사례11건

11건 중 1~5번째

1. IL-0179 DEBUG 로그가 쏟아지자 동기 로깅을 하던 요청 스레드들이 가득 찬 stdout 파이프에서 멈춘 채 DB 커넥션을 쥐고 있어, HikariCP 커넥션 풀이 고갈되고 요청이 30초 주기로 한꺼번에 실패했다.

   MUSINSA2026

   증상

   트래픽이 많은 한 서비스에서 요청이 30초마다 무더기로 실패했다. 당직자가 처음 받은 알림도 이 증상이었다.

   오류율 상승간헐적 타임아웃커넥션 풀 고갈

   촉발

   트래픽이 많은 서비스의 운영 환경에서 DEBUG 레벨 로깅이 켜진 채 트래픽이 몰렸다. 쿼리 한 건마다 로그가 수십 줄씩 나오면서 로그량이 평소의 약 100배로 늘었다.

   원인

   설정 변경

   구성 요소

   애플리케이션 로깅 라이브러리컨테이너 런타임텔레메트리 에이전트애플리케이션 데이터베이스

   기여 요인

   미검증 가정과도한 영향 범위

   감지

   당직자가 처음 받은 알림은 요청이 30초마다 무더기로 실패한다는 내용이었다. 이후 부하테스트의 근본 원인 분석 데이터에서 30초 주기의 커넥션 풀 고갈과, stdout write 에서 멈춘 스레드들이 담긴 스레드 덤프를 확인했다.

   후속 조치

   • AsyncAppender 를 상속해 큐에 넣기 전 요청 스레드에서 trace_id 와 span_id 를 캡처하는 TraceAwareAsyncAppender 를 만들고, neverBlock=true 로 큐가 차면 로그를 버리게 해 비동기 로깅과 trace_id 보존을 함께 유지했다.
   • 지속적인 부하에 대응하도록 출력하는 로그량 자체를 적정 수준으로 관리한다.

   교훈

   AsyncAppender 를 떼어 내면서 trace_id 누락은 막았지만, 요청 스레드를 로그 출력 대기에서 지켜 주던 기능도 함께 사라졌다. 여러 서비스에 한꺼번에 적용하는 표준일수록 해결하려는 문제뿐 아니라 기존에 동작하던 무엇이 바뀌는지도 확인해야 한다. 표준의 결론이 어떤 제약을 전제로 하는지 먼저 봐야 하며, 이번에는 trace 값을 읽는 시점을 바꾸자 그 제약이 풀렸다. 비동기 로깅에서는 ThreadLocal 값이 스레드 경계를 넘지 않는다는 점을 먼저 확인해야 한다. AsyncAppender 로도 지속적인 과부하는 막을 수 없으므로 로그량 자체를 적정하게 관리해야 한다.

   사례 보기
2. IL-0122 여러 핵심 서비스가 함께 읽는 설정에 잘못된 값이 들어가 ChatGPT 파드가 크래시 루프에 빠졌다

   OpenAI2025

   증상

   2025-07-15 오후 7:43 PDT 부터 일부 사용자의 ChatGPT 대화에서 오류율이 올라갔다. 상태 페이지는 이 장애를 성능 저하로 표시했다.

   컨테이너 재시작 반복오류율 상승

   촉발

   내부 엔지니어가 잘못된 값이 든 설정 변경을 적용했다.

   원인

   설정 변경

   구성 요소

   –

   기여 요인

   과도한 영향 범위단계적 배포 부재

   조치

   • 잘못된 설정 값을 올바른 값으로 되돌렸다.
   • 영향받은 파드를 롤링 재시작해 곧바로 다시 동기화되게 했다.

   후속 조치

   • 중요한 설정 변경에 더 강한 안전장치를 둔다. 앞으로 이 서비스의 중요한 설정 변경은 클러스터 하나에 먼저 배포하고, 가용성이 떨어지면 자동 헬스 가드가 다음 배포를 멈춘다.
   • 여러 서비스가 함께 쓰는 설정을 서비스별 설정 값으로 나눠 서비스 사이의 의존 위험을 줄인다.
   • 배포 안전장치를 강화한다.

   사례 보기
3. IL-0192 Crossplane 컴포지션의 병합 정책 변경이 Service 타입을 ClusterIP 로 바꿔 클라우드 로드 밸런서가 지워지고 Grafana Cloud 서비스의 약 25%가 끊겼다.

   Grafana Labs2025

   증상

   2025년 2월 18일 08:41 UTC, Grafana Labs 의 애플리케이션 팀 여러 곳이 자기 엔드포인트 일부에 접속이 되지 않는 것을 알아챘다.

   서비스 중단리소스 삭제

   촉발

   로드 밸런서의 TLS 정책 버전을 올리면서, 기본 TLS 정책을 덮어쓸 수 있도록 Crossplane 컴포지션의 병합 정책을 바꾼 변경이 개발, 스테이징, 운영 환경에 동시에 적용됐다.

   원인

   설정 변경

   구성 요소

   설정 템플릿클라우드 로드 밸런서

   기여 요인

   미검증 가정단계적 배포 부재과도한 영향 범위파괴적 변경 보호 장치 부재

   감지

   08:41 UTC 에 애플리케이션 팀 여러 곳이 자기 엔드포인트 일부에 접속이 되지 않는 것을 알아챘다. 조사해 보니 최근의 TLS 정책 설정 변경 때문에 그 엔드포인트의 로드 밸런서가 사라져 있었다.

   조치

   • 문제의 코드 변경을 롤백했다.
   • 영향받은 쿠버네티스 Service 를 다시 만들어 쿠버네티스가 로드 밸런서를 새로 만들게 했다.

   후속 조치

   • 한 번에 두 개 이상의 웨이브로 배포하는 것을 막는 CI 검사를 넣어, 개발에서 스테이징, 카나리, 운영으로 이어지는 순서를 벗어나는 배포를 잡아내게 했다.
   • 논의만 하던 더 정교한 웨이브 설계의 우선순위를 올려 개선안을 합의하고 구현한다.
   • 실수로 지워지지 않도록 로드 밸런서에 삭제 보호를 켜기 시작했다. Crossplane 수준의 삭제 보호보다 한 층 아래에서 막는다.
   • 로드 밸런서 말고도 중요한 클라우드 리소스를 하나씩 살펴 필요한 곳에 삭제 보호를 켠다.
   • 변경 검증과 가시성을 높이려고 만든 Crossplane Managed Resources exporter 를 플랫폼 엔지니어링 안에서 베타로 시험하고 있다. 이번 장애를 일으킨 변경에 적용해 보면 차이가 분명히 드러난다.
   • TLS 정책을 다시 설정하는 기능을 제대로 완성하고 시험해, 애플리케이션 팀이 배포할 수 있게 했다.

   교훈

   작은 변경이라 위험이 낮다고 가정하고 충분한 시험과 영향 범위 줄이기를 건너뛴 것이 장애로 이어졌다. 웨이브 배포는 절차로 기대하는 데 그치지 않고 시스템이 강제해야 한다. 비상 예외는 웨이브를 고르지 않았을 때의 기본 동작이 아니라 말 그대로 예외여야 한다. 이번 변경은 시험을 안 한 것이 아니라 시험한 범위가 충분하지 않았다. 클라우드 로드 밸런서 컨트롤러와 자체 도구까지 처음부터 끝까지 돌려 봐야 의도한 작은 변화만 일어나는지 알 수 있었다. 개발 웨이브부터만 적용하도록 강제했다면 제대로 시험할 수밖에 없었을 것이다.

   사례 보기
4. IL-0118 쿠버네티스 네임스페이스 라벨을 전역으로 바꾸자 네트워크 계층이 메타데이터를 다시 계산하면서 가장 큰 GPU 클러스터들 가운데 세 곳의 컨트롤 플레인이 과부하에 빠졌고, ChatGPT 와 API 가 타임아웃과 503 오류를 냈다.

   OpenAI2024

   증상

   2024년 11월 25일 태평양 시각 오전 10시 15분부터 API 와 ChatGPT 트래픽의 상당 부분이 타임아웃과 503 오류로 실패했다.

   오류율 상승지연 시간 증가컨트롤 플레인 무응답

   촉발

   쿠버네티스 네임스페이스 라벨을 전역으로 바꿨고, 이 변경 때문에 네트워크 계층이 의도치 않게 메타데이터를 다시 계산했다.

   원인

   설정 변경

   구성 요소

   쿠버네티스 API 서버

   기여 요인

   과도한 영향 범위디버그 접근 제한

   조치

   • 영향받은 클러스터에서 워크로드를 손으로 빼냈다. 컨트롤 플레인이 응답하지 않아 이 작업이 더 복잡했다.
   • 클라우드 업체와 함께 컨트롤 플레인 노드 수를 늘리고 동시에 데이터 플레인 노드 수를 줄여 컨트롤 플레인을 회복시켰다.

   후속 조치

   • 같은 장애가 다시 나지 않도록 네임스페이스 변경을 잠갔다.
   • 일부 종류의 인프라 배포를 동결했다.
   • 같은 종류의 장애가 반복되지 않도록 신원을 허용 목록으로 관리한다.
   • 가능한 경우에는 트래픽이 자동으로 다른 곳으로 더 잘 옮겨 가도록 GPU 로드 밸런싱 로직을 고친다.
   • 플릿 전체에 걸친 인프라 변경을 관리하는 방식을 개선한다.

   사례 보기
5. IL-0152 정비 작업 중 FRA1 내부 인프라 클러스터에 잘못된 설정이 들어가 그 위에서 돌던 DOKS 클러스터 200개의 컨트롤 플레인이 자동으로 삭제됐다.

   DigitalOcean2024

   증상

   2024-01-23 13:02 UTC 에 DigitalOcean 은 12:18 UTC 부터 FRA1 리전의 쿠버네티스 클러스터 문제를 조사하고 있다고 공지했다. 사용자는 FRA1 클러스터와 통신할 때 오류를 겪을 수 있었다.

   리소스 삭제컨트롤 플레인 무응답

   촉발

   정비 작업 중 FRA1 내부 인프라 클러스터에 잘못된 설정 변경이 실수로 적용됐다.

   원인

   설정 변경

   구성 요소

   etcd쿠버네티스 API 서버

   기여 요인

   자동화 증폭파괴적 변경 보호 장치 부재과도한 영향 범위

   감지

   13:02 UTC 의 첫 상태 페이지 공지는 12:18 UTC 부터 조사 중이라고 했다. 사후 보고서의 타임라인에서는 12:36 에 잘못된 설정을 원인으로 확인했다.

   조치

   • 영향받은 클러스터마다 가장 최근 백업으로 etcd 클러스터를 되살렸다.
   • etcd 를 되살린 뒤 상태가 없는 컨트롤 플레인 컴포넌트를 다시 올려 컨트롤 플레인 복구를 마쳤다.
   • 13:00 에 복구 중 예상하지 못한 문제가 생기자 복구 메커니즘을 추가로 패치했고, 15:00 에 문제를 모두 해결했다.
   • 복구 도중 추가로 발견한 작은 버그를 고쳤다.
   • 고객지원팀이 영향받은 고객에게 직접 연락해 다음 조치를 안내했다.

   후속 조치

   • 운영 환경에서 어떤 경우에도 인프라 클러스터 자원이 자동으로 삭제되지 않게 막는 수정을 배포했다.

   교훈

   컨트롤 플레인을 받치는 인프라 클러스터의 설정 변경 하나가 한 리전의 DOKS 클러스터 200개의 컨트롤 플레인을 한꺼번에 지웠다. 하루 두 번 받아 둔 etcd 백업으로 클러스터를 되살릴 수 있었지만, 컨트롤 플레인 데이터는 백업 주기만큼, 최대 12시간 전 상태로 돌아갔다. 컨트롤 플레인이 사라진 동안에도 노드의 워크로드는 계속 돌았다.

   사례 보기

원인별1