翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon Simple Queue Serviceとは?
Amazon Simple Queue Service（Amazon SQS)は、分散されたソフトウェアシステムとコンポーネントを統合と分離ができる安全性、耐久性があり利用可能なホストキューを提供します。Amazon SQS は、デッドレターキューやコスト配分タグなど、一般的な構造を提供します。 AWS SDK がサポートする任意のプログラミング言語を使用してアクセスできる汎用ウェブサービス API を提供します。
Amazon SQSを使用する利点
-
セキュリティ–Amazon SQS キューにメッセージを送信する人、およびメッセージを受信する人を制御します。Amazon SQS 管理のサーバー側の暗号化を使用するか、 AWS Key Management Service (AWS KMS) で管理されるカスタム SSE キーを使用して、キューのメッセージの内容を保護して、機密データを送信できます。
-
耐久性–メッセージの安全性のため、Amazon SQS は複数のサーバーにメッセージを保存します。標準キューはメッセージの At-least once 配信をサポートし、FIFO キューはメッセージの 1 回のみ処理と高スループットモードをサポートします。
-
可用性–Amazon SQS は、冗長なインフラストラクチャを使用して同時実行性が高いメッセージへのアクセスと、メッセージの作成と消費のための高い可用性を提供します。
-
スケーラビリティ– Amazon SQSはバッファされたリクエストを独立して個別に処理できるため、プロビジョニング指示を必要とせずに負荷の増大や急増に対応できるよう透過的にスケーリングします。
-
信頼性–Amazon SQSは処理中にメッセージをロックするため、複数のプロデューサーがメッセージを送信し、複数のコンシューマーが同時にメッセージを受信できます。
-
カスタマイズ-キューは完全に同じである必要はありません。たとえば、キューでデフォルトの遅延を設定できます。256 KB よりも大きいメッセージのコンテンツはAmazon Simple Storage Service (Amazon S3) または Amazon DynamoDBを使用し、Amazon SQSが、Amazon S3 オブジェクトへのポインタを保持して、保存できます。または、大きいメッセージを小さいメッセージに分割することができます。
Amazon SQSの基本的なアーキテクチャ
このセクションでは、分散メッセージングシステムのコンポーネントと Amazon SQS メッセージのライフサイクルについて説明します。
分散キュー
分散メッセージングシステムには、分散システムのコンポーネント、キュー (Amazon SQS サーバーで分散）、キュー内のメッセージの 3 つの主要部分があります。
次のシナリオでは、システムには複数のプロヂューサー（キューにメッセージを送信するコンポーネント）とコンシューマー（キューからメッセージを受信するコンポーネント）があります。キュー (A から E までのメッセージを保持) は、複数のAmazon SQS サーバー全体にまたがって冗長的にメッセージを保存します。
メッセージのライフサイクル
次のシナリオは、キューのAmazon SQSメッセージのライフサイクルを作成から削除までを説明しています。
プロデューサー (コンポーネント 1) はメッセージ A をキューに送信し、メッセージは Amazon SQS サーバー全体に冗長的に分散されます。
コンシューマー (コンポーネント 2) がメッセージを処理できる状態になると、キューからのメッセージを消費し、メッセージ A が返されます。メッセージ A は処理されている間キューに残り、可視性タイムアウトの間は次の受信リクエストに返されることはありません。
コンシューマー (コンポーネント 2) はキューからメッセージ A を削除して、可視性タイムアウトの期限が切れたときにメッセージが再度受信および処理されないようにします。
注記
Amazon SQSは最大メッセージ保持期間を超えてキューに保存されたメッセージを自動的に削除します。デフォルトのメッセージ保持期間は 4 日間です。ただし、SetQueueAttributes アクションを使うと、メッセージ保持期間の値を 60 秒から 1,209,600 秒 (14 日間) までの範囲で設定できます。
Amazon SQS、Amazon MQ、Amazon SNS 間の違い
Amazon SQS、Amazon SNS
Amazon SQS は、分散ソフトウェアシステムとコンポーネントをキューサービスとしてデカップリングしてスケーリングします。通常、単一のサブスクライバーを通じてメッセージを処理します。順序と損失の防止が重要なワークフローに最適です。より広範に分散する場合は、Amazon SQS を Amazon SNS と統合すると、ファンアウトメッセージングパターン
Amazon SNS を使用すると、パブリッシャーは、通信チャネルとして機能するトピックを通じて複数のサブスクライバーにメッセージを送信できます。サブスクライバーは、Amazon Data Firehose、Amazon SQS、Lambda、HTTP、E メール、モバイルプッシュ通知、モバイルテキストメッセージ (SMS) などのサポートされているエンドポイントタイプを使用して、発行されたメッセージを受け取ります。このサービスは、リアルタイムのユーザーエンゲージメントやアラームシステムなど、即時の通知を必要とするシナリオに最適です。サブスクライバーがオフラインのときにメッセージの損失を防ぐため、Amazon SNS を Amazon SQS キューメッセージと統合することで、一貫性のある配信を確保します。
Amazon MQ は、従来のメッセージブローカーからの移行を検討している企業に最適であり、AMQP や MQTT などの標準メッセージングプロトコル、Apache ActiveMQ
次の表は、各サービスのリソースタイプの概要を示しています。
| リソースタイプ | Amazon SNS | Amazon SQS | Amazon MQ |
|---|---|---|---|
| 同期 | なし | いいえ | あり |
| 非同期 | あり | あり | あり |
| キュー | なし | はい | あり |
| パブリッシャー/サブスクライバーメッセージング | あり | なし | あり |
| メッセージブローカー | なし | いいえ | あり |
新規のアプリケーションには、Amazon SQS および Amazon SNS をお勧めします。ほぼ無制限のスケーラビリティとシンプルな API が利点です。通常、従量制料金で、大量のアプリケーションに対してコスト効率の高いソリューションを提供します。JMS などの API や、アドバンストメッセージキューイングプロトコル (AMQP)、MQTT、OpenWire、STOMP (Simple Text Oriented Message Protocol) などのプロトコルとの互換性に依存する既存のメッセージブローカーからのアプリケーション移行にはAmazon MQ をお勧めします。
