Railway 사건 보고서: 2026년 5월 19일 – GCP 계정 정지

^{source https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage}

• 이 보고서는 게시 시점까지 확인된 내용을 바탕으로 작성됐으며, Google Cloud의 내부 검토 결과에 따라 업데이트될 수 있음

• Google Cloud가 Railway 계정을 잘못 정지 상태로 처리하면서 Railway 전반에 걸친 서비스 장애가 발생

• 이로 인해 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 burst-cloud 환경의 워크로드 자체는 살아 있었지만, Railway의 엣지 프록시가 Google Cloud에 호스팅된 컨트롤 플레인 API에 의존해 라우팅 테이블을 채우는 구조였기 때문에 장애가 다른 환경으로도 확산됨

• 경로 캐시가 만료되자 다른 환경의 워크로드도 접근 불가 상태가 됐고, 네트워크 컨트롤 플레인이 활성 인스턴스로 향하는 경로를 더 이상 해석하지 못하면서 404 오류를 반환함

• 영향이 가장 컸을 때는 모든 리전의 Railway 워크로드가 도달 불가 상태가 됨

• Google Cloud 환경을 복구하는 동안에는 개별 서비스를 되살리는 과정이 필요해 플랫폼 전반에서 빌드와 배포도 차단됨

• 전체 인프라를 복구한 뒤에는 대기 중이던 대량의 배포를 플랫폼에 과부하를 주지 않도록 점진적으로 소진함

• 이와 동시에 GitHub가 Railway의 OAuth 및 webhook 연동에 rate limit을 적용하면서 로그인과 빌드가 일시적으로 차단됨

• 이는 Google Cloud 장애로 캐시가 비워진 뒤 관련 호출이 급증한 데 따른 부작용이었음

• 부수적으로 서비스 약관 동의 기록도 초기화돼, 사용자는 다음에 대시보드에 방문할 때 다시 동의해야 했음

• 단일 상위 공급자의 조치가 플랫폼 전체 장애로 번지도록 만든 아키텍처 선택의 책임은 Railway에 있으며, 아래에 사고 경위와 복구 과정, 재발 방지 변경 사항을 설명함

사고 타임라인

• 5월 19일 22:10 UTC: 자동 모니터링이 API health check 실패를 감지했고, on-call 담당자에게 페이지를 보내 조사 시작

• 5월 19일 22:11 UTC: 대시보드에서 503 오류 발생, 사용자 로그인 불가

• 5월 19일 22:19 UTC: Google Cloud Platform이 Railway의 프로덕션 계정을 정지시킨 것이 근본 원인으로 확인

• 5월 19일 22:22 UTC: Google Cloud에 P0 티켓 접수, Railway의 GCP 계정 담당자도 직접 대응에 참여

• 5월 19일 22:29 UTC: 사고 공식 선언

• 5월 19일 22:29 UTC: GCP 계정 접근은 복구됐지만, 모든 컴퓨트 인스턴스는 계속 중지 상태였고 persistent disk에도 접근할 수 없었음

• 5월 19일 22:35 UTC: 캐시된 네트워크 경로가 만료되기 시작했고, Railway Metal과 AWS 워크로드도 네트워크가 더 이상 경로를 해석하지 못하면서 404 오류를 반환하기 시작

• 5월 19일 23:09 UTC: 첫 번째 persistent disk가 다시 온라인 상태가 됨

• 5월 19일 23:54 UTC: 모든 persistent disk가 ready 상태로 복구됐지만 네트워크는 여전히 다운 상태

• 5월 20일 00:39 UTC: 디스크가 ready 상태임을 확인했지만, Google Cloud 네트워크 복구가 지연돼 전체 복구가 막힘

• 5월 20일 01:30 UTC: 컴퓨트 인스턴스 복구 시작

• 5월 20일 01:38 UTC: 엣지 트래픽이 다시 처리되기 시작했고 네트워크도 복구

• 5월 20일 01:57 UTC: 오케스트레이션과 빌드 인프라 복구, 대기 중인 작업이 한꺼번에 실행돼 시스템을 압박하지 않도록 배포는 일시 중단

• 5월 20일 02:04 UTC: 컴퓨트 호스트를 점진적으로 다시 온라인 상태로 전환

• 5월 20일 02:47 UTC: GitHub가 Railway의 OAuth와 webhook 연동에 rate limit을 적용하면서 일부 사용자는 로그인하지 못했고 빌드도 차단됨

• 5월 20일 02:55 UTC: 대시보드 재접속 가능

• 5월 20일 03:59 UTC: 모든 티어에서 배포 처리가 다시 시작됨

• 5월 20일 04:00 UTC: API, 대시보드, OAuth 엔드포인트의 정상 동작 확인, 남은 워크로드는 계속 복구 중

• 5월 20일 06:14 UTC: 사고 상태를 모니터링 단계로 전환

• 5월 20일 07:58 UTC: 사고 해결

무슨 일이 있었나?

• 5월 19일 22:20 UTC, Google Cloud가 자동화된 조치의 일환으로 Railway의 프로덕션 계정을 잘못 정지 상태로 전환함

• 이 조치는 Google Cloud 내 여러 계정에 걸쳐 적용됐고, 플랫폼 차원의 조치였기 때문에 제한 전에 개별 고객에게 사전 안내는 없었음

• 이 정지 상태로 인해 Railway의 GCP 관련 인프라가 비활성화됐고, 이는 Railway Dashboard, API, 네트워크 인프라 일부와 Google Cloud에 호스팅된 추가 burst-compute 인프라를 포함함

• Railway의 컨트롤 플레인은 대시보드를 제공하고, 빌드와 배포를 처리하며, 엣지가 사용하는 라우팅 테이블을 채우는 핵심 의존성 집합이기 때문에 Google Cloud 위 모든 워크로드가 즉시 영향을 받음

• Railway의 엣지 프록시는 Google Cloud 내부에 호스팅된 네트워크 컨트롤 플레인으로부터 라우팅 테이블을 캐시해 유지하고 있었음

• 이 캐시가 유지되는 동안에는 Railway Metal과 AWS 워크로드가 계속 트래픽을 처리했지만, 캐시가 만료되자 엣지는 활성 인스턴스로 가는 경로를 더 이상 해석할 수 없었고, Metal과 AWS를 포함한 모든 리전의 워크로드가 404 오류를 반환하기 시작함

• 이로 인해 워크로드 자체는 온라인 상태였음에도 네트워크 장애의 영향이 Google Cloud를 넘어 다른 리전으로까지 확산됨

• Railway의 인프라는 고가용성을 목표로 설계돼 있었고, 데이터베이스는 여러 availability zone에 걸쳐 운영됐으며 네트워크는 AWS, GCP, Railway Metal 사이에 중복 연결을 사용했음

• 하지만 계정 접근 권한을 되찾는 것만으로 각 서비스가 자동 복구되지는 않았고, persistent disk, 컴퓨트 인스턴스, 네트워크를 각각 따로 복구해야 했음

• 이 복구 과정의 특성 때문에 장애 시간은 몇 시간 더 길어졌고, 디스크는 23:54 UTC에 ready 상태로 복구됐지만 핵심 네트워크와 엣지 라우팅은 5월 20일 01:30 UTC 무렵까지 완전히 복구되지 못함

• Railway는 이 지연과 관련 오류가 Google 측 문제였는지 확인을 기다리고 있음

• 네트워크가 복구된 뒤에는 Railway 핵심 서비스 복구와 최종 사용자 워크로드 검증을 계층별로 진행함

• 빌드 시스템에 과부하가 걸리지 않도록 배포를 일시 중단했다가 점진적으로 재개함

• 핵심 시스템 복구와 동시에, 재시도 요청이 대량으로 몰린 영향으로 GitHub가 Railway의 OAuth 및 webhook 연동에 rate limit을 적용했고, 그 결과 사용자 로그인과 빌드가 일시적으로 차단됨

• 5월 20일 04:00 UTC 무렵 기준으로 API, 대시보드, OAuth 엔드포인트는 정상 동작이 확인됐고, 나머지 워크로드는 계속 복구 중이었음

재발 방지 조치

• Railway의 네트워크 컨트롤 플레인은 복원력을 전제로 설계돼 있음

• 다중 AZ, 다중 존 컨트롤 플레인 구조로 여러 머신과 구성요소를 잃더라도 사용자 영향 없이 계속 동작할 수 있게 만들었고, 이는 몇 달 전 롤아웃에 앞서 스테이징과 실제 트래픽 환경 모두에서 검증했음

• Railway는 이전 사고를 계기로 복원력에 투자해 왔고, 그 교훈의 한 사례로 사용자 GitHub 설치를 2차 rate limit 없이 무리 없이 복구할 수 있었음

• 다만 여러 포럼에서 제기된 핵심 질문은 남아 있음. 모든 고객 워크로드에 영향을 줄 수 있는 단일 의존성이 왜 존재했는가

• Railway 네트워크는 Metal <> GCP <> AWS를 잇는 고가용성 광섬유 인터커넥트 기반 메시 링 구조이지만, 이 링 안에서도 워크로드 발견 가능성이 Google Cloud에서 실행되던 네트워크 컨트롤 플레인 API에 강하게 묶여 있었음

• 그 결과 메시 자체는 한 시간 동안 계속 동작했지만, 경로 캐시가 만료되자 메시가 라우팅 테이블을 다시 채우지 못했음

• Railway는 이 의존성을 즉시 제거해 이를 진정한 메시 구조로 바꾸는 작업을 진행 중이며, 이는 어떤 인터커넥트가 끊기더라도 클라우드 사이에 항상 경로가 남도록 하겠다는 뜻임

• 이를 위해 고가용성 데이터베이스 샤드를 AWS와 Metal까지 확장할 예정

• 앞으로 특정 클라우드의 모든 인스턴스가 갑자기 사라지더라도 데이터베이스 쿼럼이 시스템을 계속 유지하고, 더 이상 실행되지 않는 워크로드는 즉시 페일오버 처리하도록 할 계획

• 또한 데이터 플레인의 hot path에서 Google Cloud 서비스를 제거하고, 이를 보조 또는 페일오버 용도로만 남기는 방안을 계획 중임

• 이는 호스트 연결성을 담당하는 새 데이터 플레인 아키텍처와, 사용자가 Railway에 접속하고 관리할 때 사용하는 대시보드를 구동하는 새 컨트롤 플레인 아키텍처 도입과 병행됨

• 이러한 아키텍처 업그레이드는 특히 사용자 대면 구성요소를 포함한 핵심 서비스가 특정 벤더나 플랫폼 하나에 종속되지 않도록 보장하는 것이 목표임

• 어떤 벤더를 선택했는지도 Railway의 책임이며, 이번 사고의 최종 책임 역시 Railway에 있음

• 고객의 고객은 장애 원인이 Google인지 Railway인지 구분하지 않고, 자신들이 쓰는 제품이 멈췄다고 받아들일 뿐임

• 서비스 가용성은 Railway의 책임이며, Railway는 그 책임을 계속 지겠다고 밝힘