
65개 문제와 130분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
미디어 스트리밍 스타트업이 하루에 약 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 성능을 원한다면, 어떤 두 가지 조치를 취해야 합니까? (두 개 선택)
오답입니다. GZIP은 저장 및 전송 크기를 줄일 수 있지만, Spectrum에서는 핵심이 scan 효율과 parallelism입니다. GZIP으로 압축된 text 파일은 일반적으로 non-splittable이어서 parallel read를 제한하고 지연 시간을 증가시킵니다. 또한 파일당 1–5 GB는 최적의 parallelism과 복구 관점에서 종종 너무 큽니다. 더 나은 선택은 splittable compression(예: Snappy)을 사용하는 columnar Parquet/ORC와 적절한 파일 크기입니다.
정답입니다. Parquet/ORC는 columnar format으로, column pruning(참조된 column만 읽기)과 embedded statistics를 활용한 predicate pushdown/row-group skipping을 가능하게 합니다. 이는 Spectrum이 S3에서 스캔해야 하는 데이터 양을 줄여 지연 시간과 비용을 개선합니다. 대규모 dataset에 대해 분석 쿼리를 실행할 때 Redshift Spectrum 및 기타 S3 query engine의 표준 모범 사례입니다.
정답입니다. dataset을 event_date와 region(가장 일반적인 predicate)으로 partitioning하면 Spectrum이 Glue Data Catalog metadata를 사용해 partition을 pruning하여, 쿼리와 매칭될 수 없는 전체 S3 prefix를 건너뛸 수 있습니다. 이는 스캔되는 데이터를 수십~수백 배까지 줄일 수 있으며, 최신 S3 데이터에 대한 낮은 지연 시간의 ad hoc query를 가속하는 가장 효과적인 방법 중 하나입니다.
오답입니다. 매우 작은 파일(<10 KB)이 많으면 small-file 문제가 발생합니다: S3 request overhead 증가, 과도한 metadata 작업, 비효율적인 task scheduling. Spectrum은 파일당 오버헤드를 줄이고 처리량을 개선할 수 있기 때문에 더 적고 더 큰 파일에서 더 잘 동작합니다. Parallelism은 중요하지만, 작은 object가 아니라 적절한 크기(종종 수백 MB)의 파일과 partitioning으로 달성해야 합니다.
오답입니다. non-splittable format/codec(예: GZIP이 적용된 CSV)은 일반적으로 parallel read를 제한하고 관련 없는 데이터를 효율적으로 건너뛰지 못하게 하므로 Spectrum 성능을 저하시킵니다. compression이 저장되는 byte를 줄이더라도, Spectrum은 predicate를 평가하기 위해 파일의 큰 부분을 읽고 decompress해야 할 수 있습니다. 가장 빠른 쿼리를 위해서는 columnar, splittable format(Parquet/ORC with Snappy/ZSTD)이 선호됩니다.
핵심 개념: 이 문제는 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를 선택하세요.
미디어 분석 회사는 200개 이상의 예약된 데이터 파이프라인을 위한 워크플로 오케스트레이터가 필요합니다. 이 파이프라인은 온프레미스 Kubernetes 클러스터(워커 노드 3대, 각 32 vCPU)와 us-east-1의 AWS 계정 전반에서 실행되며, 두 위치 모두에서 동일한 오픈 소스 DAG 정의를 사용해야 하고, 벤더 종속을 피해야 하며, 하루 최소 500회 이상의 task 실행을 지원해야 합니다. 팀이 온프레미스에서는 오픈 소스 엔진을 실행하고 클라우드에서는 완전 관리형 동등 서비스를 사용할 수 있도록 채택해야 할 AWS 서비스는 무엇입니까?
AWS Data Exchange는 AWS에서 서드파티 데이터셋을 찾고, 구독하고, 사용하는 서비스입니다. 워크플로 오케스트레이션, 스케줄링, DAG 실행을 제공하지 않습니다. 데이터 파이프라인이 외부 데이터셋을 소비할 수는 있지만, Data Exchange는 오케스트레이터가 아니며 온프레미스와 관리형 클라우드 서비스에서 동일한 오픈 소스 DAG 정의를 실행하는 요구사항을 충족할 수 없습니다.
Amazon SWF는 AWS 네이티브 워크플로 조정 서비스입니다. 작업을 오케스트레이션할 수는 있지만 Apache Airflow가 아니며 Airflow DAG 정의를 사용하지 않습니다. SWF를 사용하면 워크플로 로직과 애플리케이션 통합을 재설계해야 하므로 벤더 종속이 증가합니다. 또한 공유 DAG 코드로 온프레미스 오픈 소스 DAG 엔진의 “완전 관리형 동등 서비스”를 제공하지 않습니다.
Amazon MWAA는 Apache Airflow를 위한 완전 관리형 AWS 서비스입니다. 온프레미스(Kubernetes에서 자체 관리 Airflow)와 AWS(관리형 Airflow) 전반에서 동일한 오픈 소스 DAG 정의를 유지해야 한다는 요구사항에 직접 부합합니다. MWAA는 확장, 가용성, 패치, 통합을 처리하며 S3, IAM, CloudWatch, VPC, KMS와 연동되므로 200개 이상의 예약 파이프라인과 하루 500회 이상의 task 실행에 이상적입니다.
AWS Glue는 crawlers, jobs, Glue Workflows를 갖춘 서버리스 데이터 통합(ETL/ELT) 서비스입니다. 그러나 Glue는 Apache Airflow가 아니며, 다시 작성 없이 온프레미스와 AWS에서 동일한 Airflow DAG를 실행할 수 없습니다. 또한 Glue는 온프레미스 Kubernetes 클러스터에 동일한 오픈 소스 엔진으로 배포할 수 없으므로 이식성과 종속 회피 요구사항을 충족하지 못합니다.
핵심 개념: 이 문제는 온프레미스와 완전 관리형 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 네이티브 워크플로 엔진보다 오픈 소스 호환 관리형 서비스를 우선하세요.
미디어 분석 스타트업이 온프레미스 Oracle 12c 데이터베이스를 1 Gbps Direct Connect 링크를 통해 AWS에 연결해 운영하고 있으며, 데이터 엔지니어는 JDBC를 통해 특정 테이블(~5천만 행, 30개 컬럼)을 크롤링하여 스키마를 카탈로그화한 다음, 데이터를 추출, 변환, 적재하여 Amazon S3 버킷에 파티셔닝된 Parquet(Snappy)로 매일 01:00 UTC 일정에 맞춰 저장해야 합니다. 또한 비용을 낮게 유지하기 위해 관리형 서비스 오버헤드를 최소화하면서 엔드투엔드 파이프라인을 오케스트레이션해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 AWS 서비스 또는 기능은 무엇입니까?
AWS Step Functions는 ETL 단계를 orchestration할 수 있지만, Glue 중심 파이프라인에 가장 자연스러운 기능이라기보다는 범용 workflow 서비스입니다. 이 시나리오에서는 파이프라인이 JDBC 소스 크롤링과 ETL job 실행 같은 Glue-native 기능에 이미 의존하고 있으므로, Step Functions를 추가하면 필요하지 않은 추가 orchestration 서비스를 도입하게 됩니다. Step Functions도 serverless이고 오버헤드가 낮지만, 시험 관점에서 가장 적절한 답은 워크플로가 주로 crawler에서 job으로 이어지는 순서를 다룰 때의 Glue-native orchestration 기능입니다. 따라서 Step Functions도 가능한 선택이지만, 제시된 보기 중 가장 비용 효율적이거나 직접적으로 맞는 선택은 아닙니다.
AWS Glue workflows는 AWS Glue crawlers, Glue ETL jobs, 그리고 triggers를 하나의 관리형 서비스에서 기본적으로 orchestration하기 때문에 가장 적합합니다. 문제는 스키마를 cataloging하기 위해 JDBC로 접근 가능한 Oracle 테이블을 크롤링한 다음, partitioned Parquet 형식으로 S3에 적재하는 scheduled ETL을 실행해야 한다고 명시하고 있으며, 이는 Glue crawler와 Glue job 기능에 정확히 대응됩니다. Glue workflows를 사용하면 별도의 orchestration 계층을 도입할 필요가 없어 서비스 확산과 운영 오버헤드를 모두 줄일 수 있습니다. Glue 구성 요소를 중심으로 한 일일 파이프라인에서는 일반적으로 이것이 가장 비용 효율적인 관리형 옵션입니다.
AWS Glue Studio는 Glue ETL jobs를 생성, 편집, 모니터링하기 위한 시각적 개발 인터페이스입니다. 데이터 엔지니어가 transformations를 설계하고 Glue job 코드를 생성하는 데 도움을 주지만, crawlers, jobs, 그리고 scheduled dependencies를 처음부터 끝까지 연결하는 기본 orchestration 기능은 아닙니다. 문제는 최소한의 오버헤드로 일일 일정에 따라 파이프라인을 orchestration할 서비스 또는 기능을 묻고 있으므로, Studio UI가 아니라 Glue workflows를 가리킵니다. Glue Studio를 선택하는 것은 job authoring과 workflow orchestration을 혼동한 것입니다.
Amazon MWAA는 여러 시스템 전반에서 복잡한 DAG 기반 orchestration을 위한 관리형 Apache Airflow를 제공하지만, 단일 일일 Glue 중심 ETL 파이프라인에는 보통 과도한 선택입니다. MWAA는 지속적으로 실행되는 Airflow 환경을 필요로 하므로, Glue workflows와 비교해 비용과 운영 복잡성이 모두 증가합니다. 문제는 관리형 서비스 오버헤드 최소화와 비용 통제를 강조하므로, MWAA는 적합하지 않습니다. 이는 이미 Airflow를 표준으로 사용하고 있거나 Glue-native 기능을 넘어서는 광범위한 custom orchestration이 필요한 조직에 더 적합합니다.
핵심 개념: 요구 사항은 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 워크플로에 사용하도록 구분하세요.
한 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는 어떻게 해야 합니까?
정답. Kinesis는 partition key를 hashing하여 record를 shard에 할당합니다. merchantId를 사용하면 한 merchant가 트래픽을 지배할 때 skew가 발생합니다. “salting”(random/deterministic suffix) 추가 또는 더 높은 cardinality key(예: eventId hash)로 전환하면 해당 merchant의 이벤트가 여러 shard로 분산되어 hot shard와 throttling을 제거하면서 동일한 전체 throughput을 유지할 수 있습니다.
오답. shard를 늘리면 aggregate capacity는 증가하지만 partition-key skew를 본질적으로 해결하지는 못합니다. merchantId가 partition key로 유지되면 flash-sale merchant의 record는 여전히 동일한 shard(또는 resharding 이후에도 소수 subset)로 hash되어 해당 shard는 계속 hot 상태로 throttling되고 다른 shard는 underutilized로 남습니다.
오답. producer를 초당 1,000 records로 throttling하면 ingestion throughput이 감소하여 동일한 전체 throughput을 유지해야 한다는 요구사항을 위반합니다. stream은 이미 aggregate capacity가 충분하며, 문제는 총 capacity 부족이 아니라 shard 간 불균등 분산입니다.
오답. record 크기를 줄이는 것은 shard가 1 MB/s limit에 걸릴 때는 도움이 될 수 있지만, hot shard는 shard당 1,000 records/s limit에도 제약을 받을 수 있습니다. 2 KB record의 경우 지배적인 merchant가 MB/s는 낮더라도 shard당 record-rate limit을 초과할 수 있습니다. 근본 원인은 record 크기가 아니라 partition-key skew입니다.
핵심 개념: 이 문제는 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에 먼저 도달합니다.
미디어 플랫폼이 PostgreSQL database에 저장된 재생 로그를 분석해야 합니다. 회사는 Zendesk에서 추적되는 고객 이슈와 로그를 상관 분석하려고 합니다. 회사는 매일 2 GB의 새로운 재생 로그를 수신합니다. 회사는 100 GB의 과거 Zendesk 티켓을 보유하고 있습니다. 데이터 엔지니어는 로그와 티켓을 분석하고 상관 분석하는 프로세스를 개발해야 합니다. 프로세스는 매일 밤 한 번 실행되어야 합니다. 가장 적은 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
운영 오버헤드가 높고 불필요하게 복잡합니다. MWAA는 Airflow environment(workers, schedulers, plugins, dependencies) 운영이 필요합니다. 상관 분석에 Lambda를 사용하고 오케스트레이션에 Step Functions를 사용하는 것은 오케스트레이션 책임을 중복시킵니다. 또한 100+ GB를 Lambda로 상관 분석하는 것은 실행 시간/메모리 제한과 분산 조인 필요 때문에 적합하지 않으며, Glue/Spark가 대규모 조인에 더 적합합니다.
AppFlow + Glue는 강력한 수집/ETL 접근이지만, MWAA를 추가하면 1일 1회 야간 파이프라인에 대해 Step Functions 대비 운영 오버헤드가 증가합니다. MWAA는 여전히 environment 관리, 스케일링, DAG 유지보수가 필요합니다. 회사가 이미 Airflow로 표준화했거나 복잡한 DAG 패턴/operator가 필요하지 않다면, Step Functions가 일반적으로 더 낮은 운영 부담의 오케스트레이션 선택입니다.
가장 적은 운영 오버헤드에 가장 적합합니다. AppFlow는 managed Zendesk connector와 S3로의 스케줄 기반 추출을 제공합니다. Glue는 JDBC를 통해 PostgreSQL에서 수집하고 Zendesk 데이터와의 확장 가능한 상관 분석(조인)을 수행할 수 있으며, Data Catalog와 (선택적으로) 증분 처리를 위한 job bookmarks를 사용할 수 있습니다. Step Functions는 서버나 Airflow environment를 관리하지 않고도 재시도 및 오류 처리를 포함한 야간 workflow를 오케스트레이션합니다.
요구 사항에 비해 과도하게 설계되었습니다. Kinesis Data Streams와 Managed Service for Apache Flink는 실시간 streaming 수집 및 stream processing을 위해 설계되었습니다. 문제는 지속적인 상관 분석이 아니라 야간 배치 실행을 요구합니다. 또한 PostgreSQL에서 Kinesis로 가져오는 것은 간단하지 않으며, 종종 커스텀 producer 또는 CDC tooling이 필요해 Glue JDBC 추출보다 운영 부담이 증가합니다.
핵심 개념: 이 문제는 매일 밤 실행되는 상관 분석 작업을 위한, 운영 부담이 가장 낮은 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를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
미디어 스트리밍 분석 팀은 Amazon Redshift Serverless(워크그룹: us-east-1의 prod-analytics)에서 클릭스트림 스키마 위에 9개의 materialized view를 사용하고 있으며, 어떤 오케스트레이션 인프라도 프로비저닝하거나 관리하지 않고 08:00~20:00 UTC 사이에 30분마다 9개 뷰 모두에 대해 REFRESH MATERIALIZED VIEW를 실행하는 스케줄을 자동화해야 합니다. 최소한의 노력으로 이 요구 사항을 충족하는 접근 방식은 무엇입니까?
Amazon MWAA는 일정에 따라 SQL tasks를 orchestration할 수 있지만, Airflow environment, DAGs, IAM roles 및 관련 configuration을 생성하고 유지 관리해야 합니다. 이는 단순한 반복 SQL maintenance 작업에 대해 문제에서 요구하는 것보다 훨씬 더 큰 운영 오버헤드입니다. 요구 사항은 orchestration infrastructure를 프로비저닝하거나 관리하지 말라고 명시하고 있으며, MWAA는 AWS가 일부를 관리하더라도 여전히 orchestration platform입니다. 따라서 MWAA는 기능적으로는 가능하지만 최소 노력 옵션은 아닙니다.
Redshift Lambda UDFs는 query execution 중 SQL statements에서 호출되며, 반복적인 database maintenance를 위한 기본 scheduling 메커니즘이 아닙니다. UDF는 Redshift Serverless 내부에서 독립적으로 30분마다 깨어나 timer에 따라 refresh를 트리거할 수 없습니다. 이를 작동시키려면 팀은 여전히 EventBridge 또는 다른 orchestration service와 같은 외부 scheduler가 필요하며, 이는 명시된 요구 사항과 모순됩니다. 또한 이 목적에 UDF를 사용하는 것은 built-in scheduled queries와 비교할 때 부자연스러운 설계입니다.
Amazon Redshift Query Editor v2는 provisioned clusters와 Redshift Serverless workgroups 모두에 대해 saved queries와 scheduled query execution을 지원합니다. 팀은 9개의 REFRESH MATERIALIZED VIEW 문이 모두 포함된 SQL script를 저장하고, 필요한 반복 주기로 실행되도록 구성할 수 있습니다. 이 접근 방식은 Redshift에서 기본 제공하는 관리형 기능을 사용하므로 Airflow, Glue jobs, EC2 instances 또는 기타 orchestration 구성 요소를 프로비저닝할 필요가 없습니다. 요구 사항은 최소한의 노력과 infrastructure management 회피를 강조하므로, Query Editor v2가 가장 직접적이고 운영적으로 단순한 솔루션입니다.
AWS Glue workflows와 jobs는 schedule할 수 있고 Amazon Redshift에 연결할 수 있지만, 주로 단순한 반복 SQL administration 작업보다는 ETL 및 data integration pipelines를 위해 설계되었습니다. 이를 구현하려면 Glue job 또는 Python shell job을 생성하고 유지 관리해야 하며, connectivity, IAM permissions 및 operational monitoring도 구성해야 합니다. Redshift가 이미 기본 scheduled query 기능을 제공하는 상황에서 이는 필요 이상으로 더 많은 설정과 더 많은 moving parts를 요구합니다. 결과적으로 Glue는 기능적 요구 사항은 충족할 수 있지만 최소 노력 요구 사항은 충족하지 못합니다.
핵심 개념: 이 문제는 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)을 먼저 찾으십시오. 타이밍 및 운영 제약을 직접 만족하는 가장 단순한 관리형 기능을 선호하십시오.
한 여행-테크 회사가 여러 레거시 시스템의 예약 및 고객 지원 데이터셋을 Amazon S3 데이터 레이크로 통합하고 있다. 한 엔지니어가 과거 내보내기 데이터(주당 약 3 TB의 CSV 및 JSON, 약 1억 2천만 행)를 검토한 결과, 많은 예약 및 고객 프로필이 시스템 전반에 걸쳐 중복되어 있음을 발견했다. 엔지니어는 curated zone에 게시하기 전에 중복 정보를 식별하고 제거해야 하며, 운영 오버헤드를 최소화하고 자동으로 확장되며 서버 또는 third-party library를 관리하지 않는 솔루션을 원한다. 다음 중 이러한 요구 사항을 가장 적은 운영 오버헤드로 충족하는 접근 방식은 무엇인가?
Pandas drop_duplicates()는 정확히 동일한 행의 중복 제거에는 간단하지만, 주당 3 TB 규모에 대해 managed되고 자동 확장되는 접근 방식이 아니다. self-managed compute(EC2/ECS/EKS)에서 실행해야 하거나 분산 접근 방식을 설계해야 하며, Pandas는 추가 프레임워크를 도입하지 않는 한 메모리 기반(단일 노드)이다. 이는 운영 오버헤드를 증가시키고 1억 2천만 행에서 성능 병목 위험을 높인다.
FindMatches ML transform을 사용하는 AWS Glue ETL은 서버리스이며 AWS-native인 중복 제거/엔터티 해석 솔루션이다. 이는 여러 레거시 시스템을 통합할 때 흔한, 정확히 일치하지 않을 수 있는 레코드 간 중복을 찾도록 설계되었다. 서버를 관리할 필요가 없고 third-party library도 피할 수 있으며, Glue의 managed scaling과 S3 및 Glue Data Catalog와의 통합을 활용한다.
third-party dedupe library를 사용하는 커스텀 Python ETL은 확률적 매칭을 수행할 수 있지만, third-party library를 피하라는 요구 사항을 위반한다. 또한 dependency 관리, 패키징, 런타임 호환성, compute 환경 확장에 대한 운영 오버헤드를 수반한다. 이 접근 방식은 상당한 엔지니어링 노력 없이는 매주 수 TB 규모에서 안정적으로 운영하기 어렵다.
AWS Glue job 내부에서 third-party dedupe library를 실행하는 것 역시 “third-party library를 피하라”는 요구 사항을 위반하며 운영 부담(예: Python wheel/egg dependency 관리, Glue 버전 호환성, job bootstrap, 트러블슈팅)을 추가한다. Glue가 서버리스 확장을 제공하더라도, dependency lifecycle과 잠재적인 Spark/Python 환경 이슈로 인해 Glue의 내장 FindMatches transform을 사용하는 것보다 오버헤드가 커진다.
핵심 개념: 이 문제는 운영 오버헤드를 최소화하면서 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,000개의 센서 이벤트를 Amazon Kinesis Data Streams로 수집하고, 운영 오버헤드를 최소화하면서 최대 30분의 event-time window에 대해 여러 집계를 수행하고 최대 90초의 late arrival을 허용하는 고가용성(높은 fault tolerance) 근실시간(near-real-time) 분석 솔루션이 필요하다. 데이터 엔지니어는 어떤 접근 방식을 선택해야 하는가?
적합하지 않다. Lambda에서 90초의 late arrival을 포함한 30분 time-based aggregation을 구현하려면 외부 state storage(예: DynamoDB)와 custom windowing, watermarking, deduplication 로직이 필요하다. 이는 운영 오버헤드와 복잡성을 증가시키며, retry와 partial failure 상황에서 정확성을 보장하기가 더 어려워진다. Lambda는 stateless transform이나 가벼운 enrichment에 더 적합하며, 견고한 event-time analytics에는 적합하지 않다.
부분적으로 관련은 있다. Amazon Managed Service for Apache Flink는 stateful aggregation에 적합한 올바른 엔진이다. 그러나 이 선택지는 요구사항으로 명시된 late arrival을 포함한 event-time window보다는 duplicate에 초점을 맞춘다. Flink는(종종 key/id와 state를 통해) duplicate도 처리할 수 있지만, 핵심 요구사항은 event-time windowing을 통한 time-based analytics이므로 D보다 직접적으로 부합하지 않는다.
여전히 적합하지 않다. tumbling window와 event timestamp를 언급하더라도, Lambda는 긴 window에서 late data를 처리하기 위한 Flink 수준의 event-time windowing semantics, watermark, managed state를 기본 제공하지 않는다. late arrival과 window finalization을 처리하려면 상당한 custom 로직과 state management를 구축/운영해야 하며, 이는 “minimum operational overhead” 요구사항과 상충한다.
정답. Amazon Managed Service for Apache Flink는 근실시간, fault-tolerant, stateful stream processing을 위해 목적에 맞게 설계되었다. event-time windowing, watermark, allowed lateness를 지원하여 최대 90초의 late arrival을 수용하면서 30분 window에 대해 여러 aggregation을 계산할 수 있다. checkpointing과 state recovery가 높은 fault tolerance를 제공하며, managed service가 custom Lambda 기반 솔루션 대비 운영 오버헤드를 줄여준다.
핵심 개념: 이 문제는 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에 적합하다.
게임 분석 회사가 콘솔 클라이언트, 전용 게임 서버, 치트 방지 센서에서 실시간 게임플레이 텔레메트리를 Amazon Kinesis Data Streams로 스트리밍하고 있습니다. 평균 12 MB/s이며 6개 shard 전반에서 최대 30 MB/s까지 피크가 발생합니다. 데이터 엔지니어는 이 스트리밍 피드를 처리하여 분석을 위해 Amazon Redshift Serverless workgroup에 적재해야 합니다. 대시보드는 sub-60-second 최신성으로 준실시간 인사이트를 제공해야 하며, 동시에 전날 데이터와 조인해야 하고, 솔루션은 운영 오버헤드를 최소화해야 합니다. 가장 적은 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
Kinesis Data Firehose는 스트리밍 데이터를 Redshift로 전달할 수 있지만, 일반적으로 내부적으로 S3 스테이징과 COPY를 사용하여 버퍼링된 micro-batch로 동작합니다. buffering 설정, COPY 성능, 피크 처리량에 따라 일관된 sub-60-second 최신성을 달성하기가 어려울 수 있습니다. 커스텀 컨슈머보다는 운영이 적지만, Kinesis Data Streams에 대한 Redshift streaming ingestion만큼 직접적/저지연은 아닙니다.
Amazon Redshift streaming ingestion은 Redshift가 Amazon Kinesis Data Streams에서 직접 매우 낮은 지연 시간으로 데이터를 수집하는 네이티브 방식입니다. Redshift에서는 일반적으로 stream 위에 materialized view를 생성하는 방식으로 이를 구현하며, 이를 통해 최신 event를 조회하고 동일한 warehouse 내의 기존 과거 table과 조인할 수 있습니다. 요구 사항이 60초 미만의 최신성과 최소한의 운영 오버헤드이므로, 이것이 가장 적합합니다. Amazon Redshift Serverless는 cluster 관리 및 scaling 작업을 제거하여 관리 부담을 더욱 줄여줍니다.
S3에 적재한 뒤 Redshift COPY 명령을 사용하는 것은 배치 수집 패턴입니다. 파일을 작성하고, 파티션을 관리하고, COPY 작업을 트리거하고, 재시도를 처리하고, 파일 크기/manifesting을 튜닝하는 프로세스를 구축하고 운영해야 합니다. 이는 운영 오버헤드를 증가시키며, 파일 생성과 배치 로드 스케줄링에 의존하므로 일반적으로 sub-minute 최신성을 보장할 수 없습니다.
Aurora zero-ETL integration with Amazon Redshift는 Amazon Aurora(MySQL/PostgreSQL)에서 Redshift로 데이터를 최소 ETL로 복제하기 위한 기능입니다. 이 시나리오의 소스는 Amazon Kinesis Data Streams이며 Aurora가 아니므로, 이 옵션은 수집 요구 사항을 해결하지 못하고 명시된 스트리밍 텔레메트리 사용 사례를 충족할 수 없습니다.
핵심 개념: 이 문제는 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 시나리오에서만 선택하세요.
데이터 엔지니어가 계정 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으로 실패합니다. 엔지니어는 이 예외를 어떻게 해결해야 합니까?
이 선택지는 Lambda execution role trust policy가 function 실행 시 어떤 service가 execution role을 assume할 수 있는지를 결정하기 때문에 틀렸습니다. EventBridge는 function을 invoke하기 위해 Lambda execution role을 assume하지 않습니다. Invocation permission은 Lambda function의 resource-based policy에 의해 제어되므로, execution role trust relationship을 변경해도 AccessDeniedException은 해결되지 않습니다. 이 선택지는 runtime permission과 invoke permission을 혼동하고 있습니다.
이 선택지는 EventBridge rule에 대해 Lambda invocation permission이 부여되어야 한다는 점을 인식하고 있으므로 가장 가까운 정답입니다. 핵심 해결책은 events.amazonaws.com service principal이 lambda:InvokeFunction을 호출할 수 있도록 허용하고, SourceArn에서 rule ARN으로 범위를 제한하는 Lambda function의 resource-based policy입니다. 이것이 EventBridge가 function을 invoke하려 할 때 Lambda가 반환하는 AccessDeniedException을 해결합니다. EventBridge target IAM role에 대한 언급은 Lambda target에는 불필요하지만, 이 선택지만이 필요한 Lambda resource-policy permission을 포함하고 있습니다.
이 선택지는 Lambda function을 private subnet에 배치하는 것이 VPC 내부 또는 외부 리소스에 대한 function의 network access에 영향을 주기 때문에 틀렸습니다. 이는 EventBridge가 function을 invoke할 권한이 있는지 여부를 제어하지 않습니다. EventBridge-to-Lambda invocation은 subnet 배치가 아니라 IAM 및 Lambda resource-based permission에 의해 관리됩니다. 따라서 function을 private subnet으로 옮겨도 Lambda의 authorization failure는 해결되지 않습니다.
이 선택지는 EventBridge schema registry와 event pattern mapping이 Lambda authorization이 아니라 event discovery 및 rule matching과 관련되어 있기 때문에 틀렸습니다. event pattern이 잘못되었다면 rule이 단순히 일치하지 않거나 target이 invoke되지 않을 것입니다. 문제는 invocation이 Lambda의 AccessDeniedException으로 실패한다고 명시하고 있으므로, 이는 Lambda 측의 invoke permission 누락을 가리킵니다. 따라서 schema 또는 pattern 수정은 근본 원인을 해결하지 못합니다.
핵심 개념: 이 문제는 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로 범위 지정되었는지도 확인하세요.
학습 기간: 1 month
문제 제대로 이해하고 풀었으면 여러분들도 합격 가능할거에요! 화이팅
학습 기간: 1 month
I passed the AWS data engineer associate exam. Cloud pass questions is best app which help candidate to preparer well for any exam. Thanks
학습 기간: 1 month
시험하고 문제 패턴이 비슷
학습 기간: 2 months
813/1000 합격했어요!! 시험하고 문제가 유사한게 많았어요
학습 기간: 1 month
해설까지 있어서 공부하기 좋았어요. 담에 또 올게요
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.