Google ACE: 안정성, 백업 및 재해 복구 — 학습 가이드

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

다음의 일부입니다: Google Associate Cloud Engineer — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Google Cloud에서의 안정성, 백업, 재해 복구는 장애 도메인, 데이터 보호 메커니즘, 트래픽 관리, 운영 준비 상태 전반에 걸쳐 의도적인 설계가 필요합니다. 이 섹션에서는 영역(zone)과 리전(region)에 걸쳐 서비스를 구성하는 방법, 상태 저장 데이터(stateful data)를 보호하고 복원하는 방법, 그리고 체계적인 런북(runbook)과 지속적인 복원력 테스트를 통해 복구 목표를 검증하는 방법을 설명합니다. 또한 플랫폼이 정의된 복구 시간 목표(RTO) 및 복구 시점 목표(RPO) 내에서 복구될 수 있도록 보장하기 위한 DR 전략의 트레이드오프와 용량 계획에 대해 간략히 설명합니다.

장애 도메인 및 리전 설계

• 영역(Zone), 리전(Region), 다중 리전 서비스

  • 영역(Zone)은 가장 작은 독립적인 장애 도메인입니다. 단일 영역 장애가 리전 서비스를 중단시켜서는 안 됩니다.
  • 리전(Region)은 지연 시간이 짧은 링크로 독립적인 영역들을 그룹화합니다. 리전 설계는 영역 장애에서는 살아남지만, 리전 전체 이벤트에서는 반드시 살아남는 것은 아닙니다.
  • 다중 리전 서비스는 여러 리전에 걸쳐 복제하여 더 높은 비용과 잠재적으로 더 높은 쓰기 지연 시간을 감수하고 리전 손실로부터 보호합니다.
  • 설계 원칙: 중요하게 생각하는 가장 작은 장애 도메인에서 단일 장애점(single point of failure)을 피해야 합니다. RTO/RPO가 영역 장애에서 살아남아야 한다면, 최소 두 개 이상의 영역에 배포하십시오. 리전 수준의 생존성이 필요하다면, 여러 리전에 활성 구성 요소를 배포하거나 다중 리전 서비스를 사용하십시오.

• Managed instance groups (MIG) 및 자체 복구(self-healing)

  • 단일 리전 내 여러 영역에 인스턴스를 분산시키려면 리전 MIG를 사용하는 것이 좋습니다. 이를 통해 별도의 도구 없이 영역 장애를 완화할 수 있습니다.
  • 부하 분산기 상태 확인(health check)은 비정상 VM을 트래픽에서 제외합니다. MIG 자동 복구(autohealing)는 비정상적이거나 응답하지 않는 VM을 교체합니다. 두 가지 모두 사용하십시오.
  • 준비 상태 엔드포인트(readiness endpoint)와 종속성을 확인하는 애플리케이션 수준 HTTP(S) 상태 확인을 사용하십시오. TCP 확인은 포트 연결 가능성만 검증합니다.
  • 자동 복구 설정 오류 장애 모드: 부하 분산기 상태 확인만 사용하면 문제가 있는 인스턴스로 트래픽이 가는 것을 막을 수는 있지만, 인스턴스를 다시 생성하지는 않습니다. 인스턴스 교체를 위해 MIG 자체의 상태 확인을 구성하고, 부팅 중 조기 재시작을 피하기 위해 초기 지연(initial delay)을 설정하십시오.

예시:

• 10초 간격과 3개의 비정상 임계값(unhealthy threshold)으로 애플리케이션 상태 확인을 생성하여 약 30초 후에 자체 복구가 트리거되도록 합니다: gcloud compute health-checks create http hc-app
  –check-interval=10s –timeout=5s
  –unhealthy-threshold=3 –healthy-threshold=1 –request-path=/healthz

• 자동 복구를 위해 리전 MIG에 상태 확인을 연결합니다: gcloud compute instance-groups managed update my-rmig
  –region=us-central1 –health-check=hc-app –initial-delay=60

• 다중 리전 고려사항

  • Global external HTTP(S) Load Balancing은 상태 확인에 기반한 자동 장애 조치(failover) 기능으로 여러 리전의 백엔드를 지원합니다.
  • 리전 간 상태 동기화는 핵심적인 트레이드오프입니다. Active-Active 구성은 처리량은 높지만, 일관성과 충돌 해결을 반드시 설계해야 합니다. Active-Passive 구성은 더 간단하지만 장애 조치가 느리고 RPO가 더 커질 수 있습니다.

데이터 보호: 데이터베이스, 스토리지, 컴퓨팅

• Cloud SQL 고가용성 및 복제본
  • 고가용성 구성은 동기식 복제를 사용하여 다른 영역(zone)에 대기 인스턴스를 배치합니다. 기본 인스턴스 장애 시 자동 장애 조치(failover)가 발생합니다. RTO는 일반적으로 몇 분이며, RPO는 리전 내에서 약 0이지만 진행 중인 트랜잭션은 고려해야 합니다.
  • 읽기 복제본은 읽기 작업을 분산하며, DR(재해 복구)을 위해 리전 간 복제본으로 사용할 수 있습니다. 비동기식으로 작동하므로 복제 지연과 0이 아닌 RPO를 예상해야 합니다.
  • 백업 및 PITR(특정 시점 복구)
    • 자동 백업과 특정 시점 복구(point-in-time recovery)를 활성화하세요. MySQL의 경우 바이너리 로깅을 활성화하고, PostgreSQL의 경우 PITR 보존을 활성화하세요.
    • 복원 절차: 데이터 손상이나 사용자 오류 발생 시, 특정 타임스탬프로 새 인스턴스에 복원하고, 애플리케이션이나 복제본이 복원된 인스턴스를 가리키도록 한 후 데이터를 검증합니다.
  • 장애 모드 및 장단점
    • HA는 논리적 데이터 손상으로부터 보호하지 않지만, 백업과 PITR은 보호합니다.
    • 리전 간 복제본은 리전 손실로부터 보호하지만 지연이 발생할 수 있습니다. 허용 가능한 RPO를 테스트해야 합니다.

예시:

• 바이너리 로깅(MySQL) 및 자동 백업 활성화: gcloud sql instances patch my-mysql
  –enable-bin-log
  –backup-start-time=03:00 –retained-backups=7

• Persistent disk(PD) 스냅샷 및 머신 이미지

  • PD 스냅샷은 디스크에 대한 증분식, 비정상 종료 일관성(crash-consistent) 백업입니다. 스토리지 위치를 구성할 수 있으며, 스냅샷의 위치 범위 내 모든 영역(zone)에서 새 디스크를 만드는 데 사용할 수 있습니다.
  • 애플리케이션 일관성 백업을 달성하려면 파일 시스템과 애플리케이션을 정지(quiesce)시키거나, 데이터베이스별 백업 메커니즘과 스냅샷을 조율해야 합니다.
  • 머신 이미지는 디스크와 인스턴스 메타데이터(부팅 디스크, 연결된 디스크, 인스턴스 속성)를 캡처합니다. 머신 이미지를 사용하면 더 빠른 플릿(fleet) 복구나 골든 서버 구성 복제에 유용합니다.
  • 스냅샷 스케줄 정책은 백업을 자동화하고 보존 기간을 적용합니다. 중요한 디스크에는 그에 맞게 태그를 지정하세요.
  • 복원 워크플로: 스냅샷으로 디스크를 생성하여 새 인스턴스에 연결하고, 시작 스크립트와 서비스 계정을 업데이트한 후, 트래픽을 다시 유입시키기 전에 애플리케이션 무결성을 검증합니다.

예시:

• 스냅샷을 생성하고 새 디스크로 복원: gcloud compute disks snapshot vm-boot –snapshot-names=boot-2024-09-01 gcloud compute disks create restored-boot –source-snapshot=boot-2024-09-01 –zone=us-central1-a

• Cloud Storage 복제, 버전 관리, 보관

  • 스토리지 클래스 선택: 자주 액세스하는 데이터는 Standard, 월 단위로 드물게 액세스하는 데이터는 Nearline, 분기 단위로 액세스하는 데이터는 Coldline(백업 및 DR에 권장), 장기간 보관하며 거의 액세스하지 않는 데이터는 Archive를 사용합니다.
  • Regional, Dual-Region, Multi-Region 버킷은 복제를 통해 내구성을 제공합니다. 터보 복제를 사용하는 Dual-Region은 새로 작성된 객체의 복제 RPO를 단축할 수 있으며, Multi-Region은 광범위한 지리적 복원력을 제공합니다.
  • 객체 버전 관리는 이전 버전을 보관하여 의도치 않은 삭제나 덮어쓰기로부터 보호합니다. 보관 정책 및 버킷 잠금(bucket lock)과 결합하여 WORM(Write Once, Read Many) 보존을 강제할 수 있습니다.
  • 실수로 인한 삭제 방지: 객체 버전 관리를 활성화하고, 잠금이 설정된 보관 정책을 사용하며, 법적 또는 처리 게이트를 위해 이벤트 기반 보류를 구현하고, IAM 및 균일한 버킷 수준 액세스를 통해 삭제를 제한합니다. 외부에서 시간제한이 있는 액세스를 위해서는 만료 기간이 엄격한 서명된 URL(signed URL)을 사용합니다.

예시: 90일 후 Coldline으로 이동하고 365일 후 삭제하는 수명 주기

• lifecycle.json { “rule”: [ { “action”: { “type”: “SetStorageClass”, “storageClass”: “COLDLINE” }, “condition”: { “age”: 90 } }, { “action”: { “type”: “Delete” }, “condition”: { “age”: 365 } } ] }
• 적용: gsutil lifecycle set lifecycle.json gs://my-bucket

트래픽, 용량, 종속성 복원력

• DNS 및 트래픽 관리 장애 조치

  • 인터넷 연결 서비스에는 전역 외부 HTTP(S) 부하 분산기(Load Balancing) 사용을 권장합니다. 이는 애니캐스트(anycast) IP를 사용하며 상태 확인 기반의 리전 간 장애 조치를 수행합니다.
  • 내부 서비스의 경우, 내부 HTTP(S) 또는 TCP/UDP 부하 분산기를 사용합니다. 여러 백엔드를 사용하여 영역(zone) 독립성을 갖도록 설계하세요.
  • DNS TTL 장단점: TTL이 낮으면 장애 조치가 더 빨라지지만 쿼리 부하가 증가하고, 일부 리졸버의 캐싱 동작으로 인해 무시될 수 있습니다.
  • 상태 확인 기반의 LB 장애 조치는 DNS만 사용하는 장애 조치보다 더 빠르고 결정적입니다.
  • 가중치 또는 장애 조치 DNS 정책은 리전 대피를 위한 최후의 제어 평면이 될 수 있지만 캐시 만료에 의존합니다.

• 용량 계획 및 할당량 설계

  • 영역 및 리전별 최소 정상 용량을 파악합니다. 장애 조치를 위해 헤드룸 버퍼(“N+1 영역” 용량)를 적용하세요.
  • 중요한 Compute Engine 형태(shape)에 대해서는 리전 예약을 사용하여 스케일 이벤트나 장애 조치 중 용량을 보장합니다.
  • 복구 중 제어 평면 지연을 피하기 위해 IP 주소, 전달 규칙, Cloud NAT 용량, 연결 추적, SSL 인증서를 미리 프로비저닝합니다.
  • 필요하기 훨씬 전에 할당량 증가를 요청하세요. 보조 리전 및 모든 종속성(예: 리전당 Cloud SQL 인스턴스 수, VPC당 전달 규칙 수, Pub/Sub 처리량, Cloud KMS QPS)에 대한 할당량을 확인해야 합니다.
  • 자동 확장(Autoscaling) 고려 사항: 재사용 대기시간을 구성하고, 필요한 경우 예측 자동 확장을 사용하며, 정책에 따라 정확히 하나의 인스턴스를 유지해야 할 경우 최소/최대 경계를 설정합니다.

• 종속성 복원력

  • 업스트림 및 다운스트림 서비스를 목록화합니다. 각각에 대해 장애 동작 및 대체 방안(폴백)을 정의합니다: 캐시된 구성, 기능 저하 모드, 서킷 브레이커, 데드 레터 토픽이 있는 큐, 역압(backpressure).
  • 복구 리전에서 IAM 및 서비스 계정 범위를 확인합니다. 누락된 역할은 DR 이벤트 중 조용한 장애(silent failure)를 일으키는 일반적인 원인입니다.
  • 암호화 키: Cloud KMS 키 복제본 또는 멀티 리전 키가 데이터 위치와 일치하는지 확인합니다. 보조 리전의 키링(key-ring) 위치 및 IAM을 계획하세요.

복원력 운영 및 지속적인 개선

• RTO, RPO, 복구 계획 및 런북

  • RTO는 서비스가 얼마나 빨리 재개되어야 하는지를 정의하고, RPO는 허용 가능한 데이터 손실을 정의합니다. 이는 비즈니스 영향 분석을 통해 도출합니다.
  • 각 시스템 구성요소를 RTO/RPO를 충족하는 특정 메커니즘에 매핑합니다: 영역(zonal) 장애에 대한 HA, 리전(regional) 장애에 대한 리전 간 복제, 데이터 손상에 대한 백업, 내구성을 위한 스토리지 클래스/복제.
  • 런북 유지 관리: 정확한 단계, 명령어, 자격 증명 액세스, 상태 검증 확인, 의사 결정 트리를 포함합니다. 버전 관리되고 접근이 제어되는 리포지토리에 저장하고 정기적으로 연습합니다.
  • 복구 검증: 실제 RTO/RPO를 측정하고, 데이터 무결성을 검증하며, 개선 조치를 수집하기 위해 정기적으로 훈련을 계획합니다. 소규모 복원(테이블, 디스크)과 전체 사이트 복구를 모두 테스트합니다.

• DR 전략 및 장단점

  • Active-active(활성-활성): 모든 리전이 트래픽을 처리합니다. 데이터 동기화가 올바르게 설계된 경우 RTO가 최소화되고 RPO가 낮습니다. 복잡성과 비용이 높으며, 충돌 해결 및 글로벌 로드 밸런싱이 필요합니다.
  • Active-passive(활성-수동): 주 리전이 활성 상태이고, 보조 리전은 웜(warm) 상태로 복제된 데이터를 수신합니다. 비용은 중간 수준이며, RTO는 수 분에서 수십 분, RPO는 복제에 따라 0이 아닐 수 있습니다.
  • Pilot-light(파일럿 라이트): 보조 리전에서 최소한의 핵심 서비스(데이터베이스 복제, 최소한의 앱 설치 공간)만 실행합니다. RTO는 수 시간이며, 비용 효율적입니다. 장애 조치 중 컴퓨팅을 확장하기 위해 신중한 오케스트레이션이 필요합니다.
  • Cold-standby(콜드 스탠바이): 인프라가 코드로 정의되어 있지만 프로비저닝되지는 않습니다. RTO는 수 일이며, 비용이 가장 낮습니다. 드리프트, 할당량, 용량 부족으로 인한 예기치 않은 문제의 위험이 있습니다.

• 카오스 테스트 및 장애 시뮬레이션

  • 인스턴스 충돌, 프로세스 중단, 상태 확인 실패, 디스크 가득 참 상태, 종속성 중단 등을 정기적으로 시뮬레이션합니다. 도구나 스크립트를 사용하여 인스턴스를 종료하거나, 백엔드로의 이그레스(egress)를 차단하거나, 프록시 계층에서 지연 시간을 주입합니다.
  • 의도적으로 상태 엔드포인트를 실패시켜 MIG 자동 복구 및 LB 제거를 검증합니다. 교체 동작 및 복구 타임라인을 확인합니다.
  • 리전 대피(evacuation) 연습: 한 리전의 백엔드를 드레이닝하고, 글로벌 로드 밸런서의 장애 조치를 관찰하며, 보조 리전의 상태 저장 종속성을 확인합니다.
  • 지속적인 개선: 테스트 중 평균 탐지 시간(MTTD), 장애 조치 시간, 데이터 손실에 대한 메트릭을 기록합니다. RTO/RPO를 줄이고 수동 단계를 제거하는 수정 사항의 우선순위를 정합니다.

실용적인 문제 시나리오

Brightlane Retail은 us-central1에서 엄격한 가용성과 주문 데이터에 대한 4시간의 RPO를 요구하는 전자 상거래 플랫폼을 운영하고 있습니다. 경영진은 다운타임 없이 영역(zonal) 장애를 극복하고, 리전(regional) 장애 발생 시 고객 영향을 최소화할 것을 요구합니다.

접근 방식:

1. HTTP 자동 복구 기능이 있는 리전 MIG와 글로벌 HTTP(S) Load Balancer 구현

   • 근거: 리전 MIG는 인스턴스를 여러 영역에 분산시키고, 애플리케이션 수준의 HTTP 상태 확인은 10초 간격의 검사를 3번 실패한 후 자가 복구를 활성화합니다. 글로벌 로드 밸런서는 비정상 VM을 자동으로 제거하고 정상 영역으로 트래픽을 장애 조치합니다.
   • 명령어: gcloud compute health-checks create http app-hc –check-interval=10s –timeout=5s –unhealthy-threshold=3 –request-path=/healthz gcloud compute instance-groups managed update web-rmig –region=us-central1 –health-check=app-hc –initial-delay=60

2. Cloud SQL HA를 리전 간 읽기 복제본 및 PITR과 함께 활성화

   • 근거: 리전 HA는 자동 장애 조치를 통해 영역(zonal) 장애로부터의 생존 가능성을 제공합니다. us-east1의 읽기 복제본은 0이 아니지만 제한된 RPO로 리전 DR을 제공합니다. PITR(MySQL의 경우 바이너리 로깅)을 활성화하면 특정 시점으로 복원할 수 있어 논리적 손상을 해결할 수 있습니다.
   • 명령어: gcloud sql instances patch orders-mysql –enable-bin-log –backup-start-time=03:00 gcloud sql instances create orders-replica –master-instance-name=orders-mysql –region=us-east1

3. Dual-Region Cloud Storage 및 수명 주기 정책으로 객체 자산 보호

   • 근거: 제품 이미지와 정적 자산은 리전 복원력을 위해 이중 리전 버킷에 저장됩니다. 수명 주기 전환은 오래된 아티팩트를 Coldline으로 이동하여 비용을 최적화하고, 버전 관리 및 보존 정책은 중요한 자산의 우발적 삭제를 방지합니다.
   • 단계: 객체 버전 관리를 활성화하고, 중요한 버킷에 30일 보존 정책을 설정하며, 중요하지 않은 빌드 아티팩트에 대해 90일 후 Coldline으로 전환하고 1년 후 삭제하는 수명 주기 규칙을 적용합니다.

4. PD 스냅샷 예약 및 상태 저장 서비스를 위한 머신 이미지 생성

   • 근거: VM 디스크의 증분 스냅샷은 빠른 충돌 일관성 복원 옵션을 제공합니다. 머신 이미지는 부팅 및 구성을 캡처하여 리전 장애 조치 중 앱 서버의 재수화(rehydration)를 가속화합니다. 스냅샷 일정은 일관성 있고 정책 기반의 백업을 보장합니다.
   • 명령어: gcloud compute resource-policies create snapshot-schedule daily-2am –max-retention-days=14 –on-source-disk-delete=apply-retention-policy –start-time=02:00 gcloud compute disks add-resource-policies app-disk-1 –resource-policies=daily-2am gcloud compute machine-images create app-mi-2024-09-01 –source-instance=app-vm-template

5. RTO/RPO 정의 및 DR 런북과 IaC 코드화

   • 근거: 웹/API에 대해 15분의 서비스 수준 RTO와 주문에 대해 4시간의 RPO를 설정합니다. 런북은 트래픽 장애 조치 절차, 읽기 복제본의 Cloud SQL 승격, DNS 비상 계획 및 검증 단계를 명시합니다. IaC(Terraform/Deployment Manager)는 결정론적 재구축을 보장하고 수동 오류를 줄입니다.

6. 보조 리전에 용량 및 할당량 프로비저닝

   • 근거: 중요한 VM 형태에 대한 예약을 생성하고, 대기 로드 밸런서 백엔드, SSL 인증서, NAT 용량을 사전 프로비저닝하며, us-east1의 Compute, SQL, 전달 규칙 및 KMS에 대한 할당량을 확인합니다. 이는 장애 조치 중 용량 고갈을 방지합니다.

7. 카오스 훈련을 통한 복구 검증 및 개선 사항 문서화

   • 근거: 분기별 영역 장애 훈련은 MIG 및 LB 동작을 검증하고, 반기별 리전 대피는 us-east1의 읽기 복제본을 승격시키고 글로벌 LB를 us-east1 백엔드로 지정하며 RTO/RPO를 측정합니다. 발견된 사항은 수동 단계를 줄이거나 복제본 용량을 늘리는 등의 개선을 이끌어냅니다.

이러한 단계를 따르면 Brightlane Retail은 자동화된 자가 복구 기능을 갖춘 영역 고가용성과 정의되고 테스트된 런북을 갖춘 리전 DR 태세를 달성하여, 주문 데이터가 4시간의 RPO를 충족하고 애플리케이션 서비스가 목표 RTO 범위 내에서 복구되도록 보장합니다.

← 보안 · 모든 도메인 · 비용 관리 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Google 찾아보기 →