이 글의 코드 및 정보들은 책을 바탕으로 작성하였습니다.
카프카 데이터 모델글을 통해
토픽의 파티션을 늘리고
그 수만큼 프로듀서도 늘려줘야
카프카를 효율적으로 사용할 수 있음을 알았다.
그런데 여기서 2가지 질문을 던질 수 있다.
무조건 파티션 수를 늘리는게 답일까?
내 토픽의 적절한 파티션 수는 어떻게 알 수 있을까?
이 글의 코드 및 정보들은 책을 바탕으로 작성하였습니다.
카프카가 고성능, 고가용성 메시징 Application으로 발전할 수 있던 배경에는
토픽과 파티션이라는 데이터 모델의 역할이 컸다.
토픽
파티션
토픽을 구성하는 데이터 저장소
수평 확장이 가능한 단위
나의 글이 1등했다.
이전에도 Weekly 순위에 들었던 적은 있지만 1등은 아니였다.
그래서 언제 1등해보나 ‘할 수 있을까?’ 란 생각이 있었는데
실제로 1등을 하다니 기분이 좋다. ㅎㅎ
기쁜 마음으로 포스팅해놔야겠다.
이 글의 코드 및 정보들은 책을 바탕으로 작성하였습니다.
분산 애플리케이션이
안정적인 서비스를 할 수 있도록
분산되어 있는 각 애플리케이션의 정보를
중앙에 집중하고 구성 관리, 그룹 관리 네이밍, 동기화 등의 서비스를 제공한다.
주키퍼는 위 그림처럼
서버 여러 대를 앙상블(클러스터)로 구성한다.
분산 어플리케이션들이 각각 클라이언트가 되어
주키퍼 서버들과 커넥션을 맺은 후 상태 정보 등을 주고받는다.
이 글의 코드 및 정보들은 책을 바탕으로 작성하였습니다.
Kafka는 Pub/Sub 모델이다.
만약 Pub/Sub 모델이 아닌 경우 발생할 수 있는 문제 상황을 알아보자.
위 그림에서 웹 서버군 1대가 추가된다면?
엄청난 복잡성을 띄게 된다.
구조가 매우 단순해졌다.
각 서비스 서버들은 Kafka로 메시지를 보내는 역할을 하게 되고
모니터링 혹은 분석 시스템들도
서비스 서버들의 상태 유무와 관계없이
Kafka에 저장되어 있는 메시지만 가져오면 된다.
각자의 역할이 확실하게 분리되면서
어느 한쪽 시스템에 문제가 발생해도
연쇄 작용이 발생할 확률은 낮아진다.