실전 문제

문제 1

Your media-streaming platform uses Memorystore for Redis (Standard Tier, Redis 6.x) as a cache for user session tokens and frequently requested metadata; during live event traffic spikes, p95 cache latency jumps from 6 ms to 180–250 ms, and Cloud Monitoring shows memory utilization at 95–98% with Redis INFO reporting ~25,000 evicted_keys/min and an eviction policy of allkeys-lru; average key size is ~1.5 KB, average TTL is 5 minutes, CPU stays under 40%, and network RTT between your GKE cluster and the Redis instance is ~1 ms in the same region; you need to reduce the frequency and impact of these latency spikes. What should you do?

문제 분석

핵심 개념: 이 문제는 Memorystore for Redis (Standard Tier)에서 부하 시 Redis cache latency를 진단하고 올바른 scaling 레버를 선택하는지를 테스트합니다. 핵심 신호는 memory pressure(95–98%), 높은 eviction rate(~25,000 evicted_keys/min), allkeys-lru policy, 그리고 낮은 CPU/network latency입니다. 정답이 맞는 이유: p95 latency spike는 극단적인 memory utilization과 과도한 eviction과 상관관계가 있습니다. allkeys-lru에서는 Redis가 지속적으로 key를 샘플링하고, LRU metadata를 업데이트하며, 새로운 write를 수용하기 위해 item을 evict해야 합니다. bursty traffic에서는 이것이 churn을 만듭니다: hot key가 evict되어 cache miss가 발생하고, backend fetch가 늘어나며, 추가적인 cache repopulation write가 발생해 latency를 증폭시킵니다. CPU가 <40%이고 RTT가 ~1 ms이므로 bottleneck은 compute나 network가 아니라 working set과 write rate 대비 memory capacity입니다. 더 큰 memory tier로 resizing하면 사용 가능한 RAM이 증가하고 eviction 빈도가 줄어들며 hit rate가 안정화되고 eviction-driven tail latency가 제거됩니다. 주요 기능 / best practices: Memorystore capacity는 instance당 고정되어 있으며, memory가 거의 가득 차면 Redis eviction 동작이 성능을 지배합니다. best practice는 일반적인 utilization이 한계보다 충분히 낮게 유지되도록 Redis를 sizing하는 것입니다(워크로드에 따라 보통 ~60–80%를 목표로 하여 spike, fragmentation, overhead를 흡수). 또한 average key size(1.5 KB)에 Redis object overhead와 TTL bookkeeping이 더해지므로 key당 실제 memory 사용량은 payload size보다 큽니다. Standard Tier는 replication/failover로 HA를 제공하지만, 자동으로 memory를 추가하지는 않습니다. scale up(또는 필요 시 application layer에서 shard)해야 합니다. 흔한 오해: network를 원인으로 의심하기 쉽지만(RTT는 이미 ~1 ms), replica를 추가하는 것도 유혹적이지만(replica는 write-side memory capacity를 늘리지 못하고 primary의 eviction을 멈추지 못함) 둘 다 핵심 원인을 해결하지 못합니다. TTL을 늘리면 hit rate가 좋아질 것 같지만, memory가 이미 포화된 상태에서는 residency time이 늘어나 eviction과 churn을 악화시킵니다. 시험 팁: 높은 memory utilization과 낮은 CPU와 함께 evicted_keys가 높게 보이면 “cache capacity 부족/working set이 너무 큼”을 떠올리고 memory scale-up(또는 redesign/shard)을 선택하세요. replica는 read scaling에 도움이 되지, memory pressure에는 도움이 되지 않습니다. TTL 변경은 memory headroom을 기준으로 평가해야 하며, pressure 상황에서 TTL을 늘리면 보통 악영향을 줍니다.

문제 2

Your healthcare analytics company is migrating a self-managed PostgreSQL 12 database from an on-premises datacenter to Cloud SQL for PostgreSQL; after cutover, the system must tolerate a single-zone outage in the target region with no more than 3 minutes of disruption (RTO ≤ 3 minutes) and zero transaction loss (RPO = 0), and you want to follow Google-recommended practices for the migration—what should you do?

문제 분석

핵심 개념: 이 문제는 zonal resilience를 위한 Cloud SQL for PostgreSQL 고가용성 설계를 테스트하며, 특히 엄격한 복구 목표인 RTO ≤ 3분 및 RPO = 0을 충족해야 합니다. Google Cloud에서 한 region 내 단일 zone 장애를 허용하기 위한 권장 패턴은 Cloud SQL High Availability (HA)이며, regional instance라고도 합니다. 정답이 맞는 이유: Cloud SQL for PostgreSQL HA (regional) instance는 동일한 region의 한 zone에 primary를, 다른 zone에 standby를 synchronous replication으로 프로비저닝합니다. replication이 synchronous이므로, 커밋된 트랜잭션은 acknowledgement 전에 두 zone 모두에 내구적으로 기록되며, 이것이 RPO = 0의 핵심 요구사항입니다. zonal failure 동안 Cloud SQL은 standby로 automatic failover를 수행하며, 일반적으로 수 분 내에 이루어져 수동 방식보다 RTO 3분 요구사항에 훨씬 더 잘 부합합니다. 이는 Cloud SQL의 zonal fault tolerance에 대한 Google 권장 모범 사례입니다. 주요 기능 / 구성: - instance 생성 시 “High availability (regional)”을 선택합니다. - standby는 동일한 region 내 다른 zone에 위치하며, 이는 요구사항(대상 region에서 단일 zone 장애)에 부합합니다. - Synchronous replication은 커밋된 트랜잭션에 대해 zero data loss를 가능하게 합니다. - Automatic failover는 운영 부담을 줄이고 RTO 예측 가능성을 개선합니다. - logical corruption/user error에 대한 보호를 위해 backups 및 (선택적으로) PITR을 함께 사용합니다(HA만으로는 이를 해결하지 못함). 흔한 오해: 많은 사람들이 read replicas(asynchronous)를 HA와 혼동합니다. read replicas는 주로 read 확장과 DR 패턴을 위한 것이며, promotion은 수동/운영적으로 복잡합니다. asynchronous replication은 RPO = 0을 보장할 수 없습니다. backups는 필수이지만 HA 메커니즘이 아니며 3분 RTO를 충족할 수 없습니다. 커스텀 CDC/logical replication 파이프라인은 복잡성을 추가하고, 빠르고 자동화된 failover와 함께 synchronous, zero-loss 동작을 보장하기도 일반적으로 어렵습니다. 시험 팁: 요구사항을 Cloud SQL 기능에 매핑하세요: - RPO = 0 + in-region에서 zonal outage 허용 => synchronous standby를 사용하는 Cloud SQL HA (regional). - Cross-region replicas는 regional disaster를 위한 것이며 보통 RPO가 0이 아닙니다. - Backups/PITR은 availability가 아니라 data recovery를 다룹니다. 명시적으로 요구되지 않는 한, 맞춤형 replication보다 managed HA와 automated failover로 reliability를 설계하라는 Google Cloud Architecture Framework 원칙을 사용하세요.

문제 3

Your edtech platform uses Cloud Firestore for storage and serves a React web app to a global audience. Each day at 00:00 UTC, you publish the same Top 20 practice tips (20 documents, ~5 KB each; total payload ~100 KB) to approximately 5 million daily active users across North America, Europe, and APAC. You need to cut Firestore read costs and achieve sub-150 ms p95 load times for this daily list while the content remains identical for 24 hours. What should you do?

문제 분석

핵심 개념: 이 문제는 전 세계에 분산된, 읽기 비중이 높고 하루 동안 동일한 콘텐츠에 대해 Cloud Firestore 읽기 비용과 지연 시간을 줄이는 방법을 평가합니다. 핵심 패턴은 사용자별 데이터베이스 읽기를 피하기 위해 (24시간 동안) 변경되지 않는 콘텐츠를 엣지에서 사전 계산하고 캐싱하는 것입니다. 정답이 맞는 이유: Firestore bundle을 사용하면 알려진 문서 집합(Top 20 tips)을 정적 아티팩트로 내보내 클라이언트가 Firestore 문서 읽기를 발생시키지 않고 로드할 수 있습니다. Firebase Hosting을 Cloud CDN 앞단에 두고 해당 bundle을 제공하면 트래픽이 Firestore에서 CDN 엣지 캐시로 이동합니다. 24시간 TTL을 적용하면 하루 500만 사용자 대부분이 가까운 엣지 로케이션에서 제공받아 전 세계 p95 150ms 미만을 달성하는 동시에 Firestore read 작업(따라서 비용)을 크게 줄일 수 있습니다. Firestore는 여전히 system of record이지만, 일일 목록은 캐시 가능한 정적 자산이 됩니다. 주요 기능 / 모범 사례: - Firestore Bundles: 문서/쿼리를 파일로 패키징하여 클라이언트 SDK가 로드할 수 있게 하고, 로컬 캐시를 채워 해당 문서에 대한 네트워크 read를 피합니다. - Firebase Hosting + Cloud CDN: 전 세계 엣지 캐싱, HTTP 캐싱 헤더, 소형 페이로드(~100 KB)에 대한 저지연 전송. - Cache control: 24시간 콘텐츠 윈도우에 맞춰 Cache-Control max-age=86400(그리고 선택적으로 immutable)을 설정하고, 캐시를 깔끔하게 갱신하기 위해 00:00 UTC에 새 bundle을 게시(종종 버전이 포함된 파일명 사용)합니다. - Architecture Framework 정렬: 반복적인 read를 엣지 캐싱으로 오프로딩하여 성능 효율성과 비용 최적화를 개선합니다. 흔한 오해: - 더 강한 일관성(serializable isolation)은 read나 지연 시간을 줄이지 않으며, 오버헤드를 증가시킬 수 있습니다. - Firestore를 다른 multi-region으로 옮기면 일부 사용자에게는 도움이 될 수 있지만, 근본적인 비용 요인(동일 데이터에 대한 수백만 번의 반복 read)을 제거하지는 못합니다. - Indexing은 쿼리 성능에 도움이 되지만, 문서 read 과금이나 전 세계 엣지 지연 시간을 줄이지는 못합니다. 시험 팁: 콘텐츠가 많은 사용자에게 동일하고 예측 가능한 일정으로 변경된다면, 데이터베이스 read보다 CDN/엣지 캐싱 또는 정적 전달을 우선 고려하세요. Firestore의 경우 특히 bundle이 사전 로딩과 read 비용 절감을 위해 설계되었고, Hosting+CDN이 웹 자산의 표준 전 세계 배포 메커니즘이라는 점을 기억하세요.

문제 4

(2개 선택)

Your travel-tech company operates a globally distributed seat allocation platform on Cloud Spanner with 3 read-write and 6 read-only regions; after importing 12 million seat and route records from a partner, you observe write latency spikes and CPU hotspots on 2 of 8 leader replicas, and Cloud Monitoring shows hot ranges on a table keyed by a monotonically increasing ticket_id and a composite key (route_id, class) where class has only 3 distinct values; at peak 35,000 writes/second, 70% of writes concentrate in a narrow key range; to follow Google-recommended schema design practices and avoid hotspots without sacrificing strong consistency or availability, what should you do? (Choose two.)

문제 분석

핵심 개념: 이 문제는 핫스팟을 방지하기 위한 Cloud Spanner 스키마 설계를 평가합니다. Spanner에서는 데이터가 정렬된 키 순서로 저장되고 “ranges”(tablets)로 분할됩니다. 쓰기는 대상 키 값이 포함된 range(들)에 집중됩니다. 많은 쓰기가 좁고 인접한 키 공간에 몰리면, 멀티 리전 구성에서도 소수의 split과 그 leader가 CPU/latency 병목이 될 수 있습니다. 정답이 맞는 이유: 두 가지 핫스팟 패턴이 설명됩니다: (1) 단조 증가하는 ticket_id primary key로 인해 모든 신규 insert가 키스페이스의 “끝”(최신 range)을 타겟팅하는 경우, (2) composite key (route_id, class)에서 class가 3개 값만 가지는 경우입니다. class가 앞쪽에 배치되거나(또는 locality를 좌우하도록) 하면, 3개의 큰 연속 파티션만 만들어져 쓰기가 집중됩니다. Google 권장 사항은 primary key의 선두 부분이 높은 cardinality와 좋은 분산을 갖도록 하는 것입니다. 따라서 다중 속성 primary key에서는 high-cardinality 속성을 앞쪽으로 올려야 합니다(D). 순차 ID를 논리적으로 정렬된 형태로 유지해야 한다면, bit-reversed sequential values(E) 같은 key transformation을 사용해 키스페이스 전반으로 insert를 분산시키면서도 uniqueness를 유지하고 효율적인 생성이 가능하게 합니다. 주요 기능 / 모범 사례: Spanner는 ranges를 자동으로 split하지만, sequential keys로 인해 발생하는 “단일 hot end”를 제거할 수는 없습니다. hot range를 계속 split할 수는 있어도, 쓰기 부하를 처리하는 단일 leader가 존재하므로 병목이 남습니다. Bit-reversal(또는 유사한 hashing/salting 패턴)은 쓰기를 여러 range와 leader로 분산합니다. Composite keys에서는 순서가 중요합니다. 가장 많은 distinct values(그리고 가장 좋은 write distribution)를 가진 속성을 먼저 두고, low-cardinality 필드는 뒤에 둡니다. 흔한 오해: Normalization(B)은 update anomalies나 저장 효율을 개선할 수 있지만, 본질적으로 key-range write concentration을 해결하지는 않습니다. Low-cardinality 속성을 승격(C)하면 보통 소수의 연속 range로 쓰기가 더 군집되어 핫스팟이 악화됩니다. Auto-incrementing keys(A)는 높은 write throughput에서 Spanner의 대표적인 안티패턴입니다. 시험 팁: “hot ranges”, “monotonically increasing”, “low cardinality”, “writes concentrated in a narrow key range”를 보면 primary key 설계와 key ordering을 떠올리세요. Spanner에서는 첫 번째 key parts가 locality를 지배합니다. high-cardinality 선두 키를 선택하고, 순차 식별자에는 bit-reversed sequences 같은 기법을 사용해 핫스팟 없이 strong consistency와 availability를 유지하면서 write scalability를 확보하세요.

문제 5

You are building a Pub/Sub–triggered service on Cloud Functions (2nd gen) in us-central1 that must connect to a Cloud SQL for PostgreSQL instance. Your security policy requires the database to accept connections only from workloads inside the prod-vpc VPC, with no public internet exposure. The function can scale up to 200 concurrent requests during peak load, and you need stable connection management. What should you do to meet the security and performance requirements?

문제 분석

핵심 개념: 이 문제는 serverless(Cloud Functions 2nd gen)에서 Cloud SQL for PostgreSQL로의 안전한 private connectivity와, 안정적인 database connection을 유지하면서 높은 concurrency를 처리하는 방법을 평가합니다. 핵심 서비스는 private services access를 사용하는 Cloud SQL private IP, Serverless VPC Access, 그리고 애플리케이션 측 connection pooling입니다. 정답인 이유: 데이터베이스가 public internet 노출 없이 prod-vpc 내부의 워크로드에서만 connection을 허용해야 한다는 요구 사항은, Cloud SQL이 public IP 없이 private IP만 사용해야 함을 의미합니다. Cloud Functions (2nd gen)는 serverless이며 기본적으로 VPC에 직접 연결되지 않으므로, private resource로 트래픽을 라우팅하려면 동일한 region과 VPC에 있는 Serverless VPC Access connector를 사용해야 합니다. 성능 측면에서 200개의 동시 요청은 각 요청이 자체 connection을 열 경우 너무 많은 database session을 생성할 수 있으므로, connection을 제한하고 재사용하기 위해 connection pool이 필요합니다. Option D만이 private networking 요구 사항과 안정적인 connection 관리 요구 사항을 모두 충족합니다. 주요 기능: - Cloud SQL for PostgreSQL을 private IP 전용으로 구성하고, private services access를 사용하여 인스턴스가 prod-vpc에서 도달 가능한 internal address를 받도록 합니다. - us-central1의 Serverless VPC Access connector를 prod-vpc에 연결하여 Cloud Functions (2nd gen)가 private IP에 도달할 수 있도록 합니다. - 애플리케이션 수준의 connection pooling을 사용하여 전체 database connection 수를 제한하고, 급증하는 serverless concurrency 환경에서 재사용성을 향상시킵니다. - 표준 database authentication 및 IAM 제어는 계속 적용됩니다. private IP는 노출을 줄여주지만 최소 권한 액세스 설계를 대체하지는 않습니다. 흔한 오해: - firewall rule로 public IP를 제한하는 것은 public 노출을 제거하는 것과 같지 않습니다. public endpoint는 여전히 엄격한 no-internet-exposure 정책을 위반합니다. - Cloud SQL Auth Proxy는 authentication과 encrypted connectivity를 개선하지만, 높은 concurrency로 인해 발생하는 connection scaling 문제를 그 자체로 해결하지는 않습니다. - serverless 워크로드는 자동으로 VPC 내부에 존재하지 않으므로, private IP access에는 Serverless VPC Access connector가 필요합니다. 시험 팁: 문제에서 serverless가 private database에 도달해야 한다고 하면, Serverless VPC Access와 Cloud SQL private IP를 떠올리세요. 또한 높은 concurrency나 connection 안정성이 언급되면 connection pooling을 떠올리세요. 요구 사항이 internet 노출을 명시적으로 금지한다면 public IP를 완전히 제거하는 답안을 우선 선택하세요.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

문제 6

Your healthcare analytics platform is closing its private data center and must move a 2-node Oracle RAC 19c OLTP cluster (24 TB) that uses ASM and SCAN listeners to Google Cloud. The application depends on RAC services with FAN/TAF-based failover and requires minimal to no code changes, while maintaining equivalent performance (~5 ms storage latency and >40,000 TPS) after migration. You need a supported landing zone that preserves the RAC architecture and existing Oracle licensing with the least rework. What should you do?

문제 분석

핵심 개념: 이 문제는 RAC 고유 기능(ASM, SCAN, FAN/TAF)을 유지해야 하고 애플리케이션 변경을 최소화하면서 기존 Oracle 라이선스를 계속 사용해야 하는, 고도로 특화되고 성능 민감한 Oracle RAC 워크로드에 대해 올바른 Google Cloud landing zone을 선택하는지를 평가합니다. 정답이 맞는 이유: Oracle용 Bare Metal Solution (BMS)은 Google 관리 시설의 전용 물리 서버에서 Oracle database(Oracle RAC 포함)를 실행하도록 특별히 설계된, 지원되는 Google Cloud 오퍼링이며 고객 VPC에 연결됩니다. 이는 RAC 아키텍처(다중 노드, BMS에서 RAC를 위해 구현된 공유 스토리지 시맨틱)를 보존하고, ASM 및 SCAN listener를 지원하며, database와 연결 모델이 Oracle RAC로 유지되므로 최소 또는 무코드 변경으로 동일한 client failover 패턴(FAN/TAF)을 가능하게 합니다. 또한 성능 요구사항에도 부합합니다. BMS는 고 TPS의 OLTP에 적합한 예측 가능하고 낮은 지연의 스토리지 및 네트워크 특성을 제공하여, 범용 가상화 플랫폼에서 마주칠 수 있는 변동성과 기능 격차를 피할 수 있습니다. 주요 기능 / Best Practices: - 지원되는 전용 호스트에서 Oracle RAC를 제공하여, 지원되지 않는 DIY RAC 구축을 회피합니다. - Oracle licensing model(일반적으로 BYOL)과 운영 툴링을 유지합니다. - VPC로의 네트워크 통합을 통해 앱에서의 private connectivity를 가능하게 합니다(Cloud Interconnect/VPN을 통한 hybrid 포함). - 마이그레이션 접근은 일반적으로 Oracle-native 방식(RMAN duplicate/restore, Data Guard, 또는 설계에 따라 storage 기반 방식)을 사용해 다운타임을 최소화합니다. - Google Cloud Architecture Framework 목표에 부합합니다: reliability(RAC HA), performance efficiency(전용 하드웨어), operational excellence(지원되는 reference architectures). 흔한 오해: 팀들은 종종 “Compute Engine으로 lift-and-shift”가 동등하다고 가정하지만, Oracle RAC는 shared storage, cluster interconnect, vendor support 측면에서 엄격한 요구사항이 있습니다. 마찬가지로 Spanner 또는 PostgreSQL로 modernizing하면 cloud-native HA가 개선될 수 있지만, 이는 “최소 또는 무코드 변경” 제약을 위반하며 Oracle 기능 동등성을 충족하지 못할 수 있습니다. 시험 팁: Oracle RAC + ASM + SCAN + FAN/TAF + 최소 변경 + 라이선스 유지 + 높은 OLTP 성능을 보면, Oracle용 Bare Metal Solution 쪽으로 강하게 기울이세요. Compute Engine은 단일 인스턴스 Oracle 또는 일부 HA 패턴에는 적합하지만, 시험 시나리오에서의 차별점은 RAC의 supportability와 성능 예측 가능성입니다.

문제 7

Your media-streaming platform runs an AlloyDB for PostgreSQL cluster in us-central1 that is accessible only via a private IP; compliance forbids opening a public endpoint or installing agents on database VMs, and you must continuously replicate a subset of 12 tables (about 1.8 TB total, up to 2,500 row changes per second) into BigQuery for analytics and ML with end-to-end latency under 10 seconds and 99.9% delivery reliability using Google-managed services that automatically handle schema changes and scale without downtime; what should you do?

문제 분석

핵심 개념: 이 문제는 프라이빗 AlloyDB for PostgreSQL 소스에서 BigQuery로 거의 실시간 change data capture(CDC)를 수행하는 능력을 평가합니다. 완전 관리형 Google 서비스를 사용하면서 낮은 지연 시간, 높은 신뢰성, 자동 확장, 그리고 스키마 진화에 대한 복원력을 요구합니다. 정답이 맞는 이유: Datastream은 데이터베이스(예: AlloyDB 같은 PostgreSQL 호환 소스 포함)를 위한 Google의 관리형 CDC 서비스입니다. Datastream은 지속적인 row-level 변경을 캡처하고 낮은 지연 시간으로 스트리밍할 수 있습니다. AlloyDB 클러스터가 private-only이고 데이터베이스 VM에 에이전트를 설치할 수 없으므로, Datastream이 적합합니다. Datastream은 호스트 에이전트가 아니라 데이터베이스 네이티브 replication/log 기반 메커니즘을 사용하기 때문입니다. Datastream은 프라이빗 연결 패턴(구성에 따라 VPC connectivity/Private Service Connect 등)을 지원하므로 트래픽을 private IP 경로로 유지할 수 있습니다. 변경 사항을 BigQuery에 end-to-end <10s 지연 시간과 99.9% 전달 신뢰성으로 적재하려면, 권장 패턴은 Datastream CDC를 Google 제공 Datastream-to-BigQuery Dataflow template을 사용하는 streaming pipeline으로 연결하는 것입니다. Dataflow는 autoscaling, checkpointing, 그리고 exactly-once/at-least-once 처리 시맨틱(싱크 동작에 따라)을 제공하여 높은 전달 신뢰성과 다운타임 없는 지속 운영을 가능하게 합니다. 주요 기능 / 구성 / 모범 사례: - 12개 필수 테이블에 대한 include list(부분 복제)를 사용하여 PostgreSQL CDC용 Datastream을 구성합니다. - private connectivity(퍼블릭 엔드포인트 없음)와 최소 권한의 데이터베이스 replication user를 사용합니다. - Datastream-to-BigQuery Dataflow template을 사용해 지속적 ingestion, 확장, 운영 관리를 처리합니다. - 스키마 진화 처리 활성화: Datastream은 DDL 변경을 캡처하며 template/pipeline이(지원되는 변경 유형 범위 내에서) BigQuery로 스키마 업데이트를 전파할 수 있어 수동 개입을 줄입니다. - Google Cloud Architecture Framework에 따라 신뢰성을 설계합니다: 리전 리소스를 적절히 사용하고, lag/throughput을 모니터링하며, 알림을 설정하고, 2,500 changes/sec 및 1.8 TB 초기 상태에 대해 quota(BigQuery streaming inserts, Dataflow worker limits, Datastream throughput)를 계획합니다. 흔한 오해: - “Federated queries”는 더 단순해 보이지만, 데이터를 복제하지 않으며 대규모에서 sub-10-second 분석 최신성 요구를 충족하지 못합니다. - “DMS가 BigQuery로 복제할 수 있다”는 흔한 혼동입니다: DMS는 database-to-database 마이그레이션/복제(예: Cloud SQL/AlloyDB로)를 위한 것이지, BigQuery로의 지속적 CDC를 주 타깃으로 하는 서비스가 아닙니다. - “Custom polling service”는 유연해 보이지만 관리형 서비스/확장/신뢰성 요구를 위반하며, 보통 낮은 지연 시간 CDC를 무거운 엔지니어링 없이 달성하기 어렵습니다. 시험 팁: private-only 소스, 에이전트 불가, 지속적 CDC, BigQuery 타깃, 낮은 지연 시간, 관리형 스키마 변경 처리가 보이면—Datastream + Dataflow template to BigQuery를 떠올리세요. DMS는 분석용 BigQuery ingestion이 아니라 운영 DB 간 마이그레이션에 사용하세요.

문제 8

Your company runs a global event-ticketing platform on Google Cloud. Your engineering team is building a real-time seat reservation service that must prevent double-booking via strongly consistent, durable writes and elastically scale with live traffic spikes. The system must sustain up to 120,000 write operations per second at peak, keep p95 write latency under 15 ms, and incur less than 5 minutes of unplanned downtime per month (99.99% availability). You need a primary data store with very low-latency, high write throughput, and a 99.99% uptime SLA for production. What should you do?

문제 분석

핵심 개념: 이 문제는 (1) 이중 예약을 방지하기 위한 strong consistency, (2) 낮은 latency로 매우 높은 write throughput, (3) 스파이크 동안의 elastic scaling, (4) 99.99% availability SLA를 제공할 수 있는 기본 운영 데이터베이스를 선택하는지를 테스트합니다. Google Cloud에서 이 조합은 가장 직접적으로 Cloud Spanner에 해당합니다. 정답이 맞는 이유: Cloud Spanner는 horizontal scale을 위해 설계된 globally distributed, strongly consistent relational database입니다. 좌석 예약은 두 사용자가 동일한 좌석을 예약하지 못하도록 ACID semantics(예: conditional updates, unique constraints, serializable isolation)가 필요한 전형적인 transactional workload입니다. Spanner는 strongly consistent하고 durable한 writes를 제공하며, 노드를 추가하여 write throughput을 확장할 수 있습니다. 또한 multi-region 구성에 대해 99.99% SLA를 제공하여 월 <5분 downtime 요구사항과 부합합니다. 주요 기능 / Best Practices: - Strong consistency + ACID transactions: 좌석 hold/confirmation에 read-write transactions를 사용하고, primary keys/unique indexes로 uniqueness를 강제합니다. - Horizontal scaling: nodes/processing units로 용량을 산정하며, Spanner는 애플리케이션 레이어에서 sharding 없이 reads/writes를 확장합니다. - Low latency at scale: compute를 Spanner instance 가까이에 배치하고, availability를 위해 multi-region을 사용하거나 단일 region latency를 더 낮추기 위한 tradeoff로 regional을 사용합니다. - Availability: multi-region instance configuration(예: nam* 또는 eur*)을 사용하고, hotspots를 피하기 위한 schema design best practices를 따릅니다(예: monotonically increasing keys를 피하고 hashed/UUID keys 또는 key salting 사용). - Architecture Framework 정렬: Reliability(multi-region, automated replication), Performance(scale-out writes), Operational Excellence(managed service, online schema changes). 흔한 오해: Bigtable은 massive write throughput과 low latency를 처리할 수 있지만, relational/ACID transactional database가 아니며 rows/entities 전반에서 이중 예약을 방지하는 데 필요한 동일한 strong transactional guarantees를 제공하지 않습니다. Memorystore는 in-memory이며 durable한 system of record가 아닙니다. Cloud SQL은 strong consistency를 제공하지만, 일반적으로 복잡한 sharding 없이 120k writes/sec에서 p95 <15 ms로 elastic하게 확장하기 어렵고, 99.99% SLA 요구사항을 동일한 방식으로 충족하지 못할 수 있습니다. Exam Tips: “prevent double-booking,” “strongly consistent durable writes,” “global,” “elastic scale,” “99.99% SLA”를 보면 Cloud Spanner를 떠올리세요. relational transactions 없이 매우 높은 throughput의 key-value/time-series라면 Bigtable을, caching이라면 Memorystore를, vertical scaling과 read replicas 중심의 전통적 relational workload라면 Cloud SQL을 떠올리세요.

문제 9

You operate a real-time sports ticketing platform that uses Cloud SQL for MySQL in asia-northeast1. At 10:12 JST on a weekday launch, the instance entered an automatic maintenance event that caused 6 minutes of downtime, impacting over 15,000 concurrent users. Your SLO requires that any maintenance occur only outside your peak window of 09:00–22:00 JST, and you must make an immediate configuration change without migrating platforms or adding new components. What should you do to prevent future maintenance from occurring during peak hours?

문제 분석

핵심 개념: 이 문제는 계획된 유지보수를 위한 Cloud SQL 운영 제어, 특히 가용성 목표에 맞추기 위해 Cloud SQL maintenance window를 구성하는 것을 평가합니다. Cloud SQL for MySQL에서는 Google이 주기적으로 유지보수(패치 적용, 마이너 버전 업데이트, 인프라 작업)를 수행합니다. 일부 유지보수는 특히 단일 존 인스턴스이거나 failover/replica promotion이 관련될 때 짧은 downtime을 유발할 수 있습니다. 정답이 맞는 이유: SLO는 09:00–22:00 JST 외 시간에만 유지보수가 수행되어야 하며, 플랫폼 migration이나 구성 요소 추가 없이 즉시 구성 변경을 해야 합니다. 직접적이고 지원되는 제어는 인스턴스의 maintenance window를 비피크 시간대(예: 일요일 01:00–03:00 JST)로 설정하는 것입니다. 그러면 Cloud SQL은 해당 window 내에서(최선의 노력으로) 적용 가능한 유지보수를 스케줄링하여, 피크 시간에 유지보수가 시작될 위험을 크게 줄입니다. 이것이 바로 maintenance window 기능이 설계된 목적입니다. 주요 기능 / Best Practices: - Cloud SQL maintenance window: 요일과 시간(구성에서는 UTC 기준이며, JST에서 UTC로 올바르게 변환해야 함)을 선택합니다. 또한 위험 허용도에 따라 maintenance track(preview vs stable) 설정도 고려하세요. - Google Cloud Architecture Framework (Reliability)와 정렬: 운영 이벤트를 계획하고, 통제된 maintenance window를 사용하며, graceful degradation을 위해 설계합니다. HA (regional)는 downtime을 줄일 수 있지만, 문제에서 구성 요소 추가를 금지합니다. - 운영 세부사항: maintenance window는 모든 이벤트에 대해 엄격한 보장을 제공하지는 않지만, 아키텍처 변경 없이 사용할 수 있는 주요 제어 수단입니다. 흔한 오해: - “데이터베이스를 바꿔서” (Spanner) 유지보수를 피한다는 것은 migration이며 제약을 위반합니다. - “Support가 downtime을 설명해줄 수 있다”는 것은 피크 시간 재발을 방지하지 못합니다. - “Cloud Scheduler가 유지보수 시간을 강제할 수 있다”는 것은 Cloud SQL 유지보수 방식이 아닙니다. Google-managed maintenance를 5분으로 programmatically 제한할 수 없습니다. Exam Tips: 문제가 업무 시간 중 Cloud SQL 유지보수를 방지하라고 하면서 migration이나 새 구성 요소를 제한한다면, 기대되는 답은 Cloud SQL maintenance window(그리고 선택적으로 maintenance track) 구성입니다. maintenance window를 넘어서는 가용성이 필요하다면 HA (regional), read replicas, 애플리케이션 레벨 retries를 고려하되, 문제에서 아키텍처 변경을 허용하는 경우에만 적용하세요.

문제 10

You are designing a global order reconciliation service for a multinational retail platform. Applications in North America, Europe, and Asia must be able to read and write concurrently, with p95 cross-region transaction commit latency under 200 ms. The database must be fully managed, relational (ANSI SQL), provide global external consistency with RPO=0, support online schema changes, and meet a 99.99% availability target. Which Google Cloud service should you choose?

문제 분석

핵심 개념: 이 문제는 동시 다중 리전 읽기/쓰기를 강력한 일관성(외부 일관성, external consistency)으로 지원하고, 데이터 손실이 0(RPO=0)이며, 매우 높은 가용성을 제공하는 완전 관리형 전 세계 분산 관계형 데이터베이스를 선택하는지를 평가합니다. 정답이 맞는 이유: Cloud Spanner는 Google Cloud의 전 세계 분산, 수평 확장 가능한 ANSI SQL 관계형 데이터베이스로, 멀티 리전 active-active 워크로드를 위해 설계되었습니다. 리전 간 트랜잭션에 대해 외부 일관성(true serializability)을 제공하는데, 이것이 “global external consistency with RPO=0” 요구사항의 핵심입니다. Spanner에서는 멀티 리전 구성에서 커밋이 복제본들에 동기식으로 복제되므로, 커밋이 승인(acknowledged)되면 한 리전이 장애가 나더라도 내구성이 보장됩니다(RPO=0). 또한 Spanner는 완전 관리형이며 온라인 스키마 변경을 지원하여 운영 요구사항에도 부합합니다. 주요 기능 / 구성 / 모범 사례: - 멀티 리전 인스턴스 구성(예: nam3, eur3, asia1)은 지리적으로 분리된 리전 간 고가용성과 동기식 복제를 제공합니다. 적절히 구성하면 99.99% 가용성 목표를 지원합니다. - 외부 일관성은 Spanner의 TrueTime 기반 동시성 제어로 구현되어, 전 세계적으로 일관된 읽기와 쓰기를 보장합니다. - ANSI SQL 및 관계형 모델링이 핵심 기능이며, 보조 인덱스와 트랜잭션을 포함합니다. - 온라인 스키마 변경은 다운타임 없이 많은 스키마 업데이트를 가능하게 합니다(글로벌 리테일 플랫폼에 중요). - 지연 시간: 리전 간 커밋 지연은 복제본 배치와 네트워크 거리의 영향을 받습니다. 강력한 일관성으로 리전 간 트랜잭션이 반드시 필요할 때 Spanner가 의도된 서비스입니다. 실제로는 p95 목표를 맞추기 위해 인스턴스 구성과 애플리케이션 접근 패턴(예: locality, leader placement)을 설계합니다. 흔한 오해: Firestore는 멀티 리전이며 강력한 일관성을 제공하지만, NoSQL 문서 데이터베이스로서 ANSI SQL 관계형이 아닙니다. Cloud SQL은 관계형이지만, 대륙 간 외부 일관성과 RPO=0을 만족하는 글로벌 active-active 쓰기를 위해 설계되지 않았습니다. 리전 간 복제는 일반적으로 비동기이며, 장애 조치 시 primary가 변경됩니다. Bigtable은 wide-column NoSQL로, 관계형 SQL 트랜잭션이나 리전 간 외부 일관성을 제공하지 않습니다. 시험 팁: “global”, “concurrent writes in multiple regions”, “ANSI SQL”, “external consistency”, “RPO=0”가 보이면 기본적으로 Cloud Spanner를 선택하세요. 대신 PostgreSQL/MySQL 호환성과 read replica 및 리전 HA를 강조하면 Cloud SQL을, 문서 데이터와 오프라인 동기화를 강조하면 Firestore를, 대규모 처리량의 key-value/time-series를 강조하면 Bigtable을 떠올리세요.

문제 11

A global event ticketing platform runs its reservation and seat-allocation system on Cloud SQL for PostgreSQL 14; your SLOs require RTO ≤ 5 minutes and RPO ≤ 5 minutes, you must tolerate a single-zone outage with zero data loss and also be able to recover from a regional outage within minutes, and you need to choose a high-availability and disaster-recovery topology that meets these constraints without changing the application.

문제 분석

핵심 개념: 이 문제는 Cloud SQL for PostgreSQL의 high availability (HA)와 disaster recovery (DR)를 비교하는 내용을 테스트합니다. Cloud SQL에서 HA는 regional instance를 통해 달성되며, 동일한 region 내의 다른 zone에 synchronous standby (failover replica)를 유지합니다. region 간 DR은 일반적으로 asynchronous replication을 사용하는 cross-region read replica로 달성합니다. 정답인 이유: 단일 zone 장애를 데이터 손실 없이 허용해야 하며 RPO ≤ 5분을 충족해야 합니다. zonal failure에서 zero data loss를 달성하려면 다른 zone의 standby로 synchronous replication이 필요하며, 이는 Cloud SQL HA (regional)가 정확히 제공하는 방식입니다. regional outage에 대비하려면 다른 region에 데이터 사본이 있어야 하고 이를 빠르게 promote할 수 있어야 합니다. Cloud SQL의 cross-region replica는 asynchronous이지만, 일반적으로 replication lag가 낮으면 RPO를 수 분 단위로 충족할 수 있고, 운영 runbook/automation이 준비되어 있다면 promotion을 통해 수 분 내 복구 경로(RTO ≤ 5분)를 제공할 수 있습니다. 또한 이 토폴로지는 애플리케이션 변경을 피할 수 있는데, region 내 failover는 동일한 instance connection name을 유지하고, DR promotion은 애플리케이션 코드 변경 없이 connection endpoint/DNS 업데이트 또는 connection indirection layer를 통해 처리할 수 있기 때문입니다. 핵심 기능 / best practices: - Cloud SQL HA (regional) primary 사용: 다른 zone의 synchronous standby, zonal outage에 대한 automatic failover. - cross-region read replica(들) 추가: DR 및 선택적 read scaling을 위한 asynchronous replication. - replication lag 모니터링 및 alerting 설정으로 RPO 목표 충족 보장. - DR replica를 적절한 machine type/storage로 사전 프로비저닝하고 promotion 절차를 테스트하여 RTO 충족. - Google Cloud Architecture Framework에 정렬: reliability( multi-zone HA + multi-region DR), operational excellence(runbook, 테스트), cost awareness(cross-region replica는 비용 증가). 흔한 오해: - read replica가 region 간에 synchronous일 수 있다고 가정(Cloud SQL cross-region replication은 asynchronous). - 같은 region 내 replica만으로 regional outage를 커버한다고 믿음(그렇지 않음). - “모든 곳에서 asynchronous”여도 zonal failure에 대해 zero data loss를 보장할 수 있다고 생각(불가능). 시험 팁: - Cloud SQL에서: “HA/regional instance”는 zone 간 synchronous standby와 automatic failover를 의미. - “Read replicas”는 주로 scaling과 DR을 위한 것이며 asynchronous임. - 요구사항을 명시적으로 매핑: zonal outage에서 zero data loss => synchronous multi-zone; regional outage 복구 => cross-region replica + promotion + 운영 준비.

문제 12

You manage a development analytics environment running on Cloud SQL for MySQL in us-central1. The instance stores approximately 1.5 TB of data, with automated backups enabled to run daily and retain 7 copies. The workload is not mission-critical, and an RPO of 24 hours is acceptable. You need to lower monthly backup storage charges without disabling backups or changing the instance machine type. What should you change to reduce backup costs?

문제 분석

핵심 개념: 이 문제는 Cloud SQL automated backup 비용을 유발하는 요인과, 명시된 복구 목표(RPO)를 더 낮은 비용으로 충족하도록 backup 구성을 조정하는 방법을 평가합니다. Cloud SQL for MySQL에서 automated backups는 backup artifacts를 생성하며, 이는 backup storage로 저장되고 과금됩니다. 지속적인 backup storage 사용량에 직접 영향을 주는 두 가지 주요 레버는 (1) 얼마나 많은 backups를 보관(retain)하는지와 (2) 각 backup의 크기(여기서는 변경하지 않음)입니다. 정답이 맞는 이유: 데이터가 1.5 TB이고 7-backup retention policy를 사용하면, 여러 일자에 걸친 retained backup storage에 대해 비용을 지불하게 됩니다. 요구사항에 따르면 워크로드는 mission-critical이 아니며 24시간 RPO가 허용됩니다. 24시간 RPO는 사고 발생 시점 기준으로 최대 24시간 이전 시점까지 복구할 수 있어야 함을 의미합니다. 2일치 backups(2 copies)를 보관하더라도 24-hour RPO를 지원하면서, 7 copies 대비 retained backup storage 양을 크게 줄일 수 있습니다. 따라서 automated backup retention을 7 days에서 2 days로 줄이는 것이 backups를 비활성화하거나 instance machine type을 변경하지 않고도 월간 backup storage 요금을 낮추는 가장 직접적이고, 지원되며, 예측 가능한 방법입니다. 주요 기능 / Best Practices: Cloud SQL에서는 automated backup retention(보관할 backups/일수)을 구성할 수 있습니다. Google Cloud Architecture Framework의 cost optimization 및 reliability 원칙에 따라 retention을 비즈니스 요구사항(RPO/RTO)에 맞추세요: 명시된 recovery objective에 필요 이상으로 보관하지 마세요. dev/test analytics 환경에서는 RPO가 완화되는 경우가 많아 더 짧은 retention이 일반적입니다. 흔한 오해: 많은 사람들이 backup frequency를 낮추는 것(Option A)이 최고의 비용 레버라고 가정합니다. 하지만 Cloud SQL automated backups는 daily scheduling을 중심으로 설계되어 있으며, 설령 frequency를 조정할 수 있다 하더라도 48시간마다로 줄이면 명시된 24-hour RPO를 위반합니다. 또 다른 사람들은 backup “storage tier”(Option B)를 바꾸거나 backups를 더 저렴한 region으로 옮길 수 있다고(Option C) 생각하지만, Cloud SQL automated backups는 backup artifacts에 대해 선택 가능한 HDD/SSD tier를 제공하지 않으며, automated backups를 임의의 더 저렴한 region에 저장하도록 지원되는 구성도 없습니다. Exam Tips: Cloud SQL에서 “backup costs를 줄여라”를 보면, 먼저 retention 설정을 확인하고 RPO를 여전히 충족하는지 검증하세요. RPO가 24 hours라면 최소 daily backups를 유지하고 운영 현실(backup 누락, 늦게 발견된 corruption)을 커버할 만큼의 copies를 보관하되, 비중요 환경에서 과도한 retention은 피하세요.

문제 13

You are designing a new centralized fleet maintenance scheduling system for 180 municipal depots, each with approximately 450 GB of historical data; you plan to onboard 12 depots per week over a 15-week phased rollout; the solution must use an SQL database, minimize costs and user disruption during each regional cutover, and allow capacity to scale up during weekday peaks and down on nights and public holidays to control spend; what should you do?

문제 분석

핵심 개념: 이 문제는 단계적 온보딩과 최소한의 전환(cutover) 중단으로 중앙집중형 멀티테넌트 워크로드를 지원할 수 있는 managed SQL database를 선택하는 능력을 평가합니다. 또한 예측 가능한 사용 패턴에 맞춰 용량을 상/하향 스케일링하여 비용을 통제하는 요구사항을 다룹니다. 더불어 SQL과 탄력적 스케일링을 지원하는 Google Cloud database가 무엇인지에 대한 지식도 확인합니다. 정답이 맞는 이유: Cloud Spanner는 보기 중 Google Cloud-native이며 fully managed relational (SQL) database로서, 수평 확장(horizontal scale)과 zone/region 전반의 high availability를 위해 설계된 유일한 선택지입니다. 180개 depot와 depot당 약 450 GB(총 약 81 TB) 규모에서는 단일 Cloud SQL 토폴로지가 운영 측면에서 복잡해지고(인스턴스 사이징, storage/IOPS, connection 관리, maintenance window 등) 현실적인 한계에 부딪힐 수 있습니다. Spanner는 downtime 없이 compute capacity(노드 또는 processing units 추가/제거)를 온라인으로 스케일링할 수 있어, 평일 피크에는 스케일 업하고 야간/휴일에는 스케일 다운하여 비용을 통제할 수 있습니다. 온보딩이 단계적(주당 12개 depot)이므로, depot-by-depot(또는 region-by-region)로 Spanner로 마이그레이션하면서 dual-write 또는 change data capture 패턴을 사용해 사용자 중단을 최소화한 통제된 cutover를 수행할 수 있습니다. 주요 기능 / best practices: - 강한 일관성(strong consistency)과 high availability를 제공하는 Spanner SQL(Regional 또는 multi-regional 구성). - 온라인 compute scaling: 노드/processing units 조정; scheduler(예: Cloud Scheduler + Cloud Functions/Run)와 metrics(Cloud Monitoring)를 결합해 “custom autoscaling” 구현. - 멀티테넌시를 위한 schema 설계: interleaving/secondary indexes를 신중히 사용; hotspot을 피하도록 primary key를 선택(예: depot_id + 시간 기반 구성요소에 필요 시 hashing 포함). - 마이그레이션 접근: staged backfill + CDC(Datastream 적용 가능 시, 또는 애플리케이션 레벨 dual writes)로 각 cutover 동안 downtime 감소. 흔한 오해: Cloud SQL은 더 저렴하고 단순해 보이지만, 180개 depot를 여러 인스턴스로 sharding하면 운영 오버헤드가 증가하고, cross-depot 리포팅이 복잡해지며, 중단을 유발하는 인스턴스 리사이징 없이 진정한 scale-down/scale-up 탄력성을 제공하지 못합니다. Bigtable autoscaling은 매력적이지만 SQL relational database가 아닙니다. Bare Metal의 Oracle RAC는 강력하지만 비용이 높고 managed, elastic scaling 목표와 정렬되지 않습니다. Exam tips: 요구사항에 (1) SQL, (2) 매우 큰 총 데이터셋, (3) 수평 확장성과 high availability 필요, (4) 온라인 용량 변경이 포함되면 Spanner가 기본 정답입니다. 또한 Spanner에는 built-in autoscaling이 없으므로, 시험 문제에서는 Cloud Monitoring과 자동화를 사용한 scheduled/metric-driven scaling 구현을 기대하는 경우가 많습니다.

문제 14

Your company needs to relocate a high-traffic payment ledger database from a co-location data center to Google Cloud. The source is MySQL 8.0.28 using the InnoDB engine with binary logging enabled in ROW format; the dataset is 1.6 TB, averaging 900 TPS with bursts up to 1,500 TPS. A dedicated Cloud VPN tunnel provides 1 Gbps bandwidth between on-premises and Google Cloud. You must preserve ACID transactions and keep the production cutover under 3 minutes at 02:00 UTC. Cloud SQL for MySQL supports the source version. What should you do?

문제 분석

핵심 개념: 이 문제는 continuous replication(binlog-based CDC)을 사용하는 Database Migration Service (DMS)를 통해 MySQL을 Cloud SQL로 낮은 다운타임으로 마이그레이션하는 방법을 테스트합니다. 데이터베이스 계층에서 ACID 동작을 유지하면서 엄격한 cutover RTO(3분 미만)를 충족하는 데 중점을 둡니다. 정답인 이유: 1.6 TB 데이터셋과 지속적인 900 TPS(최대 1,500까지 급증) 환경에서는 어떤 “offline” export/import 방식(mysqldump/CSV)도 3분보다 훨씬 오래 걸리며 긴 다운타임을 초래합니다. DMS는 MySQL 8.0에서 Cloud SQL for MySQL로의 마이그레이션을 지원하며, 초기 load 이후 MySQL binary logs의 ROW format 기반 continuous replication을 수행할 수 있습니다. 초기 load를 미리 실행하고 replication이 거의 따라잡은 상태를 유지하면, 최종 cutover는 짧고 통제된 작업이 됩니다: source에서 writes를 중지하고, replication lag가 거의 0이 되도록 기다린 뒤, destination을 promote하고, 애플리케이션의 연결 대상을 전환합니다. 주요 기능 / 구성 / 모범 사례: - binlog-based replication을 사용하는 DMS continuous migration을 사용합니다(GTID를 사용할 수 있으면 권장, 그렇지 않으면 file/position). source에 ROW binlog format(문제에서 제공됨)이 설정되어 있고, 초기 load 중 logs가 삭제되지 않도록 적절한 retention이 설정되어 있는지 확인합니다. - 네트워크 처리량을 검증합니다: 1 Gbps VPN(이론상 약 125 MB/s, 실제는 더 낮음)은 continuous replication과 시간에 걸친 초기 load에 충분합니다. 핵심은 cutover가 1.6 TB를 해당 시간 창 동안 전송하는 것이 아니라, 남아 있는 변경 사항을 반영하는 데만 의존한다는 점입니다. - 트랜잭션 무결성을 유지합니다: InnoDB + row-based binlogs는 commit된 변경 사항을 결정적으로 replication할 수 있게 합니다. 애플리케이션 cutover에는 connection string 업데이트와 필요 시 DNS/connection pool 새로고침이 포함되어야 합니다. - Google Cloud Architecture Framework의 reliability 지침을 따릅니다: 리허설을 수행하고, replication lag를 모니터링하며, rollback 계획을 수립합니다(source를 잠시 read-only 상태로 유지하되 사용 가능하게 둠). 흔한 오해: - “mysqldump가 가장 간단하다”: 작은 데이터베이스에는 맞지만, 1.6 TB에서는 긴 다운타임이 발생하고 3분 요구 사항을 충족하지 못할 위험이 큽니다. - “ETL 도구로 데이터를 마이그레이션할 수 있다”: Data Fusion pipelines는 변환/분석 중심의 데이터 이동용이지, 거의 무중단으로 트랜잭션 일관성을 유지하기 위한 용도가 아닙니다. - “CSV export가 더 빠르다”: schema 충실도(constraints, triggers, routines)를 잃고, index 재구성이 필요하며, 여전히 긴 다운타임을 의미합니다. 시험 팁: 대용량 데이터셋 + 엄격한 cutover 시간 창 + binlogs가 활성화된 MySQL이 보이면, 기본적으로 DMS continuous migration(CDC)을 떠올리세요. dump/CSV import는 작은 데이터셋이거나 다운타임이 허용될 때만 사용하세요. 또한 Cloud SQL은 read replicas를 지원하지만, 환경 간 마이그레이션은 managed되고 모니터링 가능한 cutover를 위해 DMS로 처리하는 것이 가장 적합하다는 점도 기억하세요.

문제 15

During a quarterly disaster-recovery review at a fintech company, you discover that a production Cloud SQL for MySQL 8.0 instance (single-zone, us-central1-a, 800 GB with storage auto-increase enabled) is not configured for high availability (HA), while SLOs require RTO < 60 seconds and zero data loss during zonal failures; you have a 30-minute maintenance window this weekend and cannot accept multi-hour downtime for data migration. Following Google-recommended practices, how should you enable HA on this existing instance with the least operational risk?

문제 분석

핵심 개념: 이 문제는 MySQL용 Cloud SQL 고가용성(HA)과, 최소한의 위험과 다운타임으로 기존 인스턴스에 HA를 사후 적용(retrofit)하는 방법을 평가합니다. Cloud SQL에서 HA는 REGIONAL(availability-type=REGIONAL) 구성으로 제공되며, 동일 리전 내 다른 존에 standby를 생성하고 동기식 복제와 자동 failover를 사용합니다. 정답인 이유: 옵션 C는 Google이 권장하는 운영 접근 방식입니다. 기존 인스턴스를 REGIONAL로 patch하는 것입니다. Cloud SQL은 availability type을 업데이트하여 기존 인스턴스에서 HA를 활성화하는 것을 지원합니다. 이는 전체 논리적 마이그레이션(export/import)을 피하고, cutover 위험이 있는 병렬 스택 구축도 피합니다. 짧은 maintenance window 제약과 수 시간 다운타임을 피해야 한다는 요구사항에 부합합니다. 이 작업은 재구성 중 일부 다운타임(일반적으로 수 분, 인스턴스 크기와 워크로드에 따라 달라짐)이 발생하지만, 데이터 마이그레이션과 비교하면 가장 위험이 낮은 경로입니다. 주요 기능 및 모범 사례: REGIONAL HA는 primary와 standby를 서로 다른 존에 배치하여(존 장애 보호) 동기식 복제를 사용해 데이터 손실을 최소화합니다(존 장애에 대해 “zero data loss” 기대치를 충족). 또한 낮은 RTO로 자동 failover를 활성화합니다(대개 60초 훨씬 이내이지만, 애플리케이션은 Cloud SQL connector/proxy 및 재시도 로직 같은 권장 연결 방식을 사용해야 함). Storage auto-increase도 계속 지원되며, 추가 standby 리소스를 위한 충분한 regional quota를 확보해야 합니다. maintenance window에 변경을 계획하고, 통제된 failover 테스트로 검증하세요. 흔한 오해: Export/import(A) 또는 Data Fusion(B)도 HA를 달성할 수는 있지만, 800 GB에 대해 마이그레이션 시간이 길고 cutover 복잡도가 높으며, replication을 추가하고 cutover를 정교하게 오케스트레이션하지 않으면 “zero data loss” 요구사항을 놓칠 위험이 큽니다. 옵션 D는 HA를 “toggle”하라고 하지만 수동 stop/start를 암시합니다. Cloud SQL HA 활성화는 임의의 shutdown 절차가 아니라 update/patch 작업으로 수행되며, 수동 단계는 운영 위험을 증가시킵니다. 시험 팁: Cloud SQL에서 “HA”는 일반적으로 availability-type=REGIONAL(다른 존의 standby, 자동 failover)에 해당합니다. 기존 인스턴스에서 운영 위험이 가장 낮은 방법을 묻는다면, 마이그레이션보다 서비스가 지원하는 in-place 구성 변경을 우선하세요. HA 요구사항은 항상 RTO/RPO와 연결해 생각하세요. REGIONAL HA는 존 장애에 대해 낮은 RTO와 거의 0에 가까운 RPO를 목표로 하지만, 여전히 클라이언트 측 재시도/연결 모범 사례가 필요합니다.

문제 16

Your team runs a meal-delivery ordering platform in us-central1. The API is served from Cloud Run, and transactional data is stored in a single Cloud SQL for PostgreSQL instance with automatic maintenance updates enabled. 92% of customers are in the America/Chicago time zone and expect the app to be available every day from 6:00 to 22:00 local time. Security policy requires that database maintenance patches be applied within 7 days of release. You need to apply regular Cloud SQL maintenance without creating downtime for users during operating hours. What should you do?

문제 분석

핵심 개념: 이 문제는 Cloud SQL 유지보수 동작과 계획된 유지보수 동안 가용성을 확보하도록 설계하는 방법을 평가합니다. Cloud SQL에서 유지보수(OS/데이터베이스 패치)는 재시작이 필요할 수 있으며, 따라서 단일 인스턴스 배포에서는 다운타임이 발생할 수 있습니다. Google Cloud Architecture Framework의 핵심 아키텍처 원칙은 고가용성을 위해 설계하고 단일 장애 지점을 최소화하는 것입니다. 정답이 맞는 이유: Cloud SQL for PostgreSQL에 High Availability (regional)를 활성화하면 동일 리전(us-central1) 내의 다른 zone에 동기식(synchronous) standby를 둔 primary 인스턴스가 생성됩니다. 유지보수 중 Cloud SQL은 standby로 제어된 failover를 수행하고 업데이트를 적용한 뒤 (선택적으로) 다시 fail back할 수 있습니다. 이는 단일 인스턴스를 패치하는 것에 비해 사용자에게 보이는 중단을 크게 줄여, 패치를 7일 이내 적용해야 하는 정책을 준수하면서도 운영 시간(06:00–22:00 America/Chicago) 동안 다운타임이 없어야 한다는 요구사항을 충족하는 데 도움이 됩니다. 주요 기능 / 구성: - Cloud SQL HA (regional)는 자동 failover 및 regional IP 옵션을 포함한 zonal redundancy를 사용합니다. - 유지보수는 스케줄링할 수 있지만, 유지보수 window가 있더라도 단일 인스턴스는 재시작 동안 여전히 다운타임을 겪습니다. - HA는 고가용성과 계획/비계획 다운타임 감소가 필요한 프로덕션 워크로드에 권장되는 접근 방식입니다. - Cloud Run은 stateless이며 짧은 연결 끊김을 허용할 수 있고, HA는 데이터베이스 측 중단 구간을 최소화합니다. 흔한 오해: - 유지보수 window만 설정(Option A)하면 다운타임이 제거되는 것이 아니라 발생 시점만 제어합니다. 또한 Cloud SQL 유지보수 window는 UTC로 구성되며, 프로덕션이 단일 인스턴스라면 인스턴스 간 “sequencing”은 도움이 되지 않습니다. - read replica(Option B)는 읽기 확장과 재해 복구 패턴에 유용하지만 비동기(asynchronous)이며, 유지보수 중 쓰기(write)에 대해 자동으로 primary를 대체하려면 promotion과 애플리케이션 재구성이 필요합니다. - 사용자에게 알림(Option C)은 운영 시간 동안 다운타임을 피해야 한다는 요구사항을 충족하지 못합니다. 시험 팁: Cloud SQL에서 “유지보수 중 다운타임 회피”가 보이면 먼저 HA (regional)를 떠올리세요. 유지보수 window는 스케줄링을 위한 것이지 다운타임을 제거하는 것이 아닙니다. read replica는 끊김 없는 쓰기 가용성을 제공하지 않습니다. 또한 Cloud SQL 유지보수 window는 UTC로 지정되며, 보안 패치 타임라인 때문에 제한된 기간 내 유지보수가 강제될 수 있으므로 HA가 가장 안전하고 컴플라이언스 친화적인 설계입니다.

문제 17

You are deploying a new Java service on a Windows Server 2019 VM in your company’s on-premises data center (no Cloud VPN or Interconnect to Google Cloud), and the service uses JDBC on port 5432 to connect to a Cloud SQL for PostgreSQL instance that has a private IP 10.20.30.40 and a public IP 34.98.120.10, with SSL disabled on the instance; you must ensure the service can access the database without making any configuration changes to the Cloud SQL instance—what should you do?

문제 분석

핵심 개념: 이 문제는 외부(온프레미스) 환경에서의 Cloud SQL 연결 패턴, 특히 private IP 접근과 public IP 접근의 차이 및 Cloud SQL Auth Proxy(또는 Cloud SQL connectors)를 언제 사용해야 하는지를 테스트합니다. 또한 IAM과 데이터베이스 인증의 차이, 그리고 보안 연결 모범 사례도 간접적으로 평가합니다. 정답이 맞는 이유: VM이 Cloud VPN 또는 Cloud Interconnect 없이 온프레미스 데이터 센터에 있으므로 Cloud SQL 인스턴스의 private IP(10.20.30.40)로 가는 네트워크 경로가 없습니다. Cloud SQL의 private IP는 VPC에 연결된 네트워크(동일 VPC, peered VPC, 또는 VPN/Interconnect를 통한 온프레미스)에서만 도달 가능합니다. 또한 Cloud SQL 인스턴스 구성을 변경할 수 없으므로(VPN/Interconnect 추가, authorized networks 변경, SSL 강제 등 불가) 가능한 유일한 연결 경로는 인스턴스의 public IP(34.98.120.10)입니다. 인스턴스 설정을 변경하지 않고도 안전하게 연결하려면 service account와 함께 Cloud SQL Auth Proxy를 사용해야 합니다. proxy는 IAM을 사용해 인증되고 암호화된 터널을 Cloud SQL로 설정하며, 애플리케이션은 표준 JDBC로 로컬(예: 127.0.0.1:5432)에 연결합니다. 주요 기능 / 모범 사례: - Cloud SQL Auth Proxy(또는 language connectors)는 인스턴스의 “require SSL” 설정이 비활성화되어 있어도 전송 중 IAM 기반 권한 부여와 TLS 암호화를 제공합니다. - 클라이언트에서 Google 관리 엔드포인트로 나가는 outbound 연결로 동작하며, 일반적으로 클라이언트 측에서 inbound 방화벽 오픈이 필요하지 않습니다. - 최소 권한의 service account(예: roles/cloudsql.client)를 사용하고, 광범위한 네트워크 컨텍스트에서 데이터베이스 자격 증명을 노출하는 것을 피합니다. - Google Cloud Architecture Framework 보안 원칙(강력한 identity, 안전한 연결, 공격 표면 최소화)에 부합합니다. 흔한 오해: - Google Workspace 자격 증명과 데이터베이스 자격 증명을 혼동(Cloud SQL은 PostgreSQL 인증에 데이터베이스 사용자를 사용하며, Workspace 로그인은 JDBC 인증 메커니즘이 아님). - “IP를 알면” private IP가 어디서나 도달 가능하다고 가정. hybrid connectivity가 없으면 라우팅되지 않습니다. - SSL이 비활성화되어 있으면 트래픽이 암호화되지 않는다고 생각. proxy는 여전히 Cloud SQL로 TLS를 사용합니다. 시험 팁: “VPN/Interconnect 없는 온프레미스”를 보면 private IP에 의존하는 선택지는 제거하세요. “인스턴스 변경 불가”를 보면 인스턴스 측 네트워크 allowlisting이나 SSL 강제 변경보다 Cloud SQL Auth Proxy/Connectors를 우선하세요. 또한 기억할 점: IAM은 누가 연결할 수 있는지(proxy/connector)를 제어하고, PostgreSQL users/passwords는 연결 후 데이터베이스 로그인을 제어합니다.

문제 18

You manage a small, non-critical Cloud SQL for PostgreSQL instance (2 vCPUs, 50-GB storage) used by a staging QA pipeline; the business accepts a recovery point objective of up to 72 hours and you want to minimize ongoing operational and storage costs while still retaining basic recovery capability—what backup/restore configuration should you choose?

문제 분석

핵심 개념: 이 문제는 Cloud SQL for PostgreSQL 백업 전략의 트레이드오프(automated backups vs manual backups, 그리고 transaction log retention(시점 복구/point-in-time recovery/PITR))를 평가합니다. 또한 Google Cloud Architecture Framework의 cost optimization 및 operational excellence 원칙에 맞춰, 가장 낮은 운영 및 스토리지 비용으로 RPO 요구사항을 충족하는 데 초점을 둡니다. 정답이 맞는 이유: RPO가 최대 72시간이라는 것은 비즈니스가 최대 3일치 데이터 손실을 허용할 수 있음을 의미합니다. 기본적인 복구 기능을 제공하면서도 가장 저비용인 구성은 automated backups를 활성화하되 transaction log retention(PITR)은 비활성화하는 것입니다. Automated backups는 예약된 관리형 백업을 제공하며 보존(retention) 제어와 최소한의 운영자 개입으로 동작합니다. PITR을 끄면 WAL/transaction logs를 유지하는 데 필요한 추가 스토리지 및 지속적인 쓰기/보존 오버헤드를 피할 수 있는데, 완화된 RPO에서는 이것이 불필요합니다. 주요 기능 및 모범 사례: Cloud SQL automated backups는 서비스에서 관리되며 retention window(백업/일수)를 설정할 수 있습니다. 72시간 RPO를 만족하려면 retention이 최소 3일을 커버하도록 보장해야 합니다(일반적으로 3–7일로 설정). Transaction log retention을 비활성화하면 백업 사이의 임의 시점으로 복구하는 기능은 사라지지만, 스토리지 사용량과 비용이 줄어듭니다. 중요도가 낮은 staging QA 파이프라인에서는 보통 최신 백업으로의 복구(restore-to-last-backup)로 충분합니다. 흔한 오해: 옵션 B(manual daily backups)는 빈도를 직접 제어하므로 더 저렴해 보일 수 있지만, 운영 부담이 증가하고 백업 누락 위험이 있으며 manual backups도 스토리지를 사용합니다. 옵션 D(automated + PITR)는 가장 강력하지만, 완화된 RPO에 비해 비용과 복잡도가 증가하여 정당화되기 어렵습니다. 옵션 A(no backups)는 비용을 최소화하지만 기본 복구 기능을 유지해야 한다는 요구사항을 위반합니다. 시험 팁: RPO를 백업 빈도/보존으로 변환하세요: RPO가 72시간이면 최소 72시간마다 백업이 있어야 하고 그 기간만큼 보존되어야 합니다. 운영 부담이 적어야 하는 환경에서는 automated backups를 사용하세요. PITR은 더 세밀한 복구(분/시간 단위)나 백업 사이에 발생한 논리적 손상에 대한 보호가 필요할 때만 활성화하세요. 비용 관련 문제에서는 PITR이 지속적인 transaction log 스토리지를 의미하며, 일반적으로 백업만 사용하는 것보다 비용이 더 높다는 점을 기억하세요.

문제 19

You operate a Cloud SQL for PostgreSQL deployment in Google Cloud. The primary instance runs in zone europe-west1-b, and a read replica runs in zone europe-west1-c within the same region. An alert reports that the read replica in europe-west1-c was unreachable for 11 minutes due to a zonal network disruption. You must ensure that the read-only workload continues to function and that the replica remains available with minimal manual intervention. What should you do?

문제 분석

핵심 개념: 이 문제는 zonal disruption 동안 Cloud SQL for PostgreSQL read replica의 가용성과 운영 복구를 테스트합니다. Cloud SQL read replica는 별도의 asynchronous replica instance이며, 한 zone에 있는 단일 replica는 여전히 해당 zone의 read traffic에 대한 single point of failure입니다. Cloud SQL은 단일 read replica에 대해 automatic read workload failover를 제공하지 않으므로, 지속적인 read 가용성이 필요하다면 replica capacity를 직접 복구하거나 미리 여러 replica로 설계해야 합니다. 정답인 이유: 유일한 read replica에 11분 동안 접근할 수 없었고, 요구 사항이 최소한의 수동 개입으로 read-only workload가 계속 동작하도록 보장하는 것이므로, 가장 적절한 조치는 최신 사용 가능한 상태에서 새 read replica를 생성하고 read traffic을 그쪽으로 리디렉션하는 것입니다. 이렇게 하면 primary를 중단하지 않고 serving replica를 복구할 수 있습니다. 이는 zonal failure 이후 read 가용성을 다시 확립하기 위한 선택지 중 가장 적절한 운영 대응입니다. 주요 특징: - Cloud SQL read replica는 asynchronous이며, 그 자체만으로 automatic read failover semantics를 제공하지 않습니다. - replica zone에 영향을 주는 zonal outage가 발생하면, 다른 replica가 이미 존재하지 않는 한 read traffic은 serving target을 잃을 수 있습니다. - read replica를 다시 만드는 것은 관리적 복구 작업입니다. 더 강한 복원력을 위해서는 여러 zone에 걸쳐 multiple replica를 배포하고 application 측 routing 또는 connection management를 사용해야 합니다. 흔한 오해: 흔한 실수는 zonal disruption 이후 Cloud SQL이 자동으로 다른 zone에 read replica를 다시 생성한다고 가정하는 것입니다. 또 다른 오해는 primary를 재시작하면 replica 복구에 도움이 된다는 생각인데, 일반적으로는 불필요한 write 중단만 추가합니다. clone 역시 read replica의 대체물이 아닙니다. clone은 replication target이 아니라 독립적인 복사본이기 때문입니다. 시험 팁: - primary HA/failover 동작과 read replica 동작을 구분하세요. 둘은 동일하지 않습니다. - 문제가 read workload 연속성 유지에 대해 묻는다면, replica redundancy와 traffic redirection을 떠올리세요. - replica가 하나뿐이고 그것이 사용할 수 없게 되면, 아키텍처에 이미 추가 replica가 포함되어 있지 않은 한 수동 재생성이 필요할 수 있습니다.

문제 20

You are migrating a vendor CRM database from a legacy SQL Server 2014 Enterprise instance running on a 3‑node VMware cluster with a Fibre Channel SAN to a single Cloud SQL for SQL Server instance in Google Cloud. Storage telemetry from the SAN shows peak read workloads reaching approximately 27,000 IOPS with read latency under 2 ms during quarterly reporting. You want to size the Cloud SQL instance to maximize read performance while keeping licensing costs minimal. What should you do?

문제 분석

핵심 개념: 이 문제는 Cloud SQL for SQL Server의 성능 sizing, 특히 storage size와 machine shape가 IOPS/latency에 어떤 영향을 주는지, 그리고 동시에 SQL Server licensing cost(Standard vs Enterprise)를 어떻게 균형 있게 고려하는지를 평가합니다. Cloud SQL에서 storage performance는 주로 기본 persistent disk 특성과 provisioned size(이는 IOPS/throughput ceiling에 영향을 줌)에 의해 결정되며, CPU/RAM은 query execution과 buffer cache hit rate에 영향을 줍니다. 정답인 이유: 측정된 peak read workload는 약 27,000 IOPS이며 latency는 2 ms 미만입니다. Cloud SQL에서 read performance를 최대화하려면 일반적으로 필요한 IOPS headroom을 충족할 수 있을 만큼 충분히 큰 SSD storage가 필요합니다. 이는 persistent disk SSD performance가 provisioned capacity에 따라 확장되고, per-GB IOPS limits 및 per-instance caps가 있기 때문입니다. Standard edition 옵션들 중에서 가장 큰 SSD(1 TB)는 가장 높은 달성 가능한 IOPS/throughput 범위를 제공하며, 분기별 reporting 동안 27k read IOPS를 지속할 가능성이 가장 높습니다. 또한 SQL Server Standard를 유지하면 Enterprise 대비 licensing cost를 최소화할 수 있습니다. 주요 기능 / 모범 사례: - latency에 민감한 OLTP/reporting burst에는 SSD를 선호합니다. - data volume만 기준으로 sizing하지 말고, peak IOPS와 headroom을 기준으로 storage를 sizing합니다. - SQL Server가 더 큰 buffer pool의 이점을 얻는 경우 High Memory shape를 사용합니다(핫 데이터를 caching하여 read performance 향상). 다만 storage IOPS가 여전히 제한 요소일 수 있음을 인식해야 합니다. - load testing으로 검증하고 Cloud SQL metrics(disk read ops, latency, CPU, buffer cache hit ratio)를 모니터링합니다. 흔한 오해: - vCPU를 늘리면 IOPS도 증가한다고 가정하는 것: CPU는 query processing에 도움이 되지만, storage IOPS limits가 더 큰 제약이 될 수 있습니다. - “성능”을 위해 Enterprise를 선택하는 것: Enterprise는 추가 기능(예: advanced HA/online operations)을 제공하지만 Cloud SQL storage limits를 본질적으로 제거하지는 않으며, licensing cost도 증가시킵니다. - SSD를 과소 sizing하는 것(예: 600–800 GB): 비용 효율적으로 보일 수 있지만 peak IOPS target을 충족하지 못할 수 있습니다. 시험 팁: 문제에서 IOPS/latency requirements를 제공하면, 먼저 이를 storage type과 size에 매핑한 다음 requirements를 충족하는 가장 작은 edition(Standard)을 선택하세요. 더 큰 SSD를 사용해 IOPS ceiling을 높이고, 필요한 기능이 명시적으로 Enterprise를 요구하는 경우에만 Enterprise를 선택하세요(예: 특정 HA/DR 또는 advanced SQL Server capabilities).