GCP 계정 정지로 Railway 플랫폼 8시간 먹통 사태 발생

사건 발생 시점인 22:20 UTC에 GCP가 Railway의 프로덕션 계정을 부적절하게 정지하면서, Railway의 대시보드, API, 네트워크 인프라가 영향을 받았다. 특히, Railway의 엣지 프록시는 GCP에 호스팅된 네트워크 제어 평면(Network Control Plane) API에 의존하여 라우팅 테이블을 갱신했기 때문에, 캐시 만료 후 AWS 및 자체 서버(Railway Metal)의 워크로드까지 404 에러를 반환하며 서비스 중단이 발생했다. 이는 단일 장애점(Single Point of Failure)이 전체 시스템에 미치는 영향을 보여주는 사례이다.

Railway는 GCP 계정 복구 후에도 지속적 디스크(Persistent Disk), 컴퓨트 인스턴스(Compute Instance), 네트워킹(Networking)을 개별적으로 복구해야 했다. 디스크는 23:54 UTC에 복구되었지만, 핵심 네트워킹 및 엣지 라우팅은 01:30 UTC까지 완전하게 복구되지 못했다. 이로 인해 서비스 중단 시간이 연장되었으며, GitHub의 OAuth 및 웹훅(Webhook) 통합에 대한 속도 제한(Rate Limit)으로 인해 사용자 로그인 및 빌드 작업이 추가적으로 지연되었다. 이는 복구 절차의 복잡성과 외부 서비스 의존성이 시스템 복구에 미치는 영향을 보여준다.

커뮤니티에서는 Railway가 GCP에 과도하게 의존한 점을 지적하며, 단일 공급자 종속성(Vendor Lock-in)의 위험성을 강조했다. Railway는 고가용성(High Availability)을 위해 여러 가용 영역(Availability Zone)과 AWS, GCP, 자체 서버 간의 중복 연결을 구축했지만, 네트워크 제어 평면(Network Control Plane)이 GCP에 묶여 있어 장애 발생 시 다른 환경의 서비스까지 영향을 받았다. 이는 데이터 격리 아키텍처(Data Isolation Architecture)의 중요성을 시사한다.

Railway는 데이터 미저장 정책(Zero-Retention Policy)을 통해 GCP 서비스 의존성을 제거하고, 데이터 평면(Data Plane)의 핫 패스(Hot Path)에서 GCP 서비스를 제외할 계획이다. 또한, AWS 및 자체 서버(Metal)에 데이터베이스 샤드를 확장하여 고가용성 데이터베이스(High Availability Database)를 구축하고, 새로운 아키텍처(New Architecture)를 통해 핵심 서비스의 단일 공급자 의존성을 해소할 예정이다. 이는 장애 복구(Disaster Recovery) 및 서비스 안정성(Service Reliability)을 강화하기 위한 전략으로 풀이된다.