Incident Library

IL-0356 Railway · 2026-09-30networking

Railway 에 호스팅된 모든 도메인으로 오는 새 연결이 5분 동안 HTTP 404 를 받았다

Railway 의 분산 라우팅 제어 플레인은 오리진 프록시에 도메인마다 그 뒤의 워크로드로 사용자 요청을 어떻게 보낼지 알려 주는 시스템이다. Railway 는 큰 클라우드 장애에도 버티도록 최근 이 제어 플레인을 모놀리스에서 떼어 내 전 세계에서 운영했고, 배포 파이프라인도 병렬로 돌렸다. 모놀리스 시절에는 파이프라인 하나가 스키마 변경과 서비스 배포의 순서를 지켰다. 분리한 뒤에는 둘이 서로 다른 파이프라인으로 배포됐고, 파이프라인 설정의 오류로 스키마 마이그레이션까지 병렬로 돌 수 있었다.

Railway 는 고객이 서비스 앞에 로그인을 둘 수 있게 하는 인증 계층을 만들고 있었다. 이 기능에는 라우팅 데이터를 담는 데이터베이스의 데이터 타입을 바꾸는 스키마 변경과, 새 테이블 형식을 읽는 라우팅 서비스 새 버전이 함께 필요했다. 엔지니어는 2026-09-30 07:29 UTC 에 스테이징에서 시험한 이 변경을 병합했다. 07:35 무렵 새 라우팅 서비스가 마이그레이션보다 먼저 모든 리전에 배포됐고, 아직 없는 컬럼을 조회하면서 모든 경로 조회가 오류를 냈다. 이 변경은 조회가 실패했을 때 도메인이 마지막 경로로 되돌아가는 대체 동작도 바꿨다. 그래서 오리진 프록시는 조회 실패를 경로가 없는 도메인처럼 다뤄 404 를 냈고, 그 도메인의 마지막 경로로 되돌아가지 못했다. 모든 도메인의 새 연결이 오류를 받았고, 라우팅 서비스가 맡은 사설 네트워크 DNS 조회 일부도 실패했다.

07:40 무렵 CI 시스템이 스키마 변경을 적용했고, 라우팅 서비스의 다음 재시도가 성공해 라우팅이 돌아왔다. 07:44 에 엔지니어들이 원인을 찾았고 07:47 에 완전 복구를 확인했다. 롤백은 필요하지 않았다. Railway 는 07:48 에 상태 페이지에 공개 사고를 올렸고 08:17 에 해결로 표시했다. 데이터 손실은 없었다.

심각도
–
영향 범위
New connections to all domains hosted on Railway, custom and *.up.railway.app, returned HTTP 404; public access and some private networking lookups between services failed; existing connections and running workloads were not affected
영향 사용자
all customers
지역
all regions
감지까지
0m
복구까지
5m

증상

2026-09-30 07:35 UTC 무렵부터 Railway 에 호스팅된 모든 도메인이 새 연결에 HTTP 404 not found 를 냈다. 경로 조회가 실패하기 시작하자 곧바로 내부 알림이 울려 당직 대응팀이 소집됐다.

오류는 커스텀 도메인과 *.up.railway.app 도메인에서 모든 리전에 걸쳐 났다. 이미 맺어진 연결은 끊기지 않았고 사용자 워크로드도 계속 돌았다. 스키마가 맞지 않는 동안 사용자 페이지를 새로 방문하면 오류를 받았다.

라우팅 서비스는 사설 네트워크 DNS 도 맡고 있어서, 같은 시간 동안 서비스 사이의 사설 네트워킹 조회 일부도 실패했다.

라우팅 서비스는 아직 없는 컬럼을 조회했고 모든 경로 조회가 오류로 끝났다. 오리진 프록시는 조회 실패를 경로가 없는 도메인과 똑같이 다뤄 404 를 냈고, 그 도메인에서 마지막으로 본 경로로 되돌아가지 않았다.

07:40 무렵 스키마 변경이 적용되자 라우팅 서비스의 다음 재시도가 성공했고 도메인 라우팅이 곧바로 정상으로 돌아왔다. 엔지니어들은 07:44 에 원인을 찾았다. 원인은 새 라우팅 서비스가 자기가 의존하는 스키마 변경보다 먼저 올라온 데 있었다.

증상 서비스 중단DNS 조회 실패

원인

원인 배포 결함

구성 요소 네트워크 컨트롤 플레인데이터베이스CI 시스템
기여 요인 안전하지 않은 실패 동작단계적 배포 부재과도한 영향 범위
촉발
07:29 에 병합된 라우팅 제어 플레인 변경을 배포할 때, 파이프라인 설정의 오류로 스키마 변경 파이프라인과 새 라우팅 서비스 배포 파이프라인이 동시에 돌았다. 두 파이프라인이 경쟁하다가 새 라우팅 서비스가 스키마 변경보다 먼저 모든 리전에 올라왔다.

감지

경로 조회가 실패하기 시작하자 곧바로 내부 알림이 울려 당직 대응팀이 소집됐다.

조치

후속 조치

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 네트워크 컨트롤 플레인, 데이터베이스, CI 시스템. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.