Topic Naming Convention

목차

[INTRO]

카프카에서의 화두 중 하나는 카프카 토픽의 이름을 어떻게 짓는것이냐이다.

보통 많은 회사들이 기존의 토픽명의 관습에 따라 많이 짓는다고 한다.

아래와 같은 네이밍 규칙이 권장된다.

 

<namespace>.<product>.<event-type>

<application>-<data-type>-<event-type>

<organization>.<application-name>.<event-type>.<event>

 

그리고 chris riccomini는 아래와 같은 네이밍 규칙을 사용하기도 했다고 한다.

 

<message type>.<dataset name>.<data name>

 

[카프카에서 유효한 토픽명]

카프카에서는 '_', '-', '.' 이며 아래 정규식이 카프카에서 사용할 수 있는 토픽명이다.

하지만 '_','-' 등을 혼용해서 사용할 경우 충돌이 날 수 있기 때문에 혼용하지 않도록 해야한다.

 

legalChars = "[a-zA-Z0-9\\._\\-]"

 

또한 토픽명은 대소문자를 구분한다.

 

[카프카에서 토픽명을 정할 때 몇가지 지침들]

토픽명의 포맷을 정해라

가장 중요한 것은 포맷을 정하는 것이다.

아래와 같은 예시가 있을 것이다.

 

• my-topic-name
• myTopicName
• my_topic_name
• itlabs.mytopic.name
• ITLabs-Website-Tracker

명명규칙을 일관되게해야 혼동되지 않는다.

 

* 토픽명에 어떤 것이 들어가야 하는지 정한다

포맷이 정해졌으면 토픽명에는 어떤것이 들어가는지, 순서는 어떻게 될지 정한다.

이 때 어떤 것이 토픽명에 들어가야하는지 몇가지 지침이 있다.

 

* 이름이 변경되는 필드를 토픽명에 포함시키지 마라..!

팀명, consumer명과 같은 필드들을 토픽명에 포함시키면 변경이 있을 때 대응하기 매우 힘들다.

 

* 메타데이터, 스키마와 같은 정보를 포함시키지 마라

메타데이터는 카프카 브로커를 통해 제공될 수 있고, 메시지 스키마도 Schema-Registry를 사용하여 표현할 수 있다. 단일 진실 공급원을 유지하기 위해 메타데이터 정보는 제외하도록 하자.

 

* 토픽명에 파티션정보, 보안정보 같은건 넣지마라

이것도 일종의 메타데이터와 같은 맥락으로 정보성인 것들은 안넣는것이 좋다.

 

* 토픽명을 Producer, Consumer와 연관짓지 마라

카프카 클라이언트들은 언제든 바뀔 수 있고, 메시지를 처리하는 주체가 바뀔 수 있다.

 

 

[예시]

[application name].[namespace].[data type].[event type]
devfoxstar.blog.posting.sending

[namespace].[data type].[event type].[version numbers]
blog.posting.sending.0

[development enviroment].[application name].[namespace].[data type].[event type] dev.devfoxstar.blog.posting.sending

 

[결론]

토픽명을 짓는데 정답은 없다.

하지만 기본적으로 카프카 토픽명을 짓는데 규칙이 있고, 그 규칙을 준수하는 선 내에서 조직에서 가장 효과적으로 관리할 수 있는 이름이 토픽명이 되면 된다.

 

 

[참조]

Kafka Topic Naming Conventions: Best Practices | by Kiran Prabhu | Medium

Kafka Topic Naming Conventions: Best Practices