피드로 돌아가기
InfoQInfrastructure
원문 읽기
GCP 계정 정지로 인한 8시간 전면 장애 및 Mesh Network 설계 변경
Google Cloud Suspends Railway's Production Account, Causing Eight-Hour Platform-Wide Outage
AI 요약
Context
GCP, AWS, Bare-metal을 혼합한 Mesh Network 구조였으나 Control Plane이 GCP에 집중된 Tight Coupling 구조의 한계 노출. Control Plane 장애 시 Edge Proxy의 Routing Table 캐시 만료에 따라 전체 리전 서비스가 불능 상태가 되는 Single Point of Failure(SPOF) 발생.
Technical Solution
- GCP를 Data Plane의 Hot Path에서 제외하여 Backup-only 상태로 강등
- AWS와 Bare-metal 전반으로 High-availability Database Shard 확장 배치
- 특정 Interconnect 장애 시에도 생존 경로를 통해 Routing Table을 갱신하는 Mesh Redesign 수행
- Provider-independent Mesh 아키텍처 구축을 통한 클라우드 계정 수준의 장애 격리
- 계정 정지 시에도 데이터 접근이 가능하도록 Database Backup 복구 경로 다변화
실천 포인트
- Control Plane과 Data Plane의 생명주기 및 의존성을 완전히 분리했는가? - 단일 클라우드 계정 정지 시 전체 시스템이 마비되는 'Blast Radius'가 설정되어 있는가? - 캐시 만료 후 Fallback 메커니즘이 없이 단순 Routing Table에만 의존하고 있지는 않은가? - Critical Path에서 특정 Vendor의 전용 서비스 의존도를 낮추고 추상화 계층을 두었는가?