Apache Kafka 동시성 문제에 따른 파티셔닝 조절

1. 개요 및 배경 (Background & Problem)

처리량이 부족해 토픽의 파티션 수를 늘리면(예: 12 → 24), 컨슈머 병렬도가 올라가 처리량은 개선됩니다. 그러나 다음과 같은 부작용이 동시에 나타납니다.

2. 원인 분석

2.1 파티션 = 순서 보장의 단위

• Kafka는 파티션 내부에서만 순서를 보장합니다. 토픽 전체 순서는 보장하지 않습니다.
• 기본 파티셔너는 partition = hash(key) % numPartitions. numPartitions가 바뀌면 대부분의 키가 다른 파티션으로 재매핑됩니다.

2.2 리밸런싱 비용

• 파티션 수 변경, 컨슈머 추가/이탈 시 그룹 코디네이터가 파티션을 재할당합니다.
• 기본 RangeAssignor/RoundRobin은 Eager(전체 취소 후 재할당) → 재할당 동안 전 컨슈머가 소비 중단.
• 커밋되지 않은 오프셋이 있으면 재할당 후 다른 컨슈머가 같은 메시지를 다시 소비(at-least-once).

2.3 동시성은 늘었지만 병목은 뒤로 이동

파티션 24개 = 최대 24개 컨슈머 동시 소비. 그러나 이들이 같은 DB/외부 API를 때리면 커넥션 풀·락 경합·rate limit이 새 병목이 됩니다. (스레드 수만 늘린 것과 동일한 함정)

3. 해결 전략

3.1 파티션 수는 처음부터 넉넉히, 이후엔 바꾸지 않는다

• 순서가 중요한 토픽은 증설 대신 초기 오버프로비저닝. (파티션은 늘릴 수만 있고 줄일 수 없음)
• 꼭 늘려야 하면, 새 토픽을 만들고 컨슈머를 전환(dual-write / replay) 하여 키 매핑 불연속을 통제된 시점에 처리.

3.2 연속성이 필요한 메시징: 파티션 고정 + 발행 전 순차성 확인

연속성이 연계되는 작업(같은 그룹의 메시지가 반드시 순서대로 처리되어야 하는 발송 시나리오)에서는, 리밸런싱 튜닝에 기대기보다 "애초에 흐트러지지 않게" 강제하는 편이 안전합니다.

// groupId를 파티션에 직접 매핑 (파티션 수가 바뀌어도 매핑이 흔들리지 않도록 명시적 고정)
int partition = partitionRegistry.resolve(msg.getGroupId()); // 그룹→파티션 고정 테이블
kafkaTemplate.send(new ProducerRecord<>("mail-send", partition, msg.getGroupId(), payload));

• 기본 파티셔너의 hash(key) % N에 맡기지 않고, 그룹 → 파티션 매핑을 레지스트리로 고정합니다. 파티션 증설이 있어도 기존 그룹의 순서 경로는 유지됩니다.
• 같은 파티션에 순서대로 넣으면 컨슈머는 그 파티션을 단일 스레드로 소비하므로 순서가 자연히 보장됩니다. (그룹당 in-flight 1건 유지) ② 발행 전(Publish 전) 그룹 순차성 선확인

MQ로 publish 하기 전에, 해당 groupId의 직전 메시지가 순차적으로 처리 완료되었는지 먼저 확인하고 다음 메시지를 보냅니다.

public void publishNext(GroupMessage msg) {
    GroupProgress p = progressRepo.get(msg.getGroupId());
    // 직전 시퀀스가 '처리 완료' 상태일 때만 다음 메시지 발행 (아니면 대기/재시도 큐)
    if (p.getLastAckedSeq() + 1 != msg.getSeq()) {
        pendingRepo.hold(msg);        // 아직 차례 아님 → 보류
        return;
    }
    kafkaTemplate.send(record(msg));
    progressRepo.markInFlight(msg.getGroupId(), msg.getSeq());
}
// 컨슈머가 처리 완료 후 ack → progressRepo.markAcked(groupId, seq) → 보류분 재평가

• 브로커에 한 그룹의 메시지가 여러 건 동시에 떠 있는 상황 자체를 만들지 않습니다. (생산 측 흐름 제어)
• 처리 완료 신호(ack)를 받아야 다음 건을 흘리므로, 파티션 이동·리밸런스·컨슈머 장애가 있어도 순서·원자성이 생산 측 상태 기계로 보장됩니다.
• 트레이드오프: 그룹 단위 처리량이 "직렬"로 제한됨 → 그룹 수가 많아야 전체 병렬도가 나옴. 그룹 간에는 완전 병렬. ③ 더 나은 방식에 대한 고민

실무 선택: ①+②를 함께 적용하는 경우가 많습니다. 파티션 고정으로 "경로"를 고정하고, 발행 전 확인으로 "그룹당 동시 in-flight 1건"을 강제하면, 리밸런싱 세부 튜닝은 부차적 문제가 됩니다.

3.3 순서가 필요하면 "키 단위 처리 멱등성 + 버전 가드"

파티션 이동으로 순서가 깨질 수 있음을 전제로, 소비 측에서 순서 역전을 흡수합니다.

// 이벤트에 단조 증가 버전(또는 발생 시각) 포함 → 과거 이벤트는 무시
@KafkaListener(topics = "user-events", concurrency = "6")
public void onEvent(UserEvent e) {
    int applied = stateRepo.getVersion(e.getUserId());   // 현재 반영된 버전
    if (e.getVersion() <= applied) return;               // stale → 스킵 (멱등)
    stateRepo.applyIfVersionMatches(e.getUserId(), e.getVersion(), applied); // CAS 업데이트
}

• 멱등 키(businessKey + version)로 중복·재처리를 무해화.
• DB는 WHERE version = :expected 조건부 업데이트(CAS)로 동시 처리 시 한쪽만 성공하게 함.

3.4 리밸런스 영향 최소화 (부차적 안전장치)

3.2에서 그룹당 in-flight를 1건으로 강제하면 리밸런스로 인한 순서 붕괴 위험은 크게 줄어듭니다. 아래는 처리량·중복을 줄이기 위한 보조 튜닝입니다.

3.5 다운스트림 동시성 상한

• 컨슈머 concurrency(파티션 병렬도)와 별개로, DB/외부 호출부를 Semaphore·bounded pool로 감싸 동시 요청 수를 제한.
• 대용량 payload는 Kafka에 직접 싣지 않고 Claim Check(본문은 오브젝트 스토리지, 메시지에는 참조만).

4. 결론

• 파티션 증설은 "처리량 스위치"가 아니라 "키 재분배 이벤트" 입니다. hash(key) % N의 N을 바꾸는 순간 대부분의 키가 이동하고, 그 경계에서 순서·원자성 가정이 깨집니다.
• 연속성이 중요한 메시징은 리밸런싱 튜닝보다 앞단에서 강제합니다: ① 그룹→파티션 고정 매핑으로 순차 인입 경로를 못 박고, ② 발행 전에 해당 그룹의 직전 시퀀스가 처리 완료됐는지 확인하여 그룹당 in-flight를 1건으로 유지합니다.
• 이렇게 하면 리밸런스·컨슈머 장애가 있어도 순서·완결성이 생산 측 상태 기계로 보장되며, CooperativeStickyAssignor·수동 커밋·static membership은 부차적 안전장치가 됩니다.
• 순서 역전을 사후 흡수해도 되는 경우에만 소비 측 멱등성 + 버전 가드를 씁니다.
• 파티션을 늘려도 다운스트림 공유 자원의 동시성 상한은 여전히 별도로 관리해야 합니다.