[analytics] Data Firehose
스트리밍 데이터를 S3나 Redshift로 그냥 흘려보내고 싶을 때. 서버 없이 알아서 실어 나르는 Firehose.
One-Line Summary
Data Firehose(구 Kinesis Data Firehose)는 스트리밍 데이터를 S3·Redshift·OpenSearch 등 목적지에 서버 없이 자동으로 적재(load) 해주는 완전관리형 전송 서비스다. 시험에서는 서버리스 스트리밍 적재 / 관리 불필요 / 근실시간(near real-time, 버퍼링) / 도중 Lambda 변환·포맷 변환(Parquet) 이 핵심이다. "스트리밍 데이터를 그냥 저장소로 흘려보내면 된다"면 Firehose다.
Why It Exists
Kinesis Data Streams로 데이터를 받으면, 그것을 S3나 Redshift에 넣는 소비자 코드와 인프라를 직접 만들고 운영해야 한다. 대부분의 경우 목표는 "그냥 안정적으로 적재"인데 이건 낭비다.
Data Firehose는 이 적재 파이프라인 자체를 완전관리형으로 대신해준다. 샤드도, 소비자 서버도 없다.
직접 구성
소스 -> KDS -> (직접 만든 소비자 EC2/Lambda) -> S3/Redshift (운영 부담)
Data Firehose
소스 -> Firehose -> S3 / Redshift / OpenSearch / Splunk / HTTP
(서버리스, 버퍼링·재시도·확장 자동, 코드 최소)
시험 감각:
"스트리밍 데이터를 서버 관리 없이 S3/Redshift/OpenSearch로 적재" = Data Firehose.
Abbreviations
| 약어 | 풀네임 | 의미 |
|---|---|---|
Firehose | Amazon Data Firehose | 스트리밍 데이터를 목적지로 자동 적재하는 완전관리형 서비스 |
Buffer | Buffer (size/interval) | 데이터를 모았다가 한 번에 보내는 크기/시간 기준 |
Delivery Stream | Delivery Stream | Firehose의 전송 단위(소스→목적지 연결) |
Parquet/ORC | Columnar format | 분석에 유리한 열 기반 저장 포맷 |
동작 방식과 버퍼링
Firehose는 데이터를 버퍼(크기 또는 시간) 만큼 모았다가 목적지로 보낸다. 그래서 완전 실시간이 아니라 근실시간(near real-time) 이다.
소스(KDS / 직접 PUT / CloudWatch Logs 등)
-> Firehose가 버퍼에 모음
(버퍼 크기 도달 or 버퍼 시간 경과 중 먼저 오는 것)
-> 필요 시 Lambda로 변환, 포맷 변환(JSON->Parquet)
-> 목적지로 전송(+ 실패분은 S3로 백업)
| 항목 | 내용 |
|---|---|
| 버퍼 기준 | 버퍼 크기(MB) 또는 버퍼 시간(초) 중 먼저 충족되는 쪽 |
| 지연 특성 | 근실시간(최소 버퍼 시간만큼 지연, 완전 실시간 아님) |
| 확장/운영 | 서버리스, 자동 확장, 샤드 개념 없음 |
시험 감각:
"완전 실시간(초 미만)"이 아니라 "몇 초~분 단위로 모아서 적재해도 된다" = Firehose로 충분.
지원 목적지 (Destinations)
| 유형 | 예 |
|---|---|
| AWS 저장/분석 | Amazon S3, Amazon Redshift, Amazon OpenSearch Service |
| 서드파티 | Splunk, Datadog, New Relic 등 HTTP 엔드포인트 |
가장 흔한 시험 패턴
스트리밍 로그 -> Firehose -> S3 (데이터 레이크)
스트리밍 로그 -> Firehose -> OpenSearch (검색/대시보드)
스트리밍 데이터 -> Firehose -> Redshift (S3 경유 COPY)
시험 감각:
"실시간 로그를 검색·시각화" = Firehose → OpenSearch. "스트리밍 데이터를 데이터 레이크에" = Firehose → S3.
도중 변환·포맷 변환 (빈출)
Firehose는 적재 전에 데이터를 가공할 수 있다.
| 기능 | 설명 |
|---|---|
| Lambda 변환 | 레코드를 Lambda로 실시간 정제/필터/포맷 변경 |
| 포맷 변환 | JSON → Parquet/ORC (열 기반, Athena/분석 비용·성능 개선) |
| 압축·암호화 | GZIP 등 압축, KMS 암호화 |
| 동적 파티셔닝 | 키(예: 날짜)별로 S3 경로를 나눠 저장 |
시험 감각:
"적재 전에 데이터를 변환/필터/Parquet로 변환" = Firehose + Lambda 변환 / 포맷 변환.
Firehose vs Kinesis Data Streams (핵심 비교, 빈출)
| 구분 | Data Firehose | Kinesis Data Streams |
|---|---|---|
| 주 목적 | 목적지로 적재(load) | 실시간 수집·처리(다중 소비) |
| 관리 | 완전관리형, 서버리스, 샤드 없음 | 샤드/용량 모드 관리 |
| 지연 | 근실시간(버퍼링) | 실시간(밀리초) |
| 데이터 보존/replay | 없음(적재 후 저장 안 함) | 최대 365일, replay 가능 |
| 다중 소비자 | 목적지로 보낼 뿐 | 여러 소비자 동시 소비 |
| 커스텀 처리 | Lambda 변환 정도 | Flink/Lambda 등 자유로운 처리 |
시험 감각:
"저장·적재가 목적, 서버 관리 싫다" = Firehose. "실시간 다중 소비·되감기·커스텀 처리" = KDS(필요 시 KDS→Firehose 조합).
Common Wrong Directions
| 오답 방향 | 왜 부족한가 |
|---|---|
| 완전 실시간(초 미만) 처리가 필요한데 Firehose | Firehose는 버퍼링 기반 근실시간 → 실시간은 KDS/Flink |
| 데이터를 나중에 다시 읽어야(replay) 하는데 Firehose | Firehose는 보존/replay 없음 → KDS |
| 여러 소비자가 동시에 처리해야 하는데 Firehose | Firehose는 적재 전용 → 다중 소비는 KDS |
| 단순 S3 적재인데 KDS+소비자 EC2 직접 구성 | 적재만이면 서버리스 Firehose가 운영 부담 최소 |
| 적재 전 변환을 위해 별도 파이프라인 구축 | Firehose 내장 Lambda 변환/Parquet 변환으로 충분 |
Exam Triggers
| 문제에서 이런 표현이 나오면 | 떠올릴 것 |
|---|---|
| "load streaming data into S3/Redshift/OpenSearch" | Data Firehose |
| "fully managed, no servers, minimal operations" | Data Firehose |
| "near real-time delivery / buffer then deliver" | Data Firehose |
| "transform records before loading / convert to Parquet" | Firehose + Lambda 변환 / 포맷 변환 |
| "stream logs to a search & visualization service" | Firehose → OpenSearch |
| "need to replay / multiple real-time consumers" | Data Firehose 아님 → KDS |
Memory Sentence
Data Firehose는 스트리밍 데이터를 S3·Redshift·OpenSearch로 서버 없이 자동 적재하는 근실시간 전송 서비스다. 버퍼링 기반이라 완전 실시간이 아니고, 보존·replay·다중 소비는 없다. 적재 전 Lambda 변환·Parquet 변환 가능. 실시간·다중 소비·되감기가 필요하면 KDS.
References
댓글
아직 댓글이 없습니다.