処理だけではない: Kafka Streams から分散データベースを作成した方法と、その結果

おい、ハブル！

以下の本に従うことを思い出してください。 カフカ 私たちは図書館に関する同様に興味深い作品を出版しました Kafka ストリーム API.

今のところ、コミュニティはこの強力なツールの限界を学んでいるところです。 そこで、最近ある記事が公開されましたので、その翻訳をご紹介したいと思います。 著者は自身の経験に基づいて、Kafka Streams を分散データ ストレージに変える方法を説明します。 読書を楽しむ！

Apache ライブラリ カフカストリーム Apache Kafka 上の分散ストリーム処理のために世界中の企業で使用されています。 このフレームワークの過小評価されている側面の XNUMX つは、スレッド処理に基づいて生成されたローカル状態を保存できることです。

この記事では、当社がクラウド アプリケーション セキュリティの製品を開発する際に、この機会をどのように活用して利益を上げたかについて説明します。 Kafka Streams を使用して、共有状態マイクロサービスを作成しました。各マイクロサービスは、システム内のオブジェクトの状態に関する信頼できる情報のフォールト トレラントで可用性の高いソースとして機能します。 私たちにとって、これは信頼性とサポートのしやすさの両方の点で前進です。

単一の中央データベースを使用してオブジェクトの正式な状態をサポートできる別のアプローチに興味がある場合は、それを読んでください。興味深い内容になるでしょう...

共有状態の使用方法を変える時期が来たと考えた理由

エージェントのレポートに基づいてさまざまなオブジェクトの状態を維持する必要がありました (例: サイトは攻撃を受けていましたか?)。 Kafka Streams に移行する前は、状態管理を単一の中央データベース (+ サービス API) に依存することがよくありました。 このアプローチには次のような欠点があります。 デートが集中する状況 一貫性と同期を維持することが大きな課題になります。 データベースがボトルネックになるか、最終的に次のような状態になる可能性があります。 競合状態 そして予測不能な事態に苦しむ。

図 1: への移行前に見られた典型的なスプリットステート シナリオ
Kafka と Kafka Streams: エージェントは API を介してビューを通信し、更新された状態は中央データベースを通じて計算されます。

Kafka Streams を使用すると、状態共有マイクロサービスを簡単に作成できます

約 XNUMX 年前、私たちはこれらの問題に対処するために、共有状態シナリオを徹底的に検討することにしました。 私たちはすぐに Kafka Streams を試してみることにしました。私たちは、Kafka Streams がどれほどスケーラブルで、可用性が高く、フォールト トレラントであるか、豊富なストリーミング機能 (ステートフルなものを含む変換) を備えているかを知っています。 Kafka のメッセージング システムがどれほど成熟し、信頼できるものになったかは言うまでもなく、まさに私たちが必要としていたものです。

私たちが作成した各ステートフル マイクロサービスは、非常に単純なトポロジを備えた Kafka Streams インスタンス上に構築されました。 これは、1) ソース、2) 永続的なキーと値のストアを備えたプロセッサ、3) シンクで構成されています。

図 2: ステートフル マイクロサービスのストリーミング インスタンスのデフォルト トポロジ。 ここには計画メタデータを含むリポジトリもあることに注意してください。

この新しいアプローチでは、エージェントがソース トピックに入力されるメッセージを作成し、コンシューマ (メール通知サービスなど) がシンク (出力トピック) を通じて計算された共有状態を受け取ります。

図 3: 共有マイクロサービスを使用したシナリオの新しいタスク フローの例: 1) エージェントは、Kafka ソース トピックに到着するメッセージを生成します。 2) 共有状態を持つマイクロサービス (Kafka Streams を使用) がそれを処理し、計算された状態を最終的な Kafka トピックに書き込みます。 その後 3) 消費者は新しい状態を受け入れる

この組み込みの Key-Value ストアは実際には非常に便利です。

上で述べたように、共有状態トポロジにはキーと値のストアが含まれています。 これを使用するためのオプションがいくつか見つかりました。そのうちの XNUMX つを以下に説明します。

オプション #1: 計算にキーと値のストアを使用する

最初のキー/値ストアには、計算に必要な補助データが含まれていました。 たとえば、場合によっては、共有状態が「多数決」の原則によって決定されることがありました。 リポジトリには、オブジェクトのステータスに関する最新のエージェント レポートがすべて保存されます。 その後、あるエージェントから新しいレポートを受信したら、それを保存し、同じオブジェクトの状態に関する他のすべてのエージェントからのレポートをストレージから取得して、計算を繰り返すことができます。
以下の図 4 は、新しいメッセージを処理できるように、キー/値ストアをプロセッサの処理メソッドに公開する方法を示しています。

図 4: プロセッサの処理メソッドのキー/値ストアへのアクセスを開きます (この後、共有状態で動作するすべてのスクリプトはメソッドを実装する必要があります) doProcess)

オプション #2: Kafka ストリーム上に CRUD API を作成する

基本的なタスク フローを確立したので、状態共有マイクロサービス用の RESTful CRUD API の作成を試み始めました。 私たちは、オブジェクトの状態を設定または削除するだけでなく、一部またはすべてのオブジェクトの状態を取得できるようにしたいと考えていました (バックエンドのサポートに便利です)。

すべての Get State API をサポートするために、処理中に状態を再計算する必要がある場合は常に、それを組み込みのキー/値ストアに長期間保存しました。 この場合、以下のリストに示すように、Kafka Streams の単一インスタンスを使用してそのような API を実装するのが非常に簡単になります。

図 5: 組み込みのキー/値ストアを使用してオブジェクトの事前計算された状態を取得する

API を介してオブジェクトの状態を更新することも簡単に実装できます。 基本的に、行う必要があるのは、Kafka プロデューサーを作成し、それを使用して新しい状態を含むレコードを作成することだけです。 これにより、API を通じて生成されたすべてのメッセージが、他のプロデューサー (エージェントなど) から受信したメッセージと同じ方法で処理されることが保証されます。

図 6: Kafka プロデューサを使用してオブジェクトの状態を設定できる

小さな複雑さ: Kafka には多数のパーティションがある

次に、シナリオごとに共有状態のマイクロサービスのクラスターを提供することで、処理負荷を分散し、可用性を向上させたいと考えました。 セットアップは簡単でした。すべてのインスタンスを同じアプリケーション ID (および同じブートストラップ サーバー) で実行するように設定したら、残りのほとんどすべてが自動的に行われました。 また、各ソース トピックが複数のパーティションで構成されるように指定し、各インスタンスにそのようなパーティションのサブセットを割り当てることができるようにしました。

また、状態ストアのバックアップ コピーを作成するのが一般的であることにも言及します。これにより、たとえば、障害後の回復の場合に、このコピーを別のインスタンスに転送できます。 Kafka Streams の状態ストアごとに、変更ログ (ローカル更新を追跡する) を含むレプリケートされたトピックが作成されます。 したがって、Kafka は状態ストアを常にバックアップします。 したがって、XNUMX つまたは別の Kafka Streams インスタンスに障害が発生した場合、状態ストアを別のインスタンスにすぐに復元でき、対応するパーティションがそこに保存されます。 私たちのテストでは、ストア内に何百万ものレコードがある場合でも、これが数秒で完了することがわかりました。

状態を共有する単一のマイクロサービスからマイクロサービスのクラスターに移行すると、Get State API の実装はそれほど簡単ではなくなります。 新しい状況では、各マイクロサービスの状態ストアには、全体像 (キーが特定のパーティションにマップされたオブジェクト) の一部のみが含まれます。 必要なオブジェクトの状態がどのインスタンスに含まれているかを判断する必要があり、以下に示すように、スレッドのメタデータに基づいてこれを行いました。

図 7: ストリーム メタデータを使用して、どのインスタンスから目的のオブジェクトの状態をクエリするかを決定します。 同様のアプローチが GET ALL API で使用されました

主な調査結果

Kafka Streams の状態ストアは、事実上の分散データベースとして機能できます。

• Kafka 内で常に複製される
• CRUD API はそのようなシステム上に簡単に構築できます
• 複数のパーティションの処理は少し複雑です
• 補助データを保存するために XNUMX つ以上の状態ストアをストリーミング トポロジに追加することもできます。 このオプションは次の目的で使用できます。
• ストリーム処理中の計算に必要なデータの長期保存
• 次回ストリーミング インスタンスがプロビジョニングされるときに役立つ可能性があるデータの長期保存
• もっともっと...

これらおよびその他の利点により、Kafka Streams は、私たちのような分散システムでグローバル状態を維持するのに適しています。 Kafka Streams は実稼働環境で非常に信頼性が高いことが証明されており (デプロイ後、メッセージの損失は事実上ありません)、その機能がそれだけにとどまらないと私たちは確信しています。

出所： habr.com