▲

사고 보고서: Google Cloud에 의해 차단된 Railway [해결됨]

 (status.railway.com)
1P by GN⁺ 20시간전 | ★ favorite | 댓글 1개
  • Railway의 광범위한 서비스 장애는 해결됐으며, 원인은 Railway의 Google Cloud 계정 차단으로 확인됨
  • 장애 중 사용자는 "no healthy upstream", "unconditional drop overload", 로그인 실패, 대시보드 접근 불가를 겪을 수 있었음
  • Railway는 Google Cloud 지원팀과 직접 연락해 계정 접근을 복구하고, 제어 평면과 워크로드 복구를 진행함
  • 복구 과정에서 Google Cloud의 네트워킹 문제가 남아 일부 서비스 시작이 막혔고, 비엔터프라이즈 빌드는 일시 제한됨
  • 서비스는 완전히 복구됐지만 비정상으로 감지된 일부 워크로드는 자동 재배포 중이며, 필요하면 사용자가 직접 재배포해야 함

장애 개요와 최종 상태

  • Railway는 광범위한 서비스 장애를 해결했으며, 사후 분석은 Incident Report에서 확인 가능함
  • 장애 기간 동안 사용자는 "no healthy upstream", "unconditional drop overload", 로그인 실패, 대시보드 접근 불가를 겪을 수 있었음
  • 원인은 Railway의 Google Cloud 계정 차단이며, 일부 Railway 서비스가 사용할 수 없는 상태가 됨
  • Railway는 Google Cloud 지원팀과 직접 연락해 계정 접근을 복구하고 워크로드 복구를 진행함
  • 서비스는 완전히 복구됐지만, 비정상 상태로 감지된 일부 워크로드는 자동 재배포 중이며 응답이 정상적이지 않은 서비스는 사용자가 직접 재배포해야 할 수 있음

복구 경과와 사용자 영향

  • 초기 조사와 원인 확인

    • Railway는 대시보드, API, 내부 네트워크의 제어 평면을 구동하는 Google Cloud 인프라를 복구함
    • 상위 클라우드 제공자 접근이 복구된 뒤에도 Railway 대시보드와 클라우드 인프라에서 실행되는 서비스는 수정 배포 전까지 계속 영향을 받을 수 있었음
    • Google Cloud 계정 차단 이후 Railway 플랫폼 팀은 일부 Google Cloud 호스팅 인프라 접근을 확인하고 나머지 서비스 접근을 복구함

  • Google Cloud와 네트워크 문제

    • Railway는 Google Cloud상의 컴퓨트를 복구했지만, Google Cloud 측 네트워킹 문제가 남아 일부 서비스가 시작되지 못함
    • 복구 중에는 Google Cloud에서 호스팅되는 워크로드가 간헐적 문제를 계속 겪을 수 있었음
    • Railway 인프라 팀은 영향을 받은 서비스를 다시 온라인 상태로 만들기 위한 대체 경로도 함께 검토함

  • 빌드와 배포 제한

    • Railway metal 워크로드는 점진적으로 복구되기 시작함
    • 복구 과정에서 빌드 인프라 과부하를 피하기 위해 모든 비엔터프라이즈 빌드가 일시적으로 제한됨
    • 이후 비엔터프라이즈 배포는 일시 중단 상태로 남았고, 엔터프라이즈 배포는 영향을 받지 않음
    • 배포가 다시 가능해진 뒤에도 Google Cloud에 남아 있는 워크로드는 복구 완료 전까지 간헐적 문제를 겪을 수 있었음

  • 현재 조치

    • Railway 서비스는 완전히 복구됐으며, 응답이 정상적이지 않은 서비스는 대시보드나 CLI에서 재배포해야 함
    • 추가 맥락은 FAQ에서 확인 가능하고, 직접 지원이 필요하면 Railway Station에 스레드를 열 수 있음

함께 보면 좋은 글 β

▲
GN⁺ 20시간전  [-]
Hacker News 의견들

  • Railway가 이 장애를 해결했고 사후 분석을 공개함
    https://blog.railway.com/p/incident-report-may-19-2026-gcp-a...
    5월 20일 07:57 UTC 기준 상태 페이지도 올라옴
    https://status.railway.com/incident/I23M92U0

    • 이런 경우에는 Google에 손해배상 청구가 가능해야 한다고 봄. 네트워크 장애나 서비스 실패처럼 약관에 포함될 만한 문제가 아님
    • Railway는 장애가 해결됐다고 하지만 아직 많은 서비스가 502를 반환하며 내려가 있음. 우리 쪽은 수동으로 재배포를 트리거해야 복구됐고, Railway가 자동으로 했어야 한다고 봄
      전체적으로 우리 쪽 다운타임은 11시간 초과였음

  • GCP가 또 스타트업을 내려버린 지 0일째임
    이런 일은 적어도 1년에 한 번은 보는 것 같고, AWS나 Azure에서는 들어본 적이 없음
    진지하게 말하면 그래서 GCP를 쓰지 않음. 빅3 중 가장 쓰기 편한 클라우드인데, 이런 평판 때문에 스스로 망쳐버림

    • 반대로 GCP에서 심각한 장애가 난 건 기억이 잘 안 남. AWS/Azure는 1년에 몇 번씩 재앙적으로 내려가는 것 같음
    • AWS는 더 효율적으로 함. us-east-1이 내려가면 스타트업 여러 곳을 한꺼번에 내려버림
    • https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
      Azure도 작년에 Azure와 O365 서비스 전체의 프런트도어를 망가뜨렸음
      이 회사들은 각자 잘하는 영역이 있지만, 가끔 크게 망침
    • AWS가 우리 서비스를 너무 심하게 스로틀링해서 운영할 수 없었던 적이 있음. 그들이 한 달 동안 우리 성장을 멈췄다는 글을 쓰려 했지만 이제는 큰 의미가 없어 보임
    • 우리도 같은 이유로 GCP는 건드리지 않음

  • 다들 Google을 탓하고 싶어 하지만, Railway를 꽤 오래 써본 입장에서는 결론을 내리기 전에 GCP의 입장도 들어보고 싶음. Railway에서도 이런 문제가 전에도 있었고, 그 팀이 처리하는 방식은 신뢰를 주지 못했음
    어쨌든 이번 일이 나에게는 마지막 한계였음

    • 나도 일화 수준이지만 동의함. Railway 개발팀은 여기저기 바이브 코딩을 섞어가며 꽤 느슨하게 움직이는 느낌임. “아직 스타트업이라 좀 봐달라”는 수준이 있고, Railway는 그 선을 넘음
    • 맞음. 다른 스레드에서는 클라우드 제공자를 강하게 비판하는 계정들이 많이 보이는데, 정작 이 분노의 흐름에서 근본 원인을 궁금해하거나 그 가능성을 따져보려는 태도가 거의 없는 게 이상함
    • 2년 전에 지원이 필요했는데 너무 독해서 그냥 Vercel로 옮기고 꺼지라고 했음
      다른 서비스에도 비슷한 게 필요해서 찾다가 coolify를 발견함. coolify를 쓸 수 있는데 Railway를 쓸 이유는 전혀 없음
    • 구체적인 과거 사례를 알려줄 수 있으면 읽어보고 싶음
    • 내가 알아서는 안 될 세부 내용을 들었음. 이번 건은 100% Google 책임이라고 자신 있게 말할 수 있고, Railway가 더 공유하지 못한다면 실망할 것 같음
      GCP를 아예 피하는 것 말고는 Railway가 막을 방법이 정말 없었음

  • 2024년 5월 UniSuper 장애도 있었음: https://cloud.google.com/blog/products/infrastructure/detail...
    https://www.unisuper.com.au/about-us/media-centre/2024/a-joi...
    UniSuper CEO Peter Chun과 Google Cloud CEO Thomas Kurian의 공동 성명에 따르면, UniSuper의 Private Cloud 서비스를 프로비저닝하는 과정에서 부주의한 설정 오류가 발생했고 결국 UniSuper의 Private Cloud 구독이 삭제됨
    Google Cloud는 전 세계 어떤 Google Cloud 고객에게도 전례가 없던 고립된 “단 한 번뿐인 사건”이라고 했지만, 이 구독 삭제가 두 지역 모두의 삭제를 유발해 복구에 수백 대의 가상 머신, 데이터베이스, 애플리케이션 복구가 필요했음

    • 당시 UniSuper 문제에 대해 글을 썼음: https://danielcompton.net/google-cloud-unisuper
      꽤 심각한 버그였고, 그들의 VMWare 환경이 1년 만료일을 가진 상태로 생성됐는데 Google Cloud 관점에서는 하나의 “리소스”였음
    • “Private Cloud 구독 삭제가 두 지역 모두의 삭제를 유발했다”는 건 단일 장애점이라고 부르는 것이고, 안전을 책임져본 사람이라면 누구나 악몽처럼 여길 일임
    • 구독을 닫거나 삭제하자마자 전 세계적으로 연쇄 삭제되는 구조는 재앙의 조리법처럼 들림. 왜 삭제 표시만 해두고 하루나 일주일 뒤에 지우지 않는지 모르겠음

  • 월 사용액이 큰 회사에서 대체 이런 일이 어떻게 생기는지 모르겠음. 이전 직장에서 AWS에서 의심스러운 워크로드가 돌았을 때는 TAM이 조치 전에 먼저 연락했음
    이번 건은 뭔가 잘못된 AI 자동화였고, GCP가 사람에게 실제로 연락해 응답받는 걸 싫어하는 듯해서 외주 인력이 몇 시간 뒤 지원 큐에서 보고 정형 답변만 보낸 상황 아니었을까 싶음

    • GCP 지원과 관련된 일이라면 이제 아무것도 놀랍지 않음. 우리에게는 전혀 필요 없지만 지난 6년 동안 Account Executive가 12명 넘게 바뀌었고, 모두 완전히 쓸모없었음
      매번 자기소개를 하고 엔지니어링 인력과 미팅을 잡아달라고 하며, 우리와 전혀 상관없는 정형 슬라이드 덱을 들고 와서 웃음만 나왔고, 다음 연락은 새 AE가 배정됐을 때였음
      GCP와 그 서비스들은 좋아하고 수년간 만족했지만, 사람 쪽은 정말 형편없고 왜 굳이 운영하는지도 모르겠음
    • 다른 스레드에도 의미 있는 답변이 있었던 것 같음. 우리도 계정을 다시 되찾긴 했지만, Account Rep과 CSM이 있어도 무슨 일이 벌어진 건지 파악하는 데 시간이 걸렸음
      담당자가 없었다면 더 나빴을 수도 있음
    • Google이니까 그럼. 서비스를 쓰게 해주다가, 네가 규범에서 벗어나는 순간 정지시킴

  • 공개 API를 운영하는 입장에서 Railway IP에서 오는 스팸이 말도 안 되게 많음. 남용 방지가 형편없고, 이번 일이 운영을 개선하는 계기가 됐으면 함

    • 호스팅 회사를 운영할 때 핵심 충돌이 바로 이거임. 가입을 쉽게 만들면 신규 사용자가 많이 오지만 남용도 많이 들어옴
      남용 방지책을 넣으면 시끄러운 오탐이 생기고, 이번 GCP 건도 그럴 수 있음
      호스팅 회사를 운영하는 사람은 부럽지 않음. 인터넷은 표면 아래가 정말 지저분함
      덧붙이면 AWS는 이 부분을 정말 잘함. 약 30년간의 소매 사기와 남용 대응 경험 덕분일 듯함

  • 잠깐, Railway가 GCP 위에서 돌아가는 거였나? “다른 클라우드 위에 클라우드를 만들지 않는다”고 크게 말하지 않았나?
    아니면 VPS를 빌리는 게 아니라 클라우드 제공자에게서 베어메탈만 빌린다는 뜻이었나?
    적어도 하이퍼스케일러 중 하나에 돈만 내는 게 아니라 코로케이션을 하고 스택을 더 많이 소유하는 다른 제공자가 생겼다고 생각해서 기대했음
    https://blog.railway.com/p/heroku-walked-railway-run

    • Wayback Machine으로 본 연결된 글에는 이렇게 되어 있음
      “첫날부터 이 생각을 최전선에 두고 있었다.
      또 우리가 직감한 건 다른 클라우드 위에 클라우드를 만들 수 없다는 것이다. Railway의 비즈니스, 결국 고객의 비즈니스가 가능한 한 견고하도록 자체 서버를 운영하고 다른 클라우드와 잘 공존하는 실무에 수년을 쏟았다.”
    • 맞고, 그래서 화남. 그들은 거짓말했음. GCP에 완전히 의존하고 있었음
      이제 조사를 좀 해야겠음. 이것보다 좀 더 안정적이고, 한 회사의 변덕에 덜 의존하는 게 필요함
      Railway 입장에서도 안 좋은 일인 게, 그들의 큰 주장인 평화로운 소프트웨어 배포의 핵심을 바로 찌르기 때문임. 이건 혼돈임

  • Railway가 자체 데이터센터를 만들고 있는 줄 알았음 [0]
    “사실상, 다른 사람의 클라우드 위에 클라우드를 만들 수는 없다.”
    정말 그렇네…
    [0] https://blog.railway.com/p/launch-week-02-welcome

    • Vercel은 그걸 해내는 것처럼 보임. PlanetScale도 데이터베이스 한정으로는 그렇고, 어차피 모든 것은 데이터베이스임

  • Railway에 가입할 때 시스템 남용, 암호화폐 채굴 등에 관한 약관을 읽고 이해했는지 확인하는 방식이 특이함
    추측하자면 많은 사용자가 무료 티어를 남용해서 서비스 제공자와 문제를 일으키는 듯함
    경쟁사 입장이어도 Railway가 이런 타격을 받는 걸 즐겁게 보진 않지만, 무료 컴퓨트는 온갖 이상한 사용자를 끌어들임. 우리도 겪어봤고, 유입 상단이 줄어들더라도 초기에 무료 컴퓨트를 피하기로 했음

  • Google만 탓하기는 어렵다고 봄. Railway는 플랫폼 안정성을 유지하는 데 점점 더 어려움을 겪는 것처럼 보임
    이런 일이 전체 서비스를 내려서는 안 됨. 말 그대로 안정적인 백엔드를 제공하는 게 사업이라면 백업이 있어야 함. 내 눈에는 부실한 계획으로 보임

    • 무슨 뜻인지 잘 모르겠음. Railway가 모든 고객 프로젝트를 호스팅하기 위해 멀티 클라우드 아키텍처를 써야 한다고 정말 기대하는 건가? 전체적으로 보면 그게 오히려 가용성을 낮출 것 같음
    • 재해 복구는 꽤 비싸지 않나? 특히 Railway 규모에서는 더 그럴 듯함
답변달기