장애 보고서: 2026년 5월 19일 – GCP 계정 중단

1 week ago 8

Railway 플랫폼 전반 장애가 2026년 5월 19일 22:20 UTC부터 약 8시간 이어졌고, 직접 원인은 Google Cloud의 프로덕션 계정 중단이었음
대시보드와 API는 즉시 503 오류를 반환했고, Google Cloud에 호스팅된 컴퓨트, 데이터베이스, 제어 평면, burst-compute 인프라가 오프라인으로 전환됨
Railway Metal과 AWS 워크로드는 계속 실행됐지만, 엣지 프록시가 Google Cloud의 제어 평면 API에 의존해 라우트 캐시 만료 뒤 404 오류가 확산됨
계정 접근 복구 뒤에도 영구 디스크, 컴퓨트 인스턴스, 네트워킹은 각각 따로 복구해야 했고, GitHub OAuth와 webhook 속도 제한이 로그인과 빌드를 추가로 막음
Railway는 단일 상위 제공자의 조치가 전체 장애로 번진 아키텍처 결정의 책임을 인정하고, Google Cloud를 데이터 평면 핫 패스에서 제거하는 재설계를 진행 중임

영향

2026년 5월 19일 22:20 UTC부터 5월 20일 약 06:14 UTC까지 약 8시간 동안 Railway에 플랫폼 전반 장애가 발생함
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에 의존하고 있었음
캐시된 네트워크 라우트가 만료되자 Google Cloud 외부 워크로드도 도달 불가능해졌고, 네트워크 제어 평면이 활성 인스턴스의 라우트를 해석하지 못해 404 오류를 반환함
최대 영향 시점에는 모든 리전의 Railway 워크로드가 도달 불가능한 상태가 됨
Google Cloud 환경 복구 중에는 개별 서비스를 복구하는 동안 플랫폼 전반의 빌드와 배포가 차단됨
전체 인프라가 복구된 뒤에는 대기 중이던 배포 작업의 큰 백로그를 플랫폼에 과부하를 주지 않도록 점진적으로 처리함
동시에 GitHub가 Railway의 OAuth 및 webhook 통합을 속도 제한하면서 로그인과 빌드가 일시적으로 차단됨
호출량 증가는 Google Cloud 장애로 캐시가 비워진 결과였음
서비스 약관 동의 기록도 재설정되어 사용자가 다음 대시보드 방문 시 다시 동의해야 했음
Railway는 단일 상위 제공자의 조치가 플랫폼 전반 장애로 확산되도록 만든 아키텍처 결정에 대한 책임을 인정함

장애 타임라인

5월 19일 22:10 UTC: 자동 모니터링이 API 상태 확인 실패를 감지하고 온콜 담당자에게 알림
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 계정 접근은 복구됐지만 모든 컴퓨트 인스턴스는 계속 중지 상태였고 영구 디스크는 접근 불가능했음
5월 19일 22:35 UTC: 캐시된 네트워크 라우트가 만료되기 시작하면서 Railway Metal과 AWS 워크로드가 404 오류를 반환함
5월 19일 23:09 UTC: 첫 번째 영구 디스크가 온라인으로 돌아옴
5월 19일 23:54 UTC: 모든 영구 디스크가 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 통합을 속도 제한하기 시작해 일부 사용자가 로그인할 수 없고 빌드가 차단됨
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: 장애가 해결됨

발생 원인과 복구 과정

Google Cloud 계정 중단
- 5월 19일 22:20 UTC에 Google Cloud가 자동 조치의 일부로 Railway의 프로덕션 계정을 잘못 중단 상태로 전환함
- 이 조치는 Google Cloud 내 여러 계정에 영향을 미침
- 플랫폼 전반의 조치였기 때문에 제한 전에 개별 고객에게 사전 연락이 없었음
- 중단 상태는 Railway Dashboard, API, 네트워크 인프라 일부, Google Cloud에 호스팅된 추가 burst-compute 인프라를 포함한 GCP 관련 인프라를 비활성화함
제어 평면 의존성
- Railway의 제어 평면은 대시보드를 제공하고, 빌드와 배포를 처리하며, 엣지가 사용하는 라우팅 테이블을 채우는 핵심 의존성 집합임
- Google Cloud의 모든 워크로드에는 영향이 즉시 발생함
- Railway의 엣지 프록시는 Google Cloud 내부에 호스팅된 네트워크 제어 평면의 라우팅 테이블 캐시를 유지함
- 캐시가 유지되는 동안 Railway Metal과 AWS의 워크로드는 계속 트래픽을 처리함
- 캐시가 만료되자 엣지가 활성 인스턴스의 라우트를 더 이상 해석할 수 없게 됐고, Metal과 AWS를 포함한 모든 리전의 워크로드가 404 오류를 반환하기 시작함
- 워크로드 자체는 온라인 상태였지만, 네트워크 장애 영향이 Google Cloud 밖의 리전으로 확산됨
고가용성 설계의 한계
- Railway 인프라는 고가용성을 목표로 설계되어 있으며, 데이터베이스는 여러 가용 영역에 걸쳐 실행되고 네트워크는 AWS, GCP, Railway Metal 사이의 중복 연결을 사용함
- 계정 접근이 복구되어도 개별 서비스가 자동으로 복구되지는 않았음
- 영구 디스크, 컴퓨트 인스턴스, 네트워킹이 각각 별도 복구를 필요로 했고, 이 복구 특성 때문에 장애가 몇 시간 더 이어짐
- 디스크는 23:54 UTC에 ready 상태로 복구됐지만, 핵심 네트워킹과 엣지 라우팅은 5월 20일 약 01:30 UTC까지 완전히 복구되지 않음
- Railway는 이 지연과 관련 오류가 Google 측에서 발생했는지 확인을 기다리고 있음
단계적 복구와 2차 영향
- 네트워킹이 복구되면서 Railway 핵심 서비스와 최종 사용자 워크로드 검증이 계층별로 진행됨
- 빌드 시스템 과부하를 막기 위해 배포를 일시 중지했고, 이후 점진적으로 재개함
- 핵심 시스템 복구와 병행해 GitHub가 Railway의 OAuth 및 webhook 통합을 속도 제한함
- 모든 재시도 요청의 볼륨과 burst 특성 때문에 사용자 로그인과 빌드가 일시적으로 차단됨
- 5월 20일 약 04:00 UTC에는 API, 대시보드, OAuth 엔드포인트가 동작 중임이 확인됐고, 남은 워크로드 복구가 계속됨

예방 조치

기존 복원력 설계
- Railway의 네트워크 제어 평면은 multi-AZ, multi-zone 구성으로 설계되어 여러 머신과 컴포넌트를 잃어도 사용자 영향 없이 계속 동작할 수 있음
- 이 설계는 몇 달 전 출시 전에 스테이징과 실제 트래픽에서 테스트됨
- 이전 장애 이후 복원력에 투자해 왔고, 그 결과 사용자 GitHub 설치를 2차 속도 제한 없이 안정적으로 복구한 경험이 있음
단일 의존성 제거
- Railway 네트워크는 Metal <> GCP <> AWS 사이의 고가용성 광섬유 상호 연결로 구성된 mesh ring임
- 이 링 안에서도 워크로드 발견 가능성이 Google Cloud 머신에서 실행되는 네트워크 제어 평면 API에 묶인 강한 의존성이 남아 있었음
- 메시는 약 한 시간 동안 계속 동작했지만, 라우트 캐시가 만료되자 라우팅 테이블을 다시 채울 수 없어 실패함
- Railway는 이 의존성을 즉시 제거해 실제 mesh로 만드는 작업을 진행 중임
- 목표는 어떤 상호 연결이 끊어져도 클라우드 사이에 항상 경로가 남도록 하는 것임
데이터베이스와 장애 조치 개선
- Railway는 고가용성 데이터베이스 샤드를 AWS와 Metal 전반으로 확장할 예정임
- 향후 특정 클라우드의 모든 인스턴스가 즉시 사라져도 데이터베이스 quorum이 서비스를 계속 유지하고, 더 이상 실행 중이 아닌 워크로드를 즉시 장애 조치하도록 만드는 방향임
데이터 평면과 제어 평면 재설계
- Google Cloud 서비스를 데이터 평면의 핫 패스에서 제거하고 보조 또는 장애 조치 용도로만 유지하는 계획이 진행 중임
- 호스트 연결을 가능하게 하는 데이터 평면과, 사용자가 Railway에 접근하고 관리하는 대시보드를 구동하는 제어 평면에 새 아키텍처를 구현하는 작업과 병행됨
- 이 업그레이드는 핵심 서비스, 특히 사용자 대면 컴포넌트가 어떤 단일 벤더나 플랫폼에도 의존하지 않도록 만들기 위한 것임