Kafka 토픽 네이밍 규칙이 필요한 이유
- 일관된 네이밍 규칙이 없다면, 시간이 지나면서 토픽의 이름이 불규칙해지고 찾기 어려워짐
일반적인 Kafka 토픽 네이밍 규칙
- kafka 이름은 영어, 숫자, 마침표, 밑줄, 하이픈이 사용됨
- 하지만 마침표와 밑줄을 같이 사용하는 건 추천 되지 않음
- 보통 이름은 소문자로 통일하고 케밥 케이스를 사용하는 편 ex) my-app-topic
- 토픽 이름의 구성 요소
- 데이터 센터: 데이터가 위치한 데이터 센터. 예를 들어 AWS나 Azure 같은 서비스
- 도메인: 데이터가 속한 시스템의 도메인을 정의. 제품명이나 팀이름이 아닌, 시스템의 근본적인 영역을 나타냄
- 분류: 데이터의 종류를 의미. fct(사실 데이터), cdc(데이터 변경 캡처), cmd(명령), sys(시스템)와 같은 분류 사용 가능
- 설명: 데이터의 유형을 설명하는 가장 중요한 부분으로, 토픽이 어떤 데이터를 담고 있는지 명확히 표현
- 버전: 데이터 스키마나 포맷이 변경될 때 버전을 명시하여, 이전 버전의 소비자에게 영향을 주지 않고 새로운 버전으로 전환할 수 있도록 함
ex) aws.analytics.fct.pageviews.0
- 피해야할 것들
- 변경가능한 필드: 팀이름, 서비스 이름, 제품이름 등은 변할 수 있기에 사용 하지 않는 것이 좋음
- 메타데이터: 파티션 수, 보안 정보, 스키마 정보 등은 이름에 포함하지 않고 필요시 외부 시스템에서 관리하는 것이 좋음
- 버전 관리
- 토픽 이름에 버전을 포함시키는 것은 좋은 방법이지만, 필요 이상의 버전이 생성되지 않도록 주의해야 합니다. 버전 관리는 스키마 레지스트리를 사용해 중앙에서 관리하는 것이 이상적입니다. 또한, Kafka 레코드의 헤더에 버전 정보를 포함시키는 방식도 고려할 수 있습니다.
- 네이밍 규칙 적용
- 네이밍 규칙을 정의하는 것만큼이나 중요한 것은 이를 일관되게 적용하는 것
- Kafka의 auto.create.topics.enable 설정을 false로 설정하여 자동 토픽 생성을 방지하고, CI/CD 파이프라인에서 토픽 생성을 관리함으로써 규칙 준수를 보장 가능
[예시]
AWS에서 실행되는 분석 관련 페이지뷰 데이터: aws.analytics.fct.pageviews.0
Azure에서 실행되는 GPS 데이터: azure.comms.fct.gps.0
출처2: https://digitalbourgeois.tistory.com/269#google_vignette
'개발 공부 > kafka' 카테고리의 다른 글
| 5. Kafka 메시지 처리 실패 시 대처 방법 (feat. Spring) (DLT, 재시도) (+실습) (0) | 2025.11.24 |
|---|---|
| 4. Kafka의 Producer, Consumer 서버 만들기 (feat. Spring) (+실습) (0) | 2025.11.23 |
| 3-1. Kafka의 핵심 요소와 작동 (Topic, Consumer, Producer, Consumer Group, OffSet, CURRENT OFFSET) (+ 실습) (0) | 2025.11.21 |
| 2. Kafka 간단히 설치해보기 (feat. EC2) (+실습) (0) | 2025.11.20 |
| 1. Kafka와 메시지큐 (정의, 형태) (0) | 2025.11.20 |