Jayendra’s Blog
この記事は自己学習用に「AWS Simple Queue Service – SQS – Certification(Jayendra’s Blogより)」を日本語に訳した記事です。
Simple Queue Service – SQS
- Amazon SQS は高可用性の分散キューシステムです。
- キューは、処理を待つメッセージの一時的なリポジトリであり、コンポーネントプロデューサとコンシューマの間のバッファとして機能します。
- Amazon SQS
- コンピュータ間の転送中にメッセージを格納するための、信頼性の高いスケーラブルなホスト型キューを提供します。
- 各コンポーネントを同時に使用できるようにすることなく、送受信するアプリケーションの分散コンポーネントのフォールトトレラント、疎結合、柔軟性を提供します。
- 分離コンポーネントを使用した分散アプリケーションの構築に役立ちます。
- 管理オーバーヘッドが不要で構成が少ない
- セキュリティのための HTTP over SSL (HTTPS) およびトランスポート層セキュリティ (TLS) プロトコルをサポートします。
- SQS には2種類のキュー (標準および FIFO) が用意されています
SQS FIFO キューの機能とキーポイント
- ブログ投稿-SQS FIFO キューを参照してください
SQS 標準キュー機能とキーポイント
- 冗長インフラストラクチャ
- メッセージを格納するための信頼性の高いスケーラブルなホストキューを提供
- 常に利用できるように設計され、メッセージを配信する
- 失敗したセーフキューにメッセージを格納する機能を提供します。
*メッセージへの高い同時アクセス
- 1回限りの配信
- 各メッセージの配信を1回以上保証
- 冗長性と高可用性を実現するために、メッセージのコピーを複数のサーバーに格納
- メッセージのコピーを格納しているサーバーが使用できなくなった場合や、そのサーバーでメッセージのコピーが削除されていない場合は、メッセージのコピーを重複して配信する場合があります
- アプリケーションは、重複したメッセージを処理し、同じメッセージを複数回処理する場合に悪影響を受けることがないように、多重性を持つように設計する必要があります。
- メッセージ属性
- SQS メッセージには、最大10個のメタデータ属性を含めることができます。
- 名前型の値のトリプルの形式をとる
- メッセージの本文を記述するメタデータから分離するために使用できます。
- プロセスの処理方法を理解する前に、アプリケーションがメッセージ全体を検査する必要がないため、より高速で効率の高い情報を処理および保存することができます。
- メッセージサンプル
- キューからメッセージを取得する場合の動作は、短い (標準) ポーリング、既定の動作、または長いポーリングが使用されるかどうかによって異なります。
- 短いポーリングで、
- SQS は、(重み付けされたランダムな分布に基づいて) サーバのサブセットのみをサンプリングし、それらのサーバからのメッセージを返します。
- 受信要求は、キュー内のすべてのメッセージを返さない場合があります。しかし、後続の受信要求はメッセージを返す
- 長いポーリングでは、
- 要求は指定された時間の間持続し、メッセージが利用できるとすぐにリターンはそれによりメッセージがキューに住むことを持っている費用および時間を減らす
- バッチ
- SQS は、単一のメッセージの価格を充電しながら、単一のバッチで最大10のメッセージをクラブに役立ちますバッチを送信、受信および削除することができます
- コストを削減し、スループットを向上させることができます。
- キューごとの構成可能な設定
- すべてのキューが同じである必要はありません
- 順序
- メッセージの順序を保持するために最善の努力をしても、メッセージの先入れ先出しを保証するものではありません (UPDATE @ link – SQSは、順序を維持し、一度だけ処理するFIFOキューを提供するようになりました)
メッセージ内にシーケンス情報を配置し、クライアント側で順序を実行することで処理できます。
- メッセージの順序を保持するために最善の努力をしても、メッセージの先入れ先出しを保証するものではありません (UPDATE @ link – SQSは、順序を維持し、一度だけ処理するFIFOキューを提供するようになりました)
- 疎結合
- コンポーネント間の密結合を除去
- メッセージを失うことなく、または各コンポーネントを常に利用できるようにするために、異なるタスクを実行するアプリケーションの分散コンポーネント間でデータを移動する機能を提供します。
- 複数のライターとリーダー
- 同じキューと同時にやり取りする複数のリーダーとライタをサポート
- 表示タイムアウトを使用して、処理中にメッセージをロックし、他のコンシューマが処理できないようにします。
- 可変メッセージサイズ
- テキストの256KB までの任意の形式でメッセージをサポートします。
- 256 KB を超えるメッセージは、s3 または DynamoDB を使用して管理でき、SQS は s3 オブジェクトへのポインタを保持します。
- アクセス制御
- 各キューに対してメッセージを生成および使用できる人のアクセスを制御できます。
- 遅延キュー
- 遅延キューを使用すると、キューにデフォルトの遅延を設定することができます。
- 配信不能キュー
- 配信不能キューは、最大試行回数の後に処理できなかったメッセージのキューです。
- PCI コンプライアンス
- マーチャントまたはサービスプロバイダによるクレジットカードデータの処理、保存、および送信をサポートし、PCI DSS (決済カード業界-データセキュリティ規格) に準拠しているとして検証されています。
SQS ユースケース
- ワークキュー
- 同じ量の作業を同時に処理できない分散アプリケーションのコンポーネントを分離します。
- バッファとバッチ操作
- アーキテクチャにスケーラビリティと信頼性を追加し、メッセージを失うことなく、または待ち時間を増やすことなく、一時的なボリュームスパイクをスムーズに
- 要求オフロード
- 要求をキューして、対話型の要求パスから低速の操作をオフに移動します。
- ファンアウト
- SQS を SNS と組み合わせて、同時処理のために複数のキューに同じメッセージのコピーを並列送信します。
- 自動スケーリング
- SQS キューを使用すると、アプリケーションの負荷を特定し、自動スケーリングと組み合わせることができ、トラフィックの量に応じて EC2 インスタンスをスケーリングまたはスケールアウトできます。
SQS キューのしくみ
- SQS では、キューの作成、削除、メッセージの送受信が可能
- SQS キューは、既定で4日間メッセージを保持します。
- キューは、メッセージが送信されてから1分 ~ 14 日後にメッセージを保持するように構成できます。
- SQS は、次のいずれかのアクションが30日連続で実行されていない場合、通知なしでキューを削除できます。
- SQS では、キューをメッセージで削除できます。
キューとメッセージの識別子
キューの URL
- キューは、同じ AWS アカウント内の一意のキュー名によって識別されます。
- SQS は、各キューにキュー URL 識別子 (たとえば http://sqs.us-east-1.amazonaws.com/123456789012/queue2) を割り当てます。
- キュー上の任意の操作を実行するには、キューの URL が必要です
メッセージ ID
- メッセージ id は、メッセージの識別に役立ちます。
- 各メッセージは、SendMessage 応答と共に SQS が返すシステム割り当てのメッセージ ID を受け取ります。
- メッセージを削除するには、メッセージ ID の代わりにメッセージの受信ハンドルが必要です
- メッセージ ID は100文字以内であることができます
受信ハンドル
- メッセージがキューから受信されると、メッセージを受信するという行為に関連付けられたメッセージと共に、メッセージ自体が受信ハンドルとして返されます。
- メッセージ id ではなく、メッセージを削除したり、メッセージの表示を変更したりするには、受信ハンドルが必要です。
- メッセージが複数回受信されると、受信するたびに別の受信ハンドルが割り当てられ、最新のものが常に使用されます。
可視性タイムアウト
- 動作
- SQS は、コンシューマが受信したメッセージを削除しません。
- システムが分散されているため、コンシューマがメッセージを実際に受信する保証はありません (接続が切断される可能性があるか、コンポーネントがメッセージを受信する前に失敗する可能性があります)。
- コンシューマは、受信して正常に処理されると、キューからメッセージを明示的に削除する必要があります
- メッセージがキューでまだ利用可能であるので、他の消費者は、受け取られて、そして処理することができるでしょう、そして、これは防止される必要があります
- SQS は、可視性タイムアウトを使用して上記の動作を処理します。
- SQS は可視性タイムアウト期間のメッセージの可視性をブロックし、SQS がそのメッセージの受信と処理を他のコンポーネントによって防止する時間です。
- コンシューマは、表示タイムアウトの範囲内でメッセージを削除する必要があります。コンシューマが表示タイムアウトの期限が切れる前にメッセージの削除に失敗した場合、そのメッセージは他のコンシューマに対して再び表示されます。
- 可視性のタイムアウトに関する考慮事項
- SQS がメッセージを返すと、クロックが刻々と開始する
- 各メッセージの処理時間を考慮に入れるのに十分な大きさにする必要があります
- 各キューの既定の表示タイムアウトは30秒で、キューレベルで変更できます。
- メッセージを受信すると、受信ハンドルを使用してキュー全体のタイムアウトを変更せずに、返されたメッセージの特別な表示タイムアウトを設定できます。
- コンシューマーが、現在の可視性のタイムアウト期間内にメッセージを処理できないと考えている場合は、コンシューマーが拡張できます。SQS は、新しい値を使用してタイムアウト期間を再起動します。
- メッセージの可視性タイムアウト拡張は、メッセージの特定の受信にのみ適用され、メッセージのキューまたはそれ以降の受信確認のタイムアウトには影響しません。
- SQS には、キューごとの機内メッセージ数に12万制限がありますが、受信したメッセージは削除されず、それ以降のメッセージは制限に達した後にエラーを受け取ります
メッセージライフサイクル
- コンポーネント1はメッセージ A をキューに送信し、メッセージは SQS サーバー間で冗長に分散されます。
- コンポーネント2がメッセージを処理する準備ができたら、キューからメッセージを取得し、メッセージ A が返されます。メッセージ A が処理されている間はキューに残りますが、可視性タイムアウトの継続時間に対する後続の受信要求には返されません。
- コンポーネント2では、メッセージ A をキューから削除して、表示タイムアウトの有効期限が切れると、受信および処理が行われないようにします。
SQS デザインパターン
優先キューパターン
- SQS を使用して、個々の優先度レベルに対して複数のキューを準備します。
- 優先度の高いキューで、直ちに実行するプロセス (ジョブ要求) を配置します。
- 優先度レベルに応じて、キューのジョブ要求を処理するためのバッチサーバーの数を準備します。
- キューは、プロセスを開始するための時間を遅らせるために使用することができるメッセージ “遅延送信” 機能を持っています。
SQS ジョブオブザーバパターン
- ジョブ要求を SQS メッセージとしてエンキューする。
- バッチサーバーは、SQS からメッセージをキューに取り出して処理します。
- 自動スケーリングを設定すると、CloudWatch を使用して、そのためのトリガとして、SQS メッセージの数を使って、バッチサーバーの数を自動的に増減します。
AWS認定試験の練習問題
- 質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます(これはあなたと異なる場合があります)。
- AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。
- AWSのアップデートのペースを追うためにAWS試験の質問は更新されないため、基礎となる機能が変更されても質問が更新されないことがあります。
- さらなるフィードバック、ディスカッション、修正を可能にします。
- フライト中のトランザクションを永続化するためのアーキテクチャの設計に役立つ AWS サービスはどれですか。
- Elastic IP Address
- SQS
- Amazon CloudWatch
- Amazon ElastiCache
- 会社には、ビデオファイルをオンプレミスシステムから AWS に送信してトランスコードするワークフローがあります。これらは、SQS からトランスコードジョブを Pull する EC2 ワーカーインスタンスを使用します。SQS がこのシナリオに適したサービスであるのはなぜですか。
- SQS はメッセージの順序を保証します。
- SQS は、トランスコード出力を同期的に提供します。
- SQS は、ワーカーインスタンスの正常性をチェックします。
- SQS は、エンコードタスクの水平スケーリングを容易にします。
- Amazon SQS ユース・ケースについて最もよく説明するステートメントはどれですか。
- 運用サーバー (Amazon EC2 インスタンス) で CPU 使用率が 70% に達したときに管理者に電子メール通知を送信するプロセスを自動化する (CloudWatch + SNS + SES)
- 複数のコンポーネントが互いに通信する必要があるが、同じ量の作業を同時に処理できないビデオトランスコーディング web サイトを作成する (SQS は疎結合を提供します)
- 分散 web サービス間で作業を調整し、従業員の経費精算書 (SWF –手順を順番に処理し、手動の手順が必要になる場合があります)
- 複数の国で遅延の少ないエンドユーザーに静的 web コンテンツを配布する (CloudFront + S3)
- アプリケーションは、データ変換サービスを提供します。変換されるデータを含むファイルは、まず Amazon S3 にアップロードされ、その後、スポット EC2 インスタンスのフリートによって変換が行われます。プレミアム顧客が提出したファイルは、最優先で変換する必要があります。どのようにこのようなシステムを実装する必要がありますか?
- 優先度レベルを定義する属性を持つ DynamoDB テーブルを使用します。変換インスタンスは、タスクのテーブルをスキャンし、結果を優先順位レベルで並べ替えます。
- Route53遅延ベースのルーティングを使用して、最も近い変換インスタンスに優先度の高いタスクを送信します。
- 優先度の高いメッセージには、2つの SQS キューを使用し、もう1つは既定の優先度にします。変換インスタンスは、最初に優先度の高いキューをポーリングします。メッセージがない場合は、既定の優先度キューをポーリングします。
- 単一の SQS キューを使用します。各メッセージには、優先度レベルが含まれます。変換インスタンスは優先度の高いメッセージを最初にポーリングします。
- あなたの会社はアマゾンのウェブサービス (AWS) の大きい寄付のウェブサイトを催すことを計画する。多くのデータベース書き込みを作成するトラフィックの大規模で不確定な量を予測します。AWS でホストされているデータベースへの書き込みを削除しないことを確認します。どのサービスを使用する必要がありますか。
- 予想されるピーク書き込みスループットまでのプロビジョニングされた IOPS を持つ Amazon RDS。
- Amazon シンプルキューサービス (SQS) は、書き込みをキャプチャし、キューをデータベースに書き込むためのドレイン
- Amazon ElastiCache は、書き込みがデータベースにコミットされるまで書き込みを保存します。
- Amazon DynamoDB は、予想されるピーク書き込みスループットまで、プロビジョニングされた書き込みスループットを備えています。
- お客様には、Amazon エラスティックコンピュータクラウド (EC2) 上でホストされている web アプリケーションがある aws リージョンへ 10 GB の aws ダイレクトコネクション接続があります。アプリケーションは、acid (原子性、一貫性、分離、耐久性) の一貫性モデルではなく、ベース (基本使用可能、ソフト状態、最終的な一貫性) を使用するオンプレミスのメインフレームデータベースに依存しています。データベースが書き込みのボリュームを処理できないため、アプリケーションで望ましくない動作が発生しています。どのようにして、最も費用対効果の高い方法で、オンプレミスのデータベースリソースの負荷を軽減できますか。
- AWS の オンプレミスデータベースと Hadoop クラスター間の同期メカニズムとして、Amazon エラスティックマップの削減 (EMR) S3DistCp を使用します。
- Amazon SQS キューに書き込むようにアプリケーションを変更し、ワーカープロセスを開発して、キューをオンプレミスデータベースにフラッシュします。
- DynamoDB を使用して、マップ関数を使用してオンプレミスデータベースに書き込む EMR クラスターをフィードするようにアプリケーションを変更します。
- AWS で RDS のリードレプリカデータベースをプロビジョニングし、データパイプラインを使用して2つのデータベースの書き込みを処理して同期します。
- 組織は、SQS を使用して “modularqueue” という名前のキューを作成しました。組織は、キュー上の SendMessage、ReceiveMessage、DeleteMessage、GetQueueAttributes、SetQueueAttributes、AddPermission、および RemovePermission などの操作を実行していません。このシナリオでは何が起こるでしょうか。
- AWS SQS は、キューでの非アクティブの15日後に通知を送信します
- AWS SQS は、通知なしで30日後にキューを削除することができます
- AWS SQS は30日後にキューの非アクティブをマークします
- AWS SQS は、2週間後にユーザーに通知し、3週間後にキューを削除します。
- ユーザーが AWS SQS を使用してサービスを切り離す。以下のオペレーションのうち、SQS でサポートされていない操作はどれですか。
- SendMessageBatch
- DeleteMessageBatch
- createqueue
- DeleteMessageQueue
- ユーザーが SQS を使用して “awsmodule” という名前のキューを作成しました。キューのコンシューマの1つが3日間ダウンし、利用可能になります。そのコンポーネントはキューからメッセージを受信しますか?
- はい、デフォルトでは SQS は4日間のメッセージを格納するためです。
- いいえ、デフォルトでは SQS は1日のみメッセージを保存します。
- いいえ、SQS はその時点で利用可能なコンシューマにメッセージを送信するため、
- はい、SQS はすべてのコンシューマに配信されるまでメッセージを削除しません。
- ユーザーが AWS SQS を使用して、米国東部リージョンに “queue2” という名前のキューを作成しました。ユーザーの AWS アカウント ID は123456789012です。ユーザーがこのキューで何らかのアクションを実行する場合は、以下のキュー URL を使用する必要があります。
- http://sqs.us-east-1.amazonaws.com/123456789012/queue2
- http://sqs.amazonaws.com/123456789012/queue2
- http://sqs,123456789012.us-east-1.amazonaws.com/queue2
- http://123456789012.sqs.us-east-1.amazonaws.com/queue2
- ユーザーが SQS を使用して “myqueue” という名前のキューを作成しました。キューにパブリッシュされた4つのメッセージは、コンシューマによってまだ受信されていません。ユーザーがキューを削除しようとすると、どうなるでしょうか。
- ユーザーは、キューを手動で削除することはできません。AWS は、キューの非アクティブの30日後にそれを削除します
- これは、キューを削除します
- 削除を開始しますが、すべてのメッセージが自動的に削除されるまで、4日間削除します。
- これは、ユーザーにメッセージを最初に削除するように頼みます
- ユーザーは、NoSQL データベースにデータを送信するために必要なアプリケーションを開発しました。ユーザーは、アプリケーションがデータの処理と送信を保持するが、DB の受信確認を待たずに送信するデータを切り離す必要があります。このシナリオでは、以下に挙げるアプリケーションのうちどれが役立ちますか。
- AWS Simple Notification Service
- AWS Simple Workflow
- AWS Simple Queue Service
- AWS Simple Query Service
- SQS を使用して顧客の注文を処理するオンラインストアを AWS に構築しています。バックエンドシステムは、顧客の注文が置かれているのと同じ順序でこれらのメッセージを必要とします。どのように達成することができますか?
- SQS ではこれを行うことはできません。
- 各メッセージのシーケンス情報を使用できます。
- あなたは、SQS でこれを行うことができますが、また、SWF を使用する必要があります
- メッセージは既定で同じ順序で到着します
- ユーザーが写真編集ソフトウェアを作成し、EC2 でホストしました。ソフトウェアは、写真のフォーマットと解像度についてのユーザーからの要求を受け入れ、それに応じて画像を強化するために S3 にメッセージを送信します。以下の aws サービスは、このシナリオで aws インフラストラクチャを使用してスケーラブルなソフトウェアを作成するのに役立ちます。
- AWS Glacier
- AWS Elastic Transcoder
- AWS Simple Notification Service
- AWS Simple Queue Service
- バッチプロセッサとして使用される EC2 インスタンス間でメッセージキューを設定するには、単純なキューサービス (SQS) を使用したバッチ処理ソリューションのアーキテクチャ図を参照してください。クラウドウォッチは、ジョブ要求の数 (キューに置かれたメッセージ) を監視し、自動スケーリンググループは、クラウドウォッチアラームに設定されたパラメータに基づいて、バッチサーバーを自動的に追加または削除します。このアーキテクチャを使用して、コスト効果の高い効率的な方法で次の機能を実装できますか。
- メッセージを受信するビジー EC2 インスタンスがデイジーチェーンセットアップの次のインスタンスに渡されるようにすることにより、並列処理によるジョブ実行の全体的な時間を短縮できます。
- ec2 インスタンスの障害に対するフォールトトレランスの実装メッセージが sqs に残るため、ec2 インスタンスのリカバリを続行すると、メッセージを S3 にバックアップすることにより、sqs 障害に対するフォールトトレランスを実装できます。
- メッセージを SOS 経由で交換することによって、バッチ内の EC2 インスタンス間でのメッセージ受け渡しを実装します。
- ジョブ要求数を持つ EC2 インスタンスの数を自動的に調整するため、コスト効果が向上します。
- プライオリティ・メタデータ・フィールドを SQS メッセージに割り当てることにより、優先度の低いジョブの前に優先度の高いジョブを処理します。
- Amazon SQS では、複数の読者がメッセージを失うことなく同じメッセージキューにアクセスしたり、何度も処理したりできますか。
- ユーザーを一意の id で識別します。
- 独自の暗号化を使用します。
- Amazon SQS キューには、設定可能な可視性タイムアウトがあります。
- 複数のリーダーが同じメッセージキューにアクセスすることはできません。
- ユーザーは、写真編集ソフトウェアを作成し、EC2 上でホストしています。ソフトウェアは、写真のフォーマットと解像度についてのユーザーからの要求を受け入れ、それに応じて画像を強化するために S3 にメッセージを送信します。以下の aws サービスは、このシナリオで aws インフラストラクチャを使用してスケーラブルなソフトウェアを作成するのに役立ちます。
- AWS Elastic Transcoder
- AWS Simple Notification Service
- AWS Simple Queue Service
- AWS Glacier
- 長いメッセージ保持をサポートするために SQS をどのように構成しますか。
- SetQueueAttributes メソッドを使用して MessageRetentionPeriod 属性を設定します。
- ラムダ関数を使用します。
- できませんよ。14日に設定されており、変更することはできません。
- AWS からリクエストする必要があります。
- ユーザーは、NoSQL データベースにデータを送信するために必要なアプリケーションを開発しました。ユーザーは、アプリケーションがデータの処理と送信を保持するが、DB の受信確認を待たずに送信するデータを切り離す必要があります。このシナリオでは、以下に挙げるアプリケーションのうちどれが役立ちますか。
- AWS Simple Notification Service
- AWS Simple Workflow
- AWS Simple Query Service
- AWS Simple Queue Service
- Amazon SQS のキューからメッセージが取得された場合、既定では、他のユーザーがメッセージにアクセスできない時間はどのくらいですか。
- 0秒
- 1時間
- 1日
- 絶えず
- 30秒
- SQS に関する次のステートメントのうち、どれが当てはまりますか。
- メッセージは1回だけ配信され、メッセージは最初の順序で配信されます。
- メッセージは1回だけ配信され、メッセージ配信順序は不定です
- メッセージは1回以上配信され、メッセージは最初の順序で配信されます。
- メッセージが1回以上配信され、メッセージ配信順序が不定 (FIFO キューの導入前)
- amazon sqs キューの amazon sqs メッセージをどのくらいの期間保持できますか。
- 120秒から4週間まで
- 10秒から7日まで
- 60秒から2週間まで
- 30秒から1週間まで
- SQS メッセージが完了するのに5分かかるタスクをトリガーすると、次のプロセスは、メッセージの処理に成功し、重複処理の可能性を最小限に抑えながらキューから削除しますか。
- 可視性のタイムアウトが増加したメッセージを取得し、メッセージを処理し、キューからメッセージを削除します。
- 可視性のタイムアウトが増加したメッセージを取得し、キューからメッセージを削除し、メッセージを処理します。
- 増加した DelaySeconds でメッセージを取得し、メッセージを処理し、キューからメッセージを削除します。
- 増加した DelaySeconds でメッセージを取得し、キューからメッセージを削除し、メッセージを処理します。
- 長時間実行されるジョブは1回だけ処理する必要があります。どのようにこれを行うかもしれない?
- SNS キューを使用して、ジョブを処理するのに十分な長さの可視性タイムアウトを設定します。
- SQS キューを使用して、ジョブの処理に十分な時間を再処理タイムアウトを設定します。
- SQS キューを使用して、ジョブを処理するのに十分な長さの可視性タイムアウトを設定します。
- SNS キューを使用して、ジョブの処理に十分な時間を再処理タイムアウトを設定します。
- Amazon SQS を使用している場合は、空の受信要求が大量に取得されます。これは、あなたのインスタンスに不必要なネットワーク負荷をたくさん作っています。この負荷を軽減するには何ができますか?
- 代わりに、SNS トピックにキューをサブスクライブします。
- 短いポーリングの代わりに、可能な限りポーリングを長時間使用してください。(リンク参照)
- 表示のタイムアウトを短くするように変更します。
- EC2 インスタンスで
sqsd
を使用します。
- 自動スケーリンググループと SQS キューを使用して、非同期処理アプリケーションがあります。自動スケーリンググループは、ジョブキューの深さに従ってスケールされます。ジョブの完了速度が下がったため、自動スケーリンググループのサイズが限界に達しましたが、受信ジョブの速度は増加しませんでした。考えられる問題とは何ですか?
- 入ってくる新しいジョブの中には、不正な形式で処理できないものがあります。(他のオプションはジョブの処理を完全に停止させるので、唯一の合理的なオプションは、最近のメッセージの一部が不正な形式で処理不能でなければならないようです。)
- ルーティングテーブルが変更され、作業者はイベントをもう処理できません。(変更された場合、どのジョブも処理されません)
- 誰かが、ワーカーグループ内のインスタンスの IAM ロールポリシーを変更し、キューにアクセスするためのアクセス許可を破った。(IAM ロールが変更された場合、ジョブは処理されません)
- スケーリングメトリックが正しく機能していません。(スケーリングメトリックは、インスタンスが増加する原因となったため、正常に機能しました)
- B 社はオンライン画像認識サービスを提供し、SQS を利用してシステムコンポーネントをスケーラビリティに分離します。SQS コンシューマは、できるだけ頻繁にイメージングキューをポーリングして、エンドツーエンドのスループットを可能な限り高く保ちます。しかし、B 社は、タイトなループでのポーリングは、CPU サイクルを燃やし、空の応答でコストを増やすことを実現しています。どのように B 社は空の応答の数を減らすことができますか?
- イメージキューの可視性Timeout属性を20秒に設定します。
- イメージキューReceiveMessageWaitTimeSeconds属性を20秒に設定します。 (ロングポーリング、リンク参照)
- イメージキューMessageRetentionPeriod属性を20秒に設定します。
- メッセージのDelaySecondsパラメータを20秒に設定します。
コメントを残す