사례2건

2건 중 1~2번째

1. IL-0379 Azure West Europe 의 InfluxDB Cloud 에서 9월 27일부터 30일까지 쿼리가 느려지고 타임아웃됐다

   InfluxData2026

   증상

   9월 27일 22:58 UTC 에 쿼리 큐 깊이 알림이 울렸다. Azure West Europe 리전 고객의 쿼리가 느려지고 타임아웃됐다. 쓰기는 계속 받았지만 일부 파티션에서는 새 데이터를 바로 조회할 수 없었다.

   지연 시간 증가간헐적 타임아웃복제 지연프로브 실패

   원인

   용량 한계

   구성 요소

   데이터베이스데이터베이스 복제라이브니스·레디니스 프로브파드 스케줄링과 배치

   기여 요인

   모니터링 사각지대자동화 증폭

   감지

   9월 27일 22:58 UTC 에 쿼리 큐 깊이 알림이 울려 장애 대응이 시작됐다.

   조치

   • 쿼리 계층 용량을 두 배로 늘렸다.
   • 9월 28일 아침에 멈춘 스토리지 파드를 하나씩 재시작했다.
   • 9월 29일 08:58 UTC 에 readiness 검사 타임아웃을 올려 전체에 배포했다.
   • 재시작 뒤 복구 동시성을 두 배로 늘렸다.
   • 9월 30일 00:25 UTC 에 정리 타임아웃을 24시간으로 올려 안전장치가 일으키던 강제 재시작을 멈췄다.
   • 스토리지 파드마다 자원 요청을 올려 호스트에 올라가는 파드 수를 줄였고, 파드마다 페이지 캐시용 메모리와 디스크 처리량이 두 배가 됐다.

   후속 조치

   • 페이지 폴트 비율, 캐시 커버리지, 스토리지 볼륨의 디스크 읽기, 쿼리 중단 비율에 경고 알림을 더했다. 알림은 캐시 압박이 고객에게 보이기 전에 울리도록 만들었다.
   • 런북에 major page fault 를 스토리지 성능 저하의 선행 지표로 적고, 조정할 수 있는 완화 설정을 자세히 적었다.
   • 스토리지 엔진의 참조 누수를 계속 추적한다.
   • 디스크 검사를 상태 검사 경로에서 뺀다.

   교훈

   캐시가 모자란 상태는 메모리 지표에 드러나지 않았다. 스토리지 프로세스가 메모리를 적게 쓰고 나머지를 페이지 캐시가 차지하기 때문이다. InfluxData 는 major page fault 를 스토리지 성능 저하의 선행 지표로 본다. InfluxData 는 스토리지 엔진의 참조 누수와 상태 검사 경로의 디스크 검사가 이런 장애를 일으키는 위험 요인은 아니며, 진단과 복구 중에 눈에 띄어 조사할 만한 현상이라고 밝혔다.

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

   Microsoft2025

   증상

   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 이 많았던 것은 엔진이 요청을 처리할 수 없는데도 요청을 라우팅하게 둔 모니터링 빈틈 때문이었다.

   사례 보기

원인별1