Google Professional Data Engineer

Dataflow로 마이그레이션은 일부 파이프라인에서 비용 효율적일 수 있지만, 일반적으로 작업 재작성(또는 변경)이 필요합니다(Dataproc의 PySpark는 변경 없이 Dataflow로 직접 이식할 수 없음). 문제는 재작성이나 스케줄 변경을 명시적으로 금지합니다. 또한 Dataflow는 다른 실행 모델(Beam)과 운영 방식이므로, “클러스터 구성” 관점의 비용 최적화에 대한 최선의 답이 아닙니다.

더 높은 메모리 머신 타입은 실행 시간을 줄일 수 있지만, 시간당 VM 비용을 증가시키며 이미 35분 내에 완료되는 작업의 총비용을 낮춘다는 보장이 없습니다. 이 선택지는 비용이 아니라 성능을 최적화합니다. 작업이 메모리 병목이라는 근거와 더 적은 노드로 운영할 수 있다는 근거가 없다면, 더 큰 머신으로 전환하는 것은 위험하고 종종 더 비싼 변경입니다.

local SSD는 shuffle이 많은 Spark 워크로드에서 I/O 성능을 개선할 수 있지만, 비용이 추가되며 Cloud Storage에서 읽고 BigQuery로 쓰는 짧은 주간 배치에서는 필요하지 않습니다. Dataproc 작업은 프리미엄 스토리지를 추가하는 것보다 컴퓨팅 가격 최적화에서 더 큰 이점을 얻는 경우가 많습니다. 이는 성능 튜닝 옵션이지, 가장 직접적인 비용 절감 레버가 아닙니다.

오답. Pub/Sub Kafka connector는 Kafka Connect connectors(source/sink)로 구현되며 Kafka Connect runtime과 connector 배포가 필요합니다. 이는 mirroring 선호와 맞지 않고 운영 복잡성을 증가시킵니다. 또한 cloud에 배포하더라도 불필요한 Kafka Connect 계층을 포함한 뒤 Kafka에서 읽어 Cloud Storage에 쓰는 것을 제안하므로, Pub/Sub connector 사용이 목표 대비 중복되고 혼란스럽습니다.

오답. 온프레미스 Kafka cluster에 Pub/Sub Kafka connector 설치를 명시적으로 요구하므로, 온프레미스에 Kafka Connect plugins 배포를 피해야 하는 엄격한 change control 요구사항을 위반합니다. 또한 Kafka에서 Pub/Sub로 데이터를 이동하는 방향에서 Pub/Sub를 Source connector로 구성하는 것은 방향이 반대입니다. 일반적으로 Kafka record를 Pub/Sub로 publish하려면 Sink connector를 사용합니다.

오답. Kafka-to-Pub/Sub에서 Pub/Sub를 Sink connector로 사용하는 방향 자체는 맞지만, 여전히 온프레미스에 Pub/Sub Kafka connector(Kafka Connect plugin)를 설치하고 운영해야 하므로 요구사항에 의해 금지됩니다. 또한 mirroring 기반 Kafka topic replication 접근에서 벗어나며, raw landing 대상이 명시적으로 Cloud Storage인 상황에서 불필요한 Pub/Sub semantics와 quota를 도입합니다.

Network tag와 firewall rule은 트래픽을 허용하거나 차단할 수는 있지만, node에 external IP가 없고 NAT/PGA도 없을 때 Google APIs에 도달하기 위한 경로를 제공하지는 않습니다. 또한 tag는 Google API 접근을 선택적으로 활성화하는 메커니즘도 아닙니다. 이 선택지는 authorization(firewall)과 connectivity(routing/egress)를 혼동하고 있습니다.

“Cloud Storage 및 BigQuery IP range”로의 egress firewall rule을 만드는 것은 올바른 해결책이 아닙니다. Google APIs는 일반적으로 anycast VIP를 사용하고 IP가 변경될 수 있어 IP allowlist 유지가 취약합니다. 더 중요한 점은, egress rule을 관대하게 설정하더라도 internal-only node는 해당 endpoint에 도달하기 위한 유효한 egress 메커니즘(Private Google Access 또는 Cloud NAT)이 여전히 필요하다는 것입니다.

VPC Service Controls perimeter는 perimeter 외부에서 지원되는 Google service에 대한 접근을 제한하여 데이터 유출 위험을 줄이는 데 도움이 됩니다. 하지만 private node에서 Google APIs로의 기본적인 network reachability 문제를 해결하지는 못합니다. Private Google Access(또는 NAT/PSC) 없이는 여전히 연결 실패가 발생할 수 있습니다. 이는 egress connectivity 기능이 아니라 보안 경계 기능입니다.

오답입니다. sandbox project는 여전히 프로덕션 데이터를 보호하지만, force-data-loss는 failover 중 최근 write를 잃을 가능성을 의도적으로 높입니다. 이는 프로덕션에서의 운영 방식과 덜 유사한 훈련이 되며(비록 sandbox 데이터만 영향받더라도) “no data loss” 의도와도 충돌합니다. 현실적이고 더 안전한 failover 테스트에는 limited-data-loss가 적절한 mode입니다.

오답입니다. 이는 프로덕션에서 중단을 유발하는 작업을 수행하므로, 프로덕션 데이터에 대한 영향 0을 보장해야 한다는 요구사항을 위반합니다. replica를 추가해도 replication이 비동기이기 때문에 데이터 손실 가능성을 제거하지 못하며, force-data-loss는 위험을 더 키웁니다. 또한 이 선택지는 엄격한 “no data loss” 및 “no production impact” 제약을 충족하지 못하면서 운영 복잡성과 비용만 증가시킵니다.

오답입니다. limited-data-loss mode를 사용하더라도 프로덕션에서 manual failover를 시작하면 일부 데이터 손실(비동기 replication) 가능성이 여전히 존재하고, 일시적인 클라이언트 영향(연결 재설정, 짧은 가용성 저하)도 발생할 수 있습니다. 문제는 프로덕션 데이터에 대한 영향 0을 보장해야 하며, Standard Tier Redis에서 어떤 프로덕션 failover 작업으로도 이를 확실히 보장할 수 없습니다.

오답입니다. Compute Engine의 기본 저장 시 암호화는 팀이 생성하고 제어하는 키가 아니라 Google-managed keys를 사용합니다. 전용 service account는 암호화 키 소유/관리 모델을 바꾸지 않습니다. 따라서 customer-controlled 키 생성, 로테이션 정책 강제, 요청 시 파기라는 컴플라이언스 요구사항을 충족하지 못합니다. 또한 identity/access control을 cryptographic key management와 혼동하고 있습니다.

오답입니다. 로컬에서 키를 생성해 “KMS에 업로드”하는 것은 Persistent Disks를 암호화하는 표준 접근이 아닙니다. Cloud KMS는 key material import를 지원하지만, 여전히 인스턴스에서 데이터를 수동으로 암호화하는 방식이 아니라 CMEK 통합을 사용합니다. OS/app 계층에서 수동으로 암호화하면 운영 복잡성이 증가하고, RabbitMQ/TimescaleDB가 데이터를 읽고/쓰는 방식에 변경이 필요할 가능성이 큽니다.

오답입니다. 애플리케이션 API 호출에서 KMS 키를 직접 참조하는 것은 애플리케이션 수준 암호화(envelope encryption)를 설명하는 것으로, 코드 변경이 필요하고 암호화/복호화 로직, 성능, 키 접근 패턴을 신중히 다뤄야 합니다. 요구사항에 “애플리케이션 코드 변경 없이”라고 명시되어 있으므로 부적합합니다. VM 디스크의 경우 CMEK는 애플리케이션 호출이 아니라 인프라 리소스 수준에서 구성합니다.

Dataflow job을 drain 하면 새 메시지 pull을 중단하고 종료 전에 in-flight 요소 처리를 완료하려고 시도합니다. 하지만 이는 새 pipeline이 기존 pipeline과 호환되지 않는다는 요구사항(키잉/윈도잉/state 변경)을 해결하지 못합니다. 호환되지 않는 streaming graph/state 변경은 항상 in-place 업데이트가 가능한 것이 아니며, draining만으로는 병렬의 손실 0 cutover 경로를 제공하지 않습니다.

Transform mapping JSON은 특정 Dataflow 업데이트 시나리오와 연관되지만, state 및 집계 정확도에 영향을 주는 서로 다른 키잉/윈도잉 로직 같은 임의의 호환되지 않는 의미적 변경을 일반적으로 가능하게 하지는 않습니다. 업데이트가 수락되더라도 state 비호환성과 잘못된 결과의 위험이 있습니다. 또한 이 옵션은 중단 없는 안전한 blue/green 배포라는 운영 요구사항도 해결하지 못합니다.

동일한 Pub/Sub subscription에 대해 두 개의 Dataflow job을 실행하면 공유 backlog의 메시지를 두 job이 경쟁하게 됩니다. Pub/Sub은 subscriber들에 메시지를 분배하므로, 기존 job도 모든 메시지를 보지 못하고 새 job도 모든 메시지를 보지 못합니다. cutover/cancellation 동안 메시지가 미처리로 남거나 일관되지 않게 처리되어, 데이터 손실 0 요구사항을 위반할 수 있습니다.

zone 변경은 autoscaling 한계를 제어하는 1차 수단이 아닙니다. 특정 zone의 capacity가 부족하거나 zonal 리소스 가용성에 의해 제약을 받는 경우 zone 선택이 영향을 줄 수는 있지만, Dataflow worker scaling은 일반적으로 구성(max workers)과 프로젝트 quota에 의해 제한됩니다. 이 시나리오는 scaling이 40에서 일관되게 멈춘다고 설명하므로, 일시적인 zonal capacity 문제가 아니라 구성된 cap을 강하게 시사합니다.

worker 수(initial workers / numWorkers)는 Dataflow 작업의 시작 크기를 설정합니다(autoscaling이 비활성화된 경우에는 고정 크기일 수도 있습니다). autoscaling이 활성화된 경우 initial workers를 늘리면 시작 시 backlog를 줄일 수 있지만, 구성된 최대값을 넘어 확장할 수 있게 하지는 못합니다. 작업이 이미 40까지 scale up한 뒤 멈추므로, 문제는 initial worker 수가 아닙니다.

worker당 disk size는 shuffle spill, 큰 state, 또는 임시 파일로 인해 worker의 disk가 부족한 경우 성능 저하나 실패를 완화하는 데 도움이 될 수 있습니다. 하지만 autoscaling이 어디까지 scale out할 수 있는지를 제어하지는 않습니다. 여기서의 증상은 backlog가 증가하는데도 scaling이 40 worker에서 하드하게 멈추는 것이며, 이는 worker별 disk 제약이 아니라 autoscaling 상한을 가리킵니다.

Cloud Spanner는 strong consistency와 SQL을 제공하는 globally distributed, horizontally scalable relational database입니다. ACID 트랜잭션과 high availability를 지원하지만, 일반적으로 global distribution, 대규모 확장, 또는 multi-region 복원력을 위해 선택됩니다. 최소 변경과 비용 최소화가 필요한 single-region 2.3 TB PostgreSQL lift-and-shift에는 보통 과도하며, 스키마/SQL 조정이 필요해 노력과 비용이 증가할 수 있습니다.

Cloud Bigtable은 매우 높은 throughput과 low-latency key/value 또는 time-series access 패턴에 최적화된 wide-column NoSQL database입니다. PostgreSQL 호환 표준 SQL querying, relational joins, 또는 relational database처럼 임의의 row 전반에 대한 일반적인 OLTP transactional semantics를 제공하지 않습니다. billing API를 PostgreSQL에서 Bigtable로 마이그레이션하려면 상당한 스키마 및 애플리케이션 재설계가 필요하여 “재설계 불가” 제약을 위반합니다.

Cloud Firestore는 유연한 documents, real-time sync, 그리고 단순한 querying를 제공하는 모바일/웹 앱 백엔드를 위한 document database(NoSQL)입니다. 트랜잭션을 지원하긴 하지만 relational database가 아니며 PostgreSQL 호환 SQL, joins, 또는 동일한 schema/constraint 모델을 제공하지 않습니다. PostgreSQL billing 시스템을 Firestore로 옮기려면 데이터 모델링과 애플리케이션 로직을 재고해야 하며, 이는 다음 분기에는 허용되지 않습니다.

Authorized views는 다른 프로젝트에 데이터의 일부(row/column filtering)를 안전하게 노출할 수 있지만, 가장 셀프서비스적인 discovery 메커니즘은 아닙니다. 이 규모(10개 프로젝트에 걸친 5개 부서)에서는 일반적으로 소비자 컨텍스트별로 view와 IAM binding을 생성/관리해야 하므로 관리 오버헤드가 증가합니다. 이는 광범위한 공유와 discovery가 주된 목표일 때보다는 데이터 최소화를 강제해야 할 때 더 적합합니다.

개별 사용자에게 view를 직접 공유하는 방식은 확장되지 않으며 운영적으로 취약합니다. 접근 관리는 프로젝트/부서 중심이 아니라 사용자 중심이 되어 오구성 위험과 지속적인 유지보수(온보딩/오프보딩, 역할 변경)를 증가시킵니다. 또한 여러 소비자 프로젝트에 걸친 구조화된 discovery/subscription 경험을 제공하지 않으므로, 엔터프라이즈 거버넌스 및 least-privilege 모범 사례와의 정합성이 떨어집니다.

BigQuery Data Transfer Service는 일정에 따라 telemetry dataset을 각 부서의 프로젝트로 복사합니다. 이는 복사 생성을 피하라는 요구사항을 위반하며, 중복 스토리지와 잠재적으로 중복 처리로 인해 비용을 증가시킵니다. 또한 운영 오버헤드(전송 모니터링, 실패 처리, 스키마 변경)를 추가하고, 복사본 간 데이터 최신성/일관성 문제를 유발할 수 있습니다.

공유 네트워크 파일에 기록하고 Hadoop을 실행하는 것은 지연 시간이 큰(수 분 이상) 배치 패턴으로, end-to-end <2초에는 적합하지 않습니다. 또한 리전 간 공유 스토리지에 대한 경합과 운영 복잡성을 유발합니다. Hadoop job은 연속적이고 저지연의 이벤트 단위 정합성(reconciliation)을 위해 설계되지 않았고, 거의 실시간으로 out-of-order 이벤트를 처리하는 것은 번거롭고 비용이 많이 듭니다.

Pub/Sub 수집은 좋지만, Cloud SQL에 쓰는 커스텀 HTTPS endpoint로의 push subscription은 3,333 events/sec 지속 처리에 부적합합니다. Cloud SQL은 connection 및 write 처리량 한계가 있는 OLTP 데이터베이스이므로 병목, hot row(rideId), 확장 문제에 부딪힐 가능성이 큽니다. Push 전달 재시도는 중복을 유발할 수 있어 세심한 idempotency가 필요하며, 커스텀 endpoint는 가용성과 지연 시간 측면의 리스크가 됩니다.

리전별 MySQL 데이터베이스와 주기적 query는 본질적으로 polling/배치 병합 접근으로, <2초 지연 시간을 충족할 수 없고 전역 일관성을 복잡하게 만듭니다. 리전 간 정합성(reconciliation)은 replication lag와 운영 오버헤드를 추가하며, 여전히 out-of-order 이벤트와 충돌을 처리해야 합니다. 이 설계는 장애 지점을 늘리고(여러 데이터베이스) 확장 가능한 스트리밍 집계 메커니즘을 제공하지 못합니다.

오답입니다. service_id#timestamp 형태의 row key는 각 service의 log를 함께 묶어 주지만, 일반적인 ascending timestamp에서는 최신 row가 해당 service의 key range 시작이 아니라 끝에 위치합니다. 최신 entry를 가져오려면 application이 range scan과 reverse-read 동작 또는 prefix 내 마지막 row를 찾는 logic을 사용해야 하므로, 가능한 가장 단순한 query가 아닙니다. 이 설계도 사용할 수는 있지만, service별 table에 reverse timestamp를 사용하는 방식만큼 정확한 access pattern에 직접적으로 최적화되지는 않습니다.

오답입니다. single shared table에서 reverse timestamp만 사용하면 전체 기준 최신 row가 먼저 나타나지만, row key에 service identity가 포함되지 않습니다. 그 결과 특정 microservice의 최신 row를 찾으려면 일치하는 service를 찾을 때까지 row를 scan하고 filtering해야 하므로 비효율적이며 scale이 커질수록 결정적인 방식도 아닙니다. 이 schema는 service별 최신성이 아니라 전체 최신성에 최적화되어 있습니다.

오답입니다. service별로 별도의 table을 두면 각 microservice의 data는 분리되지만, 일반 timestamp row key는 오래된 row를 먼저, 최신 row를 나중에 정렬합니다. 즉, 최신 log entry를 단순히 첫 번째 row를 읽는 방식으로 바로 가져올 수 없고, 대신 keyspace의 끝에서 읽거나 더 복잡한 scan logic을 사용해야 합니다. 또한 각 table 내에서 monotonically increasing key가 가지는 write concentration 문제도 그대로 남습니다.

오답. on_retry_callback은 task 시도가 실패하고 retry가 예약될 때(예: 상태가 UP_FOR_RETRY로 전이) 호출됩니다. retries=3이면 retry 이벤트마다 알림이 생성되며, 이는 요구사항에서 명시적으로 금지합니다. 이 선택지는 retry와 관련 있어 보이지만, 너무 이르고 너무 자주 알림을 보내 noise를 증가시키는 흔한 함정입니다.

오답. sla_missed metric으로 alerting하는 것은 종단 task failure가 아니라 SLA miss(타이밍 위반)를 대상으로 합니다. task는 SLA를 miss하더라도 나중에 성공할 수 있고, SLA miss는 scheduler delay나 upstream dependency의 영향을 받을 수 있습니다. 문제에서 SLA miss에는 알리지 말라고 명시하므로 요구사항을 충족하지 못합니다.

오답. sla_miss_callback은 task(또는 DAG)가 구성된 SLA 시간을 초과할 때, 최종적으로 성공/실패하는지와 무관하게 트리거됩니다. 요구사항은 SLA miss 알림을 피하고 retry 이후의 최종 실패에만 집중하라고 하므로, 이 callback은 잘못된 트리거 조건입니다.

오답입니다. Dataflow가 자체 리소스(예: temp storage)에 대해 CMEK를 사용하도록 구성되어 있더라도, 기존 Pub/Sub topic은 여전히 Google-managed encryption으로 message를 at rest로 저장하고, 기존 BigQuery table도 Google-managed key로 암호화된 상태로 남습니다. 기존 table에 write한다고 해서 해당 table의 encryption이 바뀌지는 않습니다. 이는 pipeline의 모든 at-rest 데이터가 중앙화된 CMEK를 사용해야 한다는 요구사항을 충족하지 못합니다.

BigQuery 측면은 일부 다루지만 여전히 오답입니다. 새 CMEK BigQuery table을 만들고 과거 데이터를 copy하면 BigQuery storage에 대한 CMEK는 충족할 수 있지만, 기존 Pub/Sub topic은 계속 Google-managed encryption으로 message를 at rest로 저장합니다. 정책이 pipeline의 모든 at-rest 데이터에 CMEK를 요구하므로, Pub/Sub를 변경하지 않으면 비준수입니다.

오답입니다. Pub/Sub는 CMEK로 바꾸지만 BigQuery table은 Google-managed key로 암호화된 상태로 남아 요구사항을 위반합니다. 또한 Pub/Sub BigQuery subscription은 특정 table로 write하므로, table이 CMEK여야 한다면 새 CMEK table(그리고 보통 이를 대상으로 하는 새 subscription)이 필요합니다.

Kafka Connect -> Pub/Sub -> Dataflow template -> BigQuery는 여러 구성 요소와 불필요한 추가 hop(Pub/Sub)을 더합니다. 또한 Kafka Connect(및 잠재적으로 Connect worker)를 운영하고 topic-to-subscription 매핑을 관리해야 합니다. 동작은 가능하지만, 명시된 목표를 위한 최소 아키텍처 접근이 아니며 direct KafkaIO ingestion 대비 latency/운영 오버헤드가 증가할 수 있습니다.

Kafka 트래픽을 중계하는 단일 proxy VM은 처리량 병목과 단일 장애 지점을 만들어 수평 확장 및 최소 리스크 요구사항을 위반합니다. 또한 불필요한 네트워크 hop과 운영 부담(VM lifecycle, patching, scaling, HA)을 추가합니다. Dataflow는 proxy layer 없이도 Interconnect를 통해 private하게 온프레미스 Kafka에 접근할 수 있습니다.

A와 비교하면 custom Dataflow pipeline은 더 많은 제어를 제공하지만, 여전히 Kafka Connect와 Pub/Sub가 필요하여 문제에서 요구하는 것보다 구성 요소와 hop이 증가합니다. Pub/Sub는 decoupling 및 buffering에 유용할 수 있으나, 프롬프트는 latency를 충족하면서 최소 추가 구성 요소와 최소 hop을 우선시하므로 direct KafkaIO ingestion이 더 단순하고 일반적으로 더 저지연입니다.

test split을 늘리면 평가 지표의 분산을 약간 줄일 수는 있지만, 모델 자체를 개선하지는 못합니다. 120M rows에서는 15% test set(~18M)만으로도 이미 매우 커서 안정적인 추정치를 제공합니다. 또한 test set을 더 크게 만들면 training data가 줄어들어 training에 더 불리할 수 있으며, training RMSE가 비정상적으로 높은 이유를 해결하지 못합니다.

더 많은 데이터는 모델이 overfitting(높은 variance)일 때 또는 training set이 너무 작을 때 도움이 될 수 있습니다. 여기서는 라벨된 120M examples가 이미 방대하며, 증상은 variance가 아니라 training set을 맞추지 못하는 것(높은 training RMSE)입니다. 80M examples를 추가로 수집하는 것은 비용과 시간이 많이 들고, underfitting이나 과도하게 제약된 training dynamics를 직접적으로 해결하지 못합니다.

더 강한 regularization은 overfitting을 완화하기 위해 사용되며, overfitting은 보통 training error가 매우 낮고 test error가 더 높게 나타납니다. 이 시나리오에서는 training RMSE가 test RMSE보다 더 나쁘므로, 모델이 training data를 잘 맞추지 못하는 것(high bias) 또는 training이 너무 일찍 중단되는 것을 시사합니다. dropout/L2를 추가하면 보통 training error가 더 증가하고 전체 성능도 악화될 가능성이 큽니다.