재해 복구 구성 요소

이 도움말은 Google Cloud의 재해 복구(DR)에 대해 설명하는 시리즈 중 두 번째 부분입니다. 이 부분에서는 Google Cloud 제품과 여러 플랫폼에서 작동하는 제품 모두에서 DR 계획의 구성 요소로 사용할 수 있는 서비스 및 제품을 설명합니다.

시리즈는 다음과 같이 구성되어 있습니다.

소개

Google Cloud에는 재해 복구(DR) 아키텍처의 일부로 사용할 수 있는 다양한 제품이 있습니다. 이 섹션에서는 Google Cloud DR 구성 요소로 가장 일반적으로 사용되는 제품의 DR 관련 기능에 대해 설명합니다.

이러한 서비스에는 대부분 고가용성(HA) 기능이 있습니다. HA는 DR과 완전히 겹치지는 않지만 HA의 많은 목표는 DR 계획 설계에도 적용됩니다. 예를 들어 HA 기능을 활용하면 가동 시간을 최적화하고 단일 VM 장애와 같은 소규모 장애의 영향을 완화할 수 있는 아키텍처를 설계할 수 있습니다. DR과 HA의 관계에 대한 자세한 내용은 재해 복구 계획 가이드를 참조하세요.

다음 섹션에서는 이러한 Google Cloud DR 구성 요소에 대해 설명하고 이러한 구성 요소가 DR 목표를 구현하는 데 어떻게 도움이 되는지 설명합니다.

컴퓨팅 및 저장소

Compute Engine
  • 확장 가능한 컴퓨팅 리소스
  • 사전 정의 및 커스텀 머신 유형
  • 빠른 부팅 시간
  • 스냅샷
  • 인스턴스 템플릿
  • 관리형 인스턴스 그룹
  • 예약 인스턴스
  • 영구 디스크
  • 라이브 마이그레이션
Cloud Storage
  • 내구성 높은 객체 저장소
  • 지리적 중복 스토리지
  • 스토리지 클래스
  • 객체 수명 주기 관리
  • 다른 소스에서 데이터 전송
  • 기본적인 저장 데이터 암호화
GKE
  • 컨테이너식 애플리케이션 배포 및 확장을 위한 관리형 환경
  • 노드 자동 복구
  • 활성 및 준비 여부 프로브
  • 영구 볼륨
  • 멀티 영역 및 리전 클러스터
  • 리전 간 클러스터 관리를 위한 명령줄 도구

Compute Engine

Compute Engine은 가상 머신(VM) 인스턴스를 제공하며 Google Cloud의 주축 역할을 합니다. Compute Engine 인스턴스의 구성, 시작, 모니터링 외에도 일반적으로 DR 계획을 구현하기 위해 다양한 관련 기능을 사용합니다.

DR 시나리오의 경우 삭제 보호 플래그를 설정하여 실수로 인한 VM 삭제를 방지할 수 있습니다. 이는 특히 데이터베이스와 같은 상태 저장 서비스를 호스팅하는 경우에 유용합니다. 낮은 RTO 및 RPO 값을 충족하려면 강력한 시스템 설계를 위한 권장사항을 따르세요.

애플리케이션이 사전 설치되어 있는 인스턴스를 구성한 다음 해당 구성을 커스텀 이미지로 저장할 수 있습니다. 커스텀 이미지는 달성하려는 RTO를 반영할 수 있습니다.

인스턴스 템플릿

Compute Engine 인스턴스 템플릿을 사용하여 VM의 구성 세부정보를 저장한 다음 기존 인스턴스 템플릿에서 인스턴스를 생성할 수 있습니다. 이 템플릿을 사용하면 필요한 만큼 인스턴스를 실행할 수 있으며 DR 대상 환경을 구축해야 할 때 원하는 방식으로 정확하게 구성할 수 있습니다. 인스턴스 템플릿은 전역적으로 복제되므로 Google Cloud 어디에서나 동일한 구성으로 쉽게 인스턴스를 다시 만들 수 있습니다.

커스텀 이미지를 사용하거나 기존 VM 인스턴스를 기반으로 인스턴스 템플릿을 만들 수 있습니다.

이 문서 뒷부분의 이미지 구성 및 배포 속도 조정 섹션에 Compute Engine 이미지 사용에 대한 자세한 설명이 나와 있습니다.

관리형 인스턴스 그룹

관리형 인스턴스 그룹은 Cloud Load Balancing(이 문서의 뒷부분에서 설명)과 함께 작동하여 영역 간에 복사된 동일한 구성의 인스턴스 그룹으로 트래픽을 분산합니다. 관리형 인스턴스 그룹은 자동 확장 및 자동 복구와 같은 기능을 허용하며 여기에서 관리형 인스턴스 그룹이 인스턴스를 자동으로 삭제하고 다시 만들 수 있습니다.

예약 인스턴스

Compute Engine에서는 추가 GPU 또는 로컬 SSD를 사용하거나 사용하지 않고 커스텀 머신 유형이나 사전 정의된 머신 유형을 사용해 특정 영역에서 VM 인스턴스를 예약할 수 있습니다. 이 기능은 사전에 완전히 구성하여 배포할 필요 없이 복구 리소스를 예약하여 장애 조치에 계속 사용할 수 있는 콜드 DR 시나리오에서 유용합니다.

영구 디스크 및 스냅샷

영구 디스크는 인스턴스에서 액세스할 수 있는 내구성 있는 네트워크 스토리지 기기입니다. 영구 디스크는 인스턴스와 독립된 위치에 존재하므로 인스턴스를 삭제한 후에도 영구 디스크를 분리하고 이동하여 데이터를 보존할 수 있습니다.

재난 발생시 영구 디스크를 다시 만들고 재현할 수 있는 Compute Engine VM의 증분 백업 또는 스냅샷을 리전 간에 복사하여 사용할 수 있습니다. 또한 영구 디스크 스냅샷 만들기로 사용자 오류로 인한 데이터 손실을 방지할 수 있습니다. 스냅샷은 증분적이며, 스냅샷 디스크가 실행 중인 인스턴스에 연결되어 있더라도 단 몇 분이면 스냅샷을 생성할 수 있습니다.

영구 디스크는 장비 고장 시 데이터를 보호하고, 데이터 센터 유지보수 이벤트를 통해 데이터 가용성을 보장하는 중복 기능을 기본 제공합니다. 영구 디스크는 영역 또는 리전별로 사용됩니다. 리전 영구 디스크는 리전의 두 영역 간에 쓰기를 복제합니다. 영역 장애 시 백업 VM 인스턴스는 보조 영역에 있는 리전 영구 디스크를 강제 연결할 수 있습니다. 자세한 내용은 리전 영구 디스크를 사용하는 고가용성 옵션을 참조하세요.

라이브 마이그레이션

라이브 마이그레이션은 소프트웨어 또는 하드웨어 업데이트와 같은 호스트 시스템 이벤트가 발생하더라도 가상 머신 인스턴스가 계속 실행되게 합니다. Compute Engine은 사용자가 VM을 재부팅할 필요 없이 동일 영역에서 실행 중인 인스턴스를 또 다른 호스트로 라이브 이전합니다. 이렇게 해서 Google은 사용자의 VM에 영향을 주지 않으면서도 인프라를 보호하고 안정적인 상태로 유지하는 데 반드시 필요한 유지관리를 수행할 수 있습니다.

가상 디스크 가져오기 도구

가상 디스크 가져오기 도구를 사용하면 VMDK, VHD, RAW 등의 파일 형식을 가져와서 새 Compute Engine 가상 머신을 만들 수 있습니다. 이 도구를 사용하면 온프레미스 가상 머신과 구성이 동일한 Compute Engine 가상 머신을 만들 수 있습니다. 이는 이미 이미지에 설치된 소프트웨어의 소스 바이너리에서 Compute Engine 이미지를 구성할 수 없는 경우에 좋은 방법입니다.

Cloud Storage

Cloud Storage는 백업 파일을 저장하는 데 이상적인 객체 저장소입니다. 다음 다이어그램에 설명된 대로 특정 사용 사례에 적합한 여러 가지 스토리지 클래스가 제공됩니다.

액세스 빈도가 높은 경우를 위한 표준 스토리지, 액세스 빈도가 낮은 경우를 위한 Nearline 및 Coldline Storage, 액세스 빈도가 가장 낮은 경우를 위한 Archive Storage를 보여주는 다이어그램

DR 시나리오에서는 Nearline, Coldline, Archive Storage가 특히 유용합니다. 이러한 스토리지 클래스를 사용하면 표준 스토리지에 비해 스토리지 비용을 줄일 수 있습니다. 그러나 이러한 클래스에 저장된 데이터 또는 메타데이터를 검색하는 데는 추가 비용이 들며 최소 저장 기간에도 요금이 부과됩니다. Nearline은 월 1회 액세스가 가능한 백업 시나리오를 위해 설계되었으므로 비용을 낮게 유지하면서 정기적인 DR 스트레스 테스트를 수행하는 데 이상적입니다.

Nearline, Coldline, Archive는 모두 액세스 빈도가 낮은 경우에 최적화되어 있으며 가격 책정 모델은 이를 염두에 두고 설계되었습니다. 따라서 최소 저장 기간에 대한 요금이 청구되며, 이러한 클래스에서 클래스의 최소 저장 기간이 지난 데이터 또는 메타데이터를 검색하면 추가 요금이 발생합니다.

Storage Transfer Service를 사용하면 Amazon S3 또는 HTTP 기반 소스에서 Cloud Storage로 데이터를 가져올 수 있습니다. DR 시나리오에서 Storage Transfer Service를 사용하여 다음을 수행할 수 있습니다.

  • 다른 저장소 제공업체의 데이터를 Cloud Storage 버킷에 백업합니다.
  • 멀티 리전의 버킷에서 단일 리전의 버킷으로 데이터를 이동하여 백업 저장 비용을 줄입니다.

GKE

GKE는 컨테이너식 애플리케이션을 배포하기 위한 관리형 환경으로 프로덕션에 즉시 사용 가능합니다. GKE에서는 HA 시스템을 조정할 수 있으며 다음과 같은 기능이 포함됩니다.

  • 노드 자동 복구. 노드가 장시간(약 10분) 동안 연속으로 상태 확인에 실패하면 GKE는 해당 노드에 대한 복구 프로세스를 시작합니다.
  • 활성 여부 프로브. 포드가 실행 중임을 GKE에 주기적으로 알리는 활성 여부 조사를 지정할 수 있습니다. pod가 프로브에 실패하면 pod를 다시 시작할 수 있습니다.
  • 영구 볼륨. 데이터베이스는 컨테이너의 수명을 초과하여 지속될 수 있어야 합니다. Compute Engine 영구 디스크에 매핑되는 영구 볼륨 추상화를 사용하면 개별 컨테이너와 독립적으로 스토리지 가용성을 유지할 수 있습니다.
  • 멀티 영역 및 리전 클러스터. Kubernetes 리소스를 한 리전 내의 여러 영역에 배포할 수 있습니다.
  • Kubemci. 이 도구를 사용하면 서로 다른 지역의 여러 GKE 클러스터에 트래픽을 부하 분산하도록 전역 부하 분산기를 구성할 수 있습니다.

네트워킹 및 데이터 전송

Cloud Load Balancing
  • 상태 확인
  • 단일 Anycast IP
  • 리전 간
  • Cloud CDN 통합
  • 자동 확장 통합
Traffic Director
  • Google 관리형 전역 L7 ILB
  • xDSv2 호환 공개 서비스 프록시를 위한 제어 영역
  • VM 및 컨테이너 지원
  • 상태 확인 오프로딩
  • 빠른 자동 확장
  • 고급 요청 라우팅 및 풍부한 트래픽 제어 정책
Cloud DNS
  • 프로그래매틱 DNS 관리
  • 액세스 제어
  • 영역에 서비스를 제공하는 Anycast
Cloud Interconnect
  • Cloud VPN(IPsec VPN)
  • 다이렉트 피어링

Cloud Load Balancing

Cloud Load Balancing은 사용자 요청을 인스턴스 집합에 분산하여 Compute Engine에 HA를 제공합니다. 장애가 발생한 인스턴스로 트래픽이 라우팅되지 않도록 인스턴스의 작업 가능 여부를 판단하는 상태 확인 기능을 사용하여 Cloud Load Balancing을 구성할 수 있습니다.

Cloud Load Balancing은 Compute Engine 인스턴스에 사용할 전역으로 액세스 가능한 단일 IP 주소를 제공합니다. 애플리케이션은 다른 지역(예: 유럽 및 미국)에서 실행중인 인스턴스가 있을 수 있으며 최종 사용자는 가장 가까운 인스턴스 세트로 연결됩니다. 인터넷에 노출된 서비스에 대한 부하 분산을 제공하는 것 외에도 비공개 부하 분산 IP 주소 배후의 서비스를 위해 내부 부하 분산을 구성할 수 있습니다. 이 IP 주소는 Virtual Private Cloud(VPC) 내부의 VM 인스턴스에서만 액세스할 수 있습니다.

Traffic Director

Traffic Director서비스 메시용 완전 관리형 트래픽 제어 영역을 배포할 수 있습니다. Traffic Director는 Compute Engine과 GKE 모두에서 실행되는 서비스 프록시의 구성을 관리합니다. HA를 위해 여러 리전에 서비스를 배포할 수 있습니다. Traffic Director는 서비스 상태 확인을 오프로드하고 서비스 프록시의 장애 조치 구성을 시작하여 트래픽을 정상 인스턴스로 리디렉션합니다.

또한 Traffic Director는 고급 트래픽 제어 개념, 회로 차단, 결함 주입도 지원합니다. 회로 차단 기능을 사용하면 특정 서비스에 대한 요청에 제한을 적용하여 제한점에 이를 경우 요청이 서비스에 도달하지 못하도록 함으로써 서비스 성능이 더 이상 저하되지 않도록 할 수 있습니다. 결함 주입 기능을 사용하면 Traffic Director가 서비스에 지연을 발생시키거나 일부 요청을 취소함으로써 요청 지연 또는 취소 시의 서비스 내결함성을 쉽게 테스트할 수 있습니다.

Cloud DNS

Cloud DNS는 자동화된 복구 프로세스의 일부로 DNS 항목을 프로그래매틱 방식으로 관리할 수 있는 방법을 제공합니다. Cloud DNS는 Anycast 네임서버의 글로벌 네트워크를 통해 DNS 영역을 전 세계의 중복 위치에서 제공하여 사용자에게 고가용성과 짧은 지연 시간을 제공합니다.

온프레미스에서 DNS 항목을 관리하도록 선택한 경우 Google Cloud의 VM이 Cloud DNS의 DNS 전달을 통해 이러한 주소를 확인하도록 할 수 있습니다.

Cloud Interconnect

Cloud Interconnect는 다른 소스의 정보를 Google Cloud로 이동하는 방법을 제공합니다. 이 제품에 대해서는 나중에 Google Cloud와의 데이터 전송에서 설명합니다.

관리 및 모니터링

Cloud 상태 대시보드
  • Google Cloud 서비스의 상태
Google Cloud의 작업 제품군
  • 업타임 모니터링
  • 알림
  • 로깅
  • 오류 보고
Deployment Manager
  • 반복 가능하고 일관된 배포 프로세스
  • 동시 배포
  • 템플릿
  • 코드형 인프라

Cloud 상태 대시보드

Cloud 상태 대시보드에는 Google Cloud 서비스의 현재 가용성이 표시됩니다. 이 페이지에서 상태를 확인할 수 있으며, 서비스에 대한 뉴스가 있을 때마다 업데이트되는 RSS 피드를 구독할 수도 있습니다.

Cloud Monitoring

Cloud Monitoring은 Google Cloud, AWS, 호스팅된 업타임 프로브, 애플리케이션 계측, 기타 다양한 애플리케이션 구성요소에서 측정항목, 이벤트, 메타데이터를 수집합니다. 관리자에게 적시에 업데이트를 제공하기 위해 Slack 또는 Pagerduty와 같은 타사 도구에 알림을 보내도록 알림 기능을 구성할 수 있습니다. DR에 Cloud Monitoring을 사용하는 또 다른 방법은 Pub/Sub 싱크를 구성하고 Cloud Functions를 사용하여 Cloud Monitoring 알림에 대한 대응으로 자동화된 프로세스를 트리거하는 것입니다.

Deployment Manager

Deployment Manager를 사용하면 일련의 템플릿으로 Google Cloud 환경을 정의할 수 있습니다. 그런 다음 명령어 하나를 반복하여 일관적으로 실행하면 이 템플릿을 사용하여 환경을 만들 수 있습니다. 마찬가지로 단일 명령어로 환경을 해체할 수 있습니다. 따라서 Cloud Deployment Manager는 어떤 리전에서든 안정적으로 작성할 수 있는 DR 복구 환경을 정의하기에 이상적입니다.

크로스 플랫폼 DR 구성 요소

둘 이상의 플랫폼에서 작업 부하를 실행하는 경우 운영 오버헤드를 줄이는 방법은 사용중인 모든 플랫폼에서 작동하는 도구를 선택하는 것입니다. 이 섹션에서는 플랫폼에 구애받지 않으며 플랫폼 간 DR 시나리오를 지원하는 몇 가지 도구 및 서비스에 대해 설명합니다.

선언적 템플릿 도구

선언적 템플릿 도구를 사용하면 플랫폼간에 인프라를 쉽게 배포할 수 있습니다. 앞에서 설명한 것처럼 Google Cloud 전용 배포의 경우 Deployment Manager를 사용할 수 있습니다. 크로스 플랫폼 배포에서 Terraform은 가장 널리 사용되는 선언적 템플릿 도구 중 하나입니다.

구성 관리 도구

대규모이거나 복잡한 DR 인프라의 경우 Chef 및 Ansible과 같은 플랫폼 독립적인 소프트웨어 관리 도구를 사용하는 것이 좋습니다. 이러한 도구를 사용하면 컴퓨팅 워크로드의 위치에 상관없이 재현 가능한 구성을 적용할 수 있습니다. 이러한 유형의 도구를 사용하는 예는 Ansible with Spinnaker 가이드Zero-to-Deploy with Chef on Google Cloud를 참조하세요.

객체 스토리지

일반적인 DR 패턴은 서로 다른 클라우드 공급자의 객체 저장소에 객체 사본을 갖는 것입니다. 이를 위한 크로스 플랫폼 도구 중 하나로, 오픈소스 Python 라이브러리인 boto를 사용하여 Amazon S3 및 Cloud Storage와 상호 작용할 수 있습니다.

조정자 도구

또한 DR 구성 요소로 컨테이너를 고려해 볼 수 있습니다. 컨테이너는 서비스를 패키지화하고 플랫폼 간 일관성을 확보하기 위한 방법입니다.

컨테이너로 작업하는 경우 일반적으로 조정자를 사용합니다. Kubernetes를 사용하면 Google Cloud 내에서 컨테이너를 관리할 수 있을 뿐만 아니라(GKE 사용) 여러 플랫폼에서 컨테이너 기반 워크로드도 조정할 수 있습니다. Google Cloud, AWS, Microsoft Azure는 모두 관리형 버전의 Kubernetes를 제공합니다.

서로 다른 클라우드 플랫폼에서 실행되는 Kubernetes 클러스터에 트래픽을 분산하려는 경우 가중치 기반 레코드를 지원하고 상태 확인을 통합하는 DNS 서비스를 사용할 수 있습니다.

또한 대상 환경으로 이미지를 가져올 수 있어야 합니다. 즉 재난 발생시 이미지 레지스트리에 액세스할 수 있어야 합니다. 플랫폼에 독립적인 좋은 옵션은 Container Registry입니다.

데이터 전송

데이터 전송은 교차 플랫폼 DR 시나리오의 핵심 구성 요소입니다. DR 데이터 전송 시나리오에서 요구하는 사실적인 모델을 사용하여 교차 플랫폼 DR 시나리오를 설계, 구현 및 테스트해야 합니다. 데이터 전송 시나리오에 대해서는 다음 섹션에서 설명합니다.

DR용 패턴

이 섹션에서는 앞에서 설명한 구성 요소를 기반으로 DR 아키텍처의 가장 일반적인 패턴 중 일부를 설명합니다.

Google Cloud와의 데이터 전송

DR 계획에서 고려할 중요한 측면의 하나는 Google Cloud와 데이터를 주고받는 전송 속도입니다. 이는 DR 계획이 온프레미스에서 Google Cloud로, 또는 다른 클라우드 제공업체에서 Google Cloud로의 데이터 이동을 기반으로 하는 경우에 중요합니다. 이 섹션에서는 우수한 처리량을 보장할 수 있는 네트워킹 및 Google Cloud 서비스에 대해 설명합니다.

온프레미스 또는 다른 클라우드 환경에 있는 워크로드의 복구 사이트로 Google Cloud를 사용하는 경우 다음의 주요 사항을 고려하세요.

  • Google Cloud에 어떻게 연결하나요?
  • 사용자와 상호 연결 제공업체 간에 얼마나 많은 대역폭이 있나요?
  • 제공업체가 Google Cloud에 직접 제공하는 대역폭은 무엇인가요?
  • 해당 링크를 사용하여 전송되는 다른 데이터에는 무엇이 있나요?

공용 인터넷 연결을 사용하여 데이터를 전송하는 경우 ISP의 용량 및 라우팅에 제한이 있으므로 네트워크 처리량을 예측할 수 없습니다. ISP는 제한된 SLA를 제공하거나 전혀 제공하지 않을 수 있습니다. 하지만 이런 연결은 상대적으로 비용이 저렴합니다.

Cloud Interconnect는 Google과 Google Cloud에 연결하는 몇 가지 옵션을 제공합니다.

  • Cloud VPN을 사용하면 Google Cloud VPC 네트워크와 대상 네트워크 사이에 IPsec VPN 터널을 만들 수 있습니다. 두 네트워크 사이에서 이동되는 트래픽은 한쪽 VPN 게이트웨이에서 암호화된 후 다른 쪽 VPN 게이트웨이에서 복호화됩니다. HA VPN을 사용하면 SLA가 99.99%인 고가용성 VPN 연결을 만들 수 있으며 중복 VPN을 만들 때보다 설정도 간편합니다.
  • 다이렉트 피어링은 Google의 공개 IP 주소에 대한 네트워크 홉을 최소화합니다. 다이렉트 피어링을 사용하여 네트워크와 Google의 에지 접속 지점(PoP) 간에 인터넷 트래픽을 교환할 수 있습니다.
  • Dedicated Interconnect는 온프레미스 네트워크와 Google 네트워크 간에 물리적인 직접 연결을 제공합니다. 이 서비스는 대규모 데이터 전송에 더 일관된 처리량을 제공하면서 SLA를 보장합니다. 회선은 10Gbps 또는 100Gbps이며 Google의 코로케이션 시설 중 하나에서 종료됩니다. 대역폭이 클수록 온프레미스에서 Google Cloud로 데이터를 전송하는 데 걸리는 시간을 줄일 수 있습니다. 다음 표에서는 10Gbps에서 100Gbps로 업그레이드할 때의 속도 향상을 보여줍니다. 10Gbps와 100Gbps의 데이터 전송 시간을 비교한 차트
  • Partner Interconnect는 Dedicated Interconnect와 유사한 기능을 제공하지만 회선 속도가 10Gbps 미만입니다. 자세한 내용은 지원되는 서비스 제공업체를 참조하세요.

다음 다이어그램은 Google Cloud로 전송해야 하는 데이터의 양에 따라 사용할 전송 방법에 대한 안내를 제공합니다.

Y축에 데이터 양(0TB~100TB 이상)을 표시하고 X축에 데이터 위치 카테고리(예: 'Google Cloud', '연결이 양호한 온프레미스' 등)를 표시한 차트로, 각 카테고리에 서로 다른 전송 솔루션을 포함

DR 계획의 일환으로 수행되는 데이터 전송에 대한 자세한 내용은 대규모 데이터 세트 전송을 참조하세요.

이미지 구성 및 배포 속도의 균형 조정

새 인스턴스를 배치하기 위해 시스템 이미지를 구성할 때 구성이 전개 속도에 미치는 영향을 고려하세요. 이미지 사전 구성의 양, 이미지를 유지관리하는 비용, 배포 속도 사이에 상충하는 관계가 있습니다. 예를 들어 컴퓨터 이미지가 최소한으로 구성되어 있으면 이를 사용하는 인스턴스가 종속 항목을 다운로드하고 설치해야 하므로 시작하는 데 더 많은 시간이 필요합니다. 반면에 컴퓨터 이미지가 높은 수준으로 구성되어 있으면 이를 사용하는 인스턴스가 더 빨리 시작되지만 이미지를 더 자주 업데이트해야 합니다. 완벽하게 작동하는 인스턴스를 시작하는 데 걸리는 시간은 RTO와 직접적인 상관 관계가 있습니다.

이미지 부팅 시간에 매핑된 3개 수준의 번들(번들되지 않음에서 완전히 번들됨까지)을 보여주는 다이어그램(가장 많이 번들된 것이 가장 빨리 부팅됨)

하이브리드 환경에서 머신 이미지 일관성 유지

하이브리드 솔루션(온프레미스-클라우드 또는 클라우드-클라우드)을 구현할 때는 프로덕션 환경 간에 VM 일관성을 유지할 방법을 찾아야 합니다.

완전히 구성된 이미지가 필요한 경우 여러 플랫폼에 동일한 머신 이미지를 만들 수 있는 Packer 같은 솔루션을 고려하세요. 플랫폼별 구성 파일과 동일한 스크립트를 사용할 수 있습니다. Packer의 경우 버전 제어에 구성 파일을 넣어 프로덕션 환경에 배포된 버전을 추적할 수 있습니다. Packer 및 기타 오픈소스 유틸리티로 이미지를 지속적으로 빌드하기 위한 자동화된 파이프라인을 만드는 방법에 대한 설명은 Jenkins, Packer 및 Kubernetes를 통한 자동 이미지 빌드를 참조하세요.

또 다른 옵션으로 Chef, Puppet, Ansible, Saltstack과 같은 구성 관리 도구를 사용하여 세밀하게 세분화된 인스턴스를 구성하고 필요에 따라 기본 이미지, 최소 구성 이미지 또는 완전 구성된 이미지를 만들 수 있습니다. 이러한 도구를 효과적으로 사용하는 방법에 대한 설명은 Ansible with Spinnaker 가이드Zero-to-Deploy with Chef on Google Cloud를 참조하세요.

또한 Amazon AMI, Virtualbox 이미지, RAW 디스크 이미지와 같은 기존 이미지를 수동으로 변환하고 Compute Engine으로 가져올 수도 있습니다.

단계식 저장소 구현

단계식 저장소 패턴은 일반적으로 가장 최근의 백업이 더 빠른 저장소에 있는 백업에 사용되며 이전 백업을 더 저렴한 저속 저장소로 천천히 이전합니다. Cloud Storage를 사용하여 패턴을 구현하는 방법에는 데이터 출처가 Google Cloud인지 온프레미스인지에 따라 두 가지가 있습니다. 두 경우 모두 서로 다른 스토리지 클래스의 버킷 간에 객체를 마이그레이션하며, 일반적으로는 표준 스토리지 클래스에서 보다 저렴한 Nearline Storage 클래스로 마이그레이션합니다.

영구 디스크에서 표준 스토리지로, 다시 Nearline Storage로 데이터를 마이그레이션하는 단계를 보여주는 다이어그램

소스 데이터가 온프레미스에서 생성된 경우 구현은 아래의 다이어그램과 유사합니다.

Cloud Interconnect를 통해 온프레미스에서 Cloud Storage로 데이터를 마이그레이션하는 단계를 보여주는 다이어그램

또는 객체 수명 주기 규칙을 사용하여 버킷 객체의 스토리지 클래스를 변경하는 방법으로 객체 클래스의 변경을 자동화할 수 있습니다.

비공개 인스턴스에 대해 동일한 IP 주소 유지

일반적인 패턴은 VM의 단일 게재 인스턴스를 유지관리하는 것입니다. VM을 교체해야 하는 경우 교체가 원래 VM인 것처럼 나타나야 합니다. 따라서 클라이언트가 새 인스턴스에 연결하는 데 사용하는 IP 주소는 동일하게 유지되어야 합니다.

가장 간단한 구성은 정확히 하나의 인스턴스를 유지관리하는 관리형 인스턴스 그룹을 설정하는 것입니다. 이 관리형 인스턴스 그룹은 원래 이미지인지 대체 이미지인지에 관계없이 인스턴스에 동일한 IP 주소가 사용되도록 하는 내부(비공개) 부하 분산기와 통합됩니다.

기술 파트너

Google은 Google Cloud에서의 백업 및 DR 사용 사례를 지원하는 강력한 파트너 생태계를 갖추고 있습니다. 특히 고객들은 파트너 솔루션을 사용하여 다음을 수행합니다.

  • 온프레미스 데이터를 Google Cloud에 백업합니다. 이러한 경우 Cloud Storage는 대부분의 온프레미스 백업 플랫폼에 대한 스토리지 대상으로 통합됩니다. 이 방법을 사용하여 테이프 및 기타 스토리지 어플라이언스를 대체할 수 있습니다.
  • 온프레미스에서 Google Cloud로 이동하는 DR 계획을 구현합니다. 파트너는 보조 데이터 센터를 제거하고 Google Cloud를 DR 사이트로 사용하는 데 도움을 줄 수 있습니다.
  • 클라우드 기반 워크로드에 대한 DR 및 백업을 구현합니다.

파트너 솔루션에 대한 자세한 내용은 Google Cloud 웹사이트의 파트너 페이지를 참조하세요.

다음 단계