사례2건

2건 중 1~2번째

1. 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 의 비즈니스 연속성 지침을 검토하라고 권했다.

   사례 보기
2. IL-0188 EKS 롤링 업데이트 때 Kubernetes 는 새 파드가 Ready 가 되자마자 옛 파드를 지웠지만 ALB 는 새 파드를 아직 healthy 로 보지 않아, 배포마다 약 30초 동안 502 가 났다.

   Yonghyun Kim2025

   증상

   새벽 3시에 "배포는 성공했는데, 서비스는 죽었다"는 Slack 메시지가 왔다. 모든 파드는 Ready 였고 Datadog 도 초록불이었지만, 사용자는 계속 오류 화면을 보고 있었다.

   오류율 상승서비스 중단

   촉발

   롤링 업데이트에서 새 파드가 readinessProbe 를 통과해 Ready 가 되자 Kubernetes 가 곧바로 옛 파드를 지웠다. 그때 ALB 는 새 파드 IP 를 대상 그룹에 막 등록해 initial 상태로 헬스 체크를 하고 있었다.

   원인

   배포 결함

   구성 요소

   클라우드 로드 밸런서인그레스 컨트롤러파드 종료 처리

   기여 요인

   미검증 가정기본 설정 방치모니터링 사각지대

   감지

   새벽 3시에 "배포는 성공했는데, 서비스는 죽었다"는 Slack 메시지로 알았다. 파드 상태와 Datadog 대시보드는 모두 정상이었고, 장애는 사용자가 보는 화면에만 나타났다.

   조치

   • 네임스페이스에 elbv2.k8s.aws/pod-readiness-gate-inject=enabled 레이블을 붙였다. AWS Load Balancer Controller 의 웹훅이 파드에 ReadinessGate 를 넣었다. 새 파드는 ALB 대상이 healthy 가 된 뒤에야 Ready 가 됐고, 그제야 옛 파드가 지워졌다.

   교훈

   Kubernetes 의 Ready 와 ALB 의 healthy 는 서로 다른 시점에 정해지므로, 둘을 잇는 장치가 없으면 롤링 업데이트 때 502 가 날 수 있다. 파드 상태와 대시보드가 모두 정상이어도 사용자는 오류를 볼 수 있다. terminationGracePeriodSeconds 를 늘려 시간을 버는 방식은 배포만 느리게 하고 새 파드가 뜰 때의 공백은 막지 못한다. ReadinessGate 는 ALB 대상 유형이 ip 일 때만 의미가 있고, instance 모드에서는 노드가 대상이라 쓸 수 없다. ReadinessGate 를 쓰면 파드가 Ready 가 되기까지 30초에서 40초가 더 걸리므로 급한 스케일 아웃에 대비해 레플리카나 HPA 를 넉넉히 잡는다. 웹훅의 failurePolicy 를 Ignore 로 두면 컨트롤러가 죽어도 배포가 막히지 않는다.

   사례 보기

원인별1