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

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

2026년 5월 19일 밤, 클라우드 배포 플랫폼 Railway에서 대규모 장애가 발생했습니다. Google Cloud가 Railway의 프로덕션 계정을 잘못된 자동 조치로 중단시키면서, Railway 전체 플랫폼이 약 8시간 동안 사용할 수 없게 됐습니다. 이 사고는 단일 클라우드 제공자에 대한 의존성이 얼마나 위험한지를 보여주는 좋은 사례입니다.

무슨 일이 있었나

2026년 5월 19일 22시 20분 UTC에 Google Cloud가 자동 조치의 일부로 Railway의 프로덕션 계정을 중단 상태로 전환했습니다. 이 조치는 Google Cloud 내 여러 계정에 영향을 미쳤으며, 사전 경고 없이 진행됐습니다.

중단이 발생하자마자 Railway의 대시보드와 API는 즉시 503 오류를 반환했습니다. Google Cloud에 호스팅된 컴퓨트, 데이터베이스, 제어 평면, burst-compute 인프라가 모두 오프라인으로 전환됐습니다.

Railway Metal과 AWS 워크로드는 자체는 계속 실행됐지만, Railway의 엣지 프록시가 Google Cloud의 제어 평면 API에 의존하고 있었기 때문에 라우트 캐시가 만료된 후 404 오류가 확산됐습니다. 결국 Google Cloud 외부에 있는 워크로드도 도달 불가능해지는 상황이 발생했습니다.

사고 타임라인

다음은 사고의 진행 과정입니다.

• 22시 10분 UTC: 자동 모니터링이 API 상태 확인 실패를 감지하고 온콜 담당자에게 알림

• 22시 11분 UTC: 대시보드가 503 오류를 반환하고 사용자가 로그인할 수 없게 됨

• 22시 19분 UTC: Google Cloud Platform이 Railway의 프로덕션 계정을 중단한 것이 근본 원인으로 확인됨

• 22시 22분 UTC: Google Cloud에 P0 티켓을 제출하고 Railway의 GCP 계정 매니저가 직접 관여함

• 22시 29분 UTC: 장애가 선언됨. GCP 계정 접근은 복구됐지만 모든 컴퓨트 인스턴스는 계속 중지 상태였고 영구 디스크는 접근 불가능했음

• 22시 35분 UTC: 캐시된 네트워크 라우트가 만료되기 시작하면서 Railway Metal과 AWS 워크로드가 404 오류를 반환하기 시작함

• 23시 09분 UTC: 첫 번째 영구 디스크가 온라인으로 돌아옴

• 23시 54분 UTC: 모든 영구 디스크가 ready 상태로 복구됐지만 네트워크는 여전히 다운 상태였음

• 5월 20일 00시 39분 UTC: 디스크 ready 상태가 확인됐고, 복구가 Google Cloud 네트워킹 복구에 막힘

• 01시 30분 UTC: 컴퓨트 인스턴스가 복구되기 시작함

• 01시 38분 UTC: 엣지 트래픽이 다시 제공되기 시작했고 네트워킹이 복구됨

• 01시 57분 UTC: 오케스트레이션 및 빌드 인프라가 복구됨. 배포를 일시 중단해서 시스템을 압도하지 않도록 함

• 02시 04분 UTC: 컴퓨트 호스트가 점진적으로 온라인 상태로 복구됨

• 02시 47분 UTC: GitHub가 Railway의 OAuth 및 webhook 통합을 속도 제한하기 시작해 일부 사용자가 로그인할 수 없고 빌드가 차단됨

• 02시 55분 UTC: 대시보드에 다시 접근 가능해짐

• 04시 00분 UTC: API, 대시보드, OAuth 엔드포인트가 동작 중임이 확인됨

• 06시 14분 UTC: 장애가 모니터링 단계로 전환됨

• 07시 58분 UTC: 장애가 해결됨

전체 장애 시간은 약 8시간이었습니다.

발생 원인과 복구 과정

사고의 근본 원인은 Google Cloud의 자동화된 시스템이 Railway의 계정을 잘못된 조치로 중단한 것입니다. Google Cloud는 계정 접근을 7분 만에 복구했지만, 개별 서비스가 자동으로 복구되지는 않았습니다.

Railway의 네트워크 제어 평면은 multi-AZ, multi-zone 구성으로 설계되어 있었지만, 계정 접근이 복구된 후에도 영구 디스크, 컴퓨트 인스턴스, 네트워킹이 각각 따로 복구를 필요로 했습니다. 특히 엣지 프록시가 Google Cloud 내부에 호스팅된 네트워크 제어 평면 API에 의존하는 구조였기 때문에, 캐시가 만료되자 라우팅 테이블을 다시 채울 수 없게 됐습니다.

Railway는 단일 상위 제공자의 조치가 플랫폼 전반 장애로 확산되도록 만든 아키텍처 결정에 대한 책임을 인정했습니다.

##Railway의 예방 조치

Railway는 이번 사고를 통해 몇 가지 중요한 교훈을 얻었고, 다음과 같은 예방 조치를 시행할 계획입니다.

단일 의존성 제거

Railway의 네트워크는 Metal <> GCP <> AWS 사이의 고가용성 광섬유 상호 연결로 구성된 mesh ring으로 설계되어 있었습니다. 그러나 그 안에서도 워크로드 발견 가능성이 Google Cloud 머신에서 실행되는 네트워크 제어 평면 API에 의존하는 문제가 있었습니다. Railway는 현재 이 의존성을 즉시 제거해서 실제 mesh로 만드는 작업을 진행 중입니다. 목표는 어떤 상호 연결이 끊어져도 클라우드 사이에 항상 경로가 남도록 하는 것입니다.

데이터베이스와 장애 조치 개선

Railway는 고가용성 데이터베이스 샤드를 AWS와 Metal 전반으로 확장할 계획입니다. 향후 특정 클라우드의 모든 인스턴스가 즉시 사라져도 데이터베이스 quorum이 서비스를 계속 유지하고, 더 이상 실행 중이 아닌 워크로드를 즉시 장애 조치하도록 만드는 것을 목표로 합니다.

데이터 평면과 제어 평면 재설계

Google Cloud 서비스를 데이터 평면의 핫 패스에서 제거하고 보조 또는 장애 조치 용도로만 유지하는 계획이 진행 중입니다. 핵심 서비스, 특히 사용자 대면 컴포넌트가 어떤 단일 벤더나 플랫폼에도 의존하지 않도록 만드는 것을 목표로 합니다.

개발자에게 주는 시사점

이번 장애는 플랫폼 개발자들에게 몇 가지 중요한 시사점을 남깁니다.

첫째, 인프라 플랫폼을 선택할 때 단일 제공자에 대한 의존성 위험을 반드시 고려해야 합니다. Railway는 상당히 성숙한 플랫폼이었지만, 단일 클라우드 제공자에 대한 의존성 때문에 전체 장애로 이어졌습니다.

둘째, 제어 평면과 데이터 평면을 분리해서 설계하는 것이 중요합니다. Railway의 경우 데이터 평면은 문제없이 동작했지만, 제어 평면이 동작하지 않으면서 전체 서비스가 불가능해졌습니다.

셋째, 장애 조치와 복구 절차를 미리 테스트해두는 것이 중요합니다. Railway는 이전 장애 이후 복원력에 투자해왔지만, 실제 사고에서는 예상보다 복구에 시간이 오래 걸렸습니다.

넷째, 자신의 시스템 아키텍처에서 단일 장애점이 어디인지 확인해야 합니다. 이번 사례처럼 한기업제공자의 자동화된 조치가 전체 플랫폼을 내려놓을 수 있습니다.

요약

Railway의 이번 장애는 클라우드 플랫폼을 사용할 때 단일 제공자 의존성의 위험성을 잘 보여주는 사례입니다. 8시간에 걸친 장애는 많은 개발자와 기업에게 영향을 미쳤으며, 특히 자동화된 CI/CD 파이프라인을 사용하고 있던 팀들은 큰 불편을 겪었습니다.

Railway는 이번 사고를 바탕으로 GCP를 데이터 평면의 핫 패스에서 제거하는 재설계를 진행 중이며, 궁극적으로 모든 핵심 서비스가 어떤 단일 벤더나 플랫폼에도 의존하지 않도록 만드는 것을 목표로 합니다.

클라우드 인프라를 사용하는 개발자라면, 이번 사례를 통해 자신의 시스템 아키텍처에서 단일 장애 점이 어디인지 확인해보는 것이 좋겠습니다.

---

📚 출처

• https://news.hada.io/topic?id=29740