사례3건

3건 중 1~3번째

1. IL-0098 ingress-nginx 에서 nginx-ingress 로 옮긴 뒤 같은 호스트를 나눠 쓰는 인그레스들의 동작이 바뀌어 cert-manager 가 새 TLS 인증서를 받지 못했다.

   2i2c2026

   증상

   새 허브를 띄우려 했는데 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 얼마 전 다른 허브에서도 같은 일이 있었다.

   요청 오라우팅배포 실패

   촉발

   nginx-ingress 로 옮긴 클러스터에서 새 TLS 인증서가 필요한 허브를 새로 배포했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러cert-manager

   기여 요인

   늦게 드러난 변경

   감지

   새 허브를 띄우다 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 전날 다른 허브에서도 같은 현상을 봤기 때문에 엔지니어가 웹사이트에서 장애를 직접 선언했다.

   조치

   • TLS 가 필요한 인그레스 객체에 어노테이션을 달아 cert-manager 가 edit-in-place 방식으로 인그레스를 고칠 수 있게 했다.

   후속 조치

   • 후속 작업을 2i2c-org/infrastructure 이슈 8016 으로 남겼다.
   • 후속 작업을 2i2c-org/infrastructure 이슈 3278 로 남겼다.

   교훈

   인그레스 컨트롤러를 바꾸면 같은 호스트를 나눠 쓰는 인그레스들 사이의 우선순위가 바뀔 수 있고, cert-manager 의 ACME 임시 인그레스처럼 그 동작에 기대는 구성 요소가 깨진다. 이 문제는 새 인증서가 필요한 배포에서 드러났다. 2i2c 는 내부 클러스터를 시험하면서 이 원인을 이미 알고 있었고, cert-manager 설정을 고치는 일도 빨랐다.

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

   사례 보기
3. IL-0186 스토리지 구성 요소가 노드에 넣은 iptables REDIRECT 규칙 때문에 워커 노드 하나의 파드가 외부 HTTP 와 HTTPS 로 나가지 못했다.

   Hans H. Kim2023

   증상

   쿠버네티스 클러스터의 특정 워커 노드에서 80 포트와 443 포트로 가는 통신이 되지 않았다. 그 노드의 파드는 외부와 HTTP, HTTPS 로 통신할 수 없었다.

   요청 오라우팅

   촉발

   스토리지 작업용 구성 요소를 설치한 서버가 특정 노드에, 80 포트와 443 포트로 가는 트래픽을 로컬 포트로 리다이렉트하는 iptables nat 규칙을 자동으로 넣었다.

   원인

   설정 변경

   구성 요소

   노드 iptables 규칙

   기여 요인

   –

   조치

   • 스토리지 담당자에게 요청해 문제의 iptables 규칙을 지웠다.

   교훈

   쿠버네티스에서는 kube-proxy 가 iptables 를 직접 다루므로 이 부분을 깊이 이해해야 한다. 네트워크 시험 중 패킷이 사라지면 어느 단계에서 문제가 생겼는지 하나씩 따져 봐야 하고, 그러려면 네트워킹이 어떤 단계를 거쳐 이루어지는지 확실히 알고 있어야 한다.

   사례 보기

원인별3