Skip to content

Commit 7bba0d5

Browse files
committed
Add Kafka Intro
1 parent b37030b commit 7bba0d5

15 files changed

+272
-0
lines changed

book/_toc.yml

+10
Original file line numberDiff line numberDiff line change
@@ -77,6 +77,16 @@ chapters:
7777
- file: docs/8_cloud_computing_and_data_engineering/8.4_use_case_cloud_dataengineering.md
7878
- file: docs/8_cloud_computing_and_data_engineering/8.5_multi_cloud_dataengineering.md
7979
- file: docs/8_cloud_computing_and_data_engineering/8.6_reference.md
80+
- file: docs/9_kafka_zero_to_hero/main_page.md
81+
sections:
82+
- file: docs/9_kafka_zero_to_hero/9_1_kafka_intro.md
83+
sections:
84+
- file: docs/9_kafka_zero_to_hero/9_1_kafka_intro/9_1_1_architecture.md
85+
- file: docs/9_kafka_zero_to_hero/9_1_kafka_intro/9_1_2_topic_and_partition.md
86+
- file: docs/9_kafka_zero_to_hero/9_1_kafka_intro/9_1_3_partition_and_producer_consumer.md
87+
- file: docs/9_kafka_zero_to_hero/9_1_kafka_intro/9_1_4_kafka_performance.md
88+
- file: docs/9_kafka_zero_to_hero/9_1_kafka_intro/9_1_5_kafka_disaster_recovery.md
89+
- file: docs/9_kafka_zero_to_hero/9_1_kafka_intro/9_1_6_reference.md
8090
- file: docs/p_movieFlix/main_page.md
8191
sections:
8292
- file: docs/p_movieFlix/1_architecture.md
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
# 9.1. Kafka Intro
2+
3+
- date : 2023-07-14
4+
- author
5+
* [이동욱](https://github.com/ehddnr301)
6+
7+
- keyword
8+
* Kafka 기본 구조
9+
* 토픽과 파티션
10+
* 파티션과 오프셋, 메시지 순서
11+
* 여러 파티션과 프로듀서
12+
* 여러 파티션과 커슈머
13+
* Kafka 성능
14+
* 장애대응
15+
16+
## 후기
17+
18+
- 1주차 Kafka Intro 스터디 내용을 정리한것입니다. 스터디중에 나온 ZeroCopy나 Replication에 대한 이야기는 Additional로 각 챕터에 추가되었습니다.
19+
- 잘못된 내용이나 질문은 댓글 혹은 PR로 자유롭게 기여해주시면 감사하겠습니다!
20+
21+
22+
<script src="https://utteranc.es/client.js"
23+
repo="Pseudo-Lab/data-engineering-for-everybody"
24+
issue-term="pathname"
25+
label="comments"
26+
theme="preferred-color-scheme"
27+
crossorigin="anonymous"
28+
async>
29+
</script>
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
# 카프카 기본 구조
2+
3+
![alt text](./images/9_1_1.png)
4+
5+
## 카프카란
6+
7+
- 카프카는 4개의 구성요소로 이루어져 있습니다. (Zookeeper, Kafka Cluster, Producer, Consumer)
8+
- 카프카는 주로 대용량의 실시간 데이터 스트리밍을 처리하기 위해 사용되는 분산 스트리밍 플랫폼입니다.
9+
10+
## Zookeeper
11+
12+
- 카프카 클러스터를 관리하는 용도로 Zookeeper가 필요합니다.
13+
- 브로커 메타데이터 관리, 파티션 리더 선출 등의 관리 역할을 수행합니다.
14+
- 주키퍼를 제거한 **KRaft 모드**를 사용하여 주키퍼 의존성을 제거하는 방법도 존재합니다.
15+
16+
## Kafka Cluster
17+
18+
- 카프카 클러스터는 메시지를 저장하는 저장소 입니다.
19+
- 하나의 카프카 클러스터는 여러개의 브로커(각각의 서버)로 구성이 됩니다.
20+
21+
## Producer
22+
23+
- 카프카 클러스터에 메시지를 넣는 역할
24+
25+
## Consumer
26+
27+
- 카프카 클러스터에서 메시지를 읽어오는 역할
28+
29+
<script src="https://utteranc.es/client.js"
30+
repo="Pseudo-Lab/data-engineering-for-everybody"
31+
issue-term="pathname"
32+
label="comments"
33+
theme="preferred-color-scheme"
34+
crossorigin="anonymous"
35+
async>
36+
</script>
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
# 토픽과 파티션
2+
3+
![alt text](./images/9_1_2_0.png)
4+
5+
## 토픽
6+
7+
- Topic은 메시지를 구분하는 단위로써 목적에 따라 여러 이름을 가질 수 있습니다.
8+
- 파일시스템의 폴더에 비유할 수 있습니다.
9+
- 무슨 데이터를 담고있는지 명확하게 명시하면 유지보수 시 편리하게 관리 할 수 있습니다.
10+
- Topic1 (X) -> purchase_log, refund_log, ... (O)
11+
- Consumer와 Producer는 Topic을 기준으로 메시지를 주고받게 됩니다.
12+
- Producer: 어떤 **Topic**에 메시지를 저장해줘
13+
- Consumer: 어떤 **Topic**에서 메시지를 읽어올래
14+
15+
## 파티션
16+
17+
![alt text](./images/9_1_2_1.png)
18+
19+
- 파티션은 메시지를 저장하는 물리적인 파일입니다.
20+
- 각 파티션은 여러 Segment로 이루어져있고 각각은 특정 오프셋 범위를 가집니다.
21+
- 하나의 토픽은 한개 이상의 파티션으로 구성됩니다.
22+
- 파티션은 하나의 토픽을 물리적으로 분할한 것입니다.
23+
- 첫번째 파티션 번호는 0번부터 시작합니다.
24+
25+
### 파티션과 오프셋, 메시지 순서
26+
27+
- 파티션은 기본적으로 추가만 가능한 Append-Only 파일입니다.
28+
- 각 메시지 저장위치를 Offset이라고 합니다.
29+
- 프로듀서가 넣은 메시지는 Paritition의 맨 뒤에 추가됩니다.
30+
- Consumer는 Offset 기준으로 메시지를 순서대로 읽어오게 됩니다.
31+
- 메시지는 삭제되지 않습니다. (retention.ms에 따라 일정 시간이 지난 뒤 삭제될 수는 있습니다.)
32+
33+
<script src="https://utteranc.es/client.js"
34+
repo="Pseudo-Lab/data-engineering-for-everybody"
35+
issue-term="pathname"
36+
label="comments"
37+
theme="preferred-color-scheme"
38+
crossorigin="anonymous"
39+
async>
40+
</script>
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
# 파티션과 프로듀서 & 컨슈머
2+
3+
## 파티션과 프로듀서
4+
5+
![alt text](./images/9_1_3_0.png)
6+
7+
- 프로듀서는 어떤 Partition에 메시지를 저장할지 결정해야합니다.
8+
1. 메시지 키가 제공되지 않은 경우 RoundRobin 방식으로 돌아가면서 저장할 수 있습니다.
9+
2. Key를 이용해 특정 Partition을 선택할 수 있습니다.
10+
- Key가 지정된 경우 Kafka는 키의 해시값을 이용해 메시지를 특정 파티션에 저장합니다.
11+
- 같은 키를 갖는 메시지는 항상 같은 Partition에 저장되기 때문에 메시지 순서가 보장됩니다.
12+
13+
## 파티션과 컨슈머
14+
15+
![alt text](./images/9_1_3_1.png)
16+
17+
- 컨슈머는 **컨슈머 그룹**에 속하게 됩니다.
18+
- 한개의 파티션은 컨슈머 그룹에서 한개 컨슈머만 연결 가능합니다.
19+
- 컨슈머 그룹에 속한 컨슈머들은 하나의 파티션을 공유 할 수 없습니다.
20+
- 한 컨슈머 그룹 기준으로 파티션의 메시지를 순서대로 처리하게 됩니다.
21+
22+
- 그림 예시를 살펴보면 Consumer Group A에서 각 컨슈머는 Partition0과 Partition1을 공유할 수 없습니다.
23+
- 다른 Consumer Group B는 Consumer Group A에서 읽고있는 Partition0과 Partition1을 읽을 수 있습니다.
24+
25+
<script src="https://utteranc.es/client.js"
26+
repo="Pseudo-Lab/data-engineering-for-everybody"
27+
issue-term="pathname"
28+
label="comments"
29+
theme="preferred-color-scheme"
30+
crossorigin="anonymous"
31+
async>
32+
</script>
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
1+
# 카프카 성능
2+
3+
![alt text](./images/9_1_4.png)
4+
5+
## 카프카 성능이 좋은 이유
6+
7+
**Partition file은 OS 페이지캐시 사용**
8+
- Partition에 대한 File IO를 메모리에서 처리합니다.
9+
- 서버에서 Page Cache를 Kafka만 사용해야 성능에 유리합니다.
10+
11+
**Zero Copy**
12+
- 디스크 버퍼에서 네트워크 버퍼로 직접 데이터 복사합니다.
13+
14+
**Consumer 추적을 위해 Broker가 하는 일이 비교적 단순**
15+
- 메시지 필터, 메시지 재전송과 같은 일은 Broker가 하지않습니다. (Producer와 Consumer가 직접 함)
16+
- Broker는 Consumer와 Partition간 매핑 관리합니다.
17+
18+
**묶어서 보내고, 받기 (Batch)**
19+
- Producer: 일정 크기만큼 메시지를 모아서 전송 가능합니다.
20+
- Consumer: 최소 크기만큼 메시지를 모아서 조회 가능합니다.
21+
22+
**처리량(throughput) 증대(확장)가 쉬움**
23+
- 1개 장비의 용량 한계 -> Broker 추가, Partition 추가
24+
- 컨슈머가 느림 -> 컨슈머 추가 (+ Partition 추가)
25+
26+
## Additional - Zero Copy
27+
28+
**일반적인 copy작업**
29+
1. 데이터를 읽어 커널의 주소공간에 있는 Read buffer에 복사
30+
2. 커널의 Read buffer에서 Apllication buffer로 데이터 복사
31+
3. Application buffer에서 커널의 Socket buffer로 데이터 복사
32+
4. Scoket buffer에서 NIC로 데이터 복사
33+
34+
**Zero-Copy**
35+
1. 데이터를 읽어 커널의 주소공간에 있는 Read buffer에 복사
36+
2. Read buffer데이터를 Socket buffer로 복사
37+
3. NIC buffer로 복사
38+
39+
- 요약하자면 더 적은 복사횟수, 더 적은 Context Switching으로 불필요한 데이터 복사를 줄이고 CPU 자원을 아낄수 있다 입니다.
40+
41+
<script src="https://utteranc.es/client.js"
42+
repo="Pseudo-Lab/data-engineering-for-everybody"
43+
issue-term="pathname"
44+
label="comments"
45+
theme="preferred-color-scheme"
46+
crossorigin="anonymous"
47+
async>
48+
</script>
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
# 카프카 장애대응
2+
3+
## 리플리카를 통한 장애대응
4+
5+
- 리플리카는 파티션의 복제본입니다.
6+
- Replication Factor 만큼 파티션의 복제본이 각 Broker에 생성됩니다.
7+
- Replication Factor를 2로 지정하게 되면 동일한 데이터를 가지고 있는 파티션이 서로 다른 Broker에 2개가 생성됩니다. 이중 하나가 Leader, 하나가 Follower가 됩니다.
8+
9+
- Leader와 Follower구성
10+
- Producer와 Consumer는 Leader를 통해서만 메시지를 처리합니다.
11+
- Follower는 Leader로부터 메시지를 복제합니다.
12+
13+
- 장애대응
14+
- 리더가 속한 브로커가 장애시 다른 Follower가 Leader가 됩니다.
15+
16+
## Additional - Replication의 기본값은 주로 3인 이유
17+
18+
- 합의 알고리즘에서 사용되는 **정족수**
19+
- 5개의 노드로 구성할 경우 정족수를 채우기 위해 최소 3개의 노드는 동의를 해야해서 2개까지 장애를 허용합니다.
20+
- 4개의 노드로 구성할 경우 정족수를 채우기 위해 최소 3개의 노드는 동의를 해야해서 1개까지 장애를 허용합니다.
21+
- 3개의 노드로 구성할 경우 정족수를 채우기 위해 최소 2개의 노드는 동의를 해야해서 1개까지 장애를 허용합니다.
22+
- 짝수개 노드로 클러스터를 구성한 경우 홀수개 노드로 구성했을때보다 장애허용에 있어 이득을 보기 힘들어 보통 홀수개로 구성되는데 그 중 3이라는 최소 수치를 설정한것으로 이해하였습니다.
23+
24+
<script src="https://utteranc.es/client.js"
25+
repo="Pseudo-Lab/data-engineering-for-everybody"
26+
issue-term="pathname"
27+
label="comments"
28+
theme="preferred-color-scheme"
29+
crossorigin="anonymous"
30+
async>
31+
</script>
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
# `🗂️ 참고자료(Reference)`
2+
3+
- [최범균님 Kafka 조금 아는 척하기1](https://www.youtube.com/watch?v=0Ssx7jJJADI)
4+
- [devocean Apache Kafka의 새로운 협의 프로토콜인 KRaft에 대해(1)](https://devocean.sk.com/blog/techBoardDetail.do?ID=165711&boardType=techBlog)
5+
- [Apache Kafka Guide #19 Segment and Indexes](https://medium.com/apache-kafka-from-zero-to-hero/apache-kafka-guide-19-segment-and-indexes-7a428f089695)
6+
- [Kafka의 Zero copy](https://h-devnote.tistory.com/19)
7+
- [뗏목 타고 합의 알고리즘 이해하기: The Raft Consensus Algorithm](https://www.youtube.com/watch?v=aywjlaKxQp4)
8+
9+
<script src="https://utteranc.es/client.js"
10+
repo="Pseudo-Lab/data-engineering-for-everybody"
11+
issue-term="pathname"
12+
label="comments"
13+
theme="preferred-color-scheme"
14+
crossorigin="anonymous"
15+
async>
16+
</script>
Loading
Loading
Loading
Loading
Loading
Loading
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
# 9. Kafka Zero-To-Hero
2+
3+
- [Kafka - Zero to Hero 실시간 성장하기](https://www.notion.so/chanrankim/Kafka-Zero-to-Hero-8637c3be78f145649f44fa990aeb9892) 스터디 내용을 정리한 문서입니다.
4+
5+
- 참가 스터디원
6+
* [김승규]()
7+
* [김승태]()
8+
* [김예진]()
9+
* [신진수]()
10+
* [이동욱](https://github.com/ehddnr301)
11+
* [이영전]()
12+
* [이호민]()
13+
* [이힘찬]()
14+
* [장승호]()
15+
* [홍지영​​]()
16+
17+
- 스터디 목표
18+
1. Kafka 이론에 대해 사용가능한 정도로 이해하기
19+
2. Kafka 상태 모니터링하기
20+
3. 데이터 실시간처리를 하는 도중 발생하는 Kafka 에러 트러블 슈팅 해보기
21+
22+
23+
<script src="https://utteranc.es/client.js"
24+
repo="Pseudo-Lab/data-engineering-for-everybody"
25+
issue-term="pathname"
26+
label="comments"
27+
theme="preferred-color-scheme"
28+
crossorigin="anonymous"
29+
async>
30+
</script>

0 commit comments

Comments
 (0)