Railway가 밝힌 바에 따르면 다음과 같은 주요 구성요소가 한 번에 사라졌다.
이 때문에 다음 기능들이 정상적으로 동작하지 않았다.
문제는 단순히 몇 개의 VM이 사라진 것이 아니었다. 플랫폼의 오케스트레이션과 라우팅 시스템 자체가 영향을 받은 것이 핵심이었다.
Railway는 일부 사용자에게 애플리케이션을 다시 배포(redeploy)하면 정상 머신으로 라우팅될 수 있다고 안내했다. 이는 워크로드 스케줄링과 라우팅을 담당하는 제어 시스템이 완전히 자동 복구되지 않았음을 시사한다.
커뮤니티 분석에서는 Google Cloud 외부에서 실행되던 워크로드—예를 들어 AWS나 Railway 자체 하드웨어—도 영향을 받았을 가능성이 제기됐다. 이는 플랫폼의 라우팅 상태나 제어 데이터가 갱신되지 못했기 때문일 수 있다. 다만 정확한 기술적 메커니즘은 공식 포스트모템이 공개되지 않아 아직 확정된 것은 아니다.
이번 사건에서 가장 많이 언급된 교훈은 아키텍처 설계와 관련된 부분이다.
Railway는 실제로 AWS, Google Cloud, 그리고 자체 하드웨어 등 여러 환경에 인프라를 분산해 운영하고 있다. 하지만 장애는 여전히 플랫폼 전체에 영향을 미쳤다.
이유는 간단하다.
제어 시스템(control plane)이 어디에 있느냐가 진짜 회복력을 결정하기 때문이다.
계정이 제한되자 단순히 컴퓨팅 리소스만 잃은 것이 아니라 다음 시스템도 동시에 영향을 받았다.
그 결과 단 하나의 계정 제한 이벤트가 전체 플랫폼 장애로 이어졌다.
이번 사건은 또 하나의 논쟁을 불러왔다. 바로 대형 클라우드 서비스의 자동 계정 제재 시스템이다.
클라우드 제공자는 다음과 같은 신호에 따라 계정을 자동으로 제한하거나 정지할 수 있다.
이 때문에 두 가지 운영 리스크가 다시 강조됐다.
Railway의 업데이트와 커뮤니티 보고가 있었지만 몇 가지 핵심 정보는 여전히 공개되지 않았다.
따라서 현재까지의 설명은 Railway 발표와 커뮤니티 분석을 기반으로 한 부분적인 재구성에 가깝다.
5월 19일 Railway 장애는 현대 클라우드 인프라의 중요한 현실을 보여준다.
여러 클라우드를 사용한다고 해서 자동으로 높은 회복력이 보장되는 것은 아니다.
배포·라우팅·오케스트레이션을 담당하는 제어 시스템이 하나의 클라우드 계정에 의존한다면, 그 계정이 잠시라도 사라지는 순간 전체 플랫폼이 동시에 멈출 수 있다.
스타트업과 인프라 플랫폼 모두에게 이번 사건은 익숙하지만 종종 과소평가되는 문제를 다시 상기시켰다.
“모든 것을 관리하는 시스템” 자체에 숨은 단일 장애 지점이 없는지 확인하는 것.
Comments
0 comments