AWS DEA-C01 각색 문제 Day 15 — Redshift 데이터 공유, Lake Formation + QuickSight, Redshift KEY, Glue 크롤러, IoT 최소 지연

AWS DEA-C01 문제로 공부하기 — Day 15

Redshift 데이터 공유(복수), Lake Formation 이벤트 + QuickSight(복수), Redshift KEY 배포 스타일 조인 최적화, Glue 크롤러 단일 테이블 조건(복수), IoT 최소 지연 S3 전송 — 5문제 핵심 정리.

AWS DEA-C01 Domain 1·2·4 · 스토리지·보안·스트리밍 5문제

📋 목차

• Q71 Redshift 멀티계정 데이터 공유 — 데이터 이동 없이 (복수)
• Q72 Lake Formation 이벤트 캡처 + QuickSight 감사 보고서 (복수)
• Q73 Redshift 상위-하위 테이블 조인 성능 최적화
• Q74 Glue 크롤러가 하나의 테이블만 생성하려면 (복수)
• Q75 IoT 센서 10초 데이터 → S3 최소 지연 전송

Q71Redshift 데이터 공유 · 멀티계정 · 크로스 리전✌️ 복수 정답

Amazon Redshift 데이터 공유(Data Sharing)는 데이터를 이동하지 않고 다른 AWS 계정이나 리전의 Redshift에서 실시간으로 읽기 접근을 허용합니다. 특정 리전에 공유하거나 모든 리전에 공유하는 두 가지 범위가 지원됩니다.

📋 Question — 두 가지를 선택하세요

Amazon Redshift 데이터 웨어하우스가 있는 회사가 새 AWS 계정을 만들어 새 리전으로 사업을 확장합니다. 새 계정이 데이터 웨어하우스의 데이터를 읽어야 하지만 데이터를 이동하지 않아야 합니다. AWS 계정 관리자에게 데이터 공유 기능을 제공하는 솔루션 두 가지는 무엇일까요?

• AAmazon Redshift 데이터 공유를 사용하여 모든 가용 영역에 데이터를 공유합니다.
  ❌ Redshift 데이터 공유의 공유 범위는 리전(Region) 및 계정 단위. 가용 영역(AZ) 단위 공유 범위 설정은 없음.
• BAmazon Redshift 데이터 공유를 사용하여 모든 리전에 데이터를 공유합니다.
  ✅ Redshift 데이터 공유 — 모든 리전 — 데이터를 복제하거나 이동하지 않고 모든 AWS 리전의 다른 계정에 실시간 읽기 접근 허용. 새 리전의 신규 계정 시나리오에 적합.
• CAmazon Redshift 데이터 공유를 사용하여 특정 Redshift 외부 테이블을 다른 리전의 AWS 계정과 공유합니다.
  ❌ Redshift 데이터 공유는 Redshift 내부 테이블을 공유하는 기능. 외부 테이블(Redshift Spectrum이 참조하는 S3 테이블)을 다른 리전 계정과 공유하는 방식이 아님.
• DAmazon Redshift 데이터 공유를 사용하여 AWS 계정의 특정 리전에 데이터를 공유합니다.
  ✅ Redshift 데이터 공유 — 특정 리전 — 공유 대상을 특정 리전으로 제한하여 데이터 공유. 데이터 이동 없이 해당 리전의 다른 계정이 읽기 접근 가능. 리전 단위 제어가 필요한 컴플라이언스 환경에 적합.

🎯

정답

B + D — 모든 리전 공유 OR 특정 리전 공유

🔑 핵심 개념 — Redshift 데이터 공유 범위

공유 범위	설명	지원?
모든 리전	모든 AWS 리전 계정에 공유	✓
특정 리전	지정 리전 계정에만 공유	✓
가용 영역(AZ)	AZ 단위 공유	✗ 없음
외부 테이블 공유	Spectrum 외부 테이블 공유	✗ 내부 테이블만

💡 이것만 기억하자

Redshift 데이터 공유 = 데이터 이동 없이 읽기 접근 허용
공유 단위: 계정 / 특정 리전 / 모든 리전

가용 영역(AZ) 단위 공유는 없음

---

Q72CloudTrail Lake · Lake Formation 이벤트 · QuickSight✌️ 복수 정답

CloudTrail Lake는 Lake Formation 이벤트를 포함한 모든 AWS 서비스 이벤트를 캡처·SQL 쿼리할 수 있습니다. QuickSight는 CloudTrail Lake를 데이터 소스로 직접 연결해 감사 보고서를 생성할 수 있습니다.

📋 Question — 두 가지를 선택하세요

데이터 레이크를 Lake Formation으로 관리합니다. 모든 Lake Formation 이벤트를 캡처하고, 쿼리로 규모 있게 분석하며 Amazon QuickSight로 감사 보고서를 생성해야 합니다. 운영 오버헤드를 최소화하는 단계 조합 두 가지는 무엇일까요?

• ACloudTrail Lake로 이벤트 데이터 스토어를 만들고, 관리·데이터 이벤트를 구성합니다. Lake Formation을 선택하고 모든 데이터 이벤트를 로깅합니다.
  ✅ CloudTrail Lake 이벤트 데이터 스토어 — Lake Formation 이벤트 포함 모든 AWS 서비스 이벤트 캡처. 별도 S3·Glue·Athena 설정 없이 이벤트 저장 + SQL 쿼리 내장. 최소 설정으로 이벤트 캡처.
• BCloudTrail 추적을 만들고 모든 Lake Formation 이벤트를 로깅합니다. CloudTrail 이벤트 기록에서 Athena 테이블을 만듭니다.
  ❌ 추적 + S3 전달 + Athena 테이블 생성까지 여러 단계를 직접 구성해야 함. CloudTrail Lake보다 설정 복잡도가 높음.
• CCloudTrail 추적으로 Lake Formation 이벤트를 로깅하고, Glue ETL + 크롤러로 서버리스 이벤트 기반 워크플로를 구축합니다.
  ❌ 추적 + S3 + Glue ETL + 크롤러까지 가장 많은 구성 단계. 오버헤드가 가장 높음. CloudTrail Lake로 훨씬 간단하게 해결 가능.
• DAmazon Athena를 데이터 원본으로 사용해 QuickSight 데이터셋을 만들고 보고서를 생성합니다.
  ❌ A와 함께 사용 시 CloudTrail Lake의 데이터를 Athena가 읽어 QuickSight에 연결하는 구조가 되지만, CloudTrail Lake는 QuickSight와 직접 연결 가능. E보다 불필요한 중간 레이어.
• EAWS CloudTrail Lake를 데이터 원본으로 사용해 QuickSight 데이터셋을 만들고 보고서를 생성합니다.
  ✅ QuickSight ← CloudTrail Lake 직접 연결 — CloudTrail Lake는 QuickSight의 네이티브 데이터 소스로 지원. A에서 캡처한 이벤트 데이터 스토어에 QuickSight를 직접 연결해 감사 보고서 생성. 최소 설정으로 감사 보고서 완성.

🎯

정답

A + E — CloudTrail Lake(이벤트 수집) + QuickSight 직접 연결(보고서)

🔑 핵심 개념 — Lake Formation 감사 파이프라인

단계	서비스	설정 복잡도
이벤트 캡처	CloudTrail Lake	최소
보고서 생성	QuickSight ← CloudTrail Lake	최소 (직접 연결)
이벤트 캡처 (대안)	CloudTrail 추적 + S3	중간
보고서 생성 (대안)	QuickSight ← Athena	중간 (추가 설정)

💡 이것만 기억하자

"Lake Formation 이벤트 + 쿼리 + QuickSight 보고서"
→ CloudTrail Lake + QuickSight 직접 연결

CloudTrail Lake = QuickSight 네이티브 데이터 소스 지원
Athena 중간 레이어 불필요

---

Q73Redshift KEY 배포 · 상위-하위 조인 · 성능⭐ 자주 출제

Redshift KEY 배포 스타일은 특정 컬럼의 같은 값을 가진 행을 같은 슬라이스에 배치합니다. 상위-하위(Parent-Child) 관계 테이블 모두를 조인 키 기준 KEY 배포로 설정하면 조인 시 네트워크 전송(브로드캐스트/재분산)이 없어집니다.

📋 Question

Amazon Redshift에서 상위-하위 관계인 두 대형 테이블 조인 쿼리 성능을 개선해야 합니다. 두 테이블 모두 EVEN 배포 스타일로 생성되어 있습니다. 가장 비용 효율적으로 성능을 향상하는 솔루션은 무엇일까요?

• A상위 테이블을 ALL 배포로 재생성합니다. 하위 테이블은 EVEN 유지합니다.
  ❌ ALL 배포 — 전체 복사본을 모든 노드에 배치. 소규모·자주 안 바뀌는 차원 테이블에 적합. 크기가 매우 큰 상위 테이블에 ALL을 적용하면 스토리지 과다 사용으로 비용 비효율적.
• B하위 테이블을 ALL 배포로 재생성합니다. 상위 테이블은 EVEN 유지합니다.
  ❌ 마찬가지로 크기가 매우 큰 하위 테이블에 ALL을 적용하면 스토리지·비용 비효율. 상위 테이블은 EVEN이라 조인 시 재분산 발생.
• C기본 키 기반 KEY 배포로 상위 테이블을 재생성합니다. 일치하는 조인 컬럼 기반 KEY 배포로 하위 테이블도 재생성합니다.
  ✅ KEY 배포 (양쪽 테이블) — 상위 테이블은 기본 키, 하위 테이블은 외래 키(같은 조인 컬럼)로 배포. 같은 키 값이 같은 슬라이스에 → 조인 시 네트워크 전송 제거. 두 테이블 모두 크기가 크더라도 ALL 배포보다 비용 효율적.
• D기본 키 기반 KEY 배포로 상위 테이블을 재생성합니다. 하위 테이블은 EVEN 배포로 재생성합니다.
  ❌ 상위만 KEY, 하위는 EVEN이면 조인 시 여전히 데이터 재분산(Redistribute) 발생. 두 테이블의 조인 컬럼 키 배포가 일치해야 효과가 있음.

🎯

정답

C — 상위·하위 테이블 모두 조인 키 기준 KEY 배포

🔑 핵심 개념 — 대형 테이블 조인 시 배포 스타일 선택

시나리오	권장 배포	이유
대형+대형 테이블 조인	양쪽 KEY (조인 컬럼)	조인 시 재분산 제거
소형 차원 + 대형 팩트 조인	차원=ALL, 팩트=EVEN/KEY	브로드캐스트 제거
일반 쿼리 (조인 없음)	EVEN	균등 분산

💡 이것만 기억하자

"대형 테이블 상위-하위 조인 성능"
→ 양쪽 모두 KEY 배포 (조인 컬럼 기준)

상위 = 기본 키(PK)로 KEY 배포
하위 = 외래 키(FK, 같은 조인 컬럼)로 KEY 배포
→ 같은 키 값 = 같은 슬라이스 → 조인 시 네트워크 전송 없음

---

Q74Glue 크롤러 · 단일 테이블 생성 조건 · S3 파티션 구조✌️ 복수 정답

Glue 크롤러가 S3 데이터로 단일 테이블을 생성하려면 파일 형식, 압축 유형, 스키마, S3 파티션 경로(접두사 구조)가 모두 동일해야 합니다. 이 중 하나라도 다르면 여러 테이블이 생성됩니다.

📋 Question — 두 가지를 선택하세요

금융 회사가 서드파티 데이터를 S3 버킷에 저장하고 Glue 크롤러를 실행했더니 하나가 아닌 여러 테이블이 생성됐습니다. 크롤러가 하나의 테이블만 생성하도록 하는 조건 두 가지는 무엇일까요?

• A객체 형식, 압축 유형, 스키마가 모든 객체에서 동일한지 확인합니다.
  ✅ 형식·압축·스키마 일관성 — Glue 크롤러가 단일 테이블을 생성하려면 모든 객체의 파일 형식(CSV, Parquet, JSON), 압축 유형(gzip, Snappy, bzip2), 스키마(컬럼·타입)가 동일해야 함. 하나라도 다르면 별도 테이블 생성.
• B객체 형식과 스키마만 동일하게 하고 압축 유형은 달라도 됩니다.
  ❌ 압축 유형이 다르면 Glue 크롤러가 별도 테이블을 생성. 형식·압축·스키마 세 가지 모두 일관되어야 함.
• C스키마만 동일하게 하고 파일 형식과 압축 유형은 달라도 됩니다.
  ❌ 스키마만으로는 부족. 파일 형식과 압축 유형도 일관되어야 단일 테이블이 생성됨.
• D각 S3 객체 이름의 접두사(prefix) 구조가 일관적인지 확인합니다.
  ✅ S3 접두사(파티션) 구조 일관성 — Glue 크롤러는 S3 경로의 파티션 구조를 기반으로 테이블을 분리. 접두사 구조(예: s3://bucket/year=2024/month=01/)가 일관되지 않으면 여러 테이블이 생성됨. 일관된 파티션 경로가 단일 테이블의 전제조건.
• E모든 S3 객체 이름이 비슷한 패턴을 따르는지 확인합니다.
  ❌ 객체 이름 패턴 유사성은 Glue 크롤러의 테이블 생성 기준이 아님. 크롤러는 S3 경로의 파티션 구조(접두사)를 기준으로 판단. 단순 파일명 패턴과 다른 개념.

🎯

정답

A + D — 형식·압축·스키마 일관성 + 접두사 구조 일관성

🔑 핵심 개념 — Glue 크롤러 단일 테이블 생성 조건

조건	일관성 필요?
파일 형식 (CSV, Parquet, JSON)	✓ 필수
압축 유형 (gzip, Snappy, bzip2)	✓ 필수
스키마 (컬럼·타입)	✓ 필수
S3 접두사(파티션) 구조	✓ 필수
파일명 패턴	✗ 무관

💡 이것만 기억하자

Glue 크롤러 단일 테이블 조건:
1. 파일 형식 동일
2. 압축 유형 동일
3. 스키마 동일
4. S3 접두사(파티션) 구조 동일

이 4가지 중 하나라도 다르면 여러 테이블 생성!

---

Q75Kinesis Data Streams · Firehose · Apache Flink · IoT 지연⭐ 자주 출제

IoT 센서 데이터를 S3로 전송할 때 최소 지연을 달성하려면 버퍼 간격(Buffer Interval)을 최소화해야 합니다. Amazon Managed Service for Apache Flink + Firehose 5초 버퍼가 가장 낮은 지연을 제공합니다. Firehose 기본 버퍼는 300초(5분)입니다.

📋 Question

실험실에서 IoT 센서가 10초마다 100KB 데이터를 전송합니다. 다운스트림 프로세스는 30초마다 S3 버킷에서 데이터를 읽습니다. S3 버킷에 데이터를 전송하는 지연 시간을 최소화하는 솔루션은 무엇일까요?

• AAmazon Kinesis Data Streams와 Amazon Data Firehose를 사용하여 데이터를 S3로 전송합니다. Firehose의 기본값 버퍼 간격을 사용합니다.
  ❌ Firehose 기본 버퍼 간격 = 300초(5분). 다운스트림이 30초마다 읽는데 5분 버퍼는 지연이 너무 큼. 버퍼를 최소로 줄여야 지연 최소화 가능.
• BAmazon Kinesis Data Streams를 사용하여 프로비저닝된 샤드 5개로 S3에 직접 전송합니다.
  ❌ Kinesis Data Streams는 S3로 직접 전송 기능이 없음. S3로 전달하려면 Firehose나 Lambda·KCL 등 별도 소비자가 필요.
• CKinesis Data Streams와 KCL 애플리케이션으로 데이터를 S3에 전송합니다. 5초 버퍼 간격을 사용합니다.
  ❌ KCL로 5초 버퍼 애플리케이션을 만드는 것은 가능하지만 직접 코드 개발·배포·관리가 필요. D의 완전관리형 Flink+Firehose보다 운영 부담이 높고 지연 최소화 면에서 동등하거나 불리.
• DAmazon Managed Service for Apache Flink와 Amazon Data Firehose를 사용합니다. Firehose에 5초의 버퍼 간격을 설정합니다.
  ✅ Apache Flink(관리형) — 스트리밍 데이터 처리 엔진. Firehose 버퍼 간격 5초 — Firehose 최소 버퍼 간격(60초가 아닌 Dynamic Partitioning 사용 시 1초까지 가능, 일반적으로 최소 60초지만 본 문제에서는 5초로 설정). 다운스트림 30초 주기 대비 충분히 짧아 최소 지연 달성.

🎯

정답

D — Apache Flink + Firehose 5초 버퍼로 최소 지연

🔑 핵심 개념 — Firehose 버퍼 간격

설정	버퍼 간격	지연
Firehose 기본값	300초 (5분)	매우 높음
Firehose 5초 설정	5초	최소
Kinesis Data Streams 직접	S3 전달 불가	불가

💡 이것만 기억하자

"IoT → S3 최소 지연" → Flink + Firehose (버퍼 간격 최소화)

Firehose 기본 = 300초 → 지연 큼
버퍼를 5초로 설정 → 지연 최소화
KDS는 S3 직접 전달 불가 (소비자 필요)

AWS DEA-C01Redshift 데이터 공유CloudTrail Lake QuickSightRedshift KEY 배포Glue 크롤러 단일 테이블Firehose 버퍼AWS 자격증