One-Line Summary
데이터 분석 문제는 보통 ① 스트리밍 데이터를 어떻게 받고(수집) → ② 실시간/배치로 어떻게 가공(처리) → ③ 어디에 저장·카탈로그화(적재/메타) → ④ 어떻게 조회·분석(쿼리) 하는지, 그 파이프라인의 어느 단계를 묻는지로 나누면 풀린다. 관측성(CloudWatch/X-Ray/Performance Insights)은 "무엇을, 어느 계층에서 보는가"로 구분한다.
Abbreviations
| 약어 | 풀네임 | 의미 |
|---|
KDS | Kinesis Data Streams | 실시간 스트리밍 수집·보관 |
Firehose | Amazon Data Firehose | 스트리밍 데이터를 목적지로 적재 |
Flink | Managed Service for Apache Flink | 실시간 스트림 처리·분석 |
Glue | AWS Glue | 서버리스 ETL + Data Catalog |
Athena | Amazon Athena | S3를 SQL로 조회(서버리스) |
EMR | Elastic MapReduce | 관리형 Hadoop/Spark 클러스터 |
Redshift | Amazon Redshift | 데이터 웨어하우스(OLAP) |
OLAP/OLTP | Analytical / Transactional | 분석 처리 / 트랜잭션 처리 |
Big Picture — 파이프라인 단계별
| 요구사항 | 먼저 떠올릴 서비스 |
|---|
| 실시간 스트리밍 데이터 수집(다중 소비/replay) | Kinesis Data Streams |
| 스트리밍 데이터를 S3/Redshift/OpenSearch로 적재 | Data Firehose |
| 흐르는 데이터를 실시간 집계·이상탐지 | Managed Service for Apache Flink |
| 서버리스 ETL + 스키마 카탈로그 | AWS Glue |
| 스키마 자동 발견 | Glue Crawler |
| S3 데이터를 즉석 SQL로 조회 | Amazon Athena |
| PB급 Hadoop/Spark 대규모 처리·클러스터 제어 | Amazon EMR |
| 복잡·빈번한 분석 쿼리(BI/OLAP) 웨어하우스 | Amazon Redshift |
| 로드 없이 S3를 웨어하우스에서 조회 | Redshift Spectrum |
| 리소스 지표·경보·로그 모니터링 | Amazon CloudWatch |
| 마이크로서비스 요청 흐름·병목 추적 | AWS X-Ray |
| DB 부하 유발 SQL 식별 | RDS Performance Insights |
스트리밍 3형제 — 받기·처리·적재
[받기] Kinesis Data Streams -> [처리] Flink -> [적재] Data Firehose -> S3/Redshift/OpenSearch
| 서비스 | 역할 | 실시간성 | 보존/replay |
|---|
| Kinesis Data Streams | 수집·보관(다중 소비) | 실시간(ms) | 있음(최대 365일) |
| Managed Service for Apache Flink | 실시간 처리·집계·이상탐지 | 실시간 | (스트림 처리) |
| Data Firehose | 목적지로 적재 | 근실시간(버퍼) | 없음 |
쿼리·분석 3형제 — Athena vs EMR vs Redshift
| 구분 | Athena | EMR | Redshift |
|---|
| 모델 | 서버리스 SQL 조회 | 관리형 클러스터 | 데이터 웨어하우스 |
| 데이터 위치 | S3 그 자리 | S3(EMRFS)/HDFS | 웨어하우스(+Spectrum으로 S3) |
| 적합 | 간헐적·즉석 조회 | 대규모·커스텀 빅데이터 | 복잡·빈번한 분석(BI) |
| 운영 부담 | 없음 | 큼(세밀 제어) | 중간(관리형) |
| 대표 키워드 | serverless, ad-hoc, query S3 | Spark/Hadoop, petabyte, control | data warehouse, OLAP, BI |
관측성 3형제 — 무엇을, 어느 계층에서
| 서비스 | 답하는 질문 | 계층 |
|---|
| CloudWatch | 지표가 임계치를 넘었나? 로그는? | 인프라/운영 |
| X-Ray | 어느 서비스 구간이 느린가? | 애플리케이션 요청 |
| Performance Insights | 어떤 SQL이 DB 부하를 만드나? | 데이터베이스 내부 |
(감사/API 기록 "누가 무엇을 했나"는 CloudTrail — CloudWatch와 반드시 구분)
Common Wrong Directions
| 오답 방향 | 왜 부족한가 |
|---|
| 단순 S3 적재에 KDS + 직접 소비자 구성 | 적재만이면 서버리스 Firehose |
| 실시간 다중 소비·replay를 SQS/Firehose로 | 다중 소비·되감기는 KDS |
| 실시간 집계를 Athena/배치로 | 흐름 중 계산은 Flink |
| 즉석 S3 조회에 상시 Redshift 클러스터 | 간헐적이면 Athena |
| 트랜잭션(OLTP)을 Redshift로 | OLTP는 RDS/Aurora, Redshift는 OLAP |
| 서버리스 ETL이면 되는데 EMR 상시 클러스터 | 운영 최소 ETL은 Glue |
| "누가 API 호출했나"를 CloudWatch로 | 감사 기록은 CloudTrail |
| DB 부하 SQL을 CloudWatch로 | 원인 SQL은 Performance Insights |
Exam Triggers
| 문제에서 이런 표현이 나오면 | 떠올릴 것 |
|---|
| "real-time streaming ingestion, multiple consumers, replay" | Kinesis Data Streams |
| "load streaming data into S3/Redshift/OpenSearch, no servers" | Data Firehose |
| "real-time aggregation / window / anomaly detection" | Managed Service for Apache Flink |
| "serverless ETL / data catalog / crawl schema" | AWS Glue |
| "query data in S3 with SQL, serverless, ad-hoc" | Amazon Athena |
| "petabyte-scale Spark/Hadoop, cluster control" | Amazon EMR |
| "data warehouse, complex frequent analytical queries, BI" | Amazon Redshift |
| "metrics/alarms/logs" | CloudWatch |
| "trace requests across microservices" | X-Ray |
| "which SQL causes high DB load" | Performance Insights |
Memory Sentence
데이터 분석은 받기(Data Streams)→처리(Flink)→적재(Firehose)→저장·카탈로그(Glue/S3)→조회(Athena·Redshift·EMR)의 파이프라인이다. 간헐적 S3 조회=Athena, 대규모 Spark=EMR, 복잡·상시 분석=Redshift. 관측은 지표=CloudWatch, 요청추적=X-Ray, DB부하SQL=Performance Insights, API감사=CloudTrail.
Notes To Expand
References
