Application Development

이 도메인이 묻는 것

Application Development는 4장 Producer 심화, 5장 Consumer 심화, 6장 전달 보장과 트랜잭션의 범위와 거의 겹칩니다. 출제 형태는 크게 세 가지입니다.

1. 설정값과 소속 — 어떤 설정의 기본값은 무엇이고, 그 설정은 프로듀서·컨슈머·브로커·토픽 중 어디에 두는가. matching 유형에서 특히 자주 나옵니다.
2. 시나리오 판단 — "컨슈머가 계속 리밸런스한다", "중복이 생겼다", "순서가 뒤바뀌었다"에서 원인 설정과 1차 처방을 고르는 문제.
3. 코드 판독 — 10~20줄의 Java 코드나 properties를 보여 주고 동작 결과·문제점·개선점을 고르는 문제. 아래 코드 읽기 대비 절에서 훈련합니다.

핵심 개념 (1) 프로듀서

send()는 비동기, 콜백은 Sender 스레드에서

producer.send()는 레코드를 직렬화하고 파티션을 결정해 RecordAccumulator라는 메모리 버퍼에 넣고 즉시 반환합니다. 실제 네트워크 전송은 별도의 Sender(I/O) 스레드가 배치 단위로 수행합니다. 따라서 콜백 onCompletion(metadata, exception)은 애플리케이션 스레드가 아니라 Sender 스레드에서, 브로커 응답을 받은 시점(또는 최종 실패가 확정된 시점)에 호출됩니다.

• metadata와 exception 중 하나는 반드시 null입니다. 성공이면 exception이 null입니다.
• 같은 파티션으로 보낸 레코드의 콜백은 전송 순서대로 실행됩니다. 파티션이 다르면 순서 보장이 없습니다.
• 콜백 안에서 블로킹 작업(DB 호출, get(), 긴 락)을 하면 Sender 스레드가 멈춰 전체 전송이 느려집니다.
• 동기 전송이 필요하면 send(record).get()이지만, 배치 효과가 사라져 처리량이 급락합니다.

멱등성과 순서 보장

Kafka 4.3의 enable.idempotence 기본값은 true입니다(3.0부터). 멱등 프로듀서는 PID(Producer ID) + 파티션별 시퀀스 번호를 붙여 보내고, 브로커가 시퀀스 번호로 중복을 판별해 폐기합니다. 재시도 때문에 같은 배치가 두 번 도착해도 로그에는 한 번만 기록됩니다.

멱등성이 켜져 있으면 max.in.flight.requests.per.connection이 5 이하여야 합니다. 기본값이 정확히 5인 이유가 여기 있습니다. 브로커가 파티션별로 최근 5개 배치의 시퀀스 번호를 기억하므로, 그 범위 안에서는 재시도로 순서가 어긋나도 브로커가 재정렬·중복 제거를 해 줍니다. 6 이상으로 설정하면 프로듀서 생성 시 ConfigException이 발생합니다.

파티셔닝 — 키가 있을 때와 없을 때

키가 있으면 murmur2(key) % numPartitions로 결정됩니다. 결정적이므로 같은 키는 항상 같은 파티션으로 갑니다. 이것이 파티션 단위 순서 보장의 근거입니다.

키가 null이면 기본 파티셔너가 sticky batching으로 분배합니다. 한 파티션에 배치를 채우고, 배치가 마감되면 다음 파티션으로 전환하는 방식입니다. 레코드 하나하나를 돌려 담는 순수 라운드로빈이 아닙니다. Kafka 2.4 이전의 DefaultPartitioner는 레코드 단위 라운드로빈이었습니다.

재시도 가능한 에러와 불가능한 에러

기준은 예외가 RetriableException을 상속하는지입니다. 재시도 가능한 예외는 프로듀서가 스스로 다시 보냅니다. 재시도 불가능한 예외는 즉시 콜백으로 올라옵니다.

핵심 개념 (2) 컨슈머

타임아웃 4종 — 하트비트 축과 poll 축은 별개입니다

이 도메인에서 가장 많이 틀리는 지점입니다. 하트비트는 백그라운드 스레드가, poll은 애플리케이션 스레드가 담당합니다. 두 축은 서로 독립적으로 타임아웃됩니다.

subscribe()와 assign()

리밸런스가 발생하는 조건 (전부)

• 컨슈머가 그룹에 합류하거나 정상 이탈(close())
• 컨슈머 크래시 — session.timeout.ms 초과로 감지
• max.poll.interval.ms 초과 — 처리가 너무 오래 걸림
• 구독 토픽의 파티션 수 증가
• 정규식 구독(subscribe(Pattern))에 매칭되는 새 토픽 생성
• 그룹 코디네이터 장애(코디네이터를 맡던 브로커 이탈)

반대로 assign()을 쓰는 컨슈머에서는 위의 어떤 이유로도 리밸런스가 일어나지 않습니다. group.instance.id를 지정한 static membership은 재시작 시 같은 멤버로 복귀해 재시작 때문에 생기는 리밸런스를 피합니다 (리밸런스 자체를 없애는 것이 아닙니다).

오프셋 커밋과 auto.offset.reset

enable.auto.commit의 기본값은 true이고 auto.commit.interval.ms는 5000입니다. 자동 커밋은 poll()이 호출될 때 "이전에 반환한 레코드들"을 커밋하는 방식이라, 처리 도중 크래시하면 이미 커밋된 레코드가 유실될 수 있습니다. 정확한 제어가 필요하면 enable.auto.commit=false + 수동 커밋입니다.

auto.offset.reset의 기본값은 latest이며, 커밋된 오프셋이 없을 때 또는 커밋된 오프셋이 로그 범위를 벗어났을 때만 적용됩니다. 정상적으로 커밋된 오프셋이 있으면 이 설정은 아무 일도 하지 않습니다.

핵심 개념 (3) 전달 보장과 트랜잭션

트랜잭션 API 호출 순서

// 1. 프로듀서 생성 시 transactional.id 필수. 애플리케이션 시작 시 한 번만.
producer.initTransactions();

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(200));
    if (records.isEmpty()) continue;

    // 2. 트랜잭션 시작
    producer.beginTransaction();
    try {
        for (ConsumerRecord<String, String> r : records) {
            // 3. 결과 레코드 전송
            producer.send(new ProducerRecord<>("out-topic", r.key(), transform(r.value())));
        }
        // 4. 읽은 오프셋을 "같은 트랜잭션 안에서" 커밋한다.
        //    consumer.commitSync() 를 쓰면 원자성이 깨진다.
        producer.sendOffsetsToTransaction(offsetsOf(records), consumer.groupMetadata());

        // 5. 커밋
        producer.commitTransaction();
    } catch (ProducerFencedException | OutOfOrderSequenceException | AuthorizationException e) {
        // 복구 불가 — 프로듀서를 닫고 종료해야 한다
        producer.close();
        throw e;
    } catch (KafkaException e) {
        // 6. 그 밖의 실패는 중단하고 다시 시도한다
        producer.abortTransaction();
    }
}

isolation.level은 컨슈머 설정입니다

기본값은 read_uncommitted입니다. 즉 프로듀서가 트랜잭션을 써도, 컨슈머가 아무 설정을 하지 않으면 중단(abort)된 트랜잭션의 메시지까지 읽습니다. EOS는 양쪽을 다 설정해야 성립합니다.

read_committed로 바꾸면 컨슈머는 LSO(Last Stable Offset)까지만 읽습니다. LSO는 "아직 끝나지 않은 트랜잭션의 시작 지점"이므로, 진행 중인 트랜잭션이 하나 있으면 그 뒤에 커밋 완료된 메시지도 보이지 않습니다. 길게 열린 트랜잭션은 컨슈머 지연으로 직결됩니다. 트랜잭션 커밋/중단을 표시하는 컨트롤 레코드는 애플리케이션에 노출되지 않지만 오프셋 번호는 소비하므로, 오프셋에 빈 칸이 생길 수 있습니다.

반드시 외워야 할 설정값

Apache Kafka 4.3 기준입니다. 굵게 표시한 값은 3.x 자료와 다르므로 예전 자료로 공부했다면 여기서 반드시 갱신하세요.

자주 나오는 함정

이 도메인에서 특히 자주 뒤바뀌어 출제되는 쌍입니다. 40쌍 전체는 함정 사전에 있습니다.

함정 1 — session.timeout.ms vs max.poll.interval.ms

함정 2 — acks vs min.insync.replicas

함정 3 — 멱등 프로듀서 vs 트랜잭션

함정 4 — request.timeout.ms vs delivery.timeout.ms

함정 5 — read_uncommitted vs read_committed

함정 6 — 할당 전략 4종

eager는 리밸런스 시작 시 모든 컨슈머가 파티션 전체를 반납합니다(stop-the-world). cooperative는 옮겨야 할 파티션만 두 라운드에 걸쳐 회수·재할당하므로 나머지 파티션은 계속 소비됩니다. 기본값 목록에 RangeAssignor가 먼저 오므로, cooperative를 쓰려면 명시적으로 CooperativeStickyAssignor만 지정해야 합니다. eager에서 cooperative로 옮길 때는 두 단계 롤링 배포가 필요합니다 (먼저 두 전략을 함께 나열해 배포하고, 다음 배포에서 eager를 제거).

코드 읽기 문제 대비

시험에 나오는 형태의 스니펫과 판독 포인트입니다. 정답을 보기 전에 스스로 문제점을 찾아보세요.

스니펫 1 — 무엇이 잘못되었는가

acks=all
enable.idempotence=true
max.in.flight.requests.per.connection=10
compression.type=snappy
linger.ms=20

스니펫 2 — 이 컨슈머의 문제는

Properties p = new Properties();
p.put("bootstrap.servers", "kafka-1:9092,kafka-2:9092");
p.put("group.id", "billing-worker");
p.put("key.deserializer", StringDeserializer.class.getName());
p.put("value.deserializer", StringDeserializer.class.getName());
// max.poll.records 와 max.poll.interval.ms 는 기본값을 사용

KafkaConsumer<String, String> consumer = new KafkaConsumer<>(p);
consumer.subscribe(List.of("invoices"));

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(500));
    for (ConsumerRecord<String, String> r : records) {
        callExternalPaymentApi(r.value());   // 레코드당 평균 1.2초
    }
}

스니펫 3 — 이 커밋 코드의 결과

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(200));
    consumer.commitSync();          // (A) 처리 전에 커밋
    for (ConsumerRecord<String, String> r : records) {
        process(r);                  // (B) 여기서 예외가 나면?
    }
}

스니펫 4 — 순서가 보장되는가

// orders 토픽은 파티션 6개
producer.send(new ProducerRecord<>("orders", null, "order-42 CREATED"));
producer.send(new ProducerRecord<>("orders", null, "order-42 PAID"));
producer.send(new ProducerRecord<>("orders", null, "order-42 SHIPPED"));

이어서 볼 곳

• 4장 · Producer 심화 전송 파이프라인, 배치, 압축, 에러 처리의 전체 설명. 기본개념
• 5장 · Consumer 심화 poll 루프, 리밸런스, KIP-848, 할당 전략. 기본개념
• 6장 · 전달 보장과 트랜잭션 EOS의 경계, 트랜잭션 코디네이터, LSO. 기본개념
• 케이스 2 · 무한 리밸런스 루프 max.poll.interval.ms 초과가 만드는 장애의 전 과정. 실수 케이스
• 케이스 7 · 재처리로 이중 결제 EOS를 켰는데도 외부 결제가 두 번 된 이유. 실수 케이스
• 함정 사전 40쌍 이 도메인의 함정을 포함한 전체 비교표. CCDAK 도구

도메인 미니 퀴즈

단일 선택 · 복수 선택 · 연결형 · 순서 배열형이 섞여 있습니다. 실제 시험에도 matching과 list order가 출제되므로 함께 연습하세요.

공식 문서 출처

• Producer Configs — acks, linger.ms, enable.idempotence, max.in.flight.requests.per.connection, delivery.timeout.ms, max.request.size
• Consumer Configs — session.timeout.ms, heartbeat.interval.ms, max.poll.interval.ms, max.poll.records, auto.offset.reset, isolation.level, group.protocol, partition.assignment.strategy
• Broker Configs — message.max.bytes, min.insync.replicas, offsets.retention.minutes
• Message Delivery Semantics — at-most-once / at-least-once / exactly-once 정의
• Consumer Rebalance Protocol — KIP-848, group.protocol=consumer에서 무시되는 설정
• Transactions — 트랜잭션 API와 LSO