【ITニュース解説】Core Kafka Fundamentals for Data Engineering

Apache Kafkaは、リアルタイムで発生する大量のイベントデータを効率的に処理するために設計された、オープンソースの分散イベントストリーミングプラットフォームだ。イベントとは、システム内で起こった出来事の記録を指し、ウェブサイトでのボタンクリックやデータベースへのデータ挿入などがこれにあたる。ストリーミングとは、データが継続的に生成、配信、処理されることを意味し、イベントストリーミングはこれらのイベントを発生と同時に連続的に捉え、保存し、処理する技術である。具体的には、リアルタイムでのデータ取得、イベントストリームの永続的な保存、リアルタイムでのイベント処理と反応、必要に応じたデータのルーティングといった機能を提供する。

Kafkaの核となる要素はブローカーだ。ブローカーはKafkaサーバーのことで、トピックやパーティションの保存、メッセージの送受信処理、プロデューサーとコンシューマーとの通信を担当する。通常、Kafkaクラスターは複数のブローカーで構成され、これによりスケーラビリティと耐障害性を確保する。トピックはイベントが書き込まれ、読み取られる論理的なカテゴリだが、実際にはスケーラビリティのためにパーティションに分割される。一つのイベントは必ず一つのパーティションに書き込まれ、パーティション内のイベントは順序付けられた追記専用のログとして不変に保存される。以前のKafkaではZookeeperという分散コーディネーションサービスが使用され、Kafkaブローカーの追跡、コントローラーブローカーの選出、ブローカーの障害管理などを行っていたが、これは独立した管理システムが必要で運用が複雑になるという欠点があった。KRaftモードでは、KafkaがZookeeperの役割を内部で処理するようになり、メタデータ管理にRaftプロトコルを用いる。これによりデプロイが簡素化され、メタデータの一貫性が強化され、数千規模のブローカーへのスケーリングが容易になった。

Kafkaクラスターは複数のブローカーが連携して動作するシステムであり、ロードバランシングと耐障害性のために複数のブローカーと、パーティションのリーダーシップを管理するコントローラーブローカーを持つ。スケーリングはブローカーの追加や削除によって行われ、その際にはパーティションの再割り当てが必要となる。パーティションを増やすことで並列処理が可能になり、レプリケーションによって耐障害性が保証される。ブローカーを複数デプロイし、トピックをパーティションに分割してデータを分散させる。さらに、各パーティションを複数のブローカーに複製することで、ブローカー障害時のデータ可用性を確保する。クライアントアプリケーションであるプロデューサーとコンシューマーはブートストラップサーバーを介してクラスターに接続し、コンシューマーはコンシューマーグループ内で複数のインスタンスを立ち上げてパーティションを分担することでスケーリングする。

トピックはイベントが発行される論理的なカテゴリ名だ。同じ種類のイベントは同じトピックに集約される。プロデューサーはトピック内のパーティションにイベントを書き込み、コンシューマーは通常、追記された順序でそれらのパーティションからイベントを読み取る。パーティションはKafkaトピックのサブディビジョンであり、イベントが順序付けられた不変のログとして保存される物理的なストレージ単位である。スケーラビリティと並列処理のために各トピックは複数のパーティションに分割され、それらはKafkaブローカー上に物理的に存在する。オフセットはパーティション内のレコードの位置を示す増加する整数で、各レコードに割り当てられる。プロデューサーがメッセージを書き込むとKafkaはパーティションごとに順序付けられたオフセットを割り当て、コンシューマーはこのオフセットをポインターとしてメッセージを読み取り、最後に処理したオフセットを記憶することで、クラッシュ後の再開地点を把握する。

プロデューサーはKafkaトピックにイベントを発行するクライアントアプリケーションだ。イベントをどのパーティションに送るかを選択でき、キーが提供される場合はそのキーにハッシュ関数を適用して常に同じパーティションに送られるが、キーを指定しない場合はラウンドロビン方式で分散される。プロデューサーは書き込みが成功したと判断する前にKafkaからどの程度の確認を待つか、Acknowledgmentモード（acks）で設定できる。acks=0は確認を待たずに送信する最も高速なモードだが、メッセージが失われる可能性がある。acks=1はリーダーパーティションが書き込みを完了したら応答するモードで、より安全だがリーダーがレプリカに複製する前にクラッシュするとデータが失われる可能性がある。acks=allはリーダーと全ての同期済みレプリカが書き込みを承認するまで待機する最も安全なモードで、堅牢な永続性保証を提供するが、レプリケーションを待つため遅くなる。

コンシューマーはKafkaトピックのイベントを購読し、読み取り、処理するクライアントアプリケーションだ。コンシューマーはgroup idで識別されるコンシューマーグループに属し、Kafkaは一つのパーティションがグループ内の正確に一つのコンシューマーによって消費されるように保証する。これにより、グループ内の複数のコンシューマーが異なるパーティションから並行してデータを読み取ることでスケーラビリティが向上し、また一つのコンシューマーが故障した場合でも、Kafkaがそのパーティションをグループ内の他のコンシューマーに再割り当てすることで耐障害性が得られる。オフセットはコンシューマーがパーティション内でどこまで読み進んだかを示す番号で、ブックマークのような役割を果たす。コンシューマーはメッセージを読み取った後、次に再起動した際に正しい場所から再開できるようにオフセットをKafkaにコミットする必要がある。自動コミットではKafkaが定期的にオフセットをコミットするが、処理とコミットのタイミングによってはデータ損失や重複のリスクがある。手動コミットではコンシューマーが処理完了後に明示的にオフセットをコミットし、より細かい制御が可能となり、厳密に一回または少なくとも一回のセマンティクスを保証できるが、実装はより複雑になる。

メッセージ配信セマンティクスは、Kafkaシステムが障害発生時も含め、メッセージをコンシューマーに何回配信するかを保証する。At-Most-Onceは、メッセージが最大1回配信されることを保証し、重複はないが失われる可能性がある。At-Least-Onceは、メッセージが少なくとも1回配信されることを保証し、失われることはないが重複が発生する可能性がある。Exactly-Onceは、各メッセージが正確に1回だけ配信されることを保証し、これはプロデューサーの冪等性を有効にし、トランザクションを利用することで実現される。プロデューサーの冪等性により、ネットワーク問題やブローカー障害時のリトライで重複書き込みが回避され、トランザクションによりメッセージ送信とコンシューマーのオフセットコミットが原子的に処理され、部分的なコミットがなくなるため、障害時でもデータ損失や重複なしに安全に再試行できる。

リテンションポリシーは、Kafkaトピックに保存されるデータを管理し、ディスク使用量を管理しつつ、コンシューマーが必要なデータにアクセスできるようにする。時刻ベースのリテンションでは、メッセージは指定された期間だけ保持され、その期間を過ぎると削除の対象となる。サイズベースのリテンションでは、トピックまたはパーティションが使用できるディスク容量を制限し、閾値を超えると最も古いログセグメントを削除して新しいデータのためのスペースを確保する。ログコンパクションは、キーを持つレコードに対して最新の値のみを保持するポリシーだ。同じキーを持つ複数のレコードがある場合、古いバージョンは削除され、最新のものだけが残る。

プロデューサーがコンシューマーよりも速くメッセージを生成する状況を解決するため、Kafkaはバックプレッシャーとフロー制御メカニズムを使用する。バックプレッシャーは、コンシューマーやブローカーが過負荷でデータフローに追いつけないことをシステムが示す。コンシューマーが遅い場合、メッセージはトピックのパーティションに蓄積され続け、遅延がリテンション制限を超えると、コンシューマーはデータを永続的に失う可能性がある。フロー制御は、プロデューサーとコンシューマーがブローカーやクライアントを圧倒することなく、バランスの取れたペースで動作することを保証する。コンシューマーラグは、遅いコンシューマーを特定するための重要なメトリクスであり、このラグが大きい、または増加している場合はコンシューマーが遅れていることを示す。

Kafkaはメッセージをバイト配列として保存・転送するため、プロデューサーはデータを送信する前にバイト形式にシリアライズし、コンシューマーはそのバイトを読み取り可能なデータ構造にデシリアライズする必要がある。一般的なシリアライゼーション形式には、人間が読めて言語に依存しないJSON、コンパクトなバイナリ形式でスキーマを別途保存できるAvro、非常にコンパクトで高速なProtobufがある。Confluent Schema Registryは、Kafkaメッセージのスキーマを管理および検証するための集中リポジトリを提供し、プロデューサーはメッセージを公開する際にスキーマを登録し、コンシューマーはデータを正しくデシリアライズするためにスキーマを取得する。

Kafkaでは、高い可用性とデータの耐久性はレプリケーションによって実現される。レプリケーションは、ブローカーが故障した場合でもデータが失われないことを保証し、耐障害性はコンポーネントがダウンしてもシステムが動作し続けることを可能にする。トピックはパーティションに分割され、各パーティションは複数のブローカーに分散されたレプリカを持つことができる。リーダーレプリカはパーティションの全ての読み書きを処理し、フォロワーレプリカはリーダーからデータを継続的にフェッチしてログを同期させる。In-Sync Replicas（ISR）は、リーダーと完全に同期しているレプリカであり、現在のリーダーが故障した場合に新しいリーダーとして選出される資格を持つのはISR内のレプリカのみである。これにより、ブローカーがリーダーレプリカをホストしている状態で故障した場合、KafkaはISR内の残りのフォロワーから自動的に新しいリーダーを選出し、クライアントはメタデータ更新を介して新しいリーダーを自動的に検出することで高い可用性を維持し、サービスの継続的な運用を保証する。

Kafka Connectは、Kafkaと他のシステム間でデータをスケーラブルかつ信頼性の高い方法でストリーミングするためのフレームワークだ。外部システムからKafkaにデータを読み込むソースコネクタと、Kafkaから外部システムにデータを書き込むシンクコネクタの二種類がある。コネクタインスタンスは、Kafkaと他のシステム間でデータをコピーするジョブであり、その利点として、複数のワーカーノードに分散サービスとして実行できるスケーラビリティ、そして障害処理、リトライ、厳密に一回セマンティクスを扱う信頼性が挙げられる。

Kafka Streamsは、Kafkaを流れるデータをリアルタイムで処理および分析するためのライブラリだ。ステートレス操作は以前のレコードに関する情報を記憶する必要がなく、各レコードを独立して処理する。一方、ステートフル操作は過去のデータを記憶する必要があり、過去のレコードに基づいて状態を維持および更新することで結果を生成する。ウィンドウイングの概念は、集約や結合のようなステートフル操作を実行できるように、ストリーミングレコードを時間によってグループ化する方法を定義し、タンブリングウィンドウ、ホッピングウィンドウ、セッションウィンドウといった種類がある。

ksqlDBは、Apache KafkaにSQLライクなインターフェースを提供し、馴染みのあるSQL構文を使用してリアルタイムストリーム処理と分析を可能にする。リレーショナルデータベースを扱うようにSQL構文でクエリを作成でき、Kafkaトピックにイベントが到着した瞬間に処理するリアルタイムストリーム処理、Kafka Streamsライブラリの上に高レベルのSQL抽象化を提供することで開発が簡素化される。

Apache Kafkaのセキュリティモデルは、データの機密性、完全性、および制御されたアクセスを保護するために連携して機能するいくつかの主要コンポーネントに基づいている。認証は、Kafkaクラスターへの接続を試みるクライアントおよびブローカーのIDを検証し、SASL（Simple Authentication and Security Layer）がそのフレームワークとして使用され、PLAINメカニズムやKerberosが利用される。認可は、Access Control Lists（ACLs）によって制御され、クライアントが実行を許可されている操作を決定するためにKafkaがチェックを行う。暗号化は、転送中のデータの機密性と完全性を保証し、不正なパーティによるメッセージの読み取りや改ざんを防ぐため、KafkaはTLS（SSL）を使用して接続を暗号化する。

Kafkaを効果的に監視するためには、コンシューマーラグ、under-replicated partitions (URP)、スループット、レイテンシーといったメトリクスを追跡すべきだ。コンシューマーラグは、パーティションに最後に生成されたメッセージとコンシューマーグループによって最後に消費されたメッセージとの差を示し、ラグが高い場合はコンシューマーが遅延していることを意味する。URPは、リーダーパーティションが同期されていないレプリカを持っている場合に発生し、ブローカー障害時にデータ損失のリスクがあることを示す。スループットはメッセージ処理レートを測定し、レイテンシーはメッセージが到着してから処理されるまでの時間（エンドツーエンド遅延）を測定する。

Kafkaのスケーリングは、クラスターの容量を調整し、より多くのデータ、高いスループット、またはより多くのクライアントを性能低下なしで処理できるようにすることである。パーティション数の調整は、トピックのパーティション数を増やすことで並列処理能力を高める。ブローカーを追加することで、データとワークロードがより多くのサーバーに分散され、全体的なストレージ容量の増加、負荷分散によるスループットの向上、耐障害性の強化に繋がる。パーティションの再バランスは、ブローカー間でパーティションを再分散させ、均等な負荷分散を保証する。パフォーマンス最適化は、プロデューサー、ブローカー、コンシューマーパイプラインにおけるボトルネックを減らすことで、メッセージの生成、保存、消費をより高速かつ信頼性の高いものにすることに焦点を当てる。バッチ処理は、プロデューサーがメッセージを個別に送信するのではなく、バッチで送信することでネットワークのラウンドトリップ回数を減らす。圧縮はバッチを圧縮することでネットワーク帯域幅とディスク使用量を削減する。KafkaはOSのページキャッシュを利用して高速なディスク読み書きを実現しており、十分なRAMを確保することで頻繁にアクセスされるログがキャッシュに保持され、高コストなディスクI/Oを回避できる。ディスクは高速なものを使用し、KafkaのログディレクトリをOSやアプリケーションのログと分離することでI/O競合を避けるべきだ。ネットワークに関しては、Kafkaはネットワークを多用するため、高帯域幅で低レイテンシーの接続と、適切に調整されたソケットバッファ、バランスの取れたパーティションリーダーが必要となる。

Apache Kafkaは、大規模なリアルタイムデータ処理のために設計された強力な分散イベントストリーミングプラットフォームだ。そのスケーラビリティ、耐久性、そして豊富なエコシステムは、イベント駆動型アーキテクチャやデータパイプラインの基盤となっている。組織が大量のデータを生成し消費し続ける中で、Kafkaは情報が信頼性高く、安全に、そして低遅延で流れることを保証する基盤を提供する。