プログラムとプログラムを繋ぐAmazon SQS
Amazon SQS（Simple Queue Service）は、AWSが提供している完全マネージド型のメッセージキューイングサービスです。
メッセージキューイングとは、レストランでの注文伝票の仕組みのようなものです。注文（メッセージ）を受けたスタッフが伝票（キュー）に記入し、キッチンは準備が整った時点でその伝票を処理します。この仕組みにより、混雑時でも注文を取りこぼすことなく、効率的に作業を進めることができます。
SQSは注文伝票の代わりにアプリケーション間のメッセージのやり取りを仲介し、送信側と受信側を柔軟に連携させるサービスです。送信側は受信側の状態を気にすることなくメッセージを送信することができ、受信側も自身の処理能力に合わせて受け取ることができるのが特徴です。
AWSのマネージドサービスとして提供されているため、運用作業はAWSが担当し、利用者はメッセージの送受信機能の実装に集中できます。使用した分だけの料金で利用できる従量課金制も、導入のしやすさを後押しする特徴となっています。
SQSはサーバーレスアーキテクチャを採用しているので、サーバーの準備や管理は不要です。メッセージの量に応じて自動的にスケールし、ほぼ無制限のスループットを実現します。アクセスが集中する場合でも、SQSがメッセージを一時的に保持することで、システムの安定性を確保できます。
キューには標準キューとFIFO（First-In-First-Out）キューの2種類があります。標準キューは高いスループットが特徴で、送ったメッセージがそのままの順序で届くことは保証されないものの、ほとんどのユースケースで利用可能です。一方、FIFOキューは、送ったメッセージの順序を保証する必要がある金融取引などで使用します。
また、メッセージの処理に失敗した際に別のキューに移動させるデッドレターキュー（DLQ）や、メッセージの処理を意図的に遅らせるディレイキューなど、実用的な機能も備えています。これらの機能を活用することで、より信頼性の高いシステムを構築することができます。
SQSを使ったシステムの事例
SQSは現在、AWSのサーバーレスサービスであるLambdaと組み合わせて使用されることが一般的です。この組み合わせにより、サーバー管理不要でスケーラブルなシステムを構築できます。
代表的な活用例として、IoTデバイスから受け取る大量データの処理があります。たとえば、多数のデバイスから画像データが送られてきて、それをクラウドに保存し、Webダッシュボードで確認するシステムを考えてみましょう。
従来のようにサーバーで直接処理すると、デバイスが増えるたびにサーバーの負荷が高まり、管理も複雑になります。しかし、SQSを間に置くことで、一時的にデータをキューとして保持し、Lambdaで順次処理することが可能になります。
また、ユーザーがアップロードした画像を元にサムネイル画像を作成する処理をバックグラウンドで実行したい場合、「画像をまずS3に保存し、SQSを経由してLambdaで処理する」というように処理を非同期にすることで、ユーザーは処理完了を待つことなく次の操作に進むことができます。
このように、SQSはシステムの一部に負荷が集中することを防ぎ、安定した処理を実現できるため、処理に時間のかかる作業や、大量のリクエストを安全に捌く必要がある場面で真価を発揮します。
他にも、複数のシステムを連携する際の中継点として使用したり、大量のデータを一括処理する際のバッファーとして利用したりする使い方もあります。また、近年主流となっているマイクロサービスアーキテクチャにおいても、サービス間を疎結合に保ち、柔軟なシステム構築を実現する重要な要素として注目されています。
利用時に気を付けたい「最低1回は必ず処理」の意味
SQSの重要な特徴として「At least once（アットリーストワンス）」という配信ポリシーがあります。これは「メッセージは最低1回は必ず処理される」という保証です。たとえば、100個のメッセージを送信した場合、必ず最低100回は処理されます。ただし、同じメッセージが複数回処理される可能性があることに注意が必要です。
この特徴により、メッセージの取りこぼしは発生しませんが、重複処理への対策は実装者側で考慮しなければなりません。これを「冪等性の担保」と呼び、同じ処理が複数回実行されても最終的な結果が変わらないようにする必要があります。
たとえば、アクセス数を数えるカウンターのような「1を足していく（カウントアップ）」処理はSQSには適していません。同じメッセージが2回処理されると、本来1回だけカウントすべきところを2回カウントしてしまい、正確な数値が得られなくなってしまうためです。
代わりに、データの上書き（PUT操作）や、処理済みを示すフラグを立てる方式の採用が推奨されます。また、処理対象のメッセージにIDを付与し、そのIDをもとに重複処理を防ぐ方法もあります。このように、メッセージが重複処理されても問題が起きない仕組みを作ることが、SQSを使用する上での重要なポイントとなります。
利用時に気を付けたいポイントや他のAWSサービスとの使い分け
SQSは処理を後回しにしたり、バックグラウンドで実行したりする非同期処理が得意ですが、非同期処理の実現にはSQS以外に複数のAWSサービスの選択肢があります。そのため、ニーズに合わせて用途に応じた最適なサービスを選ぶことが重要です。
たとえば、データストリーミングなどデータの即時処理が重要な場合は、シャード数（処理単位）の設定により処理速度を細かく制御できるなど、リアルタイム処理に特化したAmazon Kinesis（以下、Kinesis）の利用を検討すると良いでしょう。
また、リージョンを跨いだ処理が必要な場合はSNS（Simple Notification Service）が適しています。SNSは単発のメッセージを送って処理する用途に向いており、大量のアクセススパイクがない場合の選択肢として有効です。
SQSは従量課金制で提供され、毎月100万リクエストまでは無料利用枠の対象となります。サーバー管理が不要なマネージドサービスのため、運用コストを抑えることができるのも特徴です。
導入に際して多く聞かれる懸念は「メッセージが失われないか」「処理順序は保証されるか」といった点です。SQSは最低1回の配信を保証しており、メッセージが失われる心配はありません。また、順序の厳密な保証が必要な場合はFIFOキューを選択できます（ただし処理速度は標準キューより低下します）。
実際の導入においては、まず小規模な非同期処理から始めることを推奨します。たとえば画像処理のような負荷の高い処理を切り出すところから始めれば、段階的にシステムを改善していけます。Lambdaと組み合わせることで、最小限の実装でサーバーレスな処理基盤を実現できます。