SQS メッセージフィルタリングと SNS + SQS 統合

フィルタリングを使用しないファンアウトアーキテクチャでは、すべてのSQSサブスクライバーがすべてのSNSメッセージを受信します。トピックが10種類の商品カテゴリの注文イベントを発行していても、あるサブスクライバーが電子機器の注文だけを処理する場合、そのサブスクライバーは食品や衣料品のメッセージも受信し、破棄しなければなりません。これはコンピューティングリソースを無駄にし、コストを増加させ、コンシューマーに不要な負荷をかけます。SNS subscription filter policies を使うと、SNS自体が適切なサブスクライバーにだけメッセージをルーティングするため、この問題を解決できます。

filter policy は、SQSまたはLambdaのサブスクリプションに適用するJSONオブジェクトです。SNSは配信前に、各メッセージのmessage attributesに対してポリシーを評価します。メッセージ属性がフィルターポリシーに一致すれば配信し、一致しなければそのサブスクライバーへの配信を通知なしにスキップします。フィルターポリシーでは、文字列一致、数値範囲、プレフィックス一致、および属性の有無を確認する exists 演算子をサポートしています。

デフォルトでは、フィルターポリシーはmessage attributes（メタデータ）に対して一致判定を行います。2023年以降、SNSではフィルターポリシーのスコープを MessageBody に設定することで、payload-based (body) filtering もサポートしています。これにより、パブリッシャーが属性を追加しなくても、メッセージ本文に対して直接JSONパスベースのフィルタリングを行えます。本文のフィルタリングはより柔軟ですが、メッセージ本文が有効なJSONである必要があります。パブリッシャーの出力形式に適したスコープであることを必ず確認してください。

フィルターポリシーでは、単純な文字列の等価比較以外にも、複数の一致演算子をサポートしています。

• Numeric: {"numeric": ["=", 100]}、{"numeric": [">", 50, "<=", 200]}
• Prefix: {"prefix": "order-"} は、そのプレフィックスで始まる任意の文字列に一致します
• Anything-but: {"anything-but": ["CANCELLED"]} は、指定された値以外のすべての値に一致します
• Exists: {"exists": true} は属性が存在する場合に一致し、false は存在しない場合に一致します

フィルタリングを機能させるには、SNSへの発行時にpublisher must include message attributesである必要があります。属性は、データ型（String、Number、Binary）を持つキーと値のペアです。パブリッシャーは、どのサブスクライバーがどのフィルターポリシーを持っているかを知る必要はありません。イベントを表す属性をメッセージに追加するだけで、SNSが自動的にルーティングします。これにより、パブリッシャーをサブスクライバー固有のロジックから完全に分離できます。

高度なファンアウトトポロジーでは、SNSが複数の詳細度レベルでSQSキューにルーティングできます。1つのキューは監査のためにすべての注文（フィルターなし）を受信し、別のキューは不正審査のためにHIGH_VALUEの注文（amount >= 1000）だけを受信し、3つ目のキューは電子機器倉庫向けにELECTRONICSの注文だけを受信します。各SQSキューには独自のLambdaコンシューマーがあります。このパターンでは、各処理ティアを個別にスケーリングでき、既存のコンシューマーやパブリッシャーに手を加えずに新しいコンシューマーを追加できます。

SNSは異なるAWSアカウントにあるSQSキューにも配信できます。SQSキューのresource-based policyで、発行元アカウントのSNSトピックARNからSNSサービスプリンシパルが sqs:SendMessage を呼び出すことを許可する必要があります。これにより、認証情報を共有せずに、イベント発行を一元化できます（1つのアカウントが発行し、複数のアカウントチームがサブスクライブします）。クロスアカウントのファンアウトは、マルチアカウントのAWS Organizations環境でよく使われるパターンです。

イベント量が急増した場合、SNSからLambdaを直接呼び出すとLambdaが即座にスケールし、下流のデータベースやAPIを過負荷にする可能性があります。SNSとLambdaの間にSQSを追加すると、buffer を作成できます。SNSがSQSに配信し、Lambdaは制御されたバッチサイズでSQSをポーリングします。これにより、Lambdaは持続可能な速度で処理し、SQSがトラフィックの急増を吸収できます。キューの深さはバックプレッシャーの仕組みとして機能します。深さを監視し、コンシューマーの遅延を示すしきい値を超えて増加した場合にアラートを発生させることができます。

SNS → Lambda (direct): レイテンシーが最も低く、バッファリングはなく、Lambdaが即座にスケールします。サブ秒のレイテンシーが重要なリアルタイムアラートや緊急通知に適しています。SNS → SQS → Lambda: DLQのサポート、スループットの制御、Visibility Timeoutによる再試行、キューの深さの監視が追加されます。トランザクション処理、在庫更新、下流システムの制限を遵守する必要があるあらゆるシナリオに適しています。試験問題では、耐久性とレート制御が言及されている場合は、SQSによるバッファリングを選択してください。

SNS コンソールのフィルターポリシーエディタを使用すると、デプロイ前にサンプルメッセージがフィルターポリシーに一致するかどうかをテストできます。また、SNS Sandboxを使用してメッセージ配信をシミュレートし、ルーティングを検証することもできます。コードでは、既知の属性を持つテストメッセージを発行し、各サブスクリプションの CloudWatch メトリクスを確認してフィルターポリシーを検証します。NumberOfMessagesFilteredメトリクスには、フィルターによってブロックされたメッセージ数が表示されるため、本番イベントを待たずにポリシーを調整できます。

SNS と SQS を完全に統合した構成は、次のようになります。(1) アプリケーションがメッセージ属性を付けてSNS Standard トピックにイベントを発行します。(2) SNS が各サブスクリプションのフィルターポリシーを評価し、一致するメッセージだけを各 SQS キューに配信します。(3) Lambda が設定されたバッチサイズで各 SQS キューをポーリングし、メッセージを処理します。(4) 処理に失敗したメッセージは、maxReceiveCount に達するとキューのDLQに送られます。(5) DLQ のメッセージ数に対するCloudWatch アラームがチームに通知します。この完全に疎結合で耐障害性に優れたパターンは、SAA-C03 の代表的なアーキテクチャです。

このレッスンで扱った AWS Solutions Architect (SAA-C03) の概念について、理解度を確認します。

このレッスンでは、次のことを学びました。SNS フィルターポリシーは、SNS レベルでメッセージ属性またはメッセージ本文の内容に基づいてメッセージをルーティングするため、下流のコンシューマーによる不要な処理を排除できます。SNS→SQS→Lambdaパターンは、ファンアウトによるブロードキャストと処理の間に永続的なバッファリングとレート制御を追加します。また、クロスアカウント SQS 配信では、キューのリソースポリシーを使用して、複数アカウント環境で集中型の pub/sub を実現できます。次は、Amazon API Gateway の REST、HTTP、WebSocket API について学びます。