구글 클라우드 계정 차단으로 레일웨이 장애 발생, 일부 워크로드는 재배포 필요

• 레일웨이가 광범위한 서비스 장애를 겪었고, 원인은 구글 클라우드 계정 차단으로 확인됨

  • 초기에는 no healthy upstream, unconditional drop overload, 로그인 실패, 대시보드 접근 불가 같은 오류가 보고됨
  • 이후 레일웨이는 상위 클라우드 제공자 접근이 복구됐고, 전체 서비스도 회복됐다고 공지함

• 장애 영향 범위가 꽤 컸음

  • 레일웨이 대시보드, API, 내부 네트워크의 제어 평면이 구글 클라우드 인프라에 의존하고 있었음
  • 구글 클라우드에 올라간 일부 워크로드도 영향을 받았고, 복구 중에도 간헐적 문제가 이어질 수 있다고 안내됨

• 복구 과정은 한 번에 끝난 게 아니라 단계적으로 진행됨
  • 레일웨이는 구글 클라우드 지원팀과 직접 연락해 계정 접근 문제를 에스컬레이션함
  • 일부 구글 클라우드 호스팅 인프라 접근이 먼저 복구됐고, 나머지 서비스 접근을 순차적으로 되살리는 흐름이었음
  • 컴퓨트 자원은 복구됐지만 구글 클라우드 쪽 네트워킹 이슈 때문에 서비스가 시작되지 못하는 단계도 있었음

sequenceDiagram
    participant 사용자
    participant 레일웨이
    participant 구글클라우드
    participant 워크로드
    사용자->>레일웨이: 대시보드 접속과 배포 요청
    레일웨이->>구글클라우드: 제어 평면과 인프라 접근 시도
    구글클라우드-->>레일웨이: 계정 차단으로 접근 실패
    레일웨이-->>사용자: 로그인 실패와 정상 업스트림 없음 오류
    레일웨이->>구글클라우드: 지원팀에 에스컬레이션
    구글클라우드-->>레일웨이: 접근 복구
    레일웨이->>워크로드: 비정상 서비스 자동 재배포
    사용자->>워크로드: 필요 시 수동 재배포

• 복구 안정화를 위해 빌드도 임시로 제한됨

  • 레일웨이는 자체 메탈 워크로드가 점진적으로 회복되는 동안 비기업 빌드를 일시적으로 제한한다고 공지함
  • 이유는 빌드 인프라가 복구 직후 한꺼번에 몰리는 작업을 버티지 못할 수 있기 때문임

• 최종 상태는 “서비스는 복구됐지만 일부 사용자는 손을 봐야 할 수 있음”에 가까움

  • 레일웨이는 비정상으로 감지되는 워크로드를 자동 재배포 중이라고 밝힘
  • 그래도 서비스가 정상 응답하지 않으면 사용자가 직접 재배포해야 함
  • 상세 사후 분석은 안정성이 확인된 뒤 별도로 공개하겠다고 예고함

• 개발자 입장에서 이 사건은 꽤 현실적인 클라우드 의존성 사례임

  • 플랫폼 서비스가 멀티 클라우드처럼 보여도 핵심 제어 평면이 특정 클라우드 계정에 묶여 있으면 장애 반경이 커질 수 있음
  • 특히 배포 플랫폼을 쓰는 팀이라면 “내 앱이 죽었나”보다 먼저 “플랫폼 제어 평면과 상위 클라우드가 살아 있나”를 봐야 하는 상황이 생김

기술 맥락

• 이번 사건의 핵심 선택은 레일웨이가 대시보드, API, 내부 네트워크 제어 평면을 구글 클라우드 인프라 위에서 운영하고 있었다는 점이에요. 사용자는 레일웨이라는 플랫폼을 쓰지만, 실제 운영 레이어 일부는 상위 클라우드 제공자에 묶여 있었던 거죠.

• 문제가 커진 이유는 계정 차단이 단순히 몇 개 서버를 멈춘 수준이 아니라 제어 평면 접근까지 흔들었기 때문이에요. 제어 평면이 막히면 사용자는 앱 상태를 확인하거나 재배포를 누르는 기본 작업도 어려워질 수 있거든요.

• 복구 과정에서 컴퓨트 접근이 돌아와도 네트워킹 문제가 남아 서비스가 바로 시작되지 못했다는 점도 중요해요. 클라우드 장애는 가상머신 하나만 켜진다고 끝나는 게 아니라 네트워크, 배포 파이프라인, 상태 확인까지 같이 맞물려야 정상화돼요.

• 비기업 빌드를 임시로 제한한 것도 운영적으로는 자연스러운 선택이에요. 장애 직후에는 밀린 배포와 재시도가 한꺼번에 몰리기 때문에, 빌드 인프라를 보호하지 않으면 복구된 시스템이 다시 흔들릴 수 있어요.