Kafkaアーキテクチャ解説：主要コンポーネントとその役割

Apache Kafkaは、高スループットでフォールトトレラントなデータフィードを処理するために設計された、強力な分散イベントストリーミングプラットフォームです。そのアーキテクチャは、Kafkaがどのようにしてレコードのストリームを確実に処理・保存するかを理解する上で不可欠です。基本的な概念実証を設定する場合でも、ミッションクリティカルなアプリケーションをスケーリングする場合でも、その主要コンポーネントであるブローカー、トピック、プロデューサー、コンシューマー、およびZooKeeperの役割を把握することは、効果的なデプロイメントと管理のために不可欠です。

このガイドでは、Kafkaのアーキテクチャを体系的に分解し、これらのコンポーネントがどのように相互作用して、リアルタイムのデータ移動とストレージのための堅牢でスケーラブルなシステムを形成するかを詳述します。

Kafkaアーキテクチャの主要コンポーネント

Kafkaは分散システムとして動作します。つまり、その機能はスケーラビリティとレジリエンスのために複数のマシン（ノード）に分散されています。コアアーキテクチャは、以下の5つの主要エンティティの協調的な取り組みに依存しています。

1. Kafkaブローカー（サーバー）

Kafkaクラスターは、ブローカーとして知られる1つ以上のサーバーで構成されています。これらのブローカーは、データの保存（ログ）とクライアントリクエスト（読み取りと書き込み）の処理を担当します。

• 役割： ブローカーはプロデューサーからメッセージを受信し、それらをトピックパーティションにコミットし、コンシューマーにそれらのメッセージを提供します。これらはクラスターのバックボーンを形成します。
• フォールトトレランス： ブローカーが故障した場合でも、レプリケーションが正しく設定されていれば、そのパーティションはレプリカブローカーによって処理され、データの可用性が確保されます。
• スケーリング： クラスターにブローカーを追加することで、システムを水平方向にスケーリングし、負荷とストレージ容量を分散させることができます。

2. トピック（データカテゴリ）

トピックは、Kafkaでデータストリームを分類するための主要なメカニズムです。これらはデータベースのテーブルやファイルシステムのフォルダに似ています。

• 定義： トピックは、レコードが発行されるフィード名です。トピック内のデータは常に時系列順に並べられます。
• パーティション： 並列処理とスケーラビリティを実現するために、トピックはパーティションに分割されます。各パーティションは、順序付けされた不変のレコードのシーケンスです。
  • パーティション内のデータは厳密に順序付けされ、オフセットと呼ばれる増分IDが割り当てられます。
  • メッセージは、キー（指定されている場合）またはラウンドロビン方式に基づいてパーティション全体に分散されます。
• レプリケーション： フォールトトレランスのために、パーティションは複数のブローカーにレプリケートされます。アクティブなプライマリコピーを保持するブローカーがリーダーであり、他のブローカーはフォロワーです。

例：トピック設定

トピックを作成する際には、パーティション数とレプリケーションファクターを定義します。例えば、user_activityという名前のトピックを、パーティション数3、レプリケーションファクター3で作成するには、以下のコマンドを使用します。

kafka-topics.sh --create --topic user_activity --bootstrap-server localhost:9092 --partitions 3 --replication-factor 3

3. プロデューサー（データ書き込み元）

プロデューサーは、レコードのストリームをKafkaトピックに公開（書き込み）するクライアントアプリケーションです。

• 機能： プロデューサーはレコードをキーと値のペア（オプションでタイムスタンプとヘッダーを含む）にフォーマットし、Kafkaクラスターに送信します。
• パーティション割り当て： プロデューサーは、メッセージがどのパーティションに送られるかを決定します。メッセージにキーがある場合、Kafkaはそのキーにハッシュメカニズムを使用して、常に同じパーティションにマッピングします。キーが提供されない場合、メッセージはラウンドロビン方式で分散されます。
• 確認応答（Acks）： プロデューサーは、acks設定を使用して必要な耐久性レベルを設定します。これは、書き込みが成功したと見なされるまでに、いくつのブローカーが受信を確認する必要があるかを規定します（例：acks=allは最高の耐久性を保証します）。

4. コンシューマー（データ読み取り元）

コンシューマーは、1つ以上のトピックを購読し、それらに公開されたレコードのストリームを処理するクライアントアプリケーションです。

• 消費メカニズム： コンシューマーは、パーティション内のオフセットに基づいてデータを順次読み取ります。コンシューマーは、正常に処理したオフセットを追跡する責任があります。
• コンシューマーグループ： コンシューマーは通常、コンシューマーグループ内で動作します。Kafkaは、特定のコンシューマーグループ内では、各パーティションが1つだけのコンシューマーインスタンスによって消費されることを保証します。これにより、パーティション数までインスタンスを追加することで、読み取りを水平方向にスケーリングできます。

例：コンシューマーオフセット

コンシューマーがメッセージを処理すると、処理した最後のオフセットを定期的にKafkaにコミットします（通常、内部トピック__consumer_offsetsに保存されます）。コンシューマーがクラッシュした場合、同じグループ内で再起動すると、最後にコミットされたオフセットから読み取りを再開し、データ損失や二重処理を防ぎます（コミット戦略によります）。

5. Apache ZooKeeper（協調サービス）

歴史的に、Apache ZooKeeperはKafkaクラスターのメタデータと状態を管理するために不可欠でした。Kafkaはセルフマネージドメタデータアーキテクチャ（Kafka Raft Metadata Mode、略してKRaft）への移行を進めていますが、ZooKeeperは既存の広くデプロイされている多くのクラスターで依然として重要なコンポーネントです。

• メタデータストレージ： ZooKeeperは、アクティブなブローカーのリスト、ブローカーへのパーティションの割り当て、トピックの設定詳細など、クラスター設定を保存します。
• コントローラー選出： ZooKeeperは、Kafkaコントローラーの選出を管理します。コントローラーは、パーティションのリーダーシップ変更、レプリカ同期、およびクラスター全体の状態変更を管理するために選出される1つのブローカーです。

データフローと相互依存性

アーキテクチャは、明確な責任の流れを確立することで機能します。

1. プロデューサーの初期化： プロデューサーはクラスター内の任意のブローカー（ゲートウェイとして機能）に接続し、ターゲットトピックに関するメタデータを要求します。
2. リーダーへのリダイレクト： ブローカーはプロデューサーを、ターゲットパーティションの現在のリーダーレプリカに誘導します。
3. データ書き込み： プロデューサーはレコードをリーダーブローカーに送信します。
4. レプリケーション： リーダーブローカーはレコードをローカルログに書き込み、オフセットを割り当て、その後指定されたすべてのフォロワーレプリカにレコードをレプリケートします。
5. 確認応答： 設定された数のレプリカ（acksレベル）が受信を確認すると、リーダーはプロデューサーに成功を通知します。
6. 消費： コンシューマーは、関心のあるパーティションのリーダーブローカーをポーリングし、指定されたオフセットから始まるレコードを要求します。

重要な考慮事項：データ保持

従来のメッセージキューとは異なり、Kafkaは基本的に分散コミットログです。データは、コンシューマーが読み取ったかどうかに関わらず、設定された期間（デフォルトは多くの場合7日間）またはサイズしきい値に達するまでブローカーのディスクに保持されます。この永続性により、新規または遅延したコンシューマーが過去のデータを読み取ることができます。

ベストプラクティス： アプリケーションのリカバリ要件に基づいてディスクスペースを効果的に管理するために、トピックのlog.retention.hoursまたはlog.retention.bytesを慎重に設定してください。

スケーリングとレジリエンス

Kafkaのアーキテクチャは、本質的に水平スケーリングとレジリエンスのために設計されています。

• 書き込み/読み取りのスケーリング： より多くのブローカーを追加し、高トラフィックのトピックのパーティション数を増やすことによって実現されます。
• フォールトトレランス： レプリケーションによって実現されます。パーティションのリーダーブローカーが故障した場合、ZooKeeper（またはKRaftメカニズム）がその故障を検出し、残りのフォロワーが協調して新しいリーダーを選出し、プロデューサーとコンシューマーに対して最小限のダウンタイムで継続的な可用性を保証します。

ブローカーがパーティションをどのように保存するか、プロデューサーがキーを介してメッセージをどのようにルーティングするか、そしてコンシューマーグループがオフセットをどのように管理するかといった、これらの主要なアーキテクチャコンポーネントを習得することで、高性能イベントストリーミングのためにKafkaをデプロイし、チューニングするために必要な基盤が得られます。