기준: DEA-C01 시험 가이드오류 제보

DEA-C01· AssociateWeek 3 · Day 5읽기 약 16분

핵심 정리

Week 3의 네 축은 스트림 처리(Managed Flink)·수집 신뢰성·CDC(DMS)·결합 패턴이며, 하나의 파이프라인 안에서 서로 맞물린다.
전달은 at-least-once가 기본이다. 멱등 컨슈머를 더해 effectively-once를 만들고, 순서는 샤드·메시지 그룹 단위로만 보장한다.
서비스 선택은 "재생(replay)이 필요한가, 메시지 단위 삭제·재시도가 필요한가, 내용으로 라우팅해야 하는가" 세 질문으로 갈린다.
장애 문제는 증상에서 원인을 거꾸로 찾는다 — 중복 처리는 가시성 타임아웃, CDC 누락은 원본 로그 설정, 지연 증가는 처리 용량이다.
실패 레코드는 버리지 말고 DLQ·실패 대상(on-failure destination)으로 격리해 원인을 고친 뒤 재처리한다.

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

한 장으로 보는 Week 3

한 주 동안 데이터 수집의 "어려운 절반"을 다뤘다. Week 2가 "데이터를 어떻게 받아들이는가"의 기초였다면, Week 3는 "그 수집이 실시간이고, 장애가 나고, 운영 DB가 멈출 수 없고, 여러 컴포넌트가 얽혀 있을 때 어떻게 견고하게 만드는가"였다. 오늘은 흩어진 조각을 하나의 그림으로 다시 맞춘다.

핵심 질문 하나로 묶는다. "끝없이 흘러드는 데이터를, 중복·순서 뒤바뀜·장애 속에서, 운영 시스템을 멈추지 않고, 여러 소비자가 각자 활용하도록 어떻게 수집할 것인가." 이번 주의 다섯 날이 이 질문의 다섯 부분에 정확히 대응한다.

Day	주제	핵심 한 줄
Day1	스트리밍 처리(Managed Flink)	무한 스트림에 윈도우로 경계를 긋고 워터마크로 결과 시점을 정한다
Day2	수집 신뢰성	at-least-once 전달 + 멱등 컨슈머 = effectively-once
Day3	CDC / DMS	전체를 다시 읽지 말고 트랜잭션 로그로 변경만 따라간다
Day4	아키텍처 패턴	Lambda/Kappa로 처리를, SQS/SNS/EventBridge로 결합을 설계한다

흐름으로 다시 읽기: 하나의 파이프라인

이번 주 개념을 하나의 가상 파이프라인에 모두 배치한다.

[운영 RDS MySQL]
   │  (Day3) DMS Full Load + CDC, binlog ROW 필요
   ▼
[Kinesis Data Streams]  ── PartitionKey=userId (Day2 순서 보장)
   │
   ├─(Day4 팬아웃)→ [Firehose] → S3 raw  ──(Day4 Batch Layer)
   │
   ▼ (Day1 Speed Layer)
[Managed Flink]  Event time + Watermark + Tumbling window
   │  체크포인트로 exactly-once 처리
   ├─→ OpenSearch (실시간 대시보드)
   └─→ 실패 레코드 → (Day2) SQS DLQ / OnFailure destination

이 그림 안에 이번 주 전부가 들어 있다. DMS가 운영 DB의 변경을 무중단으로 캡처(Day3)하고, Kinesis가 순서를 보장하며 받아(Day2), 한쪽은 S3로 적재(배치)하고 한쪽은 Flink로 실시간 집계(Day1)한다 — 전형적인 Lambda 아키텍처(Day4)다. 처리 실패는 DLQ로 격리되고(Day2), 컴포넌트들은 스트림/큐로 느슨하게 결합된다(Day4).

이 파이프라인은 데이터 엔지니어링의 두 가지 불변 원칙을 보여준다. 첫째, 원본 보존(immutable raw) — S3 raw 레이어는 절대 수정하지 않고, 잘못은 재처리로 바로잡는다. 둘째, 단일 진실 공급원(single source of truth)에서의 다중 뷰 — 같은 데이터를 배치 뷰와 실시간 뷰로 각자 재구성한다. 수집 설계의 견고함은 이 두 원칙을 지키는 데서 나온다.

자주 헷갈리는 선택지 정리

시험에서 "무엇을 고를까"로 헷갈리는 쌍들을 묶어둔다.

상황	선택	이유
윈도우 집계·스트림 조인·상태 처리	Managed Flink	복잡한 stateful 처리
단순 변환 후 S3 적재	Firehose + Lambda	Flink는 과한 설계
중복 가능 환경에서 정합성	멱등 컨슈머(DynamoDB 조건부 쓰기)	exactly-once 전달은 불가
사용자별 순서 보장	Kinesis PartitionKey=userId / SQS FIFO GroupId	파티션/그룹 단위 순서
운영 DB 무중단 분석 복제	DMS Full Load + CDC	표준 무중단 마이그레이션
스키마·저장 프로시저 변환	SCT	DMS는 데이터만
한 이벤트 → 여러 내구성 컨슈머	SNS → SQS 팬아웃	분배 + 버퍼
콘텐츠 기반 라우팅, AWS 이벤트	EventBridge	패턴 매칭 + 서비스 이벤트
로직 중복 없이 실시간 중심	Kappa	스트림 단일 + replay

⚠️ 함정 모음: (1) CDC가 안 되면 원본 로그 설정(binlog ROW / wal_level=logical / supplemental logging)을 먼저 의심한다. (2) SQS 가시성 타임아웃 < 실제 처리 시간이면 중복 처리가 난다. (3) Flink millisBehindLatest 지속 증가 = 처리량 부족, 병렬성/샤드를 늘려야 한다. (4) SNS 단독은 컨슈머 다운 시 유실 위험 → 내구성이 필요하면 SQS를 끼운다. (5) Lambda 아키텍처의 숨은 비용은 로직 이중 구현이다.

핵심 개념 셀프 체크

스스로 답할 수 있는지 점검한다.

□ Event time / Processing time / Ingestion time의 차이는?
□ 워터마크는 무엇을 결정하는가? (→ 윈도우 결과를 언제 확정할지)
□ Tumbling / Sliding / Session 윈도우를 한 줄로 구분할 수 있는가?
□ "exactly-once 전달은 불가하지만 ___ 처리는 가능"의 빈칸은? (→ exactly-once)
□ 멱등성 키는 누가 부여해야 하는가? (→ 프로듀서)
□ Kinesis 순서 보장 단위 / SQS FIFO 순서 보장 단위는?
□ 지수 백오프에 지터를 더하는 이유는? (→ thundering herd 분산)
□ DLQ의 maxReceiveCount는 무엇을 의미하는가?
□ DMS Full Load + CDC의 3단계 동작은?
□ CDC가 읽는 것은? (→ 트랜잭션 로그)
□ Lambda vs Kappa의 핵심 트레이드오프는? (→ 로직 중복 vs replay)
□ SQS / SNS / EventBridge의 한 줄 역할 구분은?

🎯 종합 시나리오: 글로벌 게임사가 "운영 DB의 결제 기록을 데이터 레이크에 근실시간 반영하면서, 동시에 최근 5분 지역별 매출을 실시간 대시보드에 표시"하려 한다. 설계: (1) DMS CDC로 결제 DB 변경을 Kinesis로 송출(Day3) → (2) PartitionKey=region으로 지역별 순서 유지(Day2) → (3) Firehose가 S3 raw에 Parquet 적재(배치 경로) → (4) Managed Flink가 region별 5분 Tumbling window로 매출 집계 후 OpenSearch에 싱크(실시간 경로, Day1) → (5) 전체는 Lambda 아키텍처(Day4), 처리 실패는 DLQ 격리(Day2), 멱등성으로 CDC 재전송 중복 무해화(Day2). 이 한 문제가 Week 3 전부를 묶는다.

스트림·큐·토픽·버스: 네 서비스를 가르는 판별 축

Day2와 Day4에서 따로 본 Kinesis Data Streams, SQS, SNS, EventBridge를 같은 축 위에 올려놓으면 선택이 쉬워진다. 핵심은 "메시지를 읽은 뒤 무슨 일이 일어나는가"다.

판별 축	Kinesis Data Streams	SQS	SNS	EventBridge
모델	로그(스트림)	큐	펍/섭 토픽	이벤트 버스
읽은 뒤 데이터	남는다(보존 기간이 지나야 만료)	컨슈머가 삭제해야 사라진다	저장하지 않고 구독자에게 푸시	저장하지 않고 규칙에 맞는 타깃에 전달
여러 소비자	각자 독립된 위치에서 같은 데이터를 읽는다	한 메시지는 한 컨슈머가 처리	구독자 전원에게 복제	규칙에 매칭된 타깃마다 전달
재생(replay)	보존 기간 안에서 가능	불가(삭제되면 끝)	불가	아카이브를 따로 만들어 둔 경우에만
순서	샤드 내	FIFO는 메시지 그룹 내, Standard는 보장 없음	표준 토픽은 보장 없음	보장 없음
보존	기본 24시간, 최대 365일	기본 4일, 최소 60초~최대 14일	—	—
전달 실패	컨슈머가 같은 위치를 다시 읽는다	가시성 타임아웃 뒤 재노출 → DLQ	재시도 뒤 DLQ(설정 시)	기본 24시간·최대 185회 재시도 뒤 폐기, DLQ 설정 가능

재생이 필요하면 스트림이다. 집계 로직의 버그를 고친 뒤 지난 데이터를 다시 흘려야 하거나(Kappa), 새 컨슈머가 과거 시점부터 읽어야 한다면 큐·토픽으로는 안 된다. Kinesis의 보존 기간을 24시간보다 길게 잡으면 추가 요금이 붙으므로, 더 먼 과거는 S3 원본으로 재처리하는 편이 싸다.
메시지 하나하나의 성공·실패를 따로 관리하려면 큐다. SQS는 메시지 단위로 삭제·재시도·DLQ 격리가 된다. 스트림은 샤드 안에서 순서대로 읽으므로 한 레코드의 실패가 그 뒤 레코드를 막는다.
용량 산정 방식이 다르다. Kinesis 프로비저닝 모드는 샤드당 쓰기 1MB/초 또는 1,000레코드/초, 읽기 2MB/초가 기준이라 샤드 수를 직접 계산해야 한다. 온디맨드 모드는 트래픽에 맞춰 샤드 수를 자동으로 조정한다. SQS Standard는 용량 산정이 사실상 필요 없다.
소비자가 늘면 읽기 한도를 나눠 쓴다. 샤드의 읽기 2MB/초는 GetRecords로 읽는 컨슈머들이 공유한다. 컨슈머가 여럿이고 지연이 문제라면 향상된 팬아웃(등록 컨슈머)으로 컨슈머마다 전용 처리량을 받는다.

⚠️ 함정: "순서 보장 + 정확히 한 번"이라는 단서만 보고 SQS FIFO를 고르면 절반만 맞다. FIFO의 중복 제거는 보내는 쪽의 재전송을 5분 창 안에서 걸러 줄 뿐이다. 컨슈머가 처리 도중 죽어 가시성 타임아웃이 지나면 같은 메시지를 다시 받는다. 처리 결과의 정합성은 여전히 멱등 컨슈머가 책임진다.

증상에서 원인으로: 장애 역추적표

시험의 장애 문제는 대부분 "이런 증상이 보인다. 원인과 조치는?" 형태다. 이번 주에 나온 증상을 한 표로 모은다.

증상	가장 흔한 원인	조치
같은 SQS 메시지가 두 번 처리된다	가시성 타임아웃(기본 30초)이 실제 처리 시간보다 짧다	타임아웃을 최대 처리 시간보다 길게 잡거나, 처리 중 `ChangeMessageVisibility`로 연장한다(첫 수신 시점부터 최대 12시간)
FIFO 큐에서 특정 그룹만 멈춰 있다	같은 `MessageGroupId`의 앞 메시지가 처리 중이면 뒤 메시지는 나오지 않는다	독약 메시지를 DLQ로 빼고, 그룹 ID를 더 잘게 나눠 병렬성을 확보한다
한참 뒤의 재전송이 중복으로 들어온다	FIFO 중복 제거 창(5분) 밖이다	DynamoDB 조건부 쓰기 기반 멱등성 테이블로 기간을 직접 정한다
Kinesis의 특정 샤드만 쓰기 스로틀이 난다	파티션 키가 쏠린 핫 샤드. 같은 키는 항상 같은 샤드로 간다	키의 카디널리티를 높인다. 샤드를 늘려도 한 키의 트래픽은 나뉘지 않는다
Kinesis→Lambda에서 한 샤드의 처리가 멈춘다	실패한 배치를 레코드가 만료될 때까지 재시도하는 것이 기본 동작이다	`MaximumRetryAttempts`·`MaximumRecordAgeInSeconds`로 상한을 두고, `BisectBatchOnFunctionError`와 실패 대상을 설정한다
Flink `millisBehindLatest`가 계속 오른다	처리 용량이 유입량을 못 따라간다	병렬성(KPU)을 늘리고, 소스 샤드 수와 핫 키를 함께 점검한다
DMS Full Load는 끝났는데 변경분이 안 온다	원본 로그 설정 누락(binlog ROW / `wal_level=logical` / supplemental logging)	원본 설정을 켠 뒤 태스크를 다시 시작한다
`CDCLatencyTarget`만 오른다	대상 쓰기가 병목이다	대상의 적재·커밋 부담과 용량을 본다. 원본 쪽 문제가 아니다
EventBridge 타깃에 이벤트가 드문드문 빠진다	재시도를 소진한 이벤트는 폐기된다	타깃에 DLQ를 달아 실패 이벤트를 받아 둔다

Kinesis→Lambda의 실패 대상을 SQS·SNS로 지정하면 레코드 본문이 아니라 메타데이터(스트림 ARN, 샤드 ID, 시작·끝 시퀀스 번호)만 전달된다. 원본은 그 시퀀스 번호로 스트림에서 다시 읽어야 하므로, 스트림 보존 기간이 지나기 전에 조사해야 한다. S3를 대상으로 지정하면 호출 레코드 전체가 함께 저장된다. SQS의 DLQ가 메시지 자체를 옮겨 담는 것과 다른 점이다.

"exactly-once"가 가리키는 범위

이번 주에 exactly-once라는 말이 여러 번 나왔지만, 가리키는 범위가 서로 다르다. 보기에서 "어느 계층의 보장인가"를 구분해야 한다.

Flink 체크포인트의 exactly-once는 Flink 내부 상태에 대한 보장이다. 장애가 나면 마지막 체크포인트로 돌아가 소스를 다시 읽으므로, 그 사이에 이미 싱크로 나간 결과는 한 번 더 나갈 수 있다. 싱크가 멱등(같은 키로 덮어쓰기)이거나 트랜잭션을 지원해야 끝에서 끝까지 정합성이 맞는다.
SQS FIFO의 exactly-once는 큐에 중복이 들어오지 않게 하는 것(5분 창)이 핵심이다. 소비 쪽 재전달은 위 함정대로 남는다.
그래서 어느 조합을 쓰든 마지막 방어선은 같다 — 쓰는 쪽을 멱등하게 만든다. 조건부 쓰기, 자연 키 upsert, 파티션 단위 덮어쓰기가 그 도구다.

"단순 변환 후 S3 적재는 Firehose + Lambda"라는 공식에서 Lambda가 항상 필요한 것은 아니다. JSON을 Parquet/ORC로 바꾸는 일은 Firehose의 레코드 형식 변환 기능이 Glue Data Catalog 테이블의 스키마를 참조해 직접 수행한다. 입력이 JSON이 아닐 때(CSV, 로그 텍스트 등) 먼저 JSON으로 바꾸는 단계에서 Lambda 변환이 필요하다. 어느 쪽이든 상태가 없는 변환이므로 Flink를 쓸 이유가 없다는 결론은 같다.

시나리오 연습: 단서에서 선택까지

시나리오의 단서	판별 포인트	선택
클릭 로그를 실시간 대시보드와 야간 배치가 함께 쓰고, 집계 버그를 고친 뒤 지난 3일치를 다시 계산해야 한다	다중 소비자 + 재생	Kinesis Data Streams(보존 기간 연장) + Flink, 원본은 Firehose로 S3에 보존
주문 메시지를 워커가 하나씩 처리하고, 실패한 건만 따로 모아 재처리한다. 순서는 상관없다	메시지 단위 재시도·격리	SQS Standard + DLQ
계좌별 입출금은 순서대로, 계좌끼리는 병렬로 처리한다	그룹 단위 순서	SQS FIFO(`MessageGroupId`=계좌) 또는 Kinesis(파티션 키=계좌)
S3에 객체가 올라오면 접두사·크기 조건에 따라 서로 다른 처리로 보낸다	내용 기반 라우팅 + AWS 서비스 이벤트	EventBridge 규칙
온프레미스 Oracle의 변경을 중단 없이 S3 데이터 레이크로 계속 반영한다	이기종 + 무중단 + 지속 복제	DMS Full Load + CDC(대상이 S3라 변환할 스키마·코드가 없어 SCT는 불필요)
JSON 이벤트를 Parquet으로 바꿔 S3에 쌓기만 한다	상태 없는 형식 변환	Firehose 형식 변환. Flink는 과하다
두 스트림을 10분 범위로 조인해 이상 거래를 잡는다	상태·윈도우·조인	Managed Service for Apache Flink
한 이벤트를 세 팀이 각자 속도로, 유실 없이 처리한다	분배 + 팀별 내구성 버퍼	SNS → SQS 팬아웃(큐마다 DLQ)

다음 주는 이렇게 받아들인 데이터를 저장하고 변환하는 쪽 — 파티셔닝과 파일 포맷, 그리고 Glue·EMR·Spark를 이용한 변환 처리 — 로 넘어간다. 오늘 그린 파이프라인의 화살표 끝(S3, Redshift, OpenSearch)이 그 출발점이다.

📖 용어

effectively-once : 전달은 중복될 수 있어도 처리 결과는 한 번 처리한 것과 같게 만드는 방식. at-least-once 전달과 멱등 컨슈머의 조합이다.
멱등 컨슈머 : 같은 메시지를 여러 번 받아도 결과가 달라지지 않게 만든 처리기. 보통 고유 ID와 조건부 쓰기로 구현한다.
가시성 타임아웃 : SQS에서 한 컨슈머가 메시지를 받아 처리하는 동안 다른 컨슈머에게 그 메시지를 숨겨 두는 시간.
DLQ(Dead-Letter Queue) : 정해진 횟수만큼 실패한 메시지를 따로 모아 두는 큐. 정상 흐름을 막지 않고 원인을 조사하게 해 준다.
재생(replay) : 스트림에 남아 있는 과거 데이터를 처음(또는 특정 시점)부터 다시 읽어 재처리하는 것.
핫 샤드 : 파티션 키가 한쪽으로 쏠려 특정 샤드에만 트래픽이 몰리는 상태.
CDC(Change Data Capture) : 테이블 전체를 다시 읽지 않고 트랜잭션 로그에서 바뀐 내용만 잡아내 복제하는 방식.
팬아웃 : 한 메시지를 여러 수신자에게 복제해 나눠 주는 것. SNS → 여러 SQS 큐가 대표 패턴이다.
워터마크 : "이 시각 이전 이벤트는 거의 다 도착했다"고 알리는 신호. 윈도우 결과를 언제 확정할지 정한다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

Week 3 전체를 관통하는 신뢰성 명제로 가장 정확한 것은?

문제 2

다음 중 Managed Flink(Day1) 대신 Kinesis Data Firehose + Lambda 변환(Day4 단순 경로)을 선택해야 하는 상황은?

문제 3

DMS로 운영 DB를 무중단으로 분석 시스템에 복제하려는데, Full Load는 성공하지만 이후 변경분이 반영되지 않는다. 가장 먼저 확인할 것은?

문제 4

한 "주문 생성" 이벤트를 결제·재고·분석 세 도메인이 각각 독립적으로, 일시 장애에도 유실 없이 처리해야 한다. 그리고 결제 도메인은 영구 실패 메시지를 따로 격리해야 한다. 가장 적절한 조합은?

문제 5

Lambda 아키텍처를 Kappa 아키텍처로 단순화했다. 이때 얻는 이점과 새로 생기는 제약을 옳게 짝지은 것은?

참고 공식 자료