다음 클라우드 중단에 대비하세요

이번 주와 같은 주요 클라우드 사고는 필연적입니다. 다음 네 가지 방법으로貴社의 팀은 즉시 대응할 수 있습니다.

수많은 시간의 생산성 손실, 금융 시스템이 수백만 명의 사용자에게 중단되었습니다, 그리고 잠재적으로 수백억 달러의 손실이 발생할 수 있습니다. 이번 주의 AWS 중단은 글로벌 IT 팀에게 확실히 끔찍한 하루였습니다. 물론, 이것은 지난 클라우드 중단 이후 가장 최근의 글로벌 클라우드 재난이었습니다… 그리고 다음 중단까지입니다.

貴社가 AWS, GCP, Azure, 또는 다른 플랫폼을 사용하는지 여부에 관계없이, 주요 중단은 클라우드 컴퓨팅의 현실입니다. 그러면貴社의 팀은 클라우드 중단의 영향을 완화하기 위해 무엇을 할 수 있을까요? 아래에서, 나는貴社의 팀이 즉시 취할 수 있는 네 가지 단계를 제안합니다.

의심하고 조사하세요.

종종, 팀은 주요 클라우드 회사들이 본질적으로 신뢰할 수 있다고 가정하여 클라우드 계약을 맺습니다. 물론, 가장 신뢰할 수 있는 회사들은 이유가 있기 때문에 그들의 평판을 얻었습니다.同時에, 모든 클라우드와 하이퍼스케일러는 다양한 인프라 옵션을 제공합니다. AWS 북미 지역만 31개의 가용 영역과 31개의 에지 네트워크 위치를 가지고 있습니다. 그리고 일부 옵션은 다른 옵션보다 훨씬 더 신뢰할 수 있습니다.

실제로, 이번 주의 중단 원인이 된 AWS의 US-EAST-1 리전은 2020년, 2021년, 2023년에 주요 중단을 일으켰습니다. 그리고 특정 IT 분야에서 이미 알려진 바와 같이 가장 신뢰할 수 없는 리전으로 알려졌습니다. 많은 회사들은 상황을 이해했지만 리전의 낮은 비용과 풍부한 제공으로 계산된 위험을 감수했습니다. 그러나 중단의 규모를 고려하면, 많은 회사들이 완전히 놀랐을 것이라는 것을 부정할 수 없습니다. 그리고 더 신뢰할 수 있는 리전을 선택했을 것입니다. 저는 이전에 US-EAST-1에서 나쁨을 경험한 후 다른 AWS 리전으로 이동한 IT 리더들을 만났습니다.

여기서의 교훈은 클라우드 인프라 옵션에 대해 조사하고, 클라우드가 무엇이든지 간에, 신중해야 한다는 것입니다. 시작할 수 있는 곳은 무료 도구인 cloudprice, Cloudping, 그리고 하이퍼스케일러 제공 클라우드 서비스 헬스 도구의 역사적 사건 보기입니다.

클라우드 네이티브 대신 이식성을 선택하세요.

클라우드 구성 아키텍처를 설계할 때, 더 간단한 방법은 클라우드 네이티브를 선택하는 것입니다. 그러나 클라우드 제공업체가 제공하는 응용 프로그램을 선택하면, 클라우드가 다운되면 추가적인 클라우드 의존성을 가지게 됩니다.

그런 클라우드 의존성을 피하기 위해, 가능한 경우 독립적이고/또는 오픈 소스 제품을 선택하세요. 몇 가지 예는 아래와 같습니다.

물론, 클라우드 스택을 더 많이 구축하는 것은 더 많은 작업을 의미합니다. 그러나 한번 인프라가 작동하면, 작업을 추가하는 데 거의 차이가 없습니다. 그리고 탄력성과 클라우드 잠금 해제의 이점은 독립적인 옵션을 매우 가치 있게 만듭니다.

실패에 대비하세요.

클라우드 실패가 발생할 수 있으므로, 클라우드 실패를 염두에 두고 제품을 설계하세요. 한 가지 예는 Datadog입니다. 2023년 사건에서, 회사는突然으로 프로덕션의 절반 이상의 Kubernetes 노드를 잃었습니다. 그리고 완전히 재설계된 재난 접근 방식을 취했습니다. 변경 사항에는 아키텍처 병목 현상을 제거하고 기술 부채를 해결하여 부분 실패가 시스템을 통해 캐스케이드하지 않도록 하는 것이 포함되었습니다. 또한, 중단期间에 더 나은 데이터 가용성을 위해 데이터 수집 및 저장을 개선했습니다. 그리고 자동으로 대규모로 복구할 수 있는 시스템을 구축했습니다. 시작할 수 있는 좋은 곳은 Datadog의 “최종 사용자에게 중요한 것을 시작하세요”라는 권고를 따르는 것입니다. 그리고 가장 중요한 것을 보호하기 위한 안전 장치를 구축하세요.

최소 두 개의 클라우드를 사용하세요.

물론, 클라우드 실패에 대한 가장 좋은 방법은 멀티 클라우드 중복성입니다.真正한 멀티 클라우드 유연성을 달성하는 것은 많은 회사들에게巨大한 작업입니다. 왜냐하면 클라우드 간에 인프라를 번역하는 것이 매우 어렵기 때문입니다. 그러나 두 개의 클라우드에서 인프라를 구축하는 것은 강력하고, 종종 가능합니다. 이것을 작동하게 하기 위한 중요한 것은 각 클라우드에서 전문가가 있는 팀을 갖는 것입니다.

물론, 아무것도 公司를 완전히 클라우드 실패의 영향에서 보호할 수 없습니다. 그러나 적절한 조사, 클라우드 이식성 접근 방식, 실패에 대한 엔지니어링, 그리고 “듀얼 클라우드”를真正한 멀티 클라우드로 가는 단계로서 사용함으로써, 公司는 다음 주요 클라우드 사건이 발생했을 때 훨씬 더 민첩할 수 있습니다.