조용한 개발 노트

대규모 트래픽 환경에서 가장 어려운 질문은 “어떻게 고칠까?”가 아닙니다.“지금 이 상태를 장애로 봐야 할까?”서버는 살아 있고, 에러율도 낮으며, 모니터링 지표도 완전히 무너진 건 아닙니다.하지만 사용자 체감은 분명히 나빠지고 있고, 어딘가 불안합니다.이 글에서는 이 애매한 상태를 감각이 아니라 기준으로 판단하는 방법을 정리합니다.완전 장애보다 더 흔한 상태실무에서 마주치는 대부분의 문제는 완전 장애가 아닙니다.서비스는 응답한다에러율은 0.x%헬스 체크는 통과한다하지만,p99 레이턴시는 튀고일부 요청은 타임아웃되고CS나 알림은 점점 늘어난다이 상태가 바로,“판단이 필요한 상태”입니다.장애 판단을 어렵게 만드는 착각1. 에러율이 낮으면 괜찮다는 착각에러율은 장애 판단에 중요한 지표지만, 충분 조건은 아닙..

이전 글들에서 다룬 것처럼, 대규모 트래픽 환경의 장애는 보통 “한 번에 터지는 사건”이 아니라 느리게 전파되고, 어느 순간 폭발합니다.느린 호출이 자원을 점유하고타임아웃은 기다림을 늘리고재시도는 요청 수를 폭증시키며결국 전체가 같이 느려진다이 흐름을 경험한 팀은 결국 같은 질문에 도달합니다.“그래서… 어디서 끊어야 하지?”Circuit Breaker는 이 질문에 답하는 대표적인 구조입니다. 다만 많은 경우 Circuit Breaker를 “장애가 나면 붙이는 옵션”처럼 취급합니다.하지만 실무에서 Circuit Breaker의 본질은 옵션이 아니라, 장애 전파를 끊는 경계(boundary)입니다.장애 전염을 막는 방법은 ‘기다리지 않는 것’이다장애 전염이 일어나는 핵심은 단순합니다.느린 호출을 기다리는 동..

장애 상황에서 가장 빠르게 등장하는 대응은 보통 이것입니다.“실패했으니까 한 번 더 시도해보자.”재시도(retry)는 직관적으로 안전해 보입니다. 일시적인 네트워크 문제나 순간적인 지연이라면, 다시 시도했을 때 성공할 가능성도 분명히 있습니다.하지만 대규모 트래픽 환경에서는, 재시도가 문제를 해결하기는커녕 장애를 더 빠르고 크게 만드는 경우를 수없이 경험하게 됩니다.이 글에서는 재시도를 “복구 전략”이 아니라“부하를 증폭시키는 행위”라는 관점에서 바라봅니다.재시도는 실패를 줄이지만, 요청 수를 늘린다재시도의 가장 중요한 특성은 이것입니다.실패한 요청을 줄이는 대신, 총 요청 수를 늘린다.예를 들어,요청 100개 중 10개가 실패하고각 요청이 한 번씩 재시도된다면실제 시스템이 처리해야 하는 요청은 110개..

대규모 트래픽 환경에서 장애를 이야기할 때, 가장 많이 언급되는 안전장치는 보통 이것입니다.“타임아웃이 있으니까 괜찮지 않을까?”요청이 오래 걸리면 중간에 끊고, 문제가 되는 호출은 포기하면 전체 시스템은 보호될 것처럼 보입니다.하지만 실무에서는, 타임아웃이 있음에도 불구하고 서비스 전체가 같이 느려지는 상황을 수없이 겪게 됩니다.이 글에서는 타임아웃을 “장애 차단 장치”가 아니라“장애 전파 방식에 직접 관여하는 요소”로 바라봅니다.타임아웃은 ‘차단’이 아니라 ‘포기 시점’이다타임아웃은 흔히 이렇게 오해됩니다.“이 시간이 지나면 요청이 강제로 중단된다.”하지만 실제로 타임아웃이 의미하는 것은,“이 시간까지는 기다린다”에 가깝습니다.타임아웃에 도달하기 전까지, 요청은 여전히Thread를 점유하고Connec..

대규모 트래픽을 처리하는 서비스를 운영하다 보면, 이상한 경험을 하게 됩니다.분명히 한 서비스에서 문제가 시작됐는데,어느 순간 전체 서비스가 같이 느려진다.처음엔 이렇게 생각합니다.“저 서비스가 느려진 거지, 우리 문제는 아니야.”하지만 시간이 지나면,에러율이 조금씩 올라가고p99 레이턴시가 전반적으로 튀며결국 사용자 체감 장애로 이어진다이 글에서는 이 현상을 개별 장애가 아니라 ‘전파되는 장애’라는 관점에서 설명합니다.대부분의 장애는 “혼자” 발생하지 않는다현대의 서비스 구조에서, 하나의 요청은 하나의 서비스에서 끝나지 않습니다.대부분의 경우,프론트엔드 요청 하나가여러 백엔드 서비스를 거치고다시 하나의 응답으로 조합된다이 구조에서 중요한 점은 이것입니다.이 중 어느 한 곳만 느려져도,요청 전체가 같이 ..

트래픽이 많은 서비스를 운영하다 보면, 이런 말을 자주 듣게 됩니다.“우리 서버는 멀쩡한데, 외부 API가 좀 느린 것 같아요.”실제로 내부 지표를 보면,CPU 사용률은 안정적이고DB 쿼리도 큰 변화가 없으며Thread나 Connection Pool도 여유가 있어 보인다그런데도 API 레이턴시는 전반적으로 늘어나고, p99가 눈에 띄게 튑니다.이 글에서는 이 현상을 외부 API 성능 문제가 아니라 HTTP Client Pool과 외부 의존성이 결합되며 발생하는 구조적 문제로 바라봅니다.외부 API 호출은 “부가 작업”이 아니다외부 API 호출은 흔히 이렇게 인식됩니다.“응답 하나 받아오면 되는 작업”하지만 서버 입장에서 외부 API 호출은,HTTP 연결을 하나 점유하고Thread를 점유한 채로응답이 올 ..

트래픽이 많은 서비스를 운영하다 보면, 다음과 같은 상황을 자주 마주하게 됩니다.DB 모니터링 지표는 정상이고쿼리도 특별히 느리지 않은데API 응답은 점점 느려지거나 타임아웃이 발생한다이럴 때 가장 많이 나오는 말은 보통 이겁니다.“DB는 멀쩡한데요?”이 글에서는 이 현상을 DB 성능 문제가 아니라 DB Connection Pool이라는 동시성 경계 관점에서 설명합니다.DB는 느린데만 문제가 되는 게 아니다DB 문제가 항상 “쿼리가 느려진다”로 나타나는 것은 아닙니다.실무에서 더 자주 문제 되는 패턴은 이것입니다.DB는 일정한 속도로 응답하고 있는데애플리케이션 쪽에서 대기 시간이 발생한다이때의 병목은 쿼리 실행 시간이 아니라 DB에 접근하기 전 단계에 존재합니다.바로 Connection Pool입니다.C..

트래픽이 많은 서비스를 운영하다 보면, 다음과 같은 상황을 한 번쯤은 겪게 됩니다.CPU 사용률은 높지 않고메모리도 여유 있어 보이는데요청 응답이 점점 느려지거나 타임아웃이 발생한다이 상황에서 가장 흔한 반응은 이것입니다.“리소스는 남아 있는데, 왜 느리지?”이 글에서는 이 현상을 리소스 부족 문제가 아니라 Thread Pool이라는 동시성 한계 관점에서 설명합니다.CPU 여유 ≠ 처리 여유CPU 사용률이 낮다는 것은,“지금 실행 중인 스레드가 CPU를 다 쓰지 않고 있다”는 의미일 뿐입니다.하지만 요청을 처리하기 위해서는, CPU 이전에 반드시 필요한 자원이 있습니다.바로 실행 가능한 Thread입니다.Thread Pool이 가득 차 있으면, CPU가 아무리 남아 있어도 새로운 요청은 실행되지 못하고 ..

트래픽이 많은 서비스를 운영하다 보면, 가장 판단하기 어려운 유형의 문제가 있습니다.“항상 터지는 것도 아니고, 가끔씩만 타임아웃이 발생한다.”장애라고 부르기엔 애매하고, 그렇다고 무시하기엔 계속 신경 쓰입니다.특정 시간대에만일부 요청에서만잠깐 발생했다가 다시 정상으로 돌아옴이런 문제는 재현도 어렵고, 원인을 특정하기도 어렵습니다.이 글에서는 이 현상을 불안정한 시스템 문제가 아니라시스템이 가진 동시성 한계가 드러나는 구조적 현상으로 바라봅니다.간헐적 타임아웃이 보일 때의 공통적인 신호이 유형의 타임아웃에는 반복해서 나타나는 특징이 있습니다.CPU와 메모리는 여유 있어 보인다Pod 수를 늘려도 완전히 사라지지 않는다평균 응답 시간(p50)은 정상이다p95, p99 같은 tail latency만 튄다이 조..

트래픽이 늘어나면 가장 먼저 떠올리는 해법은 보통 이겁니다.“Pod를 더 늘리면 되지 않을까?”Kubernetes 환경에서는 HPA(Horizontal Pod Autoscaler)가 있기 때문에, CPU나 메트릭이 기준을 넘으면 Pod가 자동으로 늘어나고, 그만큼 처리량도 자연스럽게 증가할 것처럼 보입니다.그런데 실무에서는 이런 상황을 자주 마주합니다.Pod 수는 분명히 늘어났는데에러율은 크게 늘지 않았는데체감 속도는 오히려 더 나빠진 상황이 글에서는 이 현상을 “스케일이 안 된다”가 아니라“스케일이 의미 없는 구조”라는 관점에서 살펴봅니다.HPA가 해결해 주는 문제와, 해결해 주지 못하는 문제먼저 전제를 분명히 해야 합니다.HPA는 처리 자원을 늘려주는 도구이지, 병목을 제거해 주는 도구는 아닙니다.즉..