이 문서는 향후 다른 Google Cloud 리전으로 워크로드를 확장 및 마이그레이션하거나 리전 간에 워크로드를 마이그레이션할 때 영향을 최소화하는 방식으로 워크로드를 설계하는 데 도움이 됩니다. 이 문서는 이러한 활동을 계획 중이거나 향후 이러한 활동을 수행할 기회를 평가하고 그 결과를 살펴보고 싶은 경우에 유용합니다.
이 문서는 시리즈의 일부입니다.
이 시리즈의 안내는 리전 간 마이그레이션 또는 여러 리전으로의 확장을 미리 계획하지 않은 경우에도 유용합니다. 이 경우 리전 간에 마이그레이션하고 여러 리전으로 확장할 수 있도록 인프라, 워크로드, 데이터를 준비하기 위한 추가 노력이 필요할 수 있습니다.
이 문서는 다음을 수행하는 데 도움이 됩니다.
- 시작 영역 준비
- 리전 간 마이그레이션을 위한 워크로드 준비
- 컴퓨팅 리소스 준비
- 데이터 스토리지 리소스 준비
- 원본 환경 사용 중단 준비
시작 영역 준비
이 섹션에서는 여러 리전 간에 마이그레이션할 때 시작 영역(클라우드 기반이라고도 함)을 확장하기 위해 고려해야 할 사항을 중점적으로 살펴봅니다.
첫 번째 단계는 기존 시작 영역의 여러 측면을 다시 평가하는 것입니다. 워크로드를 마이그레이션하려면 시작 영역이 이미 있어야 합니다. 워크로드를 호스팅하는 리전에 이미 시작 영역이 있더라도 시작 영역이 다른 리전에 있는 워크로드 배포를 지원하지 않을 수도 있으므로 이를 대상 리전으로 확장해야 합니다. 이미 있는 시작 영역 중 일부에는 시작 영역에 대한 상당한 재작업 없이 다른 리전을 지원할 수 있는 설계가 있을 수 있습니다(예: ID 및 액세스 관리 또는 리소스 관리). 하지만 네트워크나 데이터와 같은 추가 요소로 인해 확장 프로그램에 대한 계획이 필요할 수 있습니다. 재평가 프로세스에서는 워크로드의 주요 요구사항을 고려하여 나중에 마이그레이션 중에 전문화할 수 있는 일반 기반을 설정할 수 있도록 해야 합니다.
엔터프라이즈 고려사항
업계 및 정부 표준, 규정, 인증과 같은 측면에서 워크로드를 다른 리전으로 이동할 때는 요구사항이 다를 수 있습니다. 다른 국가에 실제로 위치한 Google 리전에서 실행되는 워크로드는 해당 국가의 법률 및 규정을 따라야 합니다. 또한 업계 표준에 따라 해외에서 실행되는 워크로드에 대한 특정 요구사항(특히 보안 측면)이 있을 수 있습니다. Google Cloud 리전은 단일 국가에서 리소스를 실행하도록 빌드되므로 특정 규정을 준수하기 위해 워크로드가 다른 Google 리전에서 해당 국가로 마이그레이션되는 경우도 있습니다. 이러한 '국가 내' 마이그레이션을 수행할 때는 온프레미스에서 실행되는 데이터를 다시 평가하여 새 리전에서 데이터를 Google Cloud로 마이그레이션할 수 있는지 확인하는 것이 중요합니다.
ID 및 액세스 관리
마이그레이션을 계획하는 경우 이미 Google Cloud에 있는 리전에 대해 많은 ID 및 액세스 변경을 계획할 필요가 없습니다. Google Cloud에서의 ID와 리소스에 대한 액세스는 일반적으로 리소스가 실행되는 리전이 아닌 리소스의 특성에 따라 결정됩니다. 다음과 같은 사항을 고려해야 합니다.
- 팀 설계: 일부 회사는 여러 팀이 서로 다른 리소스를 처리하도록 구성되어 있습니다. 리소스 구조의 변경으로 인해 워크로드가 다른 리전으로 마이그레이션되는 경우 다른 팀에서 특정 리소스를 처리하는 것이 가장 적합할 수 있으며, 이 경우 그에 따라 액세스를 조정해야 합니다.
- 이름 지정 규칙: 이름 지정 규칙은 기능에 기술적 영향을 미치지 않을 수 있지만, 특정 리전을 지칭하는 이름 규칙으로 정의된 리소스가 있는 경우 몇 가지 사항을 고려해야 할 수 있습니다. 대표적인 예로 리전을 프리픽스로 사용하여 이름을 지정한 Compute Engine 가상 머신(VM)(예:
europe-west1-backend-1
)과 같이 이미 복제된 리전이 여러 개 있는 경우가 있습니다. 마이그레이션 도중 특정 이름 지정 규칙을 사용하는 파이프라인을 혼동하거나 최악의 경우 파이프라인의 중단을 방지하려면 새 리전을 반영하도록 이름을 변경하는 것이 좋습니다.
연결 및 네트워킹
네트워크 설계는 마이그레이션 실행 방식의 여러 측면에 영향을 미치므로 워크로드 이동 방법을 계획하기 전에 이 설계를 해결해야 합니다.
Google Cloud와의 온프레미스 연결은 리전에 다르게 설계될 수 있으므로 마이그레이션 시 반드시 재평가해야 하는 요소 중 하나라는 점에 유의하세요. 이 요소의 한 가지 예로 특정 리전에 대한 VLAN 연결을 통해 Google Cloud에 연결되는 Cloud Interconnect를 들 수 있습니다. 리전 간 트래픽을 방지하려면 리전을 닫기 전에 VLAN 연결이 연결된 리전을 변경해야 합니다. 고려해야 할 또 다른 요소는 Partner Interconnect를 사용하는 경우 리전을 마이그레이션하면 VLAN 연결을 Google Cloud에 연결할 다른 물리적 위치를 선택하는 데 도움이 될 수 있다는 점입니다. 이 고려사항은 Cloud VPN을 사용 중이고 마이그레이션 중에 서브넷 주소를 변경하기로 결정한 경우에도 적용됩니다. 새 네트워킹을 반영하도록 라우터를 재구성해야 합니다.
Google Cloud의 가상 프라이빗 클라우드(VPC)는 전역 리소스이지만 단일 서브넷은 항상 한 결합되어 있으므로, 마이그레이션 후에는 워크로드에 동일한 서브넷을 사용할 수 없습니다. 서브넷은 IP가 겹칠 수 없으므로 동일한 주소를 유지하려면 새 VPC를 만들어야 합니다. Cloud DNS를 사용하면 이전 리전을 닫기 전에 마이그레이션된 워크로드의 트래픽을 라우팅하기 위해 DNS 피어링과 같은 기능을 활용할 수 있으므로 이 프로세스가 간소화됩니다.
Google Cloud에서 기반을 구축하는 방법에 대한 자세한 내용은 Google Cloud로 마이그레이션: 기반 계획 및 구축을 참조하세요.
리전 간 마이그레이션을 위한 워크로드 준비
Google Cloud에서 인프라를 설정 중이고 나중에 다른 리전으로 마이그레이션할 계획이거나, 이미 Google Cloud를 사용 중이고 다른 리전으로 마이그레이션해야 하는 경우, 가장 간단한 방법으로 워크로드를 마이그레이션해야 노력을 줄이고 위험을 최소화할 수 있습니다. 모든 워크로드가 마이그레이션이 가능한 상태에 있는지 확인하려면 다음과 같은 접근 방식을 사용하는 것이 좋습니다.
- 특정 네트워크 토폴로지에서 쉽게 복제 가능하고 느슨하게 결합된 네트워크 설계를 선호합니다. Google Cloud는 현재 네트워크 구성을 해당 네트워크를 사용하는 리소스에서 분리하는 데 도움이 되는 다양한 제품을 제공합니다. 이러한 제품의 예로는 VM에서 내부 서브넷 IP를 분리할 수 있는 Cloud DNS가 있습니다.
- 멀티 리전 또는 전역 구성을 지원하는 제품을 설정합니다. 둘 이상의 리전을 포함하는 구성을 지원하는 제품은 일반적으로 다른 리전으로 마이그레이션하는 프로세스를 간소화합니다.
- 데이터에 관리형 리전 간 복제본이 있는 관리형 서비스를 고려합니다. 이 문서의 다음 섹션에 설명된 대로 일부 관리형 서비스를 사용하면 일반적으로 백업 또는 고가용성을 위해 다른 리전에 복제본을 만들 수 있습니다. 이 기능은 한 리전에서 다른 리전으로 데이터를 마이그레이션하는 데 중요할 수 있습니다.
일부 Google Cloud 서비스는 멀티 리전 배포 또는 전역 배포를 지원하도록 설계되었습니다. 일부 구성을 조정해야 할 수도 있지만 이러한 서비스를 마이그레이션할 필요는 없습니다.
컴퓨팅 리소스 준비
이 섹션에서는 Google Cloud의 컴퓨팅 리소스에 대한 개요와 다른 리전으로의 마이그레이션을 준비하기 위한 설계 원칙을 설명합니다.
이 문서에서는 다음 Google Cloud 컴퓨팅 제품에 대해 중점적으로 설명합니다.
Compute Engine
Compute Engine은 고객에게 VM을 제공하는 Google Cloud 서비스입니다.
Compute Engine 리소스를 한 리전에서 다른 리전으로 마이그레이션하려면 네트워킹 고려사항 외에도 다양한 요소를 평가해야 합니다.
다음을 수행하는 것이 좋습니다.
- 컴퓨팅 리소스 확인: VM의 호스팅 리전을 변경할 때 처음 발생할 수 있는 제한사항 중 하나는 CPU 플랫폼의 가용성입니다. 마이그레이션 중에 머신 시리즈를 변경해야 하는 경우 해당 시리즈에서 현재 VM의 운영체제를 지원하는지 확인합니다. 일반적으로 이 문제는 모든 Google Cloud 컴퓨팅 서비스로 확장될 수 있으므로(일부 새 리전에는 Cloud Run 또는 Cloud GPU와 같은 서비스가 없을 수 있음) 마이그레이션을 계획하기 전에 필요한 모든 컴퓨팅 서비스를 대상 리전에서 사용할 수 있는지 확인해야 합니다.
- 부하 분산 및 확장 구성: Compute Engine은 Compute Engine 인스턴스 간의 트래픽 부하 분산을 지원하고 수요에 따라 MIG에서 가상 머신을 자동으로 추가하거나 제거하는 자동 확장을 지원합니다. 부하 분산과 자동 확장을 구성하여 자체 관리 솔루션의 관리 부담을 피하면서 환경의 안정성과 유연성을 높이는 것이 좋습니다. Compute Engine에서 부하 분산과 자동 확장을 구성하는 방법에 대한 자세한 내용은 부하 분산 및 확장을 참조하세요.
- 영역 DNS 이름 사용: 리전 간 서비스 중단 위험을 완화하려면 영역 DNS 이름을 사용하여 환경에서 DNS 이름을 사용하는 가상 머신을 고유하게 식별하는 것이 좋습니다. Google Cloud는 기본적으로 Compute Engine 가상 머신에 영역 DNS 이름을 사용합니다. Compute Engine 내부 DNS의 작동 방식에 대한 자세한 내용은 내부 DNS 개요를 참조하세요. 향후 리전 간 마이그레이션을 용이하게 하고 구성을 더욱 유지보수하기 쉽게 만들려면 나중에 변경할 수 있는 구성 매개변수로 영역 DNS 이름을 사용하는 것이 좋습니다.
- 동일한 관리형 인스턴스 그룹(MIG) 템플릿 사용: Compute Engine을 사용하면 한 리전의 여러 영역에 걸쳐 가상 머신을 자동으로 프로비저닝하는 리전 MIG를 자동으로 만들 수 있습니다. 이전 리전에서 템플릿을 사용하는 경우 동일한 템플릿을 사용하여 새 리전에 MIG를 배포할 수 있습니다.
GKE
Google Kubernetes Engine(GKE)을 사용하면 Kubernetes에서 컨테이너화된 워크로드를 배포, 관리, 확장할 수 있습니다.
마이그레이션을 위해 GKE 워크로드를 준비하려면 다음 설계 포인트와 GKE 기능을 고려하세요.
- Cloud Service Mesh: Istio 메시의 관리형 구현입니다. 클러스터에 Cloud Service Mesh를 채택하면 클러스터로 들어오는 네트워크 트래픽을 보다 세부적으로 제어할 수 있습니다. Cloud Service Mesh의 주요 기능 중 하나는 두 클러스터 간에 서비스 메시를 만들 수 있다는 것입니다. 이 기능을 사용하면 새 리전에서 GKE 클러스터를 만들고 이를 서비스 메시에 추가하여 한 리전에서 다른 리전으로의 마이그레이션을 계획할 수 있습니다. 이 방법을 사용하면 새 클러스터에 워크로드를 배포하고 점진적으로 트래픽을 라우팅할 수 있으므로 메시 라우팅을 수정하여 롤백하는 동시에 새 배포를 테스트할 수 있습니다.
- 구성 동기화: 클러스터 운영자와 플랫폼 관리자가 단일 소스에서 구성을 배포할 수 있도록 오픈소스 코어를 기반으로 하는 GitOps 서비스입니다. 구성 동기화는 하나 이상의 클러스터를 지원할 수 있으므로 단일 정보 소스를 사용하여 클러스터를 구성할 수 있습니다. 이 구성 동기화 기능을 사용하여 기존 클러스터의 구성을 새 리전의 클러스터에 복제하고 해당 리전의 특정 리소스를 맞춤설정할 수 있습니다.
- Backup for GKE: 이 기능을 사용하면 클러스터 영구 데이터를 주기적으로 백업하고 데이터를 동일한 클러스터 또는 새 클러스터로 복원할 수 있습니다.
Cloud Run
Cloud Run은 Google Cloud에 컨테이너를 배포하기 위한 가벼운 접근 방식을 제공합니다. Cloud Run 서비스는 리전별 리소스이며 리전에 있는 여러 영역 간에 복제됩니다. Cloud Run 서비스를 배포할 때 인스턴스를 배포할 리전을 선택한 후 이 기능을 사용하여 다른 리전에 워크로드를 배포할 수 있습니다.
VMware Engine
Google Cloud VMware Engine은 Google Cloud에서 VMware 플랫폼을 실행할 수 있는 완전 관리형 서비스입니다. VMware 환경은 기본적으로 vSphere, vCenter, vSAN, NSX-T, HCX, 해당 도구를 포함하여 Google Cloud 위치의 Google Cloud 베어메탈 인프라에서 실행됩니다.
VMware Engine 인스턴스를 다른 리전으로 마이그레이션하려면 새 리전에서 프라이빗 클라우드를 만든 후 VMware 도구를 사용하여 인스턴스를 이동해야 합니다.
마이그레이션을 계획할 때 Compute Engine 환경에서 DNS 및 부하 분산도 고려해야 합니다. VMware Engine은 공개 인터넷에 게시된 권한 DNS 호스팅, VPC 네트워크에 표시되는 비공개 영역, VPC 네트워크에서 이름 변환 관리를 위한 DNS 전달 및 피어링을 제공하는 관리형 DNS 호스팅 서비스인 Google Cloud DNS를 사용합니다.
마이그레이션 계획은 멀티 리전 부하 분산 및 DNS 구성의 테스트를 지원할 수 있습니다.
데이터 스토리지 리소스 준비
이 섹션에서는 Google Cloud의 데이터 스토리지 리소스에 대한 개요와 다른 리전으로의 마이그레이션을 준비하는 방법에 대한 기본 사항을 설명합니다.
데이터가 이미 Google Cloud에 있으면 변환 없이 데이터를 호스팅하는 솔루션이 존재하거나 Google Cloud에서 호스팅할 수 있으므로 마이그레이션이 간소화됩니다.
데이터베이스 데이터를 다른 리전에 복사하고 다른 위치에서 데이터를 복원하는 기능은 재해 복구(DR)에서 흔히 볼 수 있는 패턴입니다. 따라서 이 문서에 설명된 일부 패턴은 데이터베이스 백업 및 복구와 같은 DR 메커니즘을 사용합니다.
이 문서에서는 다음과 같은 관리형 서비스를 설명합니다.
이 문서에서는 사용 중인 스토리지 솔루션이 컴퓨팅 리소스와 함께 배치되는 리전 인스턴스라고 가정합니다.
Cloud Storage
Cloud Storage는 여러 시스템에서 Cloud Storage로 파일을 자동으로 전송하는 Storage Transfer Service를 제공합니다. 이 서비스는 백업과 리전 간 마이그레이션을 위해 데이터를 다른 리전으로 복제하는 데 사용할 수 있습니다.
Cloud SQL
Cloud SQL은 다양한 유형의 데이터베이스를 호스팅하는 관계형 데이터베이스 서비스를 제공합니다. Cloud SQL은 인스턴스 데이터를 다른 리전에 복제할 수 있게 해주는 리전 간 복제 기능을 제공합니다. 이 기능은 Cloud SQL 인스턴스의 백업 및 복원을 위한 일반적인 패턴이지만 다른 리전에 있는 두 번째 복제본을 기본 복제본으로 승격할 수도 있습니다. 이 기능을 사용하여 두 번째 리전에서 읽기 복제본을 만든 후 워크로드를 마이그레이션하면 이를 기본 복제본으로 승격할 수 있습니다. 일반적으로 데이터베이스의 경우 관리형 서비스는 데이터 복제 프로세스를 간소화하여 마이그레이션 중에 새 리전에서 복제본을 더 쉽게 만들 수 있도록 합니다.
마이그레이션을 처리하는 또 다른 방법은 Database Migration Service를 사용하여 여러 소스의 SQL 데이터베이스를 Google Cloud로 마이그레이션하는 것입니다. 지원되는 소스 중에는 다른 Cloud SQL 인스턴스도 있으며, 다른 리전으로 마이그레이션할 수 있지만 다른 프로젝트로는 마이그레이션할 수 없다는 유일한 제한사항이 있습니다.
Filestore
이 문서의 앞부분에서 설명한 대로 Filestore의 백업 및 복원 기능을 사용하면 다른 리전으로 복원할 수 있는 파일 공유의 백업을 만들 수 있습니다. 이 기능을 사용하여 리전 간 마이그레이션을 수행할 수 있습니다.
Bigtable
Cloud SQL과 마찬가지로 Bigtable은 복제를 지원합니다. 이 기능을 사용하면 설명된 것과 동일한 패턴을 복제할 수 있습니다. Bigtable 위치 목록에서 대상 리전에서 서비스를 사용할 수 있는지 확인합니다.
또한 Filestore와 마찬가지로 Bigtable은 백업 및 복원을 지원합니다. 이 기능은 Filestore와 마찬가지로 백업을 만들고 새 리전의 다른 인스턴스에서 복원하여 마이그레이션을 구현하는 데 사용할 수 있습니다.
마지막 옵션은 예를 들어 Cloud Storage에서 테이블을 내보내는 것입니다. 이러한 내보내기를 통해 다른 서비스에서 데이터를 호스팅한 다음 해당 데이터를 리전 내 인스턴스로 가져올 수 있습니다.
Firestore
Firestore 위치가 프로젝트의 App Engine 존재 여부에 바인딩될 수 있으며, 이 경우 일부 시나리오에서는 Firestore 인스턴스가 멀티 리전에 걸쳐 있어야 합니다. 이러한 마이그레이션 시나리오에서는 App Engine을 고려하여 Firestore에 적합한 솔루션을 설계해야 합니다. 실제로 us-central
또는
europe-west
위치가 설정된 App Engine 앱이 이미 있는 경우 Firestore 데이터베이스는 멀티 리전으로 간주됩니다.
리전 위치가 있고 다른 위치로 마이그레이션하려는 경우 관리형 내보내기 및 가져오기 서비스를 사용하면 Cloud Storage 버킷을 사용하여 Firestore 항목을 가져오고 내보낼 수 있습니다. 이 방법은 한 리전에서 다른 리전으로 인스턴스를 이동하는 데 사용할 수 있습니다. 또 다른 옵션은 Firestore 백업 및 복원 기능을 사용하는 것입니다. 이 옵션은 가져오기 및 내보내기보다 비용이 저렴하고 더 간단합니다.
원본 환경 사용 중단 준비
원본 환경을 사용 중단하고 새 환경으로 전환하기 전에 미리 준비해야 합니다.
대략적으로 원본 환경을 사용 중단하기 전에 다음 사항을 고려해야 합니다.
- 새 환경 테스트: 이전 환경에서 새 환경으로 트래픽을 전환하기 전에 테스트를 수행하여 애플리케이션의 정확성을 검증할 수 있습니다. 새로 마이그레이션된 애플리케이션에서 수행할 수 있는 기본 단위 및 통합 테스트 외에도 다른 테스트 전략이 있습니다. 새 환경을 소프트웨어의 새 버전으로 간주하고 트래픽 마이그레이션을 검증에 사용되는 A/B 테스트와 같은 일반적인 패턴으로 구현할 수 있습니다. 또 다른 방법은 수신 트래픽을 원본 환경과 새 환경에서 복제하여 기능이 유지되는지 확인하는 것입니다.
- 다운타임 계획: 블루-그린과 같이 한 환경에서 다른 환경으로 트래픽을 전환하는 마이그레이션 전략을 선택할 경우 계획된 다운타임 채택을 고려하세요. 다운타임을 통해 전환을 더 효과적으로 모니터링하고 클라이언트 측에서 예기치 않은 오류를 방지할 수 있습니다.
- 롤백: 트래픽 마이그레이션을 위해 채택된 전략에 따라 새 환경에 오류나 구성 오류가 발생할 경우 롤백을 구현해야 할 수 있습니다. 환경을 롤백할 수 있으려면 새 환경의 상태를 감지할 수 있는 모니터링 인프라가 있어야 합니다.
새 리전에서 확장 테스트를 수행하고 오류 없이 새 리전에서 서비스를 시작한 후에만 첫 번째 리전에서 서비스를 종료할 수 있습니다. 새로 마이그레이션된 리전에 문제가 없는 것으로 확인될 때까지 제한된 기간 동안 첫 번째 리전의 백업을 유지하는 것이 좋습니다.
또한 아직 해결책이 없다고 가정하여 이전 리전을 재해 복구 사이트로 승격하려는 경우에도 고려해야 합니다. 이 방법을 사용하려면 사이트의 안정성을 높이는 추가적인 설계가 필요합니다. DR을 올바르게 설계하고 계획하는 방법에 대한 자세한 내용은 재해 복구 계획 가이드를 참조하세요.
다음 단계
- 안정적인 단일 및 멀티 리전 환경을 설계하기 위한 보다 일반적인 설계 원칙과 Google이 리전 및 멀티 리전 서비스로 안정성을 높이는 방법에 대한 자세한 내용은 클라우드 인프라 서비스 중단을 위한 재해 복구 설계: 일반적인 주제를 참조하세요.
- 이 설계 가이드에서 사용되는 Google Cloud 제품을 자세히 알아보세요.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 Cloud 아키텍처 센터를 확인하세요.
참여자
저자: Valerio Ponza | 기술 솔루션 컨설턴트
기타 참여자:
- 마르코 페라리 | 클라우드 솔루션 설계자
- Travis Webb | 솔루션 설계자
- Lee Gates | 그룹 제품 관리자
- Rodd Zurcher | 솔루션 설계자