Day 5 - Week 2 종합: 데이터 수집 1 복습

한 장으로 보는 수집 서비스 지도

이번 주는 데이터 엔지니어링의 출발점인 "수집(ingestion)"을 배치와 스트리밍으로 나눠 훑었다. 오늘은 흩어진 조각을 하나의 의사결정 지도로 묶는다. DEA-C01 수집 도메인 문제의 9할은 "이 시나리오에 어떤 서비스를 골라야 하나"이고, 그 답은 항상 키워드에서 나온다. 이 종합편의 목표는 시나리오 → 서비스 매핑을 반사적으로 떠올리게 만드는 것이다.

                        데이터 수집
                            │
        ┌───────────────────┴───────────────────┐
      배치(Batch)                          스트리밍(Streaming)
        │                                       │
  ┌─────┼─────────┬──────────┐         ┌────────┼──────────┬─────────┐
S3 업로드  DataSync  Transfer   Snow     KDS      Firehose    MSK
(단발/소량) (반복/대량) Family    (PB/느린  (실시간   (근실시간    (기존
           동기화·검증 (SFTP 수신) 회선)    멀티컨슈머 단순적재)    Kafka)
                                          ·재처리)

배치 4종 복습

💡 관련 이론: 배치 선택의 두 축은 "데이터양"과 "회선 상황"이다. 회선이 충분하면 온라인(DataSync), 부족하거나 데이터가 너무 크면 오프라인(Snow). 그리고 "내가 끌어오는가(DataSync) vs 외부가 밀어넣는가(Transfer Family)"라는 방향 축이 추가된다. 이 두 축만 잡으면 배치 문제는 거의 다 풀린다.

스트리밍 3종 복습

KDS      : 실시간 파이프. 샤드 단위. 멀티 컨슈머·재처리 가능. 컨슈머 코드 직접 작성.
Firehose : 근실시간 적재 파이프. 버퍼링 후 S3/Redshift/OpenSearch에 자동 적재. 코드 거의 없음.
MSK      : 관리형 Apache Kafka. 표준 오픈소스·이식성. 기존 Kafka 자산 이전에 최적.

핵심 구분 세 가지를 다시 못 박자.

1. KDS vs Firehose — 복잡한 실시간 처리·여러 컨슈머·재처리면 KDS, 단순 적재면 Firehose. 둘을 잇는 조합(KDS 소스 → Firehose가 S3 적재)은 "실시간 분석 + 원본 보관" 시나리오의 정답.
2. Kinesis vs MSK — "기존 Apache Kafka"가 보이면 MSK, "최소 운영·AWS 네이티브·단순 적재"면 Kinesis.
3. 로그 모델 공통점 — KDS·Kafka는 모두 append-only 로그라 소비해도 안 사라지고 멀티 컨슈머·재처리가 된다. SQS와 다르다.

# 종합 패턴: KDS(실시간 분석) + Firehose(원본 S3 보관) 동시 운용
import boto3
firehose = boto3.client("firehose")
 
firehose.create_delivery_stream(
    DeliveryStreamName="raw-archive",
    DeliveryStreamType="KinesisStreamAsSource",          # 소스를 KDS로 지정
    KinesisStreamSourceConfiguration={
        "KinesisStreamARN": "arn:aws:kinesis:...:stream/clickstream",
        "RoleARN": "arn:aws:iam::123456789012:role/firehose-role"
    },
    S3DestinationConfiguration={
        "BucketARN": "arn:aws:s3:::my-data-lake",
        "RoleARN": "arn:aws:iam::123456789012:role/firehose-role",
        "BufferingHints": {"SizeInMBs": 128, "IntervalInSeconds": 300},
        "CompressionFormat": "GZIP"
    }
)
# 같은 clickstream을 실시간 분석 Lambda가 별도로 소비 → 분석 + 보관 동시 달성

잘 설계된 스트리밍 아키텍처는 "수집 → 처리 → 적재"가 느슨하게 결합된다. KDS/MSK가 수집·버퍼 역할을 하면서 여러 다운스트림(실시간 분석, 데이터 레이크 적재, 검색 인덱싱)을 동시에 먹인다. 이 분리 덕분에 한 컨슈머가 느려져도 다른 컨슈머나 프로듀서가 막히지 않는다. 로그 기반 스트림이 단순 큐보다 데이터 플랫폼에 적합한 이유다.

자주 틀리는 함정 정리

• 멀티파트 미완료 조각 → 보이지 않는 S3 비용, Lifecycle abort 규칙으로 해결
• 핫 샤드/핫 파티션 → 편향된 파티션 키, 카디널리티 높은 키로 교체
• 작은 파일 문제 → Firehose 버퍼 크기를 키워 큰 파일로 적재
• Firehose는 재처리 불가 → 재처리·멀티 컨슈머가 필요하면 KDS
• 병렬성 상한 = 샤드/파티션 수 → 컨슈머만 늘려도 소용없음
• Redshift 적재는 S3 경유 COPY → 단건 INSERT 아님

판별 순서: 다섯 번 물으면 하나가 남는다

① 무엇이 들어오나?
   ├─ 파일·객체 덩어리 ───────────────► 배치 쪽 (②로)
   └─ 끊임없이 생기는 작은 레코드 ────► 스트리밍 쪽 (④로)

② 누가 움직이나?
   ├─ 외부 파트너가 SFTP/FTPS 로 올린다 ► Transfer Family
   └─ 우리가 가져온다 (③으로)

③ 회선과 규모는?
   ├─ 소량·단발 ───────────────────────► S3 업로드(CLI/SDK, 큰 파일은 멀티파트)
   ├─ 대량·반복, 회선 충분 ────────────► DataSync
   └─ 회선 부족 또는 초대용량·일회성 ──► Snow 패밀리

④ 기존 자산이 있나?
   ├─ Kafka 코드·커넥터·팀 ────────────► MSK (용량 관리도 싫으면 MSK Serverless)
   └─ 없음 (⑤로)

⑤ 읽는 쪽 요구는?
   ├─ 목적지에 쌓기만 하면 된다 ───────► Data Firehose
   ├─ 여러 앱이 각자 읽는다 / 재처리 ──► Kinesis Data Streams
   └─ 둘 다 ───────────────────────────► KDS + Firehose(KDS 를 소스로)

• ①을 건너뛰고 ⑤부터 보면 틀린다. "매일 밤 파일 서버 동기화" 문제에 Firehose 를 고르는 실수가 여기서 나온다.
• ④가 ⑤보다 앞이다. "기존 Apache Kafka"가 지문에 있으면 읽는 쪽 요구가 무엇이든 MSK 계열이 먼저다.

스트리밍 3종 정밀 비교

지난 사흘의 내용을 같은 축으로 한 표에 놓았다. 가로로 읽으면 차이가 보인다.

• 세 서비스는 대체재이면서 조합재다. KDS → Firehose, MSK → Firehose 는 모두 정식 구성이다. 보기에 조합이 나오면 "각자 맡은 역할이 겹치지 않는가"로 판단한다.

Week 2 숫자·기본값 한 장

• 한도는 대부분 조정 가능한 기본값이고 리전에 따라 다르다. 시험이 묻는 것은 숫자 자체보다 "어느 한도에 먼저 걸리는가" 다. 예를 들어 레코드가 작으면 바이트보다 건수 한도가 먼저, 컨슈머가 많으면 쓰기보다 읽기 한도가 먼저 찬다.

시나리오 연습: 단서에서 정답까지

연습 문제와 겹치지 않는 상황이다. 결정적 단서 열을 가리고 먼저 답해 본다.

증상 → 원인 → 조치

⚠️ 함정: 표의 조치 중 "샤드를 늘린다"가 정답인 줄은 생각보다 적다. 쏠림은 키 문제, 읽기 경쟁은 팬아웃 문제, 막힘은 오류 처리 문제다. 용량 증설은 "모든 샤드가 고르게 한도에 닿았을 때"에만 맞는 처방이다.

Week 3는 수집의 나머지 절반 — 스트림 위에서의 실시간 처리와 윈도우, 수집 신뢰성(멱등성·재시도·DLQ), DMS 와 CDC, 이벤트 기반 아키텍처 — 으로 넘어간다. 오늘 만든 "무엇으로 들여오나"의 지도 위에 "들여온 흐름을 어떻게 안전하게 다루나"가 얹힌다. 수집 도메인의 키워드 매핑은 이 지도에서 확인한다.

📖 용어

• 수집(ingestion) : 원천의 데이터를 분석 환경으로 들여오는 단계. 배치와 스트리밍으로 나뉜다.
• 증분 동기화 : 지난 실행 이후 바뀐 것만 골라 옮기는 방식. DataSync 의 스케줄 작업이 대표적이다.
• append-only 로그 : 뒤에 덧붙이기만 하는 기록 구조. 읽어도 지워지지 않아 여러 소비자가 각자 위치에서 다시 읽을 수 있다.
• 팬아웃 : 하나의 스트림을 여러 소비자가 독립적으로 받아 가는 것.
• 재처리(replay) : 보존 기간 안의 과거 레코드를 처음부터 다시 읽어 처리하는 것.
• 핫 샤드 / 핫 파티션 : 키가 쏠려 특정 샤드·파티션에만 부하가 몰리는 현상.
• 독약 레코드(poison pill) : 처리할 때마다 실패해 뒤 레코드의 처리를 막는 레코드.
• 스테이징 : 최종 목적지에 넣기 전에 잠시 거치는 중간 저장 위치. Firehose 의 Redshift 적재는 S3 를 스테이징으로 쓴다.
• at-least-once : 최소 한 번은 전달하되 중복이 생길 수 있는 전달 보장. 받는 쪽이 중복을 견디게 설계한다.