Apache Kafka - 아키텍처 설계 가이드: 파티션, 복제 계수 및 토픽 네이밍 컨벤션

파티션 개수와 복제 계수 설정하기

토픽을 생성할 때 가장 중요한 두 가지 요소는 파티션 개수와 복제 계수다. 이 두 요소는 시스템 성능과 지속성에 직접적인 영향을 미치기 때문에 처음부터 신중하게 설정해야 한다.

파티션 개수 변경의 영향

토픽 생성 후 파티션 개수를 늘리면 키 순서가 보장되지 않게 된다. 키를 기반으로 데이터를 전송하는 경우 이는 심각한 문제가 될 수 있다.

복제 계수 변경의 영향

토픽 라이프사이클 중에 복제 계수를 높이면 시스템에 상당한 부담을 준다:

• 네트워크 통신 증가
• 디스크 공간 사용량 증가

적절한 파티션 개수 설정 가이드라인

파티션 개수를 결정할 때 고려해야 할 사항들:

1. 성능 측정: 각 파티션이 처리할 수 있는 스루풋(초당 메가바이트)을 측정해야 한다.

2. 파티션 증가의 장점:

   • 병렬 처리 증가
   • 스루풋 향상
   • 컨슈머 그룹 확장 가능성 증가 (컨슈머 그룹 내 최대 컨슈머 수는 토픽의 파티션 개수와 같음)
   • 대형 클러스터에서 브로커 활용도 증가

3. 파티션 증가의 단점:

   • 주키퍼 사용 시 브로커 다운 시 선출 작업 증가 (KRaft 모드에서는 해결됨)
   • 더 많은 파일이 열림

4. 권장 파티션 수 계산법:

   • 작은 클러스터(브로커 6개 미만): 브로커 개수 × 3
   • 큰 클러스터(브로커 12개 초과): 브로커 개수 × 2

5. 파티션 수 증가가 필요한 경우:

   • 컨슈머 그룹 내 컨슈머가 많고 최대 스루풋에서 병렬 실행이 필요할 때
   • 프로듀서 스루풋이 높거나 향후 증가가 예상될 때

6. 중요 조언: 반드시 테스트하고, 또 테스트하세요. 각 Kafka 클러스터는 하드웨어에 따라 성능이 다르다.

7. 흔한 실수 피하기: "그냥 파티션 1000개 두자"와 같은 과도한 설정은 피하고, 토픽에 적합한 파티션 수를 설정

적절한 복제 계수 설정 가이드라인

1. 운영 환경 권장 값:

   • 최소: 2
   • 일반적: 3
   • 최대: 4

2. 복제 계수 증가의 장점:

   • 시스템 지속성 향상 (N-1개의 브로커가 실패해도 데이터 제공 가능)
   • 시스템 가용성 향상 (N-min.insync.replicas만큼 가용, 특히 acks=all 설정 시)

3. 복제 계수 증가의 단점:

   • 지연 시간 증가 (acks=all 설정 시 모든 레플리카로부터 확인 필요)
   • 디스크 사용량 증가 (복제 계수 2→3으로 증가 시 50% 추가 사용)

4. 권장사항: 복제 계수 3으로 시작하고, 최소 3개의 브로커를 사용

5. 성능 문제 발생 시: 복제 계수를 줄이기보다 더 좋은 브로커를 사용

6. 중요 경고: 운영 환경에서 절대로 복제 계수를 1로 설정하면 안 된다.

Kafka 클러스터 규모 가이드라인

1. 클러스터 내 파티션 제한:

   • 주키퍼 사용 시 최대 20만 개 (주키퍼의 스케일 제한)
   • 브로커당 권장 파티션 수: 4천 개 (소프트 리밋)
   • 20만 개 파티션을 가진 클러스터는 약 50개의 브로커 필요

2. KRaft 모드 사용 시: 수백만 개의 파티션으로 확장 가능 (주키퍼 제한 극복)

3. 확장 전략:

   • 더 많은 파티션이 필요하면 브로커 추가
   • 20만 개 이상의 파티션이 필요하면 Netflix 모델 따라 독립 클러스터 추가 생성

---

토픽 네이밍 컨벤션

토픽 이름은 자유롭게 지을 수 있지만, 클러스터 관리를 용이하게 하기 위해 일관된 가이드라인을 따르는 것이 좋다.

권장 네이밍 패턴

<message_type>.<dataset_name>.<data_name>.<data_format>

각 구성요소 설명

1. 메시지 타입 (message_type):

   • logging, queuing, tracking, etl/db, streaming, push, user 등
   • 언더스코어(_)를 사용한 snake_case 권장

2. 데이터셋 이름 (dataset_name):

   • RDBMS 시스템 이름과 유사
   • 토픽을 그룹화하는 카테고리
   • 언더스코어(_)를 사용한 snake_case 권장

3. 데이터 이름 (data_name):

   • 데이터베이스 테이블과 유사
   • 원하는 표기법 사용 가능
   • 데이터셋 내에서 점(.)을 사용해 계층 표현 가능

4. 데이터 포맷 (data_format):

   • .avro, .json, .text, .protobuf, .csv, .log 등
   • 데이터 형식을 즉시 식별 가능하게 함

예시

logging.ecommerce.user_clicks.json
queuing.payment_system.transactions.avro
tracking.website.page_views.protobuf

네이밍 컨벤션의 중요성

이러한 네이밍 컨벤션은 특히 Kafka에 보안을 적용할 때 더욱 중요해진다. 일관된 분류 체계와 패턴이 있으면 권한 관리와 토픽 구성이 훨씬 쉬워진다.

---

결론

Kafka 아키텍처를 설계할 때 파티션 개수와 복제 계수는 신중하게 결정해야 하는 중요한 요소다. 처음부터 적절하게 설정하고, 필요에 따라 테스트를 통해 조정하는 것이 중요하다. 또한, 일관된 토픽 네이밍 컨벤션을 사용하면 클러스터 관리가 훨씬 용이해진다.

이러한 가이드라인을 따르면 Kafka 클러스터를 더 효율적으로 관리하고 확장할 수 있으며, 장기적으로 운영 부담을 줄일 수 있다.