検討ポイントを挙げる前に、第 3 回 で示した AWS サービスを活用したアーキテクチャの中で、特に非同期処理の部分をおさらいします。

(1) EC サイトを利用しているエンドユーザーは、ブラウザやモバイルアプリの画面上から購入したい商品を選択し、注文処理サービスのインターフェースである Amazon API Gateway (以下、API Gateway) で提供されている API を呼び出します。

(2) 呼び出された API に対しての情報が注文完了トピックである Amazon SNS へとメッセージが送られます (その後 API Gateway は API レスポンスを返却します)。

(3) 配送・メール通知・請求/ポイント計算処理サービスの各 Amazon SQS へ注文完了トピックからメッセージが送信されます。

(4) AWS Lambda が各キューで受信したメッセージを自動でポーリング後、そのメッセージに対して処理を行います。

このアーキテクチャを題材として非同期処理での設計上の検討ポイントをみていきましょう。

また、第 3 回 でも紹介されていますが、メール通知処理サービスのようにプッシュ型でエンドユーザーに通知するといった方法があります。加えて、チャットのようにニアリアルタイム性が求められる場合には、双方向通信プロトコルを実現する API Gateway での WebScoket や AWS AppSync でのサブスクリプション 利用も検討ください。

ただし、順序性を検討する際は「ビジネス上、順序を守らないといけない理由」を再度確認してみてください。順序性を保つための仕組みを導入すると開発・運用コストやメンテナンス性に影響がでることがあります。したがって、ビジネス上必須でなければ、シンプルなアーキテクチャを目指し、過度な複雑さを回避することも選択肢となります。

ここでは、順序性を保つための例として、先着順でポイントを付与するポイント計算処理サービスを考えてみます。商品購入者への通常のポイント付与に加えて、対象商品を購入した先着 1000 名のユーザーにはさらにポイントを付与するとしましょう。ただし、キャンペーンの追加ポイントの合計は 100 万ポイントとします。

このような場合に、順序性が担保されていないと、購入順序でいえば先だったユーザーがポイント計算処理サービスにおいては最終的に合計ポイントに達してしまい追加ポイントが付与されないというケースが存在してしまいます。

詳細は メッセージに関するクォータ のメッセージのスループットを確認ください。ただし、一部リージョンでは FIFO キューの高スループット も対応し始めており、今後選択肢の幅を広げてくれるかもしれません。さらに、コンシューマが処理できないメッセージがあった際には以降のメッセージに対する処理がブロックされてしまいます。以下「メッセージの滞留と鮮度」でお伝えするメッセージの待避によって対応できますが、待避されたメッセージの順序性も検討いただければと思います。

また、第 3 回 で紹介された Amazon Kinesis Data Streams など別の AWS サービスを利用することでもこの問題に対応することができます。

結果整合性 (Eventual Consistency) とは、分散システムの各データストアに対してある項目のデータ更新が発生した場合に、それぞれのデータストアで一時的な不整合は発生しつつも、最終的には一貫性のある状態になる性質を意味します。

今回のワークロードではファンアウトされたメッセージに対して各サービスのコンシューマとなる AWS Lambda がデータストアの Amazon DynamoDB テーブルを更新しますが、これらに対して結果整合性を検討する必要があります。また、データストアの更新処理が正常に実施されずに、恒久的なデータ不整合が発生してしまう場合があります。これを解消する手段のひとつに補償 (補正) トランザクション (Compensating Transaction) があります。補償トランザクションでは、データ不整合が発生した場合に各データストアに対して打ち消し処理を行うためのイベント (今回のアーキテクチャでは、Amazon SNSやAmazon SQSにおけるメッセージ) を発行し、このイベントに対してコンシューマが一貫性のあるデータの状態にする処理をことができます。

次はメッセージの滞留と鮮度です。非同期処理では処理の契機となるメッセージが「適切な時間内で処理されているか」、「もう処理する必要の無い古いメッセージが残存していないか」ということが重要となってきます。そのため、該当メッセージが滞りなく処理されていることの確認や古いメッセージに対しての対応が必要となります。

まず、古いメッセージへの処理を回避するためにもメッセージの保存期間を適切に設定してください。例えば、Amazon SQS では メッセージの保持期間 として 1 分から最大 14 日間までメッセージを保持するように設定できます。また、この設定により滞留を防ぐことにも繋がります。

滞留が続くようであれば、バックエンドの増強などの検討が必要となってくるかもしれません。しかし、この滞留の原因はバックエンドのパフォーマンスによるものだけとは限りません。

例えば、Aamazon SQS から受信したメッセージが想定外のデータ形式により処理が失敗したり、連携するシステムやサービスにてリクエストを受け付けなかったり、そもそもアプリケーションの不具合等、様々なケースがあります。メッセージが処理されずに滞留するケースは様々な原因があるため、滞留によるスループットの低下や無駄なリソース消費を避けるためにも、メッセージの待避を検討する必要があります。

最後はロギングです。もちろん、各コンポーネントでログ出力は対応済みだと思います。ただし、非同期処理では分散コンポーネントであるが故に、出力されたログを使ってワークロードに対し一貫性のある処理状況の把握や管理が困難となります。そのためログ集約の検討が必要となってきます。このログ集約で重要となってくるのはログのデータ容量や出力リクエストに対するスケーラビリティが高いストレージの選択です。AWS では Amazon CloudWatch や Amazon S3 が候補となってくるのではないでしょうか。

ただし、Amazon CloudWatch と Amazon S3 にはそれぞれ異なる特性があります。例えば、Amazon CloudWatch はリアルタイムでログ参照や検索を実施するのが比較的簡単ですがログ分析などは不向きです。一方、Amazon S3 はログとして保存されているオブジェクトをダウンロードする、もしくは Amazon Athena などその他サービスを介して参照・検索を実施しなければなりませんが、ログ分析用のデータソースとして他 AWS サービスとの連携をサポートしています。

そして、もうひとつ重要となってくるのが分散トレーシングです。分散トレーシングとは一連の処理をユニークに識別するためのトレース ID を発行し、トレース ID をもとに各サービスでのログなどを統合・可視化することを意味します。先述のとおり、非同期処理処理ではそれぞれのコンポーネントが処理を実施するために、ワークロードをエンドツーエンド (End to End、E2E) で把握・管理することが難しいです。そのため、この分散トレーシングが重要となってきます。この分散トレーシングを導入する場合、AWS サービスでは AWS X-Ray が役立ちます。一連の処理におけるコンポーネントの繋がりを可視化したり、ターンアラウンドタイム (Turn Around Time、TAT) や各コンポーネントにおける処理時間の表示、詳細なログデータへのドリルダウンの提供、サンプリングによる取得量調整といったアプリケーションパフォーマンス管理 (Application Performance Management、APM) の機能を享受することができます。また、AWS X-Ray を利用した場合、自主的に発行しなければならないトレース ID を自動的に管理してくれます。

ロギングや分散トレーシングの導入によって、みなさまが非同期処理で直面するワークロード上の様々な問題に対応するため強力なサポートを提供してくれるはずです。そして、この情報をもとに原因調査や対策の実施、アーキテクチャのさらなる改善に役立てていただければと思います。

非同期処理における考慮事項と題して 5 つのポイントに絞った内容をお伝えしました。

最後に、今回のアーキテクチャで利用されている Amazon SQS や Amazon SNS において補足的な内容を説明していきます。

非同期処理とは少し観点がズレますが、今回のような Amazon SQS や Amazon SNS を利用したアーキテクチャにて標準キューや標準トピックを選択した場合、メッセージは少なくとも 1 回 (At-least once) の配信となります。そのため、同一メッセージが 2 回以上配信された場合にも同一の結果を保証しなければなりません。これを 冪等性 (idempontence) と言います。配送処理サービスを例にとって考えると、もし同一メッセージが 2 回以上配信された場合に同じ購入商品が 2 回届いてしまう可能性があります。そのため、標準キューや標準トピックを利用した際にも冪等性を担保されるアーキテクチャを考えていきます。

ここでは Amazon SQS や Amazon SNS で標準キューや標準トピックを利用していた場合の冪等性の担保についてお伝えしましたが、FIFO キューや FIFO トピック、Amazon Kinesis Data Streams では必ず 1 回 (Exactly-Once) の配信が担保されます。そのため、これらを利用することでメッセージブローカー側に冪等性担保の対応策を講じることも可能となります。

また、AWS Lambda などのリトライが発生した際にも重複処理が行われる可能性があるので、同様に冪等性の検討を実施いただければと思います。

いかがでしたでしょうか。最終回となる今回は、非同期処理をさらに使いこなしていただくための設計上の検討ポイントとその対応内容を解説しました。

同期処理と比較すると、非同期処理は各サービスが独立性をもって稼働しているため、設計における検討事項はより複雑になりますが、一方で、拡張性や可用性、さらにサービスをデプロイする上での保守性など多くのメリットを受け取ることができます。今回説明した内容が、非同期処理を導入する上での一助になれば嬉しく思います。

最後になりますが、「非同期処理を使いこなそう !」と題した全 4 回の連載にお付き合いいただきありがとうございました。