[Apache Kafka] kafka topic convention에 대한 고민 (2022.12.29)

0. Table Of Contents

• 0. Table Of Contents
• 1. 발생한 이슈 사항
• 2. 기본적인 Kafka Topic Convention
• 3. 개인적으로 cut 한 생각들

 

1. 발생한 이슈 사항

모식도를 먼저 그려보면 아래 그림과 같다.

 

 

여러 공장에서 여러개 장비에 대한 buffer 데이터를 cluster에 전송한다. 이 때, 보낸 데이터에 대한 식별자가 필요한데 이를 topic으로 관리한다. topic convention에 대해 고민하는 도중 아래와 같은 고민이 들었다.

• 장비별로 topic을 생성한다
• 공장별로 topic을 생성한다.

 

이외에도 convention을 지정하기 위한 고민을 하며 들었던 생각 전체를 이 글에 적어놓고자 한다.

 

 

2. 기본적인 Kafka Topic Convention

 

여러가지 요소들을 고민한 결과, 공통적으로 사용 할 수 있는 topic은 아래와 같이 정하기로 하였다.

 

<company>.<project|application>.<dataSource>.<eventType>.<etc>

 

그 이유는

• 최대한 변하지 않는 속성이어야 한다. kafka topic을 한번 만들게 되면 수정이 불가능하기 때문에 맨 처음부터 불변하는 속성값이어야 한다.
• 계층 구조를 선택하였다. url pattern처럼 한눈에 어떤 속성인지 볼 수 있어야 하며 정리되지 않을 경우 한번에 속성을 알아 차릴 수 없을 가능성이 높다.
  • 예를 들어 대한민국-인천-국제공항 / 국제공항-대한민국-인천 어느 것이 더 가독성이 좋은지에 대해 생각해보자.
• 적당한 카디널리티를 유지할 수 있는 패턴이어야 한다. 너무 많은 카디널리티가 형성되게 되면 그만큼 topic과 broker 별로 replication factor에 따라서 다량으로 복제 될 수 있으며 불필요한 영역이 많이 형성되어 관리에 어려움을 겪을 수 있다고 생각하였다.

 

위 convention을 이용하여 향후 acelo grid에 사용 될 topic을 만들면 아래와 같은 형태가 될 것으로 보인다.

 

<company>.<project|application>.<dataSource>.<eventType>.<etc>

 

3. 개인적으로 cut 한 생각들

 

• topic에 mongodb _id 값을 이용한다.
  • 이를 사용하게 되면 이 id가 어떤 값인지 mongodb를 이용하지 않게 되면 알 수 없으며 다른 프로젝트에서 이종의 db를 사용하게 될 경우 문제가 발생할 수 있다.
• topic 생성시 device 단위까지 고려하여 모든 기기별로 별도의 topic을 가진다.
  • 이 경우, device를 생성하게 되면 topic을 같이 생성해야하는 이슈가 발생 할 수 있다. 이 경우 만약 topic 자동 생성이 불가한 구조에서는 관리자의 load가 커질 가능성이 있으며, topic 자동생성이 가능한 구조에서는 개발단계에서 생성한 쓰레기 topic이 많이 생겨나 관리에 어려움을 겪게 될 것이라고 생각을 하여 기기별 topic이 아닌 datasource별 topic으로 관리하는 것으로 생각했다.