1. Kafka 병렬 처리
🔹 문제상황
Kafka의 Partition을 UI에서 Topic을 생성하는 방식으로 처음 학습했다. 그러나 이번 프로젝트에선 UI 접속하기도 전에 IDE에서 프로그램을 실행했더니 Topic이 생겨서 따로 다른 조정을 하지 않았다. 이 경우 기본 설정을 사용하게 되는데
이미지와 같이 하나의 파티션만 생긴다.
그러나 Broker는 3개.
Partition을 하나만 사용하게 된다면 독박 업무나 다름이 없다. Broker 1이 열심히 굴려지고 있을 때 2와 3은 놀고 먹는 유휴 상태가 발생하는 것.
Kafka의 장점인 병렬 처리로 인한 속도 개선을 살리기 위해선 파티션 수를 늘려줘서 클러스터 구조를 개선할 필요가 있다.
🔹 해결방법 : Kafka UI에서 Partition 수 늘리기
Kafka UI에서 수정해야 하는 Topic 항목의 오른쪽에서 ··· → 'Edit Settings'를 누르면 위 이미지와 같이 화면이 나타난다.
Number of partitions (파티션 개수) : 3개
Replication Factor (복제본 개수) : 3개
*Replication은 클러스터 내의 한 브로커에 장애가 발생하더라도 계속 동작할 수 있도록 데이터를 안전하게 보호하고 서비스를 중단 없이 유지하는 역할을 해주므로 파티션과 같은 개수로 설정한다.
Min In Sync Replicas 설정은 검색 결과를 참고했다.
✅ ISR (In-Sync Replicas) : 리더와 동기화 상태를 유지하고 있는 복제본들의 그룹
Kafka에는 Leader와 Follower라는 개념이 있다.
Leader : 리더,
Follower : 팔로워,
ISR이 브로커에만 해당되는 개념인지, 리더와 팔로워 모두 포함하는 건지 범위를 잘 모르겠어서 공부해봤다.
" ISR = 리더 + 리더와 동기화를 유지하고 있는 팔로워들 "
단순히 살아있는(활동 중인) 브로커가 아니라 팔로워와 리더 간 연결이 살아있어야 한다는 점이 핵심이었다.
만약 팔로워가 리더에게 요청을 보낸 마지막 시간이 기준 시간(보통 10초, → replica.lag.time.max.ms)을 넘어가면 그 브로커는 ISR에 포함되지 않는다.
그리고 min.insync.replicas는 해당 토픽에 최소 몇개의 ISR이 있어야 하는지를 정하는 설정값이다. 위 캡처에서 설정을 보면 2로 설정되어 있는데, 2개의 브로커가 정상 동작하고 있어야 쓰기 동작을 허락하겠다는 의미다.
➕ acks=all (또는 acks=-1)의 의미 - "ISR에 속한 모든 복제본이 데이터를 받았을 때만 성공으로 간주하겠다."
(프로듀서의 설정 중 하나)
안전하지만 느린 편(trade-off)
min.insync.replicas 설정은 Update Topic을 누르면 설정이 저장되는데 하단의 Number of partitions, Replication Factor는 각각 Submit을 누르고 Confirm 처리를 해줘야 바꾼 설정이 저장된다.
🔹 결과
학습 과정
(완벽✨정답!)
지금 작업 중이지만 다음은 메뉴 조회 API를 수정하려 한다.
