아파치 카프카

카프카는 분산형 메시지 스트리밍 브로커로, 대용량의 실시간 이벤트를 처리할 수 있다.
링크드인의 시스템 아키텍처는 확장이 어렵고 혼란스러웠음:
대규모 시스템은 유저 활동 로그(페이지뷰, 좋아요, 검색 쿼리 등), 운영 메트릭(서비스 콜 스택, 콜 레이턴시, 에러, CPU, 메모리 사용량 등)와 같은 방대한 로그 데이터를 만들어 낸다. 실제 데이터에 비해 로그 데이터는 그 양이 훨씬 많고 빠르게 증가하기 때문에 다루기 어렵다.
결과적으로 카프카를 중심으로 데이터가 흐르는 아키텍처를 구축했다:

Architecture and Design

메시지를 생산하는 프로듀서(producer)와 메시지를 소비하는 컨슈머(consumer)가 있다.
프로듀서는 메시지 큐에 메시지를 발행하고, 컨슈머는 큐에서 순차적으로 메시지를 수신한다.
이때 특정 유형이나 주제의 메시지 스트림을 토픽(topic)이라고 한다.
컨슈머는 구독 중인 토픽에 새 메시지가 도착하면 이를 수신한다. 한 컨슈머가 여러 토픽을 구독할 수도 있다.
- RabbitMQ나 ActiveMQ와 달리 push 방식 대신 pull 방식으로 동작한다.
  - push 모델의 장점은 낮은 레이턴시, 단점은 컨슈머의 오버헤드.
  - pull 모델의 장점은 컨슈머의 처리율에 따른 조정과 일괄처리, 단점은 폴링으로 인한 컨슈머 자원 소모.
- 이를 통해 컨슈머의 처리 능력에 따라 메시지를 소비할 수 있다.
만약 토픽에 소비할 메시지가 없다면, 토픽에 새 메시지가 발행될 때까지 메시지 스트림 이터레이터가 중단된다.
각 메시지는 오프셋으로 식별되며, 컨슈머가 메시지를 수신한 뒤에는 다음 메시지의 오프셋을 연산해 얻는다.

상기했듯이 특정 유형의 메시지 스트림을 토픽이라고 한다.
하나의 토픽은 여러 개의 파티션(partition)으로 구성되며, 메시지는 모든 파티션에 균등하게 분배된다.
토픽의 각 파티션은 FIFO 큐처럼 동작한다. 즉, 같은 파티션에 속한 메시지는 순서대로 처리된다.
프로듀서는 1개 이상의 토픽에 메시지를 발행하고, 발행된 메시지는 브로커에 저장된다.
파티션을 유지하는 서버를 보통 브로커(broker)라고 부르며, 여러 브로커에 파티션을 분산해 확장성을 높인다.
- 브로커에는 상태가 없다. 따라서 모든 컨슈머가 메시지를 수신했는지 알 수 없다.
- 브로커의 메시지는 일정 주기(보통 7일) 뒤 삭제된다.
  - Redis Pub/Sub의 경우 메시지가 디스크에 저장되지 않기 때문에 유실될 수 있다.
  - ActiveMQ와 RabbitMQ는 메시지를 디스크에 저장하는 옵션이 있지만, 기본적으로는 소비된 메시지를 삭제한다.

카프카는 일대일 모델과 발행-구독 모델을 모두 지원한다.
카프카에는 컨슈머 그룹이라는 개념이 있음. 각 컨슈머 그룹은 한 개 이상의 컨슈머로 구성된다.
하나의 컨슈머 그룹은 여러 토픽을 구독할 수 있고, 오프셋을 별도로 관리한다:
- 그룹 단위로 토픽을 구독할 수 있으며, 메시지는 그룹 내의 컨슈머 중 하나에게만 전달된다.
- 같은 그룹에 속한 컨슈머들은 서로 다른 프로세스 또는 머신에서 동작할 수 있다.
- 즉, 컨슈머 그룹을 통해 메시지를 병렬적으로 처리할 수 있다.

카프카의 목표는 코디네이션 오버헤드를 최소화하면서 메시지를 분배하는 것.
- 따라서 카프카에는 중앙집중식 마스터 노드가 없다. 대신 탈중앙화된 방식으로 동작한다.
- 고가용성 컨센서스 서비스 주키퍼(Zookeeper)를 사용해 카프카 클러스터의 메타데이터를 관리한다.
주키퍼는 계층적 키-값 저장소를 제공한다. 분산 설정 서비스, 동기화 서비스, 네이밍 레지스트리로 사용한다.
카프카 클러스터의 메타데이터를 주키퍼에 저장함으로써 브로커의 무상태성을 유지할 수 있다.
뿐만 아니라 주키퍼는 리더 브로커의 선출을 돕는다.
- 마스터-슬레이브 모델이 아닌거지 복제를 위해 리더-팔로워 모델을 사용한다.
- 레플리카 중 하나가 리더로 선출되면 모든 읽기, 쓰기 요청을 처리한다.
- 팔로워는 리더의 파티션을 복제해두며, 리더에 문제가 생기면 ISR(In-sync Replicas) 중 하나가 리더로 선출.