사례3건

3건 중 1~3번째

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-0077 Kyverno 1.12 가 만든 ephemeralreports 객체가 쌓여 EKS 의 etcd 데이터베이스가 한도를 넘었고 운영 클러스터가 읽기 전용이 되어 모든 쓰기가 거부됐다

   Marcin Cuber2024sev1

   증상

   운영 EKS 클러스터가 읽기 전용 상태가 됐다. etcd 데이터베이스 공간이 한도를 넘자 API 서버가 새 파드 생성이나 디플로이먼트 스케일 조정처럼 객체를 바꾸는 요청을 모두 거부했다. 글쓴이는 이를 P1 장애로 다뤘다.

   컨트롤 플레인 무응답컨트롤 플레인 지연

   촉발

   Kyverno 1.12 가 ephemeralreports 객체를 너무 많이 만들어 etcd 에 쌓았다.

   원인

   소프트웨어 결함

   구성 요소

   etcd쿠버네티스 API 서버정책 엔진

   기여 요인

   한계 경보 부재디버그 접근 제한

   감지

   클러스터가 읽기 전용이 되어 쓰기 요청이 거부되면서 드러났다. 글쓴이는 kube-apiserver 감사 로그에서 mvcc: database space exceeded 를 찾는 CloudWatch Logs Insights 쿼리로 오류가 처음 나온 시각을 확인하는 방법을 소개했다.

   조치

   • AWS 의 EKS 팀과 etcd 팀이 8GB 와 10GB 이던 etcd 저장 공간을 12GB 로 늘려 잠금을 풀었다.
   • AWS 엔지니어가 여러 승인을 거친 뒤, 정리되지 않고 쌓인 ephemeralreports 객체를 etcd 에서 직접 지웠다.

   후속 조치

   • apiserver_storage_size_bytes 지표로 etcd 데이터베이스 크기를 모니터링해 8GB 한도에 닿지 않게 한다.
   • Kyverno 1.12 를 쓰고 있다면 ephemeralreports 가 쌓이는 문제를 고친 v1.12.4 로 업그레이드한다. ephemeralreports 가 계속 생기면 admission 이벤트 보고를 끄거나 --aggregationWorkers 를 늘린다.

   교훈

   EKS 의 etcd 데이터베이스 한도는 8GB 다. 한도를 넘으면 클러스터가 읽기 전용이 되고, 컴팩션도 막혀 객체를 지워 공간을 되찾을 수 없다. 글쓴이가 관찰한 바로는 객체를 지우는 스크립트도 etcd 가 잠기기 전에만 통한다. 그러므로 etcd 크기를 모니터링하고 8GB 에 절대 닿지 않게 해야 한다. EKS 에서는 etcd 에 직접 접근할 수 없어 잠긴 etcd 를 스스로 풀 수 없다. AWS 지원팀에 의존해야 하고, 해결 방법을 알아도 실행되기까지 오래 걸릴 수 있다. apiserver_storage_objects 지표로 리소스 종류별 객체 수를 보면 무엇이 etcd 공간을 차지하는지 찾을 수 있다.

   사례 보기
3. IL-0174 Fluent Bit 2.0 으로 올린 로그 수집 사이드카 가운데 Kafka output 플러그인을 쓰는 컨테이너가 SIGSEGV 로 계속 재시작됐다.

   Hyperconnect2023

   증상

   하이퍼커넥트는 운영 Kubernetes 클러스터의 로그 수집 에이전트인 Fluent Bit 를 2.0 으로 올렸다. 사용자 영향이 적은 서비스를 골라 Fluent Bit 사이드카부터 업그레이드하고 며칠 지켜보니, Kafka output 플러그인을 쓰는 컨테이너만 SIGSEGV 로 재시작되고 있었다.

   컨테이너 재시작 반복

   촉발

   운영 클러스터에서 Fluent Bit 사이드카를 2.0 으로 업그레이드했다. 이 버전의 Kafka output 플러그인은 map 이 아닌 레코드가 들어와도 타입을 확인하지 않고 처리했다.

   원인

   소프트웨어 결함

   구성 요소

   텔레메트리 에이전트

   기여 요인

   디버그 접근 제한

   감지

   업그레이드 뒤 며칠 동안 모니터링하다가 Kafka output 플러그인을 쓰는 컨테이너만 SIGSEGV 로 재시작되는 것을 발견했다.

   조치

   • produce_message 를 부르기 전에 map 이 아닌 데이터를 건너뛰도록 Fluent Bit Kafka output 플러그인을 고쳤다.
   • 고친 플러그인으로 커스텀 빌드를 만들어 사이드카로 적용했고, segmentation fault 가 사라졌다.
   • 수정 사항을 Fluent Bit 업스트림에 PR 6452 로 냈고, 제출 8일 만에 병합됐다.

   교훈

   Linux 는 segmentation fault 가 나면 core 를 덤프하고, 이 파일을 분석하면 버그를 찾을 수 있다. Kubernetes 환경에서는 core 가 저절로 남지 않으므로 볼륨과 core_pattern 을 미리 잡아 두어야 한다. 직접 분석하기 어려워 core 파일을 다른 사람에게 넘길 때는 조심해야 한다. core 에는 실행 중이던 프로세스의 메모리 일부가 들어 있어 민감 정보가 섞일 수 있다.

   사례 보기

원인별1