まずはアーキテクチャの構成要素となる「AWS サービス」についてご紹介します。第 2 回 の連載記事では、非同期処理を実現するための手段として「キュー」と「トピック」をご説明しました。

これらを AWS で実現するためには、どのようなサービスがあるのでしょうか。

キューでご紹介するサービスは、Amazon SQS と Amazon MQ です。キューは、一時的にメッセージを格納する軽量バッファと接続エンドポイントを提供することで、メッセージの送信側と受信側の分離を可能とし、非同期化の実現に利用することができます。

Amazon SQS は、AWSが提供するフルマネージド型のメッセージキューイングサービスです。このサービスを利用することで、メッセージの送信側と受信側を分離するキューの機能を容易に実現することができます。

Amazon MQ は、オープンソースのメッセージブローカーである Apache ActiveMQ および RabbitMQ をサポートしたサービスです。Apache ActiveMQ または RabbitMQ を利用したいケースや、既にこれらのオープンソースを既存システムで利用している場合、Amazon MQ を利用することでサーバー管理の負荷を軽減しながらもこれらオープンソースと同等の機能を実現することができます。

ストリームでご紹介するサービスは、Amazon Kinesis Data Stream と Amazon MSK です。ストリームは、データソースによって継続的に生成されるデータを扱うために、レコードの並べ替えや高速な読み書きをサポートするストレージレイヤーと、そのデータに対するコンピューティングを実行する処理レイヤーから構成されるものです。送信側からのデータを一時的に溜め込むことができるため、キュー同様に送信側と受信側の非同期化を実現することができます。

Amazon Kinesis Data Streams は、Amazon SQS 同様にフルマネージド型のストリーミングサービスであり、高いスケーラビリティ、データの耐久性、および耐障害性を実現するサービスです。センサデータやユーザイベントなどをリアルタイムで処理するユースケースに適しています。

Amazon MSK (Managed Streaming for Apache Kafka) は、オープンソースの Apache Kafka を利用したストリーミングデータ処理を可能にするフルマネージド型のサービスです。Apache Kafka を利用したいケースや、既にこのオープンソースを既存システムで利用している場合、Amazon MSK を利用することでサーバー管理の負荷を軽減しながらもこのオープンソースと同等の機能を実現することができます。

トピックでご紹介するサービスは、Amazon SNS と Amazon MQ です。トピックは、通信チャネルとして機能する論理アクセスポイントを提供することで、送信側からのメッセージを複数の受信者に発行する pub/sub メッセージングを実現できるものです。

Amazon SNS は、AWS が提供するフルマネージド型のメッセージングサービスです。このサービスを利用することで、送信側のメッセージを受信側に届ける仕組みを容易に実現することができます。
Amazon MQ は先述のため割愛します。

最後にイベントバスでご紹介するサービスは、Amazon EventBridge と Amazon MQ です。イベントバスは、送信側からのイベントを受信するパイプラインです。イベントバスで受信されたイベントは、事前に定義されたルール条件に一致するかチェックされたのち、該当する受信者にルーティングされます。

Amazon EventBridge は、フルマネージド型のイベントバスサービスです。様々な AWS サービスから生成されたイベントをメッセージとして、メッセージを加工できたり、多様な AWS サービスや特定の SaaS に対してメッセージを送信することができます。
Amazon MQ は、先述のため割愛します。

本連載記事ではこれらの中から、EC サイトの事例に適したキューとトピックを選定することとします。またこの中から利用する AWS サービスとしては、適用事例が豊富でシンプルに活用可能な Amazon SQS および Amazon SNS を選定してご紹介します。

第 1 回 の記事では、EC サイトにおける非同期処理活用の一例として、急激なリクエスト増加が発生した場合の応答性改善と処理能力改善について言及しました。これを実現するためには、キュー自体に急激なリクエスト増加を受けられるためのスケーラビリティと可用性が求められます。Amazon SQS の標準キューでは、高いスケーラビリティによりほぼ無制限のスループットを提供し、冗長化されたインフラストラクチャ構成により高い可用性を実現しているため、ご紹介した事例に適したサービスとなっています。

また、注文処理のようなユースケースでは、注文順序を保証するためにキューに格納されるメッセージの順序を保証したいケースがあります。Amazon SQS では、標準キューと FIFO キューの 2 種類が用意されており、FIFO キューを利用することで First In First Out による順序を保証することができます。

Amazon SQS に格納できる情報量は、1 メッセージあたり最大 256KB となります。仮に UTF-8 の半角英数字であれば 1 文字 1Byte であるため最大で約 25.6 万文字の情報量、日本語であれば大半が 1 文字 3 byte として最大で約 8.5 万文字の情報量をプロデューサーとコンシューマーの間で受け渡すことができます。大半のユースケースはこの情報量で事足りるかと思いますが、万が一 256KB を超えるメッセージを連携したい場合には、Amazon S3 と組み合わせた処理パターン もご検討ください。

さて、キューの処理構成を AWS サービスで表してみましょう。
ここでは説明を簡略化するため、プロデューサーとコンシューマーに利用する AWS サービスは AWS Lambda に統一した記載とします。

通常、Amazon SQS に対してコンシューマーがメッセージを確認するためには、ポーリングの仕組みを独自に構築する必要があります。ただし、今回のアーキテクチャ例のように AWS Lambda をコンシューマーとして指定すると、Amazon SQS のメッセージを自動でポーリングするよう設定することができます。詳細は「AWS Lambda 関数 (コンソール) をトリガーするキューの設定」をご参照ください。また、コンシューマーがキューのメッセージを取得し処理が完了した後はキューのメッセージを削除する処理が必要となりますが、こちらも AWS Lambda を利用することで自動で削除してくれます。

以上により、キューを利用したアーキテクチャのパターンが完成しました。後ほどご説明する EC サイトのアーキテクチャでは、キューでこのパターンを利用してアーキテクチャを組み上げていきます。

(※) Amazon SQS についてより詳しく知りたい方は、公式ドキュメント のほか、builders.flashの記事「アプリケーション間連携を疎結合で実現。「Amazon SQS」をグラレコで解説」や、Black Beltの動画 / PDF もご参照ください。

第 2 回 の記事では EC サイトにおける一例として、複数の処理を並列化することで処理時間の短縮を図り、他の処理との影響分離を実現するケースについて言及しました。Amazon SNS を用いることで、この並列化と影響分離を実現することが可能となります。

メッセージ順序の保証や格納できる情報量については、Amazon SQS と類似した仕様となっています。トピックは標準トピックと FIFO トピックの2種類が用意されており、格納できる情報量は 1 メッセージあたり最大 256KB となります。標準トピックの場合、1 秒間にほぼ上限のないメッセージ数をサポートできるため、高いスループットでパブリッシャーからのメッセージを受け取ることが可能です。

さて、トピックの処理構成を AWS サービスで表してみましょう。

下記に示すアーキテクチャでは、2 つのトピック (トピック A とトピック B) をもつ Amazon SNS を例として示しており、3 つのサブスクライバーのうち 2 つがこのトピック A をサブスクライブしています。この場合、パブリッシャーがトピック A にメッセージを発行した場合には、トピック A をサブスクライブしている 2 つのサブスクライバーにのみメッセージが発行されます。

なおここでは説明を簡略化するため、パブリッシャーとサブスクライバーに利用する AWS サービスは AWS Lambda に統一した記載とします。

これにより、トピックを利用したアーキテクチャのパターンも完成しました。後ほどご説明する EC サイトのアーキテクチャでは、トピックでこのパターンを利用してアーキテクチャを組み上げていきます。

(※) Amazon SNSについてより詳しく知りたい方は、公式ドキュメント のほか、Black Beltの動画 / PDF もご参照ください。

はじめに、「例 5 : キューイングをしつつ同時に並列処理もしたいケース」に紐づくアーキテクチャの全体像を以下に示します。この全体像を①〜⑥の各パートに細分化しながらアーキテクチャを読み解いていきましょう。

まずは、同期処理の箇所についてアーキテクチャを考えてみましょう。

EC サイトの事例では、注文処理サービスから在庫管理サービスへの接続に同期処理を利用しました。この処理の流れを整理し、AWS サービスを活用したアーキテクチャとして表すと以下のようになります。

次に、本連載記事の主題である非同期処理について AWS サービスを活用したアーキテクチャを考えてみましょう。

EC サイトの事例では、注文処理サービスから配送処理サービス・メール通知処理サービス・請求処理サービス・ポイント計算処理サービスへの接続に非同期処理が利用されていました。この処理の流れを整理し、AWS サービスを活用して表すと以下のようになります。ここでは、トピックにメッセージを発行するまでの処理と、発行後の処理を分けて記載します。

非同期で実施された処理結果は、エンドユーザーからするとすぐには不要でも、後から欲しいケースも多々あります。例えば請求処理サービスで出力された請求書や、ポイント計算処理サービスで計算されたポイントなどは、いずれもどこかのタイミングでエンドユーザーに見せられるようにしなければなりません。

これを実現するために、いくつかの方法が挙げられます。

例えば、画面から注文処理サービスの API Gateway に対して定期的にポーリングさせることで、最新の情報をプル型で取得させる方法があります。この場合、定期的なポーリングがバックエンドに対するリクエスト負荷を高める可能性もあります。もし高負荷が課題となる場合には、全ユーザー均一の定期的なポーリングではなく、ユーザーのアクションに応じて情報を取得させるように画面上へリロードボタンを用意したり、画面遷移させることで最新情報を取得させる方法もあります。

また、メール通知処理サービスにあるメール通知のように、プッシュ型でエンドユーザーに通知するといった方法があります。

もし、チャットのようにニアリアルタイム性が求められる場合には、双方向の通信プロトコルである WebSocket を利用することで実現することもできます。このように、非同期処理をアーキテクチャに組み込む際には、エンドユーザーへの結果の通知方法についてもご検討ください。

本記事の冒頭でご説明した AWS サービスを利用することで、AWS サービスを活用した非同期処理アーキテクチャを実現することができました。

第 1 回 で述べたとおり、同期処理と非同期処理は排他的な存在ではなく、組み合わせることで価値を享受することができます。今回ご説明したアーキテクチャもその一例を示しています。そしてこの一例は EC サイトに限ったものではなく、みなさまが担当されているであろう様々なユースケースにも適用することができます。

これまで第 1 回〜第 3 回でご説明した内容を深く理解するためにも、改めてみなさまが設計開発に取り組まれているユースケースに当てはめながら非同期処理 / 同期処理の検討、そしてアーキテクチャの設計に取り組んでみてください。

そして深く設計を進めていくと、ここまでの記事では書かれていなかった新たな非同期処理の課題に直面するかもしれません。非同期処理のエラーハンドリングはどのように実施すれば良いのか、キューにあるメッセージを複数のコンシューマーで重複処理してしまうことはないのか、この他にも検討すべき課題があるはずです。

最終回となる次回は、非同期処理を利用する際に考慮すべき設計ポイントについてご説明することで、これら課題に対する解決策を示します。第 1 回掲げた「アーキテクチャ設計で同期処理と非同期処理を使いこなす」という目標に向けて、最終回もぜひお付き合いください。

第 3 回目となる今回は、最初に非同期処理の実現に利用できる AWS サービスを取り上げ、ECサイトの事例をもとに AWS サービスを活用した非同期処理 / 同期処理のアーキテクチャをご説明しました。

ここまでにご紹介したアーキテクチャを使いこなすためには、エラーが発生した場合のハンドリングや、重複処理への対応なども考慮しなければなりません。最終回となる第 4 回目では、非同期処理を設計する際の考慮ポイントをご説明することでこれら考慮事項に対する解決策を示したいと思います。

最終回も乞うご期待ください。それではまたお会いしましょう。