Kafka圧縮コーデックの比較：Zstd vs. Snappy vs. Gzip

Apache Kafkaは、高スループットで耐障害性の高いメッセージ配信のために設計された強力な分散イベントストリーミングプラットフォームです。Kafkaは大量のデータを扱うのに優れていますが、パフォーマンスを最適化するには、いくつかの重要なパラメーターを調整する必要があります。特に高負荷時やネットワーク環境が制約される環境において、調整すべき最も重要な領域の1つがメッセージ圧縮です。

圧縮は、ネットワーク経由で送信されディスクに保存されるデータの物理サイズを削減し、ネットワーク帯域幅の使用量とストレージコストに直接影響を与えます。しかし、圧縮は諸刃の剣です。一般的に、より強力な圧縮アルゴリズムは、プロデューサー（圧縮時）とコンシューマー（展開時）の両方でより多くのCPUサイクルを必要とします。この記事では、Kafkaで利用可能な主要な圧縮コーデック—Zstandard (Zstd)、Snappy、およびGzip—を詳細に比較し、CPUオーバーヘッド、レイテンシ、ストレージ削減の観点からトレードオフを評価し、特定のワークロードに最適なコーデックを選択できるようにします。

Kafkaにおける圧縮の理解

Kafkaでは、プロデューサーがメッセージを送信する前に圧縮することができます。ブローカーは圧縮されたバッチを保存し、コンシューマーはデータを取得して展開します。このプロセスにより、計算負荷がネットワーク/ディスク層からCPU層にシフトします。コーデックの選択は、これらのリソース間のバランスを決定するため重要です。

Kafkaは4つの主要な圧縮タイプをサポートしています（ただし、すべてのバージョンやクライアントですべてが利用できるわけではありません）：none、gzip、snappy、およびzstd。

圧縮の設定

圧縮は通常、プロデューサー側でcompression.typeプロパティを使用して設定されます。ブローカーは、プロデューサーが使用するコーデックを読み取れる必要があります。

# プロデューサー設定の例
compression.type=zstd

Kafka圧縮コーデックの詳細分析

一般的なパフォーマンス特性に基づいて、主要な3つのコーデック、Gzip、Snappy、Zstdを比較します。

1. Gzip (GNU Zip)

Gzipは、DEFLATEアルゴリズムに基づいた実績のある汎用圧縮アルゴリズムです。選択肢の中で最も高い圧縮率を提供することが多く、最大のストレージ削減につながります。

圧縮率: 高い（最高のストレージ削減）。
CPU使用率: 高い（圧縮と展開の両方にかなりのCPU時間を必要とする）。
レイテンシへの影響: 特に大きなバッチを圧縮する場合、集中的なCPU使用により目に見えるレイテンシを引き起こす可能性があります。

最適な使用例: ストレージ削減とネットワーク帯域幅の節約が最も重要であり、CPUリソースが豊富にある場合、またはメッセージスループット要件が比較的低いシナリオ。

2. Snappy

Googleによって開発されたSnappyは、最大限の圧縮よりも速度を重視して設計されています。たとえ結果のファイルサイズがGzipやZstdよりも大きくなったとしても、非常に高速な圧縮および展開速度を優先します。

圧縮率: 中程度から低い。
CPU使用率: 低い（実行時間が非常に速い）。
レイテンシへの影響: 最小限。Snappyは、エンドツーエンドのレイテンシへの影響がほぼゼロであることで知られています。

最適な使用例: 低レイテンシが絶対的な最優先事項である高スループットシステム。計算上のボトルネックを最小限に抑えつつ、ある程度のネットワーク削減効果も提供するため、多くのKafkaデプロイメントでデフォルトの選択肢となることがよくあります。

3. Zstandard (Zstd)

Facebook (Meta)によって開発されたZstandardは、現代の有力候補です。Zstdは、選択された圧縮レベルに応じて、Gzipに匹敵するかそれを上回る圧縮率を達成しながら、Snappyよりも優れたパフォーマンスを提供することを目指しています。

Zstdの主な特徴は、調整可能な圧縮レベル（通常1から22の範囲）です。

レベル1（高速）: 速度の面でSnappyを上回り、Snappyよりも優れた圧縮を提供することがよくあります。
レベル3～5（バランス）: 一般的なスイートスポットであり、低いCPUオーバーヘッドで良好な圧縮率を提供します。
レベル10以上（高レベル）: Gzipの圧縮率に近づきますが、一般的に展開速度は速いままであることが多いです。
圧縮率: 可変（中程度から非常に高いまで）。
CPU使用率: 選択されたレベルに基づいて高度に可変（低い場合も高い場合もある）。
レイテンシへの影響: 低レベルでは一般的に非常に低い。Snappyと同等。

最適な使用例: ほぼすべて$の最新のKafkaデプロイメント。Zstdは、バランスを正確に調整するための柔軟性を提供します。低レイテンシが必要な場合はレベル1または3を使用します。ストレージ削減が必要な場合は、より高いレベル（例：9または11）を使用します。

比較分析：コーデックの選択

最適なコーデックは、特定のクラスターアーキテクチャにおけるボトルネックに完全に依存します。

コーデック	圧縮率	圧縮速度	展開速度	CPUオーバーヘッド	最適な使用例
Snappy	低い	非常に速い	非常に速い	最低	レイテンシに敏感な高スループット
Zstd (レベル1-3)	中程度	速い	非常に速い	非常に低い	最新のバランスの取れたパフォーマンス
Zstd (レベル5-11)	高い	中程度	速い	中程度	柔軟なストレージ/パフォーマンスのトレードオフ
Gzip	最高	遅い	遅い	最高	ストレージアーカイブ、低スループット

実用的な意思決定ガイド

要件をコーデックにマッピングするには、次のガイドラインを使用してください。

レイテンシが重要（例：リアルタイム金融フィード）な場合: Snappyまたはレベル1のZstdを選択します。これらはCPU抵抗が最も少ないです。
ストレージコストが重要（例：数か月のデータ保持）な場合: Gzipまたは高レベル（15以上）のZstdを選択します。より多くのCPUリソースを割り当てる準備をしてください。
汎用的な高スループットシステムの場合: Zstd（レベル3または5）が圧倒的におすすめです。多くの場合、速度をほとんど犠牲にすることなく、Snappyよりも優れた効率性（圧縮バイトあたりのCPU使用量が少ない）を提供します。

設定例：速度の最適化（Zstd）

Zstdを利用していて、わずかに優れた圧縮率でSnappyに近いパフォーマンスを得たい場合は、プロデューサー設定でレベルを明示的に設定します。

# Zstdを使用した速度優先のプロデューサー設定
compression.type=zstd
producer.compression.level=3

圧縮レベルに関する警告: GzipとSnappyは標準のKafkaプロパティで詳細なレベル設定を公開していませんが、Zstdは公開しています。レベルを上げると圧縮にかかる時間（バッチが送信される前に発生する）が大幅に増加することに注意してください。

プロデューサーとコンシューマーのパフォーマンスに関する考慮事項

圧縮が接続の両側に影響を与えることを覚えておくことが重要です。

プロデューサーへの影響（圧縮時間）

プロデューサーは、レコードのバッチ全体が準備されるのを待ってから、それを圧縮して送信する必要があります。圧縮時間がlinger.msを超えると、プロデューサーはバッチを早すぎたり遅すぎたりして送信する可能性があります。非常に遅い圧縮（高レベルのGzipなど）は、プロデューサーにバッチをより頻繁に、より小さく送信させ、リクエストのオーバーヘッドを増加させる可能性があります。

コンシューマーへの影響（展開時間）

コンシューマーは、データを処理する前にCPUサイクルを費やして展開する必要があります。コンシューマーのCPUが最大負荷になっている場合、ネットワークスループットが十分であっても、展開がボトルネックとなり、コンシューマーラグにつながる可能性があります。展開速度は、コンシューマーのレイテンシに直接影響するため、圧縮速度よりも重要になることがよくあります。

この理由から、SnappyやZstd（展開ルーチンが非常に高速）のようなコーデックは、展開ルーチンが比較的遅いGzipよりも好まれます。

結論

適切なKafka圧縮コーデックの選択は、基本的なパフォーマンスチューニングの演習です。普遍的に「最良」の答えはなく、最適な選択はワークロードに依存します。Gzipは最大の潜在的なストレージ削減を提供しますが、その高いCPUオーバーヘッドにより、高スループットシステムでは実用的でないことがよくあります。Snappyは信頼性の高い低レイテンシのベースラインとして残っています。しかし、Zstandardは、エンジニアがディスク容量、ネットワークI/O、またはCPUサイクルのいずれが主要な制約であるかに基づいてパフォーマンスを微調整できる柔軟なトレードオフのスペクトラムを提供するため、現代の標準として浮上しています。