Kafka 메시지 브로커 활용기 - 1

개요 📝

A 사에서 진행하는 x 프로젝트에서는 기존에 A 사에 구축된 시스템과 연동을 통해 데이터를 받아오는 로직이 존재했었다. 새롭게 A 사에서 수주한 y 프로젝트는 x 프로젝트가 받아오는 데이터가 필요했으나, x 프로젝트와 같이 A 사 시스템과의 연동은 보안 문제로 허용되지 않는 상황이었다. 결국 x 프로젝트에서 A 사와 연동해 가져온 데이터를 y 프로젝트 쪽 DB로 넘겨주는 방안이 필요했고, 이를 위해 메시지 브로커인 Kafka를 사용하게 되었다.

 

내용 📌

앞에서 설명했듯이, 나는 데이터를 주고받는 중계자의 역할로서 Kafka를 활용하게 되었다. API 가 아닌 외부 브로커인 Kafka를 사용했던 이유는 데이터 송수신 간 아래와 같은 장점이 있기 때문이었다:

• Kafka를 사용하는 애플리케이션 인스턴스가 오류로 인해 중지되어도, 인덱스를 이용해 마지막까지 읽어 들인 데이터부터 다시 수신할 수 있다.
• Polling 방식으로 데이터를 읽어 들이므로, 실시간으로 데이터의 변동 사항을 반영할 수 있다.

위와 같은 이유로, DB 쿼리에의 의존성 및 서버에의 부하를 감소시키는 방향으로 진행이 가능했다.

구축 방식을 살펴보기 이전에, 먼저 Kafka의 기본 개념들을 살펴보도록 하자.

특징

• 비동기 메시지 처리
• Topic에 대해 Sub / Pub으로 메시지 주고받음
  
  

구성

• Zookeeper
  • Kafka 내의 메시지 큐 메타데이터 관리용
  • KRaft를 지원하는 버전 (KIP-500, 2019.08.01부터) 은 자체 클러스터 내에서 메타데이터를 관리하므로 Zookeeper 를 사용하지 않음
• Kafka Cluster

• Kafka Server (Broker)
  • 여러 개 구동 가능

• Partition
  • Log (각 Partition 도 여러 Log로 나누어진다)
    • Key
    • Value
    • Timestamp

 

Facts

1. Producer는 순차적으로 Topic에 맞게 (Queue) 메시지를 Partition에 쌓는다. 이때, Partition 이 여러 개인 경우 Round-Robin 방식으로 쌓는다.
2. Comsumer Group과 Topic 은 1 : 1 관계이다. (단방향)
3. Topic과 Consumer Group 은 1 : N 관계이다. (단방향)
4. Consumer 인스턴스 : offset을 Partition과 공유한다.
5. 즉 Consumer Group 내에서 Consumer 인스턴스는 한 번에 하나의 Partition 만 접근할 수 있다. (Partition : Consumer Instance = 1 : 1 (단방향))
6. Partition의 개수가 많을수록 병렬 처리의 이점이 있으나 단점도 존재한다. 바로 Partition 은 한 번 개수를 늘리면 줄이는 것이 불가능하다는 점이다.
7. Partition 중 Leader와 Follower를 설정할 수 있으며, Follower는 Leader를 복제하며 Leader와 다른 브로커에 존재한다. Leader 가 다운되었을 때를 대비해서 In-Sync Replica를 만드는 것이다.

정해야 할 것들

• Topic
• Partition 개수
• Consumer 개수
• 보존 기간
• 메시지 보존 기간은 log.retention.hours의 값에 따라 정할 수 있다. (기본값 = 7일)

장점

• 여러 개의 Consumer를 고려한 설계 덕분에 소비가 효율적으로 이뤄진다.
• 매번 찾아서 메시지 pull 하는 게 아니라 offset을 활용, 이전에 consumer 가 공유해 준 정보를 통해 움직인다. (캐싱 같이?)

단점

• 데이터 유무에 관련 없이 정기적으로 polling 한다.
• 그러나 데이터가 도착할 때까지 대기하는 long poll 방식을 쓸 수 있게 하는 parameter 가 있다.

 

지금까지 카프카에 대해서 간략하게 알아보았다.

이제 2부에서는 카프카를 실제로 어떻게 스프링에서 적용할 수 있는지 알아보겠다.