[Apache Kafka] 실시간 메시지 병렬 처리 실험 - 2 (Partition과 Consumer 인스턴스 수에 따른 성능 변화)

 

실시간 메시지 병렬 처리 실험 - 2 (Partition과 Consumer 인스턴스의 상관 관계)

Partition과 Consumer 인스턴스의 차이를 확인하기 위한 부하 테스트 입니다. 셋팅은 실시간 메시지 병렬 처리 실험 - 1 (셋팅, JMeter, plugins-manager) 을 참고해주세요.

코드는 적절한 파티션 수를 구하는 방법에서 작성한 그대로 사용하며 OrderConsumer만 처리 지연을 발생시키기 위해 아래와 같이 변경합니다.

@Component
public class OrderConsumer {
    @KafkaListener(topics = "order-topic", groupId = "order-group", concurrency="1")
    public void listen(Order order) {
        System.out.println("Consumed Order: " + order);
    }
}

 

부하 테스트를 진행해볼 내용은 다음과 같습니다.

1. Partition 3, Consumer Instance 1
2. Partition 3, Consumer Instance 3

우선 파티션 수 구하기 포스팅에서 작성한 공식을 사용하기 위해 partition1, consumer instance 1로 설정하여 처리 가능한 TPS를 구하도록 하겠습니다. 이전 포스팅에서 작성한 설정과 같습니다.

Thread Group

Constant Throughput Timer

 

위와 같이 설정했을 때 약 2200 TPS가 발생하는데, LAG이 1~300 정도까지 순간적으로 치솟으니 현재 처리 가능한 TPS는 2000으로 가정하겠습니다. (현재 실험을 파티션 1개, 컨슈머 인스턴스 1개라 처리량은 동일하다고 보겠습니다)

 

사용 시 LAG은 Kafka에서 제공하는 CLI를 사용하였습니다. 저는 개발 테스트 서버이므로 정확한 테스트를 위해 토픽 삭제 및 재생성 후 진행하였으나, 운영 환경에서는 절대 따라하지 마세요. 만약 필요하다면 테스트 서버를 이용 또는 충분한 검토 후 진행하시길 바랍니다.

# 토픽 삭제
bin/kafka-topics.sh --delete --topic order-topic --bootstrap-server 192.168.223.128:9092

# 토픽 재생성 (파티션 수 1개)
bin/kafka-topics.sh --create --topic order-topic --partitions 1 --replication-factor 1 --bootstrap-server 192.168.223.128:9092

# Kafka CLI를 통한 모니터링
watch -n 2 "/usr/local/kafka_2.12-3.9.0/bin/kafka-consumer-groups.sh --bootstrap-server 192.168.223.128:9092 --describe --group order-group"

※ 참고
위의 명령어 실행 → 스프링 부트 실행 순서로 한다면 각 파티션별로 확인이 가능합니다.

 

정리 및 상황 시나리오는 다음과 같습니다.

1. 피크 시 5,000 TPS까지 발생
2. 단일 파티션 / 컨슈머 인스턴스에서 처리 가능한 TPS는 2,000으로 가정
3. 필요 파티션 수 = max(t / p, t / c)  = max(5000/2000, 5000/2000) = max(2.5, 2.5) = 올림하여 3개

우선 5,000 TPS 발생할 때 파티션을 1개로 한다면 병목이 발생하는지 확인해보겠습니다. 컨슈머 인스턴스로 3으로 진행합니다.

# 토픽 재생성 (파티션 수 1개)
bin/kafka-topics.sh --create --topic order-topic --partitions 1 --replication-factor 1 --bootstrap-server 192.168.223.128:9092

@Component
public class OrderConsumer {
    // concurrency="1"
    @KafkaListener(topics = "order-topic", groupId = "order-group", concurrency="1")
    public void listen(Order order) {
        System.out.println("Consumed Order: " + order);
    }
}

 

위의 셋팅으로 진행 시 LAG이 수천까지 스파이크 현상이 발생하는 모습을 확인할 수 있으며 이는 Kafka에서 어떠한 병목 현상이 발생하고 있음을 알 수 있습니다.

※ LAG 이란?
브로커에 저장된 메시지 중 아직 컨슈머가 가져가지 못한 메시지의 수를 의미합니다.
즉, 브로커에 메시지는 정상적으로 수신되었으나 컨슈머가 해당 메시지를 소비하지 못한 상황입니다. (대기중인 메시지 수)

위의 이미지에서는 2952개의 메시지가 소비되지 못하고 대기중인 상태이며, 컨슈머의 처리 속도보다 메시지 유입 속도가 빠름을 알 수 있습니다.

 

그렇다면 이번엔 계산식에서 나왓던대로 파티션을 3개로 생성하여 진행해보겠습니다.

# 토픽 재생성 (파티션 수 3개)
bin/kafka-topics.sh --create --topic order-topic --partitions 3 --replication-factor 1 --bootstrap-server 192.168.223.128:9092

@Component
public class OrderConsumer {
    // 컨슈머 인스턴스 5로 지정
    @KafkaListener(topics = "order-topic", groupId = "order-group", concurrency="3")
    public void listen(Order order) {
        System.out.println("Consumed Order: " + order);
    }
}

 

아래는 최대치로 발생했을 때의 이미지 입니다. 1개의 파티션일 때 보다 TPS에 따라 파티션과 컨슈머 인스턴스를 늘렷을 때 훨씬 부하가 줄어든 모습을 확인할 수 있었습니다.

LAG이 수백단위로 쌓이는 것도 개선이 필요한 수치이지만 현재 사양이 그리 좋지 않은 컴퓨터에서 JMeter + Spring Boot + Kafka(VM)까지 사용중이라 부하 발생 시 CPU 100%를 넘긴지 한참 되었기 때문에 더이상 TPS를 올려 테스트 하는 것은 무의미할 것 같습니다.

하지만 위의 실험을 통해 TPS에 따라 적절한 파티션 수를 구하고 컨슈머가 메시지를 병렬 처리 하도록 하여 성능이 개선됨을 확인할 수 있었으나 현재 테스트는 내부 로직이 없는 간단한 코드, 단일 Spring Boot 서버, 단일 Kafka 브로커 환경(VM)에서 진행되었기 때문에 실제 운영 환경에서는 내부 비즈니스 로직 복잡도, 병렬 처리 구조 등에 대한 요소를 추가적으로 고려할 필요가 있어 보입니다.