Google Cloud의 잘못된 계정 정지로 인해 발생한 Railway의 플랫폼 전반 장애, 영향, 타임라인, 원인, 그리고 재발 방지 대책을 정리한 보고서입니다.
🚅
이 보고서는 게시 시점에 우리가 파악하고 있는 내용을 반영하며, Google Cloud의 내부 검토에 따라 업데이트될 수 있습니다.
Railway는 Google Cloud가 당사 계정을 잘못 정지 상태로 전환하면서 플랫폼 전반의 서비스 중단을 겪었습니다. 이로 인해 GCP에 호스팅된 모든 인프라에서 일시적인 서비스 손실이 발생했습니다. 이 인프라는 대시보드, API, 그리고 네트워크 인프라의 일부를 지원합니다. 캐시된 네트워크 경로가 만료되면서 장애는 GCP를 넘어 확산되어 모든 Railway 워크로드에 영향을 주었습니다.
아래에서는 무엇이 발생했는지, 어떻게 대응했는지, 그리고 앞으로 유사한 사고를 방지하기 위해 무엇을 하고 있는지 설명합니다.
2026년 5월 19일 22:20 UTC부터 5월 20일 약 06:14 UTC까지(약 8시간), Google Cloud가 당사 프로덕션 계정의 서비스를 정지하면서 Railway는 플랫폼 전반의 장애를 겪었습니다. 이로 인해 API, 컨트롤 플레인, 데이터베이스와 함께 Google Cloud에 호스팅된 컴퓨트 인프라가 오프라인 상태가 되었습니다.
사용자들은 즉시 대시보드와 API에서 503 오류를 경험했으며, 여기에는 "no healthy upstream" 및 "unconditional drop overload" 메시지가 포함되었고, 로그인할 수 없었습니다. Google Cloud 컴퓨트에 호스팅된 모든 워크로드도 오프라인 상태가 되었습니다.
당사의 Railway Metal 및 AWS 버스트 클라우드 환경에서 실행되던 워크로드는 계속 가동 중이었지만, Railway의 엣지 프록시는 라우팅 테이블을 채우기 위해 Google Cloud에 호스팅된 컨트롤 플레인 API에 의존합니다. 이로 인해 장애가 Google Cloud를 넘어 확산되었습니다. 경로 캐시가 만료되자, 이러한 다른 워크로드도 도달할 수 없게 되었고, 네트워크 컨트롤 플레인이 더 이상 활성 인스턴스로의 경로를 확인할 수 없게 되면서 404 오류가 반환되기 시작했습니다. 영향이 가장 컸던 시점에는 모든 리전의 Railway 워크로드가 전부 도달 불가능한 상태가 되었습니다.
Google Cloud 환경을 복구하는 동안, 개별 서비스를 복원하는 과정에서 플랫폼 전반적으로 빌드와 배포가 차단되었습니다. 전체 인프라가 복구된 후에는 플랫폼에 과부하를 주지 않기 위해 대기열에 쌓인 대량의 배포 작업을 점진적으로 처리했습니다. 이와 동시에 GitHub가 Railway의 OAuth 및 webhook 통합에 대해 속도 제한을 적용하기 시작해, 로그인과 빌드가 일시적으로 차단되었습니다. 이러한 호출량 증가는 Google Cloud 장애로 인해 캐시가 비워진 결과였습니다. 부수적인 영향으로 서비스 약관 동의 기록도 초기화되어, 사용자는 다음에 대시보드를 방문할 때 다시 동의해야 했습니다.
우리는 단일 상위 공급자의 조치가 플랫폼 전반의 장애로 확산될 수 있도록 만든 아키텍처 결정에 대해 전적인 책임을 집니다. 아래에서는 무엇이 발생했는지, 어떻게 복구했는지, 그리고 이런 일이 다시 발생하지 않도록 어떤 변경을 하고 있는지 자세히 설명합니다.
5월 19일 22:20 UTC에 Google Cloud는 자동화된 조치의 일환으로 Railway의 프로덕션 계정을 잘못 정지 상태로 전환했습니다. 이 조치는 Google Cloud 내의 많은 계정에까지 확대되었습니다. 플랫폼 전반에 걸친 조치였기 때문에, 제한이 적용되기 전에 개별 고객에게 사전 안내는 이루어지지 않았습니다.
이 정지 상태로 인해 Railway Dashboard, API, 네트워크 인프라의 일부를 지원하는 GCP 관련 인프라와, Google Cloud에 호스팅된 추가 버스트 컴퓨트 인프라가 비활성화되었습니다.
Railway의 컨트롤 플레인은 대시보드를 제공하고, 빌드와 배포를 처리하며, 엣지에서 사용하는 라우팅 테이블을 채우는 핵심 의존성 집합입니다. 영향은 Google Cloud 위의 모든 워크로드에 즉시 나타났습니다.
Railway의 엣지 프록시는 Google Cloud 내부에 호스팅된 네트워크 컨트롤 플레인으로부터 받은 라우팅 테이블 캐시를 유지합니다. 이 캐시가 유지되는 동안에는 Railway Metal과 AWS의 워크로드가 계속 트래픽을 처리했습니다. 그러나 캐시가 만료되자, 엣지는 더 이상 활성 인스턴스로의 경로를 확인할 수 없게 되었고, Metal과 AWS를 포함한 모든 리전의 워크로드가 404 오류를 반환하기 시작했습니다. 이로 인해 네트워크 장애 영향이 Google Cloud를 넘어 이러한 리전으로도 확산되었으며, 워크로드 자체는 계속 온라인 상태였음에도 불구하고 문제가 발생했습니다.
Railway의 인프라는 고가용성을 염두에 두고 설계되었습니다. 데이터베이스는 여러 가용 영역에 걸쳐 실행되며, 네트워크는 AWS, GCP, Railway Metal 간의 이중화된 연결을 사용합니다. 그러나 계정 접근이 복구되었다고 해서 이러한 개별 서비스들이 바로 복원된 것은 아니었습니다. 영구 디스크, 컴퓨트 인스턴스, 네트워킹은 모두 각각 별도의 복구가 필요했습니다. 이 복구 과정의 특성 때문에 장애는 몇 시간 더 연장되었습니다. 디스크는 23:54 UTC까지 준비 상태로 복구되었지만, 핵심 네트워킹과 엣지 라우팅은 5월 20일 약 01:30 UTC가 되어서야 완전히 복구되었습니다. (이 지연과 관련 오류가 Google 측 문제였는지는 현재 확인을 기다리고 있습니다.)
네트워킹이 복원되면서 Railway 핵심 서비스의 복구와 최종 사용자 워크로드 검증은 계층별로 진행되었습니다. 빌드 시스템에 과부하가 걸리는 것을 방지하기 위해 배포를 일시 중지했고, 이후 점진적으로 재개했습니다. 핵심 시스템 복구와 동시에 GitHub는 재시도 요청이 대량으로 한꺼번에 발생한 특성 때문에 Railway의 OAuth 및 webhook 통합에 속도 제한을 적용하기 시작했고, 이로 인해 사용자 로그인과 빌드가 일시적으로 차단되었습니다.
5월 20일 약 04:00 UTC까지 API, 대시보드, OAuth 엔드포인트는 정상 동작이 확인되었고, 나머지 워크로드는 계속 복구 중이었습니다.
Railway의 네트워크 컨트롤 플레인은 복원력을 목표로 설계되었습니다. 이는 다중 AZ, 다중 존 컨트롤 플레인으로, 여러 머신과 구성 요소를 잃더라도 사용자 영향 없이 계속 동작할 수 있습니다. 이는 스테이징과 실제 트래픽 모두에서 테스트되었습니다(몇 달 전 롤아웃 이전 포함).
우리는 이전 사고들의 결과로 복원력에 투자해 왔고, 이러한 투자는 이번 영향에 대응하는 데 도움이 되었습니다. 이러한 교훈의 이전 사례로는, Railway가 2차 속도 제한을 유발하지 않고 사용자 GitHub 설치를 우아하게 복구할 수 있었던 일이 있습니다.
하지만 여러 포럼에서 많은 분들이 물었습니다. 어떻게 Railway에 모든 고객 워크로드에 영향을 줄 수 있는 단일 의존성이 있을 수 있었느냐고 말입니다.
Railway의 네트워크는 Metal <> GCP <> AWS 사이의 고가용성 광섬유 인터커넥트를 기반으로 구축된 메시 링입니다. 그러나 이 링 안에서도 워크로드 발견 가능성이 Google Cloud에서 실행되는 머신에 호스팅된 네트워크 컨트롤 플레인 API에 묶여 있는 강한 의존성이 여전히 존재했습니다. 이는 메시가 한 시간 동안 계속 동작했음에도, 경로 캐시가 만료되자 메시가 라우팅 테이블을 다시 채우지 못했다는 뜻입니다.
우리는 즉시 이 의존성을 제거하여 이를 진정한 메시로 만들기 위해 작업하고 있습니다. 이는 어느 인터커넥트가 끊기더라도 클라우드 간에 항상 경로가 존재하도록 한다는 의미입니다.
이에 따라 고가용성 데이터베이스 샤드를 AWS와 Metal 전반으로 확장할 예정입니다. 앞으로 특정 클라우드의 모든 인스턴스가 즉시 사라지는 상황이 발생하더라도, 데이터베이스 쿼럼이 모든 것을 계속 실행 상태로 유지하고 더 이상 실행 중이 아닌 워크로드를 즉시 장애 조치할 것입니다.
마지막으로, 우리는 데이터 플레인의 핫 패스에서 Google Cloud 서비스를 제거하고, 이를 보조/장애 조치 용도로만 유지하는 계획을 세우고 있습니다. 이는 데이터 플레인(호스트 연결성 제공)과 컨트롤 플레인(Railway에 접근하고 관리하기 위해 사용하는 대시보드를 구동)의 새로운 아키텍처를 구현하는 작업과 병행해 진행됩니다. 이러한 아키텍처 업그레이드는 핵심 서비스, 특히 사용자 대면 구성 요소가 어느 한 벤더나 플랫폼에도 의존하지 않도록 보장할 것입니다.
Railway는 우리의 벤더 선택에 대한 책임을 지며, 궁극적으로 이번 일 또한 우리의 책임입니다. 여러분의 고객은 실패 원인이 Google이었는지 Railway였는지 신경 쓰지 않습니다. 그들이 보는 것은 여러분의 제품입니다. 여러분의 가동 시간은 우리의 책임이며, 우리는 계속 그 책임을 다하겠습니다.
