Google PCA: 안정성, 재해 복구 및 비즈니스 연속성 — 학습 가이드
다음의 일부입니다: Google Professional Cloud Architect — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.
개요
안정성, 재해 복구(DR), 비즈니스 연속성은 구성 요소, 영역 또는 리전 장애에도 불구하고 서비스가 합의된 목표를 계속 충족하도록 보장합니다. Google Cloud에서 안정성은 장애 도메인(영역, 리전, 글로벌)을 이해하고, 복구 목표(RTO/RPO)를 정의하고, 복원력 있는 서비스 아키텍처(예: active-active)를 선택하고, 복구 계획을 엄격하게 테스트함으로써 설계됩니다. 설계 시 서비스 중요도를 명시적인 가용성 목표, 내구성 보장, 검증된 복구 경로에 매핑해야 하며, 가용성, 일관성, 비용, 운영 복잡성 간의 균형을 맞춰야 합니다. 주요 주제에는 단일 장애점(SPOF) 격리, 가능한 경우 관리형 복제 사용, 장애 조치 결정 자동화, 프로덕션과 유사한 환경에서 가정이 유효한지 지속적으로 검증하는 것이 포함됩니다.
장애 도메인, 위치, 다중 리전 서비스
- 가용성 영역 및 리전:
- 영역은 리전 내의 독립적인 장애 도메인입니다. 영역 장애는 설계 시 고려해야 할 가장 일반적인 대규모 이벤트입니다.
- 리전은 지연 시간이 짧은 링크로 연결된 영역의 모음입니다. 리전 장애는 드물지만 중요도가 높은 시스템에서는 반드시 고려해야 합니다.
- 설계 패턴:
- 리전 내(Intra-region): 리전 관리형 인스턴스 그룹(MIG)을 통해 최소 2개 영역에 걸쳐 스테이트리스(stateless) 컴퓨팅을 배치합니다.
- 리전 간(Inter-region): 리전 손실을 허용할 수 없는 중요 서비스의 경우 상태를 복제하고 트래픽을 장애 조치합니다.
- 다중 리전 및 글로벌 서비스:
- 글로벌 컨트롤 플레인: VPC 네트워크, Cloud DNS, 글로벌 외부 HTTP(S) 부하 분산, Cloud IAM은 리전 간 결합도를 줄이는 데 사용되는 글로벌 범위의 서비스입니다.
- 데이터 플레인 배치가 중요합니다:
- Cloud Storage: 액세스 패턴과 DR 요구 사항에 맞춰 리전, 이중 리전 또는 다중 리전 버킷을 선택합니다.
- BigQuery: 데이터 세트는 리전 또는 다중 리전에 위치합니다. 다중 리전은 분석 영역의 가용성을 향상시키지만, 외부 조인을 위한 데이터 상주 위치 및 이그레스(egress)를 고려해야 합니다.
- Spanner: 인스턴스 구성(리전 또는 다중 리전)이 복제본 토폴로지와 일관성 동작을 정의합니다.
- 장애 도메인 분석:
- 모든 구성 요소를 장애 영향 반경(blast radius)에 매핑합니다. 예시:
- 영역(Zonal): 단일 VM, 영역별 GKE 노드 풀, 영역별 SSD PD.
- 리전(Regional): Cloud SQL HA의 주(primary) 인스턴스와 대기(standby) 인스턴스는 리전 단위입니다. 일부 유지보수 이벤트는 리전 전체에 영향을 줄 수 있습니다.
- 글로벌(Global): 잘못 구성된 IAM 또는 Cloud DNS는 모든 리전에 영향을 미칩니다.
- 공유 종속성(예: 단일 NAT 게이트웨이, 단일 Memorystore 인스턴스) 또는 인적 위험(공유 서비스 계정, 단일 Terraform 상태)과 같은 상호 연관된 장애를 식별합니다.
- 할당량(quota)도 장애 도메인으로 간주합니다. 리전 할당량 한도에 도달한 오토스케일러는 기능적으로 다운된 것과 같습니다.
- 모든 구성 요소를 장애 영향 반경(blast radius)에 매핑합니다. 예시:
장단점(Trade-offs):
- 영역 간 복제는 다운타임을 줄이지만 영역 간 트래픽과 비용을 증가시킵니다.
- 리전 간 설계는 RTO를 줄이지만 지연 시간, 복잡성, 비용을 증가시킵니다.
- 글로벌 애니캐스트(anycast) 부하 분산은 장애 조치를 단순화하지만, 상태 확인(health check)이 정확해야만 비정상 백엔드를 가릴 수 있습니다.
목표, 종속성 매핑, DR 검증
- RTO 및 RPO:
- 복구 시간 목표(RTO): 서비스를 복원하는 데 걸리는 목표 시간입니다. 자동화 수준, 대기 상태(standby posture), 런북(runbook)의 상세 수준을 결정합니다.
- 복구 시점 목표(RPO): 허용 가능한 데이터 손실 기간입니다. 복제 및 백업 주기를 결정합니다.
- 서비스 중요도 및 등급화:
- 목표 SLO, RTO/RPO, 테스트 주기를 포함하여 등급(예: Tier 0: 안전/재무 영향, Tier 1: 수익, Tier 2: 내부 도구)을 정의합니다.
- 비용과 복잡성을 등급에 연계합니다. 모든 서비스에 리전 간 구성이 필요한 것은 아닙니다.
- 종속성 매핑:
- 업스트림 및 다운스트림 종속성 목록을 작성합니다: ID(Cloud IAM, SAML IdP), 보안 비밀(Secret Manager, KMS), 네트워킹(DNS, Cloud Interconnect/VPN), 스토리지 및 DB, 관측 가능성(observability), CI/CD, 서드파티 API.
- 각 종속성의 리전, 영역, SLA를 문서화하고, 취약한 연결 고리에 대한 보상 제어(compensating control)를 정의합니다.
- 복구 계획:
- 장애 조치/복구(failover/failback), 데이터 복원, 구성 승격(DNS, 부하 분산기 백엔드, 방화벽)을 위한 런북과 자동화를 생성합니다.
- 권한과 서비스 계정을 미리 프로비저닝하고, 인프라 정의를 준비하여 수동 개입을 제거합니다.
- 감사 가능한 권한 상승을 통해 비상 접근(break-glass access)을 유지합니다.
- 복구 테스트:
- 상태 저장(stateful) 시스템(예: Cloud SQL HA)에 대한 정기적인 장애 조치를 예약하여 승격 및 연결 재협상이 유효한지 검증합니다.
- 영역 또는 리전 중단을 시뮬레이션하는 게임 데이(game day)를 수행합니다. 업스트림 공급자와 IAM/KMS 장애를 포함합니다.
- 결함 주입(fault injection)을 사용하여 서킷 브레이커, 타임아웃, 재시도를 검증하고, 오토스케일링과 백프레셔(backpressure)가 의도대로 작동하는지 확인합니다.
- 테스트 중에 RTO/RPO를 지속적으로 측정하고, 목표를 달성하지 못하면 아키텍처를 조정합니다.
복원력 있는 컴퓨팅, 데이터베이스, 스토리지 패턴
- 리전 MIG 및 부하 분산을 사용한 자가 치유 컴퓨팅:
- 리전 MIG를 사용하여 자동 확장(autoscaling) 및 자동 복구(autohealing) 기능으로 여러 영역(zone)에 인스턴스를 분산합니다.
- 글로벌 외부 HTTP(S) 부하 분산기와 실제 준비 상태에 맞춰진 백엔드 서비스 상태 확인(예: /healthz가 종속성을 확인)을 프런트엔드에 구성합니다.
- 지속적인 VM 재생성을 방지하기 위해 방화벽을 통해 상태 확인을 허용합니다:
gcloud compute firewall-rules create allow-lb-health-checks \
--network=prod-vpc --action=ALLOW --direction=INGRESS \
--rules=tcp:80,tcp:443 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--target-tags=web-backend
```
- 로컬 상태를 피하고, 세션을 Memorystore나 데이터베이스로 외부화합니다. 스케일 인(scale-in) 중 진행 중인 요청을 보존하기 위해 백엔드에서 연결 드레이닝(connection draining)을 사용합니다.
- 일반적인 장애 모드: 잘못된 상태 확인(너무 많거나 적은 항목을 확인), 누락된 방화벽 규칙, 비정상적인 다운스트림에 의존하는 부트스트래핑.
- Cloud SQL 복원력:
- 고가용성(High availability): 별도의 영역에 기본(primary) 및 대기(standby) 인스턴스를 두고 동기식 디스크 복제 및 자동 장애 조치(failover)를 사용합니다. 유지보수 기간을 선택하고 장애 조치를 테스트합니다.
- 읽기 복제본(Read replicas): 동일 리전 또는 교차 리전 읽기 복제본을 추가하여 읽기 부하를 분산하고 리전 이벤트에 대한 RTO를 줄입니다. DR 시 복제본을 승격시킵니다.
- 백업 및 PITR(특정 시점 복구):
- 규정 준수 및 RPO를 위해 충분한 보존 기간을 설정하여 바이너리/트랜잭션 로그를 통해 자동 일일 백업 및 특정 시점 복구(PITR)를 활성화합니다.
- 비프로덕션 환경으로의 복원을 검증하고, 승격 절차 및 애플리케이션 연결 문자열 업데이트를 연습합니다.
- 네트워크: 프로덕션 환경에서는 비공개 IP를 선호합니다. 장애 조치 테스트 시 DNS/연결 풀링 동작을 검증해야 합니다.
- 운영 팁: 주기적으로 제어된 장애 조치를 실행하여 애플리케이션 풀이 깨끗하게 다시 연결되는지 확인합니다.
gcloud sql instances failover prod-sql
```
- Spanner 구성 및 복원력:
- 리전 인스턴스는 여러 영역에 걸쳐 Paxos를 사용하여 리전 내에서 지연 시간이 짧고 강력하게 일관된 읽기/쓰기를 제공합니다.
- 다중 리전 인스턴스는 동기식 쿼럼 쓰기(강력한 글로벌 일관성)와 선택적 읽기 전용 복제본을 사용하여 여러 리전에 걸쳐 복제합니다. 쓰기 작업자와 가까운 리더 리전을 선택합니다.
- 장단점: 다중 리전은 RTO/RPO 및 읽기 가용성을 개선하지만 쓰기 지연 시간과 비용이 증가합니다. 강력한 일관성이 필요한 전 세계적으로 분산된 쓰기 집약적 워크로드에 사용합니다. 그렇지 않은 경우 리전 Spanner 또는 복제본이 있는 Cloud SQL을 고려합니다.
- Cloud Storage 내구성 및 복구 패턴:
- 위치 전략: 컴퓨팅 지역성을 위한 리전(regional), 두 리전에 걸친 액티브-액티브 구성을 위한 이중 리전(dual-region), 글로벌 사용자에게 광범위한 가용성을 제공하기 위한 다중 리전(multi-region).
- 버전 관리: 객체 버전 관리를 활성화하여 삭제 또는 손상으로부터 복구합니다. 수명 주기 규칙과 결합하여 비용을 관리합니다.
- 보존: 버킷 수준 보존 정책을 적용하고, 필요한 경우 규정 준수를 위해 보존 잠금을 적용합니다. 기록 관리를 위해 이벤트 기반 보류를 사용합니다.
- 백업 패턴: 교차 프로젝트, 별도 관리자 버킷은 우발적 삭제 및 권한 상승을 완화합니다. 데이터베이스의 경우, 논리적 백업을 별개의 프로젝트에 있는 Cloud Storage로 내보냅니다.
- 90일보다 오래된 버전을 삭제하는 수명 주기 규칙 예시:
{
"rule": [
{
"action": { "type": "Delete" },
"condition": { "age": 90, "isLive": false }
}
]
}
```
적용 방법:
gsutil lifecycle set lifecycle.json gs://prod-backups
```
- 복구: 중요한 객체의 카탈로그를 유지하고 복원을 테스트합니다. 대규모 데이터 세트의 경우, 이름 충돌을 피하고 무결성을 검증하기 위해 임시 버킷으로 복원을 준비(stage)합니다.
트래픽 관리, 다중 사이트 전략 및 지속적인 복원력
- 다중 사이트 전략:
- 액티브-액티브(Active-active): 여러 리전에서 동시에 트래픽을 처리합니다. 대칭적인 데이터 복제와 충돌 없는 쓰기가 필요합니다. 최고의 RTO/RPO를 제공하지만 비용과 복잡성이 가장 높습니다.
- 액티브-패시브(Active-passive): 핫 프라이머리와 준비된 세컨더리 구성입니다. 데이터는 지속적으로 복제되며, 장애 발생 시 트래픽이 전환됩니다. 비용과 RTO 간의 균형이 좋습니다.
- 웜 스탠바이(Warm standby): 사전 동기화된 데이터를 가진 축소된 규모의 세컨더리입니다. 장애 조치 시 스케일업이 필요하며, 중간 수준의 RTO와 비용이 듭니다.
- 파일럿 라이트(Pilot light): 최소한의 중요 데이터 복제 및 인프라 정의만 유지합니다. 대부분의 구성 요소는 장애 조치 시 프로비저닝됩니다. RTO가 길고 평상시 비용이 낮습니다.
- 콜드 스탠바이(Cold standby): 주기적인 백업만 유지합니다. 장애 발생 시 복원합니다. RTO가 가장 길고 비용이 가장 저렴합니다.
- DNS 및 트래픽 관리 장애 조치:
- 글로벌 외부 HTTP(S) 부하 분산기의 Layer 7에서 상태 기반 라우팅을 사용하는 것을 선호합니다. 이는 백엔드별 상태 확인을 수행하고 DNS 변경 없이 비정상적인 영역이나 리전에서 트래픽을 전환합니다.
- 낮은 TTL의 DNS 레코드는 대략적인 장애 조치 제어나 서로 다른 부하 분산기 VIP 간 전환에만 사용해야 합니다. DNS 캐싱으로 인해 장애 조치가 즉시 이루어지지 않음을 이해해야 합니다.
- 프라이빗 서비스의 경우, 리전별 장애 조치 패턴을 갖춘 내부 HTTP(S) 부하 분산기와 필요한 경우 프로그래밍 방식으로 업데이트할 수 있는 프라이빗 DNS를 사용합니다.
- 정상 성능 저하(Graceful degradation) 패턴:
- 기능 플래그(feature flags)를 구현하여 스트레스 상황에서 중요하지 않은 기능을 비활성화합니다.
- 서킷 브레이커(circuit breakers), 타임아웃(timeouts), 지터(jitter)를 사용한 재시도, 벌크헤드(bulkheads)를 사용하여 장애를 국소화합니다.
- 쓰기 경로가 손상되었을 때 읽기 전용 모드를 제공하고, 나중에 처리할 수 있도록 쓰기 작업을 큐에 넣습니다.
- 클라이언트에 대한 요청 비율을 제한(rate-limit)하고 역압(backpressure)을 적용하여 연쇄적인 장애를 방지합니다.
- 카오스 테스트 및 지속적인 개선:
- 네트워크(지연, 패킷 손실) 및 애플리케이션 계층에서 결함 주입(Fault injection)을 통해 복원력 제어 기능이 설계대로 작동하는지 검증합니다.
- 게임 데이(Game days)를 통해 여러 팀에 걸쳐 복구 절차를 운영화합니다. 여기에는 호출, 런북(runbook) 실행, 구체적인 시정 조치가 포함된 사후 분석(postmortems)이 포함됩니다.
- 오류 예산(error budgets)과 SLO를 추적하고, 데이터에 따라 용량, 재시도 전략, 복제 구성을 조정합니다.
- 가용성, 일관성, 비용, 복잡성 간의 트레이드오프:
- 가용성 vs. 일관성: 강력한 전역 일관성(예: Spanner 다중 리전)은 쓰기 지연 시간을 증가시킬 수 있습니다. 최종적 일관성(eventual consistency)(예: 비동기 복제본)은 지연 시간을 개선할 수 있지만 오래된 데이터를 읽을 위험이 있습니다.
- 비용 vs. RTO/RPO: 이중 리전 스토리지와 다중 리전 데이터베이스는 비용을 증가시키지만 데이터 손실과 다운타임을 최소화합니다.
- 복잡성 vs. 안정성: 모든 장애 조치 메커니즘, 복제 스트림, 라우팅 규칙은 운영 및 테스트되어야 합니다. 목표를 달성하는 데 필요한 만큼 설계를 단순하게 유지해야 합니다.
실제 문제 시나리오
빠르게 성장하는 온라인 티켓팅 회사인 Acme Tickets는 구매 API와 이벤트 카탈로그에 대해 리전 장애 발생 시에도 RTO ≤ 5분, RPO ≤ 1분이라는 엄격한 RTO/RPO를 유지하면서 지속적인 운영을 보장해야 합니다. 스택은 상태 비저장(stateless) 마이크로서비스, 관계형 주문 데이터베이스, 분석 파이프라인, 정적 미디어 자산으로 구성됩니다.
- 서비스 등급, SLO 및 복구 목표 정의
- 근거: 구매 API와 주문 DB를 Tier 0(RTO 5분, RPO 1분), 카탈로그를 Tier 1(RTO 15분, RPO 5분), 분석을 Tier 2(최선 노력)로 분류합니다. 이는 비즈니스 영향에 따라 비용과 복잡성을 조정하는 것입니다.
- 리전 배치 및 다중 사이트 전략 선택
- 근거: 상태 비저장 서비스에 대해 us-central1과 us-east1에 걸쳐 액티브-액티브(active-active)를 배포하여 RTO를 최소화하고, 주문 데이터베이스에는 액티브-패시브(active-passive)를 사용하여 쓰기 지연 시간과 비용의 균형을 맞춥니다.
- 리전 MIG 및 글로벌 HTTP(S) 부하 분산 구현
- 근거: 각각 최소 2개의 영역에 분산된 2개의 리전 MIG(리전당 하나)를 구성합니다. 단일 글로벌 애니캐스트(anycast) VIP는 상태 확인된 백엔드 서비스를 통해 트래픽을 라우팅하여 비정상적인 리전을 자동으로 장애 조치합니다.
- 상태 외부화 및 자가 복구 구성
- 근거: 세션은 카탈로그용 교차 리전 읽기 복제본이 있는 Memorystore에 저장하고, 서비스는 상태 비저장으로 유지하여 MIG 자동 복구 및 롤링 업데이트가 안전하게 이루어지도록 합니다. 상태 확인은 중요한 다운스트림을 검증하는 /healthz를 가리킵니다.
- HA 및 교차 리전 읽기 복제본을 갖춘 Cloud SQL for PostgreSQL 프로비저닝
- 근거: 주 리전에서 HA를 사용하여 영역별 복원력을 확보하고, 충분한 보존 기간으로 PITR을 활성화합니다. 보조 리전에 교차 리전 읽기 복제본을 생성하고, 리전 장애 시 승격시키는 테스트된 런북을 마련하여 최소한의 쓰기 손실로 RPO ≤ 1분을 충족합니다.
- 정기적인 데이터베이스 장애 조치 테스트 예약
- 근거: 월별로 통제된 장애 조치를 실행하여 애플리케이션 재연결 동작과 복제본 승격을 검증합니다. 이는 실제 장애 상황에서 복제본이 전혀 승격되지 않는 일반적인 장애 모드를 해결합니다.
- 버전 관리 및 보존 기능이 있는 이중 리전 Cloud Storage 버킷에 정적 미디어 배치
- 근거: 이중 리전은 두 리전에 걸쳐 객체 가용성을 보장하고, 버전 관리는 우발적인 덮어쓰기/삭제로부터 보호합니다. 수명 주기 규칙을 적용하여 오래된 버전을 만료시키고 비용을 제어합니다.
- 방화벽 및 할당량으로 상태 확인 및 이그레스(egress) 보호
- 근거: 부하 분산기 상태 확인을 위한 명시적인 방화벽 규칙을 생성하고, 리전별 인스턴스 할당량을 모니터링하여 장애 조치 중 오토스케일러 중단을 방지합니다.
- 낮은 TTL을 사용하여 DNS를 대략적인 제어 수단으로 구현
- 근거: 글로벌 부하 분산기가 상태 기반 라우팅을 처리하지만, 비상시 수동 전환을 위해 대기 VIP를 가리키는 낮은 TTL의 A 레코드를 유지하며 DNS 캐시의 한계를 이해합니다.
- DR 런북 자동화 및 게임 데이를 통한 검증
- 근거: Cloud Scheduler를 사용하여 합성 트래픽을 트리거하고, 분기별 게임 데이 동안 주입된 결함(예: 리전 간 트래픽 차단, 노드 종료) 하에서 동작을 확인하기 위해 Cloud Monitoring SLO를 사용합니다. RTO/RPO 메트릭을 수집하고 절차를 개선합니다.
- 백업 보안 및 분리
- 근거: 주문 DB의 일일 논리적 백업을 보존 잠금(retention locks)이 설정된 별도의 프로젝트에 있는 Cloud Storage 버킷으로 내보냅니다. 주기적으로 스테이징 인스턴스에 복원하여 무결성과 소요 시간을 검증합니다.
- 정상 성능 저하(Graceful Degradation) 구현
- 근거: 주문 DB의 성능이 저하되면 카탈로그를 읽기 전용으로 전환하고, 쓰기 작업을 나중에 처리하도록 큐에 넣고, 중요하지 않은 기능을 중단시킵니다. 이는 연쇄적인 장애를 방지하고 부분적인 서비스를 유지합니다.
이 아키텍처는 상태 비저장 서비스를 위한 자동화된 리전 장애 조치, 상태 저장 구성 요소를 위한 통제되고 테스트된 장애 조치, 그리고 Acme Tickets의 비즈니스 연속성 목표를 충족하는 검증된 복구 프로세스를 제공합니다.
이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
시험 합격하기 →