Amazon Simple Queue Service (Amazon SQS) はメッセージキューを利用するためのウェブサービスです。メッセージキューでは、処理されるまでメッセージが保存されます。Amazon SQS を使うと、どのコンピュータでも実行できるメッセージキューアプリケーションを短時間で構築できます。

Amazon SQS には、信頼性、セキュリティ、スケーラビリティに優れたホスト型キューイングサービスが用意されており、コンピュータ間で転送されるメッセージが保存されます。 Amazon SQS を使うと、分散されたさまざまなアプリケーションコンポーネント間でデータを移動できます。メッセージを失うことはなく、また各コンポーネントを常に利用可能にしておく必要もありません。 AWS Key Management Service (AWS KMS) と統合された Amazon SQS のサーバー側の暗号化 (SSE) を使用して、アプリケーション間で機密データをやり取りできます。

Amazon SQS は、Amazon Elastic Compute Cloud (Amazon EC2) や AWS インフラストラクチャのその他のウェブサービスと緊密に連携動作し、独立したコンポーネントを使った分散アプリケーションの構築に役立ちます。

Amazon SQS では、異なるアプリケーション要件にあわせて 2 つのキュータイプを提供しています。

標準キュー
Amazon SQS のデフォルトのキューの種類は標準です。標準キューでは、1 秒あたりのトランザクション数はほぼ無制限です。標準キューではメッセージが少なくとも 1 回配信されることが保証されます。ただし (高いスループットを可能にする、徹底して分散化されたアーキテクチャであるために) ときとして、メッセージのコピーが乱れた順序で複数配信されることがあります。標準キューでは、メッセージが通常は送信されたのと同じ順序で配信されるようにする、ベストエフォート型の順序付けが行われます。

FIFO キュー – 新規
FIFO キューは標準キューを補完します。このキュータイプの最も重要な特徴は、FIFO (先入れ先出し) 配信と確実な 1 度の処理です。メッセージが送信または受信された順序は厳密に保持されて、メッセージは 1 度配信されるとユーザーがそれを処理して削除するまで使用可能な状態に保たれ、キューに重複が入り込むことはありません。また、FIFO キューは、1 つのキュー内で複数の順序付けされたストリームを可能にするメッセージグループにも対応しています。標準キューのすべての機能が提供されますが、API アクションごとに 1 秒あたり 300 件のトランザクション (TPS) 制限が適用されます。

 

AWS を無料でお試しください

まずは無料で始める »
またはコンソールにサインイン

AWS 無料利用枠には、Amazon Simple Queue Service(SQS)でのリクエスト 100 万件が含まれます。

AWS アカウント作成の流れはこちら »

Capital One が Amazon SQS を使用してコアのバンキングアプリケーションをクラウドに移行した方法について紹介します。

sqs_thumb_reInvent2016-migrating-ent-messaging

Amazon SQS は AWS Management Console から簡単にアクセスできます。ユーザーは、ポイント・アンド・クリックのウェブベースのインターフェイスで Amazon SQS を設定・管理できます。

Amazon SQS は、使いやすく、柔軟性の高いシンプルなインターフェイスを採用しています。以下のリクエストが提供されています。

ベーシックなメッセージオペレーション

  • SendMessage: 指定されたキューにメッセージを送信します。
  • ReceiveMessage: 指定されたキューから 1 つ以上のメッセージを返します。
  • DeleteMessage: 指定されたキューから以前に受け取ったメッセージを削除します。
  • ChangeMessageVisibility: 以前に受け取ったメッセージの可視性タイムアウトを変更します。

バッチ処理によるメッセージオペレーション

  • SendMessageBatch: 指定されたキューに複数のメッセージを送信します。
  • DeleteMessageBatch: 指定されたキューから以前に受け取った複数のメッセージを削除します。
  • ChangeMessageVisibilityBatch: 以前に受け取った複数のメッセージの可視性タイムアウトを変更します。

ベーシックなキューの管理

  • CreateQueue: お客様の AWS アカウントで使用するキューを作成します。
  • ListQueues: 既存のキューをリストアップします。
  • DeleteQueue: キューの 1 つを削除します。
  • PurgeQueue: キュー内のすべてのメッセージを削除します。

詳細なキューの管理

  • SetQueueAttributes: 可視性タイムアウト (メッセージが読まれた後にロックされ読めなくなるまでの時間の長さ)、遅延の値、またはデッドレターキューなどのパラメーターによりキュー設定を管理します。
  • GetQueueAttributes: 可視性タイムアウト、キュー内のメッセージ数、または最大メッセージサイズといったキューについての情報を取得します。
  • GetQueueUrl: キューの URL を取得します。
  • AddPermission: 指定されたキューについて、別の AWS アカウントのために共有するキューを追加します。
  • RemovePermission: 指定されたキューのために共有しているキューから、AWS アカウントを削除します。
  • ListDeadLetterSourceQueues: デッドレターキューに添付されたキューのリストを表示します。

詳細については、Amazon SQS API Reference を参照してください。

Amazon SQS に格納されているメッセージには、決められた有効期間があります。これは管理しやすいものであると同時に、すべてのメッセージの処理を保証するものです。

  1. メッセージを送信するのに必要なシステムが Amazon SQS キューを選択し、SendMessage を使用して新規メッセージを追加します。
  2. メッセージを処理する別のシステムは、さらに多くのメッセージを処理する必要があります。そのため ReceiveMessage を呼び出し、このメッセージが返されます。
  3. ReceiveMessage によってメッセージが返されると、可視性タイムアウトが終わるまで、それがその他の ReceiveMessage によって返されることはありません。これによって、複数のユーザーが同一のメッセージを同時に処理しないようにすることができます。
  4. メッセージを処理するシステムがこのメッセージの作業を無事に終了すると、DeleteMessage が呼び出されます。これはキューからメッセージを削除するので、他のシステムがそれを処理することはありません。このシステムがメッセージの処理に失敗すると、可視性タイムアウトが終了次第、別の ReceiveMessage 呼び出しによって読み込みが行われます。
  5. ソースキューにデッドレターキューを関連付けておくと、指定した最大配信試行回数に達するとメッセージはデッドレターキューに移動されます。
  • 開発者が作成できる Amazon SQS キューの数に制限はなく、メッセージ数についても無制限です。
    • キューは、どのリージョンでも作成できます。
    • メッセージペイロードには、最大 256 KB のテキストを任意のフォーマットで含めることができます。ペイロードの 64 KB の「チャンク」が、1 つのリクエストとして課金されます。例えば、256 KB のペイロードを持つ単一の API コールは、4 つのリクエストとして課金されます。
    • 複数のメッセージ(最大 10 個または 256 KB まで)をバッチとしてまとめて送信、受信、または削除できます。バッチの場合も、料金は単一メッセージと同じです。つまり、バッチを利用すると、SQS のコスト効果がさらに高くなる可能性があります。
    • 256 KB を超える大きさのメッセージを送信する場合、Amazon SQS Extended Client Library for Java を使用できます。この場合、メッセージペイロードの保存に Amazon S3 が使用されます。  そのメッセージペイロードへの参照が SQS によって送信されます。
    • ロングポーリングによって、外部からのポーリングが削減されるため、コストを抑制しながら新しいメッセージをできるだけ迅速に受信できます。キューが空の場合、ロングポーリングリクエストから次のメッセージが到着するまで、最大で 20 秒かかります。ロングポーリングリクエストのコストは、通常のリクエストと同額です。
    • メッセージは、最大14日間キューに保持することができます。
    • メッセージは、送信と読み込みを同時に行うことができます。
  • メッセージが受信されると、処理されている間は「ロック済み」となります。これは他のコンピュータが、メッセージを同時に処理しないようにするためです。メッセージの処理が失敗すると、ロックが解除されてメッセージが再度利用可能になります。アプリケーションが処理にさらに時間を必要とする場合は、「ロック済み」のタイムアウトは、 ChangeMessageVisibility オペレーションで動的に変更することができます。
  • 開発者は匿名で、または特定の AWS アカウントを使用して、Amazon SQS キューを安全に共有できます。 キューの共有は、IP アドレスや時刻によっても制限することができます。
  • 新着!サーバー側の暗号化 (SSE) により、AWS Key Management Service (AWS KMS) で管理されたキーを使用して、Amazon SQS キューのメッセージの内容を保護できます。メッセージは Amazon SQS で受信され次第、SSE によって暗号化されます。 メッセージは暗号化された形式で保存され、権限を持つユーザーに送信された場合にのみ Amazon SQS によって復号されます。
  • Amazon Simple Notification Service (SNS) と組み合わせることで、開発者は同一のメッセージを複数の SQS 標準キューに "ファンアウト" できます。ファンアウトの場合、ある SNS トピックに公開されるメッセージが複数の SQS 標準キューに並列的に配信されます。  ファンアウトを使用することで、開発者は並列非同期型の処理を利用するアプリケーションを構築できます。  例えば、開発者は新しい画像がアップロードされるごとに、トピックにメッセージを発行できます。  それぞれ別のキューからの読み取りを行う独立した複数の処理によって、サムネイルの生成、画像認識の実行、および画像のメタデータの保存を行えます。現在、SNS は FIFO の順序付けに対応していません。FIFO キューへのファンアウト自体がサポートされていません。
  • 開発者は、スタックしたメッセージ (コンシューマーでの処理が成功しなかったメッセージ) をデッドレターキューで処理できます。最大受信回数を超えたメッセージは、元のキューと関連付けられているデッドレターキュー (DLQ) に移動されます。開発者は DLQ 用のコンシューマープロセスを別に設定できます。そうすることにより、メッセージがスタックした原因の分析と把握が容易になります。DLQ はソースキュー (標準または FIFO) と同じタイプである必要があります。

Amazon SQS メッセージキューイングは、他の AWS サービス (RedshiftDynamoDBRDSEC2ECSLambda、および S3 など) とともに使用できます。これにより、配信されたアプリケーションのスケーラビリティと信頼性がさらに向上します。以下に、一般的な設計パターンの例をいくつか示します。

  • ワークキュー: 配信されたアプリケーションのコンポーネントから、同じ量の作業をすべて同時に処理することができないものを切り離します。
  • オペレーションのバッファリングとバッチ化: アーキテクチャにスケーラビリティと信頼性を追加します。また、メッセージを失わず、低レイテンシーを維持したまま、一時的なボリュームスパイクを均一化します。
  • リクエストのオフロード: リクエストをキューに追加することによって、リクエストをキューに追加することによって、処理の遅いオペレーションをインタラクティブなリクエストパスから除外します。
  • ファンアウト: SQS と Simple Notification Service(SNS) とを組み合わせることで、同一のメッセージを複数のキューに並列的に送信します。
  • 優先順位: 業務の優先順位に応じた個別のキューを使用します。
  • スケーラビリティ: メッセージキューによってプロセス間が切り離されるため、メッセージの送信または受信速度のスケールアップも、プロセスを追加するのみという簡単なものになります。
  • 耐障害性: システムの一部に障害が発生しても、システム全体がダウンすることにはなりません。メッセージキューによってシステムのコンポーネントが切り離されるため、そのキューからメッセージを読み取り中のプロセスに障害が発生しても、そのキューへのメッセージ追加は継続でき、システム回復時に処理できます。

このサービスのご利用には、アマゾン ウェブ サービスカスタマーアグリーメントが適用されます。