翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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メッセージのライフサイクルについて説明します。
分散キュー
分散メッセージングシステムには 3 つの主要部分 (分散システムのコンポーネント、キュー (Amazon SQS サーバーで分散)、およびキューのメッセージ) があります。
次のシナリオでは、システムには複数のプロヂューサー(キューにメッセージを送信するコンポーネント)とコンシューマー(キューからメッセージを受信するコンポーネント)があります。キュー (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 は、分散ソフトウェアシステムとコンポーネントをキューサービスとしてデカップリングしてスケーリングします。通常、1 人のサブスクライバーを通じてメッセージを処理し、順序と損失の防止が重要なワークフローに最適です。より広範なディストリビューションのために、Amazon SQS を Amazon SNS と統合すると、ファンアウトメッセージングパターン
Amazon SNS では、パブリッシャーは、通信チャネルとして機能するトピックを通じて複数のサブスクライバーにメッセージを送信できます。サブスクライバーは、、Amazon SQSAmazon Data Firehose、Lambda、HTTP、E メール、モバイルプッシュ通知、モバイルテキストメッセージ (SMS) など、サポートされているエンドポイントタイプを使用して公開メッセージを受信します。 Amazon SQS このサービスは、リアルタイムのユーザーエンゲージメントやアラームシステムなど、即時の通知を必要とするシナリオに最適です。サブスクライバーがオフラインのときにメッセージが失われないように、Amazon SNS を Amazon SQS キューメッセージと統合することで、一貫した配信が保証されます。
Amazon MQ は、Apache ActiveMQ や RabbitMQ とともに AMQP や MQTT
次の表は、各サービスのリソースタイプの概要を示しています。
リソースタイプ | Amazon SNS | Amazon SQS | Amazon MQ |
---|---|---|---|
同期的 | いいえ | いいえ | はい |
非同期的 | はい | はい | はい |
キュー | いいえ | はい | はい |
パブリッシャー/サブスクライバーメッセージング | はい | いいえ | はい |
メッセージブローカー | いいえ | いいえ | はい |
新規のアプリケーションには、Amazon SQS および Amazon SNS をお勧めします。ほぼ無制限のスケーラビリティとシンプルな API が利点です。通常、コスト効果の高いソリューションは、大量のアプリケーションに対してその pay-as-you-go 料金で提供されます。JMS などの APIs や、アドバンストメッセージキューイングプロトコル (AMQP)、MQTT、および Simple Text Oriented Message Protocol (STOMP) などのプロトコルとの互換性に依存する既存のメッセージブローカーからアプリケーションを移行するには OpenWire、Amazon MQ をお勧めします。