Compute Engine에서 리전 배포

Last reviewed 2024-01-31 UTC

이 문서에서는 Google Cloud 리전 내 여러 영역의 Compute Engine VM에서 실행되는 다중 계층 애플리케이션의 참조 아키텍처를 제공합니다. 이 참조 아키텍처를 사용하면 애플리케이션을 최소한으로 변경하면서 온프레미스 애플리케이션을 클라우드로 효율적으로 다시 호스팅(리프트 앤 시프트)할 수 있습니다. 또한 이 문서에서는 클라우드 애플리케이션의 리전 아키텍처를 빌드할 때 고려해야 하는 설계 요소에 대해서도 설명합니다. 이 문서는 Cloud 설계자를 대상으로 합니다.

아키텍처

다음 다이어그램에서는 리전 내 세 Google Cloud 영역에 배포된 격리된 스택에서 활성-활성 모드로 실행되는 애플리케이션의 아키텍처를 보여줍니다. 이 아키텍처는 리전 배포 원형에 따라 정렬되므로 Google Cloud 토폴로지가 영역 및 리전 서비스 중단 시에도 대응할 수 있습니다.

애플리케이션은 한 리전 내의 3개 Google Cloud 영역에 걸쳐 배포되는 격리된 스택에서 활성-활성 모드로 실행됩니다.

이 아키텍처는 Infrastructure as a Service(IaaS) 클라우드 모델을 기반으로 합니다. Google Cloud에 필요한 인프라 리소스(컴퓨팅, 네트워킹, 스토리지)를 프로비저닝합니다. 운영체제, 미들웨어, 애플리케이션 스택 상위 레이어에 대한 인프라와 책임을 완전히 제어할 수 있습니다. IaaS 및 기타 클라우드 모델에 대한 자세한 내용은 PaaS, IaaS, SaaS, CaaS 비교: 차이점은 무엇인가요?를 참조하세요.

앞선 다이어그램에서는 다음 구성요소가 포함됩니다.

구성요소 목적
리전 외부 부하 분산기

리전 외부 부하 분산기가 사용자 요청을 수신하여 웹 계층 VM에 배포합니다.

트래픽 유형 및 기타 요구사항에 따라 적절한 부하 분산기 유형을 사용합니다. 예를 들어 앞의 아키텍처에 표시된 것처럼 백엔드가 웹 서버로 구성된 경우에는 애플리케이션 부하 분산기를 사용하여 HTTP(S) 트래픽을 전달합니다. TCP 트래픽의 부하를 분산하려면 네트워크 부하 분산기를 사용합니다. 자세한 내용은 부하 분산기 선택을 참조하세요.

웹 계층의 리전 관리형 인스턴스 그룹(MIG)

애플리케이션의 웹 계층은 리전 MIG의 일부인 Compute Engine VM에 배포됩니다. MIG는 리전 외부 부하 분산기의 백엔드입니다.

MIG에는 서로 다른 영역 3개에 있는 Compute Engine VM이 포함됩니다. 이러한 각 VM은 애플리케이션 웹 계층의 독립 인스턴스를 호스팅합니다.

리전 내부 부하 분산기

리전 내부 부하 분산기는 웹 계층 VM의 트래픽을 애플리케이션 계층 VM으로 분산합니다.

요구사항에 따라 리전 내부 애플리케이션 부하 분산기나 네트워크 부하 분산기를 사용할 수 있습니다. 자세한 내용은 부하 분산기 선택을 참조하세요.

애플리케이션 계층 리전 MIG

애플리케이션 계층은 내부 부하 분산기의 백엔드인 리전 MIG에 속하는 Compute Engine VM에 배포됩니다.

MIG에는 서로 다른 영역 3개에 있는 Compute Engine VM이 포함됩니다. 각 VM은 애플리케이션 계층의 독립적인 인스턴스를 호스팅합니다.

Compute Engine VM에 배포된 서드 파티 데이터베이스

이 문서의 아키텍처는 Compute Engine VM에 배포된 서드 파티 데이터베이스(예: PostgreSQL)를 보여줍니다. 다른 영역에 대기 데이터베이스를 배포할 수 있습니다. 데이터베이스 복제 및 장애 조치 기능은 사용하는 데이터베이스에 따라 달라집니다.

서드 파티 데이터베이스를 설치 및 관리하려면 업데이트 적용, 모니터링, 가용성 보장을 위한 추가 노력과 운영 비용이 필요합니다. Cloud SQL 또는 PostgreSQL용 AlloyDB와 같은 완전 관리형 데이터베이스 서비스를 사용하여 서드 파티 데이터베이스 설치 및 관리 오버헤드를 방지하고 기본 제공되는 고가용성(HA) 기능을 활용할 수 있습니다. 관리형 데이터베이스 옵션에 대한 자세한 내용은 이 가이드의 뒷부분에 있는 데이터베이스 서비스를 참조하세요.

가상 프라이빗 클라우드 네트워크 및 서브넷

아키텍처의 모든 Google Cloud 리소스는 단일 VPC 네트워크 및 서브넷을 사용합니다.

요구사항에 따라 여러 VPC 네트워크 또는 여러 서브넷을 사용하는 아키텍처를 빌드할 수 있습니다. 자세한 내용은 'VPC 설계에 관한 권장사항 및 참조 아키텍처'에서 여러 VPC 네트워크 생성 여부 결정을 참조하세요.

Cloud Storage 이중 리전 버킷

애플리케이션 및 데이터베이스 백업은 이중 리전 Cloud Storage 버킷에 저장됩니다. 영역 또는 리전 중단이 발생해도 애플리케이션과 데이터가 손실되지 않습니다.

또는 백업 및 DR 서비스를 사용하여 데이터베이스 백업을 생성, 저장, 관리할 수 있습니다.

사용 제품

이 참조 아키텍처에는 다음과 같은 Google Cloud 제품이 사용됩니다.

  • Compute Engine: Google 인프라에서 가상 머신을 만들고 실행할 수 있는 안전하고 맞춤설정 가능한 컴퓨팅 서비스입니다.
  • Cloud Load Balancing: 확장 가능한 고성능 전역 및 리전 부하 분산기 포트폴리오입니다.
  • Cloud Storage: 다양한 데이터 유형에 적합한 저비용, 무제한 객체 저장소입니다. Google Cloud 내부 및 외부에서 데이터에 액세스할 수 있고 중복성을 위해 여러 위치에 복제됩니다.
  • 가상 프라이빗 클라우드: Google Cloud 워크로드에 확장 가능한 전역 네트워킹 기능을 제공하는 가상 시스템입니다.

사용 사례

이 섹션에서는 Compute Engine의 리전 배포가 적합한 사용 사례를 설명합니다.

온프레미스 애플리케이션의 효율적인 마이그레이션

이 참조 아키텍처를 사용하면 애플리케이션을 최소한으로 변경하면서 온프레미스 애플리케이션을 클라우드로 다시 호스팅(리프트 앤 시프트)하도록 Google Cloud 토폴로지를 빌드할 수 있습니다. 이 참조 아키텍처의 모든 애플리케이션 계층은 Compute Engine VM에서 호스팅됩니다. 이 방식을 사용하면 온프레미스 애플리케이션을 클라우드로 효율적으로 마이그레이션하고 Google Cloud에서 제공하는 비용 이점, 신뢰성, 성능, 운영 간소함을 활용할 수 있습니다.

지리적 영역 내 사용자를 지원하는 고가용성 애플리케이션

영역 중단에 대한 견고성이 필요하지만 리전 중단으로 인한 다운타임을 일부 허용할 수 있는 애플리케이션에는 리전 배포 아키텍처를 사용하는 것이 좋습니다. 애플리케이션 스택 중 일부가 실패하면 적절한 용량으로 작동 중인 구성요소가 모든 계층에 하나 이상 존재할 경우 애플리케이션이 계속 실행됩니다. 영역 중단이 발생하면 애플리케이션이 다른 영역에서 계속 실행됩니다.

애플리케이션 사용자를 위한 지연 시간 감소

모든 애플리케이션 사용자가 단일 국가와 같은 단일 지리적 구역 내에 있을 때는 리전 배포 아키텍처를 통해 애플리케이션에 대한 사용자 인식 성능을 향상시킬 수 있습니다. 사용자에게 가장 가까운 Google Cloud 리전에 애플리케이션을 배포하여 사용자 요청에 대한 네트워크 지연 시간을 최적화할 수 있습니다.

애플리케이션 구성요소 간에 지연 시간이 짧은 네트워킹

컴퓨팅 노드 간에 지연 시간이 짧고 대역폭이 높은 네트워크 연결이 필요한 일괄 컴퓨팅과 같은 애플리케이션에는 단일 리전 아키텍처가 적합할 수 있습니다. 모든 리소스가 단일 Google Cloud 리전에 있으므로, 리소스 간 네트워크 트래픽이 리전 내에 유지됩니다. 리소스 간 네트워크 지연 시간이 낮고 리전 간 데이터 전송 비용이 발생하지 않습니다. 리전 내부의 네트워크 비용은 계속 적용됩니다.

데이터 상주 요구사항 준수

단일 리전 아키텍처를 사용하여 데이터 상주 요구사항을 충족하는 데 도움이 되는 토폴로지를 빌드할 수 있습니다. 예를 들어 유럽의 한 국가에서 모든 사용자 데이터를 물리적으로 유럽 내에 있는 데이터 센터에 저장하고 액세스하도록 요구할 수 있습니다. 이 요구사항을 충족하려면 애플리케이션을 유럽에 있는 Google Cloud 리전에서 실행하면 됩니다.

설계 고려사항

이 섹션에서는 이 참조 아키텍처를 사용하여 시스템 설계, 보안 및 규정 준수, 신뢰성, 운영 효율성, 비용, 성능에 대한 특정 요구사항을 충족하는 아키텍처를 개발하는 데 도움이 되는 안내를 제공합니다.

시스템 설계

이 섹션에서는 리전 배포에 사용할 Google Cloud 리전을 선택하고 적절한 Google Cloud 서비스를 선택하는 데 도움이 되는 안내를 제공합니다.

리전 선택

애플리케이션의 Google Cloud 리전을 선택할 때 다음 요소와 요구사항을 고려하세요.

  • Google Cloud 서비스 가용성. 자세한 내용은 위치별 제공 제품을 참조하세요.
  • Compute Engine 머신 유형의 가용성. 자세한 내용은 리전 및 영역을 참조하세요.
  • 최종 사용자 지연 시간 요구사항
  • Google Cloud 리소스 비용
  • 규제 기관 요구사항

이러한 요소와 요구사항 중 일부는 장단점과 관련될 수 있습니다. 예를 들어 가장 경제적인 리전에는 탄소 발자국이 가장 적을 수 있습니다. 자세한 내용은 Google Cloud 아키텍처 프레임워크의 지리적 영역 및 리전 선택을 참조하세요.

컴퓨팅 서비스

이 문서의 참조 아키텍처는 애플리케이션의 모든 계층에 Compute Engine VM을 사용합니다. 이 문서의 설계 안내는 별도로 언급되지 않는 한 Compute Engine에만 적용됩니다.

애플리케이션의 요구사항에 따라 다음과 같은 다른 Google Cloud 컴퓨팅 서비스 중에서 선택할 수 있습니다. 이 문서에서는 이러한 서비스에 대한 설계 안내를 다루지 않습니다.

  • Google Kubernetes Engine(GKE) 클러스터에서 컨테이너화된 애플리케이션을 실행할 수 있습니다. GKE는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 컨테이너 조정 엔진입니다.
  • 인프라 리소스 설정 및 운영 대신 데이터와 애플리케이션에 대한 IT 노력에 집중하려는 경우 Cloud Run 및 Cloud Functions와 같은 서버리스 서비스를 사용할 수 있습니다.

VM, 컨테이너 또는 서버리스 서비스 사용 여부 결정에는 구성 유연성과 관리 노력 간의 균형이 맞아야 합니다. VM 및 컨테이너는 더 많은 구성 유연성을 제공하지만 개발자가 리소스를 관리해야 합니다. 서버리스 아키텍처에서는 최소한의 관리 노력이 필요한 사전 구성된 플랫폼에 워크로드를 배포합니다. Google Cloud의 워크로드에 적합한 컴퓨팅 서비스를 선택하는 방법에 대한 자세한 내용은 Google Cloud 아키텍처 프레임워크의 컴퓨팅 선택 및 관리를 참조하세요.

스토리지 서비스

이 문서에 표시된 아키텍처는 모든 계층에 대해 리전 Persistent Disk 볼륨을 사용합니다. 영구 디스크는 한 리전 내 두 영역 간에 데이터를 동기식으로 복제합니다.

리전 내 영역 간에 중복된 저비용 스토리지에는 Cloud Storage 리전 버킷을 사용할 수 있습니다.

웹 계층 또는 애플리케이션 계층의 모든 VM과 같이 한 리전의 여러 VM 간에 공유되는 데이터를 저장하려면 Filestore Enterprise 인스턴스를 사용하면 됩니다. Filestore Enterprise 인스턴스에 저장하는 데이터는 리전 내 영역 3개에 동기식으로 복제됩니다. 이 복제를 통해 HA 및 영역 중단에 대한 견고성을 보장할 수 있습니다. 공유 구성 파일, 일반적인 도구 및 유틸리티, 중앙 집중식 로그를 Filestore 인스턴스에 저장하고 인스턴스를 여러 VM에 마운트할 수 있습니다.

데이터베이스가 Microsoft SQL Server인 경우 SQL Server용 Cloud SQL을 사용하는 것이 좋습니다. Cloud SQL이 구성 요구사항을 지원하지 않거나 운영체제에 액세스해야 하는 경우 장애 조치 클러스터 인스턴스(FCI)를 배포할 수 있습니다. 이 시나리오에서는 완전 관리형 Google Cloud NetApp Volumes를 사용하여 데이터베이스에 지속적인 가용성(CA) SMB 스토리지를 제공할 수 있습니다.

리전 워크로드용 스토리지를 설계할 때는 워크로드의 기능적 특성, 복원력 요구사항, 성능 기대치, 비용 목표를 고려합니다. 자세한 내용은 클라우드 워크로드에 최적화된 스토리지 전략 설계를 참조하세요.

데이터베이스 서비스

이 문서의 참조 아키텍처에서는 PostgreSQL과 같이 Compute Engine VM에 배포된 서드 파티 데이터베이스를 사용합니다. 서드 파티 데이터베이스를 설치 및 관리하려면 업데이트 적용, 가용성 모니터링 및 보장, 백업 수행, 장애 복구와 같은 노력과 비용이 필요합니다.

Cloud SQL, PostgreSQL용 AlloyDB, Bigtable, Spanner 또는Firestore와 같은 완전 관리형 데이터베이스 서비스를 사용하면 서드 파티 데이터베이스를 설치하고 관리하는 데 드는 수고와 비용을 줄일 수 있습니다. Google Cloud 데이터베이스 서비스는 업타임 서비스수준계약(SLA)을 제공하며 확장성과 관측 가능성을 위한 기본 기능을 포함합니다. 워크로드에 Oracle 데이터베이스가 필요한 경우 Google Cloud에서 제공하는 베어메탈 솔루션을 사용하면 됩니다. 각 Google Cloud 데이터베이스 서비스가 적합한 사용 사례에 대한 개요는 Google Cloud 데이터베이스를 참조하세요.

보안 및 규정 준수

이 섹션에서는 이 참조 아키텍처를 사용하여 Google Cloud에 워크로드의 보안 및 규정 준수 요구사항을 충족하는 리전 토폴로지를 설계하고 빌드할 때 고려해야 하는 요소를 설명합니다.

외부 위협으로부터 보호

DDoS 공격 및 교차 사이트 스크립팅(XSS)과 같은 외부 위협으로부터 애플리케이션을 보호하려면 Google Cloud Armor 보안 정책을 사용하면 됩니다. 보안 정책은 경계, 즉 트래픽이 웹 계층에 도달하기 전에 시행됩니다. 각 정책은 평가해야 하는 특정 조건과 조건이 충족될 때 수행할 작업을 지정하는 일련의 규칙입니다. 예를 들어 규칙에서 들어오는 트래픽의 소스 IP 주소가 특정 IP 주소나 CIDR 범위와 일치하는 경우 트래픽이 거부되도록 지정할 수 있습니다. 또한 사전 구성된 웹 애플리케이션 방화벽(WAF) 규칙을 적용할 수 있습니다. 자세한 내용은 보안 정책 개요를 참조하세요.

VM의 외부 액세스

이 문서에서 설명하는 참조 아키텍처에서 애플리케이션 계층, 웹 계층, 데이터베이스를 호스팅하는 VM은 인터넷의 인바운드 액세스가 필요하지 않습니다. 이러한 VM에 외부 IP 주소를 할당하지 마세요. 비공개 내부 IP 주소만 있는 Google Cloud 리소스는 Private Service Connect 또는 비공개 Google 액세스를 사용하여 특정 Google API 및 서비스에 계속 액세스할 수 있습니다. 자세한 내용은 서비스 비공개 액세스 옵션을 참조하세요.

이 참조 아키텍처의 Compute Engine VM과 같이 내부 IP 주소만 있는 Google Cloud 리소스에서 보안 아웃바운드 연결을 사용 설정하려면 Cloud NAT를 사용하면 됩니다.

VM 이미지 보안

VM에서 승인된 이미지(즉, 정책 또는 보안 요구사항을 충족하는 소프트웨어가 있는 이미지)만 사용하도록 하려면 특정 공개 이미지 프로젝트에서 이미지 사용을 제한하는 조직 정책을 정의하면 됩니다. 자세한 내용은 신뢰할 수 있는 이미지 정책 설정을 참조하세요.

서비스 계정 권한

Compute Engine API가 사용 설정된 Google Cloud 프로젝트에서는 기본 서비스 계정이 자동으로 생성됩니다. 이 동작이 중지되지 않는 한 기본 서비스 계정에는 편집자 IAM 역할(roles/editor)이 부여됩니다. 기본적으로 기본 서비스 계정은 Google Cloud CLI 또는 Google Cloud 콘솔을 사용하여 만드는 모든 VM에 연결됩니다. 편집자 역할에는 다양한 권한이 포함되므로 기본 서비스 계정을 VM에 연결하면 보안 위험이 발생합니다. 이 위험을 방지하려면 애플리케이션마다 전용 서비스 계정을 만들고 사용하면 됩니다. 서비스 계정에서 액세스할 수 있는 리소스를 지정하려면 세분화된 정책을 사용합니다. 자세한 내용은 '서비스 계정 사용 권장사항'의 서비스 계정 권한 제한을 참조하세요.

네트워크 보안

아키텍처에서 리소스 간 네트워크 트래픽을 제어하려면 적절한 Cloud 차세대 방화벽 규칙을 설정해야 합니다. 각 방화벽 규칙을 사용하면 프로토콜, IP 주소, 포트와 같은 매개변수를 기반으로 트래픽을 제어할 수 있습니다. 예를 들어 웹 서버 VM에서 데이터베이스 VM의 특정 포트로 TCP 트래픽을 허용하고 다른 모든 트래픽을 차단하도록 방화벽 규칙을 구성할 수 있습니다.

추가 보안 고려사항

워크로드의 아키텍처를 빌드할 때는 보안 기반 청사진에서 제공하는 플랫폼 수준 보안 권장사항과 추천을 고려하세요.

신뢰성

이 섹션에서는 이 참조 아키텍처를 사용하여 Google Cloud에서 리전 배포를 위한 안정적인 인프라를 빌드하고 운영할 때 고려해야 하는 설계 요소를 설명합니다.

인프라 중단

리전 아키텍처에서는 인프라 스택의 개별 구성요소가 실패하면 작동 중인 적절한 용량의 구성요소가 각 계층에 하나 이상 존재할 경우 애플리케이션이 요청을 처리할 수 있습니다. 예를 들어 웹 서버 인스턴스가 실패하면 부하 분산기가 사용자 요청을 다른 사용할 수 있는 웹 서버 인스턴스로 전달합니다. 웹 서버 또는 앱 서버 인스턴스를 호스팅하는 VM이 충돌하면 MIG가 VM을 자동으로 다시 만듭니다.

리전별 리소스이기 때문에 영역 서비스 중단이 발생해도 부하 분산기는 영향을 받지 않습니다. 영역 서비스 중단은 개별 Compute Engine VM에 영향을 줄 수 있습니다. 그러나 VM이 리전 MIG에 있으므로 애플리케이션의 가용성 및 응답성이 유지됩니다. 리전 MIG는 새 VM을 자동으로 생성하여 구성된 VM 수를 최소한으로 유지합니다. Google에서 영역 서비스 중단이 해결된 후에는 배포된 모든 영역에서 애플리케이션이 예상한 대로 작동하는지 확인해야 합니다.

이 아키텍처의 모든 영역에 중단이 발생하거나 리전 중단이 발생하면 애플리케이션을 사용할 수 없습니다. Google에서 중단이 해결될 때까지 기다린 후 애플리케이션이 예상한 대로 작동하는지 확인해야 합니다.

인프라 스택의 수동(장애 조치) 복제본을 다른 Google Cloud 리전에서 유지보수하여 리전 중단으로 인한 다운타임을 줄일 수 있습니다. 기본 리전에서 중단이 발생하면 장애 조치 리전의 스택을 활성화하고 DNS 라우팅 정책을 이용해서 장애 조치 리전의 부하 분산기로 트래픽을 라우팅할 수 있습니다.

리전 중단에 대한 견고성이 필요한 애플리케이션에는 멀티 리전 아키텍처를 사용하는 것이 좋습니다. 자세한 내용은 Compute Engine의 멀티 리전 배포를 참조하세요.

MIG 자동 확장

리전 MIG의 VM에서 애플리케이션을 실행할 때는 격리된 영역 서비스 중단 중에도 애플리케이션을 계속 사용할 수 있습니다. 스테이트리스(Stateless) MIG의 자동 확장 기능을 사용하면 예측 가능한 수준에서 애플리케이션 가용성과 성능을 유지할 수 있습니다. 스테이트풀(Stateful) MIG를 자동 확장할 수 없습니다.

MIG의 자동 확장 동작을 제어하려면 평균 CPU 사용률과 같은 대상 사용률 측정항목을 지정하면 됩니다. 일정 기반 자동 확장을 구성할 수도 있습니다. 자세한 내용은 인스턴스 그룹 자동 확장을 참조하세요.

VM 자동 복구

간혹 애플리케이션을 호스팅하는 VM이 실행 중이고 사용 가능할 수 있지만 애플리케이션 자체에 문제가 있을 수 있습니다. 중단, 비정상 종료가 발생하거나 메모리가 부족할 수 있습니다. 애플리케이션이 예상대로 응답하는지 확인하려면 MIG의 자동 복구 정책의 일부로 애플리케이션 기반 상태 점검을 구성하면 됩니다. 특정 VM의 애플리케이션이 응답하지 않으면 MIG에서 VM을 자동 복구(복구)합니다. 자동 복구 구성에 대한 자세한 내용은 애플리케이션 상태 점검 및 자동 복구 설정을 참조하세요.

VM 배치

이 문서에서 설명하는 아키텍처에서 애플리케이션 계층과 웹 계층은 여러 영역에 분산된 Compute Engine VM에서 실행됩니다. 이러한 분산은 영역의 서비스 중단에 대한 애플리케이션의 견고성을 보장합니다. 이러한 견고성을 더욱 향상시키려면 분산 배치 정책을 만들고 MIG 템플릿에 적용하면 됩니다. MIG에서 VM을 만들 때 각 영역 내의 VM을 여러 물리적 서버(호스트라고 함)에 배치하므로 VM이 개별 호스트 오류에 대해 견고합니다. 자세한 내용은 VM에 분산 배치 정책 적용을 참조하세요.

VM 용량 계획

MIG 자동 확장에 필요한 경우 Compute Engine VM의 용량을 사용할 수 있도록 보장하기 위해서는 예약을 만들 수 있습니다. 예약을 사용하면 특정 영역에서 선택한 머신 유형에 지정된 VM 수에 따라 일정 용량을 보장할 수 있습니다. 예약은 프로젝트에 따라 다르게 지정할 수 있고 여러 프로젝트 간에 공유할 수 있습니다. 리소스가 프로비저닝되거나 사용되지 않더라도 예약된 리소스에 대한 요금이 발생합니다. 결제 고려사항을 포함하여 예약에 대한 자세한 내용은 Compute Engine 영역별 리소스 예약을 참조하세요.

영구 디스크 상태

애플리케이션 설계에서 권장사항은 스테이트풀(Stateful) 로컬 디스크가 필요하지 않도록 하는 것입니다. 하지만 요구사항이 있는 경우 VM을 복구하거나 다시 만들 때 데이터가 보존되도록 영구 디스크를 스테이트풀(Stateful)로 구성할 수 있습니다. 하지만 새 버전이고 보안 패치가 적용된 최신 이미지로 영구 디스크를 간편하게 업데이트할 수 있도록 부팅 디스크를 스테이트리스(Stateless)로 유지하는 것이 좋습니다. 자세한 내용은 MIG에서 스테이트풀(Stateful) 영구 디스크 구성을 참조하세요.

데이터 내구성

백업 및 DR을 사용하여 Compute Engine VM의 백업을 생성, 저장, 관리할 수 있습니다. 백업 및 DR은 백업 데이터를 애플리케이션에서 읽을 수 있는 원본 형식으로 저장합니다. 필요한 경우 시간이 많이 소요되는 데이터 이동이나 준비 활동 없이 장기 백업 스토리지에서 데이터를 직접 사용하여 워크로드를 프로덕션으로 복원할 수 있습니다.

Cloud SQL과 같은 관리형 데이터베이스 서비스를 사용하는 경우 정의한 보관 정책에 따라 자동으로 백업됩니다. 규제, 워크플로, 비즈니스 요구사항을 충족하기 위해 추가 논리적 백업으로 백업 전략을 보완할 수 있습니다. 서드 파티 데이터베이스를 사용하고 데이터베이스 백업 및 트랜잭션 로그를 저장해야 하는 경우에는 리전 Cloud Storage 버킷을 사용할 수 있습니다. 리전 Cloud Storage 버킷은 영역 간에 중복되는 저비용 백업 스토리지를 제공합니다.

Compute Engine은 다음과 같이 Persistent Disk 볼륨에 저장된 데이터의 내구성을 보장하는 데 도움이 되는 옵션을 제공합니다.

  • 스냅샷을 사용하여 Persistent Disk 볼륨의 특정 시점 상태를 캡처할 수 있습니다. 표준 스냅샷은 데이터 무결성을 보장하는 자동 체크섬을 통해 여러 리전에 중복 저장됩니다. 스냅샷은 기본적으로 증분적으로 사용되므로 저장공간이 적게 사용되고 비용이 절약됩니다. 스냅샷은 구성 가능한 Cloud Storage 위치에 저장됩니다. 스냅샷 사용 및 관리에 대한 추가 권장사항은 Compute Engine 디스크 스냅샷 권장사항을 참조하세요.
  • 리전 Persistent Disk 볼륨을 사용하면 영구 디스크 오류의 영향을 받지 않는 가용성이 높은 애플리케이션을 실행할 수 있습니다. 리전 Persistent Disk 볼륨을 만들면 Compute Engine은 디스크 복제본을 같은 리전의 다른 영역에 유지합니다. 데이터는 두 영역의 디스크에 동기식으로 복제됩니다. 두 영역 중 하나가 중단되어도 데이터를 계속 사용할 수 있습니다.

데이터베이스 가용성

HA 구성의 Cloud SQL과 같은 관리형 데이터베이스 서비스를 사용하는 경우 기본 데이터베이스에 오류가 발생하면 Cloud SQL이 자동으로 대기 데이터베이스로 장애 조치됩니다. 데이터베이스 엔드포인트의 IP 주소를 변경할 필요가 없습니다. Compute Engine VM에 배포된 자체 관리형 서드 파티 데이터베이스를 사용하는 경우 기본 데이터베이스를 사용할 수 없으면 내부 부하 분산기 또는 기타 메커니즘을 사용하여 애플리케이션이 다른 데이터베이스에 연결할 수 있는지 확인해야 합니다.

Compute Engine VM에 배포된 데이터베이스에 영역 간 장애 조치를 구현하려면 기본 데이터베이스 오류를 식별하는 메커니즘과 대기 데이터베이스에 장애 조치를 수행할 프로세스가 필요합니다. 장애 조치 메커니즘의 세부 사항은 사용하는 데이터베이스에 따라 달라집니다. 관찰자 인스턴스를 설정하여 기본 데이터베이스 오류를 감지하고 장애 조치를 조정할 수 있습니다. 분할 브레인 상황을 방지하고 불필요한 장애 조치를 방지하려면 장애 조치 규칙을 적절하게 구성해야 합니다. PostgreSQL 데이터베이스에 장애 조치를 구현하는 데 사용할 수 있는 아키텍처의 예시는 Compute Engine 기반 PostgreSQL 클러스터의 고가용성을 위한 아키텍처를 참조하세요.

추가 신뢰성 고려사항

워크로드의 클라우드 아키텍처를 빌드할 때는 다음 문서에서 제공하는 신뢰성 관련 권장사항과 추천을 검토합니다.

비용 최적화

이 섹션에서는 이 참조 아키텍처를 사용하여 빌드하는 리전 Google Cloud 토폴로지의 설정 및 운영 비용을 최적화하는 방법을 안내합니다.

VM 머신 유형

VM 인스턴스의 리소스 사용률 최적화에 도움이 되도록 Compute Engine에서 머신 유형 권장사항을 제공합니다. 권장사항에 따라 워크로드의 컴퓨팅 요구사항과 일치하는 머신 유형을 선택합니다. 예측 가능한 리소스 요구사항이 있는 워크로드의 경우 커스텀 머신 유형을 사용하여 머신 유형을 필요에 맞게 맞춤설정하고 비용을 절약할 수 있습니다.

VM 프로비저닝 모델

애플리케이션이 내결함성인 경우 스팟 VM을 사용하면 애플리케이션 및 웹 계층의 VM에 대한 Compute Engine 비용을 줄일 수 있습니다. 스팟 VM 비용은 일반 VM보다 훨씬 저렴합니다. 하지만 Compute Engine에서 스팟 VM을 사전에 중지하거나 삭제하여 용량을 확보할 수 있습니다. 스팟 VM은 선점을 허용할 수 있고 HA 요구사항이 없는 일괄 작업에 적합합니다. 스팟 VM은 일반 VM과 동일한 머신 유형, 옵션, 성능을 제공합니다. 하지만 영역의 리소스 용량이 제한되면 MIG는 필요한 용량을 다시 사용할 수 있게 될 때까지 지정된 대상 크기로 자동으로 수평 확장(즉, VM 만들기)하지 못할 수 있습니다.

리소스 사용률

스테이트리스(Stateless) MIG의 자동 확장 기능을 사용하면 애플리케이션에서 트래픽 증가를 원활하게 처리할 수 있으며 리소스 필요성이 줄어들면 비용을 절감할 수 있습니다. 스테이트풀(Stateful) MIG를 자동 확장할 수 없습니다.

서드 파티 라이선스

서드 파티 워크로드를 Google Cloud로 마이그레이션할 때 사용자 라이선스 사용(BYOL)을 통해 비용을 절감할 수 있습니다. 예를 들어 Microsoft Windows Server VM을 배포하기 위해 타사 라이선스에 대한 추가 비용이 발생하는 프리미엄 이미지를 사용하는 대신 커스텀 Windows BYOL 이미지를 만들고 사용할 수 있습니다. 그런 다음 Google Cloud에서 사용하는 VM 인프라에 대해서만 비용을 지불합니다. 이 전략은 타사 라이선스에 대한 기존 투자의 가치를 지속적으로 실현하는 데 도움이 됩니다. 사용자 라이선스 사용 방식을 사용할 경우에는 다음을 수행하는 것이 좋습니다.

  • 커스텀 머신 유형을 사용하여 메모리와 독립적으로 필요한 컴퓨팅 CPU 코어 수를 프로비저닝합니다. 이렇게 하면 서드 파티 라이선스 비용이 필요한 CPU 코어 수로 제한됩니다.
  • 동시 멀티스레딩(SMT)을 중지하여 코어당 vCPU 수를 2개에서 1개로 줄이고 라이선스 비용을 50%까지 줄입니다.

Compute Engine VM에 Microsoft SQL Server와 같은 서드 파티 데이터베이스를 배포하는 경우 서드 파티 소프트웨어의 라이선스 비용을 고려해야 합니다. Cloud SQL과 같은 관리형 데이터베이스 서비스를 사용하면 데이터베이스 라이선스 비용은 서비스 요금에 포함됩니다.

추가 비용 고려사항

워크로드의 아키텍처를 빌드할 때는 Google Cloud 아키텍처 프레임워크: 비용 최적화에서 제공하는 일반 권장사항과 추천도 고려하세요.

운영 효율성

이 섹션에서는 이 참조 아키텍처를 사용하여 효율적으로 운영할 수 있는 리전 Google Cloud 토폴로지를 설계하고 빌드할 때 고려해야 해야 요소를 설명합니다.

VM 구성 업데이트

MIG의 VM 구성(예: 머신 유형 또는 부팅 디스크 이미지)을 업데이트하려면 필수 구성으로 새 인스턴스 템플릿을 만든 후 새 템플릿을 MIG에 적용합니다. MIG는 자동 업데이트 또는 선택적 업데이트 방법을 통해 VM을 업데이트합니다. 가용성 및 운영 효율성 요구사항에 따라 적절한 방법을 선택합니다. 이러한 MIG 업데이트 방법에 대한 자세한 내용은 MIG에서 새 VM 구성 적용을 참조하세요.

VM 이미지

MIG 인스턴스 템플릿의 경우 Google에서 제공하는 공개 이미지를 사용하는 대신 애플리케이션에 필요한 구성과 소프트웨어가 포함된 커스텀 이미지를 만들고 사용하는 것이 좋습니다. 커스텀 이미지를 커스텀 이미지 계열로 그룹화할 수 있습니다. 이미지 계열은 항상 계열 내에 있는 최신 이미지를 가리키므로 인스턴스 템플릿과 스크립트에서 특정 이미지 버전에 대한 참조를 업데이트하지 않아도 최신 이미지를 사용할 수 있습니다.

확정 인스턴스 템플릿

MIG에 사용하는 인스턴스 템플릿에 서드 파티 소프트웨어를 설치할 수 있는 시작 스크립트가 포함된 경우 스크립트에서 소프트웨어 버전과 같은 소프트웨어 설치 매개변수를 명시적으로 지정해야 합니다. 그렇지 않으면 MIG에서 VM을 만들 때 VM에 설치된 소프트웨어가 일관되지 않을 수 있습니다. 예를 들어 인스턴스 템플릿에 Apache HTTP 서버 2.0(apache2 패키지)을 설치할 수 있는 시작 스크립트가 포함된 경우 스크립트에서 설치해야 하는 apache2 버전(예: 2.4.53)을 정확하게 지정해야 합니다. 자세한 내용은 확정 인스턴스 템플릿을 참조하세요.

추가 운영 고려사항

워크로드의 아키텍처를 빌드할 때 Google Cloud 아키텍처 프레임워크: 운영 우수성에 설명된 운영 효율성에 대한 일반적인 권장사항과 추천을 고려하세요.

성능 최적화

이 섹션에서는 이 참조 아키텍처를 사용하여 Google Cloud에서 워크로드 성능 요구사항을 충족하는 리전 토폴로지를 설계하고 빌드할 때 고려해야 하는 요소를 설명합니다.

VM 배치

VM 간 네트워크 지연 시간을 줄여야 하는 워크로드의 경우 압축 배치 정책을 만들고 MIG 템플릿에 적용할 수 있습니다. MIG에서 VM을 만들 때 서로 가까운 물리적 서버에 배치합니다. 자세한 내용은 압축 배치 정책을 사용하여 지연 시간 감소를 참조하세요.

VM 머신 유형

Compute Engine은 비용 및 성능 요구사항에 따라 다양한 사전 정의되고 맞춤설정 가능한 머신 유형을 제공합니다. 머신 유형은 머신 시리즈 및 계열로 그룹화됩니다. 다음 표에서는 다양한 워크로드 유형에 권장되는 머신 계열과 시리즈를 간략하게 설명합니다.

요구사항 권장 머신 제품군 머신 계열 예시
다양한 워크로드에 대한 최고의 가성비 범용 머신 계열 C3, C3D, E2, N2, N2D, Tau T2D, Tau T2A
코어당 최고 성능이며 컴퓨팅 집약적 워크로드에 최적화되어 있습니다. 컴퓨팅 최적화 머신 계열 C2, C2D, H3
메모리 집약적인 워크로드를 위한 높은 메모리 대 vCPU 비율 메모리 최적화 머신 제품군 M3, M2, M1
동시에 로드되는 대규모 워크로드에 적합한 GPU 가속기 최적화 머신 제품군 A2, G2

자세한 내용은 머신 계열 리소스 및 비교 가이드를 참조하세요.

VM 멀티스레딩

Compute Engine VM에 할당하는 각 가상 CPU(vCPU)는 단일 하드웨어 멀티 스레드로 구현됩니다. 기본적으로 2개의 vCPU가 물리적 CPU 코어를 공유합니다. 병렬이거나 부동 소수점 계산을 수행하는 워크로드(예: 유전자 서열 분석 및 금융 위험 모델링)의 경우 각 물리적 CPU 코어에서 실행되는 스레드 수를 줄여 성능을 향상시킬 수 있습니다. 자세한 내용은 코어당 스레드 수 설정을 참조하세요.

VM 멀티스레딩은 데이터베이스와 같은 일부 서드 파티 소프트웨어의 라이선스에 영향을 줄 수 있습니다. 자세한 내용은 서드 파티 소프트웨어의 라이선스 문서를 참조하세요.

네트워크 서비스 등급

네트워크 서비스 등급을 사용하면 워크로드의 네트워크 비용과 성능을 최적화할 수 있습니다. 프리미엄 등급 또는 표준 등급을 선택할 수 있습니다.

  • 프리미엄 등급은 Google의 안정성이 높은 글로벌 백본을 사용하여 최소한의 패킷 손실과 지연 시간을 최소화하는 데 도움이 줍니다. 트래픽은 최종 사용자와 가까운 전역 에지 접속 지점(PoP)에서 Google 네트워크를 출입합니다. 최적 성능을 위해 프리미엄 등급을 기본 등급으로 사용하는 것이 좋습니다.
  • 표준 등급을 사용하면 트래픽은 워크로드가 실행되는 Google Cloud 위치와 가장 가까운 에지 PoP에서 Google 네트워크로 들어오고 나갑니다. 표준 등급 가격은 프리미엄 등급보다 낮습니다. 표준 등급은 패킷 손실에 민감하지 않고 짧은 지연 시간에 대한 요구사항이 없는 트래픽에 적합합니다.

추가 성능 고려사항

워크로드의 아키텍처를 빌드할 때 Google Cloud 아키텍처 프레임워크: 성능 최적화에서 제공하는 일반적인 권장사항과 추천을 고려하세요.

다음 단계

참여자

저자: Kumar Dhanagopal | 크로스 프로덕트 솔루션 개발자

기타 참여자: