인터넷 애플리케이션은 사용량이 급격하게 변동될 수 있습니다. 대부분의 엔터프라이즈 애플리케이션은 이러한 문제를 겪지 않지만, 대부분의 기업에서는 다른 종류의 급격히 증가한 워크로드에 해당하는 일괄 또는 CI/CD 작업을 처리해야 합니다.
이 아키텍처 패턴은 여러 컴퓨팅 환경에 걸친 애플리케이션의 중복 배포에 의존합니다. 목표는 용량, 복원력 또는 둘 다 높이는 것입니다.
리소스 초과 프로비저닝을 통해 데이터 센터 기반 컴퓨팅 환경에서 급격히 증가하는 워크로드를 수용할 수 있지만 이 방식은 비용 면에서 효율적이지는 않습니다. 일괄 작업의 경우, 시간에 민감한 작업에서는 작업을 지연시키는 것이 쉽지는 않지만 장시간 동안 실행을 연장하여 사용을 최적화할 수 있습니다.
클라우드 버스트 패턴의 개념은 기준 부하에 비공개 컴퓨팅 환경을 사용하고 추가 용량이 필요할 때 일시적으로 클라우드로 전환하는 것입니다.
앞의 다이어그램에서 데이터 용량이 온프레미스 비공개 환경에서 한도에 도달한 경우 시스템은 필요시 Google Cloud 환경에서 추가 용량을 확보할 수 있습니다.
이 패턴의 주요 동인은 확장 요구사항 변경에 대응하는 데 필요한 비용을 절감하고 시간과 노력을 줄이는 것입니다. 이 방식을 사용하면 추가 부하를 처리할 때 사용하는 리소스에 대해서만 비용을 지불하면 됩니다. 즉, 인프라를 초과 프로비저닝할 필요가 없습니다. 대신 주문형 클라우드 리소스를 활용하고 수요와 사전 정의된 측정항목에 맞게 확장할 수 있습니다. 따라서 수요가 최대로 증가하는 기간에 서비스 중단을 방지할 수 있습니다.
클라우드 버스팅 시나리오의 잠재적인 요구사항은 워크로드 이동성입니다. 워크로드를 여러 환경에 배포하는 것을 허용할 때는 환경 간의 차이를 추상화해야 합니다. 예를 들어 Kubernetes는 서로 다른 인프라를 사용하는 다양한 환경에서 워크로드 수준의 일관성을 확보할 수 있는 기능을 제공합니다. 자세한 내용은 GKE Enterprise 하이브리드 환경 참조 아키텍처를 참조하세요.
설계 고려사항
클라우드 버스팅 패턴은 대화형 워크로드와 일괄 워크로드에 적용됩니다. 그러나 대화형 워크로드를 처리하는 경우에는 환경 간에 요청을 배포하는 방법을 결정해야 합니다.
유입되는 사용자 요청을 기존 데이터 센터에서 실행되는 부하 분산기로 라우팅한 후 부하 분산기가 요청을 로컬 및 클라우드 리소스에 배포하도록 할 수 있습니다.
이 방식을 사용하려면 기존 데이터 센터에서 실행 중인 부하 분산기 또는 다른 시스템이 클라우드에 할당된 리소스도 추적해야 합니다. 또한 부하 분산기 또는 다른 시스템이 리소스의 자동 확장 또는 축소 작업을 시작해야 합니다. 이 방식을 사용하면 활동이 적은 시간에 모든 클라우드 리소스를 사용 중단할 수 있습니다. 그러나 리소스를 추적하기 위한 메커니즘을 구현하는 것은 부하 분산기 솔루션의 기능을 초과할 수 있으므로 전반적인 복잡성이 증가할 수 있습니다.
리소스를 추적하기 위한 메커니즘을 구현하는 대신 하이브리드 연결 네트워크 엔드포인트 그룹(NEG) 백엔드와 함께 Cloud Load Balancing을 사용할 수 있습니다. 이 부하 분산기를 사용하여 내부 클라이언트 요청 또는 외부 클라이언트 요청을 온프레미스와 Google Cloud 모두에 있고 가중치 기반 트래픽 분할과 같은 다양한 측정항목을 기준으로 하는 백엔드로 라우팅합니다. 또한 Google Cloud의 워크로드에 대해 부하 분산 제공 용량을 기준으로 백엔드를 확장할 수 있습니다. 자세한 내용은 전역 외부 애플리케이션 부하 분산기의 트래픽 관리 개요를 참조하세요.
이 방식에는 Google Cloud Armor DDoS 보호 기능 및 WAF를 활용하거나 Cloud CDN을 사용하여 클라우드 에지에서 콘텐츠를 캐싱하는 등 몇 가지 추가적인 혜택이 있습니다. 하지만 추가 트래픽을 처리하려면 하이브리드 네트워크 연결의 크기를 조정해야 합니다.
워크로드 이동성에 강조 표시된 대로 워크로드 일관성을 달성하기 위해 변경을 최소한으로 수행하여 애플리케이션을 다른 환경으로 이동할 수 있지만 그렇다고 해서 애플리케이션이 두 환경 모두에서 동일하게 작동한다는 의미는 아닙니다. 일반적으로 종속 서비스에 대한 근접성과 함께 기본 컴퓨팅, 인프라 보안 기능 또는 네트워킹 인프라의 차이에 따라 성능이 결정됩니다. 테스트를 통해 보다 정확한 가시성을 확보하고 성능 예상치를 이해할 수 있습니다.
클라우드 인프라 서비스를 사용하여 이동성 없이 애플리케이션을 호스팅할 환경을 구축할 수 있습니다. 수요가 최대로 증가하는 기간에 트래픽이 리디렉션되는 경우 클라이언트 요청을 처리하려면 다음과 같은 방식을 사용하세요.
- 일관된 도구를 사용하여 이 두 환경을 모니터링하고 관리합니다.
- 워크로드 버전 관리의 일관성을 확보하고 데이터 소스가 최신 상태인지 확인합니다.
- 수요가 증가하고 클라우드 워크로드가 애플리케이션에 대한 클라이언트 요청을 수락할 것으로 예상될 때 클라우드 환경을 프로비저닝하고 트래픽을 다시 라우팅하기 위해 자동화 기능을 추가해야 할 수 있습니다.
수요가 낮은 기간에 모든 Google Cloud 리소스를 종료하려는 경우 트래픽 부하 분산에 주로 DNS 라우팅 정책을 사용하는 것이 항상 최적이 아닐 수 있습니다. 그 이유는 주로 다음과 같습니다.
- 사용자에게 서비스를 제공하기 전에 리소스를 초기화하는 데 다소 시간이 걸릴 수 있습니다.
- DNS 업데이트는 인터넷을 통해 느리게 전파되는 경향이 있습니다.
결과는 다음과 같습니다.
- 요청을 처리하는 데 사용할 수 있는 리소스가 없는 경우에도 사용자가 클라우드 환경으로 라우팅될 수 있습니다.
- DNS 업데이트가 인터넷을 통해 전파되는 동안 사용자가 온프레미스 환경으로 일시적으로 계속 라우팅될 수 있습니다.
Cloud DNS를 사용하면 위치정보 DNS 라우팅 정책과 같은 솔루션 아키텍처 및 동작에 맞는 DNS 정책 및 라우팅 정책을 선택할 수 있습니다. 또한 Cloud DNS는 내부 패스 스루 네트워크 부하 분산기 및 내부 애플리케이션 부하 분산기의 상태 점검을 지원합니다. 이 경우 이 패턴을 기반으로 하는 전체 하이브리드 DNS 설정에 이를 통합할 수 있습니다.
내부 애플리케이션 부하 분산기 또는 리전 간 내부 애플리케이션 부하 분산기를 사용할 때와 같이 일부 시나리오에서는 Cloud DNS를 사용하여 Google Cloud에서 상태 점검을 통해 클라이언트 요청을 분산시킬 수 있습니다. 이 시나리오에서 Cloud DNS는 자체적으로 백엔드 인스턴스의 상태를 점검하는 내부 애플리케이션 부하 분산기의 전반적인 상태를 점검합니다. 자세한 내용은 DNS 라우팅 정책 및 상태 점검 관리를 참조하세요.
Cloud DNS 분할 범위를 사용할 수도 있습니다. Cloud DNS 분할 범위는 동일한 도메인 이름에 대해 DNS 쿼리 시작자의 특정 위치 또는 네트워크에 DNS 응답 또는 레코드를 설정하는 방식입니다. 이 방식은 일반적으로 각각 고유한 기능이 포함된 비공개 환경과 공개 환경을 모두 제공하도록 애플리케이션을 설계하는 요구사항을 해결하는 데 사용됩니다. 이 방식은 환경 간에 트래픽 부하를 분산시키는 데도 도움이 됩니다.
이러한 사항을 고려할 때 클라우드 버스팅은 대개 대화형 워크로드보다 일괄 워크로드에 더 적합합니다.
장점
클라우드 버스팅 아키텍처 패턴의 주요 장점은 다음과 같습니다.
- 클라우드 버스팅을 통해 데이터 센터 및 비공개 컴퓨팅 환경에 대한 기존 투자를 재사용할 수 있습니다. 재사용은 영구적으로 가능하거나 기존 장비가 교체될 때까지 유효할 수 있으며, 장비 교체 시점이 되면 전체 이전을 고려할 수 있습니다.
- 최대 수요를 충족하기 위해 더 이상 초과 용량을 유지할 필요가 없으므로 비공개 컴퓨팅 환경의 사용과 비용 효율성을 높일 수 있습니다.
- 클라우드 버스팅을 통해 컴퓨팅 리소스를 초과 프로비저닝하지 않고도 일괄 작업을 적시에 실행할 수 있습니다.
권장사항
클라우드 버스팅 구현 시 다음 권장사항을 고려하세요.
- 클라우드에서 실행 중인 워크로드가 온프레미스 환경에서 실행 중인 워크로드와 동일한 방식으로 리소스에 액세스할 수 있도록 하려면 최소 권한의 보안 액세스 원칙이 적용된 meshed 패턴을 사용합니다. 워크로드 설계에서 허용하는 경우 클라우드에서 온프레미스 컴퓨팅 환경으로의 액세스만 허용하고 그 반대는 허용하지 않을 수 있습니다.
- 환경 간의 통신 지연 시간을 최소화하려면 비공개 컴퓨팅 환경과 지리적으로 가까운 Google Cloud 리전을 선택합니다. 자세한 내용은 Compute Engine 리전 선택 권장사항을 참조하세요.
- 일괄 워크로드에 대해서만 클라우드 버스팅을 사용하는 경우, 모든 Google Cloud 리소스를 비공개 상태로 유지하여 보안 공격 표면을 줄입니다. Google Cloud 외부 부하 분산을 사용하여 워크로드에 대한 진입점을 제공하는 경우에도 인터넷에서 이러한 리소스로의 직접 액세스를 허용하지 않습니다.
아키텍처 패턴 및 타겟팅된 솔루션 동작에 적합한 DNS 정책 및 라우팅 정책을 선택합니다.
- 이 패턴의 일부로 DNS 정책 설계를 영구적으로 적용하거나 수요가 최대로 증가하는 기간에 다른 환경을 사용하여 추가 용량이 필요할 때 적용할 수 있습니다.
- 위치정보 DNS 라우팅 정책을 사용하여 리전 부하 분산기의 전역 DNS 엔드포인트를 만들 수 있습니다. 이 전술에는 Google Cloud 리전이 있는 온프레미스 배포와 함께 Google Cloud를 사용하는 하이브리드 애플리케이션을 포함하여 위치정보 DNS 라우팅 정책의 다양한 사용 사례가 있습니다.
동일한 DNS 쿼리에 대해 서로 다른 레코드를 제공해야 하는 경우 내부 및 외부 클라이언트의 쿼리와 같이 분할된 범위의 DNS를 사용할 수 있습니다.
자세한 내용은 하이브리드 DNS용 참조 아키텍처를 참조하세요.
DNS 변경사항이 빠르게 전파되도록 하려면 클라우드 환경을 사용하여 추가 용량이 필요할 때 사용자를 대기 시스템으로 다시 라우팅할 수 있도록 비교적 짧은 TTL(수명) 값으로 DNS를 구성합니다.
시간이 크게 중요하지 않고 데이터를 로컬에 저장하지 않는 작업의 경우 일반 VM 인스턴스보다 훨씬 저렴한 스팟 VM 인스턴스 사용을 고려합니다. 그러나 VM 작업이 선점되는 경우 시스템이 자동으로 작업을 재시작할 수 있어야 합니다.
해당되는 경우 컨테이너를 사용하여 워크로드 이동성을 달성합니다. 또한 GKE Enterprise는 이 설계를 지원하는 핵심 기술이 될 수 있습니다. 자세한 내용은 GKE Enterprise 하이브리드 환경 참조 아키텍처를 참조하세요.
Google Cloud에서 다른 컴퓨팅 환경으로 전송되는 트래픽을 모니터링합니다. 이 트래픽에는 아웃바운드 데이터 전송 요금이 부과됩니다.
아웃바운드 데이터 전송 볼륨이 높은 이 아키텍처를 장기간 사용하려면 Cloud Interconnect 사용을 고려합니다. Cloud Interconnect는 연결 성능을 최적화하는 데 도움이 되며 특정 조건을 충족하는 트래픽에 대한 아웃바운드 데이터 전송 요금을 줄일 수 있습니다. 자세한 내용은 Cloud Interconnect 가격 책정을 참조하세요.
Cloud Load Balancing을 사용할 때 해당되는 경우 애플리케이션 용량 최적화 기능을 사용해야 합니다. 이렇게 하면 전역으로 분산된 애플리케이션에서 발생할 수 있는 용량 문제를 해결하는 데 도움이 됩니다.
환경 경계에서 시스템을 안전하게 인증할 수 있도록 환경 간에 일반 ID를 설정하여 시스템 사용자를 인증합니다.
민감한 정보를 보호하려면 전송 중인 모든 통신을 암호화하는 것이 좋습니다. 연결 레이어에서 암호화가 필요한 경우 선택한 하이브리드 연결 솔루션에 따라 다양한 옵션을 사용할 수 있습니다. 이러한 옵션에는 VPN 터널, Cloud Interconnect를 통한 HA VPN, Cloud Interconnect용 MACsec이 포함됩니다.