それぞれ別個の機能を実行する個々のコンポーネントからアプリケーションを構築することは、スケーラビリティと信頼性が向上するベストプラクティスです。メッセージキューを使用すると、アプリケーションコンポーネント間で任意のボリュームでメッセージを送信、保存、受信できます。メッセージが失われることも、他のサービスが常に利用可能である必要もありません。
メッセージキューは、こちらで説明したように、メッセージがどのように配信され保護されるかを指定できるようにするいくつかのオプションを提供します。キューは、ファンアウト設計パターンで Pub/Sub メッセージングと組み合わせることもできます。
Amazon Simple Queue Service (SQS) は、わずか 3 つのシンプルなコマンドで開始できます。
Amazon SQS を無料で試すAWS 無料利用枠には、Amazon Simple Queue Service (SQS) でのリクエスト 100 万件が含まれます。
ほとんどのメッセージキューでは、メッセージの取得に、プッシュオプションおよびプルオプションの両方を利用できます。プルでは、キューに新規メッセージのクエリを実行し続けます。プッシュでは、メッセージが利用可能な場合に、コンシューマーが通知を受け取ります (これは Pub/Sub メッセージングとも呼ばれます)。ロングポーリングを使用して、プルが完了する前に、新しいメッセージが到着するまで指定した時間待機できるようにすることもできます。
メッセージキューの多くは、メッセージの特定の配信時間の設定をサポートしています。すべてのメッセージに共通の遅延が必要な場合は、遅延キューを設定できます。
メッセージキューは、冗長性と高可用性を確保するためにメッセージの複数のコピーを保存し、通信障害またはエラーが発生した場合にメッセージを再送信して、メッセージを少なくとも 1 回は配信するようにします。
重複を許容できない場合は、FIFO (先入れ先だし) メッセージキューにより重複を自動的にフィルタリングして、各メッセージが 1 回限り (1 回のみ) 配信されるようにします。
これらのキューの中でも、キューの「先頭」と呼ばれることもある、最も古いエントリ (つまり最初のエントリ) が、最初に処理されます。Amazon SQS FIFO キューの詳細については、デベロッパーガイドをご覧ください。
以下のブログ、「Python と Amazon SQS FIFO キューを使ったメッセージシーケンシングの保持」、「Amazon SQS FIFO API の仕組み」、および「1 回限りの処理および重複排除を行う FIFO キュー」も参照してください。
デッドレターキューは、他のキューが、正常に処理できないメッセージの送信先とすることができるキューです。これにより、キューの処理をブロックしたり、正常に消費されない可能性のあるメッセージに CPU サイクル を無駄に費やしたりすることなく、詳細な検査のためにそれらのメッセージを取って置くことが容易になります。
デッドレターキューの詳細については、ブログ「Amazon SQS デッドレターキューを使ったメッセージ障害の制御」を参照してください。Amazon SQS のデッドレターキューの使用方法については、デベロッパーガイドをご覧ください。
ポイズンピルは、受信はされても処理されない特別なメッセージです。これらは、コンシューマーに作業を終了するよう通知するために使用されるメカニズムです。新しい入力を待つこともなくなるため、クライアント/サーバーモデルでソケットをクローズすることに似ています。
メッセージキューは、キューにアクセスしようとするアプリケーションを認証し、キュー自体だけでなくネットワーク上でメッセージを暗号化するための暗号化を使用できるようにします。AWS のキューのセキュリティの詳細については、ブログ、「Amazon Simple Queue Service (SQS) のサーバー側の暗号化 (SSE)」を参照してください。また、Amazon SQS のセキュリティ機能の詳細については、デベロッパーガイドをご覧ください。
わずか 3 つのシンプルなコマンドで、無料でお試しいただけます。
