데이터 분석 파이프라인

파이프라인의 다섯 단계

분석 문항은 서비스 이름을 나열해 놓고 고르게 합니다. 이름을 하나씩 외우는 대신 단계로 환원하면 후보가 즉시 줄어듭니다. 데이터가 흐르는 순서는 언제나 같습니다.

Kinesis 제품군 — 스트리밍 수집

Amazon Kinesis Data Streams

Data Streams는 스트리밍 데이터를 실시간으로 처리하기 위한 관리형 서비스입니다. 스트림은 샤드(shard)로 나뉘고, 레코드는 파티션 키의 MD5 해시로 어느 샤드에 들어갈지 결정됩니다. 같은 파티션 키를 가진 레코드는 항상 같은 샤드로 가므로, 파티션 키 단위의 순서가 보장됩니다.

확장된 팬아웃(enhanced fan-out)은 소비자를 스트림에 등록한 뒤 HTTP/2 연결로 레코드를 밀어 주는 방식입니다. 소비자가 여럿이고 각자 빠르게 읽어야 할 때, 공유 대역을 나눠 쓰다 서로 굶는 상황을 없앱니다. 구독은 유지되는 동안 계속 이벤트를 받고, 일정 시간이 지나면 다시 구독해야 합니다.

프로비저닝 모드에서 용량을 바꾸는 방법은 SplitShard(분할) · MergeShards(병합) · UpdateShardCount(목표 개수 지정) 세 가지이며, 이 API들은 프로비저닝 모드에서만 동작합니다. 온디맨드 모드에서는 샤드를 직접 다루지 않습니다.

aws kinesis create-stream \
  --stream-name clickstream \
  --stream-mode-details StreamMode=ON_DEMAND

# 보존 기간은 시간 단위입니다. 24시간이 기본이고 최대 8760시간입니다.
aws kinesis increase-stream-retention-period \
  --stream-name clickstream \
  --retention-period-hours 168

Amazon Data Firehose

Firehose는 스트리밍 데이터를 목적지에 적재하는 완전관리형 서비스입니다. 샤드도, 소비자 애플리케이션도, 체크포인트도 없습니다. 스트림을 만들고 목적지를 지정하면 버퍼에 모았다가 배달합니다.

목적지는 Amazon S3, Amazon Redshift, Amazon OpenSearch Service, OpenSearch Serverless, Splunk, 임의의 HTTP 엔드포인트, Snowflake, Apache Iceberg 테이블입니다. 배달 전에 AWS Lambda 함수로 레코드를 변환할 수 있고, S3로 보낼 때는 형식 변환도 구성할 수 있습니다.

여기서 시험이 노리는 성질이 나옵니다. Firehose는 버퍼링이 있으므로 완전한 실시간이 아니고, 데이터를 보관하지 않으므로 재생(replay)할 수 없습니다. 배달이 끝나면 Firehose 안에 남는 것은 없습니다.

Data Streams와 Firehose의 선택 기준

판단 규칙은 두 문장입니다. 여러 소비자가 각자의 로직으로 처리해야 하거나, 나중에 다시 읽어야 하면 Data Streams입니다. 받아서 S3나 OpenSearch에 넣기만 하면 끝이고 운영 부담을 줄이고 싶으면 Firehose입니다. 둘을 이어 붙이는 구성도 흔합니다 — Data Streams로 받아 실시간 처리를 하면서, 같은 스트림을 소스로 하는 Firehose가 원본을 S3에 적재하는 형태입니다.

Amazon MSK — 언제 Kinesis 대신인가

Amazon MSK는 Apache Kafka를 관리형으로 제공합니다. 클러스터 유형은 PROVISIONED와 SERVERLESS 두 가지입니다. 기능만 보면 Data Streams와 겹치는 부분이 많지만, 선택 기준은 기능이 아닙니다.

• 이미 Kafka를 쓰고 있다 — 온프레미스나 다른 클라우드의 Kafka를 옮겨 오는 경우입니다. 프로듀서 · 컨슈머 코드와 Kafka 생태계 도구를 그대로 쓸 수 있다는 것이 결정적입니다.
• Kafka API에 의존하는 도구 체인이 있다 — Kafka Connect 커넥터, 스키마 레지스트리 등.
• Kafka 고유의 개념이 요구사항에 등장한다 — 토픽, 파티션, 컨슈머 그룹, 브로커.

반대로 새로 만드는 파이프라인이고 애플리케이션 코드를 자유롭게 쓸 수 있다면 Kinesis 쪽이 운영 부담이 적습니다. 문제에 "기존(existing)"이라는 단어와 "Kafka"가 함께 나오면 MSK를 고르는 것이 거의 항상 맞습니다.

"실시간"이라는 한정어 SAA 빈출

분석 문항에서 가장 강력한 신호는 real-time 또는 near-real-time이라는 단어입니다. 이 단어가 보이면 배치 도구는 전부 소거됩니다. AWS Glue 작업, Amazon EMR 배치 잡, 예약 실행되는 Lambda, S3에 쌓아 두고 나중에 도는 파이프라인은 답이 아닙니다.

AWS Glue — 카탈로그와 ETL

Glue는 두 가지 일을 합니다. 메타데이터를 관리하는 일과 변환 작업을 실행하는 일입니다. 시험에서는 앞쪽이 더 자주 나옵니다.

데이터 카탈로그가 왜 중요한가가 이 절의 핵심입니다. S3에 있는 파일은 그 자체로는 "어떤 컬럼이 있는지"를 모릅니다. 크롤러가 스키마를 추론해 카탈로그에 등록해야 Athena가 SQL로 조회할 수 있습니다. Athena가 답인 문제에서 Glue 크롤러가 함께 정답에 들어가는 이유가 이것입니다.

조회와 처리 — Athena, Redshift, EMR, OpenSearch Service

Amazon Athena

Athena는 API 문서 표현 그대로 "표준 SQL로 Amazon S3의 데이터를 직접 분석하는 대화형 쿼리 서비스"입니다. 서버리스라서 인프라를 준비할 것이 없고, 실행한 쿼리에 대해서만 비용을 냅니다. 쿼리는 병렬로 실행되며, 워크그룹으로 사용량과 권한을 분리합니다.

성능과 비용을 좌우하는 것은 S3에 데이터를 어떻게 두었는가입니다. 열 지향 형식(Parquet 등)으로 저장하고, 접두사로 파티션을 나누고, 파일을 지나치게 잘게 쪼개지 않는 것이 표준 권고입니다. Athena는 스캔한 데이터에 따라 요금이 정해지므로, 스캔량을 줄이는 설계가 곧 비용 최적화입니다.

aws athena start-query-execution \
  --query-string "SELECT status_code, COUNT(*) AS hits \
    FROM cloudfront_logs \
    WHERE year='2026' AND month='07' AND day='29' \
    GROUP BY status_code ORDER BY hits DESC" \
  --work-group primary \
  --result-configuration OutputLocation=s3://example-athena-results/

Amazon Redshift

Redshift는 데이터 웨어하우스입니다. 여러 소스에서 모은 정형 데이터를 클러스터에 적재해 두고 복잡한 조인과 집계를 반복 실행하는 용도입니다. Athena와의 경계는 반복성과 데이터 양에 있습니다.

가끔 임시로 조회한다면 Athena가 맞습니다. 상시 가동 클러스터가 필요 없기 때문입니다. 고정된 BI 대시보드가 하루 종일 무거운 쿼리를 돌린다면 Redshift가 맞습니다. Redshift Spectrum을 쓰면 클러스터에 적재하지 않은 S3 데이터까지 함께 조회할 수 있습니다. Redshift 자체는 11장에서 데이터베이스 관점으로 다룹니다.

Amazon EMR

EMR은 Hadoop 기반 처리를 관리형으로 제공합니다. Apache Spark, Hive 같은 오픈 소스 프레임워크를 클러스터에서 실행하며, 머신러닝 · 과학 시뮬레이션 · 대규모 로그 처리처럼 SQL 한 줄로 표현되지 않는 처리가 대상입니다.

시험에서 EMR이 정답이 되는 신호는 명확합니다 — Spark, Hadoop, Hive, HBase 같은 프레임워크 이름이 문제에 직접 등장하거나, 기존 Hadoop 워크로드를 옮긴다는 맥락입니다. 그런 신호가 없는데 EMR을 고르면 운영 부담 한정어에 걸립니다.

Amazon OpenSearch Service

OpenSearch Service는 로그와 문서를 색인해 검색하고 시각화합니다. Firehose의 배달 목적지 중 하나이기도 합니다. "로그를 검색해야 한다", "운영 대시보드에서 전문 검색이 필요하다", "이상 징후를 로그에서 찾아야 한다"가 신호입니다. 같은 로그라도 SQL 집계가 목적이면 Athena, 검색이 목적이면 OpenSearch Service입니다.

AWS Lake Formation

Lake Formation은 데이터 레이크의 권한 관리 계층입니다. S3 경로를 데이터 카탈로그가 관리하는 리소스로 등록하고, 데이터베이스 · 테이블 · 컬럼 단위로 권한을 부여합니다. S3 버킷 정책과 IAM 정책만으로는 표현하기 번거로운 "이 팀에는 이 테이블의 이 컬럼만"을 중앙에서 처리하는 것이 핵심 가치입니다.

문제에 "여러 팀이 같은 데이터 레이크를 쓰는데 세분화된 접근 제어가 필요하다"가 나오면 Lake Formation입니다.

Amazon QuickSight

QuickSight는 서버리스 비즈니스 인텔리전스(BI) 서비스입니다. Athena · Redshift · RDS · S3 등을 데이터 소스로 붙여 대시보드를 만듭니다. 파이프라인의 마지막 칸이며, 데이터를 처리하는 도구가 아니라 사람에게 보여 주는 도구입니다.

배치와 스트리밍 — 무엇으로 갈리는가

배치와 스트리밍의 차이는 기술이 아니라 요구사항의 시간 축입니다. "결과가 언제 필요한가"에 대한 답이 분 단위 이하면 스트리밍이고, 시간 단위 이상이면 배치입니다.

실무 파이프라인은 대개 둘을 함께 씁니다. Data Streams로 받은 이벤트를 즉시 처리해 경보를 내면서, 같은 데이터를 Firehose로 S3에 적재해 두었다가 Glue와 Athena로 나중에 분석하는 형태입니다. 시험 문항은 이 중 한쪽 요구만 제시하므로, 문장에서 시간 축을 찾는 것이 먼저입니다.

이름이 바뀐 서비스 정리

이 장에서 다루는 서비스는 최근 몇 년 사이에 이름이 바뀐 것이 많습니다. 옛 이름으로 된 자료를 읽을 때 같은 서비스임을 알아보지 못하면 그대로 오답으로 이어집니다.

흔한 오해

시험 포인트 정리

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

학습용 유형 연결형과 순서 배열 문항이 섞여 있을 수 있습니다. 이 두 유형은 암기 확인에 효율이 좋아서 기본개념 확인 문제에만 넣었으며, 실제 SAA-C03 시험에는 출제되지 않습니다.

이어서 볼 곳

• 14장 · 엣지와 DNS 이 장이 다루는 클릭스트림과 액세스 로그가 만들어지는 곳. CloudFront와 Route 53을 정리합니다. 기본개념
• 12장 · 서버리스와 애플리케이션 통합 Kinesis 소비자로 자주 쓰이는 Lambda, 그리고 큐와 스트림의 차이를 다룹니다. 기본개념 · SAA 최우선
• 8장 · S3와 오브젝트 스토리지 데이터 레이크의 저장 계층. 스토리지 클래스와 수명 주기가 분석 비용을 직접 좌우합니다. 기본개념 · SAA 최우선
• 11장 · NoSQL · 캐시 · 분석 DB Redshift를 데이터베이스 관점에서 다루고, DynamoDB 스트림과의 관계도 정리합니다. 기본개념
• 한정어 키워드 사전 real-time, LEAST operational overhead 같은 한정어가 어떤 답을 가리키는지 모아 두었습니다. 시험 대비 · 최우선
• 헷갈리는 쌍 비교 Data Streams 대 Firehose를 포함해 시험이 노리는 비교쌍을 한 장에 모았습니다. 빠른참조

공식 문서 출처

이 장의 개념 서술과 API 동작은 모두 아래 문서에서 확인했습니다.

• Amazon Kinesis Data Streams API 레퍼런스 — CreateStream — 샤드당 읽기 5 트랜잭션/초 · 2 MiB/초, 쓰기 1,000 레코드/초 · 1 MiB/초, 온디맨드와 프로비저닝 용량 모드
• Amazon Kinesis Data Streams API 레퍼런스 — PutRecord — 파티션 키의 MD5 해시로 샤드를 정한다는 서술, 기본 보존 24시간
• Amazon Kinesis Data Streams API 레퍼런스 — PutRecords — 배치 전송이 순서를 보장하지 않는다는 서술과 부분 실패 처리
• Amazon Kinesis Data Streams API 레퍼런스 — IncreaseStreamRetentionPeriod — 최대 보존 8,760시간(365일)
• Amazon Kinesis Data Streams API 레퍼런스 — RegisterStreamConsumer — 확장된 팬아웃이 구독 샤드당 2 MiB/초를 제공하며 소비자 수에 영향받지 않는다는 서술
• Amazon Data Firehose API 레퍼런스 — "Amazon Data Firehose was previously known as Amazon Kinesis Data Firehose"라는 개명 사실과 배달 목적지 목록
• Amazon Data Firehose API 레퍼런스 — BufferingHints — 버퍼 크기 기본 5 MiB(1~128), 버퍼 간격 기본 300초(0~900)
• Amazon Data Firehose API 레퍼런스 — CreateDeliveryStream — 소스 유형 DirectPut · KinesisStreamAsSource · MSKAsSource와 목적지 구성
• Amazon MSK API 레퍼런스 — 클러스터 유형 PROVISIONED와 SERVERLESS
• Amazon Athena API 레퍼런스 — 표준 SQL로 S3 데이터를 직접 분석하는 서버리스 대화형 쿼리 서비스라는 정의, 실행한 쿼리에만 과금
• AWS Glue API 레퍼런스 — CreateCrawler — 크롤 대상(S3 · JDBC · DynamoDB)과 일정 실행
• AWS Glue API 레퍼런스 — Crawler — 분류자로 스키마를 추론해 데이터 카탈로그에 메타데이터를 기록한다는 정의
• Amazon EMR API 레퍼런스 — Hadoop 처리 기반의 대규모 데이터 처리 서비스라는 정의
• AWS Lake Formation API 레퍼런스 — RegisterResource — S3 경로를 데이터 카탈로그가 관리하는 리소스로 등록하는 절차
• AWS Lake Formation API 레퍼런스 — GrantPermissions — 데이터 카탈로그 메타데이터와 기반 데이터에 대한 권한 부여
• Amazon OpenSearch Service API 레퍼런스 — 서비스 정식 명칭과 도메인 구성 API
• Amazon QuickSight API 레퍼런스 — 완전관리형 서버리스 비즈니스 인텔리전스 서비스라는 정의
• SAA-C03 시험 가이드 — 범위 밖 서비스 — Managed Service for Apache Flink가 시험 범위 밖이라는 근거