사례10건

10건 중 1~5번째

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-0133 폭풍으로 데이터센터 냉각이 멈춰 us-central1 리전 전체가 내려갔고, 디스크 핫플러그 버그로 Managed Kubernetes 컨트롤 플레인 약 140개의 복구가 길어졌다.

   Nebius2026

   증상

   2026년 8월 19일 09:40 UTC 무렵부터 InfiniBand 패브릭 성능 저하와 GPU 과열 알림이 쌓이기 시작했고, 10:00 이 조금 지나 첫 고객 제보가 들어왔다. 10:15 에 핵심 부품 온도 알림으로 온콜 엔지니어가 호출됐다.

   컨트롤 플레인 무응답서비스 중단모니터링 중단

   촉발

   폭풍과 관련된 사건이 데이터센터 건물에 영향을 줘 건물 관리 시스템이 꺼지고 냉수 냉각 루프가 멈췄다.

   원인

   의존성 장애

   구성 요소

   데이터센터 전력·냉각클라우드 블록 스토리지etcdInfiniBand 패브릭

   기여 요인

   단일 장애점모니터링 사각지대한계 경보 부재런북 부재장애 중첩

   감지

   시설을 감시하는 건물 관리 시스템이 같은 사건으로 꺼져 시설 수준의 알림이 없었다. 대시보드에는 09:15 무렵부터 온도 상승이 보였지만 이 지표에 알림이 없어 나중에야 확인했다. 09:40 무렵부터 InfiniBand 패브릭 저하와 GPU 과열 알림이 쌓였고, 엔지니어가 실제로 반응한 첫 신호는 10:15 의 핵심 부품 온도 알림이었다. 장애는 10:21 에 선언됐다.

   조치

   • 시설 운영사가 냉각을 수동 우회 모드로 돌리고 랙 뒷문을 열어 열을 뺐다.
   • 차단된 랙에 컨트롤 플레인 랙부터 전원을 다시 넣었다.
   • 리전 인프라 컨트롤 플레인을 손으로 되살렸다.
   • 블록 스토리지 호스트 구성 요소를 재시작해 갑작스러운 전원 차단으로 남은 디스크 연결 상태를 지웠다.
   • 개별 장애에 맞춰 둔 VM 복구 속도 제한을 리전 규모 복구에 맞게 손으로 올렸다.
   • 접근할 수 없는 Managed Kubernetes 클러스터의 컨트롤 플레인 인스턴스를 손으로 시작했다.
   • 영향받은 컨트롤 플레인 인스턴스를 통제된 방식으로 멈췄다 다시 시작하는 완화책을 대규모로 적용했다.
   • 장애로 멈춘 고객 VM 104개를 찾아 시작했다.

   후속 조치

   • 시설 운영사와 함께 회복력 검토를 마친다. 검토 범위는 시설 관리 시스템과 감시 시스템의 이중화, 그 시스템이 고장 나도 냉각 설비가 계속 도는지 여부, 냉각 설비의 전기 보호, 현장 대응 인력이다.
   • 냉각 설비 상태와 실내 온도 추세를 보는 시설 수준의 환경 알림을 만든다. 이 알림은 건물 관리 시스템과 상관없이, 워크로드 증상이 나타나기 전에 온콜 엔지니어를 호출한다.
   • 시설 운영사와 비상 에스컬레이션 경로를 문서로 만든다. 온콜 연락망과 보장된 응답 시간을 담는다.
   • 냉각이 끊겼을 때 워크로드를 끄거나 줄이는 비상 열 부하 감축 절차를 정한다. 기준과 책임자와 방법을 분명히 한다.
   • 서비스 계층마다 책임자를 정하고 의존 순서를 따르는 리전 콜드 스타트 절차를 정식으로 마련한다. 콜드 스타트는 꺼진 리전 전체를 처음부터 다시 올리는 일을 말한다.
   • 리전 단위 복구 훈련을 정기적으로 하고, 핵심 플랫폼 구성 요소와 고객 워크로드인 VM, 스토리지 연결, Managed Kubernetes 클러스터를 처음부터 끝까지 검증한다.
   • Managed Kubernetes 장애를 늘린 디스크 연결 버그를 고치고 모든 운영 리전에 배포했다.
   • Compute 사용자가 인스턴스 복구 정책을 설정하는 방법을 개선하고, 모든 Managed Kubernetes 컨트롤 플레인 노드를 개선된 복구 정책으로 옮긴다.
   • 호스트가 갑자기 고장 난 뒤 남은 스토리지 연결 상태를 자동으로 정리해, 손대지 않아도 디스크를 마운트하고 지울 수 있게 한다.
   • 모니터링 스택의 시작과 복구 경로에서 리전 내부 의존을 없애고, 리전 간 모니터링을 넓혀 리전 자체 모니터링이 약해져도 그 리전을 볼 수 있게 한다.
   • 전역 트래픽 관리에 쓰는 리전 헬스 체크가 실제 서비스 가용성을 반영하게 해, 비정상 리전에서 트래픽을 빼고 너무 일찍 되돌리지 않게 한다.

   교훈

   시설 감시는 감시 대상 시스템과 독립돼 있어야 한다. 폭풍과 관련된 사건 하나가 냉각 설비와 그 고장을 알렸어야 할 건물 관리 시스템을 함께 껐다. 환경 데이터에도 알림이 있어야 한다. 한 시간 뒤에야 울린 알림은 원인이 아니라 결과인 부품 과열을 알린 것이었다. 리전 단위 복구는 연습한 절차여야 한다. 이전 장애 뒤에 개선한 것들은 의도대로 작동했다. 컨트롤 플레인 랙에 먼저 전원을 넣었고, 네트워크 게이트웨이는 전원이 돌아오고 약 두 시간 안에 살아났고, 오브젝트 스토리지는 자동으로 복구됐다. 하지만 의존 계층 사이의 복구 순서는 장애 중에 손으로 정하고 조율해야 했다. 복구 자동화는 개별 장애뿐 아니라 대량 장애에도 맞게 설계해야 한다. 한 번만 시도하는 복구, 보수적인 속도 제한, 장애로 멈춘 인스턴스와 사용자가 멈춘 인스턴스를 구분하지 못하는 점 때문에 대규모 수작업이 필요했다. 모니터링과 트래픽 관리는 리전이 무너져도 함께 무너지지 않아야 한다. 모니터링 구성 요소는 시작 과정도 데이터도 리전 안의 구성 요소에 기대고 있었다. 전역 콘솔 트래픽 관리에 쓰는 리전 헬스 체크는 리전이 정상이 아닌데도 정상이라고 보고해 트래픽을 잠깐 리전으로 되돌렸다.

   사례 보기
3. IL-0150 DynamoDB DNS 자동화의 경쟁 조건이 us-east-1 리전 엔드포인트의 DNS 레코드를 비워 DynamoDB 와 EC2 인스턴스 시작이 실패했고, 그 여파로 EKS, ECS, Fargate 의 컨테이너 시작과 클러스터 스케일링이 14시간 넘게 막혔다

   Amazon Web Services2025

   증상

   2025년 10월 19일 23시 48분 PDT 부터 us-east-1 리전에서 공개 엔드포인트로 DynamoDB 에 연결하려던 모든 시스템이 DNS 조회에 실패했다. 고객 트래픽과 DynamoDB 에 기대는 AWS 내부 서비스가 함께 실패했다.

   DNS 조회 실패오류율 상승노드 증설 실패간헐적 연결 실패지연 시간 증가

   촉발

   DynamoDB DNS 관리 시스템에 잠재해 있던 경쟁 조건 때문에 리전 엔드포인트 dynamodb.us-east-1.amazonaws.com 의 DNS 레코드가 빈 값이 됐고, 자동화가 이를 복구하지 못했다.

   원인

   소프트웨어 결함

   구성 요소

   DNS 서버와 레코드애플리케이션 데이터베이스클라우드 로드 밸런서

   기여 요인

   자동화 증폭재시도 폭주런북 부재

   감지

   영향받은 AWS 서비스의 엔지니어링 팀이 23시 48분 장애가 시작되자 바로 투입돼 조사했고, 00시 38분 DynamoDB 의 DNS 상태를 원인으로 찾았다. NLB 헬스 체크 문제는 06시 52분 모니터링 시스템이 감지했다.

   조치

   • 01시 15분 PDT 까지 임시 조치를 적용해 일부 내부 서비스가 DynamoDB 에 연결되게 하고 복구에 필요한 핵심 내부 도구를 고쳤다.
   • 운영자가 손으로 DynamoDB 리전 엔드포인트의 DNS 정보를 바로잡아 02시 25분 모두 복구했다.
   • 04시 14분 DWFM 으로 들어오는 작업을 스로틀링하고 DWFM 호스트를 골라 재시작해 큐를 비우고 droplet 리스를 다시 맺게 했다.
   • Network Manager 의 부하를 줄이고 복구를 앞당기는 조치를 해 10시 36분 네트워크 구성 전파 시간을 정상으로 되돌렸다.
   • 09시 36분 NLB 의 자동 헬스 체크 장애 조치를 꺼서 정상인 NLB 노드와 백엔드 대상을 모두 서비스로 되돌렸고, EC2 가 회복된 뒤 14시 09분 다시 켰다.
   • 11시 23분부터 EC2 하위 시스템을 보호하려고 걸어 둔 요청 스로틀링을 풀기 시작해 13시 50분 EC2 API 와 새 인스턴스 시작을 정상화했다.

   후속 조치

   • DynamoDB DNS Planner 와 DNS Enactor 자동화를 전 세계에서 껐다.
   • 자동화를 다시 켜기 전에 경쟁 조건을 고치고, 잘못된 DNS 계획이 적용되지 않도록 보호 장치를 더한다.
   • 헬스 체크 실패로 가용 영역 장애 조치가 일어날 때 NLB 하나가 서비스에서 뺄 수 있는 용량을 제한하는 속도 제어 장치를 넣는다.
   • 기존 규모 테스트에 더해 DWFM 복구 흐름을 실행해 보는 테스트 스위트를 만들어 회귀를 찾는다.
   • EC2 데이터 전파 시스템의 스로틀링을 개선해 대기 큐 크기에 따라 들어오는 작업의 속도를 제한한다.

   교훈

   DNS 자동화가 스스로 고칠 수 없는 상태에 빠지면 사람이 손대기 전까지 리전 엔드포인트가 통째로 사라진다. 계획이 더 새로운지 적용 전에 한 번만 확인하면, 처리가 길게 지연됐을 때 그 확인 결과는 낡은 정보가 된다. 기반 서비스가 돌아와도 그 위의 시스템은 밀린 작업 때문에 혼잡 붕괴에 빠질 수 있다. 이번에는 정해진 복구 절차가 없어 엔지니어들이 여러 조치를 조심스럽게 시도한 끝에 04시 14분에야 스로틀링과 호스트 재시작으로 풀었다. EKS 처럼 EC2 인스턴스 시작에 기대는 서비스는 DynamoDB 가 회복된 뒤에도 EC2 와 네트워크 전파가 정상화될 때까지 컨테이너 시작과 스케일링이 막혔다. 헬스 체크에 따른 자동 장애 조치는 상태 정보가 흔들릴 때 정상 용량까지 빼 버릴 수 있다.

   사례 보기
4. IL-0095 엔지니어가 kubectl 이 다른 클러스터를 가리키는 줄 모르고 prod 네임스페이스를 지워 LEAP JupyterHub 가 약 1시간 동안 멈췄다.

   2i2c2025

   증상

   새 temple 클러스터에 허브를 배포하던 엔지니어가 NFS 문제를 만나 prod 네임스페이스를 지웠는데 삭제가 멈춘 채 끝나지 않았다. 파드 목록을 보니 다른 클러스터의 사용자 파드가 잔뜩 있었다.

   리소스 삭제서비스 중단

   촉발

   2i2c 엔지니어가 새 허브의 NFS 배포 버그를 우회하던 중, kubectl 이 LEAP 클러스터를 가리키고 있는 줄 모르고 prod 네임스페이스를 지웠다.

   원인

   운영 실수

   구성 요소

   영구 볼륨과 스테이트풀셋잡과 크론잡인그레스 컨트롤러Terraform

   기여 요인

   파괴적 변경 보호 장치 부재런북 부재

   감지

   네임스페이스를 지운 엔지니어가 삭제가 멈춘 것을 보고 파드 목록을 확인하다 다른 클러스터의 사용자 파드를 발견했고, 17:00 BST 에 장애를 선언했다. 모니터링 알림보다 먼저였다. 업타임 검사 실패 알림은 17:32 에 왔고 사용자의 404 제보는 17:37 에 들어왔다.

   조치

   • prod 네임스페이스에 남아 있던 사용자 파드 하나를 지워 멈춰 있던 네임스페이스 삭제를 끝냈다.
   • 재배포를 막고 있던 nfs-share-creator 잡을 종료했다.
   • 바뀐 NFS 서버 IP 주소로 prod 허브를 다시 배포했다.
   • 배포 도중 사용자가 서버를 띄우지 못하게 prod 인그레스를 지웠다.

   후속 조치

   • 장애 보고서를 쓴다.
   • "I deleted prod, what next?" 같은 상황에서 바로 볼 수 있는 짧은 장애 대응 문서를 쓴다.
   • jupyterhub-home-nfs 를 업그레이드하고 nfs-share-creator 잡을 없앤다.
   • deployer 시스템에 kubeconfig 컨텍스트가 중첩되는 것을 막는 보호 장치를 넣었다. 기본으로는 꺼져 있고 쓰는 사람이 켜야 동작한다.
   • 해당 엔지니어의 셸 설정을 바꿔 kubeconfig 컨텍스트를 더 쉽게 구분하게 했다.

   교훈

   쿠버네티스 리소스를 잃는 경우에 대비해 영구 스토리지를 Terraform 으로 따로 프로비저닝해 둔 설계 덕분에 사용자 데이터가 살아남았다. 반면 엔지니어에게 지금 어느 클러스터를 다루고 있는지 알려 주는 단서가 없었던 것이 실수로 이어졌다. 복구 방법을 알고 있어도 데이터 손실 위험을 확인해 줄 사람이 다른 시간대에 있어 재배포가 늦어졌다. NFS 배포의 순환 의존과 nfs-share-creator 잡도 복구를 늦췄다.

   사례 보기
5. IL-0085 Hetzner Cloud 의 k3s 컨트롤 플레인 노드가 메모리 부족으로 꺼진 뒤 클러스터가 Hetzner API 호출 한도를 다 써 버려 모든 고객 사이트가 약 7.5시간 멈췄다.

   Magic Pages2025

   증상

   2025-04-14 09:33 UTC 쯤 Magic Pages 의 컨트롤 플레인 노드 세 대 중 한 대가 갑자기 오프라인이 됐다. 노드를 살펴보니 메모리가 바닥나 있었다. 운영자는 평소 절차대로 고장 난 노드를 빼고 메모리가 조금 더 큰 서버로 바꾸려 했다.

   서비스 중단노드 NotReady클라우드 API 호출 한도 소진

   촉발

   컨트롤 플레인 노드 한 대가 메모리 부족으로 오프라인이 됐다. 이 노드를 교체하는 배포가 실패해 다시 시도하는 동안, 클러스터 내부 구성 요소들이 Hetzner API 를 계속 호출해 시간당 3600건 한도를 소진했다.

   원인

   용량 한계

   구성 요소

   클라우드 컨트롤러 매니저영구 볼륨과 스테이트풀셋

   기여 요인

   한계 미인지재시도 폭주모니터링 사각지대디버그 접근 제한단일 장애점런북 부재

   감지

   모니터링 경보가 쏟아지면서 고객 웹사이트에 접속할 수 없다는 것을 알았다. API 호출 한도가 원인이라는 것은 30분쯤 조사한 뒤에야 찾았다. hetzner-k3s 가 Hetzner API 오류를 감춰서 원인 파악이 늦어졌다.

   조치

   • API 호출을 확실히 멈추려고 서버 전원을 내려 쿠버네티스 클러스터 전체를 껐다.
   • Hetzner API 의 ratelimit-remaining 값이 다시 오르는 것을 지켜보면서, 복구 중에 다시 한도에 걸리지 않도록 여유분이 쌓일 때까지 기다렸다.
   • API 호출 여유가 생긴 뒤 컨트롤 플레인 서버를 다시 켰다.
   • 워커 노드를 올린 뒤 Longhorn 의 핵심 구성 요소를 손으로 띄워 스토리지 볼륨이 스스로 복구되게 했다.
   • 17:00 UTC 쯤 사이트의 95% 가 돌아온 뒤, 남은 사이트를 손으로 다시 시작했다.

   후속 조치

   • 클러스터 노드에서 나가는 Hetzner API 호출량을 따로 모니터링해서 사용량이 높아지면 미리 알 수 있게 한다.
   • Hetzner 와 협의해 API 호출 한도를 늘린다.
   • API 하나에 기대는 구조를 줄일 방법을 찾고, hetzner-k3s 로는 그렇게 하기 어렵다면 다른 도구를 검토한다.
   • 클러스터 전체가 꺼진 뒤 Longhorn 스토리지를 복구하는 절차를 더 탄탄하게 문서로 만들고 시험한다.

   교훈

   Hetzner 의 기본 API 한도인 시간당 3600건은 장애나 복구 상황에서 클러스터가 쓰는 양에 비해 부족했다. 운영자는 배포에 쓰는 API 사용량만 봤고, 실행 중인 클러스터 내부에서 나가는 호출은 지켜보지 않았다. 네트워킹 같은 핵심 기능이 클라우드 API 하나에 기대고 있으면, 그 API 가 막히는 순간 클러스터 전체가 약해진다. hetzner-k3s 의 추상화는 API 오류를 감춰 문제 해결을 늦췄다. 클러스터가 비정상 종료된 뒤 Longhorn 을 살리는 데 손이 많이 가서 장애가 길어졌다.

   사례 보기

원인별6