사례2건
2건 중 1~2번째
- 증상
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 클러스터 도구를 개선한다.
IL-0235Azure OpenAI Service 의 GPT-5.2 모델 요청이 일곱 개 리전에서 HTTP 400 과 HTTP 429 오류로 실패했다Microsoft Azure2026- 증상
2026-03-09 23:20 UTC 부터 Azure OpenAI Service 고객의 GPT-5.2 모델 요청이 HTTP 400 과 HTTP 429 오류로 실패했다. 다른 GPT 모델은 영향을 받지 않았다. 영향을 받은 리전은 Australia East, Central US, East US 2, Korea Central, Norway East, Sweden Central, UK South 였다.
- 촉발
Azure OpenAI 의 GPT-5.2 모델 업데이트에 든 구성 변경이 운영 중인 모델 엔진 코드 버전과 맞지 않았다. 업데이트가 효율과 복원력을 높이려고 일부 기능 설정을 켰는데, 배포된 엔진 버전은 그 설정을 아직 지원하지 않았다.
- 원인
- 구성 요소
- 기여 요인
- 감지
3월 10일 00:19 UTC 에 서비스 모니터링이 문제를 잡았다. 고객 영향이 시작되고 약 1시간 뒤였다. 모니터링은 클라이언트 쪽 오류만 보고 서비스 쪽 HTTP 400 이상은 보지 않아 초기 감지가 늦었다.
- 조치
- 롤백이 핫픽스보다 빨리 완화할 수 있다고 판단하고 03:18 UTC 에 영향받은 모델의 롤백을 시작했다. 18:00 UTC 에 모든 영향 리전에서 롤백을 마쳤다.
- 19:30 UTC 에 리전 전체의 용량 정보를 되살려 트래픽 분산을 정상으로 돌렸다.
- 후속 조치
- 비슷한 문제를 더 빨리 완화하도록 엔지니어에게 운영 절차 교육을 더 했다. 교육에는 어떤 상황에서 빠르게 롤백할 수 있는지가 들어갔다.
- 의존 서비스가 리전 용량의 최신 정보를 주지 못할 때를 대비해, 검증된 트래픽 라우팅 정보를 캐시에 저장해 두게 했다.
- 서비스 쪽 오류에 임계값을 두어 HTTP 400 오류 모니터링을 개선했다.
- 평소 임계값에 닿지 않는 비정상 오류율에도 알림이 가도록 HTTP 4xx 오류의 이상 탐지를 개선한다. 2026년 4월에 마칠 예정이다.
- 배포 시스템에 신호를 더 넣어 문제가 있는 배포를 자동으로 멈추게 한다. 2026년 5월에 마칠 예정이다.
- Safe Deployment Practices 의 앞 단계에 백엔드 모델 인스턴스가 충분히 있게 해 이런 문제를 더 일찍 잡는다. 2026년 6월에 마칠 예정이다.
이 2건에서 가장 많이 나오는 구성 요소: 모델 추론 서버, 모델 요청 라우팅. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.