[학습 테스트로 배워보는 kafka] 6. 학습 테스트로 카프카 파티션(kafka partition) 알아보기

---

해당 시리즈에서 제공하는 모든 소스코드는 github repository 에서 제공됩니다. 자세한 코드와 테스트 케이스는 github repository 에서 확인해주세요.

GitHub - my-research/kafka: apache kafka docs & practical usages(with spring) that i composed

이번 [학습 테스트로 배워보는 kafka] 시리즈는 아래 순서대로 챕터가 구성되고, 시리즈 외로 kafka 관련하여 더욱 많은 학습 정보는 kafka 심화 세션 에서 확인할 수 있습니다.

시리즈 목차

1. 시리즈를 시작하며
2. kafka 빠르게 훑어보고 아는체하기
3. kafka 컨셉과 용어 정리
4. 학습테스트 준비하기
5. 학습 테스트로 kafka producer 알아보기
6. 학습 테스트로 kafka consumer 알아보기
7. 학습 테스트로 partitioning 알아보기 <-- 현재 글
8. 학습 테스트로 consumer group 과 rebalancing 알아보기

학습의 단계별 순서로 목차가 구성되어있으므로 선행되어야 하는 챕터가 존재합니다

---

 

지난시간 우리는 Producer 와 Consumer 의 java client 의 기본적인 내용에 대해서 학습 테스트를 통해 알아보았다.

 

이번 시간에는 Partition 에 대해서 알아보도록 하겠다

 

partitioning

 

일반적인 데이터 처리의 파티셔닝은 데이터를 특정 기준에 따라 나누는 것을 의미한다.

 

이렇게 나뉜 여러개의 덩어리들을 독립적으로 처리해서 데이터 처리 자체를 병렬로 만들거나 검색이 용이하도록 만든다.

 

카프카에서도 동일하다

 

카프카는 토픽별로 파티셔닝을 지원한다

 

토픽 내의 데이터를 하나 혹은 그 이상의 파티션으로 나누어 이벤트 로그들을 관리한다

 

카프카는 이렇게 하나의 토픽을 여러개의 파티션으로 나눠서 데이터 분산 저장과 병렬 처리가 가능하도록 한다

 

왜 파티셔닝을 하는가?

 

데이터 처리의 개념에서 파티셔닝이나 카프카의 파티셔닝이나 결국 데이터를 더 빨리 처리하고자 하는 니즈에 의해 생겨났다.

 

만약 한개의 메시지를 발행하고 내부적으로 그 메시지를 처리하는데 1초가 걸린다고 해보자.

 

그럼 6개의 메시지를 발행하는데 총 6초가 걸릴 것이다

 

 

하지만 6개의 메시지를 3개의 파티션에 저장해야 한다면 너무나도 당연하게 2초로 시간이 단축되는 컨셉이다

 

 

토픽이 여러개의 파티션으로 나뉘면 이제 자연스럽게 메시지를 어떤 파티션에 보내야 하지? 혹은 토픽을 구독하는거야? 파티션을 구독하는거야? 이라는 주제로 고민을 시작해야 한다.

 

카프카의 파티션 할당

 

우리가 카프카 프로듀서 api 를 이용하여 카프카 브로커에 메시지(이벤트 로그)를 발행한다고 했을 때, 카프카 내부적으로는 해당하는 메시지를 어떤 파티션에 저장해야 하는가? 에 대한 partition assign 과정을 거치게 된다.

 

 

위 그림을 보면 알 수 있듯 카프카는 내부적으로 Partitiner 가 이벤트 로그(메시지)들을 어떤 파티션에 할당할지 결정하는 역할을 수행한다

파티셔너는 크게 2가지 파티션 할당 기법을 제공하는데, 다음과 같다

 

1. key based partitioning
2. Round Robin Partitioning

 

이 2가지에 대해서 알아보자

Key Based Partitioning

 

key based partition 은 우리가 메시지를 발행할 때 특정 키를 입력하여 해당 키를 hashing 한 값으로 파티션을 결정하는 방법이다.

파티션 키를 결정하기 위해서는 다음과 같은 과정을 거친다.

 

우선 파티션 키로 들어온 input 값을 murmur2 를 이용해서 해싱을 하고, 그 결과로 나온 hash 값에 파티션의 갯수만큼 mod 연산을 수행하여 실제 들어갈 partition 의 number 를 결정한다.

 

이제 테스트를 해보며 배워보자

 

테스트 1. 키를 이용한 파티션 Produce 테스트

테스트 설명

• 주석 1 & 2
  • for loop 을 돌면서 i 가 짝수/홀수에 따라 파티션 키를 각각 만들었다.
• 주석 3.
  • ProduceRecord 에 이벤트 로그를 partitionKey 와 value 형태로 생성한다
  • 앞서 producer 에서 학습했던 것 처럼 결과를 출력하는 callback 을 추가해주었다
• 주석 4.
  • 콘솔 결과 출력을 위해 blocking 한다

 

테스트를 실행시키면 다음과 같은 결과가 나온다

 

 

그럼 앞서 producer 파트에서 배웠던 테스트들 처럼 키를 명시하지 않으면 어떻게 될까?

 

아래 테스트에서 확인해보자

테스트 2. 라운드 로빈 파티션 Produce 테스트

테스트 설명

• 주석 1 & 2
  • for loop 을 총 6번 돈다
• 주석 2.
  • ProduceRecord 에 이벤트 로그를 partitionKey 없이 생성한다
  • 앞서 producer 에서 학습했던 것 처럼 결과를 출력하는 callback 을 추가해주었다
• 주석 4.
  • 콘솔 결과 출력을 위해 blocking 한다

 

이 테스트를 실행시키면 다음과 같은 결과가 출력된다

 

 

위의 결과를 보면 알 수 있듯이, 실제 키를 명시하지 않았지만 내부적으로 partitioner 에 의해 Round Robin 형태로 키가 할당되어 고르게 파티션에 들어간 것을 확인할 수 있다

 

테스트 3. 파티션 키 충돌 테스트

 

앞선 파티션 할당 동작중 해시 과정을 거친다고 했는데, 여기서 주의할 점이 있다.

 

아래의 테스트를 확인해보자

 

테스트 설명

• 주석 1
  • kafka 는 내부적으로 hash 를 하기 위해 murmur hashing 를 한다.
  • key-1 이라는 문자열을 hash 하고 임의의 파티션 수(2) 만큼 mod 연산을 수행하여 파티션 번호를 구한다
• 주석 2.
  • key-2 이라는 문자열을 파티션 키로 설정해 파티션 번호를 구한다
• 주석 3.
  • 두 키가 달라야 한다는 테스트 단언문이다

 

이 테스트는 서로 다른 키를 명시했기 때문에 실패해야한다.

 

 

하지만 안타깝게도 실패한다.

 

이것을 파티션 키 충돌이라고 한다.

 

서로 다른 파티션 키를 가졌더라도 해시값을 파티션 수로 mod 연산한 결과가 동일하기 때문에 이와 같은 문제가 발생하는 것이다.

 

개발자는 파티션 키를 잘 할당했다고 생각하지만 실제로 파티션 키가 동일하기 떄문에 한쪽으로 몰림 현상이 발생할 수 있는데, 이로 인해서 파티셔닝을 했지만 실질적으로는 아무런 효과도 얻을 수 없는 상황이 되어버린다.

 

이런 키 충돌을 최소화 하기 위해서 키에 대해서 사전에 충분한 테스트 과정이 있거나 파티션 수를 늘리는 것을 고려해야할 수도 있다.

 

파티션과 메시지 순서

 

파티션을 이야기할 때는 항상 순서에 대한 이야기가 나온다.

 

결론부터 이야기 하자면,

 

파티션 내부의 메시지 순서는 보장이 되지만 파티션간의 순서는 보장되지 않는다.

 

역시 테스트를 통해 알아보자

 

테스트 4. 단일 파티션에서 메시지 순서 확인 테스트

 

아래 테스트는 단일 파티션이 설정된 토픽으로 메시지를 발행하고 소비하는 테스트이다. 테스트 전문은 github 에서 확인할 수 있다.

 

테스트 설명

• 주석 1
  • 메시지를 발행한다.
  • 순서대로 알파벳과 이모지를 발행한다.
• 주석 2.
  • consumer 에 특정 토픽에 대해 subscribe 한다.
• 주석 3 & 4
  • consumer 의 poll() 연산을 통해서 메시지를 소비하고 해당 메시지 스트림을 String 리스트로 변환한다
• 주석 5
  • 테스트 단언문을 통해 List 의 내용물과 동일한 순서인지 검증한다

이 테스트는 성공한다

테스트 5. 다중 파티션에서 메시지 순서 확인 테스트

아래 테스트는 다중 파티션이 설정된 토픽으로 메시지를 발행하고 소비하는 테스트이다.

테스트 설명

• 주석 1
  • 메시지를 발행한다.
  • 순서대로 알파벳과 이모지를 발행한다.
• 주석 2.
  • consumer 에 특정 토픽에 대해 subscribe 한다.
• 주석 3 & 4
  • consumer 의 poll() 연산을 통해서 메시지를 소비하고 해당 메시지 스트림을 String 리스트로 변환한다
• 주석 5
  • 테스트 단언문을 통해 List 의 내용물과 동일한 순서인지 검증한다
  • 순서대로 소비되지 않는다.

발행 순서대로 소비하지 않는것을 확인하는 위의 테스트 역시 통과한다.

파티션 수는 얼마가 적당할까?

 

앞선 내용들을 종합적으로 생각해봤을 때, 파티션 수를 결정하는 일은 매우 중요하다.

 

우리는 메시지의 처리량을 높이기 위해서 파티셔닝을 한다.

 

그럼 처리량을 매우 높이기 위해서 파티션을 100개, 1000개 늘려도 될까? 당연히 안된다.

 

파티션은 카프카 브로커 내부의 토픽 디렉토리랑 매핑되고 파티션에 저장되는 메시지마다 2개의 파일(인덱스, 데이터)가 저장된다.

 

결국 파티션이 많을수록 파일 핸들러 수가 많아져 파일 핸들러가 낭비가 될 수 있다.

 

하지만 파티션 수가 적다면 메시지 처리량이 줄어들어 성능이 전반적으로 저하될 수 있다.

 

물론 상황과 조건에 따라서 결정 사항이 계속 바뀌게 될 것인데, 이러한 사항들을 인지하고 있으면 선택에 도움이 될 것이다

 

학습 테스트 정리

• ✅ 파티션 키를 명시하면 해당 키에 해당하는 파티션에 메시지(이벤트 로그)가 발행된다
• ✅ 파티션 키를 명시하지 않으면 partitioner 에 의해 적절히 파티션에 고르게 분배된다
• ✅ 파티션 키를 명시하더라도 파티션 할당 충돌이 발생할 수 있으므로 그 점을 고려해야한다
• ✅ 파티션 내에서는 순서를 보장한다
• ✅ 토픽 내의 여러 파티션간의 순서는 보장하지 않는다