클라우드 버스팅이란 무엇인가요?

클라우드 버스팅은 클라우드 컴퓨팅의 구성으로, 컴퓨팅 용량에 대한 수요가 급증하면 애플리케이션이 프라이빗 클라우드 또는 온프레미스 데이터 센터에서 실행되다가 퍼블릭 클라우드로 '버스트'됩니다. 기본적으로 오버플로 밸브 역할을 하므로 비공개 인프라가 한계에 도달하면 트래픽이 자동으로 퍼블릭 클라우드 서비스로 전달되어 서비스 중단을 방지합니다. 줄이 너무 길어질 때만 추가 계산대를 여는 소매점과 비슷하다고 생각하면 됩니다. 클라우드 버스팅 설정은 하이브리드 클라우드 배포의 한 유형입니다.

표준 클라우드 확장 모델에서는 기업이 하나의 환경에서 모든 것을 처리하려고 할 수 있습니다. 그러나 연중 가장 바쁜 날을 처리할 수 있을 만큼 충분한 물리적 서버를 보유하고 있다면 나머지 364일 동안은 해당 서버가 비어 있고 사용되지 않는다는 의미입니다. 클라우드 버스팅은 조직이 자체 데이터 센터의 기본 용량에 대한 비용을 지불하고 실제로 필요할 때만 추가 퍼블릭 클라우드 리소스에 대한 비용을 지불할 수 있도록 함으로써 이 문제를 해결하는 데 도움이 될 수 있습니다. 이러한 접근방식을 사용하면 기업은 항상 필요하지 않은 값비싼 하드웨어를 구매하지 않고도 갑작스러운 트래픽 급증을 처리할 수 있습니다.

클라우드 버스팅 작동 방식

클라우드 버스트의 메커니즘을 이해하기 위해 프라이빗 클라우드를 물탱크라고 상상해 보겠습니다. 정상적인 상황에서는 물(데이터 트래픽)이 탱크 용량 내에 머무릅니다. 그러나 갑작스러운 폭풍(트래픽 급증)이 닥치면 탱크가 넘칠 위험이 있습니다.

클라우드 버스팅 설정에서 IT팀은 일반적으로 리소스 사용량이 약 70~80%에 도달할 때 '트리거' 또는 기준점을 구성합니다. 이 기준점을 넘으면 시스템이 자동으로 밸브를 열어 보조 탱크, 즉 퍼블릭 클라우드로 전환합니다. 애플리케이션은 계속 원활하게 실행되며 오버플로 트래픽은 퍼블릭 클라우드 리소스로 라우팅됩니다. 폭풍이 지나가고 트래픽 수준이 다시 낮아지면 시스템은 밸브를 닫고 퍼블릭 클라우드 리소스를 사용 중단하여 작업을 프라이빗 클라우드로만 되돌립니다.

클라우드 버스팅 유형

팀에 필요한 제어 또는 자동화 수준에 따라 이러한 버스트를 설정하는 방법은 다양합니다.

수동 버스팅: 관리자가 수동으로 퍼블릭 클라우드 리소스를 추가할 때 발생합니다. 이는 계획된 소프트웨어 출시와 같이 예측 가능한 이벤트에 유용할 수 있습니다. 사람이 추가 용량을 언제 시작하고 중지할지 정확히 결정할 수 있기 때문입니다.
자동 버스팅: 이 메서드는 소프트웨어 정책을 사용하여 버스트를 트리거합니다. 시스템은 리소스 사용량이 특정 한도에 도달한 것을 감지하면 사람의 개입 없이도 퍼블릭 클라우드에서 자동으로 추가 리소스를 가동할 수 있습니다.
분산형 부하 분산: 이 접근방식은 트래픽을 프라이빗 클라우드와 퍼블릭 클라우드 모두에 동시에 분산합니다. 사용자 요청을 사용자에게 가장 가까운 위치 또는 당시 가장 많은 용량을 사용할 수 있는 위치로 라우팅합니다.

클라우드 버스팅을 사용해야 하는 경우

클라우드 버스팅이 모든 애플리케이션에 적합한 것은 아니며, 특히 비공개 네트워크를 벗어날 수 없는 복잡하고 민감한 데이터에 의존하는 애플리케이션의 경우 더욱 그렇습니다. 일반적으로 다음과 같은 상황에서 속도와 업타임이 중요한 계절성 또는 예측 불가능하거나 변동하는 수요 패턴이 있는 워크로드에 가장 적합합니다.

계절성 또는 예상되는 수요 급증

소매업체는 블랙 프라이데이 또는 사이버 먼데이와 같은 인기 쇼핑 이벤트 기간에 트래픽이 급증하는 경우가 많습니다. 클라우드 버스팅을 사용하면 이러한 비즈니스에서 퍼블릭 클라우드를 사용하여 며칠 동안 수백만 명의 쇼핑객을 처리한 다음, 성수기가 끝나면 프라이빗 인프라로 다시 축소할 수 있습니다.

리소스 집약적이고 기간이 제한된 작업

데이터 과학자와 엔지니어는 복잡한 시뮬레이션, AI 모델 학습 또는 3D 렌더링과 같은 기타 대규모 컴퓨팅과 같은 고성능 컴퓨팅(HPC) 작업을 실행하는 경우가 많습니다. 이러한 작업에는 몇 시간 동안 수천 대의 서버가 필요할 수 있습니다. 버스팅을 사용하면 팀에서 긴 슈퍼컴퓨팅 대기열에서 기다리거나 활용도가 낮은 슈퍼컴퓨터를 빌드하는 대신 이 막대한 성능을 일시적으로 임대할 수 있습니다.

개발 및 테스트(Dev/test)

소프트웨어 개발자는 새로운 코드나 업데이트를 테스트하기 위해 임시 환경을 자주 가동해야 합니다. 주 비공개 서버의 공간을 차지하는 대신 이러한 테스트 환경을 퍼블릭 클라우드로 버스트할 수 있습니다. 이렇게 하면 프로덕션 환경을 안전하고 안정적으로 유지할 수 있습니다.

재해 복구(DR) 지원

정전이나 자연재해로 인해 로컬 데이터 센터가 오프라인 상태가 되면 클라우드 버스팅이 재해 복구를 지원하는 장애 조치 메커니즘으로 작동할 수 있습니다. 시스템은 기본 사이트가 수정될 때까지 애플리케이션을 계속 실행하기 위해 트래픽을 퍼블릭 클라우드로 리디렉션할 수 있습니다.

조직은 클라우드 버스팅을 어떻게 구현할 수 있을까요?

클라우드 버스팅을 구현하려면 두 개의 컴퓨팅 환경 외에도 환경 간에 데이터와 애플리케이션을 이동하는 복잡성을 처리하기 위한 전략이 필요합니다. 이를 효과적으로 수행하려면 조직은 원활한 연결과 일관된 관리를 보장하는 기능이 필요합니다.

GKE로 버스트 트리거 구성

클라우드 버스팅 트리거를 구현하는 가장 효과적인 방법 중 하나는 Google Kubernetes Engine(GKE)과 수평형 포드 자동 확장 처리(HPA)를 외부 측정항목과 함께 사용하는 것입니다. 이 시나리오에서는 온프레미스 애플리케이션이 Google Cloud Monitoring에 신호(측정항목)를 보냅니다. 이 신호가 임곗값을 넘으면 GKE가 자동으로 클라우드에서 새 포드를 가동하여 부하를 처리합니다.

Pub/Sub 큐 깊이(온프레미스 작업자가 과부하 상태임을 나타내는 일반적인 지표)를 기반으로 트리거를 설정하는 방법은 다음과 같습니다.

1. 커스텀 측정항목 API 사용 설정: 먼저 GKE 클러스터가 Cloud Monitoring에서 측정항목을 읽을 수 있도록 허용해야 합니다. 클러스터에 커스텀 측정항목 Stackdriver 어댑터를 배포하면 됩니다. 이 어댑터는 Google Cloud 측정항목을 Kubernetes가 이해할 수 있는 것으로 변환하는 브리지 역할을 합니다.

로드 중...

2. HPA 구성 정의: HorizontalPodAutoscaler YAML 파일을 만듭니다. CPU 사용량을 살펴보는 표준 자동 확장 처리와 달리 이 자동 확장 처리는 외부 측정항목, 구체적으로는 Pub/Sub 구독에서 전달되지 않은 메시지 수(num_undelivered_messages)를 살펴봅니다.

로드 중...

3. 적용 및 모니터링: kubectl apply -f hpa.yaml을 사용하여 이 구성을 적용합니다. 이제 GKE가 큐를 '감시'합니다. 온프레미스 시스템이 느려지고 큐가 목표(50개 메시지)를 초과하여 채워지면 HPA가 자동으로 클라우드에서 새 포드를 만들어 백로그를 처리합니다. 큐가 비면 GKE는 포드를 다시 0개로 축소합니다.

모니터링을 통한 미세 조정

보이지 않는 것은 관리할 수 없습니다. 클라우드 버스팅을 사용하려면 IT팀이 프라이빗 데이터 센터와 퍼블릭 클라우드 전반의 리소스를 명확하게 파악해야 합니다. Google Cloud는 애플리케이션이 CPU와 메모리를 사용하는 방식을 세부적으로 파악할 수 있는 도구를 제공합니다.

애플리케이션이 얼마나 많은 '연료'를 소모하는지 정확히 파악하면 팀은 버스트 시점을 위한 정확한 기준점을 설정할 수 있습니다. 기준점이 너무 낮으면 필요하지 않은데도 퍼블릭 클라우드에 비용을 지출할 수 있습니다. 값이 너무 높으면 새 리소스가 도착하기 전에 앱이 비정상 종료될 수 있습니다. 통합 모니터링은 조직이 이러한 설정을 세부 조정하여 성능과 비용의 균형을 맞추는 데 도움이 됩니다.

자동화의 역할

수동 부하 분산은 규모가 작고 빈도가 낮은 프로젝트에는 효과적이지만 엔터프라이즈 애플리케이션에는 잘 확장되지 않을 수 있습니다. 조직은 효율성을 높이기 위해 소프트웨어와 도구를 구현하여 클라우드 컴퓨팅 리소스를 자동으로 조정할 수 있습니다. Terraform 또는 Google Cloud의 Deployment Manager와 같은 자동화 도구를 사용하면 코드형 인프라(IaC)를 정의할 수 있습니다.

즉, 시스템이 실시간 수요에 따라 서버를 자동으로 프로비저닝, 구성, 관리할 수 있습니다. 트래픽 급증이 가라앉으면 자동화 도구는 이러한 리소스의 '프로비저닝 해제' 또는 종료도 처리합니다. 이를 통해 회사는 더 이상 필요하지 않은 순간부터 퍼플릭 클라우드에 대한 비용 지불을 중단할 수 있습니다.

제어(모니터링 및 보고)

버스트 중에 제어를 유지하는 것은 보안 및 예산 관리에 매우 중요합니다. 조직은 리소스를 추적하고 서비스 중단 없이 적절하게 프로비저닝되도록 보장하기 위해 강력한 모니터링 기능이 필요합니다.

보고서 도구는 시간 경과에 따른 버스팅 비용을 추적하는 데 도움이 됩니다. 이 데이터는 향후 예산을 예측하는 데 필수적입니다. 또한 버스팅 리소스에 일관된 보안 정책을 적용해야 합니다. 모니터링 및 보고서를 구현하는 도구는 사용량의 추세와 이상치를 파악하여 시간이 지남에 따라 비용을 절감하고 효율성을 높이는 데 도움이 될 수 있습니다.

클라우드 버스팅의 이점

클라우드 버스팅 전략을 도입하면 성능과 예산의 균형을 맞추려는 조직에 여러 가지 이점을 제공할 수 있습니다.

비용 절감

기업은 추가 퍼블릭 클라우드 리소스를 사용할 때만 비용을 지불하므로 대기 기간에 유휴 상태로 있는 하드웨어를 구매하는 자본 지출을 피할 수 있습니다.

유연성 및 확장성

팀은 자체 데이터 센터에서 사용할 수 있는 물리적 공간이나 전력에 제한받지 않고도 새로운 프로젝트를 자유롭게 테스트하거나 트래픽이 급증하는 상황을 처리할 수 있습니다.

비즈니스 연속성 및 복원력

프라이빗 데이터 센터에 문제가 발생하거나 과부하가 걸리는 경우 애플리케이션은 부하를 퍼블릭 클라우드로 전환하여 온라인 상태를 유지하므로 충돌과 다운타임을 방지하는 데 도움이 됩니다.

리소스 최적화

IT팀은 중요한 작업에 대해 프라이빗 클라우드를 안정적이고 효율적인 수준으로 유지하면서 변동성이 크고 예측할 수 없는 트래픽을 유연한 퍼블릭 클라우드로 오프로드할 수 있습니다.

Google Cloud로 비즈니스 문제 해결

신규 고객에게는 Google Cloud에서 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

버스팅 및 확장성을 위한 Google Cloud의 이점

클라우드 버스팅의 개념은 보편적이지만 이를 지원하는 인프라는 제공업체마다 크게 다릅니다. Google Cloud는 하이브리드 버스팅을 더 빠르고 안정적이며 쉽게 관리할 수 있도록 해주는 구체적인 이점을 제공합니다.

GKE Enterprise를 통한 일관된 플랫폼: 많은 하이브리드 솔루션에서는 팀이 온프레미스용 환경과 클라우드용 환경이라는 두 가지 서로 다른 환경을 관리해야 하므로 버스트 중에 호환성 문제가 발생할 수 있습니다. Google Cloud의 GKE Enterprise는 두 환경 모두에서 일관된 Kubernetes 런타임을 제공합니다. 즉, 프라이빗 데이터 센터용으로 빌드된 애플리케이션을 코드 변경이나 복잡한 리플랫폼 없이도 Google Cloud로 즉시 버스팅할 수 있습니다.
향상된 네트워크 성능: 애플리케이션이 버스트되면 데이터가 프라이빗 데이터 센터와 퍼블릭 클라우드 사이를 이동해야 합니다. Google은 세계 최대 규모의 사설 광섬유 네트워크 중 하나를 운영하고 있습니다. Google Cloud는 트래픽을 공개 인터넷이 아닌 이 비공개 백본에 유지함으로써 트래픽이 많은 중요한 이벤트 중에 지연 시간을 줄이고 보안을 개선할 수 있습니다.
고급 전역 부하 분산: Google Cloud Load Balancing은 트래픽을 라우팅할 뿐만 아니라 트래픽 급증에 몇 분이 아닌 몇 초 만에 대응하고 전역적으로 리전 간에 부하를 분산할 수 있습니다. 로컬 버스트로 충분하지 않은 경우 네트워크는 자동으로 사용 가능한 용량이 있는 다음으로 가장 가까운 리전으로 사용자를 라우팅하여 표준 네트워킹 도구로는 달성하기 어려운 수준의 복원력을 제공할 수 있습니다.
오픈소스 유연성: Google Cloud는 Kubernetes 및 TensorFlow와 같은 개방형 표준을 기반으로 빌드되므로 조직은 공급업체 종속을 피할 수 있습니다. 오늘날 효과가 있으며 향후 인프라를 조정할 수 있는 유연성을 유지하는 버스팅 전략을 빌드할 수 있습니다.