非同期メッセージングとイベントパッシング

マイクロサービス間の通信を実装するための別のパターンとして、メッセージパッシングがあります。サービス間の通信には、キューを使用してメッセージを交換します。この通信方法の主な利点の 1 つは、サービス検出を行う必要がなく、サービスは疎結合されることです。

同期システムは密結合されるため、同期ダウンストリームの依存関係に問題があると、アップストリームの呼び出し元にただちに影響が及びます。アップストリームの呼び出し元による再試行はすぐにファンアウトし、問題を増幅する場合があります。

AWS は、プロトコルなどの特定の要件に応じ、このパターンの実装に役立つさまざまなサービスを提供しています。1 つの実装方法として、Amazon Simple Queue Service (Amazon SQS) キューや Amazon Simple Notification Service (Amazon SNS) の組み合わせを使用できます。

両サービスは密接に連携しています。Amazon SNS を使用することで、プッシュメカニズムを通じてアプリケーションから複数のサブスクライバーにメッセージを送信できます。Amazon SNS と Amazon SQS を組み合わせて使用することで、1 つのメッセージを複数のコンシューマーに配信できます。次の図は、Amazon SNS と Amazon SQS の統合を示しています。

AWS でのメッセージバスパターン

Amazon SQS キューを SNS トピックにサブスクライブすると、そのトピックにメッセージを発行できるようになり、サブスクライブした SQS キューに Amazon SNS からメッセージが送信されます。メッセージには、トピックに発行した件名とメッセージ、および JSON 形式のメタデータ情報が含まれています。

内部アプリケーション、サードパーティーの SaaS アプリケーション、AWS のサービスにまたがるイベントソースを使用してイベント駆動型アーキテクチャを大規模に構築する別のオプションとして、Amazon EventBridge があります。フルマネージドのイベントバスサービスである EventBridge は、さまざまなソースからイベントを受信して、ルーティングルールに基づいてターゲットを識別し、AWS Lambda、Amazon SNS、Amazon Kinesis Streams などのターゲットにほぼリアルタイムでデータを配信します。受信イベントは、配信に先立って入力トランスフォーマーでカスタマイズすることもできます。

イベント駆動型アプリケーションの開発を大幅に高速化するために、EventBridge スキーマレジストリはスキーマを収集して整理します。これには、AWS のサービスで生成されたすべてのイベントのスキーマも含まれます。また、カスタムスキーマを定義したり、推論スキーマオプションを使用してスキーマを自動的に検出したりすることもできます。ただし、これらすべての機能の潜在的なトレードオフは、EventBridge 配信のレイテンシー値が比較的高くなることです。また、EventBridge のデフォルトのスループットとクォータは、ユースケースに応じ、サポートリクエストを通じて増やす必要が生じる場合があります。

Amazon MQ に基づく別の実装戦略があります。この戦略は、既存のソフトウェアがオープンスタンダードの API と、メッセージングのプロトコルとして JMS、NMS、AMQP、STOMP、MQTT、WebSocket などを使用している場合に利用できます。Amazon SQS はカスタム API を公開します。つまり、既存のアプリケーションをオンプレミス環境などから AWS に移行する場合は、コードの変更が必要になります。Amazon MQ では、多くの場合、この作業が不要になります。

Amazon MQ は、人気の高いオープンソースメッセージブローカーである ActiveMQ の管理とメンテナンスを行います。基盤となるインフラストラクチャは、自動的にプロビジョニングされて高可用性とメッセージの耐久性を確保し、アプリケーションの信頼性をサポートします。