Google Cloud 배포 원형 가이드의 이 섹션에서는 가용성, 중단 복원력, 비용, 운영 복잡성 측면에서 각 배포 원형을 비교해서 보여줍니다.
다음 표에서는 기본 배포 원형인 영역, 리전, 멀티 리전, 전역에 대한 비교 분석을 요약해서 보여줍니다. 하이브리드 및 멀티 클라우드 토폴로지의 경우에는 토폴로지의 Google Cloud 부분에 사용되는 배포 원형이 가용성, 중단 복원력, 비용, 운영 복잡성에 영향을 줍니다.
| 설계 고려사항 | 영역 | 리전 | 멀티 리전 | 전역 |
|---|---|---|---|---|
| 인프라 가용성 | 99.9% | 99.99% | 99.999% | 99.999% |
| 영역 중단에 대한 강력한 인프라 | 시간 또는 일 단위의 RTO | 복제가 동기화된 경우 0에 가까운 RTO | 복제가 동기화된 경우 0에 가까운 RTO | 복제가 동기화된 경우 0에 가까운 RTO |
| 리전 중단에 대한 강력한 인프라 | 시간 또는 일 단위의 RTO | 시간 또는 일 단위의 RTO | 복제가 동기화된 경우 0에 가까운 RTO | 복제가 동기화된 경우 0에 가까운 RTO |
| Google Cloud 리소스 비용 | 낮음 | 중간 | 높음 | 중간 |
| 운영 복잡성 | 다른 배포 원형보다 간단함 | 영역보다 더 복잡함 | 리전보다 복잡함 | 멀티 리전보다 잠재적으로 더 간단함 |
다음 섹션에서는 앞의 표에 요약된 비교 분석에 대해 설명합니다.
인프라 가용성
다음 섹션에서는 배포 원형 간의 인프라 가용성 차이에 대해 설명합니다.
영역, 리전, 멀티 리전, 전역 배포 원형
Google Cloud 인프라는 영역 배포 원형을 사용할 때 워크로드에 대해 99.9%의 목표 가용성, 리전 배포의 경우 99.99%, 멀티 리전과 전역 배포의 경우 99.999%를 지원하도록 빌드되어 있습니다. 이러한 가용성 수치는 플랫폼 수준의 인프라에 대한 목표 값입니다.
Google Cloud에 배포되는 애플리케이션에서 기대할 수 있는 가용성은 배포 원형과 함께 다음과 같은 요소에 따라 달라집니다.
- 애플리케이션 설계
- 애플리케이션 스택의 독립적인 계층 수
- 사용된 Google Cloud 서비스의 업타임 서비스수준계약(SLA)
- 중복 리소스의 양
- 리소스의 위치 범위
자세한 내용은 Google Cloud의 신뢰성 구성요소를 참조하세요.
하이브리드 및 멀티 클라우드 배포 원형
하이브리드 또는 멀티 클라우드 토폴로지의 경우 전반적인 가용성은 각 환경의 인프라 및 환경 간 상호 종속성에 따라 달라집니다.
- Google Cloud의 구성요소와 Google Cloud 외부 구성요소 사이에 중요한 상호 종속성이 존재할 경우에는 모든 환경에서 최소 가용성을 제공하는 구성요소의 가용성보다 전반적인 가용성이 낮습니다.
- 애플리케이션의 모든 구성요소가 Google Cloud와 온프레미스에 또는 다른 클라우드 플랫폼에 중복해서 배포된 경우 이러한 중복성이 고가용성을 보장합니다.
영역 및 리전 중단에 대한 강력한 인프라
다음 섹션에서는 Google Cloud 영역 및 리전 중단 시 인프라가 워크로드를 계속 지원할 수 있는 기능 측면에서 배포 원형 간의 차이에 대해 설명합니다.
영역 배포 원형
기본 단일 영역 배포 원형을 사용하는 아키텍처는 영역 중단에 대한 복원력을 제공하지 않습니다. 복구 지점 목표(RPO) 및 복구 시간 목표(RTO)에 따라 영역 중단으로부터 복구를 계획해야 합니다. 예를 들어 다른(장애 조치) 영역에서 인프라에 대한 수동 또는 축소된 복제본을 유지보수해야 합니다. 기본 영역에서 중단이 발생할 경우 장애 조치 영역의 데이터베이스를 기본 데이터베이스로 승격하고 장애 조치 영역의 프런트엔드로 트래픽을 전송하도록 부하 분산기를 업데이트할 수 있습니다.
리전 배포 원형
리전 배포 원형을 사용하는 아키텍처는 영역 중단에 대한 복원력을 제공합니다. 한 영역에서 장애가 발생해도 다른 영역의 인프라에 영향을 미칠 가능성이 낮습니다. 데이터가 동기적으로 복제된 경우 RTO가 0에 가깝습니다. 하지만 중단이 전체 Google Cloud 리전에 영향을 미칠 경우에는 애플리케이션을 사용할 수 없게 됩니다. 애플리케이션의 RPO 및 RTO에 따라 중단 복구를 계획해야 합니다. 예를 들어 인프라의 수동 복제본을 다른 리전에 프로비저닝하고 리전 중단 시 복제본을 활성화할 수 있습니다.
멀티 리전 및 전역 배포 원형
멀티 리전 또는 전역 배포 원형을 사용하는 아키텍처는 영역 및 리전 중단에 대한 복원력을 제공합니다. 데이터가 동기적으로 복제된 경우 RTO가 0에 가깝습니다. 애플리케이션이 위치에 무관하고 전역적으로 분산된 스택으로 실행되는 아키텍처는 리전 중단에 대해 가장 높은 수준의 복원력을 제공합니다.
하이브리드 및 멀티 클라우드 배포 원형
하이브리드 및 멀티 클라우드 아키텍처의 복원력은 각 환경(Google Cloud, 온프레미스, 다른 클라우드 플랫폼)의 복원력과 환경 사이의 상호 종속성에 따라 달라집니다.
예를 들어 애플리케이션의 모든 구성요소가 Google Cloud와 다른 환경(온프레미스 또는 다른 클라우드 플랫폼)에 중복적으로 실행되는 경우 이 애플리케이션은 모든 Google Cloud 중단에 대해 복원력을 제공합니다. Google Cloud의 구성요소와 온프레미스 또는 다른 클라우드 플랫폼에 배포된 구성요소 사이에 중요한 상호 종속성이 존재할 경우에 Google Cloud 중단에 대한 복원력은 해당 아키텍처의 Google Cloud 부분에 사용하는 배포 원형의 복원력에 따라 달라집니다.
Google Cloud 리소스 비용
애플리케이션에 필요한 Google Cloud 리소스 비용은 사용하는 Google Cloud 서비스, 프로비저닝하는 리소스 수, 리소스를 보존 또는 사용하는 기간, 선택한 배포 원형에 따라 달라집니다. 배포 원형을 기준으로 아키텍처의 Google Cloud 리소스 비용을 예상하려면 Google Cloud 가격 계산기를 사용하면 됩니다.
다음 섹션에서는 여러 배포 원형 간의 Google Cloud 리소스 비용 차이에 대해 설명합니다.
영역 대 리전 및 멀티 리전 배포 원형 비교
영역 배포 원형을 사용하는 아키텍처와 비교할 때 멀티 리전 배포 원형을 사용하는 아키텍처는 중복 스토리지의 추가 비용이 발생할 수 있습니다. 또한 리전 경계를 벗어나는 네트워크 트래픽에 대해서는 리전 간 데이터 전송 비용을 고려해야 합니다.
전역 배포 원형
이 원형을 사용할 때는 전역 부하 분산기와 같은 고가용성 전역 리소스를 사용할 수 있습니다. 리전 리소스의 여러 인스턴스를 프로비저닝하고 구성하는 멀티 리전 배포보다 클라우드 리소스를 설정하고 운영하는 비용이 낮을 수 있습니다. 그러나 전역 리소스는 일부 경우에 더 높은 비용을 수반할 수 있습니다. 예를 들어 전역 부하 분산기에 프리미엄 등급 네트워킹이 필요하지만 리전 부하 분산기에는 표준 등급을 선택할 수 있습니다.
하이브리드 및 멀티 클라우드 배포 원형
하이브리드 또는 멀티 클라우드 배포 원형에서는 프로비저닝하는 리소스 비용과 함께 추가 비용을 고려해야 합니다. 예를 들어 하이브리드 또는 클라우드 간 네트워킹과 같은 비용과 여러 환경에 걸친 리소스 모니터링 및 관리 비용을 고려해야 합니다.
모든 배포 원형의 고려사항
클라우드 워크로드 실행 비용을 평가할 때는 프로비저닝하는 Google Cloud 리소스 비용과 함께 추가 비용을 고려해야 합니다. 예를 들어 인력 비용과 클라우드 배포를 설계, 빌드, 유지보수하기 위한 오버헤드 비용을 고려해야 합니다.
배포 원형 전반의 Google Cloud 리소스 비용을 비교하려면 또한 애플리케이션이 수행하는 작업 단위당 비용을 고려해야 합니다. 애플리케이션이 지원하는 사용자 수 또는 처리되는 요청 수와 같이 애플리케이션이 수행하는 작업을 반영하는 작업 단위를 파악합니다.
Google Cloud 리소스를 신중하게 활용하고 Google 권장사항을 따름으로써 클라우드 배포 비용을 최적화할 수 있습니다. 자세한 내용은 Google Cloud 아키텍처 프레임워크: 비용 최적화를 참조하세요.
운영 복잡성
다음 섹션에서는 인프라 리소스 수, 기능, 운영이 필요한 애플리케이션 스택에 따라 달라지는 배포 원형 간의 운영 복잡성 차이에 대해 설명합니다.
영역 대 리전 및 멀티 리전 배포 원형 비교
영역 배포 원형을 기반으로 하는 아키텍처는 다른 배포 아키텍처와 비교할 때 설정 및 운영이 더 쉽습니다. 여러 영역 또는 리전에서 중복적으로 실행되는 애플리케이션은 다음과 같은 이유로 인해 더 높은 운영 노력이 요구됩니다.
- 모든 스택 레벨에서 그리고 애플리케이션의 각 구성요소에 대해 여러 위치에서 애플리케이션 스택 상태를 모니터링해야 합니다.
- 어떤 위치에서든 구성요소가 사용할 수 없게 되면 진행 중인 요청을 원활하게 처리해야 합니다.
- 애플리케이션 변경사항을 신중하게 출시해야 합니다.
- 데이터베이스를 모든 위치에서 동기화해야 합니다.
전역 배포 원형
전역 배포 원형을 사용하면 전역 부하 분산기 및 전역 데이터베이스와 같은 가용성이 높은 전역 리소스를 사용할 수 있습니다. 클라우드 리소스를 설정하고 운영하는 데 필요한 노력은 리전 리소스의 여러 인스턴스를 관리해야 하는 멀티 리전 배포보다 낮을 수 있습니다. 하지만 전역 리소스에 대한 변경사항을 신중하게 관리해야 합니다.
전역 배포 원형을 사용하는 아키텍처를 운영하는 데 필요한 노력은 위치에 무관하고 분산된 스택 또는 리전별로 격리된 여러 스택을 배포하는지 여부에 따라 달라집니다.
- 위치에 무관하고 분산된 애플리케이션은 보다 유연하게 확장될 수 있습니다. 예를 들어 특정 구성요소가 특정 위치에서만 최종 사용자에 대해 중요한 지연 시간 요구사항이 있는 경우 필요한 위치에서 이러한 구성요소를 배포하고 스택의 나머지는 다른 위치에서 운영할 수 있습니다.
- 리전별로 격리된 여러 스택으로 배포되는 애플리케이션은 다음과 같은 요소로 인해 운영 및 유지보수에 더 많은 노력이 요구됩니다.
- 모든 스택 레벨에서 그리고 각 구성요소에 대해 여러 위치에서 애플리케이션 스택 상태를 모니터링해야 합니다.
- 어떤 위치에서든 구성요소가 사용할 수 없게 되면 진행 중인 요청을 원활하게 처리해야 합니다.
- 애플리케이션 변경사항을 신중하게 출시해야 합니다.
- 데이터베이스를 모든 위치에서 동기화해야 합니다.
하이브리드 및 멀티 클라우드 배포 원형
하이브리드 또는 멀티 클라우드 토폴로지는 Google Cloud만 사용하는 아키텍처에 비해 설정 및 운영에 더 많은 노력이 요구됩니다.
- 온프레미스와 Google Cloud 토폴로지 전체에 걸쳐서 리소스를 일관적으로 관리해야 합니다. 컨테이너화된 하이브리드 애플리케이션을 관리하려면 여러 위치에서 Kubernetes 클러스터를 프로비저닝, 업데이트, 최적화하는 통합 클라우드 운영 모델인 GKE Enterprise와 같은 솔루션을 사용하면 됩니다.
- 여러 플랫폼에서 리소스를 효율적으로 프로비저닝하고 관리할 수 있는 방법이 필요합니다. Terraform과 같은 도구를 사용하면 프로비저닝 노력을 줄이는 데 도움이 될 수 있습니다.
- 보안 기능과 도구가 클라우드 플랫폼 간에 표준화되어 있지 않습니다. 보안 관리자가 사용되는 모든 클라우드 플랫폼 전반에 분산된 리소스의 보안 관리를 위한 기술과 전문성을 확보해야 합니다.