Practice Test #1

AlloyDB를 polling하는 custom GKE 마이크로서비스는 CDC가 아니며, 2,500 changes/sec에서 <10s 지연 시간과 99.9% 전달 신뢰성을 달성하려면 상당한 커스텀 엔지니어링(중복 제거, 순서 보장, 재시도, backpressure, schema drift 처리)이 필요합니다. Polling은 소스 부하도 증가시키고 운영 복잡성이 큽니다. 또한 자동 확장과 다운타임 없는 스키마 변경 처리를 제공하는 Google 관리형 서비스를 사용해야 한다는 요구를 위반합니다.

BigQuery federated queries(external connections 사용)는 데이터를 제자리에서 조회하기 위한 것이지, BigQuery로 지속적으로 복제하는 것이 아닙니다. 일반적으로 downstream analytics/ML을 위해 BigQuery 테이블로 end-to-end 10초 미만 지연 시간으로 변경을 전달해야 한다는 요구를 충족하지 못하며, 높은 변경률에서 성능/비용이 예측 불가능할 수 있습니다. 또한 복제 데이터에 대해 99.9% 전달 신뢰성을 보장하는 내구성 있는 전달 파이프라인을 제공하지 않습니다.

Database Migration Service는 데이터베이스 간 마이그레이션과 지속적 복제를 위해 설계되었습니다(예: on-prem/MySQL/PostgreSQL에서 Cloud SQL/AlloyDB로). BigQuery를 타깃으로 직접 CDC를 스트리밍하는 표준 관리형 서비스가 아닙니다. 설령 다른 곳에 데이터를 staging할 수 있더라도 구성 요소와 지연 시간이 추가되며, 자동 스키마 변경 처리 요구와 BigQuery로의 직접적/확장 가능/관리형 경로 요구에 부합하지 않습니다.

Bigtable은 매우 높은 처리량과 저지연 key/value 접근(time-series, IoT, analytics serving)에 최적화된 완전 관리형 wide-column NoSQL 데이터베이스입니다. ANSI SQL 관계형이 아니며, Spanner와 같은 전 세계 외부 일관성 기반의 멀티 리전 트랜잭션 시맨틱을 제공하지 않습니다. 가용성을 위해 복제할 수는 있지만, 엄격한 일관성과 온라인 관계형 스키마 진화 요구사항을 갖는 리전 간 ACID 트랜잭션에는 적합하지 않습니다.

Firestore는 강력한 일관성과 멀티 리전 복제 옵션을 갖춘 완전 관리형 문서 데이터베이스이며, 글로벌 애플리케이션을 지원할 수 있습니다. 그러나 관계형 ANSI SQL 데이터베이스가 아니고, 관계형으로 설명된 주문 정산 시스템에서 기대되는 관계형 스키마, 조인, SQL 트랜잭션 모델을 제공하지 않습니다. 또한 Spanner를 가리키는 전형적인 “external consistency + SQL + global transactions” 요구사항과도 일치하지 않습니다.

Cloud SQL for MySQL은 관리형 관계형 데이터베이스이지만, 기본적으로 리전 단위입니다. 리전 간 설계는 일반적으로 read replica와 비동기 복제에 의존하므로 RPO=0을 보장할 수 없습니다. 동시 멀티 리전 쓰기와 global external consistency를 달성하는 것은 Cloud SQL의 기능이 아닙니다. 장애 조치 시 primary가 변경되며, 복제 모드에 따라 운영 복잡성과 잠재적 데이터 손실이 발생할 수 있습니다. active-active 쓰기로 전 세계 99.99%를 달성하는 것은 이 서비스의 목표 사용 사례가 아닙니다.

오답입니다. Cloud Data Fusion은 주로 ETL 및 데이터 통합 플랫폼이지, 낮은 다운타임 cutover를 위한 전용 트랜잭션 데이터베이스 마이그레이션 서비스가 아닙니다. 테이블별 pipeline 접근 방식은 높은 트래픽의 payment ledger에 대해 commit 순서, 트랜잭션 일관성, 또는 continuous synchronization을 자연스럽게 보장하지 못합니다. 또한 마이그레이션 중 발생하는 변경 사항을 처리하려면 상당한 다운타임이나 사용자 정의 reconciliation logic이 필요합니다. 따라서 엄격한 3분 미만 cutover 요구 사항이 있는 1.6 TB OLTP 데이터베이스에는 적합하지 않습니다.

오답입니다. mysqldump는 logical export 도구이며, 다운타임을 3분 미만으로 유지해야 하는 1.6 TB production 데이터베이스에는 일반적으로 너무 느립니다. export를 압축하더라도 dump, 전송, import, 검증에 걸리는 총 시간은 허용된 outage 시간 창보다 훨씬 길어집니다. 이 방법은 export와 import 중 source와 target 모두에 큰 부하를 주어 운영 위험도 증가시킵니다. 더 작은 데이터베이스나 긴 다운타임이 허용되는 maintenance window에는 적절할 수 있지만, 이 시나리오에는 맞지 않습니다.

오답입니다. 테이블을 CSV로 export하고 Cloud SQL로 import하는 방식은 이 정도 규모와 중요도를 가진 트랜잭션 MySQL 마이그레이션에는 적합하지 않은 수동 bulk-load 패턴입니다. CSV 워크플로는 상당한 추가 작업 없이는 triggers, routines, foreign keys 및 기타 schema-level objects와 같은 전체 데이터베이스 의미를 보존하지 못합니다. import 후 indexes와 constraints를 재구성하면 시간과 복잡성이 더 늘어나므로 outage는 3분을 훨씬 초과하게 됩니다. 이 접근 방식은 낮은 다운타임 마이그레이션이 필요한 payment ledger보다는 분석용 데이터 이동에 더 적합합니다.

유지보수 window를 설정하면 유지보수 발생 시점을 제어하는 데는 도움이 되지만, 패치에 재시작이 필요한 경우가 많기 때문에 단일 Cloud SQL 인스턴스에서 다운타임을 방지하지는 못합니다. 또한 Cloud SQL 유지보수 window는 UTC로 구성되므로 “02:00–03:00 America/Chicago”처럼 로컬 타임존으로 설정이 적용되는 방식이 아닙니다. 비프로덕션을 먼저 적용하도록 sequencing하는 것은 좋은 관행이지만, 프로덕션 가용성 문제를 해결하지는 못합니다.

read replica는 읽기 트래픽을 오프로딩할 수 있지만, primary 유지보수 동안 트랜잭션(쓰기 중심) 시스템에 대해 자동적이고 끊김 없는 연속성을 제공하지는 못합니다. Cloud SQL replica는 비동기이며, replica를 primary로 promotion하는 것은 중단을 수반하는 운영 이벤트이고 일반적으로 연결 endpoint 변경과 신중한 failover 계획이 필요합니다. 이는 운영 시간 동안 사용자 다운타임을 피해야 한다는 요구사항을 충족하지 못합니다.

유지보수 알림과 일정 재조정은 운영 측면에서 유용하지만 다운타임을 제거하지는 못합니다. 요구사항은 7일 이내 패치를 적용하고 06:00–22:00 로컬 시간 동안 다운타임을 피하는 것입니다. 사용자에게 알린다는 것은 다운타임을 수용한다는 의미이므로 명시된 목표와 충돌합니다. 또한 유지보수 시점은 Google의 유지보수 정책과 패치 컴플라이언스 기간에 의해 제약될 수 있습니다.

primary의 clone은 read replica와 동일하지 않습니다. clone은 독립적인 복사본이며, 생성 후 primary로부터 asynchronous replication을 계속하지 않습니다. read traffic에 clone을 사용하면 시간이 지나면서 data divergence가 발생하고 더 많은 수동 관리가 필요합니다. 따라서 관리되는 read replica topology를 적절히 복구하지 못합니다.

이 선택지는 read replica가 정상 zone에서 자동으로 다시 생성된다는 가정에 의존하기 때문에 올바르지 않습니다. Cloud SQL은 zonal disruption 이후 read 가용성을 유지하기 위해 단일 read replica를 다른 곳에 자동으로 재생성한다는 문서화된 보장을 제공하지 않습니다. 상태를 확인하는 것은 합리적인 운영 점검이지만, 그 자체로 read-only workload가 계속 동작하도록 보장하지는 않습니다. 문제는 단순히 무엇을 관찰해야 하는지가 아니라, 가용성을 보장하기 위해 무엇을 해야 하는지를 묻고 있습니다.

primary를 재시작하는 것은 불필요하며 잠재적으로 해롭습니다. 문제는 primary database process가 아니라 zonal network disruption으로 인해 replica에 접근할 수 없다는 점입니다. primary를 재시작하면 write traffic이 중단될 수 있고 replica 또는 read service의 복구도 보장하지 못합니다. 실제 failure domain을 해결하지 못한 채 위험만 추가합니다.