레일웨이, 구글 클라우드 계정 정지 한 방에 플랫폼 전체 장애

• 레일웨이가 2026년 5월 19일 22:20 UTC부터 5월 20일 06:14 UTC까지 약 8시간짜리 플랫폼 전반 장애를 겪음

  • 원인은 구글 클라우드가 레일웨이의 프로덕션 계정을 자동 조치로 잘못 정지한 것
  • 대시보드와 API는 503을 반환했고, 사용자는 로그인도 못 했음
  • GCP 위에 있던 컴퓨트 워크로드, API, 제어 평면, 데이터베이스가 한꺼번에 영향권에 들어감

• 진짜 문제는 “GCP가 죽어서 GCP 워크로드만 죽었다”가 아니었다는 점임

  • 레일웨이의 엣지 프록시는 라우팅 테이블을 GCP에 있는 네트워크 제어 평면 API에서 받아옴
  • 처음에는 캐시된 라우트가 남아 있어서 Railway Metal과 AWS 워크로드는 살아 있었음
  • 그런데 라우트 캐시가 만료되자 엣지가 활성 인스턴스를 찾지 못했고, GCP 밖의 워크로드도 404를 반환하기 시작함

sequenceDiagram
    participant 구글클라우드
    participant 레일웨이제어평면
    participant 엣지프록시
    participant 사용자워크로드
    participant 사용자
    구글클라우드->>레일웨이제어평면: 운영 계정 정지
    레일웨이제어평면--x엣지프록시: 라우팅 테이블 갱신 실패
    엣지프록시->>사용자워크로드: 기존 캐시로 일시 라우팅
    엣지프록시--x사용자워크로드: 캐시 만료 후 경로 확인 실패
    사용자->>엣지프록시: 서비스 요청
    엣지프록시-->>사용자: 404 또는 503 반환

• 타임라인을 보면 복구도 “계정 풀림 = 끝”이 아니었음

  • 22:19 UTC에 원인이 GCP 계정 정지로 확인됐고, 22:29 UTC에 계정 접근은 복구됨
  • 하지만 컴퓨트 인스턴스는 멈춰 있었고 영구 디스크도 바로 접근 가능한 상태가 아니었음
  • 23:54 UTC에 디스크가 준비 상태로 돌아왔지만, 네트워킹 복구가 막혀 장애가 몇 시간 더 이어짐
  • 01:38 UTC쯤 엣지 트래픽이 다시 처리되기 시작했고, 06:14 UTC에 모니터링 단계로 넘어감

• 복구 중에는 2차 장애도 터짐

  • 빌드와 배포는 플랫폼 전체에서 잠시 막혔고, 큐에 쌓인 배포를 한 번에 풀지 않도록 점진적으로 처리함
  • GCP 장애로 캐시가 날아가면서 GitHub OAuth와 웹훅 호출이 몰렸고, GitHub가 레일웨이를 레이트 리밋함
  • 그 결과 일부 사용자는 로그인과 빌드가 다시 막혔고, 서비스 약관 동의 기록도 리셋돼 대시보드 재방문 때 다시 동의해야 했음

• 레일웨이는 이번 장애의 핵심을 “벤더 탓”으로만 돌리지 않았음

  • 구글 클라우드의 잘못된 자동 조치가 트리거였지만, 단일 업스트림 액션이 플랫폼 전체 장애로 번지게 만든 아키텍처는 레일웨이 책임이라고 인정함
  • 사용자 입장에서는 구글이 실패했는지 레일웨이가 실패했는지가 중요하지 않고, 그냥 제품이 안 되는 거니까

• 레일웨이가 내놓은 재발 방지 방향은 꽤 구체적임

  • Metal, GCP, AWS를 잇는 메시 링에서 워크로드 발견 기능이 GCP 제어 평면 API에 묶여 있던 의존성을 제거하겠다고 함
  • 고가용성 데이터베이스 샤드를 AWS와 Metal까지 확장해 특정 클라우드의 모든 인스턴스가 사라져도 쿼럼을 유지하도록 바꿀 계획임
  • GCP 서비스는 데이터 평면의 핫 패스에서 빼고, 보조 또는 장애 조치 용도로만 남기는 방향을 검토 중임

기술 맥락

• 이번 사건의 핵심은 멀티 클라우드 자체가 아니라 제어 평면의 위치예요. 워크로드는 AWS와 Metal에도 있었지만, 엣지가 “어느 인스턴스로 보내야 하는지”를 알아내는 경로가 GCP에 묶여 있었기 때문에 캐시가 끝난 순간 전체가 흔들렸어요.

• 레일웨이가 GCP를 데이터 평면의 핫 패스에서 빼겠다는 건 사용자 요청 처리 경로에서 특정 벤더 계정을 필수 의존성으로 두지 않겠다는 의미예요. 장애 대응에서 중요한 건 평소의 중복 구성보다, 실제 장애 때 요청 경로가 계속 성립하느냐거든요.

• 데이터베이스 샤드를 AWS와 Metal까지 넓히려는 이유도 비슷해요. 특정 클라우드가 통째로 내려가도 쿼럼을 유지해야 제어 평면과 사용자 워크로드 복구 판단을 계속 할 수 있어요.

• 배포 큐를 한 번에 풀지 않은 것도 실무적으로 중요한 선택이에요. 장애 직후에는 밀린 작업, 재시도 요청, 외부 API 호출이 한꺼번에 몰리기 때문에 복구 시스템을 다시 죽이지 않으려면 일부러 천천히 열어야 해요.