이 문서는 Google Cloud의 재해 복구(DR)에 대해 설명하는 시리즈 중 2부입니다. 이 부분에서는 Google Cloud 제품과 여러 플랫폼에서 작동하는 제품 모두에서 DR 계획의 구성 요소로 사용할 수 있는 서비스 및 제품을 설명합니다.
시리즈는 다음 세 부분으로 구성됩니다.
- 재해 복구 계획 가이드
- 재해 복구 구성 요소(이 도움말)
- 데이터의 재해 복구 시나리오
- 애플리케이션의 재해 복구 시나리오
- 지역별로 제한된 워크로드의 재해 복구 설계
- 재해 복구 사용 사례: 지역별로 제한된 데이터 분석 애플리케이션
- 클라우드 인프라 서비스 중단의 재해 복구 설계
Google Cloud에는 재해 복구 아키텍처의 일부로 사용할 수 있는 다양한 제품이 있습니다. 이 섹션에서는 Google Cloud DR 구성 요소로 가장 일반적으로 사용되는 제품의 DR 관련 기능에 대해 설명합니다.
이러한 서비스에는 대부분 고가용성(HA) 기능이 있습니다. HA는 DR과 완전히 겹치지는 않지만 HA의 많은 목표는 DR 계획 설계에도 적용됩니다. 예를 들어 HA 기능을 활용하면 가동 시간을 최적화하고 단일 VM 장애와 같은 소규모 장애의 영향을 완화할 수 있는 아키텍처를 설계할 수 있습니다. DR과 HA의 관계에 대한 자세한 내용은 재해 복구 계획 가이드를 참조하세요.
다음 섹션에서는 이러한 Google Cloud DR 구성 요소에 대해 설명하고 이러한 구성 요소가 DR 목표를 구현하는 데 어떻게 도움이 되는지 설명합니다.
컴퓨팅 및 스토리지
다음 표에는 DR의 구성요소 역할을 하는 Google Cloud 컴퓨팅 및 스토리지 서비스의 기능이 요약되어 있습니다.
| 제품 | 특성 |
|---|---|
| Compute Engine |
|
| Cloud Storage |
|
| Google Kubernetes Engine(GKE) |
|
이러한 제품 및 기타 Google Cloud 제품의 기능과 설계가 DR 전략에 미치는 영향에 관한 자세한 내용은 클라우드 인프라 서비스 중단에 대한 재해 복구 설계: 제품 참조를 참고하세요.
Compute Engine
Compute Engine은 가상 머신(VM) 인스턴스를 제공하며 Google Cloud의 주축 역할을 합니다. Compute Engine 인스턴스의 구성, 시작, 모니터링 외에도 일반적으로 DR 계획을 구현하기 위해 다양한 관련 기능을 사용합니다.
DR 시나리오의 경우 삭제 보호 플래그를 설정하여 실수로 인한 VM 삭제를 방지할 수 있습니다. 이는 특히 데이터베이스와 같은 상태 저장 서비스를 호스팅하는 경우에 유용합니다.
낮은 RTO 및 RPO 값을 충족하는 방법에 관한 자세한 내용은 복원력 있는 시스템 설계를 참고하세요.
인스턴스 템플릿
Compute Engine 인스턴스 템플릿을 사용하여 VM의 구성 세부정보를 저장한 다음 기존 인스턴스 템플릿에서 Compute Engine 인스턴스를 만들 수 있습니다. 이 템플릿을 사용하면 필요한 만큼 인스턴스를 실행할 수 있으며 DR 대상 환경을 구축해야 할 때 원하는 방식으로 정확하게 구성할 수 있습니다. 인스턴스 템플릿은 전역적으로 복제되므로 Google Cloud 어디에서나 동일한 구성으로 인스턴스를 다시 만들 수 있습니다.
자세한 내용은 다음 리소스를 참조하세요.
Compute Engine 이미지 사용에 관한 자세한 내용은 이 문서의 뒷부분에 있는 이미지 구성 및 배포 속도 조정 섹션을 참고하세요.
관리형 인스턴스 그룹
관리형 인스턴스 그룹은 Cloud Load Balancing(이 문서의 뒷부분에서 설명)과 함께 작동하여 영역 간에 복사된 동일하게 구성된 인스턴스 그룹으로 트래픽을 분산합니다. 관리형 인스턴스 그룹은 자동 확장 및 자동 복구와 같은 기능을 허용하며 여기에서 관리형 인스턴스 그룹이 인스턴스를 자동으로 삭제하고 다시 만들 수 있습니다.
예약
Compute Engine에서는 추가 GPU 또는 로컬 SSD를 사용하거나 사용하지 않고 커스텀 머신 유형이나 사전 정의된 머신 유형을 사용해 특정 영역에서 VM 인스턴스를 예약할 수 있습니다. DR용 중요 작업의 워크로드 용량을 확보하려면 DR 대상 영역에서 예약을 만들어야 합니다. 예약이 없으면 복구 시간 목표를 달성하는 데 필요한 주문형 용량을 얻지 못할 수 있습니다. 예약은 콜드, 또는 핫 DR 시나리오에서 유용할 수 있습니다. 예약을 만들면 완전히 구성하여 배포할 필요 없이 장애 조치용 복구 리소스를 유지하여 더 낮은 RTO 요구사항을 충족할 수 있습니다.
영구 디스크 및 스냅샷
영구 디스크는 인스턴스에서 액세스할 수 있는 내구성 있는 네트워크 저장소 기기입니다. 인스턴스와 독립된 위치에 존재하므로 인스턴스를 삭제한 후에도 영구 디스크를 분리하고 이동하여 데이터를 보존할 수 있습니다.
재난 발생시 영구 디스크를 다시 만들고 재현할 수 있는 Compute Engine VM의 증분 백업 또는 스냅샷을 지역 간에 복사하여 사용할 수 있습니다. 또한 영구 디스크 스냅샷 만들기로 사용자 오류로 인한 데이터 손실을 방지할 수 있습니다. 스냅샷은 증분적이며, 실행 중인 인스턴스에 연결된 디스크를 스냅샷으로 작성할 경우에도 몇 분이면 생성됩니다.
영구 디스크는 장비 고장 시 데이터를 보호하고, 데이터 센터 유지보수 이벤트를 통해 데이터 가용성을 보장하는 중복 기능을 기본 제공합니다. 영구 디스크는 영역 또는 리전별로 사용됩니다. 리전 영구 디스크는 리전의 두 영역 간에 쓰기를 복제합니다. 영역 장애 시 백업 VM 인스턴스는 보조 영역에 있는 리전 영구 디스크를 강제 연결할 수 있습니다. 자세한 내용은 리전 영구 디스크를 사용하는 고가용성 옵션을 참조하세요.
투명한 유지보수
Google은 최신 소프트웨어로 시스템을 패치하고, 정기적인 테스트 및 예방 유지보수를 수행하고, Google 인프라가 최대한 빠르고 효율적이도록 유지함으로써 인프라를 정기적으로 유지 관리하고 있습니다.
기본적으로 모든 Compute Engine 인스턴스는 이러한 유지보수 이벤트가 애플리케이션 및 워크로드에 영향을 주지 않도록 구성되어 있습니다. 자세한 내용은 투명한 유지보수를 참고하세요.
유지보수 이벤트가 발생하면 Compute Engine은 라이브 마이그레이션을 사용하여 실행 중인 인스턴스를 동일한 영역의 다른 호스트로 자동으로 마이그레이션합니다. 라이브 마이그레이션을 통해 Google은 VM에 영향을 주지 않으면서도 인프라를 보호하고 안정적인 상태로 유지하는 데 필요한 유지보수를 실행할 수 있습니다.
가상 디스크 가져오기 도구
가상 디스크 가져오기 도구를 사용하면 VMDK, VHD, RAW 등의 파일 형식을 가져와서 새 Compute Engine 가상 머신을 만들 수 있습니다. 이 도구를 사용하면 온프레미스 가상 머신과 구성이 동일한 Compute Engine 가상 머신을 만들 수 있습니다. 이는 이미 이미지에 설치된 소프트웨어의 소스 바이너리에서 Compute Engine 이미지를 구성할 수 없는 경우에 좋은 방법입니다.
자동 백업
태그를 사용하여 Compute Engine 인스턴스의 백업을 자동화할 수 있습니다. 예를 들어 백업 및 DR 서비스를 사용하여 백업 계획 템플릿을 만들고 템플릿을 Compute Engine 인스턴스에 자동으로 적용할 수 있습니다.
자세한 내용은 새 Compute Engine 인스턴스 보호 자동화를 참고하세요.
Cloud Storage
Cloud Storage는 백업 파일을 저장하는 데 이상적인 객체 저장소입니다. 다음 다이어그램에 설명된 대로 특정 사용 사례에 적합한 여러 가지 스토리지 클래스가 제공됩니다.
DR 시나리오에서는 Nearline, Coldline, Archive Storage가 특히 유용합니다. 이러한 스토리지 클래스를 사용하면 표준 스토리지에 비해 스토리지 비용을 줄일 수 있습니다. 그러나 이러한 클래스에 저장된 데이터 또는 메타데이터를 검색하는 데는 추가 비용이 들며 최소 저장 기간에도 요금이 부과됩니다. Nearline은 월 1회 액세스가 가능한 백업 시나리오를 위해 설계되었으므로 비용을 낮게 유지하면서 정기적인 DR 스트레스 테스트를 수행하는 데 이상적입니다.
Nearline, Coldline, Archive는 모두 액세스 빈도가 낮은 경우에 최적화되어 있으며 가격 책정 모델은 이를 염두에 두고 설계되었습니다. 따라서 최소 저장 기간에 대해 비용이 청구되며, 해당 등급의 최소 저장 기간보다 일찍 데이터 또는 메타데이터를 검색하면 추가 비용이 발생합니다.
Cloud Storage 버킷의 데이터를 실수로 인한 삭제 또는 악의적 삭제로부터 보호하려면 소프트 삭제 기능을 사용하여 지정된 기간 동안 삭제되거나 덮어쓴 객체를 보존하고 객체 보류 기능을 사용하여 객체의 삭제 또는 업데이트를 방지하면 됩니다.
Storage Transfer Service를 사용하면 Amazon S3, Azure Blob Storage 또는 온프레미스 데이터 소스에서 Cloud Storage로 데이터를 가져올 수 있습니다. DR 시나리오에서 Storage Transfer Service를 사용하여 다음을 수행할 수 있습니다.
- 다른 저장소 제공업체의 데이터를 Cloud Storage 버킷에 백업합니다.
- 이중 리전이나 멀티 리전의 버킷에서 단일 리전의 버킷으로 데이터를 이동하여 백업 저장 비용을 줄입니다.
Filestore
Filestore 인스턴스는 Compute Engine 인스턴스 또는 GKE 클러스터에서 실행되는 애플리케이션이 사용할 완전 관리형 NFS 파일 서버입니다.
Filestore 기본 및 영역 등급은 영역별 리소스이며 영역 간 복제를 지원하지 않는 반면 Filestore 엔터프라이즈 등급 인스턴스는 리전별 리소스입니다. Filestore 환경의 복원력을 높이려면 Enterprise 등급 인스턴스를 사용하는 것이 좋습니다.
Google Kubernetes Engine
GKE는 컨테이너식 애플리케이션을 배포하기 위한 관리형 환경으로 프로덕션에 즉시 사용 가능합니다. GKE에서는 HA 시스템을 조정할 수 있으며 다음과 같은 기능이 포함됩니다.
- 노드 자동 복구. 노드가 장시간(약 10분) 동안 연속으로 상태 확인에 실패하면 GKE는 해당 노드에 대한 복구 프로세스를 시작합니다.
- 활성 및 준비 여부 프로브 포드가 실행 중임을 GKE에 주기적으로 알리는 활성 여부 조사를 지정할 수 있습니다. 포드가 조사에 실패하면 포드를 다시 시작할 수 있습니다.
- 다중 영역 및 지역 클러스터. Kubernetes 리소스를 한 리전 내의 여러 영역에 배포할 수 있습니다.
- 멀티 클러스터 게이트웨이를 사용하면 서로 다른 리전의 여러 GKE 클러스터에서 공유 부하 분산 리소스를 구성할 수 있습니다.
- Backup for GKE를 사용하면 GKE 클러스터에서 워크로드를 백업 및 복원할 수 있습니다.
네트워킹 및 데이터 전송
다음 표에는 DR의 구성요소 역할을 하는 Google Cloud 네트워킹 및 데이터 전송 서비스의 기능이 요약되어 있습니다.
| 제품 | 특성 |
|---|---|
| Cloud Load Balancing |
|
| Cloud Service Mesh |
|
| Cloud DNS |
|
| Cloud Interconnect |
|
Cloud Load Balancing
Cloud Load Balancing은 애플리케이션의 여러 인스턴스에 사용자 트래픽을 분산하여 Google Cloud 컴퓨팅 제품에 HA를 제공합니다. 장애가 발생한 인스턴스로 트래픽이 라우팅되지 않도록 인스턴스의 작업 가능 여부를 판단하는 상태 확인을 사용하여 Cloud Load Balancing을 구성할 수 있습니다.
Cloud Load Balancing은 애플리케이션 앞에 단일 Anycast IP 주소를 제공합니다. 애플리케이션은 다른 지역 (예: 유럽 및 미국)에서 실행중인 인스턴스가 있을 수 있으며 최종 사용자는 가장 가까운 인스턴스 세트로 연결됩니다. 인터넷에 노출된 서비스에 대한 부하 분산을 제공하는 것 외에도 비공개 부하 분산 IP 주소 배후의 서비스를 위해 내부 부하 분산을 구성할 수 있습니다. 이 IP 주소는 Virtual Private Cloud(VPC) 내부의 VM 인스턴스에서만 액세스할 수 있습니다.
자세한 내용은 Cloud Load Balancing 개요를 참고하세요.
Cloud Service Mesh
Cloud Service Mesh는 Google Cloud에서 사용할 수 있는 Google 관리형 서비스 메시입니다. Cloud Service Mesh는 애플리케이션에 관한 자세한 통계를 수집하는 데 도움이 되는 심층적인 원격 분석을 제공합니다. 다양한 컴퓨팅 인프라에서 실행되는 서비스를 지원합니다.
또한 Cloud Service Mesh는 회로 차단 및 결함 주입과 같은 고급 트래픽 관리 및 라우팅 기능을 지원합니다. 회로 차단 기능을 사용하면 특정 서비스에 대한 요청에 제한을 적용할 수 있습니다. 회로 차단 한도에 도달하면 요청이 서비스에 도달하지 못하도록 하여 서비스 성능이 더 이상 저하되지 않도록 합니다. 결함 주입을 사용하면 Cloud Service Mesh가 서비스에 지연을 발생시키거나 일부 요청을 취소할 수 있습니다. 결함 주입을 사용하면 요청 지연 또는 취소 시의 서비스 내결함성을 테스트할 수 있습니다.
자세한 내용은 Cloud Service Mesh 개요를 참고하세요.
Cloud DNS
Cloud DNS는 자동화된 복구 프로세스의 일부로 DNS 항목을 프로그래매틱 방식으로 관리할 수 있는 방법을 제공합니다. Cloud DNS는 Anycast 네임서버의 글로벌 네트워크를 통해 DNS 영역을 전 세계의 중복 위치에서 제공하여 사용자에게 고가용성과 짧은 지연 시간을 제공합니다.
온프레미스에서 DNS 항목을 관리하도록 선택한 경우 Google Cloud의 VM이 Cloud DNS 전달을 통해 이러한 주소를 확인하도록 할 수 있습니다.
Cloud DNS는 DNS 요청에 응답하는 방법을 구성하는 policies을 지원합니다. 예를 들어 고가용성을 제공하기 위해 백업 구성으로의 장애 조치를 사용 설정하거나 지리적 위치를 기반으로 DNS 요청을 라우팅하는 등 특정 기준에 따라 트래픽을 조정하도록 DNS 라우팅 정책을 구성할 수 있습니다.
Cloud Interconnect
Cloud Interconnect는 다른 소스의 정보를 Google Cloud로 이동하는 방법을 제공합니다. 이 제품에 대해서는 나중에 Google Cloud와의 데이터 전송에서 설명합니다.
관리 및 모니터링
다음 표에는 DR의 구성요소 역할을 하는 Google Cloud 관리 및 모니터링 서비스의 기능이 요약되어 있습니다.
| 제품 | 특성 |
|---|---|
| Cloud 상태 대시보드 |
|
| Google Cloud Observability |
|
| Google Cloud Managed Service for Prometheus |
|
Cloud 상태 대시보드
Cloud 상태 대시보드에는 Google Cloud 서비스의 현재 가용성이 표시됩니다. 이 페이지에서 상태를 확인할 수 있으며, 서비스에 대한 뉴스가 있을 때마다 업데이트되는 RSS 피드를 구독할 수도 있습니다.
Cloud Monitoring
Cloud Monitoring은 Google Cloud, AWS, 호스팅된 업타임 프로브, 애플리케이션 계측, 기타 다양한 애플리케이션 구성요소에서 측정항목, 이벤트, 메타데이터를 수집합니다. 관리자에게 적시에 업데이트를 제공하기 위해 Slack 또는 Pagerduty와 같은 타사 도구에 알림을 보내도록 알림 기능을 구성할 수 있습니다.
Cloud Monitoring을 사용하면 공개적으로 제공되는 엔드포인트 및 VPC 내 엔드포인트의 업타임 체크를 만들 수 있습니다. 예를 들어 URL, Compute Engine 인스턴스, Cloud Run 버전, Amazon Elastic Compute Cloud (EC2) 인스턴스와 같은 서드 파티 리소스를 모니터링할 수 있습니다.
Google Cloud Managed Service for Prometheus
Google Cloud Managed Service for Prometheus는 Prometheus 측정항목을 위한 Google 관리 멀티 클라우드 프로젝트 간 솔루션입니다. Prometheus를 사용하고, 대규모 Prometheus 관리 및 운영을 수동으로 수행할 필요 없이 워크로드를 모니터링하고 알림을 설정할 수 있습니다.
자세한 내용은 Google Cloud Managed Service for Prometheus를 참조하세요.
크로스 플랫폼 DR 구성 요소
둘 이상의 플랫폼에서 워크로드를 실행하는 경우 운영 오버헤드를 줄이는 방법은 사용중인 모든 플랫폼에서 작동하는 도구를 선택하는 것입니다. 이 섹션에서는 플랫폼과 독립적이라서 플랫폼 간 DR 시나리오를 지원하는 몇 가지 도구 및 서비스에 대해 설명합니다.
코드형 인프라
그래픽 인터페이스나 스크립트 대신 코드를 사용하여 인프라를 정의하면 선언적 템플릿 도구를 채택하고 플랫폼 전반에서 인프라 프로비저닝 및 구성을 자동화할 수 있습니다. 예를 들어 Terraform 및 Infrastructure Manager를 사용하여 선언적 인프라 구성을 실행할 수 있습니다.
구성 관리 도구
대규모이거나 복잡한 DR 인프라의 경우 Chef 및 Ansible과 같은 플랫폼 독립적인 소프트웨어 관리 도구를 사용하는 것이 좋습니다. 이러한 도구를 사용하면 컴퓨팅 작업 부하가 어디에 있더라도 재현 가능한 구성을 적용할 수 있습니다.
조정자 도구
또한 DR 구성 요소로 컨테이너를 고려해 볼 수 있습니다. 컨테이너는 서비스를 패키지화하고 플랫폼 간 일관성을 도입하는 방법입니다.
컨테이너로 작업하는 경우 일반적으로 조정자를 사용합니다. Kubernetes를 사용하면 Google Cloud 내에서 컨테이너를 관리할 수 있을 뿐만 아니라(GKE 사용) 여러 플랫폼에서 컨테이너 기반 워크로드도 조정할 수 있습니다. Google Cloud, AWS, Microsoft Azure는 모두 관리형 버전의 Kubernetes를 제공합니다.
서로 다른 클라우드 플랫폼에서 실행되는 Kubernetes 클러스터에 트래픽을 분산시키려면 가중치가 있는 레코드를 지원하고 상태 확인을 통합하는 DNS 서비스를 사용할 수 있습니다.
또한 대상 환경으로 이미지를 가져올 수 있어야 합니다. 즉 재난 발생시 이미지 레지스트리에 액세스할 수 있어야 합니다. 플랫폼과 독립적인 좋은 옵션은 Artifact Registry입니다.
데이터 전송
데이터 전송은 교차 플랫폼 DR 시나리오의 핵심 구성 요소입니다. DR 데이터 전송 시나리오에서 요구하는 사실적인 모델을 사용하여 교차 플랫폼 DR 시나리오를 설계, 구현 및 테스트해야 합니다. 데이터 전송 시나리오에 대해서는 다음 섹션에서 설명합니다.
백업 및 DR 서비스
백업 및 DR 서비스는 클라우드 워크로드용 백업 및 DR 솔루션입니다. 이 도구를 사용하면 데이터를 복구하고 중요한 비즈니스 작업을 재개할 수 있으며 여러 Google Cloud 제품과 서드 파티 데이터베이스, 데이터 저장소 시스템을 지원합니다.
자세한 내용은 백업 및 DR 서비스 개요를 참고하세요.
DR용 패턴
이 섹션에서는 앞에서 설명한 구성 요소를 기반으로 DR 아키텍처의 가장 일반적인 패턴 중 일부를 설명합니다.
Google Cloud와의 데이터 전송
DR 계획에서 고려할 중요한 측면의 하나는 Google Cloud와 데이터를 주고받는 전송 속도입니다. 이는 DR 계획이 온프레미스에서 Google Cloud로, 또는 다른 클라우드 제공업체에서 Google Cloud로의 데이터 이동을 기반으로 하는 경우에 중요합니다. 이 섹션에서는 우수한 처리량을 보장할 수 있는 네트워킹 및 Google Cloud 서비스에 대해 설명합니다.
온프레미스 또는 다른 클라우드 환경에 있는 워크로드의 복구 사이트로 Google Cloud를 사용하는 경우 다음의 주요 사항을 고려하세요.
- Google Cloud에 어떻게 연결하나요?
- 사용자와 상호 연결 제공업체 간에 얼마나 많은 대역폭이 있나요?
- 제공업체가 Google Cloud에 직접 제공하는 대역폭은 무엇인가요?
- 해당 링크를 사용하여 전송되는 다른 데이터에는 무엇이 있나요?
Google Cloud로 데이터를 전송하는 방법에 관한 자세한 내용은 Google Cloud로 마이그레이션: 대규모 데이터 세트 전송을 참고하세요.
이미지 구성 및 배포 속도의 균형 조정
새 인스턴스를 배치하기 위해 시스템 이미지를 구성할 때 구성이 전개 속도에 미치는 영향을 고려하세요. 이미지 사전 구성의 양, 이미지를 유지관리하는 비용, 배포 속도 사이에 상충하는 관계가 있습니다. 예를 들어 컴퓨터 이미지가 최소한으로 구성되어 있으면 이를 사용하는 인스턴스가 종속 항목을 다운로드하고 설치해야 하므로 시작하는 데 더 많은 시간이 필요합니다. 반면에 컴퓨터 이미지가 높은 수준으로 구성되어 있으면 이를 사용하는 인스턴스가 더 빨리 시작되지만 이미지를 더 자주 업데이트해야 합니다. 완벽하게 작동하는 인스턴스를 시작하는 데 걸리는 시간은 RTO와 직접적인 상관 관계가 있습니다.
하이브리드 환경에서 머신 이미지 일관성 유지
하이브리드 솔루션 (온프레미스-클라우드 또는 클라우드-클라우드)을 구현할 때는 프로덕션 환경 간에 이미지 일관성을 유지할 방법을 찾아야 합니다.
완전히 구성된 이미지가 필요한 경우 여러 플랫폼에 동일한 컴퓨터 이미지를 만들 수 있는 Packer와 같은 방법을 고려하세요. 플랫폼별 구성 파일과 동일한 스크립트를 사용할 수 있습니다. Packer의 경우 버전 제어에 구성 파일을 넣어 프로덕션 환경에 배포된 버전을 추적할 수 있습니다.
또 다른 옵션으로 Chef, Puppet, Ansible, Saltstack과 같은 구성 관리 도구를 사용하여 세밀하게 세분화된 인스턴스를 구성하고 필요에 따라 기본 이미지, 최소 구성 이미지 또는 완전 구성된 이미지를 만들 수 있습니다.
Compute Engine으로 Amazon AMI, Virtualbox 이미지, RAW 디스크 이미지와 같은 기존 이미지를 수동 변환하고 가져오기할 수도 있습니다.
단계식 스토리지 구현
단계식 저장소 패턴은 일반적으로 가장 최근의 백업이 더 빠른 저장소에 있는 백업에 사용되며 이전 백업을 더 저렴한 저속 저장소로 천천히 이전합니다. 이 패턴을 적용하면 서로 다른 스토리지 클래스의 버킷 간에 백업을 이전할 수 있으며, 일반적으로는 표준 스토리지 클래스에서 Nearline 및 Coldline과 같은 더 저렴한 스토리지 클래스로 이전합니다.
이 패턴을 구현하려면 객체 수명 주기 관리를 사용하면 됩니다. 예를 들어 특정 기간이 지난 객체의 스토리지 클래스를 Coldline으로 자동 변경할 수 있습니다.
다음 단계
- Google Cloud 지역 및 리전에 대해 알아보기
이 DR 시리즈의 다른 도움말 읽어보기
그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 Cloud 아키텍처 센터를 확인하세요.
참여자
저자: