Amazon SQS のFIFO機能が東京リージョンでもご利用いただけるようになりました

Amazon SQS のFIFO機能が東京リージョンでもご利用いただけるようになりました:

みなさん、こんにちは。アマゾン ウェブ サービス、プロダクトマーケティング

エバンジェリストの亀田です。

非常に多くのユーザーさんからご要望をいただいていた Amazon SQS のFIFO (First In First Out)機能が東京リージョンでご利用いただける用になりましたのでお知らせいたします。

Amazon SQSの特徴

Amazon SQSは完全マネージド型のメッセージキューイングサービスで、マイクロサービス、分散システム、およびサーバーレスアプリケーションの切り離しとスケーリングを可能とします。

AWS上でのアプリケーション設計において、非常に重要な役割を果たすサービスである一方、そのコンセプトなどが従来の一般的なWEBサービス（以下のような構成です）の設計に頻繁に用いられるものではないことから、使い方のイメージが湧きづらく敬遠されるケースもあります。

非常に良いサービスであり、コストの適正化とシステムの耐障害性を実現することができる可能性のあるサービスですので、少しその特徴を説明します。

コストの適正化：

上記のアーキテクチャを取る場合、ユーザーからのリクエスト数が増えれば増えるほど、WEB、DBともに求められるスペックは比例して向上していきます。これは、すべてのリクエストに対して同期処理、リアルタイムでレスポンスを出力しようとするためです。WEBサービスにおいては、すべてのリクエストが必ずしも同期処理、リアルタイムでのレスポンス出力が必要ないケースがあります。

ＥＣサイトにおけるユーザーからの注文等がその一例です。ユーザーからの注文を受け付けた時点で、画面には「注文を受け付けました。ありがとうございました」と表示させ、後ほどメールやアプリへのプッシュ通知で「注文を確定しました」という連絡をユーザーへ行う実装などはよくあります。

この場合、上記のＷＥＢをさらに2階層に分割し、

• １階層目：ユーザーからのリクエストを受け付ける。
  
  • SQSへリクエストを書き込む
  • ユーザーへリクエスト受付を行った旨をレスポンスで戻す。
• 2階層目：SQSに記載されているリクエストを処理する
  
  • SQSからリクエストを読み込む
  • リクエストを処理ユーザに非同期で処理結果を返す。

とすることができます。この場合、ユーザー数、リクエスト数の増加に応じて求められるスペックの向上が必要なのは、1階層目だけであり、2階層目は自身のコンピュートリソースの状況に応じて任意のタイミングで処理を行うことができるため、システムのサイジングを適切に保つことができます。（もちろんSQSへ書き込まれるリクエストが処理待ち状態で滞留すればするほど、ユーザーからは処理確定の遅延にみえてしまいますので、ある程度のリソース増強は必要になっていきます。）

耐障害性の向上：

SQSを採用したアーキテクチャは耐障害性の向上も見込むことができます。SQSは完全マネージド型サービスであり、書き込まれたメッセージが失われることはないため、システム障害においても、SQSからデータを取り出すという処理部分から再開させることで、耐障害性が向上します。

SQS FIFOの特徴

従来のAmazon SQSは、書き込まれたメッセージの配信順序はベストエフォート型であり、「少なくとも最低1回の配信」をサポートしておりました。このため、順番の入れ違いや同じメッセージの複数回配信はアプリケーション側で冪等性を確保しておく必要があり、それらが大きい課題となる場合Amazon Kinesis Data Streamsの利用などが検討されるケースもありました。

新しいSQS FIFO キューでは、「メッセージが送信される順序のとおりに 1 回のみ確実に処理」されるようになるため、アプリケーションでの実装におけるこの考慮点が解消されることとなります。

FIFOキュー利用の注意点

SQS FIFOキューは従来のSQS標準キューからの移行をサポートしておらず、新規でキューの作成が必要となります。

デフォルトでは、FIFO キューはバッチ処理により 1 秒あたり最大 3,000 件のメッセージをサポートします。制限の引き上げをリクエストする場合は、サポートリクエストを提出してください。

バッチ処理なしでは、FIFO キューは、1 秒あたり最大 300 件のメッセージ (1 秒あたり 300 件の送信、受信、または削除オペレーション) をサポートします。

– プロダクトマーケティング エバンジェリスト 亀田