add: 📰 [Chapter 02] 카프카 설치하기

_posts/kafka/2024-11-17-chapter02.md → _posts/kafka/2024-11-17-chapter02(1).md

@@ -1,5 +1,5 @@
 ---
-title: Chapter 02. Kafka 설치하기(WSL 🐧)
+title: Chapter 02(1). 카프카 설치하기(WSL 🐧)
 date: 2024-11-17 22:20:00 +0900
 categories: [카프카 핵심가이드]
 tags: [카프카 핵심가이드]

_posts/kafka/2024-11-17-chapter02(2).md

@@ -0,0 +1,293 @@
+---
+title: Chapter 02(2). 카프카 설정하기
+date: 2024-11-23 19:00:00 +0900
+categories: [카프카 핵심가이드]
+tags: [카프카 핵심가이드]
+---
+
+## **1. 브로커 설정하기 ⚙️**
+
+### **1-1. broker.id**
+- 브로커를 식별하는 고유 정수 값
+- 클러스터 내 `broker.id`는 **중복 불가**
+
+### **1-2. listeners**
+- 브로커가 클라이언트와 통신하기 위한 리스너 설정
+- **프로토콜, 호스트이름, 포트**를 정의
+- `listener.security.protocol.map`으로 리스너와 프로토콜 매핑 필요.
+- 형식: `listeners={프로토콜}://{호스트 이름}:{포트}`
+
+```
+# 단일 리스너 설정
+listeners=PLAINTEXT://localhost:9092
+listener.security.protocol.map=PLAINTEXT:PLAINTEXT
+
+# 다중 리스너 설정 (쉼표로 구분)
+listeners=PLAINTEXT://localhost:9092,SSL://localhost:9093
+listener.security.protocol.map=PLAINTEXT:PLAINTEXT,SSL:SSL
+
+# 모든 네트워크 인터페이스에서 연결 허용
+listeners=PLAINTEXT://0.0.0.0:9092
+listener.security.protocol.map=PLAINTEXT:PLAINTEXT
+```
+
+### **1-3. zookeeper.connect**
+- 브로커의 메타데이터가 저장되는 **주키퍼의 위치**를 정의
+- 형식: `zookeeper.connect={호스트}:{포트}`
+
+```
+# localhost의 2181번 포트에서 실행 중인 주키퍼 사용
+zookeeper.connect=localhost:2181
+
+# 원격 주키퍼 서버 지정
+zookeeper.connect=remote-zookeeper-host:2181
+
+# 다중 주키퍼 환경에서 쉼표로 여러 서버 지정
+zookeeper.connect=zk1:2181,zk2:2181,zk3:2181
+```
+
+### **1-4. log.dirs**
+- 로그 세그먼트를 저장할 디렉토리 경로를 설정
+
+```
+# 단일 디렉토리 설정
+log.dirs=/var/lib/kafka-logs
+
+# 다중 디렉토리 설정 (쉼표로 구분)
+log.dirs=/var/lib/kafka-logs1,/var/lib/kafka-logs2
+```
+
+### **1-5. num.recovery.threads.per.data.dir**
+- 로그 세그먼트를 관리하는 스레드 수를 설정
+- 설정된 값은 **디렉토리당 스레드 수**를 의미
+
+```
+# 디렉토리당 4개의 스레드 사용
+num.recovery.threads.per.data.dir=4
+
+# Tip : 디렉토리가 3개라면 총 스레드 수는 4 x 3 = 12
+```
+
+### **1-6. auto.create.topics.enable**
+- 브로커는 다음 상황에서 토픽을 자동 생성 (기본값 `true`)
+    - 프로듀서가 토픽에 메시지를 쓰기 시작할 때
+    - 컨슈머가 토픽으로부터 메시지를 읽기 시작할 때
+    - 클라이언트가 없는 토픽에 대한 메타데이터를 요청할 때
+- 명시적으로 토픽을 관리하려면 `false`로 설정
+
+```
+# 토픽 자동 생성 활성화 (기본값)
+auto.create.topics.enable=true
+
+# 토픽 자동 생성 비활성화
+auto.create.topics.enable=false
+```
+
+### **1-7. delete.topic.enable**
+- 토픽 삭제 가능 여부를 설정
+- 삭제 요청 시 데이터와 메타데이터가 모두 제거됨
+
+```
+# 토픽 삭제 허용
+delete.topic.enable=true
+
+# 토픽 삭제 금지
+delete.topic.enable=false
+```
+
+---
+
+## **2. 토픽별 기본값 ⚙️**
+
+### **2-1. num.partitions**
+- 새로운 토픽 생성 시 **파티션 수**를 결정
+- **기본값:** `1`
+
+```
+# 파티션 수 기본값 설정
+num.partitions=1
+
+# 파티션 수를 10으로 설정
+num.partitions=10
+```
+- 10개의 파티션이 10개의 브로커에 분산되면 각 브로커에 하나의 파티션 리더 배치
+- 병렬 처리 성능이 최적화되고 처리량 증가
+
+
+### **2-2. default.replication.factor**
+- 자동 생성된 토픽의 **복제 팩터(레플리카 수)**를 결정
+- **복제 팩터:** 토픽 데이터가 복제되는 브로커의 개수
+
+```
+# 복제 팩터 기본값 설정
+default.replication.factor=3
+```
+- 복제 팩터는 클러스터의 브로커 수보다 작거나 같아야 함
+- **`min.insync.replicas`** 설정값보다 **최소 1 이상** 크게 설정하는 것을 권장
+
+
+### **2-3. log.retention.ms**
+- 메시지의 **보존 기간**을 설정
+- 기본값: `7일(604,800,000ms)`
+
+```
+# 메시지 보존 기간을 7일로 설정 (기본값)
+log.retention.ms=604800000
+
+# 메시지 보존 기간을 3일로 설정
+log.retention.ms=259200000
+```
+
+
+### **2-4. log.retention.bytes**
+- 메시지 보존 기준을 **메시지 크기(바이트)**로 설정
+- 설정된 용량을 초과하면 가장 오래된 메시지부터 삭제
+
+```
+# 메시지 보존 크기를 1GB로 설정
+log.retention.bytes=1073741824
+
+# 메시지 보존 크기를 500MB로 설정
+log.retention.bytes=524288000
+```
+
+
+### **2-5. log.segment.bytes**
+- **로그 세그먼트 크기**를 설정
+- 설정된 크기에 도달하면 기존 세그먼트를 닫고, 새로운 세그먼트 파일을 생성
+
+```
+# 세그먼트 크기를 1GB로 설정
+log.segment.bytes=1073741824
+```
+
+
+### **2-6. log.roll.ms**
+- **로그 세그먼트 파일이 닫히는 시간 기준**을 설정
+
+```
+# 로그 세그먼트를 1시간(3600000ms)마다 닫음
+log.roll.ms=3600000
+```
+
+### **2-7. min.insync.replicas**
+- 최소 동기화 레플리카 수 설정
+- 설정된 값만큼의 레플리카가 최신 상태여야 쓰기 작업 성공
+
+
+### **2-8. message.max.bytes**
+- **메시지 크기 상한**을 설정하여 브로커가 허용하는 최대 메시지 크기를 정의
+- **기본값:** `1MB`
+- 메시지 크기를 초과하면 브로커는 메시지를 거부하고 오류를 반환
+- 프로듀서(`max.request.size`)와 컨슈머(`fetch.message.max.bytes`) 설정 값과 일치해야 함
+
+---
+
+## **3. 하드웨어 선택하기 (기예) 🎪**
+
+### **3-1. 디스크 처리량**
+- 메시지를 디스크에 기록할 때 **디스크 처리량**이 쓰기 지연에 영향을 미침
+- 고속 디스크 사용 권장
+
+
+### **3-2 디스크 용량**
+- 메시지 보존 기간 또는 보존 용량에 따라 디스크 크기를 설정해야 함
+- ex. 하루 1TB 트래픽, 일주일 보존 → **7TB + 10% 여유 공간**
+
+
+### **3-3. 메모리**
+- **페이지 캐시 활용:** 카프카 컨슈머는 시스템 페이지 캐시에서 메시지를 읽는 것이 효율적
+- 카프카와 다른 애플리케이션을 **같은 시스템에서 운영하지 않는 것**을 권장
+
+
+### **3-4. 네트워크**
+- 네트워크 대역폭이 카프카 처리량 상한선을 결정함
+- 네트워크가 포화 상태가 되면 클러스터 복제 작업에 지연이 발생할 수 있음
+- 예상 트래픽과 복제 작업을 감안해 충분한 네트워크 대역폭 확보 필요
+
+
+### **3-5. CPU**
+- 카프카는 메시지 압축, 체크섬 확인, 오프셋 부여 등에 CPU를 사용
+- 디스크나 메모리만큼 중요하지 않으므로 적정 수준의 할당 권장
+
+---
+
+## **4. 클러스터 설정하기 ⚙️**
+
+### **4-1. 브로커 개수**
+- **클러스터 크기 결정 요소**
+    - 디스크 용량 💿
+    - 브로커당 레플리카 용량
+    - CPU 용량
+    - 네트워크 대역폭
+- **브로커 수 설정 예시**
+    - 10TB 데이터를 저장하려면, 브로커당 저장 용량이 2TB일 경우 → **최소 5개의 브로커 필요**
+    - 복제 팩터를 `2`로 설정하면 데이터가 각 브로커에 복제되어 **10개의 브로커 필요**
+
+
+### **4-2. 브로커 설정**
+- 카프카 클러스터 구성에 필요한 주요 설정
+    - `zookeeper.connect`: 클러스터를 관리할 주키퍼의 주소
+    - `broker.id`: 브로커를 구분하기 위한 고유 ID
+
+
+### **4-3. 운영체제 튜닝하기**
+
+**1. 가상 메모리**
+- **페이지 캐시 활용**: 디스크 I/O 성능 향상을 위해 더티 페이지 관리 필요
+- **스왑 메모리 최소화**: 스왑 공간 대신 페이지 캐시에 메모리를 우선 할당
+
+
+**2. 디스크**
+- **파일 시스템 추천**
+    - **Ext4** 또는 **XFS** 사용
+    - **XFS**는 추가 튜닝 없이도 카프카 워크로드에 적합
+
+
+**3. 네트워킹**
+- 송신 및 수신 버퍼 크기 설정
+
+```
+net.core.wmem_default=262144
+net.core.rmem_default=262144
+net.core.wmem_max=16777216
+net.core.rmem_max=16777216
+```
+
+- 브로커 동시 클라이언트 연결 수 설정
+
+```
+net.ipv4.tcp_max_syn_backlog=128
+```
+
+---
+
+## **5. 프로덕션 환경에서의 고려 사항 🤔**
+
+### **5.1 GC(가비지 콜렉터) 설정**
+- 카프카는 **G1GC**를 기본 가비지 컬렉터로 사용하는 것을 권장
+- G1GC는 다양한 작업 부하를 조절하고 일정한 **GC 정지 시간**을 유지
+- **주요 옵션**
+    - **`MaxGCPauseMillis`**
+        - GC의 최대 정지 시간 설정
+        - 짧게 설정하면 응답성이 향상되지만 처리량이 줄어들 수 있음
+    - **`InitiatingHeapOccupancyPercent`**
+        - GC가 시작되는 힙 메모리 사용 비율 설정
+        - ex. `45`로 설정 시 힙의 45%를 사용하면 GC 시작
+- **권장 사항**
+    - 카프카는 힙 메모리를 효율적으로 사용하며 GC 대상 객체를 적게 생성
+    - 위 설정값을 낮게 잡아도 성능에 큰 영향 없음
+
+
+### **5.2 데이터센터 레이아웃**
+- 브로커 간 **랙 위치**를 고려하여 장애 발생 시 데이터 가용성을 보장
+- 동일 랙에 레플리카가 배치되지 않도록 구성
+- **설계 가이드**
+    - 각 브로커를 서로 다른 랙 또는 데이터센터에 배치
+    - 단일 장애점(전원, 네트워크 등)이 발생하지 않도록 구성
+
+
+### **5.3 주키퍼 공유하기**
+- 카프카는 **주키퍼**를 사용해 브로커, 토픽, 파티션 메타데이터 관리
+- **주키퍼 작동 방식**
+    - 컨슈머 그룹 또는 클러스터 구성 변경 시에만 쓰기 작업 발생