--- title: "레일웨이, 구글 클라우드 계정 정지 한 방에 플랫폼 전체 장애" published: 2026-05-20T00:23:54.000Z canonical: https://jeff.news/article/2875 --- # 레일웨이, 구글 클라우드 계정 정지 한 방에 플랫폼 전체 장애 레일웨이가 구글 클라우드의 잘못된 계정 정지로 약 8시간 동안 플랫폼 전반 장애를 겪었다. 문제는 단순히 GCP 위의 워크로드가 죽은 게 아니라, 라우팅 테이블을 채우는 네트워크 제어 평면이 GCP에 묶여 있어서 AWS와 자체 Metal 환경까지 접근 불가로 번진 점이다. - 레일웨이가 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를 반환하기 시작함 > [!IMPORTANT] > 멀티 클라우드처럼 보여도, 워크로드 발견 경로가 한 클라우드의 제어 평면에 묶여 있으면 장애 반경은 멀티 클라우드 전체로 퍼질 수 있음. ```mermaid 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 호출이 한꺼번에 몰리기 때문에 복구 시스템을 다시 죽이지 않으려면 일부러 천천히 열어야 해요. ## 핵심 포인트 - 구글 클라우드가 레일웨이 운영 계정을 자동 조치로 잘못 정지하면서 대시보드, API, 데이터베이스, GCP 컴퓨트가 내려감 - 엣지 프록시의 라우팅 캐시가 만료되자 GCP 밖의 AWS와 Railway Metal 워크로드도 404를 반환하며 사실상 전 지역 장애로 확대됨 - 레일웨이는 GCP를 데이터 평면의 핫 패스에서 빼고, 데이터베이스 샤드를 AWS와 Metal까지 확장하겠다고 밝힘 ## 인사이트 고가용성 구성을 해도 제어 평면의 발견 경로가 한 벤더 계정에 묶여 있으면 전체 장애가 될 수 있다는 꽤 뼈아픈 사례다. 멀티 클라우드는 리소스를 여러 군데 두는 것보다, 장애 때 의존성 그래프가 실제로 끊기지 않는지가 핵심임.