ソリューションアーキテクチャーデザイン連載(5/13)：イベントドリブンアーキテクチャーとは何ですか？

イベントドリブンアーキテクチャーは、マイクロサービスアーキテクチャーやサーバレスアーキテクチャーなど、最近のシステム開発においてよく採用されるアーキテクチャースタイルの一つです。

イベントドリブンアーキテクチャー（EDA）は、システム内のイベントに基づいて、各コンポーネントが独立して動作するアーキテクチャースタイルです。システム内で何かが起こった場合、それに応じて別のコンポーネントが呼び出され、処理が進むという流れになります。

イベントドリブンアーキテクチャーでは、各コンポーネントが独立して動作するため、非同期処理が可能であり、システムのスケーラビリティが高いというメリットがあります。また、コンポーネント間の依存関係が少ないため、柔軟なシステム設計が可能です。

具体例としては、顧客が新しい注文を行った場合、システム内でイベントがトリガーされ、在庫管理システムに在庫数の更新を要求することが挙げられます。また、顧客が購入した商品が発送された場合、システム内でイベントがトリガーされ、配送情報が更新されることがあります。

 

代表的な実装例としては、Pub/Sub（Publisher/Subscriber）モデルが挙げられます。このモデルでは、イベントを発行する側（Publisher）と、イベントを受信する側（Subscriber）が存在し、Publisherがイベントを発行すると、Subscriberはそれを受け取って適切な処理を行います。

AWS、Azure、GCPの各クラウドプロバイダーが提供するマイクロサービスのサポートツールは、次の通りです。

AWS：

• AWS Lambda
• Amazon Kinesis
• Amazon EventBridge
• AWS SNS（Simple Notification Service）
• AWS SQS（Simple Queue Service）

Azure：

• Azure Functions
• Azure Stream Analytics
• Azure Event Grid
• Azure Service Bus
• Azure Simple Queue Storage

GCP：

• Cloud Functions
• Cloud Pub/Sub
• Cloud Dataflow
• Cloud Pub/SubとGoogle Cloud Task

これらのサービスをどのように実装するかは、常にビジネスプロセスが持っている目的をどのように実現するか、全体像を考慮しながらアプローチしていきます。また、複数のアーキテクチャースタイルを柔軟にミックスすることも必要になってきます。例えば、クラウド環境の場合、イベントドリブンアーキテクチャーにマイクロサービスやサーバレスを組み込むことは、一般的になっています。
イベントドリブンアーキテクチャーは、イベントをトリガーとして処理が進行するため、イベントからイベントへの連鎖が発生することが一般的です。そのため、処理が止まったポイントで処理を再開できるようにすることと、同じデータ処理が複数回実行される可能性があるため、データの冪等性を保証する必要があります。

イベントドリブンアーキテクチャーは、拡張性や柔軟性、パフォーマンス、テスト容易性、可読性の向上など、多くのメリットを提供することができます。

• 拡張性
  各コンポーネントが独立して動作し、イベントが発生するたびにコンポーネントが呼び出されるため、システム全体の拡張性が高くなります。新しい機能を追加する際に、既存のコンポーネントに影響を与えることなく、新しいコンポーネントを追加できます。
• 柔軟性
  コンポーネントが独立して動作するため、異なるプログラミング言語やプラットフォームを組み合わせてシステムを構築することができます。これによって、システムの柔軟性が高まります。
• パフォーマンス
  必要なときにのみコンポーネントを呼び出すため、余分なリソースの消費を抑えることができます。また、非同期処理が可能なため、並列処理に適しています。
• テストの容易性
  各コンポーネントが独立して動作するため、テストが容易になります。また、各コンポーネントが疎結合であるため、単体テストや結合テストがしやすくなります。
• 可読性
  各コンポーネントが独立して動作するため、システムの全体像が容易に把握できます。また、各コンポーネントが単純な機能を持つため、コードの可読性が高くなります。

さらに、イベントドリブンアーキテクチャーは、ネイティブクラウドで展開するフルマネージドサービスのシステム基盤が提供するハイアベラビリティやスケーラビリティによって、さらなるシナジー効果を生み出しています。

イベントドリブンアーキテクチャーには、コンポーネントの複雑性、スケーラビリティの問題、セキュリティの課題、デバッグやテストの複雑さなど、いくつかのデメリットもあります。これらを踏まえた上で、イベントドリブンアーキテクチャーの導入を検討する必要があります。

• 実装の複雑性
  コンポーネント間の非同期処理やデータのフローなどが複雑になりやすく、設計や実装が複雑になることがあります。
• スケーラビリティ
  イベントが発生するたびにコンポーネントが呼び出されるため、イベントが多発する場合には、遅延することがあります。
• デバッグの問題
  非同期処理が多くなるため、デバッグが困難になることがあります。特に、複数のコンポーネントが関係するイベントの発生・受信時に、問題の特定や原因の追跡が困難になることがあります。
• セキュリティの問題
  複数のコンポーネントが相互にイベントをやりとりするため、セキュリティの問題が発生することがあります。特に、不正なイベントを発生させる攻撃などが考えられます。
• テストの複雑さ
  コンポーネントが独立して動作するため、テストが容易になるというメリットがありますが、一方で、複数のコンポーネントが相互にイベントをやりとりするため、テストの複雑さが増すことがあります。

ここで上げているデメリットは必ず起こるということではありません。しかし、これらの問題が潜在しているため、注意して回避策を講じる必要があります。

例えば、スケーラビリティに関しては、ビジネスプロセスを考慮してボトルネックが発生しそうな箇所を把握し、設計に反映させる必要があります。自動または運用でスケールできる仕組みや、遅延を解消するための配慮を設計に反映させることも必要です。さらに、クラウド上のサービスにはリソースの制限があるため、その制限も考慮した設計が必要です。

デバッグやテストにおいては、クラウドサービスに備わっているロギング機能やアラート機能などを積極的に利用すべきです。

セキュリティ面では、VPCやファイアウォール設定、コンポーネントを配置するエリアの設計などを充実させる必要があります。

最後に、コンポーネントの数が大量になり、関係性が複雑になるという問題の管理は非常に重要です。特に大規模な開発プロジェクトでは、Graph DB（例：Neo4j）の利用などが考えられます。

 

前のページへ｜Topページへ｜次のページへ