IL-0237 Lucidworks · 2026-05-28kubernetesai-infra
us-southcarolina 리전에서 Lucidworks AI 의 호스팅 LLM 이 약 1시간 반 동안 500 과 429 오류를 내며 멈췄다
2026-05-28 16:18 UTC 에서 17:53 UTC 사이에 us-southcarolina 리전의 Lucidworks AI 호스팅 LLM 을 쓸 수 없었다. llama-3-8b-instruct, llama-3v2-3b-instruct, phi-4-multimodal-instruct 로 추론하던 고객은 500 이나 429 오류를 받았다. 검색, 임베딩 모델, Platform UI 는 영향을 받지 않았다. Lucidworks Engineering 은 16:54 UTC 에 Sev1 장애를 선언했다. 장애 중 상태 페이지는 노드 업그레이드 동안 클라우드 사업자의 용량 부족으로 인스턴스가 다시 뜨지 못했다고 알렸다.
Lucidworks 는 호스팅 모델을 Ray Serve 로 서빙하며, 추론 요청을 보내는 데 head 노드와 worker 노드를 쓴다. 평소에는 head 노드가 재시작되어도 worker 노드가 요청을 계속 처리한다. 그런데 정기 쿠버네티스 패치 업그레이드가 노드 풀을 교체하면서 모든 head 노드와 worker 노드가 한꺼번에 재시작되었다. 노드 풀 업그레이드의 surge 방식은 파드가 옛 노드에서 쫓겨나기만 기다리고 새 노드에서 실행되기까지는 기다리지 않았다. 새 노드에서 파드가 Initializing 에 머물러 있어도 drain 을 성공으로 보고 다음 노드로 넘어갔다. 그래서 노드 풀이 빠르게 연달아 교체되었다. head 파드와 worker 파드는 교체 노드에서 초기화를 마치기 전에 모두 쫓겨났고, 클러스터 전체가 멈췄다.
복구는 여러 요인으로 늦어졌다. 교체된 head 노드 하나는 상태가 나빠 컨테이너 이미지를 받지 못했고, 팀은 이 노드를 손으로 지워야 했다. 6~11 GB 인 LLM 컨테이너 이미지를 받는 데 평소에는 2~4분이 걸렸지만 이때는 30~52분이 걸렸다. 팀은 별도 작업으로 새 모델을 올리던 중이었다. Ray operator 의 blue-green 배포 방식은 기존 배포와 새 배포가 모두 정상이 되어야 트래픽을 넘겼다. 그래서 blue 와 green 양쪽에서 느린 이미지 받기가 끝날 때까지 장애가 이어졌다. 팀은 상태가 나쁜 노드를 지우고, 교체 노드에서 이미지 받기가 끝나기를 기다린 뒤, 새 노드로 트래픽을 돌렸다. 17:53 UTC 에 모든 호스팅 모델이 복구되었고 18:07 UTC 에 해결을 확인했다.
- 심각도
- sev1
- 영향 범위
- Hosted LLM inference for llama-3-8b-instruct, llama-3v2-3b-instruct and phi-4-multimodal-instruct returned 500 or 429 errors; search, embedding models, the Platform UI and passthrough LLM calls were not affected
- 영향 사용자
- Customers using Lucidworks AI hosted LLM inference
- 지역
- us-southcarolina
- 감지까지
- –
- 복구까지
- 1h 35m
증상
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 호출은 정상이었다.
이 모델에 기대는 서비스를 쓰는 최종 사용자도 오류를 겪었다. Lucidworks Engineering 은 16:54 UTC 에 Sev1 장애를 선언했고, 17:14 UTC 에 상태 페이지에 첫 공지를 올렸다.
이때 팀은 정기 쿠버네티스 유지 보수로 노드를 업그레이드하던 중이었다. 17:39 UTC 공지는 클라우드 사업자의 용량 부족으로 모델을 돌리는 인스턴스가 다시 뜨지 못했다고 설명했다. 팀은 필요한 용량을 확보했지만 모델이 다시 올라오는 것이 여전히 늦어 클라우드 사업자에게 도움을 요청했다.
교체 노드에서 모델이 늦게 떴다. 교체된 head 노드 하나는 상태가 나빠 컨테이너 이미지를 받지 못했다. 6~11 GB 인 LLM 컨테이너 이미지를 받는 데 평소에는 2~4분이 걸렸지만 이때는 30~52분이 걸렸다.
원인
- 촉발
- us-southcarolina 리전 클러스터의 정기 쿠버네티스 패치 업그레이드가 노드 풀을 차례로 교체했다. surge 방식의 노드 풀 업그레이드는 파드가 옛 노드에서 쫓겨나기만 하면 다음 노드로 넘어갔다. 그래서 Ray Serve 의 head 파드와 worker 파드가 새 노드에서 뜨기 전에 모두 쫓겨났다.
감지
–
조치
- 상태가 나빠 컨테이너 이미지를 받지 못하던 교체 head 노드를 손으로 지웠다.
- 교체 노드에서 LLM 이미지 받기가 끝나기를 기다렸고, 모든 호스팅 모델이 질의에 응답하는 것을 확인했다.
- 필요한 LLM 이미지가 든 새 노드를 띄우고 Lucidworks AI 트래픽을 그 노드로 돌렸다. 예측 엔드포인트의 200 응답으로 안정을 확인했다.
후속 조치
- LLM 워크로드를 돌리는 클러스터의 쿠버네티스 업그레이드를 순서대로 진행해, 한 노드 풀이 완전히 정상이 된 뒤에 다음 노드 풀을 올리게 한다.
- 큰 ML 모델 이미지를 받는 데 오래 걸리지 않도록 이미지를 노드에 미리 올려 두는 방법을 조사한다. 후보는 디스크 이미지에 컨테이너 이미지를 미리 넣어 두는 방법과 이미지 스트리밍이다.
- 비정상적으로 느린 Docker 이미지 받기를 조사하도록 클라우드 사업자에게 지원 티켓을 연다.
- 진행 중인 배포와 겹치지 않도록 쿠버네티스 유지 보수 시간을 LLM 서비스 담당자와 맞추는 알림 절차를 만든다.
- Ray 가 새 배포와 옛 배포를 스스로 정리하기를 기다리지 않고 Lucidworks Engineering 이 blue 나 green 으로 강제 전환할 수 있도록 Ray 클러스터 도구를 개선한다.
교훈
–
출처
- https://status.lucidworks.com/incidents/160cww6nznwy · official-status · 보관본
관련 사례
같은 원인 · 공통 노드 풀
같은 원인 · 공통 노드 풀
IL-0163자동 테스트가 잡지 못한 API 변경이 배포돼 LKE 클러스터 크기를 바꿀 때 노드가 잘못된 수만큼 만들어졌고, 고객 계정에 과금되는 노드가 늘었다Linode · 2023같은 원인 · 공통 노드 풀
같은 원인 · 공통 노드 풀
같은 원인 · 공통 노드 풀
IL-01492019-09-28 07:20 UTC 이전에 만든 VMSS 기반 AKS 클러스터의 업그레이드가 PlatformImageNotFound 오류로 실패했다.Microsoft Azure · 2019같은 원인 · 공통 노드 풀
IL-0467Prow 빌드 클러스터의 노드 업그레이드 중 Boskos 파드가 크래시 루프에 빠져 GCP 프로젝트가 필요한 테스트 작업이 9시간 넘게 모두 실패했다Kubernetes project · 2019같은 원인 · 공통 노드 풀
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0237
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0237/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.