파티션을 1000개로 늘렸더니 더 느려졌다

# 컨슈머 파드를 최대 200개까지 늘릴 수 있게, 여유를 5배로 잡아 1000개로
kafka-topics.sh --bootstrap-server kafka-1:9092 \
  --alter --topic page-view --partitions 1000

ERROR Error while accepting connection (kafka.network.Acceptor)
java.io.IOException: Too many open files
	at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
	...

ERROR Failed to clean up log for __consumer_offsets-17 in dir /var/lib/kafka/data due to IOException
java.io.FileNotFoundException: /var/lib/kafka/data/page-view-843/00000000000000000000.index (Too many open files)

java.lang.OutOfMemoryError: Map failed
	at sun.nio.ch.FileChannelImpl.map0(Native Method)
	at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:...)

필요 FD 최소치 = (파티션 수) × (파티션 크기 / 세그먼트 크기) + 연결 수

권고: 브로커 프로세스에 최소 100,000개의 파일 디스크립터를 허용할 것 (출발점)

services:
  broker:
    image: apache/kafka:4.3.1
    hostname: broker
    container_name: broker
    ports:
      - '9092:9092'
    # 재현 포인트 — FD 한계를 일부러 낮춥니다. 운영에서는 100000 이상을 권장합니다.
    ulimits:
      nofile:
        soft: 4096
        hard: 4096
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: 'broker,controller'
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: 'CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT'
      KAFKA_LISTENERS: 'CONTROLLER://:29093,PLAINTEXT://:19092,PLAINTEXT_HOST://:9092'
      KAFKA_ADVERTISED_LISTENERS: 'PLAINTEXT://broker:19092,PLAINTEXT_HOST://localhost:9092'
      KAFKA_CONTROLLER_QUORUM_VOTERS: '1@broker:29093'
      KAFKA_CONTROLLER_LISTENER_NAMES: 'CONTROLLER'
      KAFKA_INTER_BROKER_LISTENER_NAME: 'PLAINTEXT'
      CLUSTER_ID: '4L6g3nShT-eMCtK--X86sw'
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS: 0
      KAFKA_LOG_DIRS: '/tmp/kraft-combined-logs'
      # 세그먼트를 작게 만들어 파일 수를 늘립니다 (재현 전용)
      KAFKA_LOG_SEGMENT_BYTES: 1048576

docker compose up -d
K=/opt/kafka/bin

# 1. 파티션 4개 토픽과 400개 토픽을 나란히 만든다
docker exec -it broker $K/kafka-topics.sh --create --topic few-parts \
  --partitions 4 --replication-factor 1 --bootstrap-server localhost:9092
docker exec -it broker $K/kafka-topics.sh --create --topic many-parts \
  --partitions 400 --replication-factor 1 --bootstrap-server localhost:9092

# 2. 같은 조건으로 부하를 준다. 처리량을 제한해 "파티션당 유입 감소"를 만듭니다.
#    --print-metrics 로 batch-size-avg / request-rate 를 함께 봅니다.
docker exec -it broker $K/kafka-producer-perf-test.sh \
  --topic few-parts --num-records 200000 --record-size 900 --throughput 2000 \
  --producer-props bootstrap.servers=localhost:9092 linger.ms=5 batch.size=16384 \
  --print-metrics 2>&1 | grep -E 'batch-size-avg|request-rate|records/sec'

docker exec -it broker $K/kafka-producer-perf-test.sh \
  --topic many-parts --num-records 200000 --record-size 900 --throughput 2000 \
  --producer-props bootstrap.servers=localhost:9092 linger.ms=5 batch.size=16384 \
  --print-metrics 2>&1 | grep -E 'batch-size-avg|request-rate|records/sec'

# → many-parts 쪽에서 batch-size-avg 가 크게 줄고 request-rate 가 크게 늡니다.
#   이것이 지연 증가의 직접 원인입니다.

# 브로커 프로세스가 연 파일 수
docker exec broker sh -c 'ls /proc/1/fd | wc -l'

# 메모리 맵 영역 수 (세그먼트당 2개씩 늘어납니다)
docker exec broker sh -c 'wc -l < /proc/1/maps'

# 파티션 400개 × 세그먼트 파일들 — 디렉터리 수를 확인
docker exec broker sh -c 'ls -d /tmp/kraft-combined-logs/many-parts-* | wc -l'
docker exec broker sh -c 'ls /tmp/kraft-combined-logs/many-parts-0/'
#   → 00000000000000000000.log / .index / .timeindex / leader-epoch-checkpoint ...

# 호스트의 현재 vm.max_map_count 확인 (공식 문서가 주의하라고 한 값)
sysctl vm.max_map_count

# 컨슈머 2개를 붙였다 떼면서 상태 전이를 관찰합니다
docker exec -it broker $K/kafka-console-consumer.sh --topic many-parts \
  --group rb-test --from-beginning --bootstrap-server localhost:9092 &
sleep 5
docker exec -it broker $K/kafka-console-consumer.sh --topic many-parts \
  --group rb-test --from-beginning --bootstrap-server localhost:9092 &

watch -n 1 'docker exec -it broker /opt/kafka/bin/kafka-consumer-groups.sh \
  --describe --group rb-test --state --bootstrap-server localhost:9092'
#   → PreparingRebalance / CompletingRebalance 에 머무는 시간을
#     few-parts 로 같은 실험을 했을 때와 비교합니다.

# 파티션당 유입이 적으므로 더 기다려야 배치가 찹니다.
# 지연 예산이 허용하는 한도까지 올립니다.
linger.ms=50
batch.size=32768
compression.type=lz4          # 배치가 커지면 압축 효과가 돌아옵니다
buffer.memory=134217728       # 파티션이 많으면 버퍼도 늘려야 합니다 (기본 33554432)

# 파일 디스크립터 — 공식 문서 권고: 브로커 프로세스에 최소 100000
ulimit -n            # 현재 값 확인
# /etc/security/limits.d/kafka.conf
#   kafka soft nofile 200000
#   kafka hard nofile 200000

# systemd 유닛이라면
#   [Service]
#   LimitNOFILE=200000

# 메모리 맵 영역 — 세그먼트당 2개씩 필요합니다
sysctl -w vm.max_map_count=262144
echo 'vm.max_map_count=262144' >> /etc/sysctl.d/99-kafka.conf

# segment.bytes 를 작게 설정한 토픽이 있으면 파일 수가 급증합니다.
# 기본값은 1073741824(1GiB)입니다. 작게 바꾼 토픽을 찾아 되돌립니다.
for t in $(kafka-topics.sh --bootstrap-server kafka-1:9092 --list); do
  kafka-configs.sh --bootstrap-server kafka-1:9092 \
    --entity-type topics --entity-name "$t" --describe | grep -q segment.bytes \
    && echo "== $t" \
    && kafka-configs.sh --bootstrap-server kafka-1:9092 \
         --entity-type topics --entity-name "$t" --describe
done

# 1. 계산으로 정한 파티션 수로 새 토픽을 만든다
kafka-topics.sh --bootstrap-server kafka-1:9092 --create \
  --topic page-view-v2 --partitions 24 --replication-factor 3 \
  --config min.insync.replicas=2

# 2. 프로듀서를 새 토픽으로 전환한다 (양쪽에 쓰는 기간을 두면 무중단 전환 가능)
# 3. 컨슈머가 두 토픽을 함께 구독하게 하고, 기존 토픽 lag 이 0이 되면 구독 해제
# 4. 기존 토픽의 리텐션이 지난 뒤 삭제
kafka-topics.sh --bootstrap-server kafka-1:9092 --delete --topic page-view