Kafka イベントストリームのモデリング

最終更新日 2022年11月30日(水)

Apache Kafka on Heroku は、最新のアプリケーションアーキテクチャを作成したり、高スループットのイベントストリームを処理したりするための強力なツールです。しかし、ストリーミングイベントデータの世界に移行することは、ORM の対話相手であるリレーショナルデータベースからの切り替えほど簡単ではありません。ストリーミングデータを最大限に活用するには、製品のロジックとニーズをサポートするように、データと Kafka 設定の両方をチューニングする必要があります。

Apache Kafka のコア概念

Apache Kafka on Heroku​ の記事で説明しているように、Apache Kafka on Heroku を理解してチューニングするために不可欠なコア概念がいくつかあります。この議論に欠かせない重要な概念は、トピックとパーティションです。

トピックは、チャネルやストリームに似た Kafka の主要な構造であり、リレーショナルデータストアでテーブルがレコードの種類を表すのと同じようにイベントの種類を表します。

トピックはいくつかのパーティションで構成されます。各パーティションには、特定のトピックに属するイベント (Kafka の用語ではメッセージ) の個別のサブセットが含まれます。

これらのパーティションの数や使用法を変更することは、製品に合わせて Kafka をチューニングし、順序付け、並列処理、障害許容力の懸念事項のバランスを取るために重要です。

バランスを取るための考慮事項

特定のトピックで使用するパーティション構造を評価するときは、以下の重要な特性のバランスを考慮する必要があります。

メッセージの順序付け

特定のパーティション内のメッセージは厳格に順序付けされますが、この順序付けはパーティションをまたいでの保証はされません。

コンシューマーグループの並列処理

コンシューマーグループには、トピック内のパーティションと同じ数だけトピックの並列コンシューマーが存在できます。

リソース利用

パーティション数が多いと、リソースの利用が増加する可能性があります。また、ブローカーが障害から回復するときに、リーダーの回復または再選出にかかる時間が長くなる可能性があります。

カスタムパーティション機能

プロデューサーでは、トピック内のパーティションにメッセージを送信するための任意のロジックを選択できます。このとき、均等な配分のために基本的なハッシュ処理を使用します。あるいは、特定の製品のニーズに合わせて順序付けおよびスループットのセマンティックスを維持するために、特定のロジックを選択することができます。

以上の属性について、徹底的にではないにしても考慮することにより、トピックのパーティション構造の設計のための強固な基礎が提供されます。

製品のロジックをサポートするためのモデリング

イベントの厳格な順序付けが最優先ではないが、きわめて活発な並列処理がスループットのために必要な場合は、スケールアウトしたコンシューマーグループを扱うのに十分だがクラスターに必要以上の負荷をかけない水準にパーティション数を設定するのが適切である可能性があります。

製品のロジックで厳格な順序付けが重要な場合は、その順序付けが重要である領域を明確にすることが重要です。たとえば、順序付けはグローバルに、すべての状態のすべての変更にわたって必要でしょうか。それとも、特定のユーザーまたはアカウントに関連した変更のみに順序付けが必要でしょうか。順序付けが重要な期間はどれくらいでしょうか。多くの場合、順序付けのために重要な属性に基づいて複合キーを作成し、それらのキーに基づいてメッセージを一貫してパーティションにハッシュ化するのが合理的です。たとえば、user_id​ と session_id​ の組み合わせによるパーティション分割では、特定のユーザーのセッションに関連したイベントの厳格な順序付けを提供しますが、セッションまたはユーザーをまたいで順序付けが維持されることはありません。

参考情報

次に示す、より広範な Kafka コミュニティからの優れた資料は、アプリケーションのニーズに合わせてパーティションをモデル化する方法を最適化するために役立ちます。