사례4건

4건 중 1~4번째

1. IL-0022 Claude 서빙 인프라의 버그 세 개가 겹쳐 2025년 8월부터 9월 초까지 응답 품질이 간헐적으로 떨어졌다

   Anthropic2025

   증상

   2025년 8월 초부터 일부 사용자가 Claude 의 응답이 나빠졌다고 알리기 시작했다. 처음 들어온 보고는 평소에도 늘 오르내리는 사용자 피드백과 구분하기 어려웠다. 8월 말이 되자 보고가 더 잦아지고 끊이지 않아 조사가 시작됐다.

   응답 품질 저하요청 오라우팅

   촉발

   8월 5일 Sonnet 4 요청 일부를 1M 토큰 컨텍스트 윈도우용 서버로 보내는 라우팅 버그가 들어갔다. 8월 25일과 26일 배포에서 TPU 서버의 잘못된 설정과 토큰 선택 코드 변경이 더해졌다. 8월 29일에는 로드 밸런싱 변경으로 잘못 라우팅되는 트래픽이 늘었다.

   원인

   소프트웨어 결함

   구성 요소

   모델 요청 라우팅TPUXLA 컴파일러

   기여 요인

   장애 중첩모니터링 사각지대디버그 접근 제한초기 신호 무시

   감지

   8월 초부터 사용자 보고가 들어왔지만 평소에도 늘 오르내리는 피드백과 구분되지 않았다. 8월 말 보고가 잦아지고 끊이지 않자 조사를 시작했고, 그 조사에서 버그 세 개가 드러났다. 벤치마크, 안전성 평가, 성능 지표, 소규모 카나리 배포는 이 저하를 잡지 못했다. XLA 버그는 Haiku 3.5 에서 먼저 관찰했고, Opus 3 의 문제는 나중에 이 버그와 맞아떨어지는 사용자 보고가 들어온 뒤에 알았다.

   조치

   • 짧은 컨텍스트 요청과 긴 컨텍스트 요청이 맞는 서버 풀로 가도록 라우팅 로직을 고쳐 9월 4일 배포했다.
   • TPU 서버의 잘못된 설정을 9월 2일 롤백했다.
   • 토큰 선택 코드 변경을 Haiku 3.5 는 9월 4일, Opus 3 는 9월 12일에 롤백했고, Sonnet 4 도 만약을 위해 롤백했다.
   • 근사 top-k 를 정확한 top-k 로 바꾸고 일부 연산을 fp32 정밀도로 통일했다.

   후속 조치

   • 배포 과정에 예상하지 못한 글자 출력을 잡는 테스트를 넣었다.
   • 정상 구현과 망가진 구현을 더 확실히 가려내는 평가를 만들었다.
   • 실제 운영 시스템에서 품질 평가를 계속 돌려 컨텍스트 윈도우 로드 밸런싱 오류 같은 문제를 잡는다.
   • 사용자 개인정보를 해치지 않으면서 커뮤니티 피드백을 디버깅할 수 있는 인프라와 도구를 만든다.
   • XLA:TPU 팀과 함께 컴파일러 버그 수정을 진행한다.

   교훈

   이번 세 버그는 잡음이 많은 평가에 크게 기대는 검증으로는 잡히지 않았다. Claude 가 한 번씩 하는 실수에서는 잘 회복해서 문제가 평가 점수에 드러나지 않았다. 온라인 보고가 늘어도 그 보고를 최근 변경 하나하나와 연결할 방법이 없었다. 겹친 버그가 플랫폼마다 다른 증상을 다른 빈도로 내면 원인 없는 무작위 저하처럼 보인다. 근본 원인을 고쳤다고 믿고 오래된 우회 코드를 지우면 그 코드가 가리던 다른 버그가 드러날 수 있다. 문제를 좁히는 데 결국 도움이 된 것은 사용자가 알려 준 구체적인 변화와 예상 밖 동작의 예시, 그리고 여러 사용 사례에 걸쳐 나타난 패턴이었다.

   사례 보기
2. IL-0138 nvidia-dkms-390 드라이버 빌드 실패로 망가진 커널 헤더가 몇 주 동안 방치됐다가, 정전 뒤 재부팅하자 하나뿐인 마스터 노드가 커널 패닉에 빠져 홈랩 쿠버네티스 클러스터가 6일 동안 멈췄다.

   Barush Mendez2025

   증상

   2025년 3월 3일 14:15:34부터 홈랩 쿠버네티스에 올린 서비스에 접속되지 않았다. 운영자가 서비스에 들어가려다 직접 알아챘고, 알아채기까지 3시간이 걸렸다.

   컨트롤 플레인 무응답서비스 중단모니터링 중단

   촉발

   정전 때문에 마스터 노드가 재부팅됐다.

   원인

   소프트웨어 결함

   구성 요소

   GPU 드라이버리눅스 커널쿠버네티스 API 서버

   기여 요인

   초기 신호 무시늦게 드러난 변경단일 장애점모니터링 사각지대

   감지

   운영자가 서비스에 접속하려다 직접 알아챘다. 자동 알림이 없어서 알아채기까지 3시간이 걸렸다.

   조치

   • 원격 접속이 되지 않아 모니터를 연결해 부팅 로그를 보고 커널 패닉을 확인했다.
   • 이전 커널 버전으로 부팅해 시스템을 되살렸다.
   • sudo apt-get remove --purge '^nvidia-.*' 로 망가진 패키지를 지우고 sudo dpkg --configure -a 로 패키지 설정 문제를 고쳤다.
   • dpkg -l | grep -v ^ii 로 남은 망가진 패키지를 찾아 sudo apt-get remove --purge <package_name> 으로 하나씩 지웠다.
   • sudo apt-get install -f 로 빠진 의존성을 채우고 sudo apt-get install --reinstall linux-headers-$(uname -r) 로 커널 헤더를 다시 설치했다.
   • 머신을 재부팅해 커널 패닉이 사라진 것을 확인했다.

   후속 조치

   • GPU 드라이버 설치가 완전히 성공했는지 확인하고, 오류가 나면 바로 변경을 되돌린다.
   • 단일 장애 지점을 없애도록 클러스터를 고가용성 구성으로 옮긴다.
   • 고가용성 구성에서 Kube-API 를 로드 밸런서 뒤에 둔다.
   • 장애를 기록하고 해결 과정을 추적할 티켓 시스템을 만든다.
   • 미리 정해 둔 문제 해결 절차를 만들어 홈랩 장애 대응 시간을 줄인다.
   • Prometheus 와 Grafana 같은 인프라 모니터링을 넣어 문제를 미리 잡는다.
   • 주요 서비스에 HTTP, TCP 검사를 거는 블랙박스 모니터링을 넣어 쿠버네티스 클러스터 밖에서도 장애를 잡는다.

   교훈

   드라이버 빌드 실패를 그대로 두면 몇 주 뒤 재부팅 때 터질 수 있다. 자동 알림이 없어서 발견과 복구가 늦었다. 마스터 노드가 하나뿐이라 노드 하나의 고장이 클러스터 전체 장애가 됐다. 원인을 찾은 뒤에는 비교적 간단히 고쳤고, 데이터 손실은 없었다.

   사례 보기
3. IL-0032 mutating admission controller 의 JSON 패치 버그로 일주일 동안 새 코드가 배포되지 않았고, 운영 서비스 하나는 파드가 두 개만 남아 오류율이 치솟았다

   Airbnb2020

   증상

   운영 서비스 하나에서 오류율이 높아졌고 그 서비스는 배포도 되지 않았다. 배포할 때 인덱스 5에 접근할 수 없다는 뜻의 unable to access invalid index 오류가 났는데, 처음에는 무슨 뜻인지 알기 어려웠다.

   오류율 상승처리량 저하배포 실패

   촉발

   지난 한 달 사이에 도입한 mutating admission controller 에 변경이 들어갔고, 그 뒤로 컨트롤러가 배열에서 항목 두 개를 지우는 JSON 패치를 잘못된 순서로 만들었다. 이 변경은 장애가 드러나기 7일 전에 적용되어 있었다.

   원인

   소프트웨어 결함

   구성 요소

   어드미션 웹훅수평 파드 오토스케일러

   기여 요인

   늦게 드러난 변경모니터링 사각지대초기 신호 무시

   감지

   운영 서비스의 오류율이 높아지고 배포가 실패하면서 드러났다. 지표는 이미 있었지만 그 지표에 걸린 알림이 없어, 7일 동안 배포가 실패하는 것을 아무도 알아채지 못했다.

   조치

   • 해당 클러스터에서 mutating admission controller 를 지워 파드가 다시 정상적으로 뜨게 했다.

   후속 조치

   • 이 문제를 더 일찍 잡을 수 있었던 기존 지표에 알림을 건다.

   교훈

   클러스터에 mutating admission controller 가 있다는 사실을 늘 염두에 둔다. 최근에 도입한 것이라 장애가 났을 때 팀원 대부분이 이를 먼저 떠올리지 못했다. 막히면 도움을 청한다. 동료를 호출한 뒤에야 조사가 진척됐다. 오류 문구를 검색한다. 처음 보고된 오류 문구를 바로 검색했다면 이미 알려진 문제라는 것을 훨씬 일찍 알았을 것이다. 알림을 만든다. 문제를 일찍 잡을 수 있는 지표가 있었지만 알림이 없었다.

   사례 보기
4. IL-0011 HAProxy 인그레스 템플릿이 백엔드 파드를 IP 순으로 정렬해 일부 파드에 요청이 몰리고 인그레스 컨테이너가 OOMKilled 됐다

   Skyscanner2019

   증상

   어느 일요일, 클러스터 사용자 한 명이 지연 시간이 올라갔다며 쿠버네티스 업무 시간 외 지원 담당을 직접 호출했다. 특히 p90 과 최댓값 지연이 높았다.

   지연 시간 증가부하 불균형OOMKilled간헐적 연결 실패

   촉발

   HAProxy 인그레스 컨트롤러를 v0.6 으로 올렸다. v0.5 문서는 sort-backends 플래그의 기본값이 false 이고 백엔드 서버를 기본으로 무작위로 섞는다고 설명했다. 그러나 템플릿이 pod_ip:port 를 키로 하는 맵을 순회할 때 Go 의 text/template 이 키 순서대로 방문해, 파드는 늘 IP 오름차순으로 설정 파일에 들어갔다. 운영 클러스터처럼 변화가 잦은 곳에서는 설정이 자주 다시 쓰였고, HAProxy 가 무중단 리로드를 하지 못해 재시작하는 일이 잦았다. 그때마다 모든 HAProxy 인스턴스가 같은 목록의 처음부터 라운드 로빈을 시작했다.

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러HAProxy설정 템플릿

   기여 요인

   스테이징 불일치미검증 가정초기 신호 무시

   감지

   클러스터 사용자가 p90 과 최댓값 지연이 오른 것을 보고 업무 시간 외 쿠버네티스 지원 담당을 직접 호출했다. 그 전에도 한 사용자가 파드 사이 요청 분포가 고르지 않다고 알렸지만 팀은 우선순위를 낮게 두었다.

   조치

   • 내부 배포 도구 Slingshot 의 설정을 바꿔, 영향받은 서비스의 매니페스트가 파드 IP 대신 Service VIP 를 쓰게 했다.
   • 컨트롤러가 맵에 넣은 순서를 슬라이스에 보관하고 템플릿이 그 슬라이스를 순회하도록 컨트롤러 코드와 설정 템플릿을 패치했다.
   • 패치를 샌드박스 클러스터에서 테스트한 뒤 운영 클러스터에 배포했다.

   후속 조치

   • 컨트롤러 패치를 운영에서 돌리고, 백엔드 주소는 다시 파드 IP 를 기본으로 쓴다.
   • 업스트림 프로젝트에 GitHub 이슈와 PR 을 올려 문제를 알렸다.
   • 클러스터 컴포넌트를 바꿀 때는 구체적인 동작과 조건을 염두에 두고 테스트한다.

   교훈

   클러스터 컴포넌트를 바꿀 때는 특정 동작과 조건을 염두에 두고 테스트해야 한다. 팀은 백엔드 목록이 정렬되면 hot-podding 이 생긴다는 것을 이미 알았지만, 새 플래그가 기대대로 동작하는지 충분히 테스트하지 않았다. 같은 키워드라도 언어의 한 곳에서 동작하는 방식이 다른 곳에서도 같으리라고 기대하면 안 된다. Go 의 range 와 text/template 의 range 는 맵을 순회하는 순서가 달랐다. 쿠버네티스 클러스터의 작은 컴포넌트 하나만 바꿔도 클러스터 사용자와 고객에게 큰 피해를 줄 수 있다.

   사례 보기

원인별1