그래프
사례3건
3건 중 1~3번째
- 증상
2026-05-28 16:18 UTC 부터 us-southcarolina 리전에서 Lucidworks AI 가 호스팅하는 LLM 인 llama-3-8b-instruct, llama-3v2-3b-instruct, phi-4-multimodal-instruct 에 보낸 질의가 500 이나 429 오류로 실패했다. 검색, 임베딩 모델, Lucidworks Platform UI, passthrough LLM 호출은 정상이었다.
- 촉발
us-southcarolina 리전 클러스터의 정기 쿠버네티스 패치 업그레이드가 노드 풀을 차례로 교체했다. surge 방식의 노드 풀 업그레이드는 파드가 옛 노드에서 쫓겨나기만 하면 다음 노드로 넘어갔다. 그래서 Ray Serve 의 head 파드와 worker 파드가 새 노드에서 뜨기 전에 모두 쫓겨났다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 상태가 나빠 컨테이너 이미지를 받지 못하던 교체 head 노드를 손으로 지웠다.
- 교체 노드에서 LLM 이미지 받기가 끝나기를 기다렸고, 모든 호스팅 모델이 질의에 응답하는 것을 확인했다.
- 필요한 LLM 이미지가 든 새 노드를 띄우고 Lucidworks AI 트래픽을 그 노드로 돌렸다. 예측 엔드포인트의 200 응답으로 안정을 확인했다.
- 후속 조치
- LLM 워크로드를 돌리는 클러스터의 쿠버네티스 업그레이드를 순서대로 진행해, 한 노드 풀이 완전히 정상이 된 뒤에 다음 노드 풀을 올리게 한다.
- 큰 ML 모델 이미지를 받는 데 오래 걸리지 않도록 이미지를 노드에 미리 올려 두는 방법을 조사한다. 후보는 디스크 이미지에 컨테이너 이미지를 미리 넣어 두는 방법과 이미지 스트리밍이다.
- 비정상적으로 느린 Docker 이미지 받기를 조사하도록 클라우드 사업자에게 지원 티켓을 연다.
- 진행 중인 배포와 겹치지 않도록 쿠버네티스 유지 보수 시간을 LLM 서비스 담당자와 맞추는 알림 절차를 만든다.
- Ray 가 새 배포와 옛 배포를 스스로 정리하기를 기다리지 않고 Lucidworks Engineering 이 blue 나 green 으로 강제 전환할 수 있도록 Ray 클러스터 도구를 개선한다.
- 증상
2026-02-23 17:30 UTC 에 ml-serve-codfw 업그레이드가 끝난 직후, 일부 머신러닝 서비스의 지표에 5XX 응답 코드가 나타나기 시작했고 알림이 울렸다. 실행 중인 모델 서버의 절반이 영향을 받았고, 이 서비스들에는 약 24시간 동안 접근할 수 없었다.
- 촉발
머신러닝 운영 쿠버네티스 클러스터 두 곳을 1.31 로 올리면서 Istio 를 1.15 에서 1.24 로 올렸다. 새 Istio 는 VirtualService 의 host 값을 더 엄격하게 검증해, host 가 겹치는 VirtualService 가 둘 이상이면 하나만 받고 나머지를 버렸다.
- 원인
- 구성 요소
- 기여 요인
- 감지
영향받은 모델 서버를 쓰는 사람들이 talk-to-machine-learning Slack 채널에 처음 알렸다. codfw 업그레이드 직후부터 Machine Learning 팀의 IRC 채널에 알림이 올라와 있었지만 팀은 알아채지 못했다.
- 조치
- Istio 핫픽스를 배포해 HTTP 500 대부분을 없앴고, 2026-02-24 16:00 UTC 에 장애가 끝났다.
- 근본 수정을 ml-staging-codfw 에서 확인한 뒤 2026-03-03 13:17 UTC 에 영향받은 모든 클러스터에 배포했다.
- 후속 조치
- 알림을 관련 Slack 채널로 보내거나, IRC 나 alerts.wikimedia.org 를 지켜보는 방안을 검토한다.
- SLO 를 더 두는 방안을 검토한다. Istio 지표가 바뀌었으므로 revertrisk-la 의 가용성 SLO 와 지연 SLO 같은 기존 SLO 도 고친다.
- 교훈
사용자가 처음 알린 시점부터 보면 비교적 짧은 시간에 문제를 풀었다. 반면 이 문제는 스테이징 클러스터에서 먼저 잡을 수 있었다. 팀은 업그레이드를 알리고 테스트를 요청했다. 클러스터를 올릴 때마다 팀 안에서 바로 테스트했다면 문제를 더 일찍 찾을 수 있었다. httpbb 테스트가 있다는 것을 관련자 모두가 알지는 못했다. codfw 업그레이드 직후 울린 알림을 Machine Learning 팀의 누구도 보지 못했다. 운도 따랐다. 깨진 기능을 되살릴 Istio 핫픽스를 찾는 데 도움을 줄 기술 담당자가 마침 온라인에 있었다.
- 증상
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 이 많았던 것은 엔진이 요청을 처리할 수 없는데도 요청을 라우팅하게 둔 모니터링 빈틈 때문이었다.
이 3건에서 가장 많이 나오는 구성 요소: 모델 추론 서버, Istio. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.