요약

  • Cloudflare는 2023년 11월 2일부터 컨트롤 플레인과 분석 서비스가 중단되었지만, 핵심 엣지 트래픽은 계속 흐르고 있었다고 밝혔습니다 [1].
  • 공개된 발화 원인은 컨트롤 플레인의 핵심 의존성을 호스팅하던 오리건주의 데이터센터 PDX-04에서 발생한 일련의 전력 장애였습니다 [1][3].
  • 이번 장애는 Kafka, ClickHouse, 인증, 내부 도구, 그리고 서비스 복구나 관찰에 필요한 다른 시스템들의 숨겨진 의존성을 드러냈습니다 [1].
  • 2024년 같은 시설에서 발생한 두 번째 전력 장애는 Cloudflare의 Code Orange 대비를 실전 테스트한 사례였으며, 컨트롤 플레인에 미치는 영향을 줄였습니다 [2].
  • 설득력 있는 마무리는 구성, 분석, 신원 확인, 내부 도구, 고객에게 보이는 컨트롤 기능이 시설 전체 상실을 견딜 수 있음을 입증해야 합니다. 엣지가 캐시되었거나 이미 구성된 트래픽을 계속 처리한다는 것만으로는 부족합니다.

무슨 일이 있었나

Cloudflare의 2023년 11월 포스트모템에 따르면 장애는 11월 2일 11:43 UTC에 시작되었습니다. 회사는 영향받은 계층을 컨트롤 플레인과 분석 서비스로 규정했습니다. 즉, 분산된 엣지가 새로운 컨트롤 플레인 판단이 필요 없는 트래픽을 계속 처리하는 동안에도 고객과 운영자는 설정 변경, 분석 확인, 관리 기능 사용에서 문제를 겪을 수 있었습니다 [1].

물리적 시작점은 오리건주의 PDX-04였습니다. Cloudflare에 따르면 Portland General Electric이 건물로 들어오는 독립 전력 피드 하나에 영향을 미치는 계획되지 않은 정비 작업을 진행했습니다. 이어서 회사는 유틸리티 피드, 배터리, 발전기, 건물 접근, 회로 차단기 교체, 서버의 단계적 복구를 포함한 일련의 과정을 설명했습니다 [1]. Baxtel의 공개 보고서 역시 이 중단을 오리건주 힐즈보로의 Flexential 데이터센터 전력 장애와 연관된 것으로 확인하며, 유틸리티 피드 사건에 대한 동일한 Cloudflare 설명을 인용했습니다 [3].

독자 수준에서 중요한 점은 단순합니다. 컨트롤 계층이 손상된 상태에서도 인터넷 엣지는 살아 있을 수 있습니다. 기존 경로, 캐시, 이미 배포된 구성은 계속 작동할 수 있습니다. 그러나 정책 변경, 분석 검토, 보안 조정, 복구 확인이 필요한 고객은 엣지 뒤에 있는 시스템에 의존합니다. 그런 시스템이 한 시설의 숨겨진 의존성 뒤에 놓여 있다면, 서비스에는 연속성 공백이 존재하는 것입니다.

숨겨진 의존성은 단일 기계가 아니었다

포스트모템은 단일 서버 장애를 묘사하지 않습니다. 의존성의 생태계를 묘사합니다. Cloudflare는 컨트롤 플레인과 분석 구성 요소, 내부 운영 도구, Kafka, ClickHouse, 신원 및 권한 부여 의존성, 그리고 서비스를 재시작하거나 재구축하는 데 필요한 시스템들을 언급했습니다 [1]. 일부 의존성은 이해되고 있었습니다. 다른 일부는 시설이 장애를 겪기 전까지 완전히 보이지 않았습니다.

이 때문에 이 사건은 일반적인 클라우드 장애 보도가 아니라 네트워크 인프라 책임성의 범주에 들어갑니다. 컨트롤 플레인은 네트워크 운영자의 권한 표면입니다. 변경이 실행 구성이 되는 지점, 경고가 운영 조치가 되는 지점, 고객이 보안 또는 라우팅 상태가 정상인지 확인하는 지점이 바로 여기입니다. 그 계층이 하나의 시설에 의존하면서 전면 상실 조건에서 테스트되지 않았다면, 공개된 위험은 단순한 다운타임이 아니라 운영 가시성과 변경 권한의 상실입니다.

포스트모템은 또한 무엇이 작동했고 무엇이 작동하지 않았는지를 분리합니다. Cloudflare는 네트워크가 대부분의 고객 트래픽을 계속 처리했다고 밝혔습니다. 이를 "장애는 사소했다"로 축소해서는 안 됩니다. 데이터 플레인은 회복 탄력적처럼 보이지만 컨트롤 플레인은 취약할 수 있다는 분열된 책임성 문제를 보여줍니다. 성숙한 사후 테스트는 두 계층을 각각 따로 검사해야 합니다.

재해 복구는 실행 코드 테스트다

Cloudflare는 재해 복구 계획을 가지고 있었다고 밝혔지만, 이 사건은 일부 서비스가 아직 시설 전면 상실에 대비하지 못했고 일부 절차가 올바른 조건에서 테스트되지 않았음을 보여주었습니다 [1]. 종이 위의 계획은 백업 위치를 명명할 수 있습니다. 실행 코드가 구성, 자격 증명, 데이터 복제, 큐, 대시보드, 내부 도구가 실제로 제시간에 재시작되는지를 결정합니다.

복구에는 수요 문제도 있었습니다. 서비스가 돌아오기 시작하면 사용자와 내부 시스템이 한꺼번에 재접속, 갱신, 재시도하면서 뇌관 소떼(thundering herd)를 만들 수 있습니다. 이는 컨트롤 플레인 용량 문제입니다. 대기 시스템이 시작되는 것만으로는 충분하지 않습니다. 백로그를 흡수하고, 정확성을 유지하고, 복구 자체가 두 번째 장애가 되지 않도록 해야 합니다 [1].

2024년 후속 보고는 공개 비교 자료를 제공한다는 점에서 유용합니다. Cloudflare에 따르면 같은 시설에서 4개월 뒤 또 다른 대규모 전력 장애가 발생했습니다. 이번에는 회사가 준비된 내부 인시던트 태세인 Code Orange를 가동했고, 이전의 변경 사항이 고객 영향을 줄였다고 보고했습니다 [2]. 이것이 모든 의존성이 해결되었다는 증명은 아닙니다. 유사한 장애가 발생했고, 운영자가 변경을 해두었으며, 두 번째 결과가 실질적으로 달랐다는 올바른 증거 패턴을 보여줍니다.

클라우드 서비스에서도 물리적 소유권은 여전히 중요하다

흔한 실수는 클라우드 컨트롤 플레인을 추상적인 소프트웨어로 취급하는 것입니다. PDX 사건은 물리적 소유권이 여전히 중요함을 보여줍니다. 공개 기록에는 유틸리티 피드, 발전기 작동, 배터리 방전, 건물 접근, 시설 통신, 회로 차단기, 서버 재시작 순서가 포함됩니다 [1][3]. 이런 세부 사항은 API 아래에 있지만 고객 결과 위에 있습니다.

제3자 시설 의존성이 자동으로 실패는 아닙니다. 대형 네트워크는 규모와 도달 범위 때문에 콜로케이션과 클라우드 유사 운영 모델을 사용합니다. 책임성의 질문은 시설 소유자, 유틸리티 공급자, 계약자 또는 물리적 접근 규칙이 복구 경로의 일부가 될 때 운영자가 무엇을 입증할 수 있는가입니다. 의존성은 고객 대면 서비스가 그 의존성이 실패하거나 느려져도 견딜 수 있을 만큼 명시적이어야 합니다.

Baxtel의 보고서는 이 사건을 데이터센터 운영자 맥락에 놓고, 유틸리티 시나리오와 그리드 지원 협정에 관한 Flexential의 공개 응답을 포함한다는 점에서 중요합니다 [3]. 이 글은 그 응답을 완전한 근본 원인 판정으로 과장해서는 안 됩니다. Cloudflare의 복구 체인이 조직 경계를 넘었다는 사실을 보여줄 뿐이며, 바로 그 지점에서 책임 기록이 흐려지기 쉽습니다.

교리 표면은 운영 연속성이다

Heng.lu의 표면은 운영자 연속성과 호스팅/네트워크 신원입니다. 디렉터리나 공개 상태 페이지는 Cloudflare를 운영자로, PDX-04를 시설 의존성으로 식별할 수 있습니다. 그런 기록은 컨트롤 플레인 상태, 자격 증명, 분석 데이터, 내부 도구가 시설 전면 상실을 견딜 수 있음을 증명하지 않습니다. 현실 계층은 실행 중인 복구 증거입니다.

이 구분은 이 글을 비극 극장에서 멀리 유지합니다. 질문은 Cloudflare, Flexential 또는 유틸리티를 고립시켜 수사적으로 비난해야 하는가가 아닙니다. 질문은 어떤 의존성이 임계 경로에 놓이도록 허용되었는지, 운영자가 장애 전에 그것을 알았는지, 그리고 어떤 테스트가 이제 동일한 의존성이 컨트롤 권한을 다시 마비시킬 수 없음을 증명하는가입니다.

네트워크 관점에서 노출된 표면은 구성 연속성입니다. 고객은 서비스를 구매하는 이유의 일부가 이상 조건에서도 정책을 변경할 수 있기 때문입니다. 보안 규칙, DNS 설정, 분석 쿼리, 터널 제어 또는 접근 정책 변경은 인시던트 중에 가장 중요할 수 있습니다. 고객이 가장 필요로 하는 순간에 컨트롤 플레인이 손상된다면, 회복 탄력성 주장은 전체 엣지 용량보다 더 구체적이어야 합니다.

설득력 있는 재발 테스트에 포함될 내용

첫째, 컨트롤 플레인 구성 요소를 호스팅하는 시설의 전면 상실을 시뮬레이션하십시오. 단일 서비스를 종료하는 것만으로는 부족합니다. 시설 수준의 가정을 제거하십시오. 로컬 네트워크, 스토리지, 큐잉, 신원 확인, 대시보드, 물리적 접근 모두입니다. 어떤 시스템이 계속되고, 어떤 시스템이 페일오버하고, 어떤 시스템이 저하 모드에 들어가고, 어떤 시스템에 수동 작업이 필요한지 기록하십시오.

둘째, 장애가 활성화된 동안 고객에게 보이는 컨트롤 경로를 테스트하십시오. 고객이 DNS나 보안 구성을 변경하고, 분석을 보고, 접근 정책을 수정하고, 자격 증명을 교체하고, 상태를 확인할 수 있습니까? 일부 기능이 의도적으로 사용 불가하다면, 상태 페이지와 제품 문서가 그것을 명확히 말해야 합니다.

셋째, 백로그 상태에서 복구를 측정하십시오. 조용한 트래픽에는 작동하는 대기 컨트롤 플레인도 모든 사용자와 내부 작업이 동시에 재시도하면 실패할 수 있습니다. 테스트는 재시작 동안의 큐 깊이, 재접속률, 인증 부하, 데이터베이스 복제 지연, 대시보드 지연 시간, 오류 예산을 포함해야 합니다.

넷째, 시설 의존성 기록을 최신 상태로 유지하십시오. 제3자 운영자, 유틸리티 피드 가정, 원격 핸즈 경로, 공개 가능한 범위 내에서 회로 차단기 또는 발전기 의존성, 그리고 대체 계획을 가동할 권한을 가진 사람이나 팀을 명명하십시오. 기밀 세부 사항은 보호될 수 있지만, 컨트롤 소유자와 테스트 결과는 보이지 않아서는 안 됩니다.

마지막으로, 다음 인시던트를 이번 인시던트와 비교하십시오. 2024년 Code Orange 보고는 유사한 물리적 사건을 변경된 대응과 감소된 영향에 연결하기 때문에 유용한 모델입니다 [2]. 이후의 모든 재발은 같은 방식으로 판단되어야 합니다. 어떤 이전 교훈이 테스트되었고, 어떤 컨트롤이 유지되었고, 어떤 새로운 의존성이 나타났으며, 고객이 여전히 무엇을 할 수 있었는가.

앞으로 지켜볼 것

Cloudflare가 공개 인시던트 보고에서 엣지 데이터 플레인 건강 상태를 컨트롤 플레인과 분석 건강 상태와 분리해 유지하는지 지켜보십시오. 고객이 구성을 변경하거나 관찰할 수 없다면, 글로벌 트래픽에 대한 단일 녹색 상태만으로는 충분하지 않습니다. 개별 서비스 이중화뿐 아니라 시설 전면 상실에 관한 언어에도 주목하십시오.

또한 Code Orange가 반복 가능한 공개 증거 패턴이 되는지 지켜보십시오. 2024년 3월 사건은 회사가 2023년 11월 이후 대비를 개선했음을 시사합니다 [2]. 더 강한 신호는 구성, 분석, 내부 도구, 고객 대면 컨트롤 기능이 PDX-04 또는 어떤 단일 시설과 무관하게 페일오버한다는 것을 보여주는 꾸준한 훈련과 인시던트 기록입니다.

지속되는 교훈은 클라우드 네트워크가 권한 계층이 손상된 상태에서도 트래픽을 계속 실어 나를 수 있다는 것입니다. 책임성이란, 중요한 건물이 어두워졌을 때 운영자가 여전히 서비스를 보고, 변경하고, 재시작하고, 설명할 수 있음을 증명하는 것을 의미합니다.

출처

  1. https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/
  2. https://blog.cloudflare.com/major-data-center-power-failure-again-cloudflare-code-orange-tested/
  3. https://baxtel.com/news/cloudflare-blames-flexential-dc-outage-for-its-service-disruption