Incident Library

IL-0413 Microsoft · 2025-10-17 (게시일)ai-infrakubernetes

Microsoft 클라우드 LLM 추론 서비스의 추론 엔진이 몰린 트래픽에 포화돼 HTTP 429·5xx 와 타임아웃을 냈다

Microsoft Redmond 의 엔지니어 세 명이 자사 클라우드 LLM 추론 서비스의 높은 심각도 장애를 분석한 논문이다. 분류 체계는 한 해 동안 서비스를 운영한 경험에서 만들었고, 정량 분석은 2025년 4월부터 6월까지의 심각도 2 장애 129건과 심각도 2.5 장애 27건, 모두 156건에 집중했다. 심각도는 0 이 가장 심각하고 4 가 가장 가벼우며, 2.5 는 심각도 2 만큼 영향이 컸지만 업무 시간 안에 해결된 장애에 붙이는 내부 등급이다. 데이터는 장애 관리 시스템 ICM, 포스트모템 보고서, 런타임 로그와 대시보드, 장애를 맡는 지정 책임자인 DRI 의 플레이북과 도구에서 손으로 모았다. 장애마다 사람이 원인 범주 네 가지 가운데 하나를 붙였고, 원인이 여럿이면 장애 요약에 가장 먼저 나온 것을 골랐다. 표본을 다시 분류해 처음 분류와 비교한 Cohen's kappa 는 0.89 였다. Cohen's kappa 는 우연히 일치할 확률을 보정한 일치도다.

서비스는 API gateway, 엔드포인트 로드 밸런서, 추론 엔진으로 이루어진다. API gateway 는 REST 나 gRPC 로 요청을 받는다. 엔드포인트 로드 밸런서는 헬스 프로브와 GPU 용량 인지 정책으로 트래픽을 보내고, request batching 과 토큰 상한을 맡는다. 추론 엔진은 모델 가중치를 올리고 요청을 실행하며 KV cache 와 샘플링 파라미터를 관리하고, Kubernetes 가 관리하는 GPU 클러스터에서 돈다. 156건 가운데 94건, 약 60% 가 추론 엔진 장애로 가장 많았고, 그 안에서 타임아웃이 약 40%, 자원 고갈이 약 29% 였다. 엔진 장애는 대부분 오래 걸리는 요청의 타임아웃과 부하 속 자원 고갈처럼 지연과 GPU 용량에서 나왔다.

사례 A 에서는 트래픽이 몰리자 이미지 인코더와 모델 컨테이너가 포화돼 GPU 와 CPU 의 균형이 무너지고 KV cache 압박이 생겼다. 샘플링 파라미터가 유난히 높은 트래픽까지 서빙을 압도해 HTTP 429, 5xx 와 타임아웃이 났다. 팀은 로드 밸런서에서 대기 토큰과 대기 요청에 상한을 두는 동적 pushback 을 켜고, request batching 과 GPU·CPU 레플리카 수를 조정하고, gRPC backoff 와 오류 매핑을 고치고, 샘플링 파라미터에 제한을 두며 클라이언트별 throttling 을 걸었다. 그 뒤 가용성이 안정되고 HTTP 429 가 줄었으며, 부하 속 타임아웃으로 인한 HTTP 5xx 도 줄었다. 오래 걸리는 요청에는 스트리밍 같은 connection liveness 방법과 GPU 용량 인지 라우팅을 썼고, 이와 함께 HTTP 408 이 줄고 SLA 가 나아졌다. 영향을 받은 고객 한 곳에서는 전체 요청 대비 HTTP 408 비율이 2025년 2월 2.72% 에서 3월 0.47% 로 내려갔다. 용량 증설, 트래픽 라우팅, 재시작은 주로 추론 엔진 장애에 썼다. 전체 156건의 조치는 모니터링만 한 경우가 75건으로 약 48.08%, 핫픽스가 44건으로 약 28.21%, 용량 증설 15건, 노드 재시작 14건, 트래픽 라우팅 7건, 배포 삭제 1건이었다.

심각도
–
영향 범위
94 of 156 high-severity incidents (April to June 2025) of Microsoft's cloud LLM inference service were inference engine failures
영향 사용자
Customers of the LLM inference service; ≈96% of all incidents affected a single endpoint
지역
–
감지까지
–
복구까지
–

증상

Microsoft 의 클라우드 LLM 추론 서비스에서 추론 엔진이 요청을 감당하지 못해 고객이 HTTP 429, 5xx 오류와 타임아웃을 받았다. 2025년 4월부터 6월까지의 높은 심각도 장애 156건 가운데 94건, 약 60% 가 추론 엔진 장애였다.

추론 엔진 장애 안에서는 타임아웃이 약 40% 로 가장 많았다. 그다음은 자원 고갈 약 29%, 크래시 약 12%, 지연 급증 약 6%, 입력 가져오기 약 6%, KV cache 약 5%, 제약 샘플링 약 1%, 메모리 누수 약 1% 였다. 엔진 장애는 대부분 지연과 GPU 용량에서 나왔고, 오래 걸리는 요청의 타임아웃과 부하 속 자원 고갈이 많았다.

전체 장애 156건의 오류 코드는 서버 쪽 HTTP 5xx 가 주를 이뤘다. HTTP 500 이 115건으로 약 74%, HTTP 408 이 16건으로 약 10%, HTTP 503 이 14건으로 약 9%, HTTP 429 와 HTTP 424 가 각각 5건으로 약 3%, HTTP 504 가 1건으로 약 1% 였다. 논문은 500 오류가 이렇게 많은 것을 엔진이 요청을 처리할 수 없는데도 요청이 그 엔진으로 라우팅되게 둔 모니터링 빈틈이 있다는 뜻으로 봤다. 장애의 약 96% 는 엔드포인트 하나에만 영향을 줬다.

사례 A 에서는 트래픽이 몰리자 이미지 인코더와 모델 컨테이너가 포화됐다. GPU 와 CPU 의 균형이 무너지고 KV cache 압박이 생겼으며, 샘플링 파라미터가 유난히 높은 트래픽이 서빙을 압도했다. 그 결과 HTTP 429, 5xx 와 타임아웃이 났다.

사례 B 에서는 오래 걸리는 요청이 프런트엔드에서 HTTP 408 타임아웃을 냈다. 백엔드는 결국 HTTP 200 으로 응답했지만, 프런트엔드는 그 전에 이미 타임아웃을 냈다.

부하가 늘면서 서빙 지표도 나빠졌다. 2025년 4월부터 6월까지 토큰 생성량이 약 1.27배 늘었고, 같은 기간 P75 TTFT 는 약 60 ms, P75 TTLT 는 약 80 ms 늘었다. 논문은 이 변화가 엔진 포화가 시작되거나 KV cache 가 비효율적이거나 아키텍처 병목이 생긴 것과 들어맞는다고 봤다.

증상 간헐적 타임아웃오류율 상승지연 시간 증가

원인

원인 용량 한계

구성 요소 모델 추론 서버
기여 요인 모니터링 사각지대
촉발
몰려드는 트래픽에 이미지 인코더와 모델 컨테이너가 포화됐다. 샘플링 파라미터가 유난히 높은 트래픽까지 겹쳐 서빙이 감당하지 못했다.

감지

논문은 고객 신고보다 먼저 헬스 프로브나 DRI 파이프라인이 낸 알림을 자동 감지로 셌다. 전체 156건 가운데 115건, 약 74% 가 자동 감지됐고 나머지는 자동으로 감지되지 않았다.

조치

후속 조치

교훈

논문은 AIOps 를 써도 적지 않은 장애가 여전히 사람의 감지나 판단을 거쳐야 했다고 밝혔다. 핫픽스는 정확성을 되찾지만 완화까지 걸리는 시간을 늘렸고, 과부하와 타임아웃 유형에서는 트래픽 라우팅과 노드 재조정이 더 빨리 완화했다. 그래서 헬스 프로브 기반 트래픽 라우팅, 재시작, 용량 증설 결정을 먼저 자동화해야 한다고 봤다. 대부분의 장애가 코드 변경이 아니라 운영 조치나 자가 복구로 끝났으므로 관측 가능성, 자동화, 잘 정해진 장애 대응 절차가 중요하다. HTTP 500 이 많았던 것은 엔진이 요청을 처리할 수 없는데도 요청을 라우팅하게 둔 모니터링 빈틈 때문이었다.

출처

관련 사례

–

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 모델 추론 서버. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.