AWS DEA-C01 각색 문제 Day 09 — Redshift CALL, Glue 작업 북마크 증분 처리, Redshift 페더레이션 쿼리, Firehose → Splunk 실시간 로그 전송, VPC 흐름 로그 + Parquet + Athena

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

Redshift CALL 문법, Glue 작업 북마크 증분 처리, Redshift 페더레이션 쿼리, Firehose → Splunk 실시간 로그 전송, VPC 흐름 로그 + Parquet + Athena — 5문제 핵심 정리.

AWS DEA-C01 Domain 1·2 · SQL · 네트워킹 · 스트리밍 5문제

📋 목차

• Q41 Redshift 저장 프로시저 실행 SQL 명령어
• Q42 Glue ETL 작업 — 일별 증분 데이터만 처리하기
• Q43 Aurora 운영 DB 데이터를 Redshift에서 실시간 분석
• Q44 VPC 흐름 로그를 Splunk로 실시간 전송
• Q45 VPC 흐름 로그 수집·분석 — 가장 비용 효율적

Q41Redshift SQL · 저장 프로시저 · CALL⭐ 자주 출제

Amazon Redshift에서 저장 프로시저(Stored Procedure)를 실행하는 SQL 명령어는 CALL입니다. SELECT·FETCH·SHOW는 저장 프로시저 실행에 사용하지 않습니다.

📋 Question

Amazon Redshift에 Daily_Aggr_SP라는 저장 프로시저(Stored Procedure)가 있습니다. 이 프로시저는 날짜를 입력받아 일별 집계 데이터를 프로덕션 테이블에 삽입합니다. 이 저장 프로시저를 실행하는 올바른 SQL 명령문은 무엇인가요?

• ACALL Daily_Aggr_SP('2024-01-01')
  ✅ CALL — SQL 표준 저장 프로시저 실행 명령어. Redshift, PostgreSQL, MySQL 모두 동일. 괄호 안에 입력 파라미터를 전달. 저장 프로시저를 호출하는 유일한 올바른 방법.
• BFETCH Daily_Aggr_SP('2024-01-01')
  ❌ FETCH — 커서(Cursor)에서 행을 가져오는 명령어. 저장 프로시저 실행 명령이 아님.
• CSHOW PROCEDURE Daily_Aggr_SP('2024-01-01')
  ❌ SHOW — 시스템 설정·객체 정보를 조회하는 명령어. 저장 프로시저를 실행하는 명령이 아님.
• DSELECT Daily_Aggr_SP('2024-01-01')
  ❌ SELECT — 데이터 조회 명령어. 함수(Function)는 SELECT로 호출하지만 저장 프로시저(Procedure)는 CALL을 사용해야 함. 저장 프로시저와 함수는 다른 객체.

🎯

정답

A — CALL 명령어로 저장 프로시저 실행

🔑 핵심 개념 — Redshift 함수 vs 저장 프로시저 실행 방법

객체 유형	실행 명령어	예시
저장 프로시저(Procedure)	CALL	CALL proc_name(param)
사용자 정의 함수(Function)	SELECT	SELECT func_name(param)
커서(Cursor)	FETCH	FETCH cursor_name

💡 이것만 기억하자

저장 프로시저 실행 → CALL proc_name(파라미터)
사용자 정의 함수 → SELECT func_name(파라미터)

Procedure ≠ Function → 실행 방법이 다름!

---

Q42Glue 작업 북마크 · 증분 처리 · 최소 코딩⭐ 자주 출제

AWS Glue 작업 북마크(Job Bookmark)는 마지막으로 처리한 데이터의 체크포인트를 자동으로 관리해 다음 실행 시 새로운 데이터만 처리하는 기능입니다. 코드 변경 없이 구성만으로 증분 처리를 구현할 수 있습니다.

📋 Question

S3에서 데이터를 검증·변환하여 RDS MySQL에 배치로 적재하는 Glue ETL 작업이 있습니다. 현재 매 실행마다 S3의 모든 데이터를 처리하는데, 일별 신규 데이터만 처리하도록 변경하고 싶습니다. 코딩 작업을 최소화하는 방법은 무엇일까요?

• AS3 파일 상태를 읽고 처리 상태를 DynamoDB에 기록하는 별도 ETL 작업을 만들어 처리된 파일을 추적합니다.
  ❌ 파일 메타데이터 읽기 + DynamoDB 상태 관리 + 메인 ETL에서 상태 확인까지 상당한 코딩 작업 필요. 작업 북마크를 쓰면 코드 없이 해결 가능.
• BGlue 작업 설정에서 작업 북마크(Job Bookmark)를 활성화하여 이전에 처리된 데이터를 자동으로 추적합니다.
  ✅ AWS Glue 작업 북마크(Job Bookmark) — 마지막 처리 지점(체크포인트)을 자동 기록해 다음 실행 시 새 데이터만 읽는 기능. 소설책에 책갈피를 끼워두면 다음에 이어 읽을 수 있는 것처럼. 코드 변경 없이 Glue 작업 구성에서 활성화만 하면 즉시 증분 처리 동작.
• CGlue 작업 지표를 사용하여 CloudWatch에서 처리된 객체를 추적합니다.
  ❌ CloudWatch 지표는 모니터링·알람용. 처리된 객체를 추적하거나 증분 처리를 제어하는 기능이 없음. 관측(Observability) 도구와 처리 제어는 다름.
• D각 실행 후 처리된 S3 객체를 삭제하도록 ETL 작업을 수정합니다.
  ❌ 처리된 데이터 삭제는 데이터 손실 위험이 있고 재처리가 불가능해짐. 삭제 로직 추가 코딩도 필요. 잘못된 접근.

🎯

정답

B — Glue 작업 북마크 활성화로 코드 없이 증분 처리

🔑 핵심 개념 — Glue 증분 처리 방법 비교

방법	코딩 필요	재처리 가능	적합성
작업 북마크(Job Bookmark)	없음 (구성만)	✓	✓ 최적
DynamoDB 상태 추적	많음	✓	복잡도 높음
처리 후 S3 삭제	필요	✗	위험함
CloudWatch 지표	없음	-	모니터링용

💡 이것만 기억하자

"Glue ETL 증분 처리 + 최소 코딩" → 작업 북마크(Job Bookmark)

코드 변경 없이 구성에서 활성화만 하면 됨
체크포인트 자동 관리 → 다음 실행 시 새 데이터만 처리

---

Q43Redshift 페더레이션 쿼리 · Aurora · 실시간 분석⭐ 자주 출제

Redshift 페더레이션 쿼리(Federated Query)는 데이터를 복제하지 않고 Aurora PostgreSQL 등 외부 DB에서 직접 데이터를 쿼리하는 기능입니다. 실시간에 가까운 분석이 필요할 때 가장 적은 운영 오버헤드로 구현 가능합니다.

📋 Question

Amazon Redshift 데이터 웨어하우스에서 과거 분석 데이터를 관리하고, 공급망 앱의 실시간 재고 데이터는 Amazon Aurora PostgreSQL에 있습니다. 분석팀이 재고 데이터를 거의 실시간으로 분석해야 하며 데이터 업데이트도 추적해야 합니다. 운영 오버헤드를 최소화하는 방법은 무엇일까요?

• AAWS DMS를 사용하여 Aurora와 Redshift 데이터를 지속적으로 동기화하고 Redshift에서 분석합니다.
  ❌ DMS 지속 복제는 설정·모니터링 오버헤드가 있고, Aurora → Redshift 반영 지연이 발생할 수 있어 실시간에 가까운 접근 요건을 보장하기 어려움.
• BRedshift에서 페더레이션 쿼리를 사용하여 Aurora PostgreSQL 데이터를 직접 쿼리합니다.
  ✅ Redshift 페더레이션 쿼리(Federated Query) — 데이터 복제 없이 Redshift SQL에서 Aurora 데이터를 직접 조회. 마치 원격 도서관 책을 가져오지 않고 그 자리에서 바로 읽는 것. 항상 최신 데이터 접근(실시간) + 설정만으로 구성 가능 + 운영 오버헤드 최소.
• CAurora 데이터를 S3로 내보내고 Redshift Spectrum으로 쿼리합니다.
  ❌ Aurora → S3 내보내기 작업이 추가되고 내보내기 주기만큼 데이터 지연 발생. 실시간 접근 요건 미충족 + 운영 오버헤드 증가.
• DGlue ETL로 시간별 Aurora → Redshift 데이터 전송 작업을 구성하고 Redshift에서 분석합니다.
  ❌ 시간별 배치 = 최대 1시간 데이터 지연. 실시간에 가까운 접근 요건 미충족. Glue 작업 관리 오버헤드도 추가.

🎯

정답

B — Redshift 페더레이션 쿼리로 Aurora 실시간 분석

🔑 핵심 개념 — Aurora 데이터 Redshift에서 분석 방법 비교

방법	실시간성	데이터 복제	운영 부담
페더레이션 쿼리	실시간	없음	최소
DMS 지속 복제	준실시간	있음	중간
Glue ETL (시간별)	최대 1시간 지연	있음	중간
Aurora → S3 내보내기	지연 있음	있음	높음

💡 이것만 기억하자

"Redshift에서 외부 DB 실시간 쿼리 + 운영 최소화"
→ Redshift 페더레이션 쿼리

데이터 복제 없음 → 항상 최신 데이터
Aurora PostgreSQL, RDS 등 외부 DB를 직접 쿼리

---

Q44Firehose · CloudWatch Logs · Splunk · 실시간 스트리밍⭐ 자주 출제

Amazon Data Firehose는 Splunk를 네이티브 대상으로 지원하는 완전관리형 스트리밍 서비스입니다. CloudWatch Logs 구독 필터로 로그를 Firehose에 직접 전달하면 Lambda 없이 최소 운영으로 Splunk 연동이 가능합니다.

📋 Question

VPC 흐름 로그를 Amazon CloudWatch Logs에 게시하도록 설정했습니다. 추가 분석을 위해 흐름 로그를 거의 실시간으로 Splunk로 전송해야 합니다. 운영 오버헤드를 최소화하는 방법은 무엇일까요?

• ASplunk를 대상으로 하는 Kinesis Data Streams를 구성하고, CloudWatch Logs 구독 필터로 Kinesis로 로그를 전송합니다.
  ❌ Kinesis Data Streams는 Splunk를 네이티브 대상으로 지원하지 않음. Splunk로 전달하려면 Firehose가 필요.
• BSplunk를 대상으로 하는 Amazon Data Firehose 전송 스트림을 생성하고, CloudWatch Logs 구독 필터로 로그를 Firehose에 전송합니다.
  ✅ Amazon Data Firehose — 완전관리형 스트리밍 서비스로 Splunk를 네이티브 대상으로 지원. CloudWatch Logs 구독 필터 — Lambda 없이 로그를 Firehose에 직접 스트리밍. 추가 코드 없이 CloudWatch Logs → Firehose → Splunk 파이프라인 구성 가능.
• CSplunk를 대상으로 하는 Firehose 전송 스트림을 생성하고, Lambda 함수를 만들어 CloudWatch Logs에서 Firehose로 로그를 전송합니다.
  ❌ Firehose가 Splunk를 지원하는 건 맞지만, Lambda 함수를 추가로 개발·관리해야 함. CloudWatch Logs 구독 필터를 사용하면 Lambda 없이 직접 연결 가능. 불필요한 오버헤드.
• DSplunk를 대상으로 하는 Kinesis Data Streams를 구성하고, Lambda 함수로 CloudWatch Logs에서 Kinesis로 로그를 전송합니다.
  ❌ Kinesis Data Streams는 Splunk 직접 연동 불가 + Lambda 개발 부담 2가지 문제. 최악의 오버헤드 조합.

🎯

정답

B — CloudWatch Logs 구독 필터 → Firehose → Splunk

🔑 핵심 개념 — Splunk 연동 서비스 비교

서비스	Splunk 네이티브 지원	CloudWatch Logs 직접 구독	Lambda 필요?
Amazon Data Firehose	✓	✓	불필요
Kinesis Data Streams	✗	구독 가능	필요

💡 이것만 기억하자

"CloudWatch Logs → Splunk 실시간 전송"
→ 구독 필터 → Firehose → Splunk

Kinesis Data Streams = Splunk 직접 연동 불가
Lambda 추가 = 불필요한 오버헤드

---

Q45VPC 흐름 로그 · S3 Parquet · Athena · 비용 최적화⭐ 자주 출제

VPC 흐름 로그 분석의 가장 비용 효율적인 패턴은 S3에 Parquet 형식으로 저장 + Athena 분석입니다. Parquet은 열 형식(Columnar)으로 압축·인코딩 최적화가 되어 있어 텍스트보다 Athena 스캔 비용이 크게 줄어듭니다.

📋 Question

VPC의 EC2 인스턴스에서 발생하는 네트워크 트래픽을 수집하고 분석하려 합니다. 가장 비용 효율적인 솔루션은 무엇일까요?

• A흐름 로그를 Amazon CloudWatch Logs에 게시하고, Amazon Athena로 분석합니다.
  ❌ CloudWatch Logs 저장 비용이 S3보다 높음. Athena는 S3를 쿼리하는 서비스라 CloudWatch Logs를 직접 쿼리 불가. 추가 연동 설정이 필요하고 비용도 높음.
• B흐름 로그를 Amazon CloudWatch Logs에 게시하고, Amazon OpenSearch Service 클러스터로 분석합니다.
  ❌ OpenSearch Service — 클러스터를 항시 운영해야 하므로 시간당 인스턴스 비용이 발생. Athena(서버리스 온디맨드)보다 비용이 훨씬 높음.
• C흐름 로그를 Amazon S3에 텍스트 형식으로 게시하고, Amazon Athena로 분석합니다.
  ❌ S3 저장은 맞지만 텍스트 형식은 Athena 스캔 비용이 높음. Athena는 스캔한 데이터 바이트 단위로 과금되므로 Parquet 같은 압축 컬럼 형식 대비 비용이 크게 증가.
• D흐름 로그를 Amazon S3에 Apache Parquet 형식으로 게시하고, Amazon Athena로 분석합니다.
  ✅ Apache Parquet — 열 기반(Columnar) 압축 포맷. 필요한 컬럼만 스캔하므로 Athena 과금 기준인 스캔 데이터량이 크게 감소(텍스트 대비 최대 90% 절감). S3 저장 비용도 압축으로 절약. Athena — 서버리스, 사용한 만큼만 과금. 클러스터 상시 운영 비용 없음.

🎯

정답

D — S3 Parquet 형식 + Athena 분석 (최저 비용)

🔑 핵심 개념 — 로그 분석 방법 비용 비교

방법	스토리지 비용	분석 비용	서버리스?
S3 Parquet + Athena	낮음(압축)	낮음(컬럼 스캔)	✓
S3 텍스트 + Athena	낮음	높음(전체 스캔)	✓
CW Logs + Athena	높음	연동 복잡	✓
CW Logs + OpenSearch	높음	클러스터 상시 과금	✗

💡 이것만 기억하자

"로그 분석 + 비용 최적화" → S3 Parquet + Athena

Parquet = 열 형식 압축 → Athena 스캔량 최소화 → 비용↓
텍스트 형식 = 전체 스캔 → 비용↑
OpenSearch = 클러스터 상시 운영 비용 → 비용↑↑

AWS DEA-C01 Redshift CALL Glue 작업 북마크 Redshift 페더레이션 쿼리 Firehose Splunk VPC 흐름 로그 S3 Parquet Athena AWS 자격증