다음은 우리가 작성할 필요가 없을 것으로 생각했던 게시 글입니다. 저희 주요 데이터 센터에서 정전이 발생한 지 5개월도 채 지나지 않아서 똑같은 데이터 센터에서 사고가 다시 발생했습니다. 실망스러운 일이며, 독자 여러분이 "그 시설을 왜 계속 이용할까?"라고 생각한다 해도 여러분을 비난할 생각은 없습니다. Cloudflare에서도 그렇게 생각하고 있으니까요. 한 가지 유의하실 것은, 해당 데이터 센터에서는 많은 것이 바뀌지 않았을 수도 있지만, Cloudflare에서는 그 5개월 동안 많은 것이 바뀌었다는 점입니다. 5개월 전에는 그 주요 데이터 센터가 오프라인 상태가 되자 매우 뼈아팠지만, 이번에는 그렇게 많이 고통스럽지는 않았습니다.
이 글은 5개월만에 고가용성 데이터 센터의 두 번째 정전이 발생했던 과정에 대한 간략한 설명입니다. 하지만 그보다는, 중요한 데이터 센터 하나에서 정전이 발생하더라도 고객에게 영향이 미치지 않도록 Cloudflare 팀에서 어떻게 노력했는지에 대한 이야기라는 게 더 어울리겠습니다.
2023년 11월 2일, 오리건주 포틀랜드에 있는 Cloudflare의 중요 시설 중 하나가 상당 기간 정전이 되었습니다. 정전은 전력망 공급자의 유지보수로 인해 발생한 것으로 보이는 연쇄적인 오류로 인해 발생했고, 시설의 접지 오류로 절정에 달했으며, 일련의 불운한 사건으로 인해 시설이 적시에 온라인 상태로 회복되지 못하면서 상황이 더욱 악화되었습니다.
다사다난했던 세부 정보를 모두 읽고 싶으시면 여기에서 확인하실 수 있습니다.
데이터 센터의 완전 정전이 발생하는 건 고통스러운 일이지만, 예상 밖의 일은 아닙니다. 불행히도 그렇게 예상했음에도 불구하고, 우리는 큰 장애를 겪더라도 제품이 계속 작동하도록 하는 몇 가지 요건을 제품에 적용하지 못했습니다.
그 실수는 우리가 두 번 다시 일어나도록 허용하고 싶지 않은 실수였습니다.
코드 오렌지
이 사건은 아주 뼈아팠으므로 우리는 코드 오렌지라고 명명했던 경보를 선포했습니다. 저희는 비즈니스에 실체적 위협이 발생하면 코드 옐로우 또는 코드 레드를 선언하는 것으로 알려진 Google의 사례에서 아이디어를 차용했습니다. 저희 로고가 오렌지색이므로 명칭을 약간 변경했습니다.
Cloudflare 코드 오렌지의 개념은 사고 대응을 주도하는 사람(이 경우에는 기술 운영 담당 수석 부사장 Jeremy Hartman)에게 자신이 우선순위가 높다고 생각하는 프로젝트를 수행하도록 팀의 어느 엔지니어에게 업무를 배당하는 권한을 부여하는 것이었습니다. (코드 레드를 선포하지 않는 한. 실제로 저희는 해킹 사고로 인해 코드 레드를 선포했고, 그 경우 더 높은 우선 순위가 되어야 했습니다. 관심이 있으시면 여기에서 자세한 내용을 읽어 보실 수 있습니다.)
즉각적인 사고를 처리한 후 Jeremy는 주요 데이터 센터 시설에 또 다른 치명적인 오류가 발생하는 경우에도 가용성을 높이기 위해 수행해야 하는 가장 중요한 작업을 신속하게 분류했습니다. 그리고 팀에서는 작업을 시작했습니다.
우리는 어떻게 했을까요?
이렇게 광범위한 실제 테스트가 이렇게 빨리 진행될 줄은 몰랐지만, 우주는 신비로운 방식으로 돌아갑니다. 최초 사고가 발생한 지 5개월이 채 되지 않은 2024년 3월 26일 화요일, 같은 시설에서 또 한 번의 대규모 정전이 발생했습니다. 아래에서 이번에 정전이 발생한 원인에 대해 자세히 살펴보겠지만, 가장 중요한 것은 이로 인해 저희 팀에서 코드 오렌지에서 수행했던 작업에 대한 완벽한 테스트를 할 수 있었다는 사실입니다. 결과는 어땠을까요?
먼저 Cloudflare의 포틀랜드 데이터 센터가 어떤 기능을 하는지 살펴보겠습니다. 2023년 11월 2일게시물에서 설명한 바와 같이 Cloudflare의 제어판은 주로 웹 사이트, API 등 모든 서비스에 대한 고객 대면 인터페이스로 구성됩니다. 또한, Analytics 및 Logging 파이프라인을 제공하는 기본 서비스도 주로 이러한 시설에서 제공됩니다.
2023년 11월과 마찬가지로 저희는 PDX01 데이터 센터와의 연결이 끊겼다는 알림을 즉시 받았습니다. 11월과는 달리 저희는 다시 한 번 정전이 발생했음을 확실히 인지했으며, 5개월 전과 똑같은 상황에 처했습니다. 또한 2월에 성공리에 수행한 내부 테스트 결과에 따라 시스템에서 어떻게 대응해야 하는지도 알고 있었습니다. 저희는 여러 달에 걸쳐 수많은 시스템을 준비하고 업데이트했고, 엄청난 수의 네트워크와 서버를 활성화했으며, 작업이 의도한 효과를 발휘하고 있는지 확인하는 테스트를 마쳤고, 이 경우에는 이중화 시설로의 자동 장애 조치가 이루어졌습니다.
당사의 제어판은 수백 개의 내부 서비스로 구성되어 있고, 포틀랜드에 있는 3개의 중요 데이터 센터 중 하나가 손실되더라도 나머지 두 시설에서 이러한 서비스가 계속 정상적으로 운영될 것으로 예상하고 있으며, 주로 포틀랜드에서 계속 운영하고 있습니다. 포틀랜드 센터를 완전히 사용할 수 없을 경우 유럽 데이터 센터로 장애 조치를 취할 수 있는 역량이 있습니다. 하지만 그건 부차적인 옵션이며, Cloudflare에서 즉시 추구하는 옵션은 아닙니다.
2024년 3월 26일 14:58(UTC)에 PDX01의 전원이 끊기고 Cloudflare의 시스템이 작동하기 시작했습니다. 15:05(UTC)이 되자, API와 대시보드는 사람의 개입 없이 정상적으로 작동했습니다. 지난 몇 달 동안 Cloudflare에서는 유사한 중단이 발생하더라도 고객이 Cloudflare 서비스를 구성하고 운영할 수 있도록 하는 데 중점을 두었습니다. 사람의 개입이 필요한 특정 서비스가 몇 가지 있어서 복구하는 데 조금 더 오래 걸렸지만, 기본 인터페이스 메커니즘은 예상대로 작동했습니다.
그 점을 좀 더 자세히 이야기하자면, 2023년 11월 2일 사고가 발생한 동안 다음 서비스들의 경우 제어판에서 6시간 이상 다운타임이 발생했으며, 그 중 몇 가지 서비스는 며칠 동안 기능이 저하되었습니다.
API 및 대시보드
Zero Trust
Magic Transit
SSL
SSL for SaaS
Workers
KV
대기실
부하 분산
Zero Trust 게이트웨이
Access
Pages
Stream
Images
2024년 3월 26일 사고의 경우 정전 후 몇 분 이내에 이 모든 서비스가 가동되었으며, 그 중 많은 서비스는 장애 조치 도중에도 전혀 영향을 받지 않았습니다.
Cloudflare 고객이 전 세계 300여 개의 도시에 있는 Cloudflare 데이터 센터를 거치는 트래픽을 처리하는 데이터 영역은 영향을 받지 않았습니다.
고객 트래픽을 확인할 수 있는 Cloudflare Analytics 플랫폼은 영향을 받았으며 당일 늦은 시간이 되어서야 완전히 복구되었습니다. Analytics 플랫폼에서 PDX01 데이터 센터에 의존하므로 이는 예상된 동작이었습니다. 제어판 작업과 마찬가지로 저희는 2023년 11월 2일 사고 직후부터 새로운 Analytics 용량을 구축하기 시작했습니다. 그러나 작업의 규모로 인해 완료하는 데 조금 더 많은 시간이 걸릴 것입니다. Cloudflare에서는 이 종속성을 제거하기 위해 최대한 빠르게 작업하고 있으며, 가까운 시일 내에 이 작업을 완료할 수 있을 것으로 예상합니다.
제어판 서비스의 기능을 검증한 후에도, 저희는 또 다시 매우 규모가 큰 데이터 센터의 콜드 스타트 문제에 봉착했습니다. 이 작업은 2023년 11월에는 약 72시간이 걸렸지만, 이번에는 약 10시간 만에 완료할 수 있었습니다. 향후에도 이 과정을 더욱 빠르게 진행할 수 있도록 해야 할 일이 남아 있으며, 향후 비슷한 사고가 발생할 경우에 대비해 절차를 계속 개선해 나갈 계획입니다.
여기에 어떻게 도달했을까요?
앞서 언급한 바와 같이, 저희는 작년 11월에 정전 사고를 겪은 후, 중요한 사건이나 위기가 발생할 때 엔지니어링 리소스의 대부분 또는 전부를 해당 문제 해결에 투입하는 프로세스인 코드 오렌지를 도입하게 되었습니다. 지난 5개월 동안 저희는 제어판의 높은 신뢰성을 보장하는 데 집중하도록 핵심적이지 않은 엔지니어링 기능을 모두 전환했습니다.
엔지니어링 부서 전체에 걸쳐 모든 팀이 힘을 모아 향후에 비슷한 장애가 발생할 경우 시스템의 복원력을 갖출 수 있도록 했습니다. 2024년 3월 26일의 사고는 예상치 못한 상황이었지만, Cloudflare에서는 나름 준비하고 있었습니다.
가장 확실한 차이점은 제어판과 API의 서비스를 복구하는 속도입니다. 사람의 개입 없이도 PDX01이 손실되고 7분이 지나서 Cloudflare 구성에 로그인하고 변경하는 것이 가능했습니다. 이는 모든 구성 데이터베이스를 고가용성(HA) 토폴로지로 이동시키고 용량 손실을 흡수할 수 있을 만큼 충분한 용량을 사전에 프로비저닝하려는 노력 덕분입니다. 20여 개의 서로 다른 데이터베이스 클러스터에 걸쳐 있는 100여 개의 데이터베이스가 영향을 받은 시설에서 동시에 장애가 발생하자 자동으로 서비스를 복구했습니다. 이 결과는 실제로 1년여에 걸친 작업의 정점이었으며, 우리는 주간 테스트를 통해 적절한 장애 조치 능력을 입증하고 있습니다.
또 하나의 중요한 개선 사항은 Logpush 인프라에 대한 업데이트입니다. 2023년 11월에는 PDX01 데이터 센터가 손실되어 로그를 고객에게 푸시할 수 없게 되었습니다. 코드 오렌지 기간에, 저희는 포틀랜드에 Logpush 인프라를 HA로 만드는 데 투자했으며, 암스테르담에 추가로 능동적 장애 조치 옵션을 마련했습니다. Logpush는 모든 포틀랜드 시설에 걸쳐 대규모로 확장된 Kubernetes 클러스터를 활용하여 서비스 소유자가 복원력이 내장된 HA 준수 서비스를 배포할 수 있는 원활한 방법을 제공합니다. 실제로 2월의 혼란스러운 훈련 중에 포틀랜드 HA 배포에서 결함을 발견했지만, Amsterdam Logpush 인프라에서 성공적으로 인계받았으므로 고객에게는 영향이 없었습니다. 이 이벤트를 진행하는 동안 저희는 그 이후 수정해온 사항이 효과가 있음을 확인했고 포틀랜드 지역의 로그를 푸시할 수 있었습니다.
그 밖에 Stream 및 Zero Trust 제품에 대하여 여러 가지 개선 사항을 마련했지만, 해당 제품 운영에는 거의 영향이 없었습니다. 동영상을 트랜스코딩하는 데 많은 컴퓨팅 리소스를 사용하는 Cloudflare의 Stream 제품은 암스테르담 시설로 원활하게 인계되어 운영을 계속할 수 있었습니다. 팀에게는 서비스에 대한 구체적인 가용성 목표가 주어졌고 이러한 목표를 달성하기 위한 여러 옵션이 제공되었습니다. Stream은 다른 복원력 아키텍처를 선택했지만 이번 중단 상황에서 원활하게 서비스를 제공할 수 있었던 서비스의 좋은 예입니다. 역시 2023년 11월에 영향을 받았던 Zero Trust도 수백 개의 데이터 센터로 대부분 기능을 이전했으며, 덕분에 이번 이벤트 내내 원활하게 작동했습니다.전 세계 300여 개의 도시에 있는 데이터 센터에서 최고 수준의 가용성을 제공하므로, 이것이 저희가 모든 Cloudflare 제품에서 채택하도록 추진하는 궁극적인 전략입니다.
데이터 센터의 전력은 어떻게 됐을까요?
2024년 3월 26일 14:58(UTC), PDX01에서는 Cloudflare의 모든 케이지에 서비스를 제공하는 Flexential에서 소유하고 운영하는 배전반 4개가 동시에 고장나면서, Cloudflare의 물리적 인프라 전원이 완전히 끊겼습니다. 이는 기본 및 이중화 전력 경로가 전체 환경에 걸쳐 모두 비활성화되었음을 의미했습니다. Flexential을 조사하는 동안 엔지니어들은 회로 스위치 보드(CSB)로 알려진 장비 세트에 초점을 맞추었습니다. CSB는 주 입력 회로 차단기와 일련의 더 작은 출력 차단기로 구성된 전기 분전반에 비유할 수 있습니다. Flexential의 엔지니어들은 CSB의 업스트림 인프라(급전, 발전기, UPS, PDU/변압기)는 영향을 받지 않고 계속 정상적으로 작동했다고 보고했습니다. 마찬가지로 원격 전력반 및 연결된 스위치기어 등 CSB로부터의 다운스트림 인프라는 영향을 받지 않았으므로, 중단이 CSB 자체에서만 발생했음을 의미합니다.
Flexential의 CSB 장애의 근본 원인에 대한 초기 평가에서는 4개의 CSB 내에서 차단기 조정 설정이 잘못된 것이 하나의 원인으로 지목되었습니다. 트립을 너무 제한적으로 설정하면 과전압 보호가 과도하게 민감해지고 장치에 잠재적으로 성가신 트립이 초래될 수 있습니다. 저희 경우에는, 4개의 CSB 내 Flexential의 차단기 설정이 다운스트림에서 프로비저닝된 전력 용량에 비해 너무 낮은 것으로 보고된 바 있습니다. 이들 차단기 중 하나 이상이 트립되면 나머지 활성 CSB 보드에 연쇄 장애가 발생하여 Cloudflare의 케이지와 공유 인프라의 다른 보드에 공급되는 전원이 완전히 손실되었습니다. 우리는 사고를 분류하는 동안 Flexential 시설 팀에서 트립 설정이 잘못된 것을 발견하여 CSB를 재설정하고 이를 예상 값으로 조정하여 단계적이고 제어된 방식으로 서버의 전원을 켤 수 있었다는 이야기를 들었습니다. 저희는 이러한 설정이 언제 이루어졌는지는 알지 못하지만, 일반적으로 이러한 설정은 데이터 센터 시운전 프로세스 및/또는 차단기 조정 연구의 일환으로 고객의 중요 부하를 설치하기 전에 설정/조정됩니다.
다음은?
저희 최우선 과제는 Analytics 플랫폼을 위한 복원 프로그램을 완료하는 것입니다. Analytics는 단순히 대시보드에 표시되는 멋진 차트가 아닙니다. 공격의 상태, 방화벽에서 차단되고 있는 활동, 심지어 Cloudflare Tunnel의 상태도 확인하려면 분석이 필요합니다. 저희가 채택한 복원력 패턴이 예상대로 작동한다는 증거가 있으므로 이에 계속 중점을 두며 최대한 빨리 진행할 계획입니다.
제대로 복구하려면 여전히 수동 개입이 필요한 일부 서비스가 있었으며, 저희는 추가적인 수동 조치가 필요하지 않도록 각각에 대한 데이터와 작업 항목을 수집했습니다. 이러한 모든 변경 사항과 개선 사항을 통해 고객이 기대하는 복원력을 제공한다는 것을 증명하기 위해 계속해서 프로덕션 컷 테스트(production cut test)를 이용할 예정입니다.
저희는 Flexential의 후속 활동에 계속 협력하면서 가능한 한도까지 Flexential의 운영 및 검토 절차에 대한 이해를 넓혀 갈 계획입니다. 이 사고는 단일 시설로 제한되었지만, Cloudflare에서는 이번 사태를 계기로 중요한 모든 데이터 센터 시설에서 유사한 보기를 확보할 수 있는 프로세스로 전환하려 합니다.
다시 한 번, Analytics Engine을 이용하시는 고객, 특히 사고 발생 기간 중 해당 제품 기능에 액세스할 수 없었던 고객 여러분께 끼친 영향에 대해 사과의 말씀을 전합니다. Cloudflare에서는 지난 4개월 동안 기대한 만큼의 성과를 거두었으며, 남은 과제를 마무리하는 데 계속 집중하겠습니다.