「メッセージキューイング」という言葉をご存知でしょうか？
ある処理から別の処理を起動したい、でも毎回引数（メッセージ）がちがうし、連続して別の処理へ指示が発生しても順番は守りたい。そもそも「別の処理」とは別システム内、別サーバーにあるし・・・という場合がよくあります。
テキストファイルに引数を書いてメッセージを渡してもよいのですが、その方法ではどこまで終わったか管理するのが難しいし、他のプログラムや悪意のある人が内容を書き換えてしまうことも考えられます。
そんなときに使うのが、メッセージキューイングという方法です。AWSでは、メッセージキューイングが簡単に実装できるサービスがあります。
それが、今回解説するAWS Simple Queue Services (SQS)です！処理と処理の連携や、システム間連携でお悩みのエンジニアの方々、必見です。
Amazon Simple Queue Service (SQS)とは
AWS SQSを語る前に、メッセージキューイング（MQ）について触れておきましょう。
メッセージキューイング（MQ）とは？
冒頭で触れた「ある処理から別の処理を起動する」に沿って説明します。以降、ある処理を処理1、別の処理を処理2とします。
処理1と処理2について、以下の前提条件を仮定します。
- 処理1は処理2に対し、引数や値などなどの何らかの情報を渡す
- 処理1は処理2を何度も連続して呼び出す
- 呼び出し順に処理する
処理1が処理2を起動するときの指示や渡す情報を「メッセージ」と呼びます。そしてメッセージは発生順に処理されなければいけないので、ちょうど筒状の入れ物にメッセージを入れていき、先に入れたものから押し出されて処理2へ渡される、と表現できます。先入れ先出し（First-In First-Out：FIFOと省略することもある）といいます。
筒の中身、つまりメッセージが筒に入り順番を待って連なっていることを「キュー」といいます。後ろからメッセージをキューへ入れていき（キューイングといいます）、入れた順に処理をする、この仕組みをメッセージキューイング（MQ)というのです。
処理2は、自分からキューを参照して、次に処理するメッセージはどれかを確認する必要があります。この作業をポーリングと呼びます。
MQを導入するメリット
MQを導入すると、処理間・システム間の連携が疎になります。
先の例でいうと、処理1はメッセージをキューイングさえしてしまえば終わりです。処理2がメッセージを取得できない状態だったとしても、処理1には関係がありません。処理2のトラブルにひきづられて処理1がダウン、ということもありません。
もちろん、処理1は処理2の戻り値をとったり、といった互いの関連性をもたせるような設計は避けるのが前提です。
そもそも「メッセージ」とは何か
メッセージとは何を意味するのでしょうか？
先の例でいうと、メッセージとは処理1が処理2に渡すものです。例えば処理2が起動するにあたり何らかの引数が必要なら、それを渡さなくてはなりません。処理1がメッセージをキューイングするときに、その引数をメッセージに格納し、処理2がそれを拾う、といった感じです。
単一の値を渡すときは何も考える必要はないのですが、複数の値を渡すときはJSONで渡せば何かと便利で今風ですね！
そして、Amazon SQSとは何か
MQについてひと通り解説したところで、今度はAmazon SQSのメリットを考えてみましょう。
Amazon SQSは、AWSが提供するMQサービスです。
前述のMQとしての最低限の機能はもちろん、AWSのサービスであるメリットを活かして、他のサービス（AWS CloudWatch等々）や、AWS内のID体系との連携も可能です。また、AWSの提供するSDKを利用して、さらに便利に活用できます。
Amazon SQSのメリット
簡単に導入できる、コードを試せる
それでは、早速試してみましょう。
AWSのコンソールから、Amazon SQSを選択し、必要な項目を入力していきます。難しければ、英語ながらチュートリアルが用意されています。
でも、何をインストールして、というよりどうやって導入するんだろう…そう心配になった方もおられるでしょう。心配はまったく不要です！
前払い金や手続きは一切不要で、何もインストールする必要はありません。サーバーインスタンスすら不要です！本当に試すだけなら、手動で（つまりAWSのマネジメントコンソールから）メッセージをキューイングできるし、ポーリングだって手動でできます。
それ以上試したい、つまり自分でコードを書いてメッセージをキューイングしたり用が済めば削除したり、といったことを試したい方ももちろん大丈夫です。
AWSではすでにAmazon SQSの開発用SDKを用意しています。Ruby、JavaScript、.Net、Python、Java、PHPで対応可能です。これらを使ってコードレベルで試すことも可能です。
絶対転送します！確実なメッセージ配信
AWSは、確実なメッセージ配信を約束しています。いかなる量のメッセージでもロスすることはありません。1つのメッセージは複数のコピーが作成され、複数のアベイラビリゾーンに配置して冗長化されています。必要に応じてユーザーがそれらを利用することも可能です。
誰にも見せません！機密保護の観点
Amazon SQSに保存されたメッセージは、暗号化して保存されます。システム間や機能間で、機密性の高いメッセージのやりとりが可能です。
Amazon SQSでできること
ここではAmazon SQSの機能面を重視して解説しましょう。
何もインストールしません
Amazon SQSを導入するにあたって、ミドルウェア等々、何もインストールする必要はありません！従来であればなにかミドルウェアをインストールして、保守して、ライセンス数をしたり運用体制を構築したり、ライセンスが切れたら継続契約をして・・・となりますよね。
その点、Amazon SQSはAWSマネジメントコンソールで設定するだけです！
自動でスケーリング
Amazon SQSは、自動でスケーリングされます。よって事前のキャパシティ設計や監視、キュー数に応じたスケーリングなどは一切不要です！キューの急増が起こった際でも、何もせずに良いのは大きいですね。
他のサービスと一緒にキー管理
Amazon SQSはAWS Key Management Service (KMS) に対応しているので、SQSメッセージを保護するキーと、その他のAWSサービスにおけるリソースを保護するキーを一括して管理できます。
それだけでなく、暗号化キーが使用されるたびにAWS CloudTrailに記録されます。その記録をさまざまな監査に対する証跡としても利用できますね。
先入れ先出しでなくともよい
Amazon SQSはMQ方式を踏襲しているためFIFO（先入れ先出し）という解説をしました。しかし、順番は特に重要な問題ない、という場合は順不同にすることもできます。これを標準キューといいます。
料金
毎月最初の100万件のリクエストまでは・・・なんと無料です！それ以降の料金は、すべてのリージョン共通で同じです。
標準キューは100万件あたり0.40USD、つまり0.00000040 USD/リクエストです。しかも単位はリクエストです。1リクエストに10メッセージまで含めることができます。標準キューは100万件あたり0.50USD、つまり0.00000050 USD/リクエストです。
基本的な使い方
では、実際にメッセージをキューイングしてみましょう。まずはキューを作成するところからです。キューとは、以下の図の筒状の場所にあたります。
キューの作成は、キュー名やタイプ（標準かFIFOか）、必要に応じてその他詳細を入力します。
できました。以下のチェックボックスの付いた行です。
ここにメッセージを送信してみましょう。先ほどの絵でいうと、ちょうど数字の箱をキューに送る操作に相当します。
次に、たまったメッセージを確認しましょう。以下の選択肢の中の「メッセージの表示/削除」から可能です。
これを選択すると、今からポーリングを開始するかどうかを確認するメッセージが開きます。
ポーリングが終了後、キューイングされているメッセージが表示されます。
同じPCから一気にやったのでイメージがつきにくいですが、本来はこの一連の流れを別サーバーや別システム間で、さらにAPI経由で行うのです。
メッセージの受け渡しのイメージがつきましたでしょうか？
まとめ
この記事では、Amazon SQSを解説しました。システム間連携や機能間連携で、メッセージの受け渡しにお困りの方、ぜひ本記事を参考にして、Amazon SQSの導入を検討してみてくださいね。
