Q: Amazon SQS とは何ですか?

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

Amazon SQS には、信頼性とスケーラビリティに優れたホストキューが用意されており、コンピュータ間で転送されるメッセージが保存されます。Amazon SQS を使うと、分散されたさまざまなアプリケーションコンポーネント間でデータを移動できます。メッセージを失うことはなく、また各コンポーネントを常に利用可能にしておく必要もありません。

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

Q: Amazon SQS で何ができますか?

Amazon SQS は非常にスケーラブルなため、使用した分についてのみ料金をお支払いいただきます。お客様は、パフォーマンスや信頼性の点で妥協することなく、小規模に利用を開始し、ビジネスニーズに合わせてアプリケーションを拡張することができます。Amazon SQS では、メッセージの保存や管理の方法について心配することなく、堅牢で洗練されたメッセージベースアプリケーションの構築に専念できます。

例えば、以下の機能があります。

  • Amazon SQS を AWS の他のサービスに統合して、アプリケーションの柔軟性と信頼性を向上させることができます。
  • Amazon SQS を使用してワークキューを作成すると、各メッセージはそれぞれのプロセスで実行される個別のタスクになります。1 台または複数のコンピュータが、メッセージキューからタスクを読み取った後、タスクを処理します。
  • メッセージキューを使用してマイクロサービスに接続するマイクロサービスアーキテクチャを構築できます。
  • Amazon SQS メッセージキューでは、重要なビジネスイベントの通知が保管されます。メッセージキューには各イベントに対応するメッセージを保存できます。イベントに関連するアプリケーションではそのメッセージを読み取り、処理できます。

Q: Amazon SQS の使用をどのように開始できますか?

10 分間のチュートリアルで、Amazon SQS キューを作成し、数ステップだけでメッセージを送信できるようになります。分散型アプリケーション間でメッセージを送信

詳細については、Amazon SQS 開発者ガイド、およびリソースセンターにあるサンプルコードを参照してください。

Q: 自社製や市販パッケージのメッセージキューイングシステムと比較して、Amazon SQS にはどのようなメリットがありますか?

Amazon SQS では、メッセージキューの管理のために独自のソフトウェアを構築したり、市販またはオープンソースのメッセージキューイングシステムを使用してシステムの開発や設定の初期作業に多くの時間を費やしたりする必要がありません。

また、自社製または市販のパッケージ化されたメッセージキューイングシステムでは、定期的なハードウェアのメンテナンスやシステム管理のためのリソースが必要です。ハードウェア障害の発生時にメッセージが失われないよう、冗長性のあるメッセージストレージを設定する必要もあるため、システムの設定や管理はさらに複雑になります。

対照的に、Amazon SQS では、管理オーバーヘッドが発生せず、必要な設定もわずかです。Amazon SQS は、毎日数十億件のメッセージを処理する巨大な規模で有効に機能します。Amazon SQS に送信されるトラフィック量の拡張や縮小にも、設定は必要ありません。また、Amazon SQS はメッセージの耐久性が非常に高いため、お客様や関係者に安心してお使いいただけます。

Q: Amazon SQS と Amazon SNS の違いは何ですか?

Amazon Simple Queue Service(SQS)および Amazon SNS は共に AWS 内のメッセージングサービスですが、開発者にそれぞれ異なった利点を提供します。Amazon SNS を利用すれば、アプリケーションは「プッシュ」メカニズムを使用して、複数の受信者にタイミングが重要なメッセージを送信することができます。そのため更新を定期的に確認または「ポーリング」する必要性がなくなります。Amazon SQS は、分散型アプリケーションが使用するメッセージキューサービスであり、ポーリングモデルを通じてメッセージを交換し、コンポーネントの送受信を切り離すために使用することができます。Amazon SQS ではアプリケーションの分散型コンポーネントに対して柔軟性が提供され、同時に利用可能な各コンポーネントを必要とすることなくメッセージの送受信を行うことができます。

一般的なパターンは、SNS を使用して Amazon SQS キューに対してメッセージを発行し、メッセージを 1 つまたは複数のシステムコンポーネントに非同期で確実に送信するというものです。詳細は、Pub/Sub メッセージングとは?をご覧ください。

Q: Amazon SQS と Amazon MQ はどのように違うのですか?

Amazon MQ、Amazon SQS、Amazon SNS は起業したての方からエンタープライズまで、誰にでも適切なメッセージサービスです。既存のアプリケーションをお使いで、メッセージをクラウドに手早く簡単に移したい場合、Amazon MQ をご検討ください。これは業界標準の API とプロトコルを使いますので、標準に基づいたメッセージブローカーならばどれからでも Amazon MQ に、アプリケーション内のメッセージコードを書き換えることなく切り替えられます。クラウド上で全く新しいアプリケーションを構築される場合は、Amazon SQS と Amazon SNS のご検討をお勧めします。Amazon SQS と SNS は軽量で、完全に管理されたメッセージキュー・トピックサービスで、ほとんど無制限にスケールでき、簡単で使いやすい API を提供します。Amazon SQS と SNS を用いて、マイクロサービス、分散型システム、サーバーなしのアプリケーションを切り離して、信頼性を向上できます。

Q: Amazon SQS にはメッセージの順序付け機能がありますか?

はい。FIFO (先入れ先出し) キューではメッセージが送受信された正確な順序が保持されます。FIFO キューを使用する場合、メッセージ内に順序付けの情報を含める必要はありません。詳細については、Amazon SQS 開発者ガイドFIFO Queue Logic を参照してください。

標準キューには、メッセージの順序をできるだけ維持しようとする厳密ではない FIFO 機能が備わっています。ただし標準キューは、徹底して分散化されたアーキテクチャを使用して、非常にスケーラブルであるように設計されているため、送信されたのとまったく同じ順序でメッセージを受信することは保証されていません。

Q: Amazon SQS では、メッセージが配信されることは保証されますか?

標準キューでは 1 回以上の配信が行われます。これは、各メッセージは少なくとも 1 回配信されることを意味します。

FIFO キューではちょうど 1 回の処理が行われます。これは、各メッセージは 1 回配信されて、ユーザーがメッセージを処理して削除するまで使用可能な状態に留まることを意味します。キューでメッセージの重複が起きることはありません。

 

Q: Amazon SQS と Amazon Kinesis Streams はどのように違うのですか?

Amazon SQS では、メッセージがアプリケーション間またはマイクロサービス間を移動するときにメッセージを格納するため、信頼性が高く非常にスケーラブルなホスト型キューが提供されます。Amazon SQS は、分散アプリケーションのコンポーネント間でデータを移動し、これらのコンポーネントを分離する場合に役立ちます。Amazon SQS は、デッドレターキューやポイズンピルの管理など、共通のミドルウェアコンストラクトを提供します。汎用のウェブサービス API も提供され、これには AWS SDK がサポートしている任意のプログラミング言語でアクセスできます。Amazon SQS は標準キューと FIFO キューの両方をサポートしています。

固有のそれぞれのメッセージを 1 回のみ消費する必要がある場合や、以下のような場合には Amazon SQS を使用します。

  • アプリケーションのコンポーネントを分離する: キューに入った作業項目があり、各項目が正常に完了したことを個々に追跡したい。Amazon SQS は ACK/FAIL の結果を追跡するので、アプリケーションでは永続的なチェックポイントやカーソルを保持する必要はありません。設定されている可視性タイムアウトの経過後、Amazon SQS は確認済みメッセージを削除し、失敗したメッセージを再配信します。
  • 個々のメッセージの遅延を設定する: ジョブのキューがあり、個々のジョブに遅延をスケジュールする必要がある。Amazon SQS では、個々のメッセージに最大で 15 分の遅延を設定できます。
  • 読み込み時の同時並行性やスループットを動的に高める: 作業キューがあり、バックログがクリアされるまで読み込むユーザーをさらに追加したい。Amazon Kinesis Streams では、十分な数のシャードにスケールアップできます (ただし、前もって十分なシャードを準備しておく必要があります)。Amazon SQS では事前の準備は不要です。
  • スケーリングの透過性: 負荷の一時的な上昇や事業の自然な成長の結果として、バッファリクエストや負荷が変化する。Amazon SQS はバッファに入れられた各リクエストを個々に処理できるため、Amazon SQS はユーザーから準備の指示を受けなくても透過的にスケーリングし、負荷を処理することができます。

Amazon Kinesis Streams では、ストリーミングの巨大なデータをリアルタイムに処理可能で、複数の Amazon Kinesis アプリケーションへのレコードを読み込んで再生する機能を利用できます。Amazon Kinesis クライアントライブラリ (KCL) では、特定のパーティションキーのすべてのレコードが同じレコードプロセッサに提供されるため、同じ Amazon Kinesis ストリームから読み取りを行う複数のアプリケーションを構築することが容易になります (カウント、集計、フィルタリングの実行など)。

複数のユーザーが各レコードを処理できる必要がある場合や、以下のような場合には、Amazon Kinesis Streams を使用します。

  • 関連するレコードを同じレコードプロセッサにルーティングする: MapReduce をストリーム送信する。 特定のキーのすべてのレコードが同じレコードプロセッサにルーティングされれば、カウントや集計などの処理が簡単になります。
  • 複数のアプリケーションが同じストリームを同時に消費できるようにする: 1 つのアプリケーションはリアルタイムにダッシュボードを更新し、他のアプリケーションはデータを Amazon Redshift にアーカイブする。 両方のアプリケーションで、同じストリームからのデータを同時に、独立して使用できます。

Q: Amazon は Amazon SQS を自社アプリケーションに使用していますか?

はい。Amazon の開発者は、毎日多数のメッセージを処理する必要があるさまざまなアプリケーションで Amazon SQS を使用しています。Amazon.com とアマゾン ウェブ サービスの両方の主要ビジネスプロセスで、Amazon SQS が使用されています。


Q: Amazon SQS の料金はどのくらいですか?

お客様が使用した分にのみお支払いいただきます。最低料金はありません。

Amazon SQS の料金は、リクエストごとに計算される分に加えて、Amazon SQS から転送されるデータに対してデータ転送料金をお支払いいただきます (データが同じリージョン内の Amazon EC2 インスタンス、または AWS Lambda 関数に転送される場合を除きます)。キューの種類およびリージョンごとの詳細な料金明細については、Amazon SQS 料金 を参照してください。

Q: Amazon SQS の無料利用枠で何ができますか?

Amazon SQS の無料利用枠では、毎月 100 万件のリクエストを無料でご利用いただけます。

多くの小規模なアプリケーションは、完全にこの無料利用枠内で運用できます。ただし、データ転送料金は別途必要です。詳細については、Amazon SQS 料金を参照してください。

無料利用枠は月ごとの提供となっています。無料利用枠は次月に持ち越されません。

Q: すべての Amazon SQS リクエストに対して課金されますか?

はい、無料利用枠を超えるすべてのリクエストに対して課金されます。すべての Amazon SQS リクエストに対して課金され、一律単価で請求されます。

Q: Amazon SQS のバッチオペレーションは、他のリクエストよりもコストが多くかかりますか?

いいえ。すべてのバッチオペレーション (SendMessageBatch、DeleteMessageBatch、ChangeMessageVisibilityBatch) のコストは、Amazon SQS の他のリクエストと同じです。メッセージをバッチにグループ化することで、Amazon SQS のコストを削減できます。

Q: Amazon SQS を利用すると、どのように課金され、請求されますか?

Amazon SQS の使用を開始するための初期料金はありません。月末に、その月の使用料金が自動的にお客様のクレジットカードに請求されます。

現在の請求期間の料金は、AWS のウェブサイトでいつでも確認できます。

  1. AWS アカウントにログインします。
  2. [Your Web Services Account] で、[Account Activity] を選択します。

Q: Amazon SQS キューに関連するコストはどのように追跡および管理できますか?

リソースとコスト管理のキューは、コスト配分タグを使用してタグ付けして追跡できます。タグは、キーと値のペアで構成されるメタデータラベルです。たとえば、コストセンターでキューをタグ付けしてから、それらのコストセンターに基づいてコストを分類し、追跡することができます。

詳細については、Amazon SQS 開発者ガイドTagging Your Amazon SQS Queues を参照してください。AWS リソースのコスト配分タグの詳細については、AWS 請求とコスト管理ユーザーガイドのコスト配分タグの使用を参照してください。

Q: 料金は税込み価格ですか?

別途記載がない限り、表示される料金には VAT、売上税、その他取引に対して適用される一切の税金および関税は含まれません。

日本の請求連絡先をお持ちのお客様が AWS をご利用になった場合は、ご利用になったリージョンにかかわらず、料金とあわせて別途消費税をご請求させていただきます。詳細については、アマゾン ウェブ サービス消費税率変更についてのよくある質問を参照してください。


Q: Amazon SQS を他の AWS のサービスと共に使用できますか?

はい。アプリケーションの柔軟性とスケーラビリティを向上させるために、Amazon SQS を、Amazon EC2、Amazon EC2 Container Service (Amazon ECS)、AWS Lambda といったコンピューティングサービス、および Amazon Simple Storage Service (Amazon S3)、Amazon DynamoDB といったストレージサービスやデータベースサービスと共に使用できます。

一般的ユースケースの 1 つは独立した分散アプリケーションです。このようなアプリケーションの場合、複数のコンポーネントやモジュールが相互に通信する必要がありますが、すべてが同量の作業を同時に処理できるわけではありません。この場合、Amazon SQS メッセージキューには、Amazon EC2 インスタンスで実行されているアプリケーションによって処理されるメッセージが保管されます。

Amazon EC2 インスタンスは、メッセージキューを読み込み、ジョブを処理してから、(別のアプリケーションでさらに処理するなどにより) 結果をメッセージとして別の Amazon SQS メッセージキューにポストします。Amazon EC2 によりアプリケーションを動的に拡張および縮小できるようになるため、アプリケーション開発者は、ジョブが適切なタイミングで必ず実行されるよう、Amazon SQS キューのメッセージ量に基づき、Auto Scaling を使用してコンピューティングインスタンス数を変えられます。

Q: Amazon SQS のユースケースの例を挙げてください。

動画トランスコーディングウェブサイトでは、以下のように Amazon EC2、Amazon SQS、Amazon S3、および Amazon DynamoDB が共に使用されます。

  1. エンドユーザーが、トランスコードする動画をこのウェブサイトへ送信します。
  2. 動画は Amazon S3 に保存され、リクエストメッセージはメッセージ内の動画フォーマットおよびターゲット動画フォーマットへのポインターと共に Amazon SQS の着信キューに配置されます。
  3. Amazon EC2 インスタンスで実行されているトランスコーディングエンジンは、着信キューからリクエストメッセージを読み込み、ポインターを使用して Amazon S3 から動画を取り出し、ターゲットフォーマットに動画をエンコードします。
  4. 変換された動画は Amazon S3 へ戻され、別の応答メッセージが変換済み動画へのポインターと共に Amazon SQS 発信キューに配置されます。
  5. 同時に、クエリのために、動画についてのメタデータ (フォーマット、作成日、長さなど) のインデックスを Amazon DynamoDB に付けられます。

このワークフローを通して、専用の Auto Scaling インスタンスにより着信キューを絶えずモニタリングできます。Auto Scaling インスタンスは、着信キューのメッセージ数に基づいて、応答時間に関するウェブサイトユーザーの要件を満たせるようにトランスコードする Amazon EC2 インスタンスの数を動的に調整します。

Q: どのようにしたら Amazon SQS とやり取りできますか?

AWS マネジメントコンソールを使用して Amazon SQS にアクセスできます。これによって Amazon SQS キューの作成とメッセージの送信が簡単になります。

Amazon SQS には、ウェブサービス API も用意されています。また、AWS SDK と統合されるため、選択したプログラミング言語で作業することができます。

Q: メッセージキューに対してどのようなオペレーションを利用できますか?

メッセージキューのオペレーションの詳細については、Amazon SQS 製品の詳細を参照してください。

Q: 誰がメッセージキューに対するオペレーションを実行できますか?

AWS アカウントの所有者 (またはアカウント所有者が権限を委任した AWS アカウント) のみが、Amazon SQS メッセージキューでオペレーションを実行できます。

Q: Java Message Service (JMS) と Amazon SQS とは併用できますか?

はい。JMS クラスタ運用のオーバーヘッドの高さについて心配することなく、Amazon SQS の規模、低いコスト、および高可用性を生かせます。

Amazon では、JMS 1.1 仕様を実装し Amazon SQS を JMS プロバイダーとして使用する Amazon SQS Java Messaging Library を提供しています。詳細については、『Amazon SQS 開発者ガイド』の「Amazon SQS での JMS の使用」を参照してください。

Q: Amazon SQS ではどのようにメッセージが識別されるのですか?

すべてのメッセージには、メッセージがメッセージキューに配信される際に Amazon SQS から返される、グローバルに一意の ID が割り当てられます。メッセージをさらに処理するためにこの ID が必要になるわけではありませんが、メッセージキューの特定のメッセージが受信状況を追跡するのに役立ちます。

メッセージキューからメッセージを受信すると、応答に受信ハンドルが含まれます。受信ハンドルは、メッセージを削除する際に入力する必要があります。

Q: Amazon SQS では処理に失敗したメッセージはどのように扱われますか?

Amazon SQS では、API またはコンソールを使用してデッドレターキューを設定できます。デッドレターキューは、他のソースキューからメッセージを受信するキューです。

キューをデッドレターキューにすると、そのキューは、完了できなかった処理試行が最大数に達した後にメッセージを受信します。デッドレターキューを使用すると、処理できないメッセージを後で分析するために分離できます。

詳細については、このページの「FIFO キューではデッドレターキューを使用できますか?」および『Amazon SQS 開発者ガイド』の「Amazon SQS デッドレターキューの使用」を参照してください。

Q: 可視性タイムアウトとは何ですか?

可視性タイムアウトは、Amazon SQS で、他の消費コンポーネントがメッセージの受信と処理を行わないようにする期間です。詳細については、『Amazon SQS 開発者ガイド』の「可視性タイムアウト」を参照してください。

Q: Amazon SQS では、どのような方法により、メッセージが失われたり複数回処理されたりすることなく、同じメッセージキューに複数のリーダーがアクセスできるようになりますか?

各 Amazon SQS キューには、設定可能な可視性タイムアウトがあります。メッセージキューからメッセージが読み込まれる場合、他のリーダーは、設定された時間、そのメッセージを認識できなくなります。メッセージの処理に必要な時間が可視性タイムアウトよりも短い場合、各メッセージは処理され、削除されます。

メッセージを処理するコンポーネントが故障している場合や利用できなくなった場合は、可視性タイムアウトが終了すると、メッセージキューを読み込むコンポーネントがメッセージを再び認識できるようになります。これにより、それぞれ異なるメッセージを処理する複数のコンポーネントが、同じメッセージキューからメッセージを読み込めるようになります。

Q: メッセージ可視性の上限は何時間ですか?

Amazon SQS メッセージの可視性タイムアウトの上限は 12 時間です。

Q: Amazon SQS はメッセージメタデータに対応していますか?

はい。Amazon SQS のメッセージには、最大 10 件のメタデータ属性を含めることがきます。メッセージ属性を使用して、メッセージの本文と本文を記述するメタデータを分離できます。これにより、アプリケーション側で処理方法を判断するためにメッセージ全体を調査する必要がなくなり、情報を処理して保存する速度と効率が向上します。

Amazon SQS メッセージ属性の形式は、名前-タイプ-値の 3 部から構成されます。サポートされるタイプには、文字列、バイナリ、および数値 (整数、浮動小数点、および倍精度浮動小数点数を含む) があります。詳細については、『Amazon SQS 開発者ガイド』の「Amazon SQS メッセージ属性の使用」を参照してください。

Q: どのように "キューされていた時間" の値を判断できますか?

"キューされていた時間" の値を判断するため、メッセージの受信時に SentTimestamp 属性をリクエストできます。"キューされていた時間" の値で、現在の時間の結果からその値を差し引きます。

Q: Amazon SQS のレイテンシーは通常どれくらいですか?

SendMessage、ReceiveMessage、および DeleteMessage の各 API リクエストの場合、レイテンシーは通常数十ミリ秒~数百ミリ秒です。

Q: 匿名アクセスで、メッセージの SenderId 属性の値とは何ですか?

AWS アカウント ID を利用できない場合 (メッセージの送信元が匿名ユーザーの場合など) は、Amazon SQS から IP アドレスが提供されます。

Q: SQS ロングポーリングとは何ですか?

SQS ロングポーリングとは、SQS キューからメッセージを取り出すための新しい手法です。従来の SQS ショートポーリングは、ポーリングされたキューが空であっても直ちに応答を返しますが、SQS ロングポーリングでは、メッセージがキューに達するか、ロングポーリングがタイムアウトになるまで応答を返しません。SQS ロングポーリングの場合、SQS キューでメッセージが使用可能になった時点ですぐに、そのメッセージを簡単かつ低コストで取り出すことができます。

Q: Amazon SQS ロングポーリングを使用するには追加料金がかかりますか?

いいえ。ロングポーリングの ReceiveMessage 呼び出しに対して請求される料金は、ショートポーリングの ReceiveMessage 呼び出しの場合と同額です。

Q: Amazon SQS ロングポーリングと Amazon SQS ショートポーリングを使用する必要があるのは、それぞれどのような場合ですか?

ほとんどの場合、Amazon SQS ショートポーリングではなく、Amazon SQS ロングポーリングを使用することをお勧めします。ロングポーリングリクエストを使用すると、メッセージがキューに達した時点ですぐに、キューの消費コンポーネントがそのメッセージを受信でき、また ReceiveMessageResponses インスタンスが空で返される回数が減ります。

ほとんどのユースケースで、Amazon SQS ロングポーリングはパフォーマンスの向上とコスト削減につながります。ただし、アプリケーションが ReceiveMessage 呼び出しから直ちに応答を受け取る必要がある場合は、アプリケーションに多少の変更を加えないとロングポーリングのメリットを活用できない可能性があります。

例えば、複数のキューを単一スレッドでポーリングするアプリケーションの場合は、ショートポーリングからロングポーリングへの切り替えが機能しない可能性があります。単一スレッドは、すべての空のキューでロングポーリングタイムアウトを待機するので、メッセージが含まれる可能性のあるキューの処理が遅れるからです。

このようなアプリケーションで複数のキューを処理する場合は、単一スレッドを使用しないようにすることができます。これにより、そのアプリケーションで Amazon SQS ロングポーリングのメリットを活用できるようになります。

Q: ロングポーリングタイムアウトにはどのような値を指定できますか?

通常は、ロングポーリングタイムアウトの上限値である 20 秒を指定できます。ロングポーリングタイムアウト値を大きくすると、ReceiveMessageResponses インスタンスが空で返される回数が減るので、ロングポーリングタイムアウトはできるだけ大きい値に設定するようにしてください。

アプリケーションが最大値の 20 秒で動作しない場合 (前の質問の例を参照)、ロングポーリングタイムアウトを最小で 1 秒まで減らせます。

AWS SDK はすべて、デフォルトの 20 秒のロングポーリングで動作します。Amazon SQS へのアクセスに AWS SDK を使用しない場合、または AWS SDK に短いタイムアウトを特別に設定した場合は、長いリクエストを許可するように、または短いロングポーリングタイムアウトを使用するように、Amazon SQS クライアントを変更しなければならないことがあります。

Q: AmazonSQSBufferedAsyncClient for Java とは何ですか?

AmazonSQSBufferedAsyncClient for Java には AmazonSQSAsyncClient インターフェイスが実装され、以下のようないくつかの重要な機能が追加されています。

  • アプリケーションに変更を加えることなく、複数の SendMessage、DeleteMessage、または ChangeMessageVisibility といったリクエストに対して自動バッチ処理を実行する。
  • ローカルバッファにメッセージをプリフェッチする。アプリケーションは、Amazon SQS からメッセージが取り出されるのを待たずに直ちにメッセージを処理できる。

こうした自動バッチ処理とプリフェッチの連携によって、スループットが向上してアプリケーションのレイテンシーが減少するほか、Amazon SQS リクエストが減り、コストが削減されます。詳細については、『Amazon SQS 開発者ガイド』の「クライアント側のバッファリングとリクエストのバッチ処理」を参照してください。

現在、Amazon SQS Buffered Asynchronous Client では FIFO キューをサポートしていません。

Q: AmazonSQSBufferedAsyncClient for Java はどこでダウンロードできますか?

AmazonSQSBufferedAsyncClient for Java は、AWS SDK for Java の一部としてダウンロードできます。

Q: AmazonSQSBufferedAsyncClient for Java を使用する際にアプリケーションを書き換える必要がありますか?

いいえ。AmazonSQSBufferedAsyncClient for Java は、既存の AmazonSQSAsyncClient のドロップインリプレースメントとして実装されます。

最新の AWS SDK を使用できるようアプリケーションを更新し、クライアントを AmazonSQSAsyncClient から AmazonSQSBufferedAsyncClient for Java に変更されるなら、ご使用のアプリケーションで自動バッチ処理とプリフェッチの追加のメリットを利用できるようになります。

Q: Amazon SNS のトピックから通知を受信するために Amazon SQS メッセージキューをサブスクライブするにはどうすればよいですか?

  1. Amazon SQS コンソールで Amazon SQS 標準キューを選択します。
  2. [Queue Actions] で、ドロップダウンリストから [Subscribe Queue to SNS Topic] を選択します。
  3. ダイアログボックスで、[Choose a Topic] ドロップダウンリストからトピックを選択して、[Subscribe] ボタンをクリックします。

詳細については、『Amazon SQS 開発者ガイド』の「Amazon SNS トピックへの Amazon SQS キューのサブスクライブ」を参照してください。

Q: 複数の Amazon SQS キューに同一のメッセージを送信するにはどうすればよいですか?

  1. Amazon SNS を使用してトピックを作成します。
  2. 複数の Amazon SQS 標準キューを作成し、Amazon SNS トピックにサブスクライブします。
  3. メッセージを Amazon SNS トピックに送信するたびに、メッセージが Amazon SQS メッセージキューに送信されます。

これにより、トピックにサブスクライブしているすべての Amazon SQS メッセージキューに、Amazon SNS からメッセージが配信されます。

Q: Amazon SNS では、メッセージの Amazon SQS キューへの少なくとも 1 回の配信が提供されますか?

Amazon SNSは、各メッセージが少なくとも 1 回 Amazon SQS 標準キューに配信されるように設計されています。

Q: メッセージキュー自体は削除せずにメッセージキュー内のすべてのメッセージを削除できますか?

はい。PurgeQueue アクションを使用して Amazon SQS メッセージキューのすべてのメッセージを削除できます。

メッセージキューを消去すると、それまでにそのキューに送信されたすべてのメッセージが削除されます。メッセージキューとその属性は残るため、再設定しなくてもメッセージキューを使い続けることができます。

特定のメッセージのみを削除するには、DeleteMessage アクションまたは DeleteMessageBatch アクションを使用します。


Q: 標準キューFIFO キューの違いは何ですか?

標準キュー

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

sqs-what-is-sqs-standard-queue-diagram

乱れた順序で 1 回以上到着するメッセージをアプリケーションが処理できる限り、多くのシナリオで標準のメッセージキューを使用できます。例えば以下のような場合です。

  • 負荷の高いバックグラウンドの作業からライブユーザーリクエストを分離する: ユーザーはサイズ変更中またはエンコード中にメディアをアップロードできます。
  • 複数のワーカーノードにタスクを割り当てる: クレジットカードの検証リクエストを大量に処理します。
  • 今後の処理のためのバッチメッセージ: データベースに追加する複数のエントリをスケジュールします。

FIFO キュー

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

sqs-what-is-sqs-fifo-queue-diagram



FIFO キューは、以下の例のように、オペレーションとイベントの順序が重要である場合、または重複が許されない場合に、アプリケーション間のメッセージングを強化するために設計されています。

  • ユーザーが入力したコマンドが正しい順序で実行されていることを確認します。
  • 価格の変更を正しい順序で送信して、正しい製品価格を表示します。
  • アカウントを登録する前に受講者がコースに登録できないようにします。

Q: FIFO キューを利用できるリージョンはどれですか?

FIFO キューは、現在米国西部 (オレゴン)、米国東部 (オハイオ)、米国東部 (バージニア北部)、欧州 (アイルランド) リージョンで利用できます。この機能は、今後数か月のうちにさらに多くのリージョンで利用可能になる予定です。

Q: メッセージのコピーはいくつ送られてきますか?

FIFO キューは、重複メッセージがないように設計されています。ただし、特定のシナリオではメッセージの生産者によって重複が起きることもあります。例えば生産者がメッセージを送信し、応答がない場合に、同じメッセージを再送信する場合などです。Amazon SQS API には、メッセージの生産者が重複して送信しないようにする重複排除機能が用意されています。メッセージの生産者によって発生した重複は、5 分間の重複排除間隔で削除されます。

標準キューについては、重複したメッセージのコピーを受信することもあります (少なくとも 1 回の配信)。標準キューを使用する場合は、アプリケーションがべき等性を持つように設計する必要があります (つまり、同じメッセージを複数回処理したときにアプリケーションが悪影響を受けてはいけません)。

Q: 以前使用していた Ama on SQS クエリは FIFO キューに変わるのですか?

いいえ。Amazon SQS 標準キュー (既存のキューの新しい名称) は、変わらないままで、標準キューをこれまで通り作成できます。これらのキューでは引き続き、最高レベルのスケーラビリティとスループットが提供されますが、順序保証はなく、重複が発生することがあります。

標準キューは、複数のべき等消費者との作業配分など、多くのシナリオに適しています。

Q: 既存の標準キューを FIFO キューに変換できますか?

いいえ。作成時にキューのタイプを選択する必要があります。ただし、FIFO キューに移行することはできます。詳細については、『Amazon SQS 開発者ガイド』の「Moving From a Standard Queue to a FIFO Queue」を参照してください。

Q: Amazon SQS FIFO キューには下位互換性がありますか?

FIFO キューの機能を利用するには、最新の AWS SDK を使用している必要があります。

FIFO キューでは、標準キューと同じ API アクションが使用され、メッセージの受信と削除の仕組みや可視性タイムアウトの変更も同じです。ただし、メッセージの送信時には、メッセージグループ ID を指定する必要があります。詳細については、『Amazon SQS 開発者ガイド』の「FIFO Queue Logic」を参照してください。

重要: 既存の標準キューを FIFO キューに変換することはできません。移行するには、アプリケーション用に新しい FIFO キューを作成するか、既存の標準キューを削除して FIFO キューとして再作成する必要があります。詳細については、『Amazon SQS 開発者ガイド』の「Moving from a Standard Queue to a FIFO Queue」を参照してください。

Q: Amazon SQS FIFO キューは、どの AWS のサービスや外部サービスと互換性がありますか?

Amazon SQS に通知を送信する AWS のサービスや外部サービスの一部では、FIFO キューをターゲットとして設定できるものの、FIFO キューと互換性がない場合があります。

AWS のサービスの以下の機能では、現在 FIFO キューとの互換性がありません。

FIFO キューと他のサービスの互換性に関する詳細については、サービスドキュメントをご覧ください。

Q: Amazon SQS FIFO キューは、Amazon SQS Buffered Asynchronous Client、Amazon SQS Extended Client Library for Java、または Amazon SQS Java Message Service (JMS) クライアントと互換性がありますか?

FIFO キューは、現在は Amazon SQS Buffered Asynchronous Client と互換性がありません。

Amazon SQS Extended Client Library for Java および Amazon SQS Java Message Service (JMS) クライアントとは互換性があります。

Q: Amazon SQS FIFO キューがサポートしている AWS CloudWatch メトリクスはどれですか?

FIFO キューでは標準キューがサポートしているすべてのメトリクスをサポートしています。FIFO キューについては、すべての近似メトリクスで正確な数が戻されます。例えば、以下の AWS CloudWatch メトリクスがサポートされています。

  • ApproximateNumberOfMessagesDelayed – キュー内の、遅延が発生したためにすぐに読み取ることができないメッセージの数。
  • ApproximateNumberOfMessagesVisible – キューから取得可能なメッセージの数。
  • ApproximateNumberOfMessagesNotVisible – 転送中の (クライアントに送信されたが、まだ削除されていない、または可視性ウィンドウの末尾にまだ到達していない) メッセージの数。

Q: メッセージグループとは何ですか?

メッセージは FIFO キュー内で別個の、順序が付けられた「バンドル」にグループ化されます。メッセージグループ ID ごとに、すべてのメッセージが厳密な順序で送受信されます。ただし、異なるメッセージグループ ID 値を持つメッセージは、順序を無視して送受信される場合があります。メッセージグループ ID をメッセージに関連付ける必要があります。メッセージグループ ID を指定しないと、アクションは失敗します。

複数のホスト (または同じホスト上の異なるスレッド) が、同じメッセージグループ ID を持つメッセージを FIFO キューに送信した場合、Amazon SQS は到着順にメッセージを配信して処理に回します。Amazon SQS がメッセージの送受信の順序を確実に保つようにするには、複数の送信者が必ず各メッセージを一意のメッセージグループ ID で送信するようにします。 

Q: Amazon SQS FIFO キューは複数の生産者をサポートしていますか?

はい。1 つまたは複数の生産者が FIFO キューにメッセージを送信できます。メッセージは Amazon SQS で正常に受信された順序で保管されます。

複数の生産者が、SendMessage アクションまたは SendMessageBatch アクションからの成功応答を待たずに、メッセージを並行に送信する場合、その生産者間の順序が保たれない場合があります。SendMessage アクションまたは SendMessageBatch アクションの応答には最終的な順序シーケンスが含まれます。FIFO キューはこれを使用してキューにメッセージを配置します。そのため複数の並行の生産者コードによってキューにおける最終的なメッセージの順序を決定できます。

Q: Amazon SQS FIFO キューは複数の消費者をサポートしていますか?

設計上、Amazon SQS FIFO キューでは、同じメッセージグループからのメッセージを同時に複数の消費者に提供することはありません。ただし、FIFO キューに複数のメッセージグループが存在する場合、並列の消費者を利用して、別のメッセージグループからのメッセージを別のコンシューマーに提供するよう Amazon SQS を設定できます。

Q: FIFO キューではデッドレターキューを使用できますか?

はい。ただし、FIFO キューでは FIFO デッドレターキューを使用する必要があります。(同様に、標準デッドレターキューは標準キューでのみ使用できます。)

Q: Amazon SQS FIFO キューのスループット制限はどのくらいですか?

バッチ処理なしでは、FIFO キューは、1 秒あたり最大 300 件のメッセージ (1 秒あたり 300 件のSendMessage、ReceiveMessage、または DeleteMessage のオペレーション) をサポートできます。オペレーションあたり 10 件のメッセージという最大バッチ処理を利用すれば、FIFO キューは、1 秒あたり最大 3,000 件のメッセージをサポートできます。Amazon SQS 標準キューのスループットには上限がありません。

Q: FIFO キュー属性に固有の制限はありますか?

FIFO キューの名前は .fifo サフィックスで終わる必要があります。このサフィックスはキュー名の制限である 80 文字には含まれません。キューが FIFO であるかどうかを確認するには、キュー名がサフィックスで終わるかどうかをチェックします。


Q: データを保存している Amazon SQS のストレージをどの程度信頼できますか?

Amazon SQS では、すべてのメッセージキューとメッセージを、可用性の高い単一の AWS リージョン内で、冗長性のある複数のアベイラビリティーゾーン (AZ) に保存しています。そのため単一のコンピュータ、ネットワーク、AZ などの障害により、SQS メッセージがアクセスできなくなることはありません。詳細については、Amazon Relational Database Service User GuideRegions and Availability Zones を参照してください。

Q:メッセージキューにあるメッセージのセキュリティを確保するにはどうすればよいですか?

認証メカニズムにより、Amazon SQS メッセージキューに保存されているメッセージが不正アクセスから保護されます。誰がメッセージをメッセージキューに送信できるか、またメッセージキューから誰がメッセージを受信できるかを制御できます。セキュリティを強化するため、メッセージキューに配置する前にメッセージを暗号化するアプリケーションを構築できます。

Amazon SQS には、独自のリソースベースのアクセス権限システムがあり、AWS Identity and Access Management (IAM) のポリシーと同じ言語で記述されたポリシーが使用されます。例えば、IAM ポリシーと同じように、変数を使用できます。詳細については、『Amazon SQS 開発者ガイド』の「Amazon SQS ポリシーの例」を参照してください。

Amazon SQS は、SSL プロトコルおよび Transport Layer Security (TLS) プロトコル経由の HTTP (HTTPS) に対応しています。ほとんどのクライアントでは、コードまたは設定を変更することなく、TLS の新しいバージョンに自動的にネゴシエートできます。Amazon SQS では、すべてのリージョンで Transport Layer Security (TLS) プロトコルのバージョン 1.0、1.1、1.2 に対応しています。

Q: ReceiveMessage オペレーションと DeleteMessage オペレーションが別にあるのはなぜですか?

Amazon SQS がお客様にメッセージを返すと、実際にメッセージが受信されたかどうかにかかわらず、そのメッセージはメッセージキューに残ります。メッセージの削除はお客様の側で行ってください。削除リクエストで、お客様がメッセージの処理を終えたことを確認します。

メッセージを削除しないと、Amazon SQS は別の受信リクエストを受信したときに、そのメッセージを再配信します。詳細については、Amazon SQS 開発者ガイドVisibility Timeout を参照してください。

Q: 削除したメッセージを再受信することはできますか?

いいえ。FIFO キューでは重複メッセージは発生しません。

標準キューの場合、まれな状況において、以前に削除したメッセージを再受信することがあります。これは、DeleteMessage オペレーションでメッセージのコピーがすべて削除されないまれな状況で発生することがあります。理由は、削除時に Amazon SQS の分散システムに含まれるいずれかのサーバーを利用できなかったためです。このメッセージのコピーが再配信される場合があります。標準キューを使用する場合は、アプリケーションがべき等性を持つ (つまり、削除済みメッセージを再受信した場合にエラーや不一致が発生しない) ように設計する必要があります。

Q: 以前に削除したメッセージに対して DeleteMessage リクエストを発行するとどうなりますか?

以前に削除したメッセージに対して DeleteMessage リクエストを発行すると、Amazon SQS は "成功" という応答を返します。


Q: Amazon SQS のサーバー側の暗号化 (SSE) にはどのような利点がありますか?

サーバー側の暗号化 (SSE) を使うと、機密データを暗号化されたキューで送信できます。SSE では、AWS Key Management Service (AWS KMS) で管理されたキーを使用して、Amazon SQS キューのメッセージの内容を保護できます。SSE では、Amazon SQS でメッセージを受信した時点ですぐに暗号化します。メッセージは暗号化された形式で保存され、Amazon SQS は許可された消費者に送信された場合のみメッセージを復号化します。

AWS KMS は、安全で可用性の高いハードウェアとソフトウェアを組み合わせて、クラウド向けに拡張されたキー管理システムを提供します。

AWS KMS を使用すると、以下のような利点があります。

  • カスタマーマスターキー (CMK) を自分で作成したり管理したりできます。
  • Amazon SQS で AWS 管理の CMK を使用することもできます。これは、各アカウントおよびリージョンで一意となります。 
  • AWS KMS のセキュリティ基準は、暗号化に関連するコンプライアンス要件を満たすのに役立ちます。

詳細については、以下のリソースを参照してください。

Q: SSE のキューを利用できるリージョンはどれですか?

Amazon SQS の SSE は、米国東部 (バージニア北部とオハイオ) と米国西部 (オレゴン) リージョンで利用できます。この機能は、今後数か月のうちにさらに多くのリージョンで利用可能になる予定です。

Q: 新規または既存の Amazon SQS キューで SSE を有効にするには、どうすればよいですか?

Amazon SQS API を使用して新規または既存のキューで SSE を有効にするには、CreateQueue または SetQueueAttributes アクションの KmsMasterKeyId 属性を設定して、AWS 管理の CMK またはカスタム CMK のカスタマーマスターキー (CMK) ID (エイリアス、エイリアス ARN、キー ID、またはキー ARN) を指定します。

詳細な手順については、Amazon SQS 開発者ガイドCreating an Amazon SQS Queue with Server-Side Encryption および Configuring Server-Side Encryption (SSE) for an Existing Amazon SQS Queue を参照してください。

Q: どの Amazon SQS キュータイプで SSE を使用できますか?

標準キューと FIFO キューの両方が SSE をサポートしています。

Q: Amazon SQS で SSE を使用するには、どのような権限が必要ですか?

SSE を使用するには、AWS KMS のキーポリシーを設定し、キューの暗号化とメッセージの暗号化/復号化を許可する必要があります。

キューで SSE を有効にするには、Amazon SQS またはカスタム CMK の AWS 管理のカスタマーマスターキー (CMK) を使用できます。詳細については、AWS KMS 開発者ガイドカスタマーマスターキーを参照してください。

暗号化されたキューにメッセージを送信する場合、生産者には CMK に対する kms:GenerateDataKey および kms:Decrypt 権限が必要です。

暗号化されたキューからメッセージを受信する場合、消費者には、指定されたキューのメッセージを暗号化するのに使用される CMK に対して、kms:Decrypt 権限が必要です。キューがデッドレターキューとして使用される場合、消費者には、ソースキューのメッセージを暗号化するのに使用される CMK に対しても kms:Decrypt 権限が必要です。

詳細については、What Permissions Do I Need to Use SSE? (Amazon SQS 開発者ガイド) を参照してください。

Q: Amazon SQS で SSE を使用するには料金がかかりますか?

追加の Amazon SQS 料金はありません。ただし、Amazon SQS から AWS KMS への呼び出しには料金が発生します。詳細については、AWS Key Management Service の料金を参照してください。

AWS KMS の使用料金は、キューに設定されているデータキーの再利用期間によって異なります。詳細については、How Do I Estimate My AWS KMS Usage Costs? (Amazon SQS 開発者ガイド) を参照してください。

Q: Amazon SQS の SSE は何を暗号化し、その暗号化はどのように行われますか?

SSE は、Amazon SQS キュー内のメッセージ本文を暗号化します。

SSE は以下のコンポーネントを暗号化しません。

  • キューのメタデータ (キュー名と属性)
  • メッセージのメタデータ (メッセージ ID、タイムスタンプ、属性)
  • キュー単位のメトリクス

Amazon SQS では、Amazon SQS またはカスタム CMK の AWS 管理のカスタマーマスターキー (CMK) を基にデータキーを生成し、設定可能な時間範囲 (1 分~24 時間) でメッセージのエンベロープ暗号化および複合化を行います。

Q: Amazon SQS の SSE では、メッセージの暗号化にどのようなアルゴリズムを使用していますか?

SSE では AES-GCM 256 アルゴリズムを使用しています。

Q: SSE は Amazon SQS の機能に干渉しますか?

メッセージを暗号化すると、権限のないユーザーや匿名ユーザーはその内容を利用できなくなります。メッセージの暗号化は、Amazon SQS の通常の機能には影響しません。

  • メッセージは、キューの暗号化が有効になった後に送信された場合のみ暗号化されます。Amazon SQS は、バックログされたメッセージを暗号化しません。
  • 暗号化されたメッセージは、そのキューの暗号化が無効になっていても暗号化されたままです。

Q: 暗号化された Amazon SQS キューは、暗号化されていないキューやデッドレターキューとはどのように共存できますか?

メッセージをデッドレターキューに移動しても、その暗号化には影響しません。

  • 暗号化されたソースキューから暗号化されていないデッドレターキューにメッセージを移動すると、メッセージは暗号化されたままになります。
  • 暗号化されていないソースキューから暗号化されたデッドレターキューにメッセージを移動すると、メッセージは暗号化されていないままになります。

Q: SSE では、1 秒あたりのトランザクション (TPS) や、Amazon SQS で作成できるキューの数を制限しますか?

SSE では Amazon SQS のスループット (TPS) を制限しません。作成できる SSE キューの数は、以下によって制限されます。

  • データキーの再利用期間 (1 分~24 時間)。
  • AWS KMS アカウント単位の制限 (デフォルトでは 100 TPS)。
  • キューにアクセスする IAM ユーザーまたはアカウントの数。
  • サイズの大きいバックログの存在 (バックログが大きくなると AWS KMS の呼び出しが増えます)。

例えば、以下の制限項目を想定してみましょう。

  • データキーの再利用期間を 5 分 (300 秒) に設定します。
  • KMS アカウントのデフォルトの AWS KMS TPS 制限は 100 TPS です。
  • バックログなしで Amazon SQS キューを使用しており、すべてのキューへの SendMessage または ReceiveMessage アクション用に 1 名の IAM ユーザーがいます。

この場合、SSE を使用した Amazon SQS キューの理論上の最大値は以下のように計算できます。

300 秒 × 100 TPS / 1 名の IAM ユーザー = 30,000 キュー

Q: AWS KMS の使用料金をどのように見積もることができますか?

コストを予測し、AWS の請求をより正確に把握するため、Amazon SQS が CMK を使用する頻度を調べることができます。

注意: 以下の計算式を使用することで予想されるコストを大まかに把握することができますが、Amazon SQS の分散性により、実際のコストはもっと高くなる可能性もあります。

キューごとの API リクエスト数 (R) を計算するには、以下の数式を使用します。

R = B / D × (2 × P + C)

B = 請求期間 (秒)

D = データキーの再利用期間 (秒)

P = Amazon SQS キューに送信するプリンシパルの生産数

C = Amazon SQS キューから受信するプリンシパルの消費数

重要: 通常、プリンシパルの生産では、プリンシパルの消費よりも 2 倍のコストが発生します。詳細については、How Does the Data Key Reuse Period Work? (Amazon SQS 開発者ガイド) を参照してください。

生産者と消費者の IAM ユーザーが異なる場合、コストが増加します。

計算例については、How Do I Estimate My Customer Master Key (CMK) Usage Costs? (Amazon SQS 開発者ガイド) を参照してください。料金の詳細については、AWS KMS の料金を参照してください。


Q: Amazon SQS は PCI DSS 認定を受けていますか?

はい。Amazon SQS は PCI DSS レベル 1 の認定を受けています。詳細については、PCI 準拠を参照してください。

Q: Amazon SQS は HIPAA に対応していますか?

はい、AWS では HIPAA 準拠プログラムを拡張し、Amazon SQS を HIPAA 対応サービスとして追加しました。AWS と事業提携契約 (BAA) を締結している場合は、Amazon SQS を使用して独自の HIPAA 準拠アプリケーションの構築、通信中のデータの保存、および (保護医療情報 (PHI) が含まれるメッセージを含む) メッセージの送信を行うことができます。

すでに AWS と BAA を締結している場合は、今すぐ Amazon SQS の使用を開始することができます。BAA を締結していない場合、またはお使いの HIPAA 準拠アプリケーションへの AWS の使用に関してご質問がある場合は、詳細をお問い合わせください。

注意: Amazon SQS 経由での PHI の転送を望まない場合 (または 256 KB より大きなメッセージがある場合)、代わりに Amazon SQS Extended Client Library for Java を使用して Amazon S3 経由で Amazon SQS メッセージペイロードを送信することもできます (Amazon S3 は HIPAA 対応サービスです (Amazon S3 Transfer Acceleration の使用を除く))。詳細については、『Amazon SQS 開発者ガイド』の「Java 用 Amazon SQS 拡張クライアントライブラリの使用」を参照してください。


Q: Amazon SQS メッセージキューにはどのくらいの期間メッセージを保持できますか?

メッセージの保持期間を延長すると柔軟性が向上し、メッセージの作成から消費までの間隔を延ばすことができます。

Amazon SQS メッセージを保持する期間を、1 分間~14 日間の範囲内で設定できます。デフォルトでは 4 日間になっています。メッセージの保持期間が終了すると、お客様のメッセージは自動的に削除されます。

Q: メッセージをより長い期間保持するには Amazon SQS をどのように設定すればよいですか?

メッセージ保持期間を設定するには、コンソールまたは Distributiveness メソッドを使用して MessageRetentionPeriod 属性を設定します。この属性を使用して、メッセージが Amazon SQS に保持される秒数を指定します。

MessageRetentionPeriod 属性を使用すると、メッセージの保持期間を 60 秒間 (1 分間)~1,209,600 秒間 (14 日間) の範囲内で設定できます。このメッセージ属性の使い方の詳細については、Amazon SQS API リファレンスを参照してください。

Q: Amazon SQS の最大メッセージサイズを設定するにはどうすればよいですか?

最大メッセージサイズを設定するには、コンソールまたは SetQueueAttributes メソッドを使用して MaximumMessageSize 属性を設定します。この属性で、Amazon SQS メッセージに含めることができるバイト数の限度を指定します。この限度は 1,024 バイト (1 KB)~262,144 バイト (256 KB) の間の値に設定します。詳細については、『Amazon SQS 開発者ガイド』の「Amazon SQS メッセージ属性の使用」を参照してください。

256 KB を超えるメッセージを送信するには、Amazon SQS Extended Client Library for Java を使用します。このライブラリにより、Amazon S3 のメッセージペイロード (最大 2 GB) への参照を含む Amazon SQS メッセージを送信できます。

Q: メッセージにはどのような種類のデータを使用できますか?

Amazon SQS メッセージとして送信できるのは、最大 256 KB のテキストデータ (XML、JSON、未フォーマットのテキストなど) です。以下の Unicode 文字を使用できます。

#x9 | #xA | #xD | [#x20~#xD7FF] | [#xE000~#xFFFD] | [#x10000~#x10FFFF]

詳細については、XML 1.0 の仕様を参照してください。

Q: Amazon SQS メッセージキューはどのくらいのサイズにすることができますか?

単一の Amazon SQS メッセージキューに含めるメッセージの数に制限はありません。ただし、転送中メッセージの数については標準キューで 120,000、FIFO キューで 20,000 という制限があります。メッセージは、コンポーネントを消費することによりキューから取得されたものの、キューから削除されていない場合に転送中になります。

Q: 作成できるメッセージキューの数はいくつですか?

作成できるメッセージキューの数は無制限です。

Amazon SQS メッセージキューの名前にサイズ制限はありますか?

キュー名は 80 文字に制限されています。

Q: Amazon SQS メッセージキューの名前に何か制約はありますか?

英数字、ハイフン (-)、および下線 (_) を使用できます。

Q: メッセージキュー名は再利用できますか?

メッセージキューの名前は AWS のアカウントとリージョンに対して一意である必要があります。同じ名前のメッセージキューを削除した後に、メッセージキューの名前を再利用できます。


Q: メッセージキューを共有するにはどうすればよいですか?

共有するメッセージキューとアクセスポリシーステートメントを関連付けます (また、付与する権限を指定します)。Amazon SQS では、アクセスポリシーステートメントを作成および管理するため、以下の API を利用できます。

  • AddPermission
  • RemovePermission
  • SetQueueAttributes
  • GetQueueAttributes

詳細については、Amazon SQS API リファレンス を参照してください。

Q: 共有されたキューアクセスに対する支払いは誰が行いますか?

共有されたキューアクセスについては、メッセージキュー所有者にお支払いいただきます。

Q: メッセージキューを共有できる別の AWS ユーザーをどのように識別できますか?

Amazon SQS API は、AWS アカウント番号により AWS ユーザーを識別します。

Q: メッセージキューの共有先の AWS ユーザーに何を伝える必要がありますか?

他の AWS ユーザーとメッセージキューを共有するには、共有するメッセージキューの完全 URL を伝える必要がありますCreateQueue オペレーションや ListQueues オペレーションは、応答でこの URL を返します。

Q: Amazon SQS は匿名アクセスに対応していますか?

はい。匿名ユーザーによるメッセージキューへのアクセスを許可するアクセスポリシーを設定できます。

Q: どのようなときに Permissions API を使用しますか?

Permissions API は、開発者がメッセージキューへのアクセスを共有するためのインターフェイスとなります。ただし、この API では、条件付きアクセスやより高度なユースケースを許可できません。

Q: どのようなときに、JSON オブジェクトと共に SetQueueAttributes オペレーションを使用しますか?

SetQueueAttributes オペレーションは、フルアクセスポリシー言語に対応しています。例えば、このポリシー言語を使用すると、メッセージキューへのアクセスを IP アドレスや時間帯によって制限できます。詳細については、『Amazon SQS 開発者ガイド』の「Amazon SQS ポリシーの例」を参照してください。


Q: Amazon SQS は、どのリージョンで利用できますか?

対象となるサービスリージョンについては、AWS グローバルインフラストラクチャの製品およびサービス一覧 (リージョン別) を参照してください。
注意: FIFO キューは、現在米国西部 (オレゴン)、米国東部 (オハイオ)、米国東部 (バージニア北部)、欧州 (アイルランド) リージョンでのみ利用できます。この機能は、今後数か月のうちにさらに多くのリージョンで利用可能になる予定です。

Q: 異なるリージョンのキュー間でメッセージを共有できますか?

いいえ。各リージョンの Amazon SQS メッセージキューは相互に独立しています。

Q: リージョン間で料金の違いはありますか?

Amazon SQS は、中国 (北京) を除いたすべてのリージョンで同一料金です。詳細については、Amazon SQS 料金を参照してください。

Q: さまざまなリージョン間での料金構成はどのようなものですか?

Amazon SQS と同じリージョンにある Amazon EC2 や AWS Lambda の間でデータを転送する場合は無料です。

Amazon SQS と別のリージョンにある Amazon EC2 や AWS Lambda の間でデータを転送する場合は、通常のデータ転送料金が課金されます。詳細については、Amazon SQS 料金を参照してください。