루시와 프로그래밍 이야기

13.1 주키퍼 없는 카프카의 미래 기존은 주키퍼에 대한 의존성이 높음 주키퍼는 매우 단순하고 안정적인 어플리케이션으로서 많은 분산 애플리케이션들의 코디네이터 역할을 함 13.1.1. 주키퍼 사용에 따른 제약사항 컨슈머의 오프셋 저장소 전환 카프카 2.0 이전 버전에서는 컨슈머 그룹의 저장소로 주키퍼의 지노드를 이용함 메시지수 증가/오프셋 증가/컨슈머 증가 -> 카프카 0.10버전부터 카프카의 내부 토픽인 _consum_offsets로 이전하면서 의존선 제거 각기 다른 애플리케이션 운영에 대한 부담 주키퍼와 카프카는 아파치에서도 완전히 별개의 프로젝트임 (추구하는 방향성도 다름) 각기 다른 API사용에 따른 부담 -> 개발생산성 저하로 이어짐 운영의 어려움 습득해야하는 지식이 2배 운영의 리소스가 2배 ..

운영중인 카프카 클러스터에 미치는 영향을 최소로 줄이면서 버전을 업그레이드하는 과정을 실습 업그레이드 순서와 주의사항 8.1 카프카 버전 업그레이드를 위한 준비 현재 사용하고 있는 카프카의 버전이 무엇인지 확인하기 명령어를 이용하는 방법 : /usr/local/kafka/bin/kafka-topics.sh —version -> 2.6.0 카프카가 설치된 경로에서 jar파일들을 확인하는 방법 : 실습환경에서는 /usr/local/kafka 가 위치이므로 -> ls -l /usr/local/kafka/libs/kafka_* 차이점 파악 : 업그레이드 하려는 버전을 정하고 카프카의 릴리스 노트 등을 살펴보면서 버전 업그레이드 시 문제가 될 만한 부분은 없는지 확인 카프카 상위 버전은 클라이언트들의 하위 호환성..

4.4 정리 카프카에서 메세지의 신뢰성을 보장하는데 중요한 리플리케이션의 개념 리플리케이션 동작을 위한 리더와 팔로워의 구분 및 역할 그리고 장애 복구를 위한 동작들 카프카 클러스터 내에서 리더 선출 작업을 책임지고 있는 컨트롤러 4.1 카프카 리플리케이션 카프카는 초기 설계 단계에서부터 일시적인 하드웨어 이슈 등으로 브로커 한두 대에서 장애가 발생하더라도 중앙 데이터 허브로서 안정적인 서비스가 운영될 수 있도록 구상됐습니다. 이때 안정성을 확보하기 위해 카프카 내부에서는 리플리케이션이라는 동작을 하게 됩니다. 4.1.1 리플리케이션 동작 개요 카프카의 리플리케이션 동작을 위해 토픽 생성시, 필수값으로 replication factor라는 옵션을 설정해야 합니다. kafka-topics.sh --boot..