Google ACE: 스토리지, 데이터베이스 및 데이터 서비스 — 학습 가이드

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

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

개요

이 섹션에서는 Google Cloud 스토리지, 데이터베이스, 분석 데이터 서비스에 대한 실용적이고 운영 중심적인 레퍼런스를 제공합니다. 구성 패턴, 액세스 제어, 내구성 메커니즘, 성능 및 비용 특성, 안전한 복구 관행을 중점적으로 다룹니다. 목표는 특정 워크로드에 어떤 서비스를 사용할지 결정하고, 운영상의 트레이드오프를 이해하며, 일반적인 장애 모드를 예측하는 데 도움을 주는 것입니다.

Cloud Storage 설계, 액세스, 수명 주기 및 보호

Cloud Storage는 비정형 데이터와 백업을 위한 내구성 있고 가용성이 높은 객체 스토리지입니다.

• 버킷과 객체: 버킷은 특정 위치(리전 또는 이중/다중 리전)에 있는 전역 네임스페이스로, 변경 불가능한 객체 버전을 포함합니다. 이그레스(egress)를 최소화하고 데이터 상주 요구사항을 충족하도록 버킷 위치를 선택하세요.
• 스토리지 클래스: 액세스 빈도에 따라 Standard(핫), Nearline(최소 약 30일), Coldline(최소 약 90일), Archive(최소 약 365일)를 사용합니다. DR 백업의 경우 Coldline이 일반적인 기본값입니다. 버킷 내에서 객체별로 클래스를 혼합하여 사용할 수 있습니다.
• 수명 주기 규칙: Age, CreatedBefore, MatchesStorageClass, NoncurrentVersion 조건을 사용하여 전환 및 삭제를 자동화합니다. 90일 후에 전환하고 365일 후에 삭제하는 예시:
  1. lifecycle.json: { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
  2. 적용: gsutil lifecycle set lifecycle.json gs://my-bucket
• 보관 및 법적 보존 조치: 보관 정책은 해당 기간이 만료되기 전에 객체가 삭제되거나 수정되는 것을 방지합니다. 정책을 잠그면 되돌릴 수 없습니다. 법적 보존 조치는 객체별로 적용되며, 삭제 전에 해제해야 합니다.

액세스 제어 및 공유:

• 균일(Uniform) 액세스 vs 세분화된(fine-grained) 액세스: IAM만으로 권한을 관리하려면 버킷 수준 균일 액세스(UBLA)를 사용하는 것이 좋습니다. 세분화된 액세스(객체 ACL)는 레거시 방식이며 감사 가능성과 전파를 복잡하게 만듭니다. UBLA를 활성화하면 ACL이 비활성화되며, ACL에 의존하던 기존 통합에 즉시 영향을 줄 수 있습니다.
• 서명된 URL: Google ID 없이 단기 액세스가 필요한 경우 서명된 URL을 사용합니다. IAM으로 서명하여 서비스 계정 키 파일을 사용하지 않도록 하세요: gcloud storage sign-url gs://my-bucket/path/object –duration=4h –impersonate-service-account sa-sharing@proj.iam.gserviceaccount.com 서비스 계정이 자체적으로 또는 서명자 역할을 통해 service account token creator 권한을 가지고 있는지 확인하세요.
• 암호화: 기본적으로 서버 측 암호화가 적용됩니다. 키와 감사 추적에 대한 제어가 필요할 때 버킷 또는 객체 범위에서 CMEK를 활성화하세요. KMS 키 가용성 및 순환을 모니터링해야 합니다. CMEK를 사용할 수 없으면 업로드와 복호화가 차단됩니다.
• 버전 관리: 덮어쓰기/삭제 후 이전 버전(noncurrent version)을 보관하려면 객체 버전 관리를 활성화하세요. 수명 주기 규칙과 결합하여 이전 버전을 만료시키고 스토리지 증가를 제어할 수 있습니다. 많은 버전이 존재할 때 클라이언트 측 목록 조회 로직에 유의해야 합니다.

장애 모드 및 완화:

• 실수로 인한 삭제 또는 덮어쓰기: 버전 관리 및 보관 정책을 사용합니다. 엄격한 규정 준수를 위해 보관 정책을 잠그세요.
• 잘못된 공개 액세스 구성: 공개 액세스 방지(Public Access Prevention) 및 UBLA를 강제 적용합니다. Cloud Asset Inventory 및 정책 분석기(policy analyzer)로 주기적으로 감사합니다.
• 초과 비용: 수명 주기 규칙, 객체 수준 클래스, 요청자 지불(requester pays)은 예상치 못한 비용을 줄여줍니다. Cloud Monitoring 측정항목 및 예산으로 모니터링하세요.

유용한 명령어:

• UBLA 및 보관 정책이 적용된 버킷 생성: gcloud storage buckets create gs://my-bucket –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://my-bucket –retention-period=365d

컴퓨팅 워크로드를 위한 블록 및 파일 스토리지

Compute Engine 및 GKE의 액세스 패턴, 성능 요구사항, 내구성 요건에 따라 스토리지를 선택하세요.

• Persistent Disk (PD): 내구성 있는 블록 스토리지로, 영역(zonal) 또는 리전(regional) 단위입니다. 유형: 순차 처리량에 적합한 Standard(HDD), 낮은 지연 시간과 높은 IOPS를 위한 Balanced(pd-balanced) 및 SSD(pd-ssd). Regional PD는 여러 영역에 걸쳐 동기식으로 복제하여 더 빠른 복구를 가능하게 합니다. PD는 스냅샷을 생성하고, 온라인으로 크기를 조절하며, 여러 VM에 읽기 전용으로 연결할 수 있습니다(읽기-쓰기는 단일 작성자만 가능).
  • 트레이드오프: SSD는 IOPS가 높을수록 비용이 증가합니다. HDD는 비용 효율적이지만 임의 IO에 대한 지연 시간이 깁니다. Regional PD는 비용이 더 들지만 RTO를 줄여줍니다.
• Local SSD: 매우 높은 IOPS와 낮은 지연 시간을 제공하는 NVMe 또는 SCSI 연결 임시 스토리지입니다. 데이터는 VM 중지 또는 호스트 유지보수 시 손실됩니다. 임시 캐시나 복제된 데이터에만 사용하세요. 데이터 손실을 방지하려면 다른 곳에 백업하거나 복제해야 합니다.
• Filestore: POSIX 공유 파일 시맨틱을 위한 관리형 NFS입니다. Basic 등급은 영역 단위이며, Enterprise 및 상위 등급은 동기식 복제와 더 높은 IOPS를 갖춘 리전 단위 HA를 제공합니다. GCVE, HPC 스크래치 공간, 미디어 렌더링 및 공유 파일 잠금이 필요한 애플리케이션에 이상적입니다.
  • 트레이드오프: NFS는 클라이언트 측 캐싱 및 잠금 시맨틱을 도입합니다. 처리량과 지연 시간은 등급별로 다릅니다. Local SSD처럼 한 자릿수 마이크로초 지연 시간의 작은 임의 IO에는 적합하지 않습니다.

장애 고려사항:

• 호스트 유지보수: Local SSD 데이터가 손실됩니다. 애플리케이션 복제로 보호하세요.
• 영역 장애: 영역 단위 PD 및 Basic Filestore가 중단됩니다. HA를 위해 Regional PD 또는 Filestore Enterprise를 사용하세요.
• 스냅샷 일관성: 애플리케이션과 일관된 PD 스냅샷을 만들려면, 파일 시스템 동결(freeze) 또는 데이터베이스 네이티브 정지(quiesce)와 조율하여 충돌 복구 기간을 피해야 합니다.

관리형 데이터베이스 및 데이터 서비스

Cloud SQL (관리형 MySQL, PostgreSQL, SQL Server):

• 구성: 머신 형태, 스토리지 유형, 연결(비공개 IP 선호), 공개 IP 사용 시 승인된 네트워크, 유지보수 기간, 성능 진단을 위한 insights를 선택합니다. 연결 및 CPU 한도를 준수하기 위해 연결 풀링(예: Cloud SQL Auth Proxy, PGbouncer)을 사용합니다.
• 고가용성: 리전 HA 인스턴스는 다른 영역에 동기식 스토리지 복제를 사용하는 대기 인스턴스를 배포하며, 장애 조치는 자동입니다. 장애 조치 중 짧은 쓰기 불가 시간이 발생할 수 있습니다.
• 복제본: 읽기 확장 및 BI 부하 분산을 위한 읽기 복제본, 마이그레이션을 위한 외부 복제. 복제본 지연(replica lag)을 모니터링하고 멱등성(idempotent) 리더를 설계합니다.
• 백업 및 PITR: 특정 시점 복구(point-in-time recovery)를 위해 자동화된 백업과 바이너리/WAL 로깅을 활성화합니다. 정기적으로 복원을 테스트합니다. gcloud sql instances patch my-sql –backup-start-time=03:00 –enable-bin-log
• 장애 모드: 장기 실행 트랜잭션은 vacuum/checkpointing을 차단하고, 연결 급증은 스래싱(thrash)을 유발하며, 할당량이 부족하면 스토리지 자동 증가가 중단될 수 있습니다. CPU, 메모리, 연결, 복제본 지연, 디스크 사용량에 대한 알림을 설정합니다.

Cloud Spanner:

• 확장성 및 리전성: 동기식 복제와 강력한 전역 일관성을 갖춘 리전 또는 다중 리전 인스턴스. 처리량과 스토리지를 위해 노드를 확장하며, 리더 리전(leader region) 배치는 쓰기 지연 시간에 영향을 줍니다.
• 스키마 및 키: 핫스팟을 피하도록 기본 키를 설계하고, 시계열 데이터의 경우 해시 또는 무작위 접두사를 사용한 복합 키를 사용하여 쓰기를 분산합니다. 쿼리 패턴을 위해 보조 인덱스를 사용하고, 자주 필터링되는 열을 함께 저장하는 것을 고려합니다. 잠금 경합을 최소화하기 위해 트랜잭션을 작고 제한적으로 유지합니다.
• 트랜잭션: TrueTime을 통해 외부 일관성을 제공하는 강력한 일관성의 분산 트랜잭션. 쓰기 지연 시간은 쿼럼(quorum)에 의해 제한되며, 충돌이 발생하면 트랜잭션이 중단되므로 백오프(backoff)를 사용하여 재시도합니다.

Firestore 및 Bigtable:

• Firestore (네이티브 모드): 컬렉션, 실시간 리스너, 트랜잭션당 최대 500개 문서에 대한 트랜잭션, 문서 읽기 및 대부분의 쿼리에 대한 강력한 일관성을 제공하는 문서 저장소. 모바일/웹 앱 데이터, 계층적 JSON, 이벤트 기반 앱에 가장 적합합니다.
• Bigtable: 페타바이트 규모와 10ms 미만의 지연 시간을 위한 와이드 컬럼 데이터베이스. 단일 행 트랜잭션만 지원하며, 핫스팟을 피하도록 행 키를 설계합니다. 시계열, IoT, 개인화, 대규모 카운터에 이상적입니다. 임시 조인(ad-hoc joins)이나 복잡한 집계에는 적합하지 않습니다.

Memorystore:

• Redis 및 Memcached: 마이크로초-밀리초 수준의 지연 시간을 위한 인메모리 캐시. 기본(Basic) 등급은 HA가 없으며, 표준(Standard) 등급은 Redis에 대해 자동 장애 조치 기능이 있는 리전 HA를 제공합니다. 임시(ephemeral) 데이터로 취급하고, 기록 시스템(system of record)으로 사용하지 마십시오.

BigQuery:

• 데이터세트 및 테이블: 데이터세트별로 구성하고, 프로젝트, 데이터세트, 테이블, 열, 행 수준에서 액세스를 제어합니다. 파티션 및 클러스터링된 테이블을 사용하여 스캔되는 바이트와 비용을 제어합니다.
• 로드 및 쿼리 작업: Cloud Storage, Cloud SQL 내보내기 또는 스트리밍 삽입을 통해 로드합니다. 예상 비용을 산정하려면 모의 실행(dry run)을 사용합니다: bq query –use_legacy_sql=false –dry_run=true ‘SELECT …’
• 액세스 제어: 읽기 전용 소비자를 위해 데이터세트 범위에서 BigQuery 데이터 뷰어(BigQuery Data Viewer) 역할을 부여하고, 최소 권한 원칙을 위해 승인된 뷰 또는 행/열 수준 보안을 사용합니다.

데이터 이동, 마이그레이션, 검증 및 운영 트레이드오프

마이그레이션 및 전송:

• Database Migration Service (DMS): 복제를 통해 최소한의 다운타임으로 Cloud SQL에 동종 마이그레이션을 수행합니다. 지연 시간 메트릭과 체크섬 비교를 통해 전환을 검증합니다.
• Cloud Storage 전송: 반복적이거나 이벤트 기반 전송에는 Storage Transfer Service를 사용하고, 체크섬을 포함한 일회성 동기화 복사에는 gsutil -m rsync를, 대규모 오프라인 이동에는 Transfer Appliance를 사용합니다.
• 가져오기/내보내기: Cloud SQL은 Cloud Storage로 내보낼 수 있으며, 다시 가져오기는 PITR 부트스트랩 및 데이터 검증을 지원합니다. BigQuery는 Cloud Storage에서 일괄 로드를 지원하며, 다운스트림에서 사용할 수 있도록 Avro/Parquet 형식으로 내보낼 수 있습니다.
• 검증: 객체 체크섬(CRC32C), 행 수, 샘플링 쿼리, 애플리케이션 수준의 불변성(invariant)을 사용합니다. BigQuery의 경우, 소스와 타겟 간의 GROUP BY 개수 또는 해시를 비교합니다.

성능, 가용성, 용량 및 비용 트레이드오프:

• Cloud Storage: 컴퓨팅 리소스를 동일 위치에 배치하여 이그레스(egress)를 최적화하고, 액세스 빈도에 따라 클래스를 선택하며, 더 높은 스토리지 비용으로 영역 간 복원력과 더 높은 가용성을 확보하기 위해 이중/다중 리전을 사용합니다.
• PD/Filestore: 지연 시간이 짧은 IO에는 SSD를, 처리량 중심에는 HDD를 사용하고, HA를 위해 리전 복제를 사용하며, 스로틀링을 피하기 위해 IOPS를 적절한 크기로 조정합니다.
• Cloud SQL: 수직적 확장은 간단하지만 제한적입니다. 읽기 복제본은 읽기 트래픽을 분산시키고, HA는 가용성을 추가하지만 읽기 용량은 늘리지 않습니다. 스토리지 클래스는 지연 시간과 비용에 영향을 줍니다.
• Spanner: 강력한 일관성을 유지하며 수평적으로 확장됩니다. 프리미엄 비용은 글로벌 RPO/RTO와 단순화된 샤딩으로 상쇄됩니다. 쓰기 작업은 키 디자인과 리더 리전의 지연 시간에 민감합니다.
• Firestore/Bigtable/Memorystore: 지연 시간, 데이터 모델, 일관성에 따라 선택합니다. 인메모리 캐시는 데이터베이스 부하를 줄이지만 캐시 무효화의 복잡성을 더합니다.
• BigQuery: 주문형 비용은 스캔된 바이트에 비례합니다. 파티셔닝/클러스터링 및 조건자 푸시다운(predicate pushdown)은 비용을 절감합니다. 고정 요금제 약정은 예측 가능성을 확보하는 대신 약정이 필요합니다.

문제 해결 및 안전한 복구:

• Cloud Storage: 객체 버전 관리 및 보관 정책을 사용하여 복구하고, Cloud Logging 데이터 액세스 로그를 검토하여 읽기/쓰기 이벤트를 감사하며, 복구 중에 CMEK 키가 활성화되어 있는지 확인합니다.
• PD/Filestore: 스냅샷 또는 백업에서 복원하고, fsck 및 데이터베이스 복구 모드를 실행하며, 스냅샷 생성 전에 애플리케이션 수준의 정지(quiesce)를 통해 일관성을 보장합니다.
• Cloud SQL: 기본 인스턴스의 데이터 손실을 방지하기 위해 PITR을 사용하여 새 인스턴스로 복원하고, 읽기 전용 테스트로 확인하며, 안전한 전환 패턴을 위해 방화벽과 비공개 DNS를 유지합니다.
• Spanner/Bigtable: 키 액세스 편중을 통해 핫스팟(hotspotting)을 조사하고, Monitoring을 사용하여 지연 시간 및 스로틀링을 추적하며, 중단된 트랜잭션이나 속도 제한이 걸린 작업에 대해 백오프 및 재시도를 구현합니다.
• BigQuery: 실행 세부 정보를 통해 느린 쿼리를 진단하고, 파티션과 클러스터링을 추가하며, SELECT * 사용을 제한하고, 적절한 경우 중간 결과를 구체화합니다. 시간 여행(time travel) 기간 내에 삭제된 테이블은 스냅샷을 복원하거나 스냅샷 시점에서 복사하여 복구합니다.

실제 문제 시나리오

Contoso Retail은 백업 및 분석 데이터를 통합하는 동시에 액세스 제어를 강화하고 트랜잭션 시스템에 대해 특정 시점 복구(point-in-time recovery)를 활성화하려고 합니다. 요구 사항은 다음과 같습니다: 자동 계층화를 통해 애플리케이션 백업 저장, 제3자에게 단기 파일 공유 제공, 소규모 관계형 워크로드에 PITR 활성화, 실행 전 분석 쿼리 비용 추정.

접근 방식:

1. UBLA, 보관 정책, 수명 주기가 설정된 리전 Cloud Storage 버킷을 생성합니다.

   • 명령어: gcloud storage buckets create gs://contoso-backups –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://contoso-backups –retention-period=365d gsutil lifecycle set lifecycle.json gs://contoso-backups
   • 근거: UBLA는 IAM에서 승인을 중앙 집중화하고 감사 가능성을 향상시킵니다. 1년 보관 정책은 실수로 인한 삭제를 방지합니다. 수명 주기 정책은 90일 후 백업을 Coldline으로 전환하고 만료 시 삭제하여 비용을 제어합니다.

2. 전용 서비스 계정을 통해 백업 작업에 쓰기 전용 액세스 권한을 부여합니다.

   • 명령어: gcloud storage buckets add-iam-policy-binding gs://contoso-backups –member=serviceAccount:backup-writer@contoso.iam.gserviceaccount.com –role=roles/storage.objectCreator
   • 근거: storage.objectCreator 역할은 메타데이터 변조와 민감한 백업의 읽기를 방지하여 최소 권한 원칙을 준수합니다.

3. 키를 배포하지 않고 서명된 URL을 사용하여 4시간 동안 공급업체와 민감한 백업을 공유합니다.

   • 명령어: gcloud storage sign-url gs://contoso-backups/db-dump-2024-09-30.sql.gz –duration=4h –impersonate-service-account share-signer@contoso.iam.gserviceaccount.com
   • 근거: 시간 제한이 있고 ID가 없는 액세스는 외부 ID나 수명이 긴 보안 비밀을 생성할 필요가 없습니다. 가장(Impersonation)은 중앙 집중식 KMS 기반 서명을 사용하며 키 유출 위험을 제거합니다.

4. 주문 데이터베이스에 대해 Cloud SQL 백업 및 PITR을 활성화합니다.

   • 명령어: gcloud sql instances patch orders-sql –backup-start-time=02:00 –enable-bin-log
   • 근거: 자동화된 백업과 바이너리/WAL 로깅은 보관 기간 내의 어느 시점으로든 복원 지점을 제공하여 논리적 손상 및 운영자 실수로부터 보호합니다.

5. 새 인스턴스로 복원하여 복구를 테스트하고 전환 전에 데이터를 검증합니다.

   • 명령어: gcloud sql backups list –instance=orders-sql gcloud sql instances restore-backup orders-restore –backup-id=LATEST –destination-instance=orders-restore
   • 근거: 별도의 인스턴스로 복원하면 프로덕션에 영향을 주지 않으며, DNS나 애플리케이션 수준의 전환 전에 체크섬 및 샘플 쿼리를 통해 검증할 수 있습니다.

6. 시험 실행(dry run)으로 BigQuery 쿼리 비용을 추정하고 파티셔닝으로 최적화합니다.

   • 명령어: bq query –use_legacy_sql=false –dry_run=true ‘SELECT COUNT(*) FROM contoso.analytics.sales WHERE sale_date >= “2026-01-01”’
   • 근거: 시험 실행은 스캔할 바이트를 보여줍니다. sale_date가 파티션 열이고 범위가 지정된 조건자를 사용하도록 하면 스캔되는 바이트가 줄어들어 주문형 비용을 제어할 수 있습니다.

7. 액세스 모니터링 및 감사.

   • 단계:
     • Cloud Storage 및 BigQuery에 대한 데이터 액세스 로그를 활성화합니다.
     • Cloud SQL 연결, 디스크 사용량, 백업 실패에 대해 Cloud Monitoring 알림을 구성합니다.
   • 근거: 데이터 액세스 로그는 규정 준수를 위해 객체 수준의 읽기/쓰기 가시성을 제공합니다. 사전 예방적 알림은 MTTR을 단축하고 백업 및 PITR이 효과적으로 유지되도록 보장합니다.

8. 장애 모드 및 런북(runbook)을 문서화합니다.

   • 단계:
     • 객체 버전 복원, 서명된 URL 해지, Cloud SQL PITR, 시간 여행을 사용한 BigQuery 테이블 복구 절차를 기록합니다.
   • 근거: 명확하고 테스트된 런북은 사고 발생 시 운영 위험을 줄이고 팀 전체에 걸쳐 안전한 복구 관행을 표준화합니다.

← VPC 네트워킹 · 모든 도메인 · 배포 →

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

Google 찾아보기 →