翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Simple Queue Serviceとは?
Amazon Simple Queue Service（Amazon SQS)は、分散されたソフトウェアシステムとコンポーネントを統合と分離ができる安全性、耐久性があり利用可能なホストキューを提供します。Amazon SQS は、[デッドレターキュー](sqs-dead-letter-queues.md)や[コスト配分タグ](sqs-queue-tags.md)など、一般的な構造を提供します。 AWS SDK がサポートする任意のプログラミング言語を使用してアクセスできる汎用ウェブサービス API を提供します。
## Amazon SQSを使用する利点
+ **セキュリティ**–Amazon SQS キューにメッセージを送信する人、およびメッセージを受信する人を[制御](security-iam.md)します。Amazon SQS 管理のサーバー側の暗号化を使用するか、 AWS Key Management Service (AWS KMS) で管理されるカスタム [SSE](sqs-server-side-encryption.md) キーを使用して、キューのメッセージの内容を保護して、機密データを送信できます。
+ **耐久性**–メッセージの安全性のため、Amazon SQS は複数のサーバーにメッセージを保存します。標準キューは[メッセージの At-least once 配信](standard-queues-at-least-once-delivery.md)をサポートし、FIFO キューは[メッセージの 1 回のみ処理](FIFO-queues-exactly-once-processing.md)と[高スループット](high-throughput-fifo.md)モードをサポートします。
+ **可用性**–Amazon SQS は、[冗長なインフラストラクチャ](#sqs-basic-architecture)を使用して同時実行性が高いメッセージへのアクセスと、メッセージの作成と消費のための高い可用性を提供します。
+ **スケーラビリティ**– Amazon SQSは[バッファされたリクエスト](sqs-client-side-buffering-request-batching.md)を独立して個別に処理できるため、プロビジョニング指示を必要とせずに負荷の増大や急増に対応できるよう透過的にスケーリングします。
+ **信頼性**–Amazon SQSは処理中にメッセージをロックするため、複数のプロデューサーがメッセージを送信し、複数のコンシューマーが同時にメッセージを受信できます。
+ **カスタマイズ**-キューは完全に同じである必要はありません。たとえば、[キューでデフォルトの遅延を設定](sqs-delay-queues.md)できます。1 MiB よりも大きいメッセージのコンテンツは [Amazon Simple Storage Service (Amazon S3)](sqs-s3-messages.md) または Amazon DynamoDB を使用し、Amazon SQS が、Amazon S3 オブジェクトへのポインタを保持して、保存できます。または、大きいメッセージを小さいメッセージに分割することができます。
## Amazon SQSの基本的なアーキテクチャ
作成から削除まで、 分散メッセージングシステムの部分およびAmazon SQSメッセージのライフサイクルについて説明します。
このセクションでは、分散メッセージングシステムの各コンポーネントの概要および Amazon SQS メッセージのライフサイクルについて説明します。
### 分散キュー
分散メッセージングシステムには 3 つの主要部分、**分散システムのコンポーネント**、**キュー** (Amazon SQS サーバーで分散)、**キューのメッセージ**があります。
次のシナリオでは、システムには複数の*プロヂューサー*（キューにメッセージを送信するコンポーネント）と*コンシューマー*（キューからメッセージを受信するコンポーネント）があります。キュー (A から E までのメッセージを保持) は、複数のAmazon SQS サーバー全体にまたがって冗長的にメッセージを保存します。
![\[分散メッセージングシステムには、分散システムのコンポーネント、キュー (Amazon SQS サーバーに分散)、キュー内のメッセージという 3 つの主要な部分があります。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/ArchOverview.png)
### メッセージのライフサイクル
次のシナリオは、キューのAmazon SQSメッセージのライフサイクルを作成から削除までを説明しています。
![\[キュー内の Amazon SQS メッセージのライフサイクル (作成から削除まで)。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-message-lifecycle-diagram.png)
![\[Section one description for the previous lifecycle diagram.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png) プロデューサー (コンポーネント 1) はメッセージ A をキューに送ります。このメッセージは Amazon SQS サーバー全体に冗長的に分散されます。
![\[Section two description for the previous lifecycle diagram.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png) コンシューマー (コンポーネント 2) でメッセージを処理する準備が整うと、キューからメッセージを消費し、メッセージ A が返されます。メッセージ A は処理されている間キューに残り、[可視性タイムアウト](sqs-visibility-timeout.md)の間は次の受信リクエストに返されることはありません。
![\[Section three description for the previous lifecycle diagram.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png) 可視性タイムアウトの期限が切れると、コンシューマー (コンポーネント 2) はキューからメッセージ A を削除し、メッセージが再び受信されて処理されるのを回避します。
**注記**
Amazon SQSは最大メッセージ保持期間を超えてキューに保存されたメッセージを自動的に削除します。デフォルトのメッセージ保持期間は 4 日間です。ただし、`[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)` アクションを使うと、メッセージ保持期間の値を 60 秒から 1,209,600 秒 (14 日間) までの範囲で設定できます。
## Amazon SQS、Amazon MQ、Amazon SNS 間の違い
Amazon SQS、[Amazon SNS](https://aws.amazon.com/sns/)、[Amazon MQ](https://aws.amazon.com/amazon-mq/) は、高度にスケーラブルで使いやすいマネージドメッセージングサービスを提供します。各サービスは、分散システム内の特定の役割向けに設計されています。これらのサービス間の違いについて、以下に詳しく説明します。
**Amazon SQS** は、分散ソフトウェアシステムとコンポーネントをキューサービスとしてデカップリングしてスケーリングします。通常、単一のサブスクライバーを通じてメッセージを処理します。順序と損失の防止が重要なワークフローに最適です。より広範に分散する場合は、Amazon SQS を Amazon SNS と統合すると、[ファンアウトメッセージングパターン](https://aws.amazon.com/getting-started/hands-on/send-fanout-event-notifications/)が可能になり、複数のサブスクライバーにメッセージを一度に効果的にプッシュできます。
**Amazon SNS** を使用すると、パブリッシャーは、通信チャネルとして機能するトピックを通じて複数のサブスクライバーにメッセージを送信できます。サブスクライバーは、[Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)、[Amazon SQS](#welcome)、[Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)、HTTP、E メール、モバイルプッシュ通知、モバイルテキストメッセージ (SMS) などのサポートされているエンドポイントタイプを使用して、発行されたメッセージを受け取ります。このサービスは、リアルタイムのユーザーエンゲージメントやアラームシステムなど、即時の通知を必要とするシナリオに最適です。サブスクライバーがオフラインのときにメッセージの損失を防ぐため、Amazon SNS を Amazon SQS キューメッセージと統合することで、一貫性のある配信を確保します。
**Amazon MQ** は、従来のメッセージブローカーからの移行を検討している企業に最適であり、AMQP や MQTT などの標準メッセージングプロトコル、[Apache ActiveMQ](http://activemq.apache.org/)、[RabbitMQ](https://www.rabbitmq.com/) をサポートしています。大幅な再設定なしで、安定した信頼性の高いメッセージングを必要とするレガシーシステムとの互換性を提供します。
次の表は、各サービスのリソースタイプの概要を示しています。
| リソースタイプ | Amazon SNS | Amazon SQS | Amazon MQ |
| --- | --- | --- | --- |
| 同期 | なし | なし | あり |
| 非同期 | はい | はい | あり |
| [キュー] | なし | はい | あり |
| パブリッシャー/サブスクライバーメッセージング | あり | なし | あり |
| メッセージブローカー | なし | なし | あり |
新規のアプリケーションには、Amazon SQS および Amazon SNS をお勧めします。ほぼ無制限のスケーラビリティとシンプルな API が利点です。通常、従量制料金で、大量のアプリケーションに対してコスト効率の高いソリューションを提供します。JMS などの API や、アドバンストメッセージキューイングプロトコル (AMQP)、MQTT、OpenWire、STOMP (Simple Text Oriented Message Protocol) などのプロトコルとの互換性に依存する既存のメッセージブローカーからのアプリケーション移行にはAmazon MQ をお勧めします。