Railway는 Google Cloud가 당사의 계정을 잘못된 정지(suspended) 상태로 설정함에 따라 플랫폼 전반에 걸친 서비스 중단을 경험했습니다. 이로 인해 GCP (Google Cloud Platform) 기반의 모든 호스팅 인프라에 일시적인 서비스 손실이 발생했습니다. 이 인프라는 당사의 대시보드, API 및 네트워크 인프라의 일부를 지원합니다. 캐시된 네트워크 경로(cached network routes)가 만료됨에 따라, 장애는 GCP를 넘어 모든 Railway 워크로드(workloads)로 확대되었습니다.

아래에서는 어떤 일이 발생했는지, 어떻게 대응했는지, 그리고 향후 유사한 사고를 방지하기 위해 무엇을 하고 있는지 설명합니다.

2026년 5월 19일 22:20 UTC부터 5월 20일 약 06:14 UTC 사이(~8시간 동안), Google Cloud가 당사의 프로덕션 계정(production account)에 대한 서비스를 중단함에 따라 Railway는 플랫폼 전반의 장애를 겪었습니다. 이로 인해 Google Cloud에 호스팅된 컴퓨팅 인프라와 함께 API, 컨트롤 플레인(control plane) 및 데이터베이스가 오프라인 상태가 되었습니다.

사용자들은 대시보드와 API에서 "no healthy upstream" 및 "unconditional drop overload" 메시지를 포함한 503 에러를 즉시 경험하였으며, 로그인을 할 수 없었습니다. Google Cloud 컴퓨팅에 호스팅된 모든 워크로드가 오프라인 상태가 되었습니다.

당사의 자체 Railway Metal 및 AWS 버스트 클라우드(burst-cloud) 환경의 워크로드는 가동 상태를 유지했으나, Railway의 에지 프록시(edge proxies)는 라우팅 테이블(routing tables)을 채우기 위해 Google Cloud에 호스팅된 컨트롤 플레인 API에 의존하므로 장애가 Google Cloud를 넘어 연쇄적으로 발생했습니다. 경로 캐시(route caches)가 만료됨에 따라 이러한 다른 워크로드에도 접근할 수 없게 되었으며, 네트워크 컨트롤 플레인이 활성 인스턴스로의 경로를 더 이상 해석(resolve)할 수 없게 됨에 따라 404 에러가 반환되었습니다. 영향이 정점에 달했을 때, 모든 지역의 모든 Railway 워크로드에 접근할 수 없는 상태가 되었습니다.

Google Cloud 환경을 복구하는 과정에서, 개별 서비스들을 복구하는 동안 플랫폼 전반에 걸쳐 빌드(builds) 및 배포(deployments)가 차단되었습니다. 인프라 전체가 복구된 후에는 플랫폼에 과부하가 걸리는 것을 방지하기 위해 대기 중이던 대량의 배포 백로그(backlog)를 점진적으로 처리했습니다. 이와 동시에, GitHub이 Railway의 OAuth 및 웹훅(webhook) 통합에 대해 속도 제한(rate-limiting)을 적용하기 시작하면서 로그인과 빌드가 일시적으로 차단되었습니다. 이러한 호출량의 증가는 Google Cloud 장애로 인해 캐시(caches)가 삭제됨에 따라 발생했습니다. 부작용으로 서비스 약관(Terms-of-service) 동의 기록도 초기화되어, 사용자가 대시보드에 다시 방문했을 때 약관에 재동의하도록 요청되었습니다.

우리는 단일 상위 제공업체(upstream provider)의 조치가 플랫폼 전체의 장애로 이어지게 만든 아키텍처 결정에 대해 모든 책임을 통감하며, 아래에 발생한 상황, 복구 과정, 그리고 재발 방지를 위해 시행 중인 변경 사항을 상세히 기술합니다.

• 5월 19일, 22:10 UTC - 자동 모니터링 시스템이 API 상태 확인(health check) 실패를 감지하고 온콜(on-calls) 담당자에게 페이지를 보냈으며, 담당자들이 문제 조사를 시작했습니다.

• 5월 19일, 22:11 UTC - 대시보드에서 503 에러 반환. 사용자들이 로그인할 수 없는 상태가 되었습니다.

• 5월 19일, 22:19 UTC - 근본 원인 파악: Google Cloud Platform이 Railway의 프로덕션(production) 계정을 정지시켰습니다.

• 5월 19일, 22:22 UTC - Google Cloud에 P0 티켓을 접수했습니다. Railway의 GCP 계정 관리자(account manager)가 직접 개입했습니다.

• 5월 19일, 22:29 UTC - 장애(Incident) 선포.

• 5월 19일, 22:29 UTC - GCP 계정 액세스 복구됨. 모든 컴퓨팅 인스턴스(compute instances)는 정지 상태로 유지되었으며 영구 디스크(persistent disks)는 접근할 수 없는 상태였습니다.

• 5월 19일, 22:35 UTC - 캐시된 네트워크 경로(network routes)가 만료되기 시작했습니다. 네트워킹이 더 이상 경로를 해석(resolve)할 수 없게 됨에 따라 Railway Metal 및 AWS 상의 워크로드(workloads)에서 404 에러가 반환되기 시작했습니다.

• 5월 19일, 23:09 UTC - 첫 번째 영구 디스크가 온라인 상태로 복구되었습니다.

• 5월 19일, 23:54 UTC - 모든 영구 디스크가 준비(ready) 상태로 복구되었습니다. 네트워크는 여전히 다운된 상태였습니다.

• 5월 20일, 00:39 UTC - 디스크가 준비되었음을 확인했습니다. Google Cloud 네트워킹 복구가 지연되어 전체 복구가 차단되었습니다.

• 5월 20일, 01:30 UTC - 컴퓨팅 인스턴스 (Compute instances) 복구가 시작되었습니다.

• 5월 20일, 01:38 UTC - 에지 트래픽 (Edge traffic) 서비스가 재개되었습니다. 네트워킹 (Networking)이 복구되었습니다.

• 5월 20일, 01:57 UTC - 오케스트레이션 (Orchestration) 및 빌드 인프라스트럭처 (build infrastructure)가 복구되었습니다. 대기 중인 작업들이 동시에 실행되면서 시스템에 과부하가 걸리는 것을 방지하기 위해 배포 (Deploys)를 일시적으로 중단했습니다.

• 5월 20일, 02:04 UTC - 컴퓨팅 호스트 (Compute hosts)가 점진적으로 온라인 상태로 전환되고 있습니다.

• 5월 20일, 02:47 UTC - GitHub가 Railway의 OAuth 및 웹훅 (webhook) 통합에 대해 속도 제한 (rate-limiting)을 적용하기 시작했습니다. 일부 사용자가 로그인할 수 없으며, 빌드가 차단되었습니다.

• 5월 20일, 02:55 UTC - 대시보드 (Dashboard) 접속이 다시 가능해졌습니다.

• 5월 20일, 03:59 UTC - 모든 티어 (tiers)에서 배포 (Deployments) 프로세스가 다시 시작되었습니다.

• 5월 20일, 04:00 UTC - API, 대시보드 및 OAuth 엔드포인트 (endpoints)가 정상 작동함을 확인했습니다. 남은 워크로드 (workloads)의 복구가 계속되고 있습니다.

• 5월 20일, 06:14 UTC - 장애 상황이 모니터링 (monitoring) 단계로 전환되었습니다.

• 5월 20일, 07:58 UTC - 장애가 해결되었습니다.

5월 19일 22:20 UTC에 Google Cloud는 자동화된 조치의 일환으로 Railway의 프로덕션 계정 (production account)을 잘못된 상태로 일시 중단 (suspended) 상태로 전환했습니다. 이 조치는 Google Cloud 내의 많은 계정으로 확대되었습니다. 이는 플랫폼 전반에 걸친 조치였기 때문에, 제한 조치 이전에 개별 고객에게 사전 안내가 이루어지지 않았습니다.

이 일시 중단 상태로 인해 Railway 대시보드, API 및 네트워크 인프라 (Network infrastructure)의 일부를 지원하는 GCP 관련 인프라와 Google Cloud에 호스팅된 추가 버스트 컴퓨팅 (burst-compute) 인프라가 비활성화되었습니다.

Railway의 컨트롤 플레인 (control plane)은 대시보드를 서비스하고, 빌드 및 배포를 처리하며, 에지 (edge)에서 사용하는 라우팅 테이블 (routing tables)을 생성하는 핵심 의존성 (dependencies) 세트입니다. 이로 인한 영향은 Google Cloud 상의 모든 워크로드 (workloads)에 즉각적으로 나타났습니다.

Railway의 에지 프록시 (edge proxies)는 Google Cloud 내에 호스팅되는 네트워크 제어 평면 (network control plane)으로부터 라우팅 테이블 (routing tables) 캐시를 유지합니다. 해당 캐시가 유지되는 동안에는 Railway Metal 및 AWS 상의 워크로드 (workloads)가 계속해서 트래픽을 처리할 수 있었습니다. 하지만 캐시가 만료되자, 에지 (edge)에서 활성 인스턴스로의 경로를 더 이상 해석 (resolve)할 수 없게 되었고, Metal 및 AWS를 포함한 모든 리전 (regions)의 워크로드에서 404 에러가 반환되기 시작했습니다. 이로 인해 워크로드 자체는 온라인 상태를 유지했음에도 불구하고, 네트워크 중단 영향이 Google Cloud를 넘어 해당 리전들로까지 연쇄적으로 확산되었습니다.

Railway의 인프라는 고가용성 (high availability)을 위해 설계되었습니다. 당사의 데이터베이스는 여러 가용 영역 (availability zones)에 걸쳐 실행되며, 네트워크는 AWS, GCP, 그리고 Railway Metal 간의 중복 연결 (redundant connections)을 사용합니다. 그러나 계정 액세스 (account access)를 복구하는 것이 이러한 개별 서비스들의 복구를 의미하지는 않았습니다. 영구 디스크 (persistent disks), 컴퓨팅 인스턴스 (compute instances), 그리고 네트워킹 (networking) 모두 별도의 복구 과정이 필요했습니다. 이러한 복구 프로세스의 특성으로 인해 중단 시간이 몇 시간 더 연장되었습니다. 디스크는 UTC 기준 23:54에 준비 상태로 복구되었으나, 핵심 네트워킹 및 에지 라우팅 (edge routing)은 5월 20일 약 01:30 UTC가 되어서야 완전히 복구되었습니다. (당사는 이러한 지연 및 관련 에러가 Google 측의 문제였는지 확인을 기다리고 있습니다.)

네트워킹이 복구됨에 따라, Railway 핵심 서비스의 복구와 최종 사용자 워크로드의 검증이 계층별 (layer by layer)로 진행되었습니다. 빌드 시스템 (build systems)에 과부하가 걸리는 것을 방지하기 위해 배포 (deploys)를 일시적으로 중단했으며, 점진적으로 재개할 수 있도록 조치했습니다. 핵심 시스템 복구와 병행하여, GitHub은 모든 재시도 요청의 양과 급증하는 특성 (burst nature)으로 인해 Railway의 OAuth 및 웹훅 (webhook) 통합에 대한 속도 제한 (rate-limiting)을 적용하기 시작했고, 이로 인해 사용자 로그인과 빌드가 일시적으로 차단되었습니다.

5월 20일 약 04:00 UTC 경, API, 대시보드 (dashboard), 그리고 OAuth 엔드포인트 (endpoints)가 정상 작동하는 것이 확인되었으며, 나머지 워크로드들의 복구가 계속되었습니다.

Railway의 네트워크 제어 평면 (network control plane)은 회복 탄력성 (resilience)을 위해 설계되었습니다. 이는 여러 대의 머신과 구성 요소의 손실을 견디면서도 사용자 영향 없이 작동할 수 있는 멀티-AZ (multi-AZ), 멀티-존 (multi-zone) 제어 평면입니다. 이는 몇 달 전 배포되기 전, 스테이징 (staging) 환경과 실제 트래픽 (live traffic) 모두에서 테스트되었습니다.

우리는 이전의 장애 사례들을 통해 회복 탄력성에 투자해 왔으며, 이는 이번 영향에 대응하는 데 도움이 되었습니다. 이러한 교훈의 이전 사례로는, Railway가 2차 속도 제한 (secondary rate-limits)을 유발하지 않고 사용자의 GitHub 설치를 원활하게 복구할 수 있었던 점이 있습니다.

하지만 많은 이들이 여러 포럼을 통해 어떻게 Railway가 모든 고객 워크로드 (workloads)에 영향을 미칠 수 있는 단일 의존성 (single dependency)을 가질 수 있었는지 질문해 왔습니다.

Railway의 네트워크는 Metal <> GCP <> AWS 간의 고가용성 광섬유 상호 연결 (high availability fiber interconnects)로 구축된 메시 링 (mesh ring) 구조입니다. 그러나 이 링 구조 내에서도, 워크로드 탐지 가능성 (workload discoverability)이 Google Cloud에서 실행되는 머신에 호스팅된 네트워크 제어 평면 API에 묶여 있다는 강력한 의존성 (hard dependency)이 여전히 존재했습니다. 이는 메시 (mesh)가 한 시간 동안 계속 작동했음에도 불구하고, 경로 캐시 (route cache)가 만료되었을 때 메시가 라우팅 테이블 (routing tables)을 다시 채우는 데 실패했음을 의미합니다.

우리는 이 의존성을 제거하여 진정한 메시 (true mesh)로 만들기 위해 즉시 작업에 착수하고 있습니다. 이는 상호 연결 (interconnects) 중 어느 하나가 중단되더라도 클라우드 간에 항상 경로가 존재함을 의미합니다.

그 결과로, 우리는 고가용성 데이터베이스 샤드 (high availability database shards)를 AWS와 Metal 전반으로 확장할 예정입니다. 향후 특정 클라우드의 모든 인스턴스가 즉시 사라지더라도, 데이터베이스 정족수 (database quorum)가 모든 것을 계속 실행 상태로 유지하고 더 이상 실행되지 않는 워크로드를 즉시 페일오버 (failover)할 것입니다.

마지막으로, 저희는 데이터 플레인 (data plane)의 핫 패스 (hot path)에서 Google Cloud 서비스를 제거하고, 이를 보조/페일오버 (secondary/failover) 용도로만 유지하는 계획을 세우고 있습니다. 이는 데이터 플레인 (호스트로의 연결을 가능하게 함) 및 컨트롤 플레인 (사용자가 Railway에 접속하고 관리하는 데 사용하는 대시보드를 구동함)을 위한 새로운 아키텍처 (architecture)를 구현하는 것과 병행하여 진행됩니다. 이러한 아키텍처 업그레이드는 저희의 핵심 서비스, 특히 사용자 대면 컴포넌트 (user facing components)가 특정 벤더 (vendor)나 플랫폼에 의존하지 않도록 보장할 것입니다.

Railway는 벤더 (vendor) 선택에 대한 권한을 가지며, 궁극적으로 저희가 이 결정을 책임집니다. 고객들은 장애의 원인이 Google인지 Railway인지 신경 쓰지 않습니다. 그들은 여러분의 제품을 봅니다. 여러분의 업타임 (uptime)은 저희의 책임이며, 저희는 이를 계속해서 지켜나갈 것입니다.