Google PCA: 데이터 스토리지, 데이터베이스 및 분석 아키텍처 — 학습 가이드

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

개요

Google Cloud에서 데이터 스토리지, 데이터베이스, 분석을 설계하려면 내구성, 가용성, 액세스 제어, 비용, 운영 복원력을 계획하면서 워크로드 패턴을 서비스에 맞춰야 합니다. 이 섹션에서는 객체 스토리지 및 수명 주기 거버넌스, 운영 데이터베이스 및 캐시, 분석 웨어하우징 및 처리, 수집 아키텍처, 거버넌스, 보호 및 성능 관련 실무 지침을 다룹니다. 설계 선택 사항, 운영상의 고려 사항, 일반적인 장애 모드 또는 절충점을 설명합니다.

스토리지 및 객체 아키텍처

Cloud Storage 버킷 설계

• 위치: 낮은 지연 시간과 비용 효율성이 중요한 워크로드에는 리전(region)을 선택하고, 예측 가능한 장애 조치를 통한 비즈니스 연속성을 위해서는 이중 리전(dual-region)을, 전역 읽기 액세스를 위해서는 다중 리전(multi-region)을 선택합니다. 이중 리전은 SLA가 보장되는 낮은 RPO를 위해 선택적으로 터보 복제(turbo replication)를 제공하며, 그렇지 않은 경우 복제는 비동기식으로 이루어집니다.
• 네임스페이스 및 분리: 데이터 도메인, 환경, 민감도 수준에 따라 버킷을 분리하여 사용합니다. 일관된 권한 관리를 위해 균일한 버킷 수준 액세스 및 공개 액세스 방지를 적용합니다.
• 스토리지 클래스: 핫 데이터에는 Standard, 자주 액세스하지 않는 데이터(월별)에는 Nearline, 분기별로 액세스하는 데이터에는 Coldline, 장기 보관용 데이터에는 Archive를 사용합니다. Autoclass는 최소한의 운영 작업으로 클래스 배치를 자동으로 최적화할 수 있습니다.
• 수명 주기 정책: 보관 기간, 스토리지 클래스 또는 객체 프리픽스(prefix)에 따라 전환 및 삭제를 자동화합니다. 90일보다 오래된 객체를 삭제하는 예시: { “rule”: [ { “action”: {“type”: “Delete”}, “condition”: {“age”: 90} } ] } 적용 방법: gsutil lifecycle set lifecycle.json gs://my-bucket
• 보관 및 법적 보존 조치: 버킷 보관 정책을 구성하고, 선택적으로 정책을 잠가 기간 단축을 방지할 수 있습니다(규정 준수). 이벤트 기반 보존 및 객체 버전 관리를 사용하면 실수로 인한 삭제나 덮어쓰기로부터 복구할 수 있습니다.
• 복제: 두 리전 간 백그라운드 복제를 통해 API에서 동기식 일관성 시맨틱을 제공하려면 이중 리전을 선택하고, 특화된 RPO/RTO 또는 직무 분리 요건을 충족하기 위해 프로젝트 간 또는 위치 간 복사본이 필요한 경우 버킷 간 복제를 사용합니다.

장애 모드 및 절충점

• 클래스 불일치는 비용과 지연 시간을 증가시킵니다. Autoclass는 이를 줄여주지만 객체별 관리 오버헤드가 추가됩니다.
• 보관 잠금은 되돌릴 수 없으므로 비프로덕션 환경에서 정책을 테스트해야 합니다.
• 복제는 내구성을 향상시키지만 쓰기 지연 시간과 비용을 증가시킬 수 있으므로, 대상 위치에 맞게 읽기/쓰기 경로를 설계해야 합니다.

패턴

• 데이터 레이크: Cloud Storage에 원시(raw) 및 정제(curated) 영역을 구성하고, Dataplex를 통해 거버넌스를 구현하며, Data Catalog에 스키마를 외부화합니다.
• 아카이브: 규정 준수를 위해 보관 잠금이 설정된 Archive 클래스를 사용하고, 드문 분석이 필요할 경우 BigQuery 외부 테이블 또는 온디맨드 복원을 활용합니다.
• 레이크하우스: BigLake를 사용하여 Cloud Storage와 BigQuery 전반의 액세스를 통합하고 일관된 보안을 적용합니다.

운영 데이터 저장소 및 캐싱

Cloud SQL

• 고가용성: 대기 인스턴스로의 동기식 복제를 통한 리전 내 HA. 자동 장애 조치는 일반적으로 수 초에서 2분 내에 완료됩니다. 인스턴스 엔드포인트는 동일하게 유지되어 앱 변경을 최소화합니다.
• 읽기 전용 복제본: 리전 내 또는 리전 간 비동기식 복제. 읽기 확장(read scale-out) 및 DR(재해 복구)에 유용합니다. 복제 지연을 모니터링해야 하며, 오래된 데이터 읽기는 정확성에 영향을 줄 수 있습니다.
• 백업 및 PITR: 예약된 백업 및 트랜잭션 로그를 사용한 특정 시점 복구(Point-in-Time Recovery, 일반적으로 엔진에 따라 최대 7일). 정기적으로 복원을 테스트해야 합니다.
• 비공개 연결: VPC 피어링을 통한 비공개 IP는 노출과 지연 시간을 줄여줍니다. IP 범위가 겹치지 않도록 계획해야 합니다.
• 마이그레이션: Database Migration Service는 온프레미스나 다른 클라우드로부터의 다운타임 최소화 이전을 지원합니다. 대용량 링크의 경우, 패킷 손실과 지연 시간을 줄이기 위해 VPN보다 Dedicated Interconnect 또는 Partner Interconnect를 사용하는 것이 좋습니다.

장단점 및 장애 모드

• HA 장애 조치는 연결을 재설정하므로, 애플리케이션은 백오프(backoff)를 적용하여 재시도해야 합니다. 유지보수 기간 동안 성능이 일시적으로 저하될 수 있습니다.
• 장기 실행 트랜잭션은 복제 지연과 PITR 복구 시간을 증가시킵니다.
• 스토리지를 과도하게 프로비저닝하는 것은 저렴한 보험과 같습니다. IOPS를 부족하게 프로비저닝하면 최대 부하 시 잠재적 장애를 유발합니다.

Cloud Spanner

• 글로벌 확장성 및 일관성: TrueTime과 2단계 커밋(two-phase commit)을 사용하여 여러 리전에 걸쳐 강력한 읽기/쓰기 일관성을 제공합니다. 가장 낮은 쓰기 지연 시간을 위해서는 리전 단위 구성을, 더 높은 가용성과 글로벌 읽기를 위해서는 다중 리전 구성을 선택합니다.
• 트랜잭션: 행과 테이블에 걸쳐 외부 일관성(external consistency)과 완전한 ACID를 보장합니다. 읽기 전용 트랜잭션은 복제본 전반으로 확장됩니다.
• 스키마 설계: 핫스팟(hotspot)을 피하는 기본 키를 선택하고, 지역성(locality)을 위해 인터리브 처리된 테이블(interleaved tables)을 사용하며, 보조 색인의 쓰기 증폭(write amplification) 및 백필(backfill) 동작을 고려해야 합니다.
• 리전성: 리더 리전(leader region)의 위치가 쓰기 지연 시간을 결정합니다. 다중 리전 구성은 쿼럼(quorum) 비용과 커밋 지연 시간을 추가합니다.

장단점

• 쓰기 지연 시간은 지리적 범위가 넓어질수록 증가합니다. 가용성 및 글로벌 배포가 필요한 경우가 아니라면 다중 리전 구성을 피해야 합니다.
• 기본 비용이 단일 노드 VM 데이터베이스보다 높습니다. 용량 계획은 SLO 및 성장세에 맞춰야 합니다.

Firestore, Bigtable, Memorystore 및 선택 기준

• Firestore: 모바일/웹 백엔드를 위한 문서 데이터베이스. 단일 문서에 대한 강력한 일관성, 세분화된 보안, 자동 색인 생성 기능을 제공합니다. 자주 업데이트되는 문서의 경합에 주의하고, 분산 카운터(distributed counters)와 일괄 쓰기(batched writes)를 사용하세요.
• Bigtable: 와이드 컬럼, 페타바이트 규모, 초저지연 시계열 및 IoT 데이터베이스. 핫스팟을 피하도록 행 키(row key)를 설계하고(예: 해싱 또는 솔팅), 노드와 클러스터 단위로 확장하며, 가용성을 위해 다중 클러스터 라우팅을 사용합니다. 복제는 비동기식이며, 강력한 일관성은 클러스터별로 보장됩니다.
• Memorystore for Redis: 인메모리 캐시. 기본(Basic) 등급은 단일 인스턴스(HA 없음)이며, 표준(Standard) 등급은 복제본과 자동 장애 조치를 제공합니다(짧은 연결 끊김 가능). 신뢰할 수 있는 단일 소스(source of truth)가 아닌 캐시로 취급해야 합니다. 영속성 기능은 휘발성을 줄여주지만 데이터베이스 백업을 대체하지는 않습니다.

워크로드 기반 선택

• 조인/ACID를 사용하는 중간 규모의 관계형 워크로드: Cloud SQL.
• 수평 확장 및 외부 일관성이 필요한 글로벌 관계형 워크로드: Cloud Spanner.
• 처리량이 높은 시계열/텔레메트리 또는 초대용량 키-값 워크로드: Bigtable.
• 계층적 쿼리를 사용하는 앱 중심 문서 모델: Firestore.
• 일시적 가속 및 속도 제한: Memorystore.

분석, 수집, 처리

BigQuery

• 데이터 세트: 논리적 보안 및 결제 경계. 도메인 및 수명 주기 단계별로 이름 지정 규칙을 채택하세요.
• 파티셔닝: 시간 필터링을 위한 수집 시간 또는 열 기반 파티셔닝. 정수 범위 파티셔닝도 가능합니다. 스캔 범위를 줄이기 위해 event_ts에 시간 단위 파티셔닝을 사용하세요.
• 클러스터링: 최대 4개의 열을 기준으로 관련 데이터를 스토리지에 함께 배치합니다. 선택적 쿼리의 성능과 비용을 개선합니다.
• 예약: 예약 및 할당을 통해 전용 슬롯을 관리합니다. 일시적으로 급증하는 실험에는 Flex Slot을 사용하고, 기아(starvation) 상태를 피하기 위해 중요한 워크로드를 격리하세요.
• 액세스 제어: 프로젝트 및 데이터 세트 수준의 IAM. 행 수준 정책 및 정책 태그를 사용한 테이블/열 제어. 승인된 뷰 및 루틴을 통해 선별된 데이터를 공유하세요.

유용한 예시: bq mk –dataset myproj:analytics bq mk –table –time_partitioning_field=event_ts –clustering_fields=user_id,device_type myproj:analytics.events ./schema.json

장단점 및 장애 모드

• 잘못된 파티셔닝은 전체 테이블 스캔과 통제 불가능한 비용으로 이어집니다.
• 클러스터링은 필터나 조인에 클러스터링된 열이 포함될 때만 도움이 됩니다. 빈번한 데이터 재정렬은 이점을 감소시킬 수 있습니다.
• 슬롯을 부족하게 프로비저닝하면 작업이 큐에 쌓이고, 과도하게 프로비저닝하면 비용이 증가합니다. 슬롯 사용률과 디스크로 분산된 셔플(spilled shuffle)을 모니터링하세요.

데이터 수집 및 처리

• Pub/Sub: 글로벌, 내구성, 최소 1회 전송(at-least-once delivery) 보장. 순서 지정 키(ordering key)는 처리량과의 트레이드오프를 감수하고 키별 순서를 강제합니다. 멱등성 있는(idempotent) 소비자를 설계해야 합니다.
• Dataflow: 자동 확장, 정확히 1회 상태 저장 처리(exactly-once stateful processing), 윈도우, 트리거를 갖춘 통합된 배치 및 스트리밍. Streaming Engine이 상태를 오프로드합니다

거버넌스, 보호 및 성능

데이터 거버넌스 및 보안

• 메타데이터 및 리니지: 기술 및 비즈니스 메타데이터에 Data Catalog를 사용하고, Dataflow, BigQuery, Dataproc에서 리니지 캡처를 활성화하여 종속성을 추적합니다.
• 품질: Dataplex 데이터 품질로 규칙을 적용하고 Composer 또는 Dataform에서 검사를 오케스트레이션합니다. 불량 레코드는 격리합니다.
• 액세스 경계: BigQuery 및 Cloud Storage 주변에 VPC Service Controls를 사용하여 데이터 무단 반출 위험을 줄입니다. 컨텍스트 인식 액세스를 위해 IAM Conditions를 사용하고, 암호화 제어를 위해 CMEK를, 열 수준 제한을 위해 정책 태그를 사용합니다.
• 보존: Cloud Storage 버킷 보존, BigQuery 테이블 시간 여행(최대 7일까지 구성 가능), 데이터세트/테이블 만료를 법적 요구사항에 맞게 조정합니다.

백업, PITR 및 삭제 방지

• 백업 검증: 주기적으로 Cloud SQL 및 Spanner 백업을 격리된 환경으로 복원하고 체크섬 및 애플리케이션 수준 검증을 실행합니다.
• Bigtable: PITR을 활성화하여 구성된 보존 기간 내의 타임스탬프로 복구합니다. 테이블 또는 클러스터 수준 복원을 테스트합니다.
• Spanner: 재해 복구를 위해 백업을 사용합니다. 감사 쿼리를 위해 버전 보존 기간 내의 오래된 읽기(stale read)를 활용합니다.
• Cloud Storage: 객체 버전 관리 및 버킷 보존 잠금을 활성화하여 우발적인 삭제를 방지합니다. 운영자 오류 격리를 위해 별도의 프로젝트에 복제합니다.
• BigQuery: 시간 여행 및 테이블 스냅샷을 사용합니다. 필수 승인 및 데이터세트 수준 삭제 방지를 통해 프로덕션 데이터세트에 대한 삭제(drop)를 방지합니다.

데이터 성능 및 비용 관리

• 핫 키 방지: Bigtable 행 키(해시 접두사)를 분산시키고, 리더십 선출을 무작위화하는 Spanner 기본 키를 선택하고, Firestore 카운터를 샤딩합니다.
• 인덱스: 필요한 SQL 및 NoSQL 인덱스를 유지 관리합니다. BigQuery에서는 공통 필터를 기준으로 클러스터링하고, Cloud SQL에서는 느린 쿼리를 모니터링하고 Postgres를 정기적으로 vacuum/analyze합니다.
• 용량 계획: 부하 테스트로 기준을 설정하고, SLO 및 오류 예산을 설정합니다. BigQuery 슬롯 사용률, Bigtable CPU/읽기-수정-쓰기 지연 시간, Cloud SQL CPU/IOPS, Pub/Sub 백로그를 모니터링합니다.
• 비용 관리: 안정적인 워크로드에는 BigQuery 슬롯 약정을, Cloud Storage에는 Autoclass를 사용하고, Bigtable 테이블을 압축하고 블룸 필터를 조정하며, 오래된 파티션과 데이터세트를 만료시키고, 팀별 예산 및 알림을 구현합니다.

실용적인 문제 시나리오

Acme Retail Group은 통합된 저지연 클릭스트림 및 주문 분석 플랫폼이 필요합니다. 요구사항: 10초 이내의 실시간 KPI, SQL을 사용한 5년간의 기록 분석, 1시간 미만의 복구 목표, 미국 내 엄격한 데이터 상주, 우발적인 데이터 손실 방지.

1. 원시 이벤트 저장 및 내구성 있는 수집 구현

• 원시 및 큐레이션 영역을 위해 us-central1/us-east1 이중 리전 Cloud Storage 버킷을 생성합니다. 원시 영역에 Autoclass 및 객체 버전 관리를 활성화합니다.
• 근거: 이중 리전은 내구성 및 상주 요구사항을 충족합니다. 버전 관리는 잘못된 백필로부터 보호합니다. Autoclass는 스토리지 비용을 자동으로 최적화합니다.

2. Pub/Sub 및 Dataflow를 사용하여 안정적으로 이벤트 스트리밍

• 클릭스트림 및 주문 이벤트를 user_id별 순서 지정 키(ordering key)를 사용하여 Pub/Sub 주제에 게시합니다. Dataflow 스트리밍 파이프라인을 구현하여 유효성을 검사하고, 중복을 제거하고, 보강하고, 출력을 BigQuery(핫 KPI) 및 Cloud Storage(큐레이션 영역의 parquet)로 분기합니다.
• 근거: Pub/Sub는 전역적이고 내구성 있는 최소 한 번 전송(at-least-once delivery)을 제공합니다. Dataflow는 정확히 한 번 상태(exactly-once state) 및 자동 확장을 제공합니다. 분기는 재처리를 위한 레이크하우스 패턴을 유지합니다.

3. Bigtable 및 Redis에서 실시간 기능 제공

• 보강된 이벤트의 하위 집합을 솔트(salt) 처리된 user_id#timestamp 행 키를 사용하여 Bigtable에 씁니다. 가장 최근 세션을 위한 프런트 캐시로 Memorystore for Redis를 사용합니다.
• 근거: Bigtable은 시계열 데이터에 대해 저지연, 고처리량 쓰기를 제공합니다. 솔트 처리는 핫스팟을 방지합니다. Redis는 실시간 개인화를 위한 테일 레이턴시(tail latency)를 줄입니다.

4. BigQuery에서 웨어하우스 및 쿼리 최적화

• event_date로 파티셔닝되고 user_id, channel로 클러스터링된 데이터세트를 생성합니다. KPI에는 구체화된 뷰(materialized view)를 사용하고, 작은 파일 로드에는 예약된 압축을 사용합니다. 급증에 대비한 작은 플렉스 슬롯 버퍼와 함께 기준 슬롯 예약을 구매합니다.
• 근거: 파티셔닝 및 클러스터링은 스캔을 줄이고 비용을 절감합니다. 구체화된 뷰는 대시보드를 가속화합니다. 예약은 비용을 제한하고 중요한 워크로드가 큐에 들어가는 것을 방지합니다.

5. 액세스 관리 및 무단 반출 방지

• 분석가 그룹에 대해 데이터세트 수준 IAM을 적용합니다. PII 열을 제한하기 위해 정책 태그를 사용하고, 공급업체 액세스를 위해 승인된 뷰(authorized view)를 사용합니다. BigQuery 및 Cloud Storage 주변에 VPC Service Controls를 적용합니다. 규제 대상 데이터세트에는 CMEK를 사용합니다.
• 근거: 데이터세트 및 열 수준에서 최소 권한 원칙을 적용합니다. VPC SC는 데이터 무단 반출 위험을 줄입니다. CMEK는 암호화 제어 요구사항을 충족합니다.

6. 백업, PITR 및 복원 테스트 구현

• Bigtable PITR을 7~14일 동안 활성화합니다. 트랜잭션 주문 저장소를 위해 매주 Spanner 또는 Cloud SQL 백업을 생성합니다. 중요한 BigQuery 테이블을 매일 스냅샷하고, 실수는 시간 여행 기능에 의존합니다. 분기별로 격리된 프로젝트에서 복원 훈련을 실행합니다.
• 근거: 계층화된 복구 옵션은 논리적 오류 및 재해에 대응합니다. 정기적인 훈련은 RPO/RTO 및 런북을 검증합니다.

7. 데이터 보존 및 수명 주기 관리

• 30일 후 원시 객체를, 5년 후 큐레이션된 객체를 제거하는 수명 주기 규칙을 적용합니다. 규정 준수를 충족하는 버킷 수준 보존 정책을 잠급니다. 임시 데이터세트에 대해 BigQuery 데이터세트/테이블 기본 만료를 설정합니다.
• 근거: 자동 적용은 운영 위험을 줄입니다. 보존 잠금은 우발적이거나 승인되지 않은 정책 약화를 방지합니다.

8. 성능 및 비용 모니터링, 핫스팟 완화

• BigQuery 슬롯 사용률, 스캔된 바이트, BI 쿼리 동시성을 추적합니다. Bigtable CPU 및 읽기-수정-쓰기 지연 시간을 모니터링합니다. Pub/Sub 백로그에 대해 알림을 설정합니다. user_id 핫스팟이 발생하면 솔트 너비를 늘리고 Dataflow를 통해 키를 백필합니다.
• 근거: 지속적인 원격 측정은 병목 현상을 조기에 발견합니다. 사전 예방적인 키 전략 변경은 전체적인 재설계 없이 SLO를 유지합니다.

9. 비공개 연결 및 격리 제공

• 하이브리드 종속성의 경우, Cloud Router와 함께 Partner 또는 Dedicated Interconnect를 사용합니다. IP 범위가 겹치지 않도록 합니다. 관리형 서비스 엔드포인트에는 Private Service Connect를 사용합니다.
• 근거: 비공개 경로는 지연 시간과 패킷 손실을 줄입니다. 명확한 IP 계획과 PSC는 격리 및 예측 가능한 라우팅을 보장합니다.

10. 안정성 운영화

• 카나리 Dataflow 파이프라인과 블루/그린 BigQuery 뷰를 활성화합니다. Data Catalog 승인을 통해 스키마 진화를 강제합니다. 데드 레터 큐(dead-letter queue)를 인시던트 대응과 통합합니다.
• 근거: 통제된 롤아웃은 장애 영향 반경을 제한합니다. 관리되는 스키마 변경은 데이터 품질을 유지합니다. DLQ는 인시던트 중 데이터 손실이 없도록 보장합니다.

← 컴퓨팅 · 모든 도메인 · 네트워킹 →

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

Google 찾아보기 →