クラウド・ネイティブのお作法（1）「非同期処理」～24時間365日ダウンタイムがゼロのシステムのために必要なこと

AWSの深いところ見せちゃいます！ by AWSクラウドサポートエンジニア　第6回

非同期処理 - ユーザー画面はレスポンス良くしたい（2）

ELBおよびSQSを用いた非同期処理のシステム構成

　便利なリクエストキューではありますが、単一のサーバーで実装してしまうと単一障害点になってしまいます。

　AWSでは、リクエストキューのために、Amazon SQSというサービスを提供しています。先ほどの事例で言えば、図6のような位置でリクエストを受け付けることが可能です。

　Amazon SQSでは、複数のサーバーにリクエストを保持し冗長化しています。また、メッセージが増加しても高スループットで処理することが可能で、簡単に使用することができます。

図6　ELB_SQS

ポーリング（pull型）とイベント（push型）

　非同期処理を実装すると、利用者は待たされることがなくなりますが、キューイングされたリクエストが実際に処理完了したか否かについては、別途確認しなければなりません。また、処理完了後に実行させたい処理もあるかもしれません。このとき、プログラム設計のアプローチとして2通り考えることができます。

　1つめのアプローチとして、データ更新を依頼したアプリケーションが自ら定期的にステータスを確認する方法が考えられます。これをポーリング、もしくは、データを引っ張ってくるという意味合いから、pull型と呼びます。

　2つめのアプローチとして、実際のデータ更新を担当するバックエンド側プログラムが、アプリケーションに対して、「データが完了した」という旨のイベント通知を行う設計も考えられます。アプリケーションに対してイベントをプッシュするという意味合いでpush型と呼びます。

AWS APIにおける非同期処理

　AWSのAPIには、同期処理を想定したAPI（同期API）と非同期処理を想定したAPI（非同期API）があります。多くのAPIは非同期処理を想定して実装されています。

　先ほどご説明した通り、非同期APIの場合、APIのレスポンス返信時点では処理は完了していないため、当該処理の完了を別途確認する必要があります。また、その確認方法として、ポーリング（pull型）とイベント（push型）が考えうることをご説明しました。

　AWSのAPIでは、ポーリング（pull型）の手法として、リソースの状態をDescribeするAPIを繰り返し発行することを想定しています。後続の処理を記述したい場合には、ポーリングを繰り返すループ処理によって状態変化を検知したのち、後続の処理を行います。

　イベント（push型）の場合、リソースの状態変化はイベントとして通知されます。このイベントを契機に後続の処理を加えることができます。