Incident Library
  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례12건

12건 중 1~5번째

  1. 증상

    2026년 1월 22일 20:25 UTC 부터 Cloudflare 의 Miami edge 라우터 하나가 BGP 트랜짓 제공자와 피어에게 예상하지 않은 경로를 광고했다. 20:40 UTC 에 네트워크 팀이 Miami 에서 나간 의도하지 않은 경로 광고를 조사하기 시작했다.

    촉발

    20:25 UTC 에 정책 자동화 플랫폼으로 Bogotá 데이터센터용 BGP 광고를 Miami 에서 빼는 변경을 내보냈다. 이 변경이 Miami 라우터의 여러 BGP export 정책에서 prefix-list 6-BOG04-SITE-LOCAL 줄만 지워, 남은 정책이 route-type internal 인 경로를 모두 받아들여 밖으로 광고하게 됐다.

    원인
    구성 요소
    기여 요인
    감지

    20:40 UTC 에 네트워크 팀이 Miami 에서 나간 의도하지 않은 경로 광고를 조사하기 시작했고, 20:44 UTC 에 대응을 조율하려고 인시던트를 열었다.

    조치
    • 20:50 UTC 에 네트워크 운영자가 잘못된 설정 변경을 손으로 되돌렸다. 이때 영향이 끝났다.
    • 자동화가 같은 라우터에서 다시 돌지 않도록 그 라우터의 자동화를 멈췄다.
    • 21:47 UTC 에 유출을 촉발한 변경을 네트워크 자동화 코드 저장소에서 되돌렸다.
    • 22:07 UTC 에 운영자가 라우팅 정책 버그 없이 자동화가 다시 돌 수 있음을 확인했고, 22:40 UTC 에 Miami 라우터의 자동화를 다시 켰다.
    후속 조치
    • 경로 유출을 일으킨 라우팅 정책 자동화의 결함을 고치고, 이 결함과 비슷한 결함을 바로 막는다.
    • 외부 export 정책에서 제공자와 피어에게서 받은 경로를 명시적으로 거부하는 BGP community 기반 안전장치를 라우팅 정책에 더한다.
    • 비어 있거나 잘못된 정책 term 을 찾는 라우팅 정책 자동 평가를 CI/CD 파이프라인에 넣는다.
    • 네트워크 설정 문제와 자동 변경의 나쁜 영향을 더 일찍 알아채도록 개선한다.
    • RFC9234 의 BGP role 과 Only-to-Customer Attribute 를 배포하기에 앞서 라우팅 장비 공급사의 구현을 검증한다. BGP role 과 Only-to-Customer Attribute 는 라우팅 정책과 상관없이 자기 AS 에서 생기는 경로 유출을 막는 유일한 방법이다.
    • 비정상적인 AS path 를 가진 경로를 네트워크가 자동으로 거부할 수 있게 하는 RPKI Autonomous System Provider Authorization, 곧 ASPA 를 장기적으로 채택하도록 권한다.
    교훈

    Cloudflare 는 이번 사고로 경로 유출을 실수로 일으키기가 얼마나 쉬운지 직접 겪었다고 적었다. 경로 유출을 막으려면 여러 갈래의 대책이 필요하고, 라우팅 정책 설정과 자동화에서 단기와 장기로 고칠 곳을 여럿 찾았다고 했다.

  2. 증상

    2025년 9월 14일 17:42 UTC 부터 18:43 UTC 까지 Miami 데이터센터 US-MIA 와 Milan 데이터센터 IT-MIL 에서 패킷 손실이 났다. 9월 15일 01:44 UTC 부터 04:22 UTC 까지는 Sao Paulo 데이터센터 BR-GRU 에서 패킷 손실이 났다. 대부분의 경우 고객은 성능 저하를 겪었다.

    촉발

    코어 라우터와 엣지 라우터 사이의 prefix 수가 서서히 늘어, 허용된 최대 prefix 수라는 안전 한도를 넘었다.

    원인
    구성 요소
    기여 요인
    –
    조치
    • 모든 데이터센터 라우터의 prefix 한도를 올렸다.
    후속 조치
    • Akamai 백본과 데이터센터 ECOR 라우터 사이 세션의 한도를 올리는 작업을 진행한다.
    • 기존 알림을 고쳐 한도에 닿기 전에 심각도를 확인하게 하고, 이 알림을 사내 담당 팀에 바로 넘겨 즉시 조치하게 한다.
  3. 증상

    2025-03-10 16:23 UTC 무렵 FR-PAR 리전의 모든 제품에서 공용 인터넷 연결이 크게 흔들렸다. 인터넷 트래픽 대부분이 사실상 버려졌고, FR-PAR-2 가용 영역과 나머지 PAR 리전 사이의 공용 인터넷 연결이 심하게 끊겼다.

    촉발

    Scaleway 네트워크 팀이 FR-PAR 리전 백본에 새 데이터 센터를 붙이던 중 라우터 구성을 잘못 넣었다. 이 실수로 OpCore DC3 와 DC5 사이의 1Tbps 넘는 트래픽이 100Gbps 링크 하나로 돌아갔다.

    원인
    구성 요소
    기여 요인
    감지

    라우터 구성 실수는 빨리 발견되어 4분 안에 롤백됐다.

    조치
    • 잘못 넣은 라우터 구성을 4분 안에 롤백해 16:27 UTC 에 올바른 구성을 되돌렸다.
    후속 조치
    • 변경 관리를 고쳐 동료 검토와 운영 공지 절차를 강화한다.
    • 백본 수준의 네트워크 구성을 적용하기 전에 안전장치와 시험을 더 거치도록 운영 절차를 고친다.
    • Object Storage 동기화 소프트웨어의 문제를 찾아 수정을 만들고 시험했으며, 이 수정을 배포하고 있다.
  4. 증상

    2023년 2월 12일 Linode US-West 리전의 고객이 자기 Linode 에 접속하지 못했다. 상태 페이지는 10:22 UTC 에 US-West 의 연결 문제 신고를 조사 중이라고 알렸고, 12:52 에 다시 연결 문제 신고가 들어왔다고 알렸다.

    촉발

    2월 11일 17:45 UTC 에 US-West 두 데이터 센터를 잇는 A 쪽 다중 광섬유 회선의 링크 하나가 끊겼고, 2월 12일 2:45 UTC 에 이중화 짝인 B 쪽 회선 전체가 끊겼다. 하드웨어 업체와 함께 원인을 조사하던 중에는 시스템에 영향을 주지 않는 명령 하나가 드문 버그를 건드려 A 쪽 링크가 모두 끊겼다.

    원인
    구성 요소
    기여 요인
    감지

    2월 12일 10:22 UTC 상태 페이지에 US-West 리전의 연결 문제 신고를 조사 중이라는 공지가 올라왔다. 12:52 UTC 에는 연결 문제 신고가 더 들어와 다시 살펴보기 시작했다.

    조치
    • 2월 12일 10:13 UTC, Santa Clara 보더 라우터에서 인터넷 트래픽을 모두 뺀 변경을 되돌려 서비스를 살렸다.
    • 버그를 피하려고 두 회선의 코드를 긴급히 업그레이드했다. 업그레이드는 16:25 UTC 에 끝나 연결이 돌아왔고, 17:29 UTC 까지 트래픽이 A 쪽 경로로 돌아왔다.
    • 하드웨어 업체, 광섬유 제공자와 함께 B 쪽 고장 지점을 찾아, 2월 14일 18:30 UTC 에 B 쪽 경로를 살리고 US-West 두 사이트 사이 이중화를 모두 되찾았다.
  5. 증상

    2023-01-25 07:08 UTC 부터 Azure 리전의 리소스와 Microsoft 365, Power Platform 같은 Microsoft 서비스에 연결할 때 네트워크 지연이 길어지거나 타임아웃이 났다. 모니터링은 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다.

    촉발

    07:08 UTC 에 마드리드에서 전 세계 WAN 에 용량을 더하던 엔지니어가, 다시 검증하지 않은 표준 운영 절차대로 IGP 데이터베이스를 비우는 명령을 실행했다. 이 명령은 한 제조사의 라우터에서는 로컬 라우터에 그치지 않고 IGP 로 이어진 모든 라우터에 IGP 토폴로지 데이터베이스를 다시 계산하라고 지시했다.

    원인
    구성 요소
    기여 요인
    감지

    모니터링이 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다. 변경하던 엔지니어는 바뀐 절차 때문에 이 알림을 전달받지 못했다. 팀은 최근 변경을 모두 살펴 08:20 UTC 에 문제의 명령을 찾았다.

    조치
    • WAN 라우팅이 수렴한 뒤에도 남은 패킷 손실을 없애려고, 사고 중 멈춰 있던 비정상 장비 제거 시스템과 트래픽 엔지니어링 시스템을 손으로 다시 시작했다. 12:43 UTC 에 복구를 마쳤다.
    후속 조치
    • 세 제조사 전부와 모든 WAN 라우터 역할을 대상으로, 넓은 영향을 줄 수 있는 비슷한 명령을 감사하고 막는다. 2023년 2월에 끝낼 예정이다.
    • 승인된 자동화와 승인된 비상 접근인 break glass 작업, 승인되지 않은 장비 작업을 실시간으로 보여 줘, 당직 엔지니어가 누가 네트워크 장비에서 무엇을 바꾸는지 볼 수 있게 한다. 2023년 2월에 끝낼 예정이다.
    • 정기적인 필수 운영 교육과 모든 표준 운영 절차를 지키겠다는 확인 절차를 도입해 절차를 계속 개선한다. 2023년 2월에 끝낼 예정이다.
    • 아직 검증을 기다리는 표준 운영 절차를 모두 감사하고, 엔지니어 의견을 받아 30일 안에 Change Advisory Board 검토를 우선 받게 한다. 2023년 4월에 끝낼 예정이다.
내 클러스터에도 있는지 확인하기

이 12건에서 가장 많이 나오는 구성 요소: 백본망, BGP 라우팅. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별5

설정 변경3건

  1. IL-0394 Cloudflare Miami 라우터가 내부 IPv6 경로를 BGP 피어와 트랜짓 제공자에게 유출해 25분 동안 백본이 혼잡해지고 트래픽이 드롭됐다
  2. IL-0225 라우터 명령 하나가 Microsoft WAN 의 모든 라우터에 토폴로지를 다시 계산하게 해 전 세계 Azure 네트워크 연결이 불안정해졌다.
  3. IL-0228 라우터 설정 변경 중 인터넷 전체 라우팅 테이블이 IGP 로 광고돼 OVHcloud 전 세계 네트워크의 IPv4 라우팅이 멈췄다.

용량 한계1건

기여 요인
–
조직
  1. IL-0564 Linode 의 Miami, Milan, Sao Paulo 데이터센터에서 패킷 손실로 서비스 성능이 떨어졌다
    Linode2025

운영 실수2건

  1. IL-0348 FR-PAR 리전의 모든 제품에서 공용 인터넷 연결이 끊기고 여러 제품이 오래 불안정했다
  2. IL-0221 유지보수 명령이 Facebook 백본 네트워크의 연결을 모두 끊어 데이터 센터와 DNS 서버가 인터넷에서 닿지 않게 됐다.
    Meta2021

소프트웨어 결함3건

  1. IL-0344 Linode US-West 의 Fremont 와 Santa Clara 데이터 센터가 인터넷 연결과 두 사이트 사이 연결을 잃었다
    Linode2023
  2. IL-0256 하드웨어 로드 밸런서가 거듭 죽고 대기 장비로 넘어간 뒤 라우터가 동기화하지 못해 Basecamp 전체가 이틀 연속 열리지 않았다
  3. IL-0222 유지보수 자동화가 여러 위치의 네트워크 제어 평면 작업을 한꺼번에 내려 미국 Google Cloud 리전의 네트워크가 심하게 혼잡해졌다.

의존성 장애3건

  1. IL-0267 싱가포르 캐시 거점 eqsin 의 전송 회선 두 개가 함께 끊겨 BGP 가 내려가고 eqsin 의 호스트에 닿을 수 없게 됐다
  2. IL-0255 데이터센터 사이 메트로 회선이 잠깐 끊긴 뒤 Redis 레플리카가 재동기화 루프에 빠져 BC3 가 느려지고 채팅이 멈췄다
  3. IL-0358 Packet 공용 클라우드의 여러 리전에서 라우팅 루프와 블랙홀로 연결이 간헐적으로 끊겼다
    Packet2019