260917. Study 1 - 카프카 스터디 전 참고자료
1. Kafka 창시자가 말하는 로그와 분산 시스템의 본질
* 원문
Using logs to build a solid data infrastructure
다만 이 글의 저자는 Kafka 창시자 Jay Kreps가 아니라 Martin Kleppmann이야. 내용은 Jay Kreps의 원문 **“The Log”**를 참고하고 있고, 로그·분산 시스템·Kafka의 관계를 설명해.
그리고 Jay Kreps가 직접 쓴 Confluent 원문은 이쪽이야.
Putting Apache Kafka To Use: A Practical Guide to Building an Event Streaming Platform
이 글은 Jay Kreps가 작성했고, Kafka를 기업의 이벤트 스트리밍 플랫폼으로 활용하는 관점을 설명해.
* 해석 영상
youtube.com/watch?si=ClR8bJWUjGkOwDYm&v=v2Eab3U0W9s&feature=youtu.be
[정리]
1. Kafka는 왜 메시지 큐가 아니라 분산(커밋) 로그라고 불리는가?
1) 로그는 Append-only + 시간 순서 정렬된 레코드 배열이다.
이 순서(Order)가 곧 시간이며, 분산시스템 일관성의 근간이 된다.
2) DB의 로그는 충돌 복구(WAL)에서 출발해 원격 복제 → 범용 데이터 구독으로 진화했다.
3) 같은 순서로 같은 입력 → 같은 결과.
분산시스템의 일관성 문제는 결국 순서 합의(Ordering) 문제이며,
로그가 그 순서를 물리적으로 구현한다.
State Machine Replication Principle
" 동일하고 결정론적인 두 프로세스가 같은 상태에서 시작하고 같은 순서로 동일한 입력을 받으면,
동일한 출력을 생성하고 같은 상태로 끝난다."
결론> 같은 순서를 기록하는것이 로그.
분산시스템의 일관성의 문제는 순서를 맞추는 문제이고,
로그는 이 순서를 물리적으로 구현하는 도구이다.
그래서 로그가 분산시스템의 핵심임.
즉, 로그의 순서가 분산 시스템의 일관성을 만들어 낸다.
2. 두 가지 복제 모델
===> 이미지 추가!
무엇을 로그에 기록하느냐에 따라 복제 전략이 달라진다.
요청(Command)을 기록할 것인가, 결과(State)를 기록할 것인가.
1) State Machine Replication (상태 기계 모델)
돌아오는 요청자체를 로그에 기록. 모든 복제본이 각 요청을 직접 처리.
예: "+1", "*2" 같은 변환 명령 기록
2) Primary-Backup (주-백업 모델)
리더 (Master) 가 처리 후 상태 변화 결과를 로그에 기록. 팔로워(Slave) 는 결과를 순서대로 적용.
예: "1", "3", "6" 같은 결과값 기록
주의!
로그의 순서가 깨지면 일관성이 깨진다!
3. 하위 알고리즘과 로그
Paxis, Raft, ZAB - 모든 합의 알고리즘은 결국 분산 로그를 유지하기 위한 방법이다.
합의 결과가 쌓이면 로그가 되고, 그 로그를 모든 노드가 동일하게 유지하는것이 이 알고리즘의 본질이다.
* 합의 : 분산된 여러 노드가 서로 다른값을 주장할 때 하나의 값으로 일치 시키는 과정.
4. 테이블과 로그의 이중성
로그가 원본이고, 테이블은 파생물이다.
이 이중성이 현대 데이터 아키텍처의 근간.
===> 이미지 추가!
예 1: Git 유추
commit log = 소스코드의 로그 / 체크아웃 = 현재 테이블. 완전한 로그는 모든 이전 상태 재생성
예 2: 은행계좌 유추
로그의 거래 내역 전체 / 테이블 = 현재 잔액
5. 테이블-로그의 이중성과 실무 아키텍처의 연결
이중성을 이해하면 Event Sourcing, CQRS, Kafka KTable이 모두 같은 개념의 다른 구현임을 알게 된다.
1) Event Sourcing
상태 저장 대신 이벤트를 로그로 저장. 현재 상태 = 모든 이벤트의 재생 결과. 감사ㆍ 시간이행 쿼리 가능
ex> 금융, 의료 모든 변경 이력이 중요한 업무에서 쓰임.
2) CQRS
쓰기(Command) = 이벤트 로그/ 읽기(Query) = 이벤트 재생한 파생 뷰. 로그-테이블 이중성의 아키텍처 패턴화.
3) Kafka Streams KTable
Kafka 토픽(로그)을 테이블뷰로 자동 투영. KStream(이벤트) + KTable(상태)의 조인. 이중성의 완벽한 실용 구현
이 세가지는 이름은 다르지만 본질은 같음.
로그와 테이블의 이중성을 다양한 형태로 구현함.
6. 데이터 통합 문제와 Kafka의 탄생
1) 문제점: 시스템이 늘어날수록 데이터 파이프라인은 O(N^2)으로 폭발한다.
데이터 이동 자체가 가장 큰 엔지니어링 부채가 된다.
Garbage In Garbege Out.
===> 이미지 추가!
2) 해결책: 중앙 로그 하나를 두면 O(N^2) → O(N)
새 시스템 추가 시 단 하나의 연결만 필요하다.
모든 데이터 소스는 중앙로그에 발행하고 Data Consumer는 중앙로그를 구독하는 형태.
① 소비자 Consumer는 데이터가 어디에서 왔는지 알 필요가 없다.
본인이 사용하고 싶은 로그를 소비하면 된다.
② 중앙 로그는 버퍼 역할도 한다.
Consumer의 특징에 따라서 자신의 속도로 데이터를 소비하면 된다.
===> 이미지 추가!
결과적으로 각 소비자가 자신의 속도에 맞게 자신의 상황에 맞게 데이터를 소비할 수 있다.
7. ETL의 재해석
1) 데이터를 만드는 팀이 스키마와 품질에 책임져야 한다.
중앙 허브(로그)는 단지 전달자다.
X 기존 ETL 방식
Source → 중앙 팀이 ETL → DW. 배치 ㆍ단방향 ㆍ지연 ㆍDW팀 병목. 실시간 공급 불가
O 로그 중심 방식
생산자가 정제 후 로그 게시. 로그 = 중립 허브. DW ㆍ검색 ㆍ캐시 ㆍ모니터링 동시 구독.
8. KAFKA의 핵심 설계 철학
Kafka는 DB도, 로그 수집기도, 전통적 메시징 시스템도 아니다.
Jay Kreps의 표현: "로그를 독립 서비스로(Log as a Stand-alone Service)"
9. 로그 보존 전략 & 기술 설계
Log Compaction은 Kafka를 단순 메시지 큐를 넘어 상태 저장소로 만든다.
이벤트 데이터(Retention)와 상태 데이터(Compaction)를 구분하라.
1) Retention - 이벤트 데이터용
시간(7일) 또는 용량 기준으로 오래된 메시지 삭제
ex> 클릭 이벤트, 사용자 행동 로그, 메트릭
2) Log Compaction - 상태 데이터용
같은 키의 오래된 레코드 삭제, 최신 값만 유지 Kafka를 DB처럼 활용 가능.
ex> 사용자 프로필, 계좌 잔액, 설정 값
재생, 여러 사용자가 독립적으로 읽어야 한다
→ Kafka
단순히 task를 전달하고 처리하는 용도
→ Rabbit MQ
10. 실시간 스트림 처리와 로그
스트림 처리는 배치의 반대가 아니다.
배치는 윈도우 크기가 1일인 스트림 처리다.
데이터가 연속적으로 발생하면, 처리도 연속적이어야 한다.
* 윈도우 : 데이터를 처리하는 시간 단위
11. 데이터 흐름 그래프 & 상태 저장 처리
로그는 스트림 처리 단계를 연결하는 버퍼이자 순서 보장자다.
프로세서 상태도 로그로 백업하면 장애 복구가 가능하다.
===> A Multijob Dataflow Graph (그림)
로그의 역할
1) 처리 단계 간에 순서 보장
2) Consumer의 속도 차이를 흡수하는 버퍼
데이터를 생산하는 속도가 소비하는 속도보다 빠를 때,
로그가 중간에서 버퍼 역할을 해서 소비자가 자신의 속도에 맞게 처리할수 있게 함.
주의!
실시간 스트림 처리에서 상태를 유지해야 하는 경우가 있음.
ex> 클릭 스트림 처리, 사용자별 클릭 횟수를 집계
어플리케이션이 상태를 메모리에 유지 해야 함.
이 어플리케이션이 장애로 죽어버리면 메모리 상태가 사라짐.
이 때 해결책도 로그임.
로컬 데이터베이스의 상태를 저장하면서 변경 사항을 로그로 백업.
===> State Store
이 패턴을 구현한 대표적인 사례
핵심 메시지는
스트림 처리도 로그가 중심
처리 단계로 연결하는 것도 로그
순서를 보장하는 것도 로그
장애를 복구하는 것도 로그
스트림 처리의 중심에는 항상 로그가 있다.
12. 시스템을 로그로 바라보기
모든 분산시스템은 로그(일관성ㆍ순서)와 서빙 레이어(쿼리 ㆍ인덱스)로 분리할 수 있다.
DB, 검색 인덱스, 캐시 - 모두 로그의 파생 뷰다.
1) 로그 레이어
데이터를 안전하게 기록하고
순서 보장, 일관성, 복제, 복구, 모든 분산 시스템이 공통으로 필요한 것.
2) 서빙 레이어
데이터를 빠르게 조회함.
사용자나 어플리케이션의 요청에 직접 응답해주는 영역.
로그를 읽어서 빠르게 찾을 수 있는 인덱스 구조로 변환해 둠.
변환 인덱스 구조 형태는 DB 시스템마다 다름.
13. 언번들링 & 현대 아키텍처
이렇게 기능이 분리된 시스템들을 어떻게 하나로 연결할수 있을까?
→ DB의 기능들이 전문 시스템으로 분리(Unbundling)되고,
그 분리된 시스템들을 다시 로그가 연결한다.
하나의 거대한 시스템에 묶여 있던 기능들을 풀어서 각각의 전문 시스템으로 분리한다.
분산 조율은 주키퍼가 (Zookeeper)
로그는 카프카 (Kafka)
검색 엔진은 누신 (Nucene (인덱싱))
네트워크 통신은 네티(Netty)
데이터 직렬화는 에이브로 (Avro)
이렇게 각 기능이 전문 시스템으로 분리됨.
14. Outro - 핵심 정리
로그를 이해하면 분산시스템의 본질이 보인다.
01. 로그는 분산시스템에서 순서와 일관성을 보장하는 가장 근본적인 추상화다.
* 근본적인 추상화 : 복잡한 문제를 순서와 일관성 보장이라는 심단순한 개념 하나로 보여주기 때문에
02. Kafka는 O(N^2) 데이터 통합 문제를 O(N)으로 풀기 위해 탄생한, 로그를 독립 서비스로 만든 인프라다.
메시지 큐가 아니다.
→ 저자는 분산시스템과 복잡한 데이터의 통합 문제를 해결하기 위해서 카프카라는 중앙 로그 허브를 개발했으며
이때 카프카는 단순히 메시지 큐가 아니라 조직 전체 데이터 흐름의 중추 그것이 카프카의 본질이다.
03. 테이블-로그의 이중성을 이해하면 Event SourcingㆍCQRS가 자연스럽게 이해된다.
04. 모든 분산시스템은 로그 레이어와 서빙 레이어로 분리할 수 있다. 복잡해 보이는 시스템도 결국 이 두레이어의 조합이다.
→ 레디스, 엘라스틱 서치, 카산드라와 같은 이름도 다르고 용도도 달라 보이지만
사실 모두 로그를 구독해서 각자의 방식으로 인덱싱하는 파생 뷰
다시말해서, 로그가 원본이고 이 시스템들은 파생물임.
15. 현재 회사의 시스템은 어떤가?
Q1. Log & Consistency
우리 회사의 분산시스템의 데이터 일관성은 어떻게 보장하고 있는가?
로그가 그 역할을 하고 있는가, 아니면 다른 메커니즘인가?
Q2. Data Pipeline
서비스 간 데이터 동기화가 혹시 O(N^2) 의 복잡성을 가진 파이프라인으로 구성되어 있지 않은가?
즉 중앙 로그 허브 없이 서비스끼리 직접 연결하고 있지는 않은가?
===> Proxy 서버?, Relay 서버?
Q3. Event Sourcing
우리 시스템은 상태(State)를 저장하는가, 이벤트(Event)를 저장하는가?
감사 추적(Audit Trail) 이 필요한 도메인인데 상태만 저장하고 있지는 않은가?
Q4. Kafka Usage
우리 회사는 Kafka를 제대로 활용하고 있는가?
단순 메시지 큐로만 쓰고 있지는 않은가? replayㆍcompaction은 활용하는가?
Q5. ETL & Ownership
데이터 정제 책임이 생산자에게 있는가, 중앙 팀이 모든 정제를 떠맡고 있는가?
DW팀이 병목이 되고 있지는 않은가?
Q6. Stream vs Batch
배치로 처리하고 있는 것 중 실시간 스트림으로 전환하면 더 나은 것이 있는가?
배치가 관행이 된 것인가, 아니면 정말 배치가 최선인가?
'이직준비 3 > Study' 카테고리의 다른 글
| 260917. Study 1 - 카프카 (v4.0) (1) | 2026.09.16 |
|---|
