사례33건

33건 중 1~5번째

1. 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 컨트롤 플레인 노드를 개선된 복구 정책으로 옮긴다.
   • 호스트가 갑자기 고장 난 뒤 남은 스토리지 연결 상태를 자동으로 정리해, 손대지 않아도 디스크를 마운트하고 지울 수 있게 한다.
   • 모니터링 스택의 시작과 복구 경로에서 리전 내부 의존을 없애고, 리전 간 모니터링을 넓혀 리전 자체 모니터링이 약해져도 그 리전을 볼 수 있게 한다.
   • 전역 트래픽 관리에 쓰는 리전 헬스 체크가 실제 서비스 가용성을 반영하게 해, 비정상 리전에서 트래픽을 빼고 너무 일찍 되돌리지 않게 한다.

   교훈

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

   사례 보기
2. IL-0438 CloudFront VPC Origins 장애로 Builder Work 가 504 오류를 내며 거의 모든 접속이 막혔다

   ANDPAD2026

   증상

   2026년 7월 16일 17시쯤 Datadog 이 알림을 울렸고, 거의 같은 때 CloudFront 에서 VPC Origins 연결을 쓰는 배포에 5xx 오류가 늘기 시작했다. CloudFront 자체는 정상으로 돌았지만 VPC Origins 기능에만 장애가 나서 504 Gateway Time-out 이 잇따랐다.

   서비스 중단오류율 상승

   촉발

   CloudFront 의 VPC Origins 연결을 관리하는 AWS 내부 공유 서브시스템에서 용량 제약이 생겼다.

   원인

   클라우드 제공자 장애

   구성 요소

   CDN 과 엣지 네트워크클라우드 로드 밸런서인그레스 컨트롤러웹 애플리케이션 방화벽 규칙

   기여 요인

   단일 장애점

   감지

   17시쯤 Datadog 이 알림을 울렸고, 거의 같은 때 VPC Origins 연결을 쓰는 CloudFront 배포에서 5xx 오류가 늘고 있는 것을 알았다.

   조치

   • CloudFront 의 오리진이 VPC Origins 하나뿐이었으므로, CloudFront 를 거치지 않고 Internet-facing ALB 로만 라우팅하도록 임시로 바꾸기로 했다.
   • VPC Origins 도입 때 지운 Internet-facing Ingress 를 다시 만들고, Argo Rollouts 의 Rollout 리소스에 묶은 뒤 promote 했다.
   • 기존 WAF 는 us-east-1 글로벌 범위의 CloudFront 용이라 ALB 에 연결할 수 없어, 보안 팀과 함께 ALB 용 리전 WAF 를 따로 만들었다.
   • ACM 인증서, WAF, 액세스 로그 설정을 묶은 IngressClass 를 새로 만들었다.
   • 일반 트래픽용, Cognito 인증과 VPN 접근 제한을 건 관리 화면용, 리다이렉트용 Ingress 를 더해 라우팅을 되살렸다.

   후속 조치

   • VPC Origins 와 CloudFront 구성으로 돌아가면서, 다음 장애에 대비해 Internet-facing 으로 바꾸는 수단을 코드에 넣어 둔다.
   • 복구 때 만든 Internet-facing ALB 를 남기고, AWS Load Balancer Controller 의 IngressClassParams spec.inboundCIDRs 로 Security Group 인바운드를 사내 CIDR 과 제한 공개용 CIDR 에만 허용한다. values.yaml 의 securityGroupInboundCidrs 를 주석 처리하면 inboundCIDRs 가 빠져 0.0.0.0/0 으로 열리게 했다.
   • Terraform 으로 관리하는 Route53 A 레코드를 CloudFront 로 되돌렸다. ALB 로 가는 별칭 설정 route53_alias_name 은 주석 처리한 채 코드에 남겨, 주석을 풀고 apply 하면 Route53 을 ALB 로 돌릴 수 있게 했다.

   교훈

   VPC Origins 는 ALB 를 Private 서브넷에 두어 인터넷에서 오는 직접 접근을 막고 통신 경로를 단순하게 해 운영 부담을 줄인다. 그 대신 CloudFront 와 오리진 사이의 통신이 AWS 가 관리하는 공유 서브시스템을 거치므로, 그 서브시스템이 망가지면 CloudFront 전체가 정상이어도 통신이 끊긴다. ANDPAD 는 VPC Origins 의 이점을 버리지 않고 장애 때 쓸 우회 경로를 미리 마련해, 다음에 같은 위험이 드러날 때의 대응 비용을 낮추기로 했다. 상시 켜 둔 ALB 의 유지 비용은 치르지만, 이번에 Ingress 재생성과 Rollout 연결에 시간이 걸린 것을 반성해 주석만 풀면 전환할 수 있게 했다.

   사례 보기
3. IL-0465 IONOS Container Registry 에서 이미지 푸시와 풀이 504 Gateway Timeout 으로 실패했다

   IONOS Cloud2026

   증상

   2026-03-04 에 IONOS Container Registry 고객이 컨테이너 이미지를 푸시하거나 풀할 때 504 Gateway Timeout 오류를 받았다. 레지스트리에 기대는 배포가 막혔다. 상태 페이지에는 09:23 UTC 에 레지스트리의 오류 수가 늘었고 고객이 이미지를 풀하지 못할 수 있다고 처음 올라왔다.

   이미지 풀 실패오류율 상승

   촉발

   마이그레이션 중 일시적인 용량 제약 때문에 중요한 컨트롤 플레인 구성 요소 둘이 같은 프록시 인스턴스에 놓였다. 직접적인 계기는 그 프록시가 동시 연결 한도에 닿아 새 연결을 받지 않은 것이었다.

   원인

   용량 한계

   구성 요소

   컨테이너 레지스트리와 자격 증명관리형 쿠버네티스 컨트롤 플레인과 제공자 API파드 스케줄링과 배치

   기여 요인

   여유 용량 부재단일 장애점한계 경보 부재

   조치

   • 12:22 UTC 에 쿠버네티스 팀이 쿠버네티스 컨트롤 플레인 구성 요소 하나의 버전을 롤백하는 완화책을 배포했다.
   • 프록시 용량을 더 마련했다.
   • 영향받은 컨트롤 플레인 구성 요소를 서로 다른 프록시 인스턴스로 옮겨 부하를 고르게 되돌렸고, 504 오류가 끝났다.

   후속 조치

   • 노드마다 전용 로컬 프록시를 쓰도록 레지스트리와 쿠버네티스 API 사이의 연결을 다시 설계해 공유 프록시 병목을 없앤다. 운영 적용은 2026년 2분기로 잡았다.
   • 프록시 연결 사용률이 한도에 다가가기 전에 경고가 울리도록 알림 기준을 조정한다. 2026년 2분기에 끝낼 예정이다.
   • 인프라 클러스터를 더 배포하고 기존 레지스트리를 다시 나눠, 어느 클러스터도 안전한 운영 용량을 넘지 않게 한다. 사용량이 늘면 자동화가 부하를 계속 고르게 맞춘다.

   사례 보기
4. IL-0063 Redis 스테이트풀셋을 다시 만들자 Redis 클러스터가 한꺼번에 재시작되며 일부가 망가졌고, 재연결 폭주로 백엔드가 OOM 으로 죽어 AdGuard VPN 이 약 50분 멈췄다.

   AdGuard VPN2025

   증상

   8:10 UTC 에 팀은 Redis 스테이트풀셋을 고아 삭제했다. 고아 삭제는 파드와 디스크는 그대로 두고 스테이트풀셋 객체만 지우는 방식이다. 스테이트풀셋을 다시 만들자 쿠버네티스가 8:10 부터 8:15 UTC 사이에 스테이트풀셋 전체를 빠르게 재시작했다. 처음에는 백엔드 서비스가 Redis 연결 오류를 냈지만 서비스 전체가 곧바로 무너지지는 않았다.

   서비스 중단OOMKilled프로브 실패지연 시간 증가

   촉발

   팀은 디스크를 온라인으로 늘린 뒤 Git 의 선언적 설정을 실제 상태와 맞추려고 Redis 스테이트풀셋을 고아 삭제했다. 고아 삭제는 파드와 디스크는 남기고 스테이트풀셋 객체만 지우는 방식이다. 그다음 늘린 크기를 적은 저장소 템플릿으로 스테이트풀셋을 다시 만들었다.

   원인

   설정 변경

   구성 요소

   영구 볼륨과 스테이트풀셋인메모리 캐시컨테이너 메모리 한도

   기여 요인

   헬스 프로브 부재미검증 가정단일 장애점재시도 폭주여유 용량 부재

   감지

   Redis 클러스터 여러 인스턴스의 디스크 여유 공간이 바닥나고 있다는 알림이 시작이었다. 그 뒤의 장애는 스테이트풀셋을 다시 만든 직후 백엔드 서비스가 Redis 연결 오류를 내면서 드러났다.

   조치

   • 망가진 Redis 클러스터를 손으로 복구했다. 마스터에서 쓸모없어진 노드 ID 를 지우고, 해당 레플리카를 리셋한 뒤 클러스터에 다시 붙이고 복제가 따라잡기를 기다렸다.
   • 실제로 메모리가 바닥난 구성 요소를 찾아낸 뒤, 백엔드 서비스를 확장하고 그 구성 요소의 메모리 한도를 올렸다.
   • 프로브를 잠시 느슨하게 해, 백엔드 인스턴스가 ready 와 not ready 를 오가지 않고 바로 트래픽을 받게 했다.
   • 10:00 UTC 에 임시 조치를 되돌렸다.

   후속 조치

   • 빠져 있던 스타트업 프로브를 넣는다. 데이터셋을 다 읽기 전에는 파드를 ready 로 표시하지 않는다.
   • 재시작한 파드가 옛 마스터 IP 주소에 묶여 있을 때 쓸 수 있도록 Redis 용 자체 컨트롤 플레인을 만든다.
   • 서비스 전체의 단일 장애점이 된 이 Redis 클러스터 의존을 줄인다. 중요한 정보 일부를 서버마다 따로 둔 Redis 클러스터 같은 다른 데이터 저장소로 옮기고, 백엔드 일부 구성 요소에 Kafka 를 쓰기 시작한다.

   교훈

   장애를 일으킨 것은 디스크 확장이 아니라 상태를 맞추려고 컨트롤러 객체를 다시 만든 단계였다. 고칠 수 없는 필드가 있으면 객체를 통째로 바꾸는 위험한 방법을 쓰게 된다. 그렇게 바꾸면 쿠버네티스가 워크로드를 넓은 범위에서 다시 조정할 수 있다. 스타트업 프로브와 엄격한 레디니스 프로브가 있어야 롤링 재시작이 현재 파드가 정말 준비될 때까지 기다린다. 이번 장애에서 가장 뼈아픈 것은 프로브가 없었다는 점이다. 분산 클러스터가 다시 붙고 복제를 따라잡는 데는 시간이 걸리므로, 의존하는 서비스는 그동안 기능을 줄여서라도 버티도록 설계해야 한다.

   사례 보기
5. IL-0100 노드가 파드의 CPU 요청에 비해 작아 CPU 가 포화되면서 PostHog 기능 플래그 서비스에 열흘 사이 장애가 세 번 났다.

   PostHog2025

   증상

   2025-10-21 21:45 UTC, 타임아웃 오류를 줄이려는 배포 직후 자동 모니터링이 기능 플래그 서비스의 오류율 상승을 잡았다. 2분 만에 롤백했지만 오류율은 내려가지 않았고, US 데이터센터에서 평가 요청의 약 38% 가 오류를 냈다.

   노드 CPU 고부하오류율 상승지연 시간 증가컨테이너 재시작 반복데이터베이스 과부하

   촉발

   10월 21일에는 증상만 고치려던 타임아웃 처리 배포가 장애를 일으켰다. 28일에는 플래그 서비스와 무관한 일상 배포가 파드 롤아웃을 일으켰고, 이 롤아웃이 장애로 이어졌다. 24일에는 로드밸런서 뒤에서 모든 트래픽을 IP 하나에서 온 것으로 본 레이트 리밋 배포가 장애를 일으켰다.

   원인

   용량 한계

   구성 요소

   노드 풀파드 스케줄링과 배치인메모리 캐시데이터베이스

   기여 요인

   한계 경보 부재재시도 폭주롤백 무효단일 장애점단계적 배포 부재스테이징 불일치

   감지

   21일에는 배포 2분 뒤 자동 모니터링이 오류율 상승을 잡았고, 28일에는 온콜이 높은 오류 수 경보를 받았다. PostHog 는 대부분의 경우 2분 안에 감지했다고 정리했다. 24일에는 429 오류 경보가 없어서 18:10 UTC 부터 들어온 고객 신고로 알았고, 감지까지 62분이 걸렸다. CPU 경보가 아예 없어서 공통 원인인 CPU 포화는 오래 드러나지 않았고, 29일에서 30일 사이 장애는 7시간 넘게 이어졌다.

   조치

   • 10월 21일 타임아웃 처리를 바꾼 배포를 2분 안에 롤백했지만 오류는 멈추지 않았다.
   • 10월 21일 23:00 UTC 부터 연결과 Redis 쓰기를 조절해 23:28 UTC 에 서비스를 복구했다.
   • 10월 28일 롤아웃을 멈추고 US 플래그 파드를 0개로 줄여 Redis 가 회복되기를 기다린 뒤, 파드를 차례로 다시 올렸다.
   • 10월 30일 00:03 UTC 에 하드웨어 변경을 롤백해 오류는 대부분 가라앉혔지만 지연은 남았다.
   • 파드 리소스 요청을 늘리고 쿠버네티스 플릿 크기를 조정해 노드당 파드 수를 줄였다.
   • 로드밸런서와 서비스 사이 Envoy 재시도에 한도를 걸었다.
   • 데이터베이스 연결 타임아웃과 다른 중요한 설정을 런타임 설정으로 옮기고, 타임아웃 값을 피크 부하에 맞게 늘렸다.
   • 노드마다, 파드마다 CPU 사용률이 80% 를 5분 동안 넘으면 온콜을 호출하는 CPU 경보를 추가했다.

   후속 조치

   • 플래그, 수집, 인프라 팀 엔지니어로 전담 팀을 꾸려 애플리케이션과 인프라 전체를 살피고 남은 병목을 찾는다.
   • 플래그 서비스의 Redis 를 본 애플리케이션의 Redis 와 분리하는 방안을 검토한다.
   • ArgoCD 동기화를 다시 켜기 전에 플래그 서비스 차트 설정을 ArgoCD 의 현재 값에 맞추고, 배포 전략과 Redis 전략을 정한다.
   • 플래그 관련 코드의 필수 코드 오너를 기능 플래그 팀으로 정한다.
   • 중요한 플래그 지표와 런북 링크를 한데 모은 대시보드를 만들고, 기능 플래그 런북을 고친다.
   • 기존 서비스 지표와 인프라 지표에 빠져 있는 경보를 추가한다.
   • readiness 검사가 liveness 검사를 그대로 따라 하지 않고, 데이터베이스에 ping 을 보내는 식으로 부하가 걸렸을 때 약해졌던 의존성을 확인하게 바꾼다.
   • 캐시 채우기 작업에 레이트 리밋을 걸어 Redis 에 감당하지 못할 만큼 작업이 몰리지 않게 한다.
   • 연결 풀을 모니터링해 풀이 바닥에 가까워지면 자동으로 요청을 조절하고, 동시 연결 수에 상한을 둔다.
   • 운영 규모의 부하 시험 체계를 만든다.
   • 점진적 롤아웃 기반을 만들어 배포가 미치는 범위를 줄인다.
   • Postgres 에서 Redis 로 가는 데이터 흐름을 문서로 정리하고, 데이터 전송이 한꺼번에 몰릴 때 쓸 런북을 만든다.

   교훈

   가장 큰 교훈은 CPU 크기 산정이었다. 노드가 파드 요청에 비해 작으면 노드 하나에 파드가 너무 많이 몰리고, CPU 포화가 과도한 병렬 처리, 연결 풀 고갈, 느린 쿼리처럼 서로 다른 모습으로 나타난다. 증상만 고친 수정 때문에 21일의 장애가 28일에 되풀이됐다. PostHog 는 CPU 를 넉넉히 받은 파드를 적은 수로 돌리는 편이 낫다고 정리했다. 기능 플래그 서비스와 본 애플리케이션이 Redis 를 같이 쓰면 한쪽 과부하가 다른 쪽을 쓰러뜨리는 단일 장애 지점이 된다. CPU 지표는 처음부터 경보로 걸어야 하고, Postgres 에서 Redis 로 가는 전송 급증도 경보 대상이다. 재시도, 캐시 채우기, 연결 생성에 한도가 없으면 장애가 커진다. 과부하 패턴은 운영 트래픽에서만 드러났으므로 부하 시험이 필요하고, 중요한 설정은 배포 없이 바꿀 수 있어야 한다.

   사례 보기

원인별11