연쇄적 장애: Railway의 GCP 계정 정지 사례를 통한 교훈
2026년 5월 19일, Railway는 약 8시간 동안 지속된 파괴적인 플랫폼 전반의 서비스 중단 사태를 겪었습니다. Google Cloud Platform (GCP)의 자동 계정 정지로 시작된 이 사건은 GCP에 호스팅된 인프라뿐만 아니라 AWS 및 Railway 자체 베어메탈 서버에서 실행되는 워크로드에까지 영향을 미치는 완전한 장애로 빠르게 확산되었습니다.
이 사건은 클라우드 아키텍처의 중요한 사례 연구로서, "resilient"한 멀티 클라우드 전략이 어떻게 서로 다른 환경에 걸쳐 연쇄적인 붕괴를 일으키는 단일 장애점(single point of failure)을 가질 수 있는지를 보여줍니다.
장애의 구조
UTC 기준 22:20에 Google Cloud는 자동화된 조치를 통해 Railway의 운영 계정을 잘못된 상태로 정지시켰습니다. 그 영향은 즉각적이었습니다. GCP에 호스팅된 Railway Dashboard, API, 그리고 핵심 네트워크 인프라의 주요 구성 요소들이 모두 오프라인 상태가 되었습니다.
Railway는 하이브리드 인프라(Metal, AWS, GCP)를 활용하고 있지만, 아키텍처에는 숨겨진 치명적인 의존성이 있었습니다. 다양한 워크로드로 트래픽을 라우팅하는 에지 프록시(edge proxies)는 라우팅 테이블을 채우기 위해 GCP에 호스팅된 네트워크 제어 평면(network control plane) API에 의존하고 있었습니다.
연쇄 효과
장애는 세 가지 뚜렷한 단계로 전개되었습니다:
- 즉각적인 손실: 모든 GCP 호스팅 컴퓨팅, 데이터베이스, 그리고 제어 평면 API가 즉시 사라졌으며, 사용자들에게 503 에러를 반환했습니다.
- 캐시 윈도우: 짧은 기간 동안, 에지 프록시가 캐시된 라우팅 테이블을 사용하고 있었기 때문에 Railway Metal 및 AWS의 워크로드들은 여전히 접속이 가능했습니다.
- 전체 붕괴: 캐시가 만료되자 에지 프록시들은 더 이상 활성 인스턴스로의 경로를 해석할 수 없게 되었습니다. 제어 평면 API(신뢰할 수 있는 원천, source of truth)가 GCP 상에서 오프라인 상태였기 때문에 네트워크는 다시 정보를 채울 수 없었습니다. 이로 인해 물리적 호스팅 위치와 관계없이 모든 지역의 모든 워크로드에서 404 에러가 발생했습니다.
복구 과정의 어려움과 2차 장애
계정 액세스 권한을 복구하는 것이 즉 즉시 서비스 복구를 의미하지는 않았습니다. Railway는 지속성 디스크(persistent disks), 컴퓨팅 인스턴스, 그리고 네트워킹이 모두 별도의 순차적인 복구 프로세스를 필요로 한다는 점을 언급했습니다. 이로 인해 다운타임이 몇 시간 더 연장되었으며, 핵심 네트워킹은 다음 날 UTC 01:30경에야 비로소 완전히 복구되었습니다.
시스템이 다시 온라인 상태로 돌아오면서 "thundering herd" 효과가 발생했습니다. 대기 중이던 배포와 재시도된 요청들이 대량으로 시스템에 몰려들었습니다. 이는 2차 장애를 유발했습니다: GitHub가 Railway의 OAuth 및 webhook 통합에 대해 속도 제한(rate-limiting)을 적용하기 시작했고, 이는 일시적으로 사용자 로그인 및 신규 빌드를 차단했습니다.
기술적 분석 및 커뮤니티 비판
이 사건은 Hacker News의 기술 커뮤니티에서 GCP의 신뢰성과 "Platform-as-a-Service" (PaaS) 추상화의 위험성에 초점을 맞춘 두 가지 주요 주제로 상당한 논문을쟁했습니다.
GCP와의 "신뢰" 격차
많은 엔지니어들이 GCP의 자동화된 계정 정지에 관한 유사한 경험담을 공유했습니다. 비판론자들의 공통된 의견은 Google의 자동화된 집행 메커니즘이 너무 공격적이며 B2B 고객을 위한 충분한 인간의 감독이 부족하다는 것이었습니다.
"Google의 문화적 문제가 있습니다... 내 동료 C-level 경영진들 사이의 대화는, 이러한 종류의 사건이 몇 년 동안 발생하지 않을 때까지는 GCP를 고려 대상에 둘 수조차 없다는 것입니다."
누출된 추상화 (The Leaky Abstraction)
일 some 관찰자들은 다른 인프라 제공업체 위에 구축된 Railway와 같은 제공업체를 사용하는 것의 가치에 대해 의문을 제기했습니다. 논거는, 이것이 클라우드 제공업체의 서비스 약관이나 자동화된 봇에 의한 근본본적인 취약성을 제거하지 못하면서 비용과 위험의 층을 하나 더 추가할다는는 것입니다.
예방 조치: 진정한 메쉬(Mesh)를 향 향하여
Railway는 제어 평면이 multi-AZ였지만 multi-provider였던 것은 아니었음을 인정했습니다. 재발 방지를 위해 그들은 다음과 같은 아키텍처적 변화를 구현하고 있습니다:
- 진정한 메쉬 네트워킹 (True Mesh Networking): 워크로드 발견 가능성을 위해 GCP 호스팅 제어 평면(control plane)에 대한 강한 의존성을 제거합니다. 이를 통해 한 클라우드 제공업체가 장애를 발생시키면 메쉬가 다른 경로를 통해 경로를 해석할 수 있도록 보장합니다.
- 교차 클라우드 데이터베이스 쿼럼 (Cross-Cloud Database Quorum): 고가용성 데이터베이스 샤드(shards)를 AWS 및 Metal에 걸쳐 확장합니다. 이를 통해 클라우드 제공업체 전체가 사라지더라도 데이터베이스 쿼럼(quorum)이 유지되어 즉각적인 페일오버(failover)가가 가능하도록 합니다.
- GCP를 핫 패스(Hot Path)에서 제거: Google Cloud 서비스를 기본 데이터 평면(data plane)에서 제외하여, 보조 또는 페일오버 역할을로 맡깁니다.
최종 결론
Railway의 장애 보고서는 극단적인 투명성을 보여주는 드문 사례로, 그들의 아키텍처적 결정이 단일 업스트림 조치에 의해 전체 장애로 연쇄히 이어질 수 있음을 인정했습니다. 모든 플랫폼 엔지니어를 위한 핵심 교훈은 중복성(redundancy)은 독립성(independence)과 같지 않다는 것입니다. 데이터를 세 개의 클라우드에 두는 것은, 그 데이터를 찾는 "지도"가 단 하나의 클라우드에만 저장되어 있다면 무용지물입니다.