Kubernetes HPA 스래싱 진정 플레이북

지난달 화요일 점심 시간에 주문 API 지연이 95퍼센타일 기준 2.8초까지 튀었는데, 처음엔 당연히 데이터베이스 병목을 의심했습니다. 그런데 대시보드를 겹쳐 보니 CPU는 55퍼센트 안팎인데 파드 수가 6개에서 18개로 급증했다가 10분 안에 다시 7개로 내려오는 패턴이 반복됐습니다. 문제는 리소스 부족이 아니라 HPA 스래싱이었습니다. 트래픽이 2~3분 단위로 출렁이는 서비스인데 HPA가 30초 주기로 평균 CPU만 보고 확대·축소를 반복하니, 새 파드가 워밍업하기도 전에 축소 판단이 내려졌고 캐시 미스와 커넥션 재수립이 겹치면서 응답 시간이 더 나빠졌습니다. 당시 온콜 채널에서 가장 혼선이 컸던 지점은 “파드를 더 늘리면 되지 않나”라는 직관이었습니다. 실제로는 파드 수 변동 폭이 크면 큐 길이와 레디니스 지연이 함께 흔들려 장애가 길어집니다. 그래서 우리는 문제 정의를 “처리량 부족”이 아니라 “스케일 의사결정 주기 불일치”로 바꿨고, 이 한 줄을 기준으로 튜닝 우선순위를 다시 정했습니다.

판단 기준은 세 가지로 고정했습니다. 첫째, 스케일 이벤트 간격이 파드 기동 완료 시간보다 짧은지 확인합니다. 우리 클러스터는 이미지 풀과 애플리케이션 초기화까지 평균 75초가 걸리는데, HPA 평가 주기가 30초면 동일 피크에서 상반된 결정을 연속으로 내리기 쉽습니다. 둘째, 요청량 메트릭과 CPU 메트릭의 위상 차이를 봅니다. 주문 API는 트래픽 급증 후 CPU 상승까지 40~60초 지연이 있었고, 이 구간에서 축소가 먼저 실행돼 큐가 쌓였습니다. 셋째, 최소 레플리카가 피크 직전의 안정 상태를 지키는 값인지 확인합니다. 우리는 minReplicas: 4로 설정해 두었는데 실제 평시 안정 구간이 7~8개라, 점심 피크가 시작되면 매번 바닥에서 재학습하듯 스케일링이 시작됐습니다. 이 기준으로 로그를 다시 읽으니 원인이 선명해졌습니다. “CPU 임계값을 낮출까 높일까”가 핵심이 아니라, 메트릭 관측 창과 워크로드 반응 시간을 맞추는 것이 먼저였습니다.

실행 절차는 하루 단위로 작게 끊어 적용했습니다. 1일차에는 HPA에 behavior.scaleDown.stabilizationWindowSeconds를 300으로 넣어 축소 결정을 늦췄고, 급격한 하강을 막기 위해 1분당 축소 비율 상한을 20퍼센트로 제한했습니다. 2일차에는 minReplicas를 8로 올리고, CPU 단일 기준 대신 요청량 기반 커스텀 메트릭을 병행해 “트래픽 급등 초기”를 먼저 감지하게 바꿨습니다. 3일차에는 배포 파이프라인에 부하 재현 시나리오를 넣어 점심 시간 패턴을 사전에 재생했고, 튜닝값이 바뀌면 자동으로 비교 리포트가 나오게 했습니다. 여기서 효과가 가장 컸던 장면은 롤백 기준을 미리 적어 둔 부분이었습니다. 평균 지연이 20분 이상 개선되지 않거나 에러율이 0.8퍼센트를 넘으면 즉시 이전 HPA 설정으로 되돌리도록 정해 두니, 팀이 불안해서 중간에 값을 다시 흔드는 일이 줄었습니다. 결과적으로 같은 트래픽 조건에서 파드 변동 폭은 12개에서 4개로 줄었고, 95퍼센타일 지연은 2.8초에서 1.1초로 안정됐습니다.

운영 체크리스트는 단순하지만 반드시 남겨야 합니다. HPA 변경 전후로 scale events/min, ready latency, queue depth, 95p latency 네 지표를 같은 대시보드에서 비교하고, 변경 사유를 PR 본문에 한 문장으로 기록하세요. 스케일다운 지연을 길게 잡았으면 비용 경보도 함께 조정해야 합니다. 그렇지 않으면 장애는 줄었는데 월말 비용 알림이 폭발해 다시 과도한 축소 압력이 생깁니다. 또 하나, 프로브 설정을 건드리지 않은 채 HPA만 튜닝하면 “스케일은 안정인데 재시작은 증가” 같은 반쪽 결과가 나올 수 있습니다. 우리는 실제로 readiness timeout을 기본값으로 두고 있다가 피크 중 재시작이 늘어 두 번째 사고를 겪었습니다. 마지막으로 회고 때는 수치보다 결정 순서를 복기하세요. 어떤 경보를 보고, 누가 축소 지연을 승인했고, 언제 롤백 가능성을 닫았는지 남겨야 다음 온콜이 같은 실수를 피합니다. HPA 스래싱은 복잡한 이론보다 운영 리듬을 서비스 리듬에 맞추는 문제였고, 그 관점을 팀 공통 언어로 만든 뒤에야 장애가 잦아들었습니다.