'リファレンスアーキテクチャ: 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 の設定

実装例

次のアーキテクチャ図は、この 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 スクリプト​はアーキテクチャ全体をデプロイします。

利点と欠点

利点

  • サービスは分離され、代替可能で、独立しています。
  • メッセージはバッファリングされ、リソースが利用可能になると消費されます。
  • 大量イベント処理のためのサービスのスケーリングが容易です。
  • Kafka は可用性が高く、フォールトトレラントです。
  • さまざまな言語でコンシューマー/プロデューサーを実装できます。

欠点

  • このアーキテクチャは運用がやや複雑で、Kafka の知識が必要です。
  • 部分的な障害への対処が困難になる可能性があります。

その他の資料

ブログ記事

ドキュメント

​