Cloudflare 2022년 장애: BGP 변경 단계 배포가 책임성의 시험이 되다

요약

• 2022년 6월 21일, Cloudflare는 네트워크 구성 변경이 Multi-Colo PoP 아키텍처를 사용하는 19개 데이터센터에서 장애를 일으켰다고 밝혔다. 해당 위치들은 네트워크의 약 4%였지만 트래픽의 큰 비중을 처리했다. Cloudflare는 장애 기간 전체 요청의 약 절반이 영향받은 트래픽에 해당한다고 보았으며, 사용자 영향은 위치에 따라 달랐다고 언급했다. [1]
• 의도된 변경은 사이트 로컬 프리픽스에 정보성 BGP 커뮤니티를 표준화하는 것이었다. MCP 스파인 라우터에서는 정책 항의 재정렬로 인해 비활성화된 프리픽스에 관한 항이 중요한 사이트 로컬 경로를 광고해야 하는 항들보다 앞으로 이동했다. 그 결과 경로 정책이 해당 프리픽스를 철회했다. [1]
• 이 철회는 외부 도달 가능성 그 이상을 제거했다. Cloudflare에 따르면 자사 서버들이 정상적으로 통신하거나 고객 오리진에 도달할 수 없게 되었고, Multimog 로드밸런싱 계층은 영향받은 MCP 내부의 컴퓨팅 클러스터들 간에 요청을 이동시킬 수 없었다. 그 결과 작은 클러스터들이 큰 클러스터와 비슷한 트래픽을 받아 과부하가 걸렸다. [1]
• 엔지니어들은 변경을 되돌리기 위해 영향받은 위치에 접근하는 데에도 어려움을 겪었다. 백업 절차가 필요했다. 복구 과정에서 엔지니어들이 서로의 되돌리기를 덮어쓰는 경우가 있어, 최종 위치가 복구되기 전까지 문제가 산발적으로 재발했다. [1]
• Cloudflare의 프로세스에는 이미 변경 티켓, 드라이런, 동료 검토, 단계적 배포가 포함되어 있었다. 통제 실패는 더 구체적이었다: 초기 배포 단계 어느 것도 MCP 위치를 시험하지 않았다. 첫 대표적 테스트는 마지막 단계가 모든 MCP 스파인에 도달했을 때 비로소 이루어졌다. [1]
• BGP 커뮤니티는 라우팅 정책에서 사용되는 메타데이터다. 커뮤니티는 내보내기 정책이 올바르게 정렬되어 있는지, 필요한 프리픽스가 계속 광고되고 있는지를 증명하지 못한다. RPKI 오리진 검증은 어떤 오리진 AS가 프리픽스에 대해 승인되었는지를 다룬다; 이 사건의 내부 항 정렬, 카나리아 선택, 롤백 절차는 검증하지 못한다. [10][11][12][14][15][16]
• 따라서 책임성은 운영 증거를 요구해야 한다: 변경 전후의 정확한 후보 구성, 기계 검증 가능한 필수 프리픽스 집합, 경로 정책 시뮬레이션, MCP 전용 카나리아, commit-confirm 동작, 독립적인 관리 도달 가능성, 단일 권위 있는 롤백 책임자, 위치별 변경 기록, 그리고 라우터 로그와 대조된 외부 경로 관찰이다.
• 공개 라우트 컬렉터는 외부에서 보이는 광고와 철회를 확인하는 데 도움이 되지만, 모든 비공개 사이트 로컬 경로나 내부 정책 결정을 드러내지는 못한다. 운영자 기록은 여전히 필요하다. [17][18][19]
• 공개 기록은 악의적 의도, 과실, 규제 위반, 영향받은 모든 프리픽스, 모든 고객 손실, 또는 명시된 모든 개선 조치가 현재도 배포 중인지를 입증하지 않는다. 이 한계는 명시적으로 유지되어야 한다.

검토된 변경도 시험되지 않은 변경일 수 있다

인프라 조직은 종종 프로세스 라벨을 통제를 가리키는 약칭으로 사용한다. 변경은 티켓 처리되었다. 드라이런은 완료되었다. 여러 엔지니어가 검토했다. 배포는 단계적으로 이루어졌다. 이 진술 각각은 참일 수 있지만, 운영 리스크는 여전히 시험되지 않은 상태일 수 있다.

Cloudflare의 2022년 6월 21일 장애에 대한 설명은 이 구분을 이례적으로 명확하게 보여준다. 이 변경은 변경 요청 티켓을 통과했고, 드라이런을 포함했으며, 동료 검토를 받았고, 단계별 배포 절차를 따랐다. 초기 단계들은 장애를 일으키지 않았다. 실패는 배포가 Cloudflare가 Multi-Colo PoP(MCP)라고 부른 아키텍처를 사용하는 19개 위치에 도달했을 때 나타났다. 초기 단계 어느 것도 MCP 위치를 시험하지 않았다. 관련 라우팅 토폴로지를 대표하는 첫 단계가 바로 모든 MCP 스파인에 구성을 적용한 단계였다. [1]

이것은 티켓, 검토, 드라이런, 단계 배포가 무용하다는 논거가 아니다. 각 통제에는 정의된 주장이 필요하다는 증거다. 티켓은 승인과 의도를 기록한다. 검토는 지명된 사람들이 변경의 어떤 표현을 검토했음을 기록한다. 드라이런은 도구가 지정된 모델이나 장치 상태에 대해 계산한 결과를 기록한다. 단계 배포는 각 단계가 서로 다른 고장 도메인을 대표하고, 다음 단계 전에 멈출 수 있을 만큼 작을 때에만 범위를 제한한다.

따라서 책임성 질문은 “프로세스가 존재했는가”가 아니라 “각 프로세스 단계가 무엇을 입증했는가”이다. 이 사건에서 초기 배포는 변경이 구형 아키텍처를 사용하는 위치를 방해하지 않았음을 입증했다. 그러나 정책이 MCP 스파인에서 필요한 광고를 보존할 것임은 입증하지 못했다. 비대표 위치에서 나온 녹색 결과는 결정적 질문에 답할 수 없었다.

이 격차가 중요한 이유는 네트워크 구성이 실행 가능한 운영 권한이기 때문이다. 경로 정책 항은 단순히 트래픽이 어디로 가야 하는지를 기술하지 않는다. 항의 순서는 라우터가 어떤 경로를 광고하거나 보류하는지를 결정한다. 커밋되면 구성은 서버, 피어, 오리진, 운영자, 복구 시스템이 사용하는 도달 가능성 그래프를 바꾼다. 무해한 메타데이터 추가와 대규모 장애 사이의 차이는, 한 정책 분기가 다른 분기보다 먼저 평가되는 것 하나일 수 있다.

Cloudflare의 보고서를 “잘못된 구성이 장애를 일으켰다”는 슬로건으로 축소해서는 안 된다. 유용한 교훈은 더 좁고 더 demanding하다: 변경 통제는 아키텍처, 경로 불변식, 고장 도메인, 복구 접근에 묶여야 한다. 관련 아키텍처를 건너뛰는 단계 절차는 실제로 실패할 시스템에 대한 증거 없이 신중함의 외관만 만들어 낼 수 있다.

의도된 변경은 정보성이었으나, 실제 변경은 도달 가능성이었다

Cloudflare는 광고 중인 일부 프리픽스에 붙는 BGP 커뮤니티, 구체적으로는 사이트 로컬 프리픽스에 정보성 커뮤니티를 추가하는 표준화 작업을 하고 있었다고 밝혔다. BGP 커뮤니티는 운영자가 경로에 라벨을 붙이고 라우팅 정책에 영향을 주기 위해 사용하는 속성이다. 표준 커뮤니티 명세는 개별 프리픽스가 아니라 경로의 클래스에 라우팅 결정을 적용할 수 있도록 목적지를 묶는 방법을 정의한다. Large Communities는 현대 운영 요구에 맞게 그 형식을 확장한다. [1][11][12]

의도된 추가는 서비스 경로를 철회하려는 시도로 설명되지 않았다. Cloudflare는 그것을 보고서에 나온 일반 라우터들에서는 무해한 정보로 규정했다. 실질적 차이는 MCP 스파인 라우터에서 나타났다. 구성 diff가 하나의 통합 내보내기 정책에서 항들의 순서를 재배열했다. 비활성화된 프리픽스와 관련된 항이 서비스와 내부 기능을 위한 사이트 로컬 경로를 광고하는 항들보다 앞으로 이동했다. 정책 항은 순차적으로 평가되기 때문에, 먼저 일치한 항이 뒤따르는 광고 로직이 제 역할을 하지 못하게 막았다. [1]

이것이 의미적 의도와 실제 동작 사이의 차이이다. 변경 작성자는 메타데이터를 붙이려 했을 수 있다. 검토자는 커뮤니티 추가를 봤을 수 있다. 티켓 제목은 “커뮤니티 표준화”라고 적혀 있을 수 있다. 그러나 그 어떤 표현도 라우터를 통제하지 못한다. 라우터는 결과로 나온 정책을 순서대로 평가한다. 생성되거나 렌더링된 구성이 그 순서를 바꾼다면, 실제 운영 효과는 정책 엔진이 실행하는 그 무엇이든 된다.

BGP 자체가 도달 가능성 메커니즘을 제공한다. 네트워크는 주소가 어떤 경로를 통해 도달 가능하다는 것을 피어에게 알리기 위해 프리픽스를 광고한다. 도달 가능성이 더 이상 없거나 광고되어서는 안 될 때 경로를 철회한다. 철회된 프리픽스는 선택된 경로들에서 사라져, 관련 주소가 그 경로를 통해 도달 불가능할 수 있다. BGP-4 명세는 이러한 광고와 철회 의미를 정의하며, 특정 정책 항에 대한 운영자의 비즈니스 의도는 알지 못한다. [10]

이 구분은 증거 요건을 만든다. 변경 승인은 상위 수준의 요청이나 생성된 템플릿이 아니라, 라우터가 실제로 평가할 정확한 후보 구성에 묶여야 한다. 검토 기록은 다음을 보여야 한다:

1. 변경 전후의 정확한 렌더링된 정책.
2. 영향받은 모든 항의 평가 순서.
3. 수용, 거부, 광고, 철회될 것으로 예상되는 경로 집합.
4. 그 집합에 속한 각 프리픽스의 출처.
5. 정책이 실행될 장치 역할과 아키텍처.
6. 대표적인 경로 입력을 사용한 시뮬레이션 또는 랩 결과.
7. 정책 출력이 잘못된 경우에도 도달 가능한 관리 및 롤백 경로.

이러한 묶음이 없으면, 검토는 요청은 검증하면서도 컴파일된 효과를 놓칠 수 있다. 인프라 책임성은 실행 중인 시스템이 소비하는 구성을 따라간다.

사이트 로컬 프리픽스는 서비스 경로의 일부였다

“사이트 로컬”이라는 용어는 부차적으로 들릴 수 있다. 마치 영향받은 경로가 고객에 영향을 주지 않는 내부 정리 항목처럼 들린다. Cloudflare의 보고서는 그렇지 않음을 보여준다. 해당 프리픽스들은 자사 장비들 간의 통신을 가능하게 했고, 서버가 고객 오리진에 도달하게 했다. 그 철회는 이 경로들을 끊었다. [1]

Cloudflare는 프리픽스를 MCP 위치에서 사용되는 내부 로드밸런싱 시스템인 Multimog와도 연결했다. 관련 도달 가능성이 사라지면서 Multimog는 더 이상 MCP 내의 서버들 사이로 요청을 전달할 수 없었다. 그 결과 크기가 다른 컴퓨팅 클러스터들이 비슷한 트래픽 부하를 받았다. 작은 클러스터들이 과부하에 걸렸다. [1]

이 메커니즘이 중요한 이유는, 누락된 프리픽스의 단순 개수보다 일부 경로 철회가 훨씬 큰 서비스 영향을 미칠 수 있는 이유를 설명해 주기 때문이다. 하나의 프리픽스가 많은 서비스가 공유하는 의존성을 지원할 수 있다. 그것이 오리진 도달 가능성, 내부 클러스터 통신, 로드밸런싱 경로를 담당한다면, 그 철회는 시스템 전반에서 작업이 분배되는 방식을 바꾼다. 서비스는 엣지에서 트래픽을 계속 받으면서, 그 트래픽을 안전하게 처리하거나 전달하는 데 필요한 내부 경로를 잃을 수 있다.

따라서 이 사건은 운영자가 경로의 중요도를 어떻게 분류하는지 시험한다. 프리픽스 레지스트리는 소유권이나 오리진 승인에서 멈추지 않아야 한다. 운영 역할을 기록해야 한다:

• 프리픽스가 인터넷 대면, 관리 전용, 사이트 로컬, 고객 오리진 대면, 또는 클러스터 간인가?
• 어떤 라우터와 정책이 그것을 광고하는가?
• 어떤 서비스가 그것에 의존하는가?
• 어떤 모니터링 검사가 그것의 도달 가능성을 증명하는가?
• 어떤 위치가 같은 정책 템플릿을 공유하는가?
• 경로가 사라졌지만 들어오는 트래픽은 계속되면 어떤 일이 발생하는가?
• 관리 접근이 같은 경로 패밀리나 정책을 사용하는가?
• 그 의존성을 대신 담당할 것으로 예상되는 대체 경로는 무엇인가?

이 기록은 네트워크에 대한 주권이 아니다. 경로를 존재하게 만들지도 않는다. 검증 가능한 예상 상태의 대장(ledger)을 만든다. 운영자는 이 대장을 라우팅 정보 베이스, 포워딩 정보 베이스, 외부 컬렉터, 능동 프로브, 서비스 수준 결과와 비교할 수 있다. 정확하고, 고유하고, 변경 통제되고, 관찰된 동작과 묶인 기록은 고객이 모니터링 시스템이 되기 전에 철회를 감지 가능하게 만든다.

Multimog 효과는 또한 용량에 토폴로지 맥락이 필요한 이유를 보여준다. Cloudflare에 따르면 영향받은 MCP 위치에는 크기가 다른 클러스터들이 있었다. 내부 포워딩이 실패하자 작은 클러스터들이 큰 클러스터와 비슷한 트래픽을 받았다. 따라서 총 사이트 용량을 보여주는 용량 대시보드는 사용 가능한 용량을 과대 표시할 수 있었다. 경로 실패는 총 용량을 접근 가능하게 만든 균형 메커니즘을 제거했다.

증거에 기반한 검토는 각 MCP가 시험된 저하 모드를 갖고 있었는지를 물어야 한다. Multimog가 사이트 로컬 도달 가능성을 잃었을 때 트래픽을 외부로 배출할 수 있었는가? 작은 클러스터가 어드미션 컨트롤로 자신을 보호할 수 있었는가? 경로 정책 카나리아에 BGP 세션 상태뿐 아니라 오리진 접근, 클러스터 간 포워딩, 관리 접근에 대한 프로브가 포함되어 있었는가? 공개 보고서는 의존성을 식별하지만, 모든 보호 통제를 공개하지는 않는다.

19개 위치는 분산 네트워크 내부의 집중을 드러냈다

Cloudflare에 따르면 19개 MCP 위치는 네트워크의 약 4%였지만, 장애는 전체 요청의 약 50%에 영향을 주었다. 회사는 또한 영향이 위치에 따라 달랐음을 강조했다: 일부 사용자는 Cloudflare를 사용하는 속성에 도달할 수 없었고, 다른 위치들은 정상 운영을 계속했다. [1]

이 수치들은 출처가 밝혀진 상태로 유지되어야 하며, 사람, 고객, 웹사이트 또는 재정 손실의 수로 변환되어서는 안 된다. 그러나 이 수치들은 토폴로지 교훈을 뒷받침한다. 네트워크는 지리적으로 분산되어 있으면서도 트래픽은 소수의 고용량 위치에 집중될 수 있다. 위치 수를 세는 것은 그들이 담당하는 트래픽 비중, 고객 의존성, 피어링 용량, 오리진 연결성을 측정하는 것과 같지 않다.

MCP 프로그램은 가장 분주한 위치의 복원력을 개선하기 위한 것이었다. Cloudflare는 추가 라우팅 계층과 스파인 연결 메시를 갖춘 Clos 방식 아키텍처를 설명했다. 이 아키텍처는 유지보수나 고장 처리를 위해 내부 네트워크의 일부를 활성화하거나 비활성화할 수 있게 했다. 이것들은 정당한 복원력 목표이다. 이 사건은 그 아키텍처가 본질적으로 결함이 있음을 증명하지 않는다. [1]

그러나 이 사건은 공통 정책 경로가 물리적으로 분리된 위치들을 연결할 수 있음을 보여준다. 같은 렌더링된 경로 정책이 하나의 최종 배포 단계에서 모든 MCP 스파인에 도달한다면, 그 정책 템플릿은 공유 고장 도메인이 된다. 물리적 다양성은 그 공통 통제 의존성을 제거하지 않는다.

이것은 되풀이되는 네트워크 책임성 패턴이다. 운영자는 여러 라우터, 시설, 캐리어, 경로를 가질 수 있지만, 단일 자동화 템플릿, 자격 증명 시스템, 경로 정책, 컨트롤러 또는 배포 단계가 여전히 공통 모드 고장을 만들 수 있다. 다양성은 사건을 일으킨 통제 표면에서 측정되어야 한다.

MCP 배포를 위한 유용한 변경 지도에는 다음이 포함될 수 있다:

이 표는 저위험 첫 단계가 대표적 단계로 오인되는 것을 막는다. 카나리아는 작아야 하지만, 변경되는 기능과 아키텍처를 실제로 시험해야 한다. 유일한 대표적 사이트가 카나리아로 쓰기에 트래픽이 너무 많다면, 그 자체가 랩 트윈, 섀도 평가, 더 작은 대표 도메인, 또는 생산 전 더 강한 정적 불변식을 요구하는 아키텍처 및 운영 리스크이다.

관리 도달 가능성의 상실은 복구 문제를 바꿨다

Cloudflare는 경로 철회로 인해 엔지니어들이 영향받은 위치에 도달해 구성을 되돌리기가 더 어려워졌다고 밝혔다. 통제를 확보하기 위해 백업 절차가 사용되었다. [1]

이 세부 사항은 분석의 중심에 있어야 한다. 네트워크 변경은 롤백 명령이 존재한다는 이유만으로 안전하게 되돌릴 수 있는 것이 아니다. 운영자는 여전히 인증하고, 장치에 도달하고, 올바른 상태를 판별하고, 네트워크가 저하된 상태에서 롤백을 조율할 수 있어야 한다. 관리 트래픽이 변경되는 경로들에 의존한다면, 복구 경로는 같은 고장 도메인을 공유한다.

독립 접근이 모든 장치마다 완전히 별도의 글로벌 네트워크를 요구하는 것은 아니다. 요구되는 것은 시험 중인 고장에서 살아남는 합리적으로 설계된 접근이다. 옵션에는 별도 라우팅된 관리 네트워크의 콘솔 서버, 대역 외(out-of-band) 캐리어 링크, 시한 롤백을 실행할 수 있는 로컬 자동화, 장치의 commit-confirm 기능, 보호된 터미널 접근, 또는 그 도달 가능성이 후보 정책에 의존하지 않는 제어 채널이 포함될 수 있다.

각 옵션에는 한계가 있다. 대역 외 캐리어는 같은 시설이나 전원을 공유할 수 있다. 콘솔 서버는 같은 신원 제공자나 DNS 서비스에 의존할 수 있다. commit-confirm 타이머는 너무 일찍 취소되거나 모든 의존 상태를 복원하지 못할 수 있다. 로컬 자동화는 잘못된 기준선을 적용할 수 있다. 책임성은 선택된 경로가 정확한 상실 조건에서 작동함을 증명하는 훈련을 요구한다.

이 사건에 관련된 시험은 단순하다: 대표적인 MCP 환경에서 일반 사이트 로컬 및 관리 도달 가능성을 제공하는 경로 집합을 철회하거나 억제한 다음, 운영자가 여전히 상태를 점검하고 승인된 구성을 복원할 수 있는지 검증하라. 훈련은 접근까지의 시간, 실패한 불변식을 식별하기까지의 시간, 롤백 시작까지의 시간, 필요한 광고를 복원하기까지의 시간, 서비스 복구를 확인하기까지의 시간을 측정해야 한다.

평상시의 성공적인 로그인 스크린샷은 충분하지 않다. 시험은 실패한 의존성을 제거해야 한다. 실행 중인 시스템의 증거는 어떤 경로를 “대역 외”라고 라벨 붙인 다이어그램보다 우선한다.

공개 보고서는 Cloudflare가 사용한 모든 백업 절차를 식별하지 않으며, 이는 보안과 운영상의 이유로 합리적이다. 민감한 토폴로지와 자격 증명은 공개되어서는 안 된다. 조직은 접근 통제 하에 감사 가능한 증거를 유지할 수 있다: 훈련 타임스탬프, 장치 범위, 독립 증명, 경로 프로브, 성공 기준, 예외 사항.

롤백 권한은 협업 통제로서 실패했다

Cloudflare의 타임라인에 따르면 최종 되돌리기가 지연된 이유는 네트워크 엔지니어들이 서로의 변경을 덮어썼기 때문이다. 일부 되돌리기가 이전 되돌리기를 취소해 문제가 산발적으로 재발했다. [1]

이것은 단순한 인적 오류의 각주가 아니다. 이것은 인시던트 대응에서 직렬화 속성이 결여되었음을 식별한다. 큰 영향을 주는 장애 동안 여러 엔지니어가 유효한 접근 권한과 강한 행동 이유를 가질 수 있다. 변경 시스템이 하나의 권위 있는 목표 상태, 가시적인 소유권, 장치별 잠금, 공유 진행 기록을 제공하지 않는다면, 병렬 작업은 진동(oscillation)을 만들 수 있다.

운영 교훈은 오직 한 사람만 대응해야 한다는 것이 아니다. 조사, 경로 관찰, 고객 커뮤니케이션, 서비스 테스트, 롤백 준비는 병렬로 진행될 수 있다. 같은 라우팅 상태의 변경은 협업이 필요하다. 시스템은 한 대응자가 다른 대응자가 제거한 구성을 다시 도입하기 어렵게 만들어야 한다.

유용한 통제는 다음을 포함한다:

• 선언된 인시던트 사령관과 네트워크 변경 책임자.
• 복구를 위한 고정(frozen) 목표 상태 커밋.
• 롤백 중 장치 또는 정책 도메인 잠금.
• 각 시도된 및 완료된 되돌리기를 기록하는 단일 오케스트레이터.
• 관리 확인이 상실되면 이전 상태를 자동 복원하는 commit-confirm 타이머.
• 구성을 변경하지 않고 경로 및 서비스 복구를 검증하는 읽기 전용 관찰자.
• 비상 수동 변경이 정상 자동화 재개 전에 권위 있는 구성에 반영되는 규칙.
• 소유권이 팀 또는 지역 간에 이동할 때의 명시적 인수인계.

이 통제들은 위치별 대장을 만들어야 한다. 각 MCP에 대해 기록은 문제 구성 식별자, 롤백 명령 또는 커밋, 실행자, 시작 및 종료 시간, 장치 확인, 경로 테이블 결과, 관리 도달 가능성, 서비스 프로브, 그리고 같은 정책을 다룬 이후의 변경을 보여야 한다. 대장은 간섭을 가시화하고 마지막 사이트가 복구되었다는 신뢰할 수 있는 선언을 뒷받침한다.

Cloudflare의 개선 조치에는 자동 commit-confirm 롤백과 더 나은 스태거 강제가 포함되었다. [1] commit-confirm 메커니즘은 경로 변경이 관리 접근을 제거할 수 있을 때 특히 관련이 있다. 도달 가능성과 불변식 검사를 통과한 후 운영자가 새 상태를 확인하지 않으면, 라우터는 이전 상태를 자동으로 복원할 수 있다.

commit-confirm은 마법이 아니다. 타임아웃은 검증에 충분히 길어야 하지만 영향을 제한할 만큼 짧아야 한다. 이전 상태 자체가 안전해야 한다. 확인은 약한 신호만으로 자동화되어서는 안 된다. 다중 장치 변경은 한 라우터가 되돌려지는 동안 다른 라우터가 후보 상태에 남는 일이 없도록 조율된 의미 체계가 필요하다. 이 메커니즘도 여전히 훈련과 증거가 필요하다.

프로세스는 존재했지만, 증명 의무는 불완전했다

Cloudflare의 보고서는 변경이 티켓, 드라이런, 단계적 배포, 그리고 여러 동료 검토자를 거쳤음을 명시적으로 말한다. [1] 이것은 이미 성숙한 변경 관리 어휘를 갖춘 조직에게 이 사건을 유용하게 만든다.

허술한 사후 분석 대응은 또 하나의 승인을 추가하는 것이다. 더 많은 서명은 누락된 조건을 시험하지 않으면서 전달을 늦출 수 있다. 증거는 네 가지 더 강한 질문을 가리킨다.

첫째, 드라이런은 어떤 입력을 사용했는가? 구형 아키텍처에 대해서만 정책을 렌더링했다면, MCP 항 정렬 효과를 드러낼 수 없었다. 드라이런은 생성 로직의 영향을 받는 모든 정책 역할, 특히 다른 템플릿이나 상속을 갖는 역할을 포함해야 한다.

둘째, 드라이런은 어떤 주장을 평가했는가? 문법적으로 유효한 구성도 여전히 필요한 프리픽스를 철회할 수 있다. 검증은 파싱 결과만이 아니라 경로 출력을 비교해야 한다. 필요한 사이트 로컬, 관리, 오리진 대면, 또는 서비스 프리픽스가 예기치 않게 변경되면 도구는 실패해야 한다.

셋째, 배포 그룹은 어떻게 정의되었는가? 모든 초기 지역이 구형 설계를 사용했다면 지리적 순서만으로는 아키텍처 특유의 결함을 드러내지 못한다. 그룹은 하드웨어, 소프트웨어, 토폴로지, 정책 역할, 컨트롤 플레인 버전, 트래픽 비중, 관리 경로를 반영해야 한다.

넷째, 무엇이 진행을 멈추는가? 단계 배포는 명시적 관찰 창과 자동 게이트를 갖고 있을 때만 효과적이다. 다음 그룹이 시작되기 전에 시스템은 카나리아가 필요한 경로, 오리진 도달 가능성, 내부 로드밸런싱, 관리 접근, 서비스 성공을 유지했음을 보여주는 증거가 필요하다.

동료 검토에도 비슷한 의무가 있다. 검토자는 모든 역할의 렌더링된 diff, 예상 경로 출력, 카나리아 매트릭스, 롤백 계획, 복구 경로가 독립적이라는 증거가 필요하다. 검토자에게 이것을 상위 수준 티켓에서 추론하게 하는 것은 같은 격차를 초대한다.

목표는 관료적 완벽이 아니다. 프로세스를 고장 메커니즘에 묶는 것이다. BGP 정책의 경우 운영 주장은 “지정된 프리픽스가 지정된 피어에게 계속 광고되는 동안 의도된 속성만 변경된다”이다. 이 주장은 기계적으로 시험할 수 있다.

경로 불변식은 의도를 시험으로 바꾼다

경로 불변식은 변경 전, 중, 후에 참이어야 하는 진술이다. 예시는 다음과 같다:

• 모든 MCP 스파인이 승인된 사이트 로컬 프리픽스 집합을 광고한다.
• 관리 프리픽스가 지정된 독립 접근 지점에서 도달 가능하다.
• 고객 오리진 연결성 프로브가 각 컴퓨팅 클러스터에서 성공한다.
• 내부 로드밸런싱이 크기가 다른 클러스터들 간에 요청을 이동시킬 수 있다.
• 예기치 않은 공개 프리픽스가 광고되지 않는다.
• 보호된 프리픽스가 철회되지 않는다.
• 변경된 경로의 수와 속성이 승인된 변경 범위와 일치한다.

필수 프리픽스 집합은 서비스 소유권에 연결된 정확한 운영 레지스트리에서 나와야 한다. 일회성 티켓에 복사된 비공식 목록이어서는 안 된다. 프리픽스 식별, 역할, 오리진, 예상 피어, 보안 메타데이터, 변경 이력에는 내구성 있는 소유권이 필요하다.

커밋 전에 정책 시뮬레이션은 후보를 대표적인 경로와 피어 맥락에 대해 평가할 수 있다. 카나리아 커밋 후에는 시스템이 라우터의 라우팅 정보 베이스와 광고 경로 뷰를 불변식과 비교할 수 있다. 능동 프로브는 서비스 경로를 시험할 수 있다. 외부 컬렉터는 공개 광고에 대한 별도의 뷰를 제공할 수 있다. [17][18][19]

비교는 예상된 변경과 예상치 못한 변경을 구분해야 한다. 목적이 커뮤니티 추가라면, 승인된 집합 내에서 속성이 변경되는 동안 경로 존재는 안정적으로 유지되어야 한다. 필수 사이트 로컬 프리픽스의 철회는 그때 전역 HTTP 오류를 기다리는 증상이 아니라 즉각적인 게이트 실패이다.

경로 불변식은 인시던트 커뮤니케이션도 개선한다. “네트워크가 복구 중입니다”라고 말하는 대신, 운영자는 필요한 광고가 정의된 수의 위치에서 복원되었고, 관리 도달 가능성이 돌아왔으며, 내부 포워딩이 통과하고, 고객 요청 성공률이 명시된 범위 내에 있다고 보고할 수 있다. 각 주장에는 증거와 경계가 있다.

허위 확신의 위험이 있다. 불변식 집합은 불완전할 수 있다. 경로가 존재하지만 잘못 포워딩할 수 있다. 컨트롤 플레인 뷰가 데이터 플레인과 다를 수 있다. 그렇기 때문에 경로 검사는 포워딩과 서비스 프로브와 짝을 이루어야 한다. 인시던트가 표현되지 않은 의존성을 드러내면 시험 스위트를 갱신해야 한다.

BGP 커뮤니티 자체가 장애를 일으키지 않았다

이 사건을 “BGP 커뮤니티가 Cloudflare를 무너뜨렸다”로 요약하면 부정확하다. 커뮤니티는 경로에 붙는 메타데이터다. 운영자는 정책, 태깅, 트래픽 엔지니어링, 운영 신호 전달에 그것들을 사용한다. RFC 1997과 RFC 8092는 커뮤니티 형식을 정의하며, Cloudflare의 정책 순서를 지시하지 않는다. [11][12]

의도된 커뮤니티 추가는 변경 맥락의 일부였다. 장애 메커니즘은 MCP 스파인에서 정책 항의 실제 순서와 그로 인한 필수 프리픽스 철회였다. [1] 이 구분이 중요한 이유는 개선 조치가 실패한 통제를 다루어야 하지, 표준 메커니즘에 낙인을 찍어서는 안 되기 때문이다.

커뮤니티의 의미가 문서화되고, 고유하고, 일관되게 적용된다면 책임성을 개선할 수 있다. 커뮤니티는 경로 클래스, 의도된 처리, 유지보수 상태, 지리, 고객 관계를 식별할 수 있다. 그러나 라벨은 정책 평가가 필요한 결과를 보존할 때만 유용하다. “사이트 로컬”이라고 말하는 커뮤니티는 앞선 항이 그 경로를 거부하면 광고를 유지하지 못한다.

같은 원리가 변경 이름과 주석에도 적용된다. 사람이 읽을 수 있는 라벨은 검토를 돕지만, 실행 중인 정책이 도달 가능성을 결정한다. 운영자는 커뮤니티 정의에서 경로 집합, 정책 분기, 예상 광고, 관찰된 결과까지 추적할 수 있어야 한다. 추적이 문서에서 끝난다면 운영 증거는 불완전하다.

RPKI는 중요하지만 직접적인 수선책은 아니다

RPKI는 IP 주소 자원을 승인된 오리진 AS에 묶는 방법을 제공한다. Route Origin Validation은 라우터가 오리진과 프리픽스 길이가 Route Origin Authorization과 일치하는지에 따라 광고를 분류하게 한다. RFC 6480은 아키텍처를, RFC 6811은 오리진 검증을 기술한다. [15][16]

이 통제들은 2022년 6월의 실패와는 다른 질문을 다룬다. RPKI는 Cloudflare의 AS가 공개 프리픽스를 오리진으로 삼는 것이 승인되었는지 판단하는 데 도움이 될 수 있다. 그러나 내부 내보내기 정책 항이 사이트 로컬 프리픽스를 광고해야 하는지, 항들이 올바르게 정렬되어 있는지, MCP 카나리아가 대표적인지, 롤백 접근이 독립적인지는 판단하지 않는다.

승인된 경로도 실수로 철회될 수 있다. 유효한 오리진은 가용성을 증명하지 않는다. 반대로 내부 사이트 로컬 경로는 공개 RPKI나 외부 컬렉터에 전혀 보이지 않을 수 있다. RPKI를 만능 해결책으로 제시하면 실제 통제 실패를 가리게 된다.

RPKI는 여전히 증거 모델에 속한다. 네트워크 자원 승인, 경로 정책, 운영 연속성은 상호작용하기 때문이다. 운영자는 정확한 번호 자원 기록과 보안 메타데이터를 유지하면서, 정책 동작과 서비스 도달 가능성을 별도로 검증해야 한다. 레지스트리 무결성과 실행 중인 코드의 증거는 상호 보완이지 대체물이 아니다.

이 경계는 공개 책임성에도 유용하다. 사후 분석은 인시던트가 오리진 승인 문제였는지, 경로 누수였는지, 하이재킹이었는지, 내부 정책 철회였는지, 또는 다른 라우팅 메커니즘이었는지를 진술할 수 있다. 정확한 분류는 모든 BGP 관련 사건을 같은 실패로 취급하는 것을 피하고 올바른 개선 조치를 뒷받침한다.

외부 경로 관찰은 가치 있지만 불완전하다

RIPE NCC의 Routing Information Service는 피어들로부터 BGP 데이터를 수집하며, RIS Live는 업데이트 스트림을 공개한다. CAIDA의 BGPStream은 여러 컬렉터의 라우팅 데이터를 다루는 도구를 제공한다. 이 시스템들은 연구자와 운영자가 참여 관측 지점에서 보이는 광고, 철회, 경로 변경, 복원을 관찰하는 데 도움을 줄 수 있다. [17][18][19]

공개 프리픽스 인시던트에 대해 외부 관찰은 중요한 질문에 답할 수 있다:

• 언제 프리픽스가 선택된 컬렉터에서 사라졌는가?
• 어떤 피어나 지역이 철회를 관찰했는가?
• 언제 광고가 돌아왔는가?
• 복원 후 경로나 속성이 바뀌었는가?
• 이 사건이 운영자의 공개 타임라인과 일치하는가?

2022년 6월의 사후 분석은 외부적으로 경험된 서비스 실패뿐 아니라 사이트 로컬 프리픽스와 내부 MCP 동작에 관한 것이다. 공개 컬렉터는 모든 관련 경로를 볼 수 없을 수 있다. 컬렉터는 비공개 정책 항, 라우터 후보 구성, 내부 관리 도달 가능성, Multimog 상태를 노출하지 않는다. 외부 신호의 부재가 비공개 시스템이 건강했다는 증명은 아니다.

이 한계를 외부 증거를 무시하는 데 쓰면 안 된다. 이것은 대조 작업을 정의한다. 운영자는 라우터 로그, 구성 커밋, 광고 경로 스냅샷, 능동 프로브 결과, 서비스 텔레메트리를 보관할 수 있다. 공개 컬렉터는 독립적인 계층을 제공한다. 신뢰할 수 있는 종결은 뷰들이 어디서 일치하고, 어디서 가시성이 다르며, 왜 그런지를 설명한다.

증거는 일관된 시계로 타임스탬프가 찍혀야 한다. 그렇지 않으면 라우팅 업데이트, 구성 커밋, 인시던트 선언, 되돌리기, 도달 가능성 프로브, 고객 오류가 순서가 어긋나 보일 수 있다. 시간 동기화와 불변 로그는 대응을 평가하는 데 필요한 순서를 보존하기 때문에 책임성 통제다.

영향 수치에는 자체적인 경계가 필요하다

Cloudflare는 19개 MCP 위치가 네트워크의 약 4%였지만 장애가 전체 요청의 50%에 영향을 주었다고 밝혔다. 회사는 요청 볼륨 그래프와 송신 대역폭 뷰도 공개했다. [1]

이 수치들은 고용량 사이트에 트래픽이 집중되었음을 보여준다. 인터넷 사용자의 절반, Cloudflare 고객의 절반, 또는 모든 웹사이트의 절반이 완전히 이용 불가능했다는 증명은 아니다. 요청 트래픽은 인구 수가 아니다. 일부 위치는 정상 운영을 계속했고, 고객 영향은 지리와 서비스 경로에 따라 달랐다.

책임 있는 영향 보고는 다음을 구분해야 한다:

• 실패한 요청.
• 지연되거나 재시도된 요청.
• 필요한 경로를 잃은 위치.
• 과부하가 걸린 클러스터.
• 영향받은 사이트에서 도달 불가능해진 고객 오리진.
• 영향받지 않은 위치에서 계속된 서비스.
• 첫 복구까지의 시간과 최종 되돌리기까지의 시간.
• 경로 복원 후의 잔여 오류.

공개 보고서는 이 차원들 중 몇몇에 대해 강한 정보를 제공하지만 고객별 완전한 목록은 제공하지 않는다. 이 글은 정밀성을 만들어 내서는 안 된다.

미래의 인시던트에서 운영자는 분모와 불확실성을 공개하여 정보 공개를 개선할 수 있다. 요청의 50%가 영향을 받았다면, 측정 구간, 성공 기준, 재시도 처리 방식, 지리, 그리고 수치에 다른 사이트로 옮겨진 트래픽이 포함되는지를 정의하라. 명확한 지표는 고객이 그 주장을 자신의 로그와 비교하게 한다.

책임성은 브랜드 노출이 아니라 통제를 따른다

Cloudflare는 경로 정책, 배포 절차, MCP 그룹화, 드라이런 범위, 동료 검토 자료, 관리 접근, 자동화, 롤백 협업을 통제했다. 사후 분석은 장애가 공격이 아니라 자사의 오류였음을 인정한다. [1] 이 사실들은 Cloudflare를 책임성 분석의 중심 운영자로 만든다.

그렇다고 모든 결과가 법적으로 귀속되거나 모든 엔지니어가 동등한 책임을 지는 것은 아니다. 공개 기록은 개인의 과실이나 과오를 입증하지 않는다. 거버넌스는 통제를 팀과 시스템에 매핑해야 한다:

• 네트워크 아키텍처 책임자는 MCP 역할과 고장 도메인을 정의했다.
• 정책 책임자는 내보내기 항과 커뮤니티 처리를 정의했다.
• 자동화 책임자는 구성을 렌더링하고 배포했다.
• 변경 책임자는 단계와 관찰 창을 선택했다.
• 검토자들은 제공된 증거를 평가했다.
• 인시던트 사령관이 복구를 조율했다.
• 장치 및 플랫폼 팀은 롤백과 commit-confirm 메커니즘을 제공했다.
• 서비스 팀은 오리진 도달 가능성, Multimog, 클러스터 부하, 고객 요청을 모니터링했다.
• 경영진은 허용 가능한 트래픽 집중과 변경 리스크를 정했다.

라우터 및 소프트웨어 벤더는 이용 가능한 안전 메커니즘에 영향을 주지만, Cloudflare의 공개 보고서는 항 재정렬을 벤더 결함으로 돌리지 않는다. 표준화 단체는 프로토콜 동작을 정의하지만 Cloudflare의 정책을 운영하지 않는다. 고객은 서비스에 의존했지만 내부 사이트 로컬 경로 구성을 통제하지 않았다.

고객에게도 여전히 의존성 아키텍처에 대한 책임이 있다. 공개 서비스가 하나의 CDN이나 권위 DNS 경로에 의존하는 조직은 그 의존성을 이해하고, 가능한 곳에서 대체 접근을 시험하고, 제공자에 도달할 수 없을 때의 커뮤니케이션을 정의해야 한다. 그 책임은 Cloudflare의 라우터에 대한 통제를 고객에게 이전시키지도, 모든 의존성을 회피 가능하게 만들지도 않는다.

규제자와 대형 구매자는 비공개 토폴로지를 처방하지 않고도 증거를 요청할 수 있다. 제공자가 아키텍처 대표적 카나리아, 경로 불변식, 독립 관리 접근, 직렬화된 롤백, 훈련을 사용하는지 물을 수 있다. 계약은 공개와 복구 증거를 정의할 수 있다. 보호된 검토가 목적을 달성할 때 민감한 구성을 공개적으로 요구하는 것은 피해야 한다.

실용적인 증거 팩

가장 강한 사후 종결은 동일한 오류가 재발할 수 없다는 보증이 아니다. 무엇이 바뀌었고 새 통제가 어떻게 작동하는지 보여주는 경계 지어진 팩이다.

이 팩은 기록과 운영 증명을 구분한다. 프리픽스 레지스트리는 고유성, 소유권, 역할, 예상 피어, 보안 메타데이터, 변경 이력을 보존하므로 유용하다. 그러나 패킷이 흐르게 만드는 권위는 아니다. 정책 시뮬레이션은 동작을 예측하므로 유용하다; 카나리아와 실시간 경로 상태는 여전히 관찰이 필요하다. 공개 사후 분석은 사건을 기술하므로 유용하다; 그러나 모든 이후 약속이 여전히 활성 상태임을 증명하지는 않는다.

민감한 세부 사항은 보호될 수 있다. 정확한 관리 주소, 자격 증명, 토폴로지, 라우터 구성은 공개되면 보안 리스크를 만들 수 있다. 독립 감사인, 규제자, 기밀 유지 하의 고객이 검토할 수 있다. 공개 공지는 통제 결과, 타임스탬프, 범위, 미해결 한계를 요약할 수 있다.

비교 경계가 중요하다

Cloudflare는 다른 라우팅 및 구성 인시던트를 경험한 바 있다. 그것들을 하나의 일반 장애로 취급하면 분석이 약화된다.

2019년 6월의 사건은 외부 경로 누수였다. 그것은 2022년의 MCP 스태징 실패가 아니다.

2020년 7월의 Cloudflare 장애는 라우터 규칙 장애였다. 그 직접 메커니즘은 2022년의 사이트 로컬 프리픽스 철회와 다르다.

2025년 3월의 사건은 결함 있는 ROA였다. 2022년의 경로는 내부 정책에 의해 철회되었고, 공개 기록은 결함 있는 ROA를 원인으로 기술하지 않는다.

Cloudflare의 2025년 기능 파일 실패는 BGP 내보내기 정책 사건이 아니었다.

이 사례들은 하나의 추상적 교훈을 공유한다: 작은 통제 입력이 글로벌 범위를 얻을 수 있다. 구체적인 증거와 수선은 다르다. 네트워크 책임성은 실제로 실패한 프로토콜, 계층, 권위, 전파 경로, 복구 경계를 명명하는 것을 요구한다.

공개 기록이 입증하지 않는 것

Cloudflare의 사후 분석은 상세하지만 당사자의 설명이다. 메커니즘과 타임라인에 대한 가장 강한 공개 출처를 제공하면서, 중요한 자료는 비공개로 남겨둔다.

공개 기록은 철회된 모든 프리픽스, 완전한 라우터 구성, 전체 변경 티켓, 검토자 의견, 자동화 코드, 비공개 토폴로지, 관리 접근 설계, 또는 모든 서비스 의존성을 공개하지 않는다. 모든 장치의 완전한 라우팅 정보 베이스나 포워딩 상태를 보여주지 않는다.

공개 트래픽 그래프는 영향받은 모든 고객, 사용자, 요청 유형, 오리진, 또는 재정적 결과를 식별하지 않는다. 이 글은 서비스 크레딧, 수익 손실, 규제 처벌, 계약 위반, 고객 과오를 추론하지 않는다.

사후 분석은 인시던트가 Cloudflare의 오류이고 공격이 아니라고 말한다. 악의적 의도, 은폐, 범죄 행위, 개인의 책임을 입증하지 않는다. 그것 자체로 법적 주의 의무 기준을 확립하지 않는다.

개선 조치 섹션은 계획된 및 즉시 작업을 기록한다. 모든 MCP 전용 카나리아, 정책 재설계, 스태거 자동화, commit-confirm 메커니즘이 오늘날에도 배포되고 효과적임을 증명하지 않는다. 현재 문서는 아키텍처와 통제를 설명할 수 있지만, 정확한 2022년 상태의 소급적 증명으로 취급되어서는 안 된다.

RIPE RIS와 BGPStream은 독립적인 라우팅 관찰을 제공할 수 있지만, 이용 가능한 공개 증거는 모든 사이트 로컬 철회의 완전한 컬렉터 재구성을 제공하지 않는다. 외부 가시성에는 한계가 있다.

이러한 미지의 것들은 책임성 분석을 막지 않는다. 증거 보유자가 답해야 할 질문을 정의하고, 이 글이 기술적 사후 분석을 근거 없는 고발로 바꾸지 않게 한다.

운영자, 이사회, 고객, 검토자를 위한 질문

네트워크 운영자는 물어야 한다:

• 어떤 경로 정책이 아키텍처나 라우터 역할에 따라 다른가?
• 드라이런이 영향받은 모든 역할을 렌더링하는가?
• 변경을 통해 계속 광고되어야 하는 프리픽스는 무엇인가?
• 필수 프리픽스 목록이 버전화되고, 소유되고, 서비스 의존성에 연결되어 있는가?
• 정책 시뮬레이터가 대표적인 경로 입력과 항 순서를 평가하는가?
• 첫 카나리아가 작고 아키텍처 대표적인가?
• 어떤 관찰 창과 자동 게이트가 진행을 멈추는가?
• 후보 정책이 일반 관리 경로를 제거한 후에도 운영자가 장치에 도달할 수 있는가?
• commit-confirm이 일관된 다중 장치 상태를 복원하는가?
• 인시던트 롤백 중 변경 권한은 누가 갖는가?
• 읽기 전용 팀이 구성을 변경하지 않고 경로와 서비스를 관찰할 수 있는가?

이사회와 리스크 위원회는 물어야 한다:

• 트래픽의 어느 비중이 가장 분주한 공통 통제 도메인에 의존하는가?
• 지리적 분산이 공유 정책이나 자동화 의존성을 숨기는가?
• 어떤 관리, 신원, DNS, 전원, 캐리어 의존성이 주 경로와 복구 경로에 공유되는가?
• 일회성 개선이 아니라 반복 훈련을 보여주는 증거는 무엇인가?
• 고객 영향 지표는 어떻게 정의되고 경로 및 서비스 증거와 대조되는가?

고객은 물어야 한다:

• 어떤 서비스가 Cloudflare의 도달 가능성, DNS, CDN, 보안, 접근, 또는 오리진 경로에 의존하는가?
• 제공자와 그 상태 경로가 손상되더라도 중요한 커뮤니케이션이 계속될 수 있는가?
• 대체 제공자나 직접 오리진 경로가 기술적·운영적으로 시험되었는가?
• 우회 또는 페일오버에서 어떤 보안 트레이드오프가 발생하는가?
• 전면 장애를 가정하지 않고 자사의 영향을 확립하는 로그는 무엇인가?

검토자와 감사인은 물어야 한다:

• 요청뿐 아니라 정확한 렌더링된 정책을 검토했는가?
• 카나리아가 MCP 토폴로지와 스파인 정책에 일치했는가?
• 사이트 로컬 및 관리 경로가 불변식에 포함되었는가?
• 독립 측정과 라우터 로그가 일치했는가?
• 두 엔지니어가 서로의 되돌리기를 덮어쓸 수 있었는가?
• 각 개선 조치 주장이 현재 시험 결과와 예외 기록에 연결되어 있는가?

이 질문들은 실패가 불가능하다고 가정하지 않는다. 알려진 라우팅 오류 클래스가 경계 지어지고, 관찰 가능하고, 복구 가능한지를 시험한다.

결론: 단계는 그것이 대표하는 시스템만큼만 좋다

Cloudflare의 2022년 6월 장애는 통제된 변경으로 시작했다. 변경은 티켓, 드라이런, 동료 검토, 여러 배포 단계를 거쳤다. 그럼에도 초기 단계 어느 것도 시험하지 않은 아키텍처에 도달하자 중요한 사이트 로컬 프리픽스를 철회했다. 철회는 서버와 오리진 도달 가능성을 끊고, 내부 부하 재분배를 비활성화하고, 작은 클러스터들을 과부하에 걸게 하고, 복구에 필요한 관리 경로를 손상시켰다. 동시에 이루어진 되돌리기들은 그 뒤 산발적 재발을 낳았다. [1]

이 사건은 BGP 변경 스태징을 책임성의 시험으로 만들었다. 어떤 단계도 다른 단계보다 먼저 온다는 이유만으로 증거가 아니다. 단계는 관련 토폴로지, 정책 역할, 소프트웨어, 경로 입력, 트래픽 집중, 관리 의존성을 대표해야 한다. 성공 기준에는 계속 가용해야 하는 경로와 서비스가 포함되어야 한다.

수선 모델은 구체적이다. 승인을 렌더링된 구성에 묶는다. 필수 프리픽스와 그 운영 역할의 정확한 대장을 유지한다. 정책 출력을 시뮬레이트한다. MCP 전용 카나리아를 사용한다. 광고, 포워딩, 오리진 연결성, 내부 로드밸런싱, 관리 접근을 관찰한다. 롤백을 commit-confirm과 하나의 권위 있는 변경 책임자로 보호한다. 가시성이 허용하는 곳에서 비공개 라우터 기록을 독립적인 공개 측정과 대조한다.

BGP 커뮤니티, RPKI, 경로 컬렉터, 티켓, 다이어그램은 모두 증거를 제공한다. 그러나 그중 어느 것도 실행 결과를 대체하지 못한다. 커뮤니티는 경로에 라벨을 붙인다; 정책 순서가 결정을 통제한다. RPKI는 오리진 승인을 검증한다; 가용성이나 내부 정책의 정확성을 증명하지는 않는다. 컬렉터는 선택된 외부 뷰를 관찰한다; 모든 비공개 의존성을 드러내지는 않는다. 티켓은 의도를 기록한다; 프리픽스의 광고를 유지하지는 않는다.

그것이 지속되는 교훈이다. 분산 네트워크는 대표적인 고장 상황에서 실행 중인 경로, 통제 정책, 관리 접근, 롤백 메커니즘이 서비스를 보존할 때 복원력을 갖는다. 증명은 프로세스의 이름이 아니다. 도달 가능하게 남은 경로, 배포를 멈춘 카나리아, 그리고 다른 팀이 되돌리지 않고 한 팀이 완료할 수 있었던 복구이다.

출처

1. Cloudflare, “Cloudflare outage on June 21, 2022”:https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/
2. Cloudflare, 2022 Impact Report:https://cf-assets.www.cloudflare.com/slt3lc6tev37/fBTOgkechN3IcaoT3kbA3/c9b74ee483d28c795d3c7891d8d36034/2022_Cloudflare_Impact_Report.pdf
3. Cloudflare, “Cloudflare Backbone: A Fast Lane on the Busy Internet Highway”:https://blog.cloudflare.com/cloudflare-backbone-internet-fast-lane/
4. Cloudflare, “The backbone behind Cloudflare’s Connectivity Cloud”:https://blog.cloudflare.com/backbone2024/
5. Cloudflare, “Load Balancing without Load Balancers”:https://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p/
6. Cloudflare, CDN Reference Architecture:https://developers.cloudflare.com/reference-architecture/architectures/cdn/
7. Cloudflare, IP addresses and anycast network:https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/
8. Cloudflare, Peering Policy:https://www.cloudflare.com/peering-policy/
9. PeeringDB, Cloudflare network record:https://www.peeringdb.com/net/4224
10. IETF / RFC Editor, RFC 4271, Border Gateway Protocol 4:https://www.rfc-editor.org/rfc/rfc4271
11. IETF / RFC Editor, RFC 1997, BGP Communities Attribute:https://www.rfc-editor.org/rfc/rfc1997
12. IETF / RFC Editor, RFC 8092, BGP Large Communities Attribute:https://www.rfc-editor.org/rfc/rfc8092
13. IETF / RFC Editor, RFC 8326, Graceful BGP Session Shutdown:https://www.rfc-editor.org/rfc/rfc8326
14. IETF / RFC Editor, RFC 7454, BGP Operations and Security:https://www.rfc-editor.org/rfc/rfc7454
15. IETF / RFC Editor, RFC 6811, BGP Prefix Origin Validation:https://www.rfc-editor.org/rfc/rfc6811
16. IETF / RFC Editor, RFC 6480, RPKI Architecture:https://www.rfc-editor.org/rfc/rfc6480
17. RIPE NCC, RIS Live Manual:https://ris-live.ripe.net/manual/
18. RIPE NCC, Routing Information Service:https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
19. CAIDA, BGPStream:https://bgpstream.caida.org/
20. Cloudflare, “What is BGP?”:https://www.cloudflare.com/learning/security/glossary/what-is-bgp/