사례7건

7건 중 1~5번째

1. IL-0349 Berlin 의 VMware 기반 Private Cloud 에서 관리망과 스토리지, 외부 라우팅이 함께 끊겼다

   IONOS Cloud2026

   증상

   Berlin 의 VMware 기반 Private Cloud 에서 관리 VPN 접속과 개별 VM 을 오가는 트래픽이 모두 끊겼다.

   네트워크 도달 불가스토리지 연결 끊김

   촉발

   계획된 정비 시간에 작업자가 관리 장비에 새 VLAN 을 더하는 명령을 잘못 실행했다. 코어 장비와 관리 장비 사이 트렁크의 기존 VLAN 이 덮어써지고 새 VLAN 하나만 남았다.

   원인

   운영 실수

   구성 요소

   네트워크 스위치트랜짓 게이트웨이와 네트워크 연결 장비

   기여 요인

   과도한 영향 범위파괴적 변경 보호 장치 부재

   조치

   • 복구 막바지에 영향을 받은 서비스를 재시작했다. 이 재시작으로 짧은 2차 장애가 났다.

   후속 조치

   • 관리 장비가 더 잘 분리되도록 구조 전체를 감사한다. 목표 시점은 2026년 3분기다.
   • 구성 안전장치나 자동화 스크립트 같은 방법으로 의도하지 않은 VLAN 변경을 막는 방안을 검토하고 적용한다. 목표 시점은 2026년 1분기다.

   사례 보기
2. IL-0341 Cloudflare 와 AWS us-east-1 사이 링크가 혼잡해져 그 리전에 오리진을 둔 고객이 높은 지연과 패킷 손실을 겪었다

   Cloudflare2025

   증상

   2025년 8월 21일 16:27 UTC 부터 AWS us-east-1 에 오리진을 둔 고객과, us-east-1 의 서버를 거쳐 Cloudflare 와 트래픽을 주고받는 사용자에게 높은 지연, 패킷 손실, 오리진 연결 실패가 났다. 16:44 에 Cloudflare 네트워크 팀이 애시번 IAD 의 내부 혼잡 알림을 받았다.

   패킷 손실지연 시간 증가간헐적 타임아웃

   촉발

   16:27 UTC 쯤 한 고객이 AWS us-east-1 에서 Cloudflare 캐시에 있는 객체를 대량으로 요청하기 시작했다. 그 응답 트래픽이 Cloudflare 에서 AWS 로 가는 전체 트래픽을 두 배로 늘렸다.

   원인

   용량 한계

   구성 요소

   트랜짓 게이트웨이와 네트워크 연결 장비BGP 라우팅CDN 과 엣지 네트워크

   기여 요인

   여유 용량 부재수동 조치 악화과도한 영향 범위

   감지

   장애가 시작되고 17분 뒤인 16:44 UTC 에 Cloudflare 네트워크 팀이 애시번 IAD 의 내부 혼잡 알림을 받았다. 17:45 에는 애시번 IAD 의 고객 영향을 이유로 장애가 선언됐다.

   조치

   • 19:05 UTC 에 트래픽 급증을 일으킨 고객 하나에 속도 제한을 걸어 혼잡을 줄였다.
   • 네트워크 팀이 트래픽 엔지니어링 조치를 더 해 19:27 에 혼잡을 완전히 풀었다.
   • 19:45 부터 Cloudflare 의 요청에 따라 AWS 가 BGP 광고 철회를 되돌렸고, 20:07 에 IAD PNI 로 Cloudflare 에 보내는 BGP 프리픽스 광고를 정상으로 돌려놓았다.

   후속 조치

   • 한 고객의 트래픽이 다른 고객에게 영향을 줄 만큼 네트워크를 혼잡하게 만들기 시작하면 그 트래픽의 우선순위를 골라서 낮추는 장치를 만든다.
   • Data Center Interconnect 증설을 앞당겨 네트워크 용량을 지금보다 크게 늘린다.
   • AWS 와 함께 양쪽의 BGP 트래픽 엔지니어링 조치가 앞으로 서로 부딪치지 않게 한다.
   • 고객마다 네트워크 자원을 나눠 예산을 정하고, 예산을 넘긴 고객의 트래픽이 다른 고객의 서비스를 떨어뜨리지 못하게 하는 새 트래픽 관리 시스템을 만든다. 이 시스템은 이번에 손으로 한 혼잡 대응 조치 상당수도 자동화한다.

   교훈

   Cloudflare 는 이 사고로 한 고객의 사용 방식이 나머지 생태계를 해치지 못하게 막는 안전장치가 더 필요하다는 것이 드러났다고 했다. 어느 한 고객이 공유 자원을 독차지해 다른 고객의 안정성을 해치지 못하도록 고객 격리를 더 잘 설계해야 하고, 수요를 감당할 만큼 네트워크 인프라 용량을 늘려야 한다는 것을 핵심 교훈으로 꼽았다. 결론에서는 드물게 트래픽이 몰린 상황에서 네트워크 혼잡 관리가 모자라 장애가 났다고 했다.

   사례 보기
3. IL-0361 VPC 피어링을 Transit Gateway 로 옮기던 중 seek.com.au 의 구직 검색이 16분 동안 오류를 냈다

   SEEK2021

   증상

   2021년 5월 seek.com.au 에서 구직 검색을 하던 일부 사용자가 오류를 받았고, 장애는 16분 이어졌다. SEEK 는 검색 트래픽을 처리하던 피어링 연결을 Transit Gateway 로 옮기던 중이었고, 검색이 동작하지 않는다는 것을 꽤 빨리 알아챘다.

   오류율 상승패킷 손실간헐적 타임아웃

   촉발

   SEEK 는 VPC 피어링 연결에서 Transit Gateway 로 옮기는 절차의 둘째 단계로 첫 VPC 의 라우팅 테이블만 Transit Gateway 를 쓰게 바꿨다. 이 상태에서는 VPC A 에서 나가는 패킷은 피어링 연결로, VPC B 에서 나가는 패킷은 Transit Gateway 로 가서 오가는 경로가 달라졌다.

   원인

   설정 변경

   구성 요소

   트랜짓 게이트웨이와 네트워크 연결 장비

   기여 요인

   한계 미인지기본 설정 방치모니터링 사각지대

   감지

   마이그레이션 도중 SEEK 는 검색이 동작하지 않는다는 것을 꽤 빨리 알아챘다.

   조치

   • 검색이 동작하지 않는 것을 보고 피어링 연결에서 Transit Gateway 로 옮기던 마이그레이션을 롤백했다.

   후속 조치

   • SEEK 환경의 EC2 인스턴스 MTU 를 8500 으로 낮춰 8500 바이트보다 큰 패킷을 보내지 않게 한다. Amazon Linux 2 에서는 네트워크 인터페이스가 올라올 때마다 인터페이스 이름을 인자로 받아 실행되는 /sbin/ifup-local 스크립트를 두어 인스턴스의 기본 MTU 를 8500 으로 덮어쓴다.

   교훈

   SEEK 는 피어링 연결과 Transit Gateway 의 MTU 가 다르다는 중요한 정보를 마이그레이션 전에 알지 못했다. Transit Gateway 가 큰 패킷을 알리지 않고 버린다는 사실은 AWS 의 Transit Gateway 할당량 문서에 적혀 있었지만, SEEK 는 이것이 할당량이라기보다 더 찾기 쉬운 곳에 있어야 할 기본 정보라고 봤다. SEEK 는 이 장애로 MTU, MSS, AWS 관리형 네트워크 장비의 세부 동작을 많이 배웠다. 장애에서 얼마나 배우는지는 장애의 심각도보다 근본 원인을 이해하려는 호기심과 의지에 달려 있다고 보았다.

   사례 보기
4. IL-0223 us-east-1 에서 AWS 내부 네트워크와 주 네트워크를 잇는 장비가 연결 폭주로 혼잡해져 EC2 API 와 여러 AWS 서비스의 제어 평면이 몇 시간 동안 오류를 냈다.

   Amazon Web Services2021

   증상

   2021-12-07 PST 오전 7시 33분부터 us-east-1 에서 새 인스턴스를 띄우거나 기존 인스턴스를 조회하는 EC2 API 의 오류율과 지연이 늘었다. AWS 운영팀은 혼잡이 시작되자 곧바로 실시간 모니터링 데이터를 볼 수 없었다.

   컨트롤 플레인 지연지연 시간 증가오류율 상승모니터링 중단DNS 조회 실패

   촉발

   PST 오전 7시 30분에 주 AWS 네트워크에서 도는 한 AWS 서비스의 용량을 늘리는 자동 작업이, 내부 네트워크 안의 많은 클라이언트에서 예상하지 못한 동작을 일으켰다. 연결 시도가 한꺼번에 몰려 내부 네트워크와 주 네트워크 사이의 네트워크 장비가 감당하지 못했다.

   원인

   소프트웨어 결함

   구성 요소

   트랜짓 게이트웨이와 네트워크 연결 장비자동 용량 관리 시스템

   기여 요인

   재시도 폭주순환 의존

   감지

   혼잡이 시작되자 운영팀의 실시간 모니터링 데이터가 곧바로 끊겼다. 운영자는 로그를 보고 상황을 파악했고, 처음에는 내부 DNS 오류가 늘어난 것을 찾았다.

   조치

   • 내부 DNS 트래픽을 혼잡한 네트워크 경로에서 옮겼다. PST 오전 9시 28분에 이 작업을 마치자 DNS 해석 오류가 완전히 회복됐지만 혼잡은 남았다.
   • 내부 네트워크의 트래픽을 가장 많이 내는 출처를 찾아 전용 네트워크 장비로 분리했다.
   • 네트워크 트래픽이 많은 서비스 일부를 껐다. PST 오후 12시 35분에는 EventBridge 이벤트 전달도 껐다.
   • 네트워크 용량을 늘렸다. 혼잡은 오후 1시 34분에 크게 나아졌고 오후 2시 22분에 모든 네트워크 장비가 회복됐다.
   • 이번 일을 촉발한 확장 작업을 즉시 껐다.

   후속 조치

   • 모든 개선 조치를 배포할 때까지 이번 일을 촉발한 확장 작업을 다시 켜지 않는다.
   • 네트워크 클라이언트가 혼잡에서 제대로 back-off 하지 못하게 한 잠재 문제를 고치는 수정을 만들어 2주 안에 배포한다.
   • 비슷한 혼잡이 다시 생겨도 영향받을 수 있는 네트워크 장비를 보호하도록 네트워크 설정을 추가한다. 이 설정은 이미 배포했다.
   • 내부 네트워크를 쓸 수 없을 때도 API Gateway 서버가 정상으로 남게 하는 완화책을 만들고, 비슷한 일이 생겼을 때 더 빨리 복구하도록 서버 교체 과정을 개선한다.
   • 서비스 영향을 더 쉽게 알아볼 수 있는 새 Service Health Dashboard 를 내년 초에 내놓는다.
   • 고객과의 소통이 늦어지지 않도록 여러 AWS 리전에서 동시에 도는 새 구조의 지원 시스템을 내놓는다.

   사례 보기
5. IL-0336 도쿄 리전으로 가는 Direct Connect 트래픽에 패킷 손실과 간헐적인 연결 끊김이 6시간 넘게 이어졌다

   Amazon Web Services2021

   증상

   일본 시간 2021년 9월 2일 오전 7시 30분부터 Direct Connect 로 도쿄 리전에 접속하는 고객의 트래픽에 간헐적인 연결 문제와 패킷 손실 증가가 나타났다. 같은 시각 AWS 엔지니어는 패킷 손실 증가를 알리는 내부 알람을 받았다.

   패킷 손실간헐적 연결 실패

   촉발

   네트워크 장비 운영체제에 결함이 있었고, 이 결함은 아주 특정한 패킷 속성과 내용이 맞아야만 드러났다. 고객 트래픽이 그 조건에 맞는 패킷을 꾸준히 만들어 내 결함을 건드렸다. AWS 는 악의를 의심할 이유가 없다고 밝혔다.

   원인

   소프트웨어 결함

   구성 요소

   트랜짓 게이트웨이와 네트워크 연결 장비

   기여 요인

   늦게 드러난 변경스테이징 불일치

   감지

   오전 7시 30분, 도쿄 리전에 접속하는 Direct Connect 고객의 패킷 손실 증가를 알리는 내부 알람이 AWS 엔지니어에게 울렸다. 고장 난 장비를 감시하는 자동화도 고장 장비의 비율이 평소보다 높다는 것을 알아채고 엔지니어에게 조사와 조치를 요청했다.

   조치

   • 이 계층에 이중화가 충분하다고 보고 영향받은 장비를 서비스에서 빼, 정상 장비가 트래픽을 처리하게 했다. 잠시 나아졌지만 다른 장비들이 같은 고장을 일으켰다.
   • 고장 난 장비를 리셋하고 천천히 서비스에 되돌려 봤지만 고장은 이어졌다.
   • 한 가용 영역에서 먼저 새 프로토콜을 끄고 회복이 유지되는지 지켜보면서 도쿄 리전 전체에 적용할 변경을 준비했다. 그 뒤 도쿄 리전에서 새 프로토콜을 껐다.

   후속 조치

   • 고객 영향이 나기 전에 이 결함을 찾아 고치는 개선된 방법을 갖추고, 나머지 모든 AWS 리전에 이 변경을 조심스럽게 적용한다.

   사례 보기

원인별5