클라우드 컨트롤 플레인이 실패할 때
클라우드 장애의 원인이 인프라가 아닌 컨트롤 플레인 실패로 이동하고 있다. 다중 리전, 이중화 등 기존 복원력 전략만으로는 관리 계층 장애 시 대응이 불가능해질 수 있으며, 이는 IDC와 클라우드 운영 환경에서 중요한 아키텍처적 맹점으로 지적된다.
얼마 전 한 기업과 작업한 적이 있다. 그 기업은 모든 것을 제대로 했다고 믿고 있었다. 워크로드를 여러 리전에 분산하고, 주요 데이터 저장소를 복제했으며, 페일오버 절차를 문서화하고, 자동화에 상당한 투자를 했다. 서류상으로는 성숙한 클라우드 배포처럼 보였다. 그러다 핵심 제공업체 중 하나에서 컨트롤 플레인 문제가 발생했다. 인프라 자체가 완전히 사라진 것은 아니었지만, 관리 계층이 불안정해지면서 팀은 적시에 변경을 가하거나 예상했던 복구 조치를 실행하거나, 환경의 상태를 실시간으로 신뢰할 수 없게 됐다. 실패한 것은 단순한 컴퓨트나 스토리지가 아니었다. 실패한 것은 클라우드의 제어 메커니즘이 항상 존재할 것이라는 기업의 가정이었다.
이 경험은 점점 커지는 문제의 핵심을 드러낸다. 클라우드 신뢰성은 최근 다시 주목받고 있는데, 이는 점점 더 많은 장애가 격리된 인프라 장애가 아닌 컨트롤 플레인 실패와 연결되기 때문이다. 업타임 인스티튜트 보고서는 이러한 변화를 강조했으며, 이는 모든 진지한 아키텍트의 주의를 끌어야 한다. 관리 계층이 문제가 될 때 폭발 반경은 대부분의 조직이 예상하는 것보다 훨씬 더 넓어질 수 있다.
수년 동안 업계는 주로 인프라 측면에서 복원력을 논의해 왔다. 우리는 존, 리전, 백업, 서비스 이중화에 집중한다. 물론 이러한 요소들은 여전히 중요하다. 그러나 그것만으로는 더 이상 전체 이야기를 설명하지 못한다. 클라우드는 단순히 서버, 스토리지 시스템, 네트워크의 집합이 아니다. 또한 API, 오케스트레이션 계층, 아이덴티티 시스템, 정책 엔진, 서비스 컨트롤러, 자동화 프레임워크를 중심으로 구축된 거대한 운영 모델이기도 하다. 이러한 상위 제어 구조가 깨지거나 손상되면 복구 계획은 매우 빠르게 무너질 수 있다.
또 다른 아키텍처 문제
우선 아키텍트들은 컨트롤 플레인이 모든 조건에서 안정적으로 유지될 것이라고 안전하게 가정할 수 있는 보이지 않는 계층이 더 이상 아니라는 점을 받아들여야 한다. 이제 그것은 실패 도메인의 일부이기 때문에 아키텍처 문제의 일부가 됐다. 워크로드, 스케일링 로직, 네트워크 정책, 페일오버 조치, 서비스 권한, 운영 결정이 모두 그 계층이 정상적으로 작동하는 데 의존한다면, 컨트롤 플레인 실패는 단일 애플리케이션이나 리전 배포보다 훨씬 더 많은 것을 위태롭게 할 수 있다.
많은 조직이 단순히 이중화를 갖추고 있다는 이유만으로 자신들이 복원력이 있다고 확신하는 것을 보았다. 그것으로는 충분하지 않다. 컨트롤 플레인 아래의 이중화는 그 위에서 발생하는 실패로부터 당신을 완전히 보호하지 못한다. 아래에는 건강한 인프라가 있지만 중요한 시스템을 올바르게 운영하는 데 필요한 조정을 할 수 없게 될 수 있다. 이것이 바로 아키텍처적 맹점이며, 이러한 사건들의 가시성이 높아지면서 점점 더 분명해지고 있다.
멀티리전 설계만으로는 충분하지 않다
가장 흔한 반응 중 하나는 멀티리전 아키텍처가 답이라는 것이다.