p99, 로드 밸런서, 오토스케일링: 직접 실험하며 익히는 지연 시간

AI 요약

평균 지연 시간이 80ms로 안정돼 보여도 요청 100건 중 하나가 4초 걸린다면 사용자는 느린 서비스라고 느낄 수 있습니다. 특히 요청을 많이 보내는 사용자는 지연 꼬리에 걸릴 가능성도 커집니다. 글쓴이는 p50, p95, p99 같은 백분위 지표를 외우는 것만으로는 부족하며, 분포의 모양을 보고 원인을 가늠하는 감각이 필요하다고 설명합니다. 이를 연습할 수 있도록 브라우저에서 실행하는 무료 시뮬레이터 세 가지를 소개합니다. 글쓴이는 해당 시뮬레이터 제작에 참여했다고 밝힙니다.

지연 백분위 시뮬레이터

첫 번째 도구는 요청 지연 시간 분포를 히스토그램으로 보여주고 p50, p90, p95, p99 표시를 함께 움직입니다. 다섯 가지 상황을 비교합니다. 정상 API는 백분위 값이 서로 가까운 기준 분포입니다. 콜드 스타트는 일부 요청에 큰 초기화 비용이 붙어 p50은 거의 그대로인데 p99가 튀는 형태입니다. 서버리스 환경이나 JIT 워밍업에서 볼 수 있는 모양입니다. 캐시 변동은 빠른 캐시 적중과 느린 미스가 섞여 중간 백분위까지 넓게 흔들립니다. 노이지 네이버는 공유 인프라의 자원 간섭으로 중앙값 위쪽을 포함한 분포 전체가 퍼집니다. 롤링 배포는 새 인스턴스와 기존 인스턴스의 요청이 섞여 두 집단의 분포가 겹칩니다.

이 모양들은 실제 캐시나 이웃 프로세스를 재현하는 모델이 아니라, 문제 유형을 단순화한 분포입니다. 같은 p99 값도 분포 전체 모양에 따라 원인이 다를 수 있으므로 p99만으로 원인을 단정하지 말고, 익숙한 형태를 단서 삼아 추가로 확인해야 한다는 설명입니다. 또 페이지 하나가 서로 독립적인 백엔드 요청 수십 개를 보내고 모두 끝날 때까지 기다리면, 적어도 하나가 p99 지연을 겪을 확률이 빠르게 커집니다. 따라서 백엔드의 p99가 프런트엔드에서는 중앙값 수준의 경험으로 나타날 수도 있습니다.

로드 밸런서와 재시도

두 번째 도구는 서버 세 대로 구성된 환경에서 라운드 로빈, 최소 연결, IP 해시, 무작위 분배를 바꿔 가며 트래픽 흐름을 보여줍니다. 트래픽을 버스트 상태까지 높이고 서버 장애 확률을 최대 30%로 설정할 수 있으며, 실행 중 서버를 직접 중단할 수도 있습니다. 재시도 기능도 켜고 끌 수 있습니다.

글은 두 가지 실험을 권합니다. 먼저 재시도를 켠 상태에서 장애율을 높이면 실패한 요청이 다시 전송되며, 시스템이 힘든 순간에 부하가 더해집니다. 재시도는 공짜가 아니며, 장애 뒤 재시도된 요청 수를 보면 그 비용을 확인할 수 있습니다. 다음으로 각 분배 알고리즘에서 서버 하나를 내리고 트래픽이 어떻게 재배치되는지 비교합니다. IP 해시는 같은 클라이언트를 같은 서버로 보내 세션 상태를 유지하는 구조에 쓰이지만, 지정된 서버가 죽었을 때의 재분배 동작도 함께 살펴야 합니다. 라운드 로빈은 차례대로 보내고 최소 연결은 현재 부하를 기준으로 보내므로, 서버가 건강할 때는 비슷해 보여도 장애와 버스트 상황에서는 작업이 쌓이는 위치가 달라집니다.

오토스케일링과 반응 시간

세 번째 도구에서는 확장 임계값, 인스턴스 수, 수직·수평 확장 방식을 조정하고 네 가지 트래픽 상황을 시험합니다. 점진적 증가는 대부분의 정책이 무난히 따라가는 입문 사례입니다. 갑작스러운 급증에서는 임계값을 감지하고 인스턴스를 준비하는 동안 이미 사용자에게 영향이 갑니다. 트래픽 변화가 확장 반응보다 빠르면 임계값만 조정하기보다 여유 용량을 확보해야 합니다.

예측 가능한 블랙 프라이데이 트래픽은 급증 전에 용량을 늘리는 편이 반응형 확장보다 낫습니다. 변동 부하는 확장과 축소를 너무 민감하게 반복할 때 생기는 플래핑을 보여줍니다. 시뮬레이터는 축소 대기 시간을 길게 설정해 트래픽이 낮아지는 구간에도 용량을 유지하는 모습을 보여줍니다. Kubernetes HPA 같은 운영 환경의 쿨다운과 안정화 구간도 불필요한 변동을 줄이는 대신 일부 유휴 용량을 감수합니다.

세 도구를 관통하는 주제는 용량 결정이 지연 시간과 오류로 드러난다는 점입니다. 확장 시뮬레이터는 전체 백분위 분포 대신 응답 시간과 실패를 추적하지만, 용량 부족이 나쁜 지연 분포를 만들고 오토스케일러는 유휴 인스턴스를 최소화하면서 정상 분포를 유지하려 한다는 연결을 보여줍니다. 글은 먼저 다섯 가지 지연 분포를 익히고, 이어 서버 장애·재시도 실험을 한 뒤, 갑작스러운 급증과 블랙 프라이데이 상황을 연습하라고 제안합니다. 그러면 p99 그래프에서 분포 전체를 묻게 되고, 로드 밸런서 선택을 장애 시 동작의 문제로, 오토스케일러 설정을 트래픽 변화에 대한 가정으로 읽게 됩니다. 더 깊이 공부할 자료로 Google SRE의 분산 시스템 모니터링 장과 Gil Tene의 「How NOT to Measure Latency」를 안내합니다.

dev.to 반응

• @anh_nguynvn_0478e614ba — p99 급증을 보지 않으면 평균 80ms라는 숫자가 정말 위험한 함정이 됩니다. 대시보드에서는 시스템이 안정적으로 보이는데, 오토스케일링이 갑작스러운 트래픽에 너무 늦게 반응해 소수 사용자가 계속 타임아웃을 겪는 상황을 저도 본 적 있습니다. 배운 점은 오토스케일링 임계값을 정할 때 평균을 절대 믿지 말고, 지연 시간이 오르기 시작할 때 p99를 억제하도록 새 인스턴스의 워밍업 시간을 줄이는 데 집중해야 한다는 겁니다. (labagent.tech)
• @johnanderson55 — 평균이 실제 사용자 경험을 숨긴다는 점에 공감합니다. 세 시뮬레이터가 p99, 로드 밸런싱, 오토스케일링을 서로 완전히 별개의 주제로 다루지 않고 연결한 방식도 좋습니다. 갑작스러운 급증이나 서버 장애 때 무슨 일이 생기는지 보면 재시도와 확장 지연의 영향을 글로 읽는 것보다 훨씬 쉽게 이해할 수 있습니다.
• @parsa_m — 재시도는 시스템이 이미 압박을 받기 전까지는 안정성 기능처럼 보입니다. 실패한 요청이 부하를 더 만들면 작은 장애가 훨씬 큰 장애로 번질 수 있습니다.

원문: dev.to / 번역·요약: Trawling