사례1건
1건 중 1~1번째
- 증상
Microsoft 의 클라우드 LLM 추론 서비스에서 추론 엔진이 요청을 감당하지 못해 고객이 HTTP 429, 5xx 오류와 타임아웃을 받았다. 2025년 4월부터 6월까지의 높은 심각도 장애 156건 가운데 94건, 약 60% 가 추론 엔진 장애였다.
- 촉발
몰려드는 트래픽에 이미지 인코더와 모델 컨테이너가 포화됐다. 샘플링 파라미터가 유난히 높은 트래픽까지 겹쳐 서빙이 감당하지 못했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
논문은 고객 신고보다 먼저 헬스 프로브나 DRI 파이프라인이 낸 알림을 자동 감지로 셌다. 전체 156건 가운데 115건, 약 74% 가 자동 감지됐고 나머지는 자동으로 감지되지 않았다.
- 조치
- 로드 밸런서에서 대기 토큰과 대기 요청에 상한을 두는 동적 pushback 을 켰다.
- request batching 과 GPU·CPU 레플리카 수를 조정했다.
- gRPC backoff 와 오류 매핑을 고쳤다.
- 샘플링 파라미터에 제한을 두고 클라이언트별 throttling 을 걸었다.
- 오래 걸리는 요청에서 엔진 연결이 타임아웃 나는 문제에는 스트리밍을 켜고, request batching 을 조정하고, 대기 토큰에 상한을 뒀다. 그 결과 HTTP 408 이 줄고 성공률이 높아졌다.
- 용량 증설, 트래픽 라우팅, 재시작을 주로 추론 엔진 장애를 완화하는 데 썼다.
- 후속 조치
- 오래 걸리는 요청과 높은 샘플링 조건에 맞게 서빙을 최적화해 타임아웃과 자원 고갈을 줄인다.
- 헬스 프로브 기반 failover 와 GPU 용량 인지 라우팅을 넓혀, 상태가 나빠진 엔드포인트에서 트래픽이 스스로 빠져나가게 한다.
- 토큰과 처리량 증가를 예측하고 용량 증설 결정을 자동화해, 완화 시간을 늘리는 수동 핫픽스와 수동 증설을 피한다.
- 적응형 알림을 배포하고 엔진 수준 텔레메트리를 늘려, 트래픽이 적은 엔드포인트에서, 그리고 오류가 모호하게 변환되는 곳에서 생기는 감지 빈틈을 메운다.
- 교훈
논문은 AIOps 를 써도 적지 않은 장애가 여전히 사람의 감지나 판단을 거쳐야 했다고 밝혔다. 핫픽스는 정확성을 되찾지만 완화까지 걸리는 시간을 늘렸고, 과부하와 타임아웃 유형에서는 트래픽 라우팅과 노드 재조정이 더 빨리 완화했다. 그래서 헬스 프로브 기반 트래픽 라우팅, 재시작, 용량 증설 결정을 먼저 자동화해야 한다고 봤다. 대부분의 장애가 코드 변경이 아니라 운영 조치나 자가 복구로 끝났으므로 관측 가능성, 자동화, 잘 정해진 장애 대응 절차가 중요하다. HTTP 500 이 많았던 것은 엔진이 요청을 처리할 수 없는데도 요청을 라우팅하게 둔 모니터링 빈틈 때문이었다.
이 사례에서 가장 많이 나오는 구성 요소: 모델 추론 서버. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.