고민보단 실천을

HTTP 커넥션 풀/Keep-Alive 실전: 타임아웃, 재사용, 커넥션 누수로 장애 나는 패턴의외로 HTTP 커넥션(keep-alive/풀) 때문에 장애가 나는 경우가 많다. 풀 고갈/누수/타임아웃을 운영 관점에서 정리한다.OkHttp 설정 예시val client = OkHttpClient.Builder() .connectTimeout(300, TimeUnit.MILLISECONDS) .readTimeout(800, TimeUnit.MILLISECONDS) .callTimeout(1000, TimeUnit.MILLISECONDS) .connectionPool(ConnectionPool(50, 30, TimeUnit.SECONDS)) .build()커넥션 누수의 전형적인 원인응답 바디를 끝까지 ..

프론트 번들 사이즈 줄이기: tree-shaking, code splitting, 분석 도구로 체감 성능 개선번들은 한 번 커지면 줄이기 어렵다. 측정->원인 찾기->구조 개선 순서로 접근해야 한다.code splitting 예시import { lazy, Suspense } from 'react';const AdminPage = lazy(() => import('./pages/AdminPage'));// 라우트/기능 단위로 지연 로딩tree-shaking이 망가지는 패턴commonjs 의존성이 크다(ESM 우선).barrel export(index.ts)가 사이드이펙트를 만든다.필요 없는 폴리필을 전역으로 넣는다.분석이 먼저번들 최적화는 '무엇이 커졌는지'를 먼저 보는 게 가장 빠르다. 큰 의존성 1개를..

CORS 프리플라이트 최적화: 왜 OPTIONS가 폭주하고 어떻게 줄이나CORS는 허용/차단만의 문제가 아니다. 운영에서는 OPTIONS 프리플라이트가 트래픽을 잡아먹는 경우가 있다. 발생 조건과 줄이는 방법을 정리한다.프리플라이트 발생 조건(요약)simple request가 아니다(커스텀 헤더, 특정 Content-Type 등).Authorization 헤더 사용.PUT/DELETE 같은 메서드.Access-Control-Max-Age로 캐시Access-Control-Allow-Origin: https://app.example.comAccess-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONSAccess-Control-Allow-Headers: Content-T..

API Pagination 실전: Offset vs Cursor, 정렬 안정성으로 중복/누락 방지하기페이지네이션은 구현이 쉬워 보여도, 데이터가 계속 변하는 서비스에서는 중복/누락과 성능 문제로 바로 운영 이슈가 된다.Offset과 Cursor(Seek) 방식의 차이를 비교하고, 정렬 안정성과 커서 설계까지 포함해 바로 적용 가능한 형태로 정리한다.Offset이 쉬운 만큼 위험한 이유OFFSET이 커질수록 앞쪽 행을 더 많이 스캔/버린다.데이터 삽입/삭제가 동시에 일어나면 페이지 사이에 중복/누락이 생긴다.정렬 키가 유일하지 않으면 결과가 흔들린다(createdAt만 정렬 등).Cursor(Seek) 페이지네이션 기본 쿼리실무에서는 (createdAt, id)처럼 유일해지는 조합을 정렬 키로 만든다.--..

Prometheus scrape/relabeling 실전: 지표 라벨 폭발을 막고 쿼리를 빠르게 만드는 법Prometheus가 느려지고 비용이 늘어나는 가장 흔한 이유는 '라벨 폭발'입니다.scrape/relabeling으로 지표를 운영 가능한 형태로 정리하는 방법을 실무 기준으로 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.실전 내용(바로 적용)Prometheus가 느려지고 비용이 늘어..

MySQL 온라인 스키마 변경: pt-online-schema-change vs gh-ost 선택 기준과 운영 함정MySQL 스키마 변경은 트래픽이 있으면 곧 장애가 될 수 있습니다.pt-osc와 gh-ost의 차이, 그리고 운영에서 터지는 함정을 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.실전 내용(바로 적용)MySQL 스키마 변경은 트래픽이 있으면 곧 장애가 될 수 있습니다.pt-o..

Kubernetes Taints/Tolerations 실전: 특정 워크로드를 전용 노드에 격리하는 법특정 워크로드(배치/ML/로그)가 전체 노드를 흔들면, 결국 '격리'가 필요합니다.Taints/Tolerations로 전용 노드를 만드는 기본 패턴을 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.실전 내용(바로 적용)특정 워크로드(배치/ML/로그)가 전체 노드를 흔들면, 결국 '격리'가 필..

HPA vs Cluster Autoscaler 차이: Pod 스케일과 노드 스케일을 같이 맞추는 법HPA를 켰는데도 스케일이 안 되는 이유는, 결국 '노드가 없다'일 때가 많습니다.HPA(파드)와 Cluster Autoscaler(노드)의 역할 차이와 운영 포인트를 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.실전 내용(바로 적용)HPA를 켰는데도 스케일이 안 되는 이유는, 결국 '노드가..

HTTP/2 vs HTTP/3(QUIC) 선택 기준: 성능이 좋아지는 조건과 주의점HTTP/3를 켰는데 체감이 없을 때가 많습니다. 좋아지는 조건이 있기 때문입니다.HTTP/2와 HTTP/3의 차이를 성능 관점으로만 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)API/HTTP 영역은 '작은 정책'이 전체 사용자 경험과 운영 비용을 바꿉니다. 그래서 실무에서는 구현보다도 기준(정책)과 검증 루프가 중요합니다.특히 프록시/CDN/게이트웨이가 있는 환경에서는 서버 코드만 보면 원인을 놓치기 쉽습니다. 레이어를 같이 정리해두면 같은 장애를 반복하지 않게 됩니다.실전 내용(바로 적용)HTTP/3를 켰는데..