Kafka 는 초기 버전부터 "broker.rack" 이란 설정을 제공하여,

특정 서버 Rack 전체에 전력이 나가는 장애 상황이 발생하더라도

다른 Rack 에 위치한 Broker Node 에 Replica 를 할당시켜 동작 불능에 빠지지 않게 하는

고가용성의 표본적인 기능을 제공해주고 있습니다.

문제는 이런 기능을 제공하는것까진 좋았는데,

Kafka 는 기본적으로 Leader Replica 에 메세지를 Write 하고 Read 하는 구조이기 때문에

Client 인 Producer 나 Consumer 는 자칫 메세지를 자기와 가깝지 않는 노드와 통신을 하게 되어 성능 이슈를 야기할 수 있습니다.

이를 개선하기 위해 Kafka 버전 2.4 부터 Consumer 설정에 "client.rack" 을 추가하여,

ISR 상태인 Follower Replica 가 있다면 읽을 수 있게 하는 기능이 추가되었지만

이 또한 Consumer 리밸런싱에 관여하는 Partition Assignor 가 Rack 설정을 고려하지 않기 때문에

자신과 Rack 이 동일하지 않는 노드의 파티션 오너쉽을 가져갈 수 있어 완벽한 해결은 아니었습니다.

이와 관련된 내용은 2023년 DEVIEW 때 이동진님께서 발표하신 "네이버 스케일로 카프카 컨슈머 사용하기" 에서도 다뤘었습니다.

📺 네이버 스케일로 카프카 컨슈머 사용하기 : https://tv.naver.com/v/33857687

그러다 드디어 Kafka 3.5 부터 기본적으로 Built-In 되어있는 Partition Assignor 에 해당 기능을 제공하게 되어 Consumer 의 Rack Awareness 가 가능해지게 되었습니다.

이에 대한 내용은 아래 첨부드린 Introducing Apache Kafka 3.5 를 참고해주세요.

📢 Introducing Apache Kafka 3.5: https://www.confluent.io/blog/introducing-apache-kafka-3-5/

다만 지금까지 언급된 내용은 Consumer 에 대한 내용이고

현재까지 Producer 에 대해서는 이렇다할 해법은 존재하지 않습니다.

관련 내용을 검색해보면 Producer 에서 사용하는 Partitioner 를 Customizing 하는 방법(https://levelup.gitconnected.com/rack-aware-partition-assignment-for-kafka-producers-and-consumers-bdf706960491)도 나오지만

여기서 제안한 방법은 동일한 key 값을 가진 message 는 동일한 partition 으로 가야하는 순서보장 법칙을 위배하기 때문에 순서보장이 필요없는 케이스에서만 사용할 수 있습니다.