非同期処理 - ユーザー画面はレスポンス良くしたい（2）
ELBおよびSQSを用いた非同期処理のシステム構成
便利なリクエストキューではありますが、単一のサーバーで実装してしまうと単一障害点になってしまいます。
AWSでは、リクエストキューのために、Amazon SQSというサービスを提供しています。先ほどの事例で言えば、図6のような位置でリクエストを受け付けることが可能です。
Amazon 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型）の場合、リソースの状態変化はイベントとして通知されます。このイベントを契機に後続の処理を加えることができます。
