사례3건

3건 중 1~3번째

1. 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 연결에 시간이 걸린 것을 반성해 주석만 풀면 전환할 수 있게 했다.

   사례 보기
2. IL-0267 싱가포르 캐시 거점 eqsin 의 전송 회선 두 개가 함께 끊겨 BGP 가 내려가고 eqsin 의 호스트에 닿을 수 없게 됐다

   Wikimedia Foundation2023

   증상

   16시 37분 UTC 에 Icinga 가 cr3-eqsin 의 BGP 상태가 CRITICAL 이라고 알렸고, 몇 분 뒤 eqsin 의 호스트들이 한꺼번에 DOWN 으로 떴다. 호출 알림 세 건이 동시에 울렸고 그중 두 건은 batphone 으로 올라갔다.

   네트워크 도달 불가

   촉발

   eqsin 을 코어 데이터센터에 잇는 전송 회선 두 개 중 하나는 오래 이어진 광케이블 절단으로 끊겨 있었다. 남은 하나가 전송 회선 공급사 Arelion 의 계획 작업 PWIC225900 으로 내려갔다.

   원인

   의존성 장애

   구성 요소

   백본망BGP 라우팅CDN 과 엣지 네트워크

   기여 요인

   단일 장애점초기 신호 무시

   감지

   자동 모니터링이 먼저 잡았다. 16시 37분 UTC 에 Icinga 가 cr3-eqsin 의 BGP 상태 CRITICAL 을 알렸고, 이어서 cr2-eqsin 의 BGP 상태와 eqsin 호스트들의 DOWN 알림이 울렸다. 호출 알림 세 건이 동시에 울렸고 그중 두 건이 batphone 으로 올라갔다.

   조치

   • 16시 48분 UTC 에 eqsin 을 DNS 에서 뺐다.
   • 나중에 eqsin 을 다시 DNS 에 넣었다.

   후속 조치

   • 백업 GRE 터널을 만든다. 작업은 T327265 이다.
   • 오래 끊겨 있던 전송 회선이 수리된 뒤 제대로 다시 올라오는지 확인한다. 작업은 T322529 이다.
   • 공급사의 점검 알림을 자동으로 읽어 들여 점검 일정이 서로 겹치면 알린다. 작업은 T230835 이다.

   교훈

   eqsin 을 DNS 에서 빨리 뺀 것이 잘됐고, 먼저 빼고 나중에 조사한다는 태도가 맞았다. 잘못된 것은 세 가지였다. eqsin 이 너무 오래 전송 회선 하나로만 버텼다. 두 전송 회선이 겹쳐서 내려가는 것을 SRE 들이 잡지 못했다. 공급사의 계획 작업이 작업 티켓이나 알림으로 남지 않았다. 알림은 맞게 울렸지만 IRC 에서 감당하기 어려울 만큼 많았다.

   사례 보기
3. IL-0229 손상된 SmartEdge 데이터 파일을 받은 bunny.net 의 전 세계 DNS 서버가 크래시를 되풀이해 플랫폼 대부분이 2시간 넘게 멈췄다.

   bunny.net2021

   증상

   2021-06-22 UTC 8:25 에 업데이트를 내보내고 몇 분 만에 전 세계에 있는 100대 가까운 bunny.net DNS 서버가 거의 모두 죽었다. bunny.net 은 트래픽의 60% 넘게 잃었고, 수백 Gbit 의 처리량이 사라졌으며, 750,000개가 넘는 웹사이트가 영향을 받았다.

   컨테이너 재시작 반복DNS 조회 실패서비스 중단요청 오라우팅부하 불균형

   촉발

   2021-06-22 UTC 8:25 에 최적화 데이터베이스의 다운로드 크기를 줄이려는 업데이트가 손상된 파일을 Edge Storage 에 올렸다. DNS 서버가 이 파일을 읽자 BinaryPack 직렬화 라이브러리가 stack overflow 예외를 일으켰고, 예외 처리를 건너뛴 채 DNS 프로세스가 종료됐다.

   원인

   배포 결함

   구성 요소

   DNS 서버와 레코드CDN 과 엣지 네트워크오브젝트 스토리지

   기여 요인

   순환 의존단일 장애점자동화 증폭롤백 무효수동 조치 악화

   감지

   팀은 무슨 일인지 알아채는 데 시간이 걸렸다. 업데이트 10분 뒤에야 DNS 서버가 다시 시작했다가 죽기를 되풀이하고 있고, 이 상태로는 되살릴 방법이 없다는 것을 알았다.

   조치

   • UTC 8:45 에 SmartEdge 시스템을 끄는 업데이트를 DNS 노드에 손으로 배포했다. 하지만 손상된 GeoDNS 데이터베이스 때문에 요청이 Madrid 로 몰렸다.
   • 9:40 무렵 임시 조치로 모든 요청을 가장 큰 리전인 Frankfurt 로 보내는 라우팅 업데이트를 준비해 DNS 서버 몇 대에 손으로 배포했다. 트래픽의 상당 부분이 돌아왔다.
   • 자체 시스템을 쓰지 않으려고 배포 시스템과 파일을 모두 외부 클라우드 스토리지 서비스로 옮겼다.
   • 10:15 에 배포 시스템과 DNS 소프트웨어를 새 스토리지에 연결하도록 바꾸고 배포했다. 10:30 에 트래픽이 돌아왔지만 잘못된 GeoDNS 데이터베이스 버전 때문에 요청은 여전히 Madrid 로 갔다.
   • 10:45 에 외부 서비스를 거쳐 데이터베이스를 동기화하고 최신 파일 세트를 배포해 서비스를 되살렸다. 11:00 에 상황이 안정되기 시작했다.

   후속 조치

   • 긴급 수정으로 BinaryPack 라이브러리를 단계적으로 걷어 낸다.
   • 앞으로 쓰는 외부 라이브러리를 더 폭넓게 시험한다.
   • 내부 API 를 외부의 독립 서비스로 완전히 옮긴다. 그 서비스가 내려가면 업데이트를 못 하지만, bunny.net 시스템이 내려가도 무너지는 인프라에 갇히지 않고 빠르게 대응할 수 있다.
   • 중요하지 않다고 본 소프트웨어 하나가 여러 클러스터에 걸친 단일 장애 지점이 되지 않게 하는 방법을 조사한다.
   • DNS 시스템이 모든 백업 데이터의 로컬 사본을 갖추고 장애를 자동으로 감지하게 해, 시스템끼리 최대한 독립시키고 장애가 연쇄로 번지지 않게 한다.

   교훈

   bunny.net 은 내부 인프라의 핵심 부분까지 모든 시스템이 서로 기대도록 설계했다. 그 때문에 손상된 파일 하나가 여러 겹의 이중화를 무너뜨리고 복구할 길까지 막았다. 자체 인프라를 자기 생태계 안에 지으면 한 곳의 장애가 연쇄로 번질 수 있다. 업데이트는 카나리 방식으로 잘게 배포하려 했지만, 중요하지 않다고 본 소프트웨어 하나가 여러 클러스터에 동시에 걸친 단일 장애 지점이 됐다. 급하게 고치는 동안 오타와 실수가 늘었고, 결국 침착하게 모든 것을 다시 확인한 뒤의 마지막 배포로 복구했다.

   사례 보기

원인별3