사례52건

52건 중 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-0136 Sweden Central 리전에서 내부 서비스 배포가 캐시를 비워 메타데이터 백엔드에 평소 20배의 트래픽이 몰렸고, 데이터베이스 연결에 기대는 헬스 체크가 인스턴스를 계속 재시작시켜 Azure OpenAI 요청이 6시간 가까이 실패했다

   Microsoft Azure2026

   증상

   2026년 9월 29일 10시 03분 UTC 부터 15시 58분 UTC 까지 Sweden Central 리전의 Azure OpenAI Service, Foundry Agent Service, Foundry Models, Azure AI services 에서 요청이 간헐적으로 실패했다. 고객은 이 리전에 올라간 모델과 데이터 플레인 API 에 요청을 보낼 때 지연 증가, HTTP 500 오류, HTTP 503 오류를 겪었다.

   오류율 상승지연 시간 증가간헐적 연결 실패간헐적 타임아웃프로브 실패아웃바운드 연결 고갈

   촉발

   09시 38분 UTC 에 Sweden Central 에서 내부 서비스 하나의 계획된 배포가 시작됐다. 이 배포가 그 서비스의 캐시를 비웠고, 배포 시점이 리전의 트래픽 정점과 겹쳤다.

   원인

   배포 결함

   구성 요소

   인메모리 캐시애플리케이션 데이터베이스

   기여 요인

   피크 시간 변경재시도 폭주자동화 증폭모니터링 사각지대런북 부재의존성에 묶인 헬스 체크

   감지

   10시 17분 UTC 서비스 모니터링이 리전의 Azure OpenAI Service 요청 실패율 상승을 감지해 엔지니어링 팀에 경보를 보냈다. 고객 영향이 시작되고 14분 뒤였다. 10시 28분 엔지니어가 투입돼 조사를 시작했다.

   조치

   • 15시 40분 UTC 백엔드 서비스의 자동 헬스 체크가 원격 연결에 의존하지 않도록 구성을 바꿔 재시작 루프를 멈췄다.

   후속 조치

   • 백엔드 서비스의 자동 헬스 체크가 데이터베이스 계층 연결에 의존하지 않도록 바꿔, 의존 서비스에 문제가 생겨도 인스턴스가 불필요하게 재시작되지 않게 했다.
   • 백엔드 서비스가 쓰는 캐시 계층의 부하와 지연에 모니터링과 경보를 더했다.
   • 이런 연결 고갈 상황에 맞춰 문제 해결 가이드와 절차를 고쳐 온콜 엔지니어가 비슷한 상황을 수습할 수 있게 했다.
   • 트래픽이 갑자기 늘어도 백엔드 서비스가 버티도록 스로틀링과 요청 속도 제한을 더한다. 완료 목표는 2026년 10월이다.
   • 여러 리전에서 백엔드 서비스가 쓰는 캐시 계층의 용량을 늘린다. 완료 목표는 2026년 10월이다.
   • 진단 지표와 자동 탐지를 개선해 이런 문제를 더 빨리 찾게 한다. 완료 목표는 2026년 10월이다.
   • 장기적으로 백엔드 서비스가 쓰는 캐시 계층을 파티션으로 나눠 처리량을 높인다. 완료 목표는 2026년 12월이다.

   교훈

   헬스 체크가 원격 의존성 연결에 기대면, 의존성 쪽 문제가 인스턴스를 계속 재시작시키는 루프로 번진다. 이번 장애는 트래픽 급증 자체보다 이 재시작 루프 때문에 6시간 가까이 이어졌다. 캐시를 비우는 배포를 트래픽 정점에 내보내면 캐시 미스가 뒤쪽 서비스로 한꺼번에 몰린다. 연결 고갈은 기존 네트워크 지표에 잘 드러나지 않았고, 그 사이 규모 조정과 자원 증설처럼 원인과 맞지 않는 조치에 시간을 썼다. Microsoft 는 고객에게 지수 백오프를 쓰는 재시도 패턴과 Microsoft Foundry 의 비즈니스 연속성 지침을 검토하라고 권했다.

   사례 보기
3. IL-0092 ingress-nginx 를 1.12.0 에서 1.14.3 으로 올리자 새 ModSecurity 와 OWASP Core Rule Set 이 정상 요청을 오탐으로 막아 HMPPS 사용자가 인증하지 못했다.

   UK Ministry of Justice2026

   증상

   2026년 3월 30일 08:56 에 Cloud Platform 팀은 #hmpps-auth-audit-registers 슬랙 채널에서 ModSecurity 가 요청을 예상치 못하게 막는다는 메시지를 봤다. 같은 날 07:11 에 운영 인그레스 세 개에 새 ingress-nginx 를 배포하기 시작한 뒤였다.

   오류율 상승서비스 중단

   촉발

   Cloud Platform 팀이 ingress-nginx 1.14.3 을 운영 인그레스 세 개에 배포했다. 이 버전에는 새 ModSecurity WAF 와 새 OWASP Core Rule Set 이 들어 있었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러웹 애플리케이션 방화벽 규칙

   기여 요인

   스테이징 불일치

   감지

   Cloud Platform 팀은 HMPPS Auth 팀 슬랙 채널의 메시지로 장애를 알았다. 팀은 08:56 에 #hmpps-auth-audit-registers 채널에서 ModSecurity 가 요청을 예상치 못하게 막는다는 메시지를 봤고, 09:14 에 장애를 선언했다.

   조치

   • 09:14 에 ingress-nginx 롤백을 시작해 09:43 에 마쳤다.
   • HMPPS 개발자들이 HMPPS Auth 로 가는 트래픽을 막는 규칙을 자기 ModSecurity 설정에서 예외 처리했다.
   • Cloud Platform 팀이 posthog 쿠키가 걸리는 규칙을 플랫폼의 모든 서비스에서 임시로 예외 처리했다.
   • 두 예외를 둔 상태로 새 ingress-nginx 를 다시 배포해 14:00 에 마쳤다.

   후속 조치

   • posthog 쿠키의 범위를 줄여 모든 *.justice.gov.uk 서비스로 가는 요청에 실리지 않게 했다. 다만 이 변경과 CRS 규칙 배포 사이가 짧아 사용자 브라우저의 쿠키가 만료되거나 바뀔 시간이 모자랐다.
   • posthog 쿠키가 충분히 많은 사용자 브라우저에서 만료되면 플랫폼 전체에 넣은 임시 예외를 없앤다.
   • 서비스 팀들에게 개발과 테스트 워크로드에 비운영 인그레스 컨트롤러를 쓰라고 다시 강조해, 이후 ModSecurity 와 CRS 업데이트에서 생길 문제를 미리 찾게 한다.
   • Cloud Platform 3.0 에서는 운영과 비운영 워크로드를 다른 클러스터로 나눠 비운영 워크로드가 반드시 비운영 인그레스를 거치게 한다.

   교훈

   WAF 규칙 세트 업데이트는 보안을 높이려는 변경이어도 정상 트래픽을 막을 수 있다. 베타 인그레스와 비운영 배포로 시험 기회를 줬어도 서비스 팀들이 개발과 테스트에 비운영 인그레스를 실제로 쓰지 않으면 Expect 헤더 같은 오탐은 운영에서야 드러난다. 시험에서 찾은 문제라도 쿠키처럼 사용자 브라우저에 남는 값이면 대응이 효과를 내기까지 시간이 걸린다. 팀은 롤백으로 먼저 영향을 끊고 예외를 준비한 뒤 다시 배포해 같은 날 업그레이드를 마쳤다.

   사례 보기
4. IL-0200 새로 띄운 쿠버네티스 노드가 호환되지 않는 etcd 버전으로 돌아 여러 운영 클러스터의 합의가 깨졌고, GitHub.com 의 git 작업과 웹 요청이 5XX 오류로 실패했다.

   GitHub2026

   증상

   2026년 3월 12일 01:36 UTC 부터 GitHub.com 의 git 작업, 웹 요청, 관련 서비스에서 오류율이 올라갔다. git push, git clone, 페이지 로드가 간헐적으로 5XX 오류를 내며 실패했다.

   오류율 상승

   촉발

   계획된 인프라 업그레이드 중에 설정 문제가 생겨 새로 프로비저닝한 쿠버네티스 노드가 호환되지 않는 etcd 버전으로 올라왔다.

   원인

   설정 변경

   구성 요소

   etcd

   기여 요인

   모니터링 사각지대

   감지

   상태 페이지의 첫 공지는 01:54 UTC 에 올라왔다. 일부 GitHub 서비스의 성능이 떨어졌다는 보고를 조사하고 있다는 내용이었다. 오류율이 오르기 시작한 01:36 UTC 에서 18분 뒤였다.

   조치

   • 장애가 이어지는 동안 배포를 멈췄다.
   • 호환되지 않는 etcd 버전으로 돌던 새 노드를 찾아 빼냈고, 그 뒤 클러스터 합의가 돌아왔다.
   • 검증용 배포로 모든 시스템이 정상인 것을 확인한 다음 평소 운영을 재개했다.

   후속 조치

   • 노드를 교체할 때 버전 호환성 검사를 자동화해 강제한다.
   • 스플릿 브레인 상태를 더 일찍 잡아내는 모니터링을 만든다.
   • 복구 도구를 고쳐 복구에 걸리는 시간을 줄인다.

   사례 보기
5. IL-0124 서킷 브레이커가 풀리자 낡은 상태를 근거로 쌓여 있던 용량 조정이 한꺼번에 실행돼 여러 추론 엔진이 동시에 빠졌고, OpenAI API 의 오류율과 지연 시간이 올랐다.

   OpenAI2026

   증상

   2026년 3월 4일 오후 4시 26분 PST 무렵부터 약 30분 동안 여러 모델의 API 요청에서 오류율과 지연 시간이 올랐다. 영향은 주로 API 트래픽에 나타났고, Codex 트래픽 일부도 영향을 받았다.

   오류율 상승지연 시간 증가

   촉발

   보호용 서킷 브레이커가 일부 스케줄링 작업을 멈춰 둔 사이에 인프라 작업이 큐에 쌓였고, 서킷 브레이커가 풀리자 이 작업이 한꺼번에 실행됐다.

   원인

   소프트웨어 결함

   구성 요소

   자동 용량 관리 시스템

   기여 요인

   자동화 증폭늦게 드러난 변경파괴적 변경 보호 장치 부재모니터링 사각지대

   조치

   • 엔지니어들이 영향을 받은 모델에 인프라 자원을 손으로 다시 배정했다.
   • 추론 엔진을 다시 올리고 모델에 재배정해 서비스를 되살렸다.

   후속 조치

   • 자동 용량 관리 시스템이 실제 상태와 어긋났을 때 이를 더 잘 감지하고 대응하도록 보호 장치를 보강한다.
   • 서킷 브레이커와 스케줄링 시스템의 상태와 그 영향을 쉽게 알아볼 수 있도록 관측성을 높인다.
   • 오래 멈췄다가 풀린 뒤 큐에 쌓인 작업이 대량으로 한꺼번에 실행되지 않도록 보호 장치를 더한다.
   • 용량 조정이 실제 상태와 어긋나는 문제를 잡아내도록 모니터링과 알림을 개선한다.

   교훈

   실행을 멈춘 동안에도 작업을 큐에 쌓는 자동화는 멈춤이 풀리는 순간 낡은 상태를 근거로 한 변경을 한꺼번에 쏟아낼 수 있다. 서킷 브레이커가 무엇을 멈춰 두었는지, 풀릴 때 무엇이 실행될지 눈으로 확인할 수 있어야 한다. 긴 멈춤 뒤에 쌓인 작업이 대량으로 한 번에 실행되지 않게 막아야 한다.

   사례 보기

원인별9