'リファレンスアーキテクチャ: Apache Kafka を使用したイベント駆動型マイクロサービス'

最終更新日 2022年12月28日(水)

シナリオ
アーキテクチャ
実装ガイドライン
利点と欠点
その他の資料

このアーキテクチャは、Heroku 上の一連のサービスが分離していて、代替可能で、独立している場合に、スケーラブルで、可用性が高く、フォールトトレラントな非同期通信バックボーンである Apache Kafka on Heroku を使用してこれらのサービスを調整する方法を示しています。

シナリオ

非同期で通信する必要がある多数のマイクロサービスがあります。
マイクロサービスは、分離され、代替可能で、個別にメンテナンスされるものとします。
多くのサービスによって処理する必要があるイベントを生成する 1 つ以上のサービスがあります。
一般的な HTTPS アプローチよりも分離性を高めたマイクロサービス通信パターンを使用したいと考えています。

このリファレンスアーキテクチャでは、Apache Kafka on Heroku を使用してマイクロサービス間の非同期通信を調整します。サービスが Kafka にイベントを発行し、下流のサービスは直接呼び出される代わりにそれらのイベントに反応します。このように、イベントを生成するサービスがイベントを消費するサービスから分離されています。その結果、スケーラブルで、互いに独立していて、代替可能であるサービスによって構成されたアーキテクチャが実現します。

リレーショナルデータベースを使用したモノリシックアーキテクチャではボトルネックが発生しがちですが、マイクロサービス間の非同期通信に Kafka を使用することでそのようなボトルネックを回避できます。Kafka は可用性が高いため、停止の懸念が少なく、障害は最小限のサービス中断で暗黙的に処理されます。設定した期間中のデータが Kafka によって保持されるため、必要に応じてイベントを巻き戻して再現することを選択できます。

architecture diagram of Apache Kafka as a central message broker for a set of microservices Apache Kafka による一連のマイクロサービスのスケーラブルで分離性の高い調整

コンポーネント

必須

ブローカーとして機能する Apache Kafka on Heroku インスタンス
Kafka からのメッセージを消費するように設定される一連の個別サービス
イベントを Kafka に発行するように設定される (潜在的に重複した) 一連のサービス

実装ガイドライン

マイクロサービスの設定

Kafka のコンシューマーとプロデューサーを個別の Heroku アプリに分離し、必要に応じてスケーリングします。
モノリスをマイクロサービスに変換している場合は、そのようなシステムへの移行アプローチの 1 つを説明しているこちらのブログ記事を参照してください。
Kafka と通信するための、アプリの各種クライアントライブラリのドキュメントに目を通します。

非同期メッセージングと Kafka の設定

Apache Kafka on Heroku をプロビジョニングします。
必ず、プロデューサーとコンシューマーに相当するすべてのアプリで同じ Kafka インスタンスを共有してください。
マイクロサービスの通信にハイブリッド型のアプローチを採用してみましょう。HTTPS メッセージと Kafka メッセージの両方を使用すると効果的な場合があります。
Kafka の設定についての詳細は、Apache Kafka on Heroku のカテゴリを参照してください。

実装例

次のアーキテクチャ図は、この Terraform スクリプトを使用してデプロイできる単純なイベント駆動型マイクロサービスアーキテクチャを示しています。

Apache Kafka 経由でマイクロサービスをダッシュボードおよびバックエンドデータサービスに接続するアーキテクチャ図

この特定の例は、非同期メッセージングと HTTPS の両方を使用するハイブリッドシステムです。イベントは模擬の e コマースアプリケーション (edm-ui) から発生し、HTTPS で edm-relay に送信されて、ここからそれぞれの Kafka トピックに書き込まれます。これらのメッセージは 2 つの異なるアプリ (edm-stream と edm-stats) によって消費されます。

すべてのイベントが各サービスによって処理されるよう、edm-stats アプリと edm-stream アプリは異なる Kafka コンシューマーグループに属しています。各サービスは、イベントによって駆動される異なったビジネス目的を持ちます。

edm-stream は Socket.io を介してイベントを edm-dashboard に直接ストリーミングします。
edm-stats はイベントの統計情報を記録し、そのデータを Heroku Postgres データベースに保存し、そのデータのためのシンプルな API を提供します。

最後に、edm-dashboard はデータ視覚化 UI であり、まず HTTPS で edm-stats の履歴統計データを要求し、Socket.io を介して edm-stream からストリーミングイベントを受信します。

このアーキテクチャの分離型の性質により、イベントを消費するサービスの追加は簡単です。新しいコンシューマーグループに属する別のサービスを作成すると、選択したトピックをそのサービスが購読します。

Heroku での Terraform の使用方法については「Heroku で Terraform を使用する」を参照してください。この Terraform スクリプトはアーキテクチャ全体をデプロイします。