들어가며: '0초 통보' 재해에 대비하는 데이터센터의 현실
넷플릭스가 라이브 스트리밍을 확장하며 사람과 프로세스, 인프라의 삼박자를 강조한 것처럼, 메타(페이스북)의 데이터센터 운영도 동일한 철학을 공유합니다. 허리케인, 산불, 전력망 장애 등 예고 없는 재해는 데이터센터 인프라에 치명적입니다. 기존에는 몇 시간 전 경고를 받는 상황에 대한 대비책이 잘 갖춰져 있었지만, **'0초 통보' 재해(Instantaneous Power Loss)**는 완전히 다른 수준의 대비를 요구합니다.
메타는 이러한 문제를 해결하기 위해 Instant PowerLoss Storm이라는 새로운 테스트 패러다임을 도입했습니다. 이는 기존의 Disaster Readiness(DR) Storm 프로그램의 최종 방어선 역할을 하며, 알려진 위험뿐 아니라 예상치 못한 위험까지 처리할 수 있도록 설계되었습니다.
참고: 이 글은 메타 엔지니어링 블로그의 'Lights Out, Systems On: Validating Instant Power Loss Readiness' 포스트를 기반으로 재구성한 인사이트입니다. 원문 보기
방어 기법: Defense-in-Depth 전략의 실제
메타는 순간적인 전력 손실을 견딜 수 있는 능력을 데이터센터 스택 전체에 걸쳐 '처음부터' 설계했습니다. 기계·전기 설비부터 서버 랙, 스토리지, 컴퓨트, 그리고 핵심 오케스트레이터인 Twine까지 모든 계층이 전력 손실 내성을 갖추고 있었습니다.
핵심 메커니즘
- 배터리와 Power Loss Siren (PLS): 랙 전원이 끊겼을 때 인메모리 데이터를 유지하는 능력
- Unavailability Events (UE): Twine 서비스를 위한 비동기 신호 메커니즘으로, 리전 전체에 걸쳐 장애 발생을 전파
그러나 단일 DC 내의 단일 장애 도메인에서는 검증되었던 이 기능들이 전체 리전(Region) 시나리오에서는 새로운 취약점을 드러냈습니다. 특히 리전 규모가 일반 장애 도메인의 50~60배에 달하고, 복제본 배치 문제와 자율 부트스트래핑(Autonomous Bootstrapping) 문제가 핵심 난제였습니다.
부트스트래핑의 악몽: 순환 의존성과 '부메랑' 문제
메타의 Twine 오케스트레이터에는 Scheduler, Allocator, Broker, Zelos(코디네이터) 등 컨트롤 플레인 서비스들이 존재합니다. 이 서비스들이 없으면 리전 내 어떤 서비스도 실행할 수 없습니다. 평소에는 순환 의존성(Circular Dependency) 위험이 낮지만, 전체 리전을 부트스트래핑할 때는 치명적인 '닭과 달걀' 문제가 발생합니다.
메타는 이 문제를 Belljar라는 CI/CD 파이프라인 테스트를 통해 해결했습니다. Belljar는 컨트롤 플레인 서비스 간의 시작 의존성을 지속적으로 감지하고 제거합니다. 또한 만약의 경우를 대비해 Twine Recovery Kit (Twrko) 라는 전용 도구를 만들어 예상치 못한 순환 의존성을 강제로 끊을 수 있도록 했습니다.
또 다른 문제는 '부메랑' 효과였습니다. 장애 복구를 위해 사용되는 UE 신호가 정작 컨트롤 플레인 서비스 자체를 종료시켜 버리는 현상이었습니다. 메타는 이 문제를 컨트롤 플레인 서비스가 전력 관련 UE의 종료 신호를 '무시'하도록 하는 단순하고 지속 가능한 접근법으로 해결했습니다.
트레이드오프: 신뢰성 vs 성장 속도의 균형
완벽한 내성을 구축하는 것은 가능하지만, 이는 인프라에 과도한 엔지니어링 비용을 초래할 수 있습니다. 메타는 다음과 같은 트레이드오프를 설정했습니다.
| 반드시 피해야 할 영향 | 허용 가능한 위험 |
|---|---|
| 스토리지/DB 데이터 손실 | 일시적인 서비스 오류 |
| DC 시설(기계/전기) 영구 손상 | 사전 정의된 임계치 내 랙 장애 |
| 단일 리전을 넘는 지속적 영향 | 서비스 라우팅 테이블의 제한된 지연 |
국내 SI 환경에서의 적용 맥락: 국내 데이터센터 운영 환경에서는 특히 '허용 가능한 위험'의 기준을 명확히 설정하는 것이 중요합니다. 많은 기업들이 '무조건 100% 가용성'을 목표로 하지만, 이는 오히려 불필요한 비용과 복잡성을 초래할 수 있습니다. 메타의 접근법처럼 '무엇을 포기할 수 있는가'를 먼저 정의하는 것이 현명합니다.
검증: 실제 프로덕션 리전을 꺼보다
메타는 Instant PowerLoss Storm을 검증하기 위해 실제 대규모 프로덕션 리전의 전원을 차단했습니다. 이는 상당한 위험을 수반했지만, 체계적인 단계적 접근법을 통해 리스크를 관리했습니다.
- 신규/사전 프로덕션 리전에서 자체 문제 검증
- 섀도우 리전(프로덕션 복제) 에서 테스트
- 가장 작은 프로덕션 리전에서 제한된 폭발 반경으로 테스트
- 핵심 스토리지, AI, 데이터 웨어하우스 워크로드를 호스팅하는 대규모 리전 전원 차단
테스트는 실제 정전 상황을 재현하기 위해 사전 조치를 전혀 취하지 않았으며, MTTR(평균 복구 시간)도 실제 장애 시나리오와 동일하게 설정했습니다.
결론: 느리게 가는 것이 결국 빠른 길이다
메타의 Instant PowerLoss Storm은 단순한 테스트 그 이상입니다. 이는 인프라 전반에 걸친 아키텍처 개선을 이끌어냈고, 데이터센터 설계 혁신과 검증을 가능하게 하는 기반이 되었습니다. 메타는 '신뢰성과 속도는 동전의 양면'이라는 철학 아래, 빠른 성장을 위한 강력한 기반을 마련했습니다.
다음 단계 학습 방향:
- 데이터센터 장애 도메인(Fault Domain) 설계 패턴 학습
- Kubernetes 기반 오케스트레이터의 컨트롤 플레인 이중화 전략 연구
- 리전 단위 재해 복구(DR) 설계 패턴 (Active-Passive, Active-Active)
함께 보면 좋은 글:
- NVIDIA Nemotron 3 Nano Omni: 문서·영상·음성을 동시에 이해하는 오픈소스 멀티모달 모델 등장
- 넷플릭스가 라이브 스트리밍을 확장한 비결: 사람과 프로세스, 인프라의 삼박자
