Apache Kafka Summary

Apache Kafka

아파치 카프카는 오픈 소스 분산 이벤트 스트리밍 플랫폼으로 LinkedIn에서 개발된 메시징 시스템이다.

---

카프카가 만들어지기 전에는 다음과 같다.

-데이터 연동 복잡
-서로 다른 데이터 파이프라인 연결
-확장의 어려움

---

LinkedIn이 해결하고자 한 것은 다음과 같다.

-모든 시스템으로 데이터를 실시간 처리 가능
-확장이 용이

발행된 메시지를 한 곳으로 모아 필요한 주체가 가져다 사용한다.
Publish-Subscribe 모델로 구현되었으며 프로듀서(Producer, 생산자), 컨슈머(Consumer, 소비자), 브로커(Broker, 중재자)로 구성되어있다.

---

주요 개념

• Broker : 실행된 카프카 애플리케이션 서버 중 1대로 프로듀서가 발행한 메시지를 받아 컨슈머로부터 요청된 메시지를 제공
• Zookeeper : 카프카의 상태와 클러스터 관리
• Producer : 메시지 발행
• Consumer : 메시지 소비
• Cluster : 브로커 그룹
• Topic : 메시지 종류
• Partition : Topic이 나눠지는 단위
• Log : 1개의 메세지이며 컨슈머가 소비하고 없어지는게 아닌 카프카 설정에 의해 삭제되며 기본은 7일로 설정
• Offset : 파티션 내에서 각 메시지가 가지는 Unique Id

---

처리방식

프로듀서가 메시지를 발행하면 브로커로 전달되고 토픽의 파티션에 데이터가 기록(Record)된다.
예를 들어 Test 라는 토픽에 파티션이 3개가 있다고 한다면 파티션 0~2 까지 전부 기록할 수 있고 특정 파티션에만 기록할 수도 있다.
파티션은 고유의 오프셋을 가지기 때문에 기록되는 데이터는 파티션 마다 별도로 관리된다.
기록된 데이터는 컨슈머가 필요한 데이터를 요청하면 해당 데이터만 반환하기 때문에 속도가 매우 빠르다.

---

컨슈머를 그룹으로 처리할 때는 반드시 해당 topic의 파티션은 그 consumer group과 1:n 매칭을 해야한다. 그렇기 때문에 아래의 경우가 존재한다.

• partiton 3 :consumer 2 = consumer 중에 하나는 2개의 파티션을 소비
• partiton 3: consumer 3 = consumer 1개랑 파티션1나랑 1:1매칭
• partiton 3: consumer 4 = consumer 1개가 아무것도 하지 않음
  그렇기 때문에 파티션을 늘릴때는, Consumer의 개수도 고려해야한다. 보통은 개수를 같이 맞춰주는 것을 권장하지만, 실제 메세지가 쌓이는 속도보다 처리하는 속도가 훨씬 빠르다면 굳이 1:1매핑보다는 파티션개수 => 컨슈머 개수 로 설정하는 것도 나쁘지 않다.

컨슈머 그룹은 하나의 topic에 대한 책임을 갖고 있다. 같은 그룹내의 어떤 컨슈머가 down된다면, 걔가 원래 파티션1에 대해서 소비를 맡았던 놈인데, 파티션1에 대한 소비를 할 수 없는 상황이다. 이런 상황을 Rebalance 라고 한다. 리밸런스가 된 상황이면, 파티션 재조정을 통해서 다른 컨슈머가 파티션1의 소비를 이어서 하게된다. 물론 위에서 설명한 offset 정보를 그룹내에서 서로간의 공유하고 있기 때문에, 뻗기 직전의 offset위치를 알고 그 다음부터 소비하면 문제가 없어지는 것이다.

출처 : https://medium.com/@umanking/%EC%B9%B4%ED%94%84%EC%B9%B4%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-%EC%9D%B4%EC%95%BC%EA%B8%B0-%ED%95%98%EA%B8%B0%EC%A0%84%EC%97%90-%EB%A8%BC%EC%A0%80-data%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-%EC%9D%B4%EC%95%BC%EA%B8%B0%ED%95%B4%EB%B3%B4%EC%9E%90-d2e3ca2f3c2

---

카프카는 고가용성을 제공하기위해 파티션 데이터의 복사본을 유지할 수 있으며 얼만큼 저장할 것인지는 리플리케이션 팩터를 통해 토픽 별로 달리 설정이 가능하다. 예를 들어 3으로 설정한 경우 이들 중 하나는 리더가 되고 나머지는 리플리카가 된다. 리더의 변경사항을 나머지 리플리카들이 잘 따라가면 ISR(In-Sync Replica)를 구성하고 리더가 있는 브로커에 장애가 생기면 나머지 리플리카 중 하나가 새로 리더가 되어 클라이언트 요청을 담당한다. 리더의 변경사항을 지속적으로 못따라가면 데이터 유실 방지를 위해 ISR에서 빠지게 된다.