아파치 카프카 애플리케이션 프로그래밍 with 자바 3장, 의미 있는 토픽 이름 작명법을 읽고 정리한 내용
아래 글을 읽고 정리한 내용
토픽 이름 짓기
대부분 카프카 클러스터는 공용의 자원이다. 많은 사용자(프로듀서, 컨슈머, …)가 쓰고, 많은 데이터 종류가 저장된다. 누가 사용하는지 또 어떤 종류의 데이터인지 토픽 이름으로 추상화하는 것은 중요하다. 당장 내일부터 서울의 시내 버스가 (나름의 규칙이 있는)번호 대신 임의의 이름을 쓴다거나(”용산부터양재까지”, “전기_저상_3”, “자바2명타세요~”), 지하철 색이 사라진다고 생각해보자. 끔찍하다.
토픽 이름에 대한 규칙(naming convention)은 너무나도 중요하다.
auto.create.topics.enable 을 끄자
그런데 그렇게 세상을 어지럽히는 존재가 있다. 필요 없는 기능이라고 과감하게 말할 수 있다. 카프카를 poc하며 체험판을 쓸 때라면 모를까. 적어도 그런 poc를 prod까지 옮기진 말아야 한다. git commit -m 플래그만큼 쓸모 없는 기능이라고 생각한다.
토픽 이름은 변경할 수 없다.
처음부터 잘 지어야 하고, 그렇기에 이름 규칙의 중요성이 더 부각된다. 토픽 이름을 바꾸는 방법은 새 토픽을 만들어 그곳으로 이벤트(데이터)를 옮기고 기존 토픽은 삭제하는 것이다.. 이벤트를 옮길 때 컨슈머의 처리, 리파티셔닝 등 고민할 사항들이 생긴다.
그럼에도, 이름을 바꾸는 이유가 이름 규칙이 바뀌었기 때문이라면 빠르게 바꾸는 것이 나을 것이다. 그만큼 이름 규칙에 있는 가치가 크기 때문이다.
의미 있는 토픽 이름 작명법
책에선 몇 가지 기준을 제시한다:
•
“용도”, “누가” 사용하는지, 어떻게? 만들어졌는지 등을 담아 모호하지 않게
•
오너십이 드러나도록; e.g. 팀 이름(템플릿 2)
•
(필요하다면)히스토리 추적 가능하도록; e.g. 티켓 번호(템플릿 3)
•
여러 카프카 클러스터의 경우 구분이 필요하다.
•
kebab-case + . 도메인 구분 그리고 위 기준에 해당하는 템플릿과 예시이다:
1.
<env>.<team>.<app>.<msg-type> : prd.marketing.sms-platform.json
2.
<project>.<service>.<env>.<event> : commerce.payment.prd.notification
3.
<env>.<service>.<ticket-num>.<msg-type> : dev.email-sender.jira-1234.email-vo-custom
4.
<cluster>.<env>.<service>.<msg-type> : aws-kafka.live.marketing-platform.json
Kafka Topic naming conventions - 5 recommendations with examples
Kadeck이라는 아파치 카프카 모니터링 서비스에서 쓴 토픽 이름 규칙과 관련한 글이다. 여기선 다섯가지 항목의 추천 또는 팁으로 토픽 이름 규칙 생성에 대해 이야기한다.
don’t do too little, but don’t overdo it either!
여기선 “Beer coaster rule”에 대해서도 강조한다. 자신 조직에 어울리는 딱 맞는 것을 찾아야 한다. 너무 광범위한 사례에 대한, 베스트 프랙티스는 우리에게 “베스트”가 아닐 수 있다.
살짝 쿠션 멘트 같기도 하지만, 이름 규칙의 적용은 위에 있는 템플릿 하나 고른다고 해결되지 않는다는 걸 의미한다. 그럼에도 딱 맞는 “맥주 받침”을 고르기 위해 추천하는 것들을 살펴보자.
1. separate.with.dots.lowercase
첫 추천은 실용적인 내용이다. 점으로 구분하는 역 도메인 표기법(reversed DNS)를 사용하라고 한다.
토픽 이름은 underscore(_)와 점(.)을 구별하지 않는다. 둘 중 하나만 써야하는데, reversed DNS라는 이미 검증되고 익숙한 방법이 있으니 점을 채택한 것이다.
또 여기선 lowercase만 쓰라고 했지만, 대시(-)를 포함한 kebab-case 역시 괜찮다고 생각한다. 한 서브 도메인의 이름이 길어질 수 있으니. PascalCase나 camelCase를 피하라는 이야기다(snake_case를 안쓰는 이유는 위에서 설명된다).
2. domain.subdomain1.subdomain....data
Use business domains and subdomains as part of the name to give data a unique label
토픽이 담겨 있는 “데이터”를 나타낼 수 있어야 한다. 위와 반복되는 이야기이지만, 소유권이 중요하다. 데이터 사용자는 여럿일 수 있다. 따라서 생성자에게 소유권이 있다(프로듀서 이름 자체를 의미하지 않는다).
또는 DDD 관점에서 도메인으로 구분하는 것을 추천 예시로 채택했다. 그리고 데이터의 기능적인 기술적인 이름은 제일 마지막에 써준다:
•
risk.portfolio.analysis.loans.csvimport
•
sales.ecommerce.shoppingcarts
3. “official”/”internal”(public/private)
Mark “official” topics that can be used outside your domain (e.g. after data quality measures have been taken) and “internal” topics
이번엔 소유권이 아닌 데이터를 사용하는 입장의 이야기이다. DDD에선 이 사용 범위를 도메인 안팎(public/private)으로 정의하는 것 같다(나중에 DDD를 공부해봐야겠다).
따라서 이에 대한 명시를 앞선 이름 규칙 제일 앞에 오게 붙이도록 추천한다:
•
public.sales.ecommerce.shoppingcarts
•
private.risk.portfolio.analysis.loans.csvimport
4 . 그 외의 이름과 “숫자” 압수
Avoid using version numbers, team names, partition numbers or consumer/producer names as part of the topic name.
Use application names only in absolutely exceptional cases, if unavoidable, prefer “Domain Service Names” (see DDD).
도메인과 관련된 외의 것이 토픽 이름에 포함되지 않아야 한다. 큰 이유는 그런 이름들과 데이터와의 결합도(coupling)를 없애기 위함이다.
하지만 예외적으로, 정말 특정 앱의 데이터라면, 앱 이름을 토픽에 사용하라고 한다. 굳이 중립적인 추상화(도메인?)가 사람들을 더 헷갈리게 한다:
In such a case, it makes no sense to create a large abstraction layer, especially if everyone in the company asks for the data of application X anyway and the “neutral” name causes confusion. However, the name of the domain service (e.g. “pricingengine”) can often be used as a good alternative in the sense of Domain-Driven Design.
숫자가 데이터의 버전이라 하더라도 coupling 문제는 여전하다. 앱이 바라봐야 할 토픽이 버전마다 달라진다는 문제가 생긴다. 데이터 버전 관리는 레코드(로그) 헤더의 스키마와 중앙 스키마 레지스트리로 해결해야 한다.
그리고 나는 변수 이름 짓기에서와 비슷한 이유로도 숫자를 (이름에!) 쓰지 않는게 당연하다고 생각한다 .
.5. 멀티 테넌트 환경일 “경우에만” 테넌트(회사) 표기
Start your topic name with the company domain only in multi-tenant enviornments
회사의 reversed DNS를 네임스페이스처럼 표기하고 싶은 욕구는, 카프카를 사용하는 테넌트(회사)가 여럿일 경우 즉, 멀티 테넌트 환경일때만 사용하자. 회사가 하나로 자명하다면 굳이 토픽 이름만 길어진다.
습득 교훈
토픽 이름을 잘 짓기 위해 명명 규칙을 정하는 것도 중요하지만, 잘 따르는 것이 훨씬 중요하다. 그래서 Kadeck은 자신들 서비스에서 토픽 이름 규칙 강제와 validation하는 기능을 제공한다고 한다. 기회가 되면 꼭 도입하고 싶다.
다시 토픽 이름 짓기 규칙에 대해 정리해보면:
•
이름 규칙이 중요하다. 토픽 이름을 바꾸는 것은 어렵기 때문이다.
◦
그럼에도 규칙이 바뀐다면 빠르게 삭제, 재생성하여 규칙을 따르자.
•
auto.create.topics.enable 을 끄자.
•
데이터에 대해(용도, 목적 등) 충분히 추상화 시키자.
•
오너십이 포함되어야 한다.
•
DDD 관점에서의 추천(feat. Kadeck의 맥주 받침 제조법)
◦
점과 소문자(또는 kebab-case)로 표현
◦
reversed DNS = DDD의 소유권(데이터 생성자)
◦
그 앞에 사용 범위를 붙일 것; public/private
◦
버전 숫자, 그 외의 팀 이름 등 불필요한 데이터 커플링을 만드는 이름을 쓰지 말 것
▪
예외) 너무나 자명한 경우엔 굳이 추상화시키지도 말 것
◦
회사의 reversed DNS(네임스페이스)는 카프카 클러스터가 멀티 테넌트(회사)인 경우에 맨 앞에 추가
실제 적용해볼만큼 규모의 데이터와 조직 숫자에서의 경험이 없어서 예시가 풍부하진 않다. 잘 유념해두었다가 꼭 활용해보고 싶다.