사례10건

10건 중 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-0121 우선순위 낮은 워크로드를 관리하는 컨트롤 플레인 클러스터에 잘못된 코드가 배포되어, 그 클러스터가 함께 관리하던 운영 추론 워크로드가 망가졌다

   OpenAI2025

   증상

   2025-07-09 오후 2:10 PDT 부터 gpt-4.1-mini 모델의 API 성공률이 떨어지고 ChatGPT 검색의 오류율이 크게 올랐다.

   오류율 상승

   촉발

   잘못된 코드 변경이 주로 우선순위 낮은 워크로드를 관리하는 컨트롤 플레인 클러스터에 배포되었다.

   원인

   배포 결함

   구성 요소

   –

   기여 요인

   과도한 영향 범위파괴적 변경 보호 장치 부재

   조치

   • 잘못된 코드 변경을 롤백했다.

   후속 조치

   • 운영 추론 워크로드가 이 컨트롤 플레인 클러스터에서 관리되지 않도록 막는 안전장치를 더했다.
   • 영향이 큰 컨트롤 플레인 변경을 배포할 때 쓰는 테스트를 강화했다.
   • 기존 운영 추론 워크로드를 모두 운영용 컨트롤 플레인 클러스터가 관리하도록 옮긴다.
   • 의도하지 않은 대규모 변경이 서비스에 일어나지 않게 막는 서킷 브레이커를 만든다.

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

   OpenAI2024

   증상

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

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

   촉발

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

   원인

   설정 변경

   구성 요소

   쿠버네티스 API 서버

   기여 요인

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

   조치

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

   후속 조치

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

   사례 보기
5. IL-0145 Australia East 의 전압 강하로 냉각기가 멈춰 데이터 홀 장비가 꺼지면서, 영역 중복이 아닌 AKS 작업 큐 데이터베이스가 내려가 두 리전의 AKS 생성, 수정, 삭제 작업이 막혔다

   Microsoft Azure2023

   증상

   2023년 8월 30일 10시 30분 UTC 무렵부터 Australia East 리전에서 Azure, Microsoft 365, Power Platform 서비스에 접근하거나 쓰는 데 문제가 생겼다. AKS 에서는 리소스 공급자를 거치는 생성, 조회, 수정, 삭제 작업과 스케일링이 실패했다.

   컨트롤 플레인 무응답오류율 상승서비스 중단

   촉발

   8월 30일 08시 41분 UTC, Australia East 의 영향받은 가용 영역에서 약 18마일 떨어진 전력 설비에 낙뢰가 떨어져 전압 강하가 일어났다. 이 전압 강하로 여러 데이터센터의 냉각 시스템에 있는 냉각기가 멈췄다.

   원인

   클라우드 제공자 장애

   구성 요소

   AKS 컨트롤 플레인애플리케이션 데이터베이스

   기여 요인

   단일 장애점과도한 영향 범위

   감지

   10시 47분 UTC Cosmos DB 영향이 모니터링에 잡혔고, 10시 48분 첫 자동 공지가 Azure Service Health 로 나갔다. 11시 30분 공개 Azure 상태 페이지에 첫 공지가 올라갔고, 11시 36분 Australia East 의 모든 구독에 포털 공지를 보냈다.

   조치

   • 11시 34분 UTC 냉수 온도를 낮추려고 영향받은 데이터 홀의 남은 네트워크, 컴퓨트, 스토리지 장비를 원격으로 내렸다.
   • 12시 12분 UTC 재시작이 막혔던 냉각기 다섯 대를 손으로 다시 켰다.
   • 데이터 홀 안전 점검을 마친 뒤 장비에 단계적으로 전원을 넣어 15시 10분 UTC 모든 장비의 전원을 복구했다.
   • AKS 작업 큐로 쓰는 SQL Database 가 복구되자 다른 조치 없이도 AKS 작업이 되살아났다.

   후속 조치

   • AKS 팀은 작업 큐로 쓰는 SQL Database 데이터베이스를 모두 영역 중복으로 즉시 전환한다. 완료 목표는 2023년 9월이다.
   • AKS 팀은 리전을 넘나드는 SQL Database 큐 사용을 모두 영역 중복 Service Bus 큐로 바꾼다. 완료 목표는 2023년 9월이다.
   • 가용 영역의 부하가 조금씩 늘면서 냉각기 운전 구성이 냉각기 관리 시스템의 타이밍 결함에 취약해져 있었다. 전압 변동 뒤 재시작에 실패하지 않도록 냉각기 관리 시스템의 제어 타이밍 로직을 바꿨다.
   • 여러 냉각기가 한꺼번에 멈췄을 때 손으로 재시작하는 비상 운영 절차에서, 재시작 순서를 냉각기가 붙어 있는 차례가 아니라 데이터 홀 부하를 기준으로 정하도록 바꿨다. 냉각을 모두 되살리는 동안 모든 데이터 홀이 일부라도 냉각을 받아 열 폭주가 늦춰지게 하려는 것이다.
   • 냉각기 관리 시스템을 바꾸기 전까지의 임시 조치로 데이터센터 기술자 인원을 늘려 수동 재시작 절차를 바로 실행할 수 있게 했다.
   • 스토리지 팀은 대규모 복구 과정을 최적화한다. 장애 중에 빨리 판단할 수 있도록 판단에 쓰는 데이터를 늘리고, 더 빨리 실행할 수 있도록 문제 해결 가이드를 고친다. 완료 목표는 2023년 12월이다.
   • Azure Service Fabric 팀은 SQL Database 테넌트 링 복구의 신뢰성을 높인다. 완료 목표는 2023년 12월이다.
   • SQL Database 팀은 자동 장애 조치 그룹의 발동 기준을 검토해 장애 조치가 기대한 시간 안에 일어나게 한다. 완료 목표는 2023년 10월이다.
   • SQL Database 팀은 데이터베이스를 대량으로 옮길 수 있도록 내부 도구를 개선한다. 완료 목표는 2023년 12월이다.
   • Cosmos DB 팀은 단일 리전 쓰기 계정의 서비스 관리형 장애 조치를 최적화해 복구 시간을 줄인다. 완료 목표는 2023년 11월이다.
   • ARM 팀은 스토리지 계층을 차세대 영역 중복 구조로 옮기는 작업을 마친다. 완료 목표는 2023년 12월이다.
   • 장애 관리 팀은 장비 전원을 내려야 하는 상황에 맞춰 준비 태세, 절차, 플레이북을 강화하는 방법을 찾는다. 완료 목표는 2023년 10월이다.

   교훈

   AKS 컨트롤 플레인의 기반 인프라를 여러 가용 영역에 나눠 두어도, 생성, 조회, 수정, 삭제 작업이 거치는 작업 큐 데이터베이스가 영역 중복이 아니면 한 영역의 장애가 리전 전체의 AKS 작업을 멈춘다. 다른 리전이 같은 데이터베이스에 기대고 있으면 장애가 그 리전까지 번진다. 이미 돌고 있는 워크로드는 영향을 받지 않았을 것으로 Microsoft 는 보았지만, 스케일링처럼 리소스 공급자를 거쳐야 하는 일은 모두 막혔다. 영역 중복 스토리지, 그리고 영역 복원력이나 다중 리전 쓰기를 켠 Cosmos DB 계정은 이번 장애에서도 계속 동작했고, 영역 중복 SQL Database 도 프록시 모드로 연결한 일부 고객을 빼면 중단이 없었다.

   사례 보기

원인별5