最初にトピックのサブスクライバーである SQS キューにメッセージを配信し、同じトピックのサブスクライバーでもある AWS Lambda 関数を実行する Amazon SNS トピックを実装したいと考えています。その後、Lambda 関数は SQS キューからメッセージを読み取り、それらのいくつか (数百) を並行して処理できます。
私の質問は、SNS トピックに送信されたメッセージが最初に SQS キューに配信され、その後 Lambda 関数に配信されることを保証する方法があるかどうかです?
これの目的は、メッセージごとに個別に Lambda 関数を実行する必要なく、多数のメッセージにスケーリングすることです。
この目的のために、ラムダのトリガーは、クラウド ウォッチ アラートから使用すると、より効果的かつ効率的になる可能性があります。クラウド ウォッチ アラートが SQS のバッファ制限に設定されていると、ラムダを起動して完全なキューを開始および処理できます。
あなたが探しているものは、現在 1 つでは不可能SNS Topicです。にサブスクライブするLambdaと、SNS Topicその特定の がメッセージLambdaを受信するたびSNS Topicに並行して実行されます。
解決策は、2 つSNS Topics用意して、最初のメッセージにメッセージを発行し、SQSサブスクライブすることです。この最初のトピックへのメッセージの送信が成功したら、2 番目のトピックにメッセージを送信して、最初に保存されたメッセージを処理するSNS Topicために を実行できます。LambdaSNS TopicSQS
別の考えられる解決策は上記の方法かもしれません。定期的なメッセージを 2 番目のトピックに送信して、subscribed を実行することができますLambda。これにより、Lambda SQS Workers.
SQS キューと Lambda 関数の両方を SNS トピックにサブスクライブすることは、Lambda 関数に低レイテンシーで SNS メッセージを処理させる良い方法です。私は今このプロセスをテストしました。試行するたびに、SQS メッセージが挿入された後にラムダ関数が呼び出されます。これが常に当てはまるとは思いませんが、私が測定したい限り、遅延の問題を修正します. これは保証されていません。見逃したメッセージを取得するには、CloudWatch のスケジュールされたイベントが必要になります。