AWSのSQSとは？SQSの用語や特徴について詳しく紹介していきます！

AWSの「Amazon SQS（Simple Queue Service）」とは？

「Amazon SQS（Simple Queue Service）」とは、AWS（Amazon Web Services）社が提供している「完全マネージド型」の「メッセージキューイング（Message Queueing　※MQと略称されます）」サービスです。 インターネット上で稼働するシステムを構築する際に、主に「疎結合」と呼ばれるアーキテクチャを実現するため、システムの構成要素の一つとして利用されます。 上記の「完全マネージド型」や「メッセージキューイング」等の用語にはあまり馴染みのなく、どのような機能であるかイメージしづらいかもしれません。 この記事では、こういった用語を分かりやすく説明しながら「Amazon SQS」というAWSサービスの詳細をひもといていきます。加えて、サービスの特徴や主な機能を解説しながら、具体的な利用ケースを紹介します。

「完全マネージド型」とは？

「完全マネージド型」サービスとは、ECサイト等を運営する際に、本来であれば必要となるシステム管理業務をサービス提供側ですべて肩代わりしてくれるサービスのことです。「フルマネージド（Fully Managed）型」とも呼ばれます。 具体的なシステム管理業務の例としては、サーバやネットワーク機器の管理、OSやミドルウェアの設定、24時間365日の各種監視設定、障害時の復旧対応等、ハードウェアとソフトウェアの両面で非常に多岐に渡っています。 上記のことは一般的には、社内のシステム管理部門が従事することが多いかと思われます。これらすべての業務を内包して管理される形態を、すなわち「完全マネージド（managed：管理された）型」でサービスとして提供されています。 そのためサービス利用者は、煩雑で負荷が大きいシステム管理業務から解放され、そのサービスを利用することだけに集中でき、自社のアプリケーション開発等のコア業務に専念することが可能です。

「メッセージキューイング（MQ）」とは？

「メッセージキューイング」とは、システム間で送信するデータを一時的に溜め込む場所を設けて、そこから順次中継していく仕組みです。その場所を「キュー」、送信するデータを「メッセージ」と呼びます。 例えば、「システムA」から「システムB」にデータを送信する際に、「システムA」はキューに一旦メッセージを渡してしまい、「システムB」は任意のタイミングでメッセージをキューから取得します。つまり、キューが「メッセージの一時保管場所」のような機能を果たします。 この仕組みの利点としては、「システムA」は「システムB」のデータ受信完了まで「待ち状態」になることが避けられ、通信回線を専有する必要がなくなります。このような「バケツリレー方式」でのデータ送受信の仕組みを「非同期処理」といいます。 これと対をなす概念のデータ送受信方式としては、通信回線上の全システム間でのデータ送受信が完了するまで待つ形式を取る、一般的に「オンライン」と呼ばれる「同期処理」になります。

「疎結合」とは？

「疎結合」とは、システム間でお互いの情報をできるだけ持たないようにした独立性が高い状態のことです。 例えば、「システムA」から「システムB1」、「システムB2」…「システムB10」と10箇所へデータを送信するケースでみてみましょう。 この場合に「システムA」は、送り先「システムBx」の10個のURL情報をすべて知っている必要があります。この状態を「密結合」と言います。 この「密結合」の問題点としては、「システムBx」側でURLの変更があった場合に、「システムA」側でURLの情報を早急に更新する必要があります。「システムBx」にトラブルが発生して他のシステムへの即時切替え対応が必要になった場合に、障害復旧に遅くなってしまいます。 そこで、「システムA」と「システムBx」の間に「キュー」を配置して、そこでメッセージを一時的に預かるようにします。こうすることで「システムA」は、「キュー」のURLだけを把握していれば良くなり、「システムBx」側の設定変更等の影響を受けない「疎結合」なアーキテクチャとなります。

AWSの「Amazon SQS」の特徴について

それでは「メッセージキューイング」のAWSサービスである「Amazon SQS（キュー）」の主な特徴について解説していきます。 主な特徴としては、データ送信側アプリケーションである「プロデューサー」が「Amazon SQS（キュー）」に「メッセージ」を送り、データ受信側アプリケーションの「コンシューマー」が「Amazon SQS」からメッセージを取得するという通信形態を取ります。 「Amazon SQS」のキューには、「標準キュー」と「FIFOキュー」の2種類のサービスがあります。それぞれのキュー方式は仕様が異なり、メッセージの処理方法によって使い分ける必要があります。キューは、メッセージを14日間まで保存することが可能です。 これらの用語について詳しく確認していきましょう。

「メッセージ」とは？

「メッセージ」とは、「プロデューサー（※後述します）」が生成して送信するデータのことです。このデータサイズは256KBまでで、サイズ上限の指定が必要になります。 参考までに、「Amazon SQS」への「メッセージ登録のコード例（プロデューサー側）」と「メッセージ取得のコード例（コンシューマー側）」を示します。 ※「AWS SDK（ソフトウェア開発キット） for JavaScript」を用いた場合 ＜SQS へのメッセージ登録コード（プロデューサー側）＞ require ‘aws-sdk’ sqs = Aws::SQS::Client.new(region: ‘ap-northeast-1’) resp = sqs.send_message_batch({ queue_url: URL, entries: [ { id: ‘msg1’, message_body: ‘Hello world’ }, { id: ‘msg2’, message_body: ‘How is the weather?’ } ], }) ＜SQS からのメッセージ取得のコード例（コンシューマー側）＞ require ‘aws-sdk’ sqs = Aws::SQS::Client.new(region: ‘ap-northeast-1’) resp = sqs.receive_message(queue_url: URL, max_number_of_messages: 10) resp.messages.each do |m| puts m.body end

「プロデューサー」とは？

「プロデューサー」とは、「Amazon SQS（キュー）」に「メッセージ」を送信する側のアプリケーションやシステムです。 プロデューサーとなるアプリケーションは、各種開発言語「AWS SDK（ソフトウェア開発キット）」を利用して開発します。

「コンシューマー」とは？

「Amazon SQS（キュー）」の「メッセージ」を受け取る側のアプリケーションやシステムのことです。 自動的に受け取るのではなく、キューに対してメッセージが溜まっていないかを定期的に確認しにいき、メッセージがあれば取得するという方式（「ポーリング」という動作です）を取ります。 キューから送られてくるメッセージの増減に応じて、コンシューマーの数も増減させるといった、いわゆる「スケーラブル」なアーキテクチャとするのが一般的です。

「標準キュー」とは？

「標準キュー」とは、メッセージを順不同（配信順序が変わることがある）で送るキュー方式で、メッセージが重複する（2回以上送ってしまう）可能性があります。 つまり、「1回だけ」「順番通りに」メッセージを送るという用途には向きません。しかし、そういった制御がない分だけ高速なキューイング処理が可能となっています。 従ってメッセージの重複や順番を制御するには、アプリケーション側で一意な連番を付加して送るなどの対応が必要となります。

「FIFO（先入れ先出し）キュー」とは？

「FIFO（先入れ先出し）キュー」とは、メッセージを「1回のみ」配信し、順序性も担保されるというキュー方式です。 その名の通り、受け取ったメッセージを受け取った順に送るよう制御されています。その分だけ「標準キュー」より処理速度が劣ります。

「標準キュー」と「FIFOキュー」の違い

AWSの「Amazon SQS」で用意されている2つのキューの主な違いをまとめてみましょう。 （1）配信方式 標準キュー：少なくとも1回（2回以上もあり） FIFOキュー：1回のみ （2）配信順序 標準キュー：順番が変わる可能性がある FIFOキュー：順序性を保つ （3）配信順序（100万件を超えた場合） 標準キュー：100万件ごとに0.40USD FIFOキュー：100万件ごとに0.50USD

耐障害性の向上

これまで述べてきたとおり、「Amazon SQS」を活用して「疎結合アーキテクチャ」にすることで耐障害性が向上します。 具体的には、コンシューマー側のアプリケーションが動作するサーバが一時的にダウンしていても、プロデューサー側のアプリケーションは影響を受けなくなります。

AWSサービスを活用した「Amazon SQS」の利用ケース

それでは、どのような利用ケースで「Amazon SQS」を利用するかを具体例で確認しましょう。

具体例での処理手順について

想定例として、ユーザがECサイトで商品を注文し、最終的に注文が確定するまでの手順を以下に示します。 ＜例：ECサイトで商品を注文する場合＞ ①ユーザが、ECサイトで商品を注文する ②ECサイトのシステムからユーザに「受注通知」を一旦返却する（※注文は仮確定状態） ③ECサイトのシステムから「倉庫システム」に「在庫照会（倉庫、発送日、配達日数等）」を行う（時間がかかる重い処理） ④「倉庫システム」からECサイトに「在庫確定通知」を送る ⑤ECサイトからユーザに対して「注文確定通知」を送る ここでポイントになるのは、上記②で「受注通知」をユーザに一旦返却している点です。 ECサイトのシステムは、「在庫照会」のメッセージを一旦キューに登録してしまい、「倉庫システム」からの返事を待たずに、ユーザに受注通知だけ送ってしまいます。 ユーザは、「在庫照会」という重い処理結果を待たずに、注文した結果がどうなったかを知ることができます。

「Amazon SNS」との違い

最後に、「Amazon SNS（Simple Notification Service）」という「Amazon SQS」によく似たAWSサービスがあります。こちらとの違いについて簡単に触れていきます。 「Amazon SQS」では、コンシューマーがキューにメッセージを取りに来る「ポーリング方式」でした。一方、「Amazon SNS」は、キューからメッセージ受信側（ここでは「サブスクライバー」と言います）にメッセージを送る、「プッシュ方式」を取ります。 「プッシュ方式」を取る場合のメリットとしては、キューを定期的に確認する処理が不要となる点と、キュー側のタイミングでメッセージを送れる点等があります。

「Amazon SQS」サービスの今後

「Amazon SQS」のような「メッセージキューイング」は、30年以上前から使われているレガシーなシステム方式です。特にAWS上で疎結合アーキテクチャのシステムを構築する際には欠かせない方式と言えます。 今後も様々なシステムで継続的に利用されるサービスですので、AWS上でのシステム構築の際にはご利用を検討してみてはいかがでしょうか。]]>