Kafka圧縮タイプ比較: gzip / snappy / lz4 / zstdの選定

Kafkaの圧縮は、基本的にProducerのレコードバッチ単位で適用され、Brokerはそのまま保存・複製します。例外として、トピック側でcompression.typeを明示するとBrokerが再圧縮する場合があります。

本記事では、アルゴリズムごとの特性、設定パターン、監視・検証方法をまとめ、最後にCCDAK/CCAAKで頻出の論点を整理します。

Kafkaの圧縮の基本とデータフロー

Kafkaでは、Producerがレコードをバッチ化し、compression.typeに基づいてバッチごとに圧縮します。Brokerは圧縮済みバッチをほぼそのままログに書き、レプリケーションも圧縮済みのバイト列で行われます。Consumerは取得時にクライアントライブラリが展開します。

トピック設定のcompression.typeがproducerの場合、Producerが選んだ圧縮方式のまま保存されます。gzip/snappy/lz4/zstdなど具体的な値を設定した場合、Brokerは受信時に再圧縮するためCPU負荷とレイテンシが増えます。圧縮対象はレコードバッチであり、バッチが大きいほど一般に圧縮効率は向上します。

サイズ制限は圧縮後サイズに適用されます。具体的には、Producerのmax.request.size、Broker/トピックのmessage.max.bytes(またはmax.message.bytes)は圧縮後のレコードバッチサイズで評価されます。

• Producer設定: compression.type=none|gzip|snappy|lz4|zstd (デフォルトは非圧縮のことが多い)
• Topic設定: compression.type=producer|uncompressed|gzip|snappy|lz4|zstd
• 再圧縮が発生するのは、トピック側が具体的な圧縮方式を指定した場合
• バッチ化に影響: batch.size と linger.ms を大きくすると圧縮率は上がりやすいが遅延は増える
• レプリケーションは圧縮済みデータで行われる(帯域節約に寄与)

Producer圧縮とBroker保存の流れ(トピック設定による分岐)

Producer
   |
   | 1) バッチ化 + 圧縮(compression.type)
   v
[圧縮済みレコードバッチ]
   |
   |--> トピック compression.type = producer の場合 ---------
   |                                                |
   v                                                v
Broker へ送信  ------------------------------>  ログにそのまま保存
   |
   |--> トピック compression.type = gzip/lz4/... の場合 ----
                                                    |
                                                    v
                                              Brokerで再圧縮
                                                    |
                                                    v
                                              ログに保存
                                                    |
                                                    v
                                          レプリケーション(圧縮済みのまま)
                                                    |
                                                    v
                                                Consumer が展開

主要な圧縮タイプ(Producerのcompression.type)

none
gzip
snappy
lz4
zstd

アルゴリズム別の特性とデータ適合性

テキストや繰り返しの多いJSON/Avroは圧縮効果が高く、バイナリや既に圧縮済みのデータ(画像/動画/ZIP)は効果が薄いか悪化します。バッチが小さい場合、どの方式でも効果は限定的です。

低遅延・高スループット重視ならlz4かsnappyが無難です。ネットワーク帯域がボトルネックでCPUに余裕があるならzstdが有利です。gzipは高圧縮ですが遅いので、遅延許容か夜間バッチ等に向きます。

混在環境では、トピックcompression.type=producerとしてProducerごとに最適化するか、全体で統一したい場合は各Producer側を同一に合わせるのがベストです(トピック側で固定するとBroker再圧縮が発生します)。

• メッセージが小さい/疎な場合: snappy/lz4でオーバーヘッド最小化
• メッセージが大きい/可逆テキスト中心: zstd/gzipで帯域重視
• 突発負荷がある場合: snappy/lz4でCPUヘッドルーム確保
• 全Producerで方式を統一できるなら、トピック側はproducerのままが安全

Java Producerでの基本設定例

Properties p = new Properties();
p.put("bootstrap.servers", "broker1:9092,broker2:9092");
p.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
p.put("value.serializer", "org.apache.kafka.common.serialization.ByteArraySerializer");
// 圧縮方式を選択
p.put("compression.type", "lz4");
// バッチとレイテンシのトレードオフ
p.put("batch.size", "131072");      // 128KB 目安
p.put("linger.ms", "10");            // 10ms 待ってバッチ化
KafkaProducer<String, byte[]> producer = new KafkaProducer<>(p);

設定パターン: Producer優先か、トピック固定か

原則として、圧縮方式はProducerで決め、トピックのcompression.typeはproducerのままにします。これによりBrokerの再圧縮を避け、CPUと待ち時間を節約できます。

全Producerで統一が難しく、監査や帯域制限の理由で統一したい場合のみ、トピック側に具体的な方式(gzip/snappy/lz4/zstd)を設定します。その場合はBrokerのCPUと遅延上昇を見込み、リソース計画とスロークライアントの影響評価を行います。

TLSやSASLを使う場合でも、圧縮は暗号化の前に適用されます。したがってネットワーク帯域の節約効果は残ります。

• 推奨既定: トピック compression.type=producer、各Producerでsnappyまたはlz4
• 帯域が厳しい: Producerでzstdを試験導入(互換性とCPUを確認)
• 運用都合で統一必須: トピック固定。ただしBroker再圧縮のコストに注意
• バッチ化で圧縮率向上: batch.sizeとlinger.msの調整が有効

トピック設定の具体例(Broker側CLI)

# 既存トピックをProducer優先に(再圧縮を避ける)
kafka-configs --bootstrap-server localhost:9092 \
  --entity-type topics --entity-name orders \
  --alter --add-config compression.type=producer

# 統一したい場合にlz4で固定(再圧縮が発生)
kafka-configs --bootstrap-server localhost:9092 \
  --entity-type topics --entity-name orders \
  --alter --add-config compression.type=lz4

# 新規作成時にproducerのままで作成
kafka-topics --bootstrap-server localhost:9092 \
  --create --topic events --partitions 12 --replication-factor 3 \
  --config compression.type=producer

運用・監視・検証: スループットとレイテンシの見極め

圧縮はCPUとレイテンシのコストを伴います。導入時は、性能試験ツールとメトリクスで、CPU使用率、BytesIn/Out、リクエストレイテンシ(RequestQueueTime/LocalTime/RemoteTime)を確認します。再圧縮がある場合はBroker CPUの跳ね上がりに注意します。

テナント混在のクラスタでは、重い圧縮(gzip/zstd)を使うProducerのピークが他ワークロードに影響しないよう、スループット制御やクォータ、送信バッチ調整を併用します。

Consumer側の展開もCPUを使うため、消費側の遅延やGC、スループット低下がないかを併せて監視します。

• Brokerメトリクス例: kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec/BytesOutPerSec
• Producerメトリクス例: record-send-rate, request-latency-avg, compression-rate-avg
• Consumerメトリクス例: records-consumed-rate, fetch-latency-avg, lag
• 負荷試験は平常時とピーク時の両方で実施(遅延SLAを確認)

性能検証例(kafka-producer-perf-test)

# lz4で送信(1KBメッセージ、100万件)
kafka-producer-perf-test --topic perf --num-records 1000000 \
  --record-size 1024 --throughput -1 --producer-props \
  bootstrap.servers=localhost:9092 compression.type=lz4 batch.size=131072 linger.ms=10

# zstdで送信(帯域重視)
kafka-producer-perf-test --topic perf --num-records 1000000 \
  --record-size 1024 --throughput -1 --producer-props \
  bootstrap.servers=localhost:9092 compression.type=zstd batch.size=131072 linger.ms=20

選定ガイドと試験対策ポイント(CCDAK/CCAAK)

実務選定のコアは、遅延SLA・CPU・帯域のどれがボトルネックかを明確にすることです。次の簡易ガイドを基に社内の代表ワークロードで検証してください。

試験では、圧縮の適用箇所(Producer中心)、トピック側のproducer指定で再圧縮を回避、レプリケーションが圧縮済みで行われる点、バッチ設定と圧縮効率の関係が頻出です。zstd/lz4の使い分けも問われます。

• 低遅延/高TPS: lz4 または snappy
• 帯域最重視: zstd (環境サポートとCPUに余裕があること)
• レガシー/広い互換: gzip
• Broker再圧縮は原則避ける: トピックはcompression.type=producer
• 圧縮効果を最大化: 適切なbatch.size + linger.ms(遅延SLAと両立)
• サイズ制限は圧縮後サイズで評価される点に注意

圧縮方式チートシート

snappy: 速い/圧縮率中/CPU低 → 低遅延
lz4: さらに速い/圧縮率中-高/CPU低-中 → デフォルト候補
zstd: 圧縮率高/CPU中-高 → 帯域重視
gzip: 圧縮率高/CPU高/遅い → バッチ系・遅延許容

Topic: compression.type=producer(再圧縮回避)
Producer: compression.type=<上記いずれか>
Batching: batch.size↑ + linger.ms↑ → 圧縮率↑(遅延↑)

問題で確認

よくある質問