연습 문제

문제 1

(2개 선택)

미디어 스트리밍 스타트업이 하루에 약 3 TB의 원시 clickstream 로그를 Amazon S3에 적재하고, 선별된 집계 데이터를 Amazon Redshift RA3 cluster로 로드하며, 분석가들은 또한 AWS Glue Data Catalog에 의해 백업되는 external schema를 사용하여 Amazon Redshift Spectrum을 통해 가장 최신의 S3 데이터에 대해 낮은 지연 시간의 ad hoc query를 실행해야 합니다. 대부분의 필터가 event_date(YYYY-MM-DD)와 region에 적용되고 팀이 가장 빠른 Spectrum query 성능을 원한다면, 어떤 두 가지 조치를 취해야 합니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 AWS Glue Data Catalog를 사용하는 external schema를 통해 Amazon S3의 데이터를 직접 쿼리할 때 Amazon Redshift Spectrum 성능 최적화를 테스트합니다. Spectrum은 predicate를 S3/Glue metadata로 pushdown하고 S3 object를 스캔하며, 성능은 얼마나 많은 데이터를 읽어야 하는지와 얼마나 효율적으로 읽을 수 있는지에 의해 좌우됩니다. 정답이 맞는 이유: (B) S3 데이터를 columnar format(Parquet/ORC)으로 변환하는 것은 Spectrum에 대한 가장 영향이 큰 최적화 중 하나입니다. Columnar format은 데이터를 column 단위로 저장하고 통계(예: row group별 min/max)를 포함하여 predicate pushdown과 관련 없는 block을 건너뛰는 것을 가능하게 합니다. 일반적인 ad hoc analytics가 일부 column을 선택하고 event_date/region으로 필터링하는 경우, Spectrum은 row-based text format보다 훨씬 적은 byte를 읽습니다. (C) event_date와 region으로 partitioning하면 물리적 레이아웃과 Glue partition metadata가 가장 일반적인 WHERE predicate와 정렬됩니다. Spectrum은 Glue catalog를 사용해 partition을 pruning하여, 매칭되지 않는 partition의 object를 스캔하지 않고도 전체 partition을 제외할 수 있으므로, “가장 최신 데이터” 쿼리의 S3 I/O와 지연 시간을 크게 줄입니다. 주요 AWS 기능 / 모범 사례: - AWS Glue Data Catalog partition을 사용하는 Redshift Spectrum partition pruning. - Parquet/ORC를 통한 predicate pushdown 및 column pruning. - S3 data lake 레이아웃: Hive-style partitioning을 위한 s3://bucket/path/event_date=YYYY-MM-DD/region=.../. - small-file 문제를 피하고, 더 적고 더 큰 파일을 선호(Parquet의 경우 종종 100–1000+ MB)하여 S3 request overhead를 줄이고 scan 효율을 향상. 흔한 오해: 많은 작은 파일로 “더 많은 parallelism”을 얻으면 속도가 빨라진다고 생각하기 쉽지만, Spectrum과 S3 request overhead 때문에 작은 파일은 더 느리고 더 비쌉니다. 또 다른 함정은 CSV에 GZIP을 사용하는 것입니다. 저장되는 byte는 줄일 수 있지만, 일반적으로 non-splittable이라 효율적인 parallel read와 predicate 기반 건너뛰기를 방해하여 query latency를 악화시키는 경우가 많습니다. 시험 팁: Spectrum/Athena 스타일 엔진에서 가장 빠른 쿼리는 보통 (1) 자주 사용하는 필터 기준으로 partitioning하고 (2) splittable compression을 사용하는 columnar format을 선택할 때 나옵니다. date와 region에 대한 빈번한 필터가 보이면 해당 key로 partitioning을 선택하세요. ad hoc analytics가 일부 column만 선택하는 경우 Parquet/ORC를 선택하세요.

문제 2

미디어 분석 회사는 200개 이상의 예약된 데이터 파이프라인을 위한 워크플로 오케스트레이터가 필요합니다. 이 파이프라인은 온프레미스 Kubernetes 클러스터(워커 노드 3대, 각 32 vCPU)와 us-east-1의 AWS 계정 전반에서 실행되며, 두 위치 모두에서 동일한 오픈 소스 DAG 정의를 사용해야 하고, 벤더 종속을 피해야 하며, 하루 최소 500회 이상의 task 실행을 지원해야 합니다. 팀이 온프레미스에서는 오픈 소스 엔진을 실행하고 클라우드에서는 완전 관리형 동등 서비스를 사용할 수 있도록 채택해야 할 AWS 서비스는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 온프레미스와 완전 관리형 AWS 서비스 모두에서 실행할 수 있는 오픈 소스 DAG 엔진을 사용하여 예약된 데이터 파이프라인을 위한 워크플로 오케스트레이션을 테스트합니다. 핵심은 이식성(동일한 DAG 정의), 벤더 종속 회피, 그리고 운영 확장성입니다. 정답이 맞는 이유: Amazon Managed Workflows for Apache Airflow (MWAA)는 Apache Airflow를 위한 AWS의 완전 관리형 서비스입니다. Airflow는 오픈 소스이며 온프레미스에서 Kubernetes에 배포되는 경우가 흔합니다. Airflow DAG를 표준으로 삼으면 회사는 동일한 DAG 코드를 두 곳에서 실행할 수 있습니다: (1) 온프레미스 Kubernetes 클러스터에서 자체 관리 Airflow, (2) us-east-1의 MWAA. 이는 “두 위치에서 동일한 오픈 소스 DAG 정의” 및 “온프레미스에서 오픈 소스 엔진을 실행하고 클라우드에서 완전 관리형 동등 서비스를 실행” 요구사항을 직접 충족합니다. 또한 MWAA는 하루 500회 이상의 task 실행을 훨씬 상회하는 일반적인 엔터프라이즈 스케줄링/오케스트레이션 요구를 지원합니다. 주요 AWS 기능: MWAA는 Airflow 컨트롤 플레인(scheduler, web server, workers)을 관리하고 IAM, VPC 네트워킹, CloudWatch logs/metrics, DAG/plugins/requirements를 위한 S3, 암호화를 위한 KMS를 통해 AWS 서비스와 통합됩니다. 또한 워커 용량 확장(environment class/worker scaling)을 지원하고 운영 부담(패치, 업그레이드, 고가용성)을 줄여줍니다. 하이브리드 패턴에서는 팀이 종종 DAG를 공유 repo에 두고 CI/CD를 통해 온프레미스 Airflow와 MWAA의 S3 DAG bucket에 배포합니다. 흔한 오해: AWS Glue는 관리형 ETL 서비스이며 workflows/triggers를 포함하지만, 온프레미스 오케스트레이터와 “동일한 오픈 소스 엔진”이 아니고 Glue를 온프레미스에서 네이티브로 실행할 수도 없습니다. Amazon SWF는 AWS 네이티브 워크플로 서비스(Airflow 호환 아님)로 DAG 로직을 다시 작성해야 하므로 종속성이 증가합니다. AWS Data Exchange는 서드파티 데이터셋 구독을 위한 서비스이지 오케스트레이션이 아닙니다. 시험 팁: “DAGs”, “Airflow”, “avoid vendor lock-in”, “managed equivalent in AWS”가 보이면 MWAA를 떠올리세요. 문제가 오케스트레이션 코드의 하이브리드 이식성을 강조한다면, 리팩터링이 필요한 AWS 네이티브 워크플로 엔진보다 오픈 소스 호환 관리형 서비스를 우선하세요.

문제 3

미디어 분석 스타트업이 온프레미스 Oracle 12c 데이터베이스를 1 Gbps Direct Connect 링크를 통해 AWS에 연결해 운영하고 있으며, 데이터 엔지니어는 JDBC를 통해 특정 테이블(~5천만 행, 30개 컬럼)을 크롤링하여 스키마를 카탈로그화한 다음, 데이터를 추출, 변환, 적재하여 Amazon S3 버킷에 파티셔닝된 Parquet(Snappy)로 매일 01:00 UTC 일정에 맞춰 저장해야 합니다. 또한 비용을 낮게 유지하기 위해 관리형 서비스 오버헤드를 최소화하면서 엔드투엔드 파이프라인을 오케스트레이션해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 AWS 서비스 또는 기능은 무엇입니까?

문제 분석

핵심 개념: 요구 사항은 JDBC를 통해 온프레미스 Oracle 테이블을 크롤링하고, 스키마를 카탈로그화하고, 데이터를 변환한 뒤, 이를 partitioned Parquet 형식으로 Amazon S3에 적재하는 일일 ETL 파이프라인을 위한 낮은 오버헤드와 비용 효율적인 orchestration 메커니즘입니다. 이 파이프라인은 Glue crawler 및 Glue ETL job과 같은 AWS Glue 구성 요소를 중심으로 자연스럽게 구성되므로, 가장 적절한 orchestration 기능은 AWS Glue workflows입니다. 정답인 이유: AWS Glue workflows는 Glue crawlers, Glue jobs, 그리고 triggers를 관리형 serverless 방식으로 orchestration하도록 특별히 설계되었습니다. 하루 한 번 실행되는 ETL 프로세스의 경우, Glue workflows는 별도의 orchestration 플랫폼 없이도 기본적인 dependency 처리, scheduling, retries, 그리고 status tracking을 제공합니다. 따라서 파이프라인이 이미 JDBC ingestion 및 스키마 cataloging을 위해 Glue를 중심으로 구축되어 있을 때 운영 오버헤드와 비용을 모두 낮게 유지할 수 있습니다. 주요 기능: Glue workflows는 crawler와 ETL job을 함께 연결할 수 있고, scheduled 또는 conditional triggers를 사용할 수 있으며, AWS Glue Data Catalog와 직접 통합됩니다. Glue는 Direct Connect를 통해 온프레미스 Oracle 데이터베이스에 대한 JDBC connections를 지원하고, Glue jobs는 Snappy compression이 적용된 partitioned Parquet를 S3에 쓸 수 있습니다. 따라서 Glue workflows는 추가 orchestration 서비스를 도입하는 대신 전체 파이프라인에 일관되게 잘 맞는 선택입니다. 흔한 오해: Step Functions는 강력한 범용 orchestrator이지만, 워크플로가 주로 Glue-native이고 crawler와 ETL job orchestration이 필요한 경우에는 가장 자연스럽거나 비용 효율적인 답은 아닙니다. Glue Studio는 시각적 authoring 인터페이스일 뿐이며, orchestration 메커니즘 자체는 아닙니다. MWAA는 단순한 일일 관리형 ETL 파이프라인에 비해 운영 부담과 비용이 훨씬 큽니다. 시험 팁: 문제에서 데이터 소스 크롤링, 스키마 cataloging, JDBC ingestion, 그리고 S3로의 ETL을 명시적으로 언급하면 먼저 AWS Glue를 떠올리세요. orchestration이 주로 Glue-native 구성 요소 간에 이루어진다면, 보통 Glue workflows가 가장 좋은 답입니다. Step Functions는 Glue가 더 큰 orchestration 패턴의 한 부분일 뿐인 더 광범위한 multi-service 워크플로에 사용하도록 구분하세요.

문제 4

한 fintech 회사가 결제 이벤트 로그를 12개 shard가 있는 Amazon Kinesis Data Streams data stream으로 스트리밍하고 있습니다. 각 record는 2 KB이며 producer는 전체적으로 초당 약 5,000개의 record를 전송하지만, CloudWatch에서는 두 개 shard가 95% write utilization을 보이는 반면 다른 shard들은 10% 미만입니다. 또한 해당 hot shard들에 대해 PutRecords 호출이 ProvisionedThroughputExceeded를 반환합니다. Producer는 현재 merchantId를 partition key로 사용하고 있으며, flash sale 동안 단일 merchant가 이벤트의 약 70%를 생성하여 stream의 aggregate limit 미만의 총 throughput임에도 hot shard가 발생합니다. 동일한 전체 throughput을 유지하면서 throttling을 제거하려면 data engineer는 어떻게 해야 합니까?

문제 분석

핵심 개념: 이 문제는 Amazon Kinesis Data Streams의 shard 단위 throughput과 partition key가 shard 할당을 어떻게 결정하는지 테스트합니다. 각 record는 partition key를 hashing하여 shard로 라우팅되므로, key 분포가 불균등하면 stream의 총(aggregate) capacity가 충분하더라도 “hot shard”가 발생합니다. 정답이 맞는 이유: 12개 shard가 있는 stream은 aggregate write capacity가 충분하지만, 한 merchant가 이벤트의 ~70%를 생성합니다. Producer가 merchantId를 partition key로 사용하기 때문에 대부분의 record가 동일한 shard(들)로 hash되어 해당 shard의 write utilization이 ~95%까지 올라가 ProvisionedThroughputExceeded가 발생합니다. 해결책은 hot merchant의 이벤트가 여러 shard로 퍼지도록 partition-key cardinality를 높이는 것입니다. 일반적인 패턴은 논리적 grouping을 위해 merchantId를 유지하되 random 또는 deterministic suffix(예: merchantId + “-” + (hash(eventId) % 128))를 추가하여 record가 shard 전반에 분산되도록 하면서 동일한 전체 throughput을 유지하는 것입니다. 주요 AWS 기능: Kinesis Data Streams는 shard당 limit(일반적으로 write 기준 1 MB/s 또는 1,000 records/s)를 강제합니다. shard가 어느 limit이든 초과하면 PutRecords가 throttling됩니다. Partition key가 분산을 제어하며, Kinesis는 hot key를 shard 간에 자동으로 rebalance하지 않습니다. 기법으로는 random suffix 추가, 더 높은 cardinality key(eventId) 사용, 또는(적절한 경우) explicit hash key 사용으로 라우팅을 제어하는 방법이 있습니다. 흔한 오해: “shard만 추가하면 된다”(옵션 B)고 생각하기 쉽습니다. 하지만 partition key가 merchantId로 그대로라면 hot merchant는 여전히 제한된 일부 shard로 hash되며, resharding은 총 capacity를 늘릴 뿐 hot key가 분산된다는 보장은 없습니다. 또 다른 오해는 record 크기를 줄이면(옵션 D) throttling이 해결된다는 것입니다. 그러나 hot shard는 MB/s가 충분하더라도 records/s limit(1,000 records/s)에 걸릴 수 있습니다. Producer를 throttling하는 것(옵션 C)은 throughput을 낮추므로 요구사항을 만족하지 못합니다. 시험 팁: 일부 shard만 hot이고 나머지가 idle이면 partition-key skew를 의심해야 합니다. 올바른 해결책은 shard scaling보다는 거의 항상 partition key 전략 변경(cardinality 증가 / salting 추가)입니다. 또한 shard limit 두 가지(MB/s와 records/s)를 모두 확인하세요. 작은 record는 종종 records/s limit에 먼저 도달합니다.

문제 5

미디어 플랫폼이 PostgreSQL database에 저장된 재생 로그를 분석해야 합니다. 회사는 Zendesk에서 추적되는 고객 이슈와 로그를 상관 분석하려고 합니다. 회사는 매일 2 GB의 새로운 재생 로그를 수신합니다. 회사는 100 GB의 과거 Zendesk 티켓을 보유하고 있습니다. 데이터 엔지니어는 로그와 티켓을 분석하고 상관 분석하는 프로세스를 개발해야 합니다. 프로세스는 매일 밤 한 번 실행되어야 합니다. 가장 적은 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 매일 밤 실행되는 상관 분석 작업을 위한, 운영 부담이 가장 낮은 serverless 배치 수집 + ETL/오케스트레이션 패턴을 선택하는지를 평가합니다. 여기서의 주요 managed services는 Amazon AppFlow(SaaS 수집), AWS Glue(managed Spark ETL 및 JDBC 수집), AWS Step Functions(serverless 오케스트레이션)입니다. 정답이 맞는 이유: 옵션 C는 운영해야 할 인프라를 최소화하는 목적 특화 managed services를 사용합니다. AppFlow는 Zendesk에 기본적으로 연결되며, 스케줄에 따라 100 GB의 과거 티켓(이후에는 증분 업데이트)을 Amazon S3로 적재할 수 있습니다. AWS Glue는 JDBC를 통해 PostgreSQL에서 재생 로그를 추출할 수 있으며(일반적으로 DB가 위치한 VPC/subnet/security group에 대한 Glue connection 사용), Zendesk 데이터세트와의 상관 분석 조인을 수행하고 정제된 결과를 S3(또는 warehouse)로 기록할 수 있습니다. Step Functions는 야간 실행을 오케스트레이션합니다: AppFlow 트리거(또는 AppFlow 스케줄링에 의존), Glue job 시작, 재시도/타임아웃 처리, 성공/실패 알림 게시. 주요 AWS 기능: - Amazon AppFlow: managed SaaS 수집, 스케줄링, (지원되는 경우) 증분 pull, S3로 직접 전달; 커스텀 API 코드 필요를 줄임. - AWS Glue: managed ETL, Glue Data Catalog, 증분 처리를 위한 job bookmarks(2 GB/일 로그에 유용), 데이터세트 상관 분석을 위한 확장 가능한 Spark join. - Step Functions: 내장 재시도, 오류 처리, service integrations를 갖춘 serverless workflow; Airflow environment를 운영하는 것보다 운영 부담이 낮음. 흔한 오해: - Airflow(MWAA)는 “managed”이지만 여전히 environment sizing, dependency 관리, DAG 운영, 지속적인 튜닝이 필요하며, 단순한 야간 파이프라인에서는 Step Functions보다 오버헤드가 더 큰 경우가 많습니다. - Kinesis/Flink는 streaming 상관 분석에 매력적이지만, 요구 사항은 1일 1회 야간 배치입니다. streaming은 불필요한 복잡성과 비용을 추가합니다. 시험 팁: “least operational overhead”와 단순한 스케줄 기반 workflow가 보이면, 완전한 serverless 오케스트레이션(Step Functions)과 managed 수집/ETL(AppFlow/Glue)을 우선 고려하십시오. MWAA는 복잡한 DAG 생태계, 많은 task/operator, 또는 Airflow 고유 기능이 필요한 경우에 사용하십시오. 워크로드가 명시적으로 배치인 경우 streaming services는 피하십시오. (참고: AWS Well-Architected Framework—Operational Excellence pillar; Amazon AppFlow, AWS Glue, AWS Step Functions의 managed integrations 및 오케스트레이션 관련 서비스 문서.)

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

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

문제 6

미디어 스트리밍 분석 팀은 Amazon Redshift Serverless(워크그룹: us-east-1의 prod-analytics)에서 클릭스트림 스키마 위에 9개의 materialized view를 사용하고 있으며, 어떤 오케스트레이션 인프라도 프로비저닝하거나 관리하지 않고 08:00~20:00 UTC 사이에 30분마다 9개 뷰 모두에 대해 REFRESH MATERIALIZED VIEW를 실행하는 스케줄을 자동화해야 합니다. 최소한의 노력으로 이 요구 사항을 충족하는 접근 방식은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Amazon Redshift Serverless의 “serverless 운영”을 테스트합니다. 특히 오케스트레이션 인프라를 구축하거나 관리하지 않고 반복적인 SQL 유지보수(REFRESH MATERIALIZED VIEW)를 스케줄링하는 방법을 묻습니다. 또한 운영 자동화와 최소 노력의 관리형 도구 선택도 다룹니다. 정답이 맞는 이유: Amazon Redshift Query Editor v2는 Redshift 워크그룹에 대해 SQL을 작성, 저장, 실행할 수 있는 관리형 콘솔 기반 방식이며 쿼리 스케줄링을 지원합니다. 9개의 materialized view 모두에 대해 REFRESH MATERIALIZED VIEW를 실행하는 스크립트를 저장하고(30분마다) 반복 스케줄과 활성 시간대(08:00–20:00 UTC)를 연결하면, 어떤 오케스트레이션 플랫폼도 프로비저닝하지 않고 요구 사항을 충족할 수 있습니다. 이는 Redshift에 내장된 도구를 사용하고 추가 서비스, 네트워킹, 워커, DAG/Job 관리가 필요 없으므로 “최소 노력”에 부합합니다. 주요 AWS 기능: - Redshift Query Editor v2: Redshift(Serverless 포함)를 위한 관리형 SQL 편집기이며 저장된 쿼리와 스케줄링을 제공. - Scheduled query execution: 일정 주기로 SQL을 실행; 필요 시 08:00–20:00 UTC 윈도우는 해당 시간대 내 스케줄링(또는 필요하면 SQL에 시간 가드 추가)으로 구현 가능. - Redshift materialized views: 분석 워크로드에서 사전 계산된 결과를 최신으로 유지하기 위한 올바른 명령은 REFRESH MATERIALIZED VIEW. 흔한 오해: - “어떤 스케줄러든 된다”: MWAA, Glue, Lambda도 스케줄링은 가능하지만 추가 인프라, 권한, 운영 오버헤드를 유발하여 요구 사항과 상충합니다. - “Lambda UDF 타이머”: Redshift UDF는 네이티브 시간 기반 트리거를 제공하지 않으며, 스케줄링은 외부 오케스트레이터에서 와야 합니다. 시험 팁: “오케스트레이션 인프라를 프로비저닝하거나 관리하지 않고” 그리고 작업이 “스케줄에 따라 SQL 실행”이라면, MWAA나 Glue 같은 무거운 오케스트레이션 옵션을 고르기 전에 데이터 서비스 자체 또는 관리형 UI의 네이티브 스케줄링 기능(예: Redshift Query Editor v2 scheduled queries)을 먼저 찾으십시오. 타이밍 및 운영 제약을 직접 만족하는 가장 단순한 관리형 기능을 선호하십시오.

문제 7

한 여행-테크 회사가 여러 레거시 시스템의 예약 및 고객 지원 데이터셋을 Amazon S3 데이터 레이크로 통합하고 있다. 한 엔지니어가 과거 내보내기 데이터(주당 약 3 TB의 CSV 및 JSON, 약 1억 2천만 행)를 검토한 결과, 많은 예약 및 고객 프로필이 시스템 전반에 걸쳐 중복되어 있음을 발견했다. 엔지니어는 curated zone에 게시하기 전에 중복 정보를 식별하고 제거해야 하며, 운영 오버헤드를 최소화하고 자동으로 확장되며 서버 또는 third-party library를 관리하지 않는 솔루션을 원한다. 다음 중 이러한 요구 사항을 가장 적은 운영 오버헤드로 충족하는 접근 방식은 무엇인가?

문제 분석

핵심 개념: 이 문제는 운영 오버헤드를 최소화하면서 S3 기반 데이터 레이크에서 서버리스로 데이터 중복 제거를 수행하는지를 평가한다. 핵심 AWS 서비스는 AWS Glue(서버리스 Spark)이며, 특히 엔터티 해석(entity resolution)을 위한 AWS Glue ML Transform인 “FindMatches”(정확히 일치하지 않을 수 있는 레코드의 중복 제거)이다. 정답이 맞는 이유: 옵션 B는 AWS Glue FindMatches가 서버, Spark cluster 또는 third-party library를 관리할 필요 없이 machine learning을 사용해 데이터셋 전반의 중복 레코드를 식별하도록 설계된 managed capability이므로 가장 운영 부담이 적다. 이는 Glue의 서버리스 실행 모델로 확장되며, 중복이 정확 일치 또는 “fuzzy”(예: 이름 변형, 주소 포맷 차이, 레거시 시스템 간 서로 다른 ID)일 수 있는 대규모 주간 배치(3 TB, 약 1억 2천만 행)에 적합하다. 라벨링된 예제로 transform을 학습시킨 뒤, Glue ETL job의 일부로 실행하여 S3에 중복 제거된 curated dataset을 생성할 수 있다. 주요 AWS 기능: - AWS Glue ETL jobs: 자동 확장과 managed infrastructure를 제공하는 서버리스 Apache Spark. - Glue ML Transforms (FindMatches): 내장 엔터티 매칭/중복 제거 기능; Glue Studio/Jobs에 통합. - S3 data lake zones: raw에서 curated로의 패턴; Glue Data Catalog가 schema/partition을 추적할 수 있음. - 운영 단순성: dependency packaging 불필요, cluster lifecycle 관리 불필요, IAM 및 CloudWatch logs/metrics와의 네이티브 통합. 흔한 오해: Pandas 기반 중복 제거(옵션 A)는 단순해 보이지만, 일반적으로 compute(EC2/ECS/EKS/EMR)를 프로비저닝하고 운영해야 하며 3 TB/1억 2천만 행 규모에서 신중한 분산 설계 없이는 잘 확장되지 않는다. third-party “dedupe” library 옵션(C/D)은 강력한 확률적 매칭을 제공할 수 있지만, dependency 관리, 패키징, 버전 관리, 트러블슈팅 오버헤드를 유발하며, 이는 third-party library를 피하라는 요구 사항에 의해 명시적으로 배제된다. 시험 팁: “운영 오버헤드 최소화”, “자동 확장”, “서버 관리 회피”, “third-party library 없음”을 보면 managed/serverless AWS-native 기능을 우선 고려하라. Glue에서 중복 제거/엔터티 해석에는 커스텀 Python이나 외부 라이브러리보다 “FindMatches”가 시험에서 선호되는 선택지다. 또한 단순한 키 기반의 exact dedup과 레거시 시스템 간의 fuzzy matching의 차이를 구분하라—FindMatches는 후자를 위해 목적에 맞게 설계되었다.

문제 8

도시 모빌리티 기업이 도시 교통 카메라에서 초당 8,000개의 센서 이벤트를 Amazon Kinesis Data Streams로 수집하고, 운영 오버헤드를 최소화하면서 최대 30분의 event-time window에 대해 여러 집계를 수행하고 최대 90초의 late arrival을 허용하는 고가용성(높은 fault tolerance) 근실시간(near-real-time) 분석 솔루션이 필요하다. 데이터 엔지니어는 어떤 접근 방식을 선택해야 하는가?

문제 분석

핵심 개념: 이 문제는 Amazon Kinesis Data Streams에 대해 event-time windowing, late-arriving data 처리, 그리고 낮은 운영 오버헤드를 요구하는 근실시간 스트림 처리/분석 서비스 선택을 평가한다. 핵심 서비스는 Amazon Managed Service for Apache Flink(이전 명칭: Kinesis Data Analytics for Apache Flink)로, 견고한 window semantics를 갖춘 stateful stream processing을 제공한다. 정답이 맞는 이유: 요구사항에는 최대 30분의 event-time window에 대한 여러 집계와 최대 90초의 late arrival 허용이 포함된다. 이는 Flink의 event-time processing, watermark, managed state로 가장 잘 처리되는 전형적인 stateful stream processing 요구사항이다. Amazon Managed Service for Apache Flink는 Kinesis Data Streams와 직접 통합되며(적절한 checkpointing과 sink 구성 시) exactly-once processing을 지원하고, 낮은 latency로 여러 집계를 지속적으로 계산할 수 있다. 또한 checkpoint와 state recovery를 통해 고가용성과 fault tolerance를 제공하도록 설계되어 “highly fault-tolerant” 요구사항을 충족하며, self-managed framework 대비 운영 오버헤드를 최소화한다. 주요 AWS 기능: - out-of-order/late event를 처리하기 위한 event-time windowing과 watermark(예: lateness 약 90초 허용). - Amazon S3로의 durable checkpoint와 fault tolerance를 위한 automatic recovery를 갖춘 stateful processing. - ops를 줄이기 위한 autoscaling/managed runtime(patching, provisioning, CloudWatch와의 monitoring 통합). - Kinesis Data Streams source 및 일반적인 sink(예: Kinesis, OpenSearch, S3, DynamoDB)를 위한 native connector. 흔한 오해: Lambda는 단순한 streaming transform은 가능하지만, late arrival이 있는 긴(30분) stateful aggregation에는 적합하지 않다. state를 외부(DynamoDB/ElastiCache)로 분리하고, windowing 로직을 구현하며, retry/duplicate를 처리하고, 정확성을 관리해야 하므로 복잡성과 운영 부담이 증가한다. 또한 Lambda의 event source mapping과 batching은 진정한 event-time semantics 및 watermark 기반 window 완료를 대체할 수 없다. 시험 팁: “event-time windows”, “late arrivals”, “multiple aggregations”, “fault-tolerant stateful analytics”가 보이면 Lambda보다는 (managed) Apache Flink를 떠올려라. Lambda는 stateless 또는 short-lived processing에 적합하고, Flink는 windowing과 out-of-order data 처리를 포함한 복잡하고 장시간 실행되는 stateful stream analytics에 적합하다.

문제 9

게임 분석 회사가 콘솔 클라이언트, 전용 게임 서버, 치트 방지 센서에서 실시간 게임플레이 텔레메트리를 Amazon Kinesis Data Streams로 스트리밍하고 있습니다. 평균 12 MB/s이며 6개 shard 전반에서 최대 30 MB/s까지 피크가 발생합니다. 데이터 엔지니어는 이 스트리밍 피드를 처리하여 분석을 위해 Amazon Redshift Serverless workgroup에 적재해야 합니다. 대시보드는 sub-60-second 최신성으로 준실시간 인사이트를 제공해야 하며, 동시에 전날 데이터와 조인해야 하고, 솔루션은 운영 오버헤드를 최소화해야 합니다. 가장 적은 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Amazon Kinesis Data Streams의 데이터를 Amazon Redshift Serverless에서 60초 미만의 최신성으로 분석하는 가장 운영 부담이 낮은 방법을 선택하는 것에 관한 것입니다. Amazon Redshift streaming ingestion은 Redshift가 Kinesis Data Streams에서 직접 읽고 매우 낮은 지연 시간으로 SQL 분석에 사용할 수 있도록 하는 네이티브 기능입니다. 정답인 이유: Redshift streaming ingestion은 중간 전달 서비스, 커스텀 consumer 또는 예약된 batch load 없이 Amazon Kinesis Data Streams의 데이터를 거의 실시간으로 분석하도록 특별히 설계되었습니다. 실제로 Redshift는 Kinesis stream 위에 materialized view를 생성할 수 있으므로 dashboard가 최신 event를 조회하고, 이전 날짜의 telemetry와 같이 이미 Redshift에 저장된 과거 데이터와 조인할 수 있습니다. 이는 최신성 요구 사항과 운영 오버헤드를 최소화해야 한다는 요구를 모두 충족합니다. 주요 AWS 기능 / 구성: - Amazon Kinesis Data Streams의 Amazon Redshift streaming ingestion은 Redshift 내부에서 stream 데이터에 대한 네이티브한 저지연 액세스를 제공합니다. - Amazon Redshift Serverless는 cluster sizing, patching, capacity planning과 같은 인프라 관리 작업을 제거합니다. - streaming source에 대한 materialized view를 사용하면 최신 event에 대해 SQL query를 수행할 수 있으며, 거의 실시간 가시성을 위해 refresh할 수 있습니다. - 과거 데이터는 표준 Redshift table에 유지할 수 있으며, 결합된 분석을 위해 streaming materialized view와 조인할 수 있습니다. 일반적인 오해: Kinesis Data Firehose에서 Redshift로의 전송은 종종 가장 운영 부담이 낮은 streaming 옵션으로 오해되지만, Firehose는 buffered delivery와 S3 staging, 그리고 COPY를 통해 Redshift로 전달하므로 진정한 저지연 streaming ingestion이라기보다 micro-batch 패턴에 가깝습니다. S3와 COPY 조합은 훨씬 더 batch 지향적이며 더 많은 orchestration이 필요합니다. Aurora zero-ETL은 Aurora가 source system인 경우에만 적용되며, 여기서는 해당되지 않습니다. 시험 팁: source가 Kinesis Data Streams이고 target이 Redshift이며 최신성 요구 사항이 1분 미만이라면 Redshift streaming ingestion을 우선 고려하세요. buffered delivery가 허용될 때는 Firehose를 선택하고, S3에서 batch loading할 때는 COPY를 선택하며, zero-ETL은 Aurora-to-Redshift replication 시나리오에서만 선택하세요.

문제 10

데이터 엔지니어가 계정 111111111111(us-west-2)의 analytics-bus에서 trigger-etl이라는 사용자 지정 Amazon EventBridge 규칙을 구성하여 rate(5 minutes) 스케줄로 AWS Lambda 함수 arn:aws:lambda:us-west-2:111111111111:function:etl-summarizer-v2 를 호출하도록 했지만, 테스트 이벤트를 전송하면 대상 호출이 Lambda의 AccessDeniedException으로 실패합니다. 엔지니어는 이 예외를 어떻게 해결해야 합니까?

문제 분석

핵심 개념: 이 문제는 Amazon EventBridge가 AWS Lambda function을 invoke하도록 어떻게 권한이 부여되는지를 테스트합니다. Lambda target의 경우, EventBridge는 Lambda execution role을 사용하지 않으며, 일반적으로 Lambda를 호출하기 위해 별도의 target IAM role도 필요하지 않습니다. 대신, Lambda에는 EventBridge service principal(events.amazonaws.com)에 function invoke 권한을 부여하는 resource-based policy가 있어야 하며, 보통 SourceArn을 통해 특정 EventBridge rule ARN으로 범위가 제한됩니다. 정답인 이유: EventBridge target invocation 중 Lambda에서 발생하는 AccessDeniedException은 function policy가 해당 EventBridge rule의 function invoke를 허용하지 않아 Lambda가 invoke 요청을 거부했음을 의미합니다. 해결 방법은 Principal을 events.amazonaws.com으로, SourceArn을 analytics-bus의 trigger-etl rule ARN으로 설정한 lambda:AddPermission과 같은 Lambda permission statement를 추가하거나 수정하는 것입니다. 이것이 동일한 account 및 Region에서 EventBridge-to-Lambda integration에 대한 표준 authorization model입니다. 주요 AWS 기능: Lambda는 어떤 AWS service 또는 account가 function을 invoke할 수 있는지를 제어하는 resource-based policy를 지원합니다. Lambda를 target으로 하는 EventBridge rule은 Lambda execution role이 아니라 해당 resource policy에 의존합니다. Lambda execution role은 function이 실행될 때 필요한 권한(예: S3에서 읽기 또는 CloudWatch Logs에 쓰기)에만 사용됩니다. 일반적인 오해: 흔한 실수는 Lambda execution role 또는 그 trust policy가 누가 function을 invoke할 수 있는지를 제어한다고 생각하는 것입니다. 또 다른 오해는 EventBridge가 모든 target type에 대해 항상 target IAM role이 필요하다고 생각하는 것입니다. Lambda의 경우 핵심 요구 사항은 Lambda resource-based permission입니다. VPC 배치나 schema registry configuration과 같은 network 설정은 invocation에 대한 Lambda AccessDeniedException 오류를 발생시키지 않습니다. 시험 팁: 하나의 AWS service가 Lambda를 invoke할 때는 먼저 Lambda resource-based policy를 확인하세요. 오류가 명시적으로 Lambda의 AccessDeniedException이라고 말한다면, event pattern, schema, 또는 VPC networking보다 invoke permission에 집중하세요. 또한 해당 permission이 올바른 rule ARN, account, Region, 그리고 해당되는 경우 올바른 function version 또는 alias로 범위 지정되었는지도 확인하세요.

Practice Test #2

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(8)

다른 모의고사

Practice Test #1

지금 학습 시작하기