data-center-infrastructure

1 개의 포스트

meta

불은 꺼지고 시스템은 켜진다: 즉각적인 정전 대비 태세 검증 (새 탭에서 열림)

Meta는 데이터센터의 무경고 전력 상실에 대비하기 위해 **Instantaneous PowerLoss Storm**이라는 새로운 재해 대응 테스트 체계를 도입했다. 기존 시스템에 방어 심층화 전략을 적용하고, 지역 전체의 전원을 실제로 차단하는 단계적 검증을 통해 서비스·데이터·시설의 복원력을 확인했다. 목표는 한 지역 전체의 전력 상실을 개별 장애 도메인 손실만큼 안정적으로 처리하는 것이다. ## 무경고 재해에 대비한 새로운 테스트 패러다임 - 기존의 허리케인, 산불, 전력·네트워크 장애 대응책은 사전 경보가 있을 때 효과적이다. - 그러나 순간적인 전력 상실처럼 전혀 예고되지 않는 재해는 기존 전략만으로 대응하기 어렵다. - Instantaneous PowerLoss Storm은 Meta의 기존 Disaster Readiness(재해 대비) “Storm” 프로그램에 추가된 최종 방어선이다. - 알려진 위험뿐 아니라 새롭게 등장하거나 아직 발견되지 않은 위험까지 검증 대상으로 삼는다. ## 데이터센터 전 계층에 적용한 방어 심층화 - 전력 상실 내성을 데이터센터의 전체 스택에 내장했다. - 기계·전기 설비 - 서버 랙 - 스토리지와 컴퓨트 - Twine 컨테이너 오케스트레이터 - 랙 전원이 끊겨도 배터리와 Power Loss Siren(PLS)을 이용해 메모리 데이터를 보존할 수 있도록 했다. - Twine 서비스 간에는 지역 전체에서 동작하는 비동기 신호 체계인 Unavailability Event(UE)를 구축했다. - 기존 기능은 단일 데이터센터의 장애 도메인에서 검증되어 있었지만, 여러 데이터센터가 연결된 지역 전체 장애에서는 다음 문제가 추가로 발생했다. - 장애 규모가 일반 장애 도메인보다 약 50~60배 큼 - 서비스 복제본 배치 문제 - 수백만 개 서비스의 동시 재시작과 자동 발견 - 전원이 꺼진 지역을 스스로 부팅해야 하는 문제 ## 전체 지역 부팅과 순환 의존성 문제 - Twine의 Scheduler, Allocator, Broker, Zelos 같은 제어 플레인 서비스는 다른 서비스를 시작하기 위한 필수 구성요소다. - 전체 지역이 동시에 부팅될 때 제어 플레인 서비스끼리 서로를 필요로 하는 순환 의존성, 즉 “ouroboros” 문제가 발생할 수 있다. - 이를 해결하기 위해: - 핵심 시작 의존성을 식별했다. - CI/CD에서 Belljar 테스트를 지속적으로 실행해 의존성 문제를 조기에 발견했다. - 예기치 않은 순환 의존성을 끊을 수 있도록 Twine recovery kit을 제공했다. - 이 복구 키트는 Twine 자체를 구동하는 서비스에 대한 “jumpstart” 역할을 한다. - Belljar, Twrko, recovery kit을 함께 사용해 지역 전체 부팅 시 발생할 수 있는 순환 의존성 위험을 줄였다. ## 제어 플레인을 종료시키는 ‘부메랑’ 문제 - UE는 서비스 종료와 복구를 조정하는 신호지만, 이 신호를 생성·전달하는 제어 플레인 자체가 UE에 의해 종료될 수 있었다. - 그러면 일부 서비스가 종료 신호를 받지 못한 채 고아 상태로 남을 수 있다. - 특정 서비스를 UE 전달 대상에서 제외하는 복잡한 방식 대신, 전력 관련 UE를 제어 플레인 서비스가 무시하도록 설계했다. - 단순한 예외 처리로 시스템 복잡도와 유지보수 부담을 낮췄다. ## 신뢰성과 개발 속도 사이의 절충 - 순간 장애에 완벽히 대응하려는 설계는 과도한 엔지니어링이나 정상 운영 중 오탐 위험을 만들 수 있다. - 따라서 반드시 방지해야 할 영향과 감수할 수 있는 영향을 구분했다. - 반드시 방지해야 하는 영향: - 스토리지·데이터베이스 데이터 손실 - 데이터센터 기계·전기 설비의 영구 손상 - 단일 지역을 넘어 지속되는 광범위한 장애 - 허용 가능한 영향: - 일시적인 서비스 오류 - 사전에 정한 한도 내의 랙 장애 - 서비스 라우팅 테이블의 제한된 최신성 저하 - 지역 장애 감지의 일시적인 지연 - 사후 복구가 어렵거나 합리적인 MTTR 내에 완화할 수 없는 문제를 허용 범위 밖으로 정의했다. ## 단계적 검증으로 위험과 폭발 반경 축소 - 전원을 직접 차단하는 테스트는 큰 위험을 동반하므로 점진적인 검증 방식을 택했다. - 검증 단계는 다음과 같다. - 신규·사전 운영 지역에서 의존성 등 독립적인 문제를 먼저 테스트 - 운영 지역을 복제한 shadow 지역에서 실험 - 가장 작고 새로운 운영 지역에서 실제 전력 차단 수행 - 이후 스토리지, AI, 데이터 웨어하우스가 위치한 대규모 운영 지역까지 확대 - 최종 단계의 전력 차단 훈련을 Instantaneous PowerLoss Storm이라고 명명했다. ## 실제 Storm 실행 방식 - 전체 지역에 전력 공급 장애를 주입해 즉시 전원을 차단한다. - 실제 장애처럼 보이도록 테스트 전에 선제적인 보호 조치를 최소화했다. - 현실적인 사고 상황의 MTTR을 반영한 뒤, 영향을 받은 지역을 전역 컨트롤러와 스케줄러에서 격리하는 “drain” 조치를 수행했다. - 반복적인 훈련을 통해 인프라와 엔지니어가 지역 전체 장애를 개별 장애 도메인 장애처럼 처리하도록 개선하고 있다. ## 실용적인 결론 대규모 인프라의 무경고 장애 대비에는 단일 복구 기능보다 시설부터 오케스트레이터까지 이어지는 방어 심층화가 중요하다. 특히 전체 시스템 부팅 시의 순환 의존성과 제어 플레인 보호를 사전에 검증하고, 작은 환경에서 시작해 실제 운영 지역으로 단계적으로 확대하는 방식이 안전성과 개발 속도를 함께 확보하는 현실적인 접근이다.