アプリケーション全体でリアルタイム通知を管理することは、適切なメッセージングサービスなしには非常に困難です。
Amazon Simple Notification Service (SNS) は、マイクロサービス、分散システム、サーバーレスアプリケーションの切り離しとスケーリングのための完全管理型メッセージングソリューションを提供するためにここにあります。SNSを使用すると、HTTP/S、電子メール、SMS、モバイルプッシュ通知など、複数の輸送プロトコルを介して多数のサブスクライバーにメッセージを送信できます。AWS SNSは、信頼性のある配信、リトライ、バックオフ機能を含むメッセージ配信のすべての重要な作業を処理し、コアアプリケーション機能の構築に集中できる自由を提供します。
AWS SNSは、スケーラブルで理解しやすいパブリッシュ-サブスクライブモデルに従っています。単一の公開メッセージは複数のエンドポイントに同時に配信されるため、SNSはイベント駆動型アーキテクチャに最適です。
このチュートリアルでは、AWS SNSの設定と使用方法を紹介します。さまざまなチャンネルに通知を送信します。
AWS SNSとは何ですか?
Amazon Simple Notification Service(SNS)は、マイクロサービス、分散システム、およびサーバーレスアプリケーションを分離できるAWSの管理型パブサブメッセージングサービスです。
SNSは、出版者がメッセージをトピックに送信し、購読者がそれらのメッセージを受信するシンプルなパブリッシュ-サブスクライブモデルで動作します。 SNSトピックをコミュニケーションチャンネルと考えてください – このチャンネルにメッセージを公開し、購読者はすぐに通知を受け取ります。 このシステムの美しいところは、出版者が自分のメッセージを受け取っている人が誰かを知る必要がないこと、そして購読者がメッセージを送っている人が誰かを知る必要がないことです。
これが、他のAWSメッセージングサービスとはどう違うのか疑問に思うかもしれませんが、Simple Queue Service (SQS)は、主に非同期タスクの処理に設計されたキューベースのモデルを使用しているのに対し、SNSは複数の受信者にメッセージを一斉に配信することに焦点を当てています。 これにより、SNSはちょうど発生したイベントについて多くのシステムに通知する必要があるシナリオに最適です。 この違いについては、SQS vs SNSブログ記事で詳しく説明されています。
SNSは複数の配信プロトコルをサポートしており、これにより購読者が通知を受け取る方法に柔軟性をもたらしています。
AWS SNSの主な機能
SNSには、必要な通知サービスを提供するための機能が満載されています。以下にいくつかリストアップします:
- ファンアウトアーキテクチャ:SNSは数千のエンドポイントに同時にメッセージを配信できるため、単一のAPI呼び出しでアプリケーションエコシステム全体にアップデートを配信することができます。
- 複数の輸送プロトコル:メッセージを送信するための方法は1つだけに限定されません。SNSはHTTP/HTTPSエンドポイント、電子メール、SMS、モバイルプッシュ通知、SQSキューなど、さまざまな輸送プロトコルをサポートしています。
- メッセージフィルタリング:すべての購読者がすべてのメッセージを必要とするわけではありません。メッセージフィルタリングを使用すると、購読者は興味のあるメッセージのみを受信するためのフィルタポリシーを作成でき、ノイズや処理オーバーヘッドを削減できます。
- メッセージアーカイブ:送信されたすべての通知の記録を保持する必要がある場合、SNSはメッセージアーカイブのためにAmazon S3とアナリティクスのためにAmazon Redshiftと統合されていることを知って喜ぶでしょう。
- 配信状況の追跡: 通知の配信状況を監視して、目的地に確実に到達することを確認できます。これは、SMSやモバイルプッシュ通知の場合に特に役立ちます。配信が保証されていない状況でも、安心です。
- 暗号化: サーバーサイドの暗号化をサポートするSNSにより、機密データが保護され、メッセージが送信中も機密性が確保されます。
SNSの最高の部分は拡張性です。SNSは自動的にアプリケーションのニーズに合わせてスケーリングします。1日に10回でも1000万回でも通知を送信しても、サービスは手動での介入を必要とせずに適応します。
次に、SNSの設定方法を紹介します。
AWS SNSの設定
SNSで最初の通知を送信する前に、すべての準備を整えるためにいくつかの設定手順に従う必要があります。
ステップ1: AWSアカウントの作成
まだAWSアカウントをお持ちでない場合は、SNSを使用する前にアカウントを作成する必要があります。
ヘッドオーバーしてくださいAWSホームページそして右上隅にある「AWSアカウントを作成」ボタンをクリックしてください。メールアドレスを提供し、パスワードを作成し、基本的なアカウント情報を入力する必要があります。 AWSはクレジットカードの詳細も求めます-心配しないでください、SNSにはかなり寛大な無料層があり、それらの制限を超過しない限り請求はされません。
アカウントが設定されたら、さらに進む準備が整います。ただし、ルートアカウントを使用する代わりに、専用のIAMユーザーを作成することを強くお勧めします。これは今日の記事の範囲外ですが、詳細なガイドラインについては、公式の手順を参照してください。
ステップ2:AWS管理コンソールでSNSを設定する
AWSアカウントがあるので、SNSサービスにアクセスする時が来ました。
資格情報でAWS Management Consoleにログインし、SNSを見つけます。これは3つの方法で行えます:
- コンソールの上部の検索バーに”SNS”と入力
- トップナビゲーションバーの”サービス”をクリックし、”Application Integration”カテゴリーの下にSNSを見つける
- 直接SNSコンソールに移動するSNS console
どの方法であれ、以下の画面が表示されます:
画像1 – AWS SNSサービスページ
SNS ダッシュボードに入ると、左側に「トピック」、「サブスクリプション」、「モバイル」などのオプションが表示されます。ダッシュボードでは、SNS リソースと最近のアクティビティの概要が表示されます。
新しいアカウントではかなり空になっているかもしれませんが、これは予想されることです。では、最初の SNS トピックを作成しましょう。
ステップ 3: SNS トピックの作成
SNS トピックは、出版者がメッセージを送信し、購読者がリッスンするためのコミュニケーションチャネルです。
これはラジオ局のようなものです – 局は特定の周波数(トピック)で放送し、その周波数にチューニングされたすべての人が放送を受信します。SNS の場合、アプリケーションはトピックにメッセージを公開し、そのトピックに購読しているすべてのエンドポイントがそのメッセージを受信します。
最初のSNSトピックを作成する方法は次のとおりです:
- 画面に表示されているイメージ1で、トピック名を入力します。
- “次のステップ”ボタンをクリックします。
- タイプには「標準」を選択します(FIFOトピックは後で説明します)。
- (任意) 表示名を入力します。これはSMSや電子メールの購読者に送信されるメッセージに含まれます。
- その他の設定はデフォルトのままにしてください。
- “トピックを作成” をクリックします。
テキストよりも画像が好みの場合、画面は以下のようになります:
画像2 – SNSトピック作成
値に満足したら、下にスクロールして”トピックを作成” ボタンが表示されるまで進んでください:
画像3 – SNSトピック作成(2)
以上です!あなたのSNSトピックは今すぐ使用できる状態になりました。トピックARN(Amazonリソースネーム)など、トピックを一意に識別する詳細が表示されます:
画像4 – 作成されたトピックの詳細
新しいトピックは購読の準備ができていますが、まだ購読者がいないため、公開したメッセージはどこにも届きません。心配しないでください、次のセクションで購読者を追加するときにそれを修正します。
SNS購読者と購読
前述のように、あなたのSNSトピックはラジオ局のようなものです。現在、リスナーはいませんが、メッセージを受け取る購読者を追加すればそれは変わります。
SNS購読者とは何ですか?
購読者とは、メッセージが公開されたときにあなたのSNSトピックから通知を受け取るエンドポイントのことです。
ニュースレターのアナロジーを考えてみてください。新しい版(メッセージ)を発行するたびに、それはあなたのメーリングリストに登録されている全員に届けられます。SNSはこのプロセスを自動化し、スケーラブルにし、すべての配信ロジスティクスを処理します。
AWSはさまざまな種類の購読者をサポートしており、メッセージの処理方法に柔軟性を提供します。以下に主な種類をリストします:
- メールアドレス: プレーンテキスト通知を直接メールボックスに送信します。
- SMS番号: テキストメッセージ通知を携帯電話に届けます。
- SQS キュー:他の AWS サービスにメッセージをルーティングしてさらなる処理を行います。
- Lambda 関数: 通知に応答してサーバーレスのコード実行をトリガーします。
- HTTP/HTTPS エンドポイント:Web アプリケーションや API にメッセージを送信します。
- モバイルプッシュ:モバイルアプリに直接通知を配信します。
各登録タイプにはそれぞれの利点と使用事例があります。たとえば、メールやSMSは人間の受信者にとって優れていますが、SQSキューやLambda関数はシステム間通信に適しています。
ステップ1:登録者の追加
登録者の概念が理解できたので、トピックに1つ追加しましょう。このチュートリアルでは、最も簡単な設定であるメールを使用します。
SNSトピックにメール登録者を追加する方法は次のとおりです:
- トピックの詳細ページ( 画像4に表示されるもの)で、「サブスクリプションの作成」ボタンをクリックします。
- 「プロトコル」ドロップダウンから「メール」を選択します。
- 「エンドポイント」フィールドに、通知を受け取るべきメールアドレスを入力します。
- 他の設定はデフォルト値のままにしておきます。
- 「サブスクリプションを作成」をクリックします。
あなたの画面は次のようになるはずです:
画像5 – メール購読の作成
「購読を作成」をクリックすると、AWSはトピックに購読を追加しますが、それは「確認待ち」状態になります:
画像6 – 確認待ち状態
これは重要なセキュリティ機能です。AWSは、メールアドレスの所有者が実際にこれらの通知を受け取りたいかどうかを確認したいと考えています。
ステップ2:購読の確認
購読者を追加した後、彼らはあなたのSNSトピックから通知を受け取りたいことを確認する必要があります。
メール購読の場合、AWSは指定されたアドレスに確認メールを自動的に送信します。メールには、受信者が購読を有効にするためにクリックしなければならないリンクが含まれています。これが行われるまで、そのトピックに公開されたメッセージはこのエンドポイントに配信されません。
以下は、典型的な確認メールの例です:
画像 7 – SNS 確認メール
受信者は、メール内の「購読を確認」リンクをクリックするだけです。これにより、購読が現在アクティブであることを確認するページに移動します:
画像 8 – 購読確認メッセージ
プロセスはSMS購読者に対しても似ています – AWSは受取人が従う必要がある確認リンクが含まれたテキストメッセージを送信します。HTTP/HTTPSエンドポイントはAWSからの確認リクエストに応答する必要がありますが、Lambda関数やSQSキューなどのAWSリソースは自動確認のために設定できます。
SNSコンソールの左サイドバーにある「サブスクリプション」セクションをクリックすることで、サブスクリプションのステータスを確認できます。確認済みのサブスクリプションは「確認済み」のステータスが表示され、確認待ちのものは「確認待ち」と表示されます。
画像9 – サブスクリプションのステータス
サブスクリプションが確認されると、メッセージの送信を開始する準備が整います!トピックに公開されたメッセージは、指定されたプロトコルを使用してすべての確認済み購読者に配信されます。
SNSサブスクリプションの設定はこれで終わりです。次のセクションでは、トピックにメッセージを公開し、購読者が正しく受信しているかをテストする方法を学びます。
SNSトピックへのメッセージの公開
SNSトピックを設定し、購読者を追加したら、最初の通知を送信する準備が整いました。
ステップ1:メッセージの公開
AWSコンソールを介してメッセージを公開するのは良いスタート方法です。
最初のメッセージを送信するには、トピックの詳細ページに移動し、右上にある「メッセージを公開」ボタンをクリックします(画像4)。これにより、メッセージ公開フォームが開き、通知を作成できます。メッセージの件名と本文のフィールドが表示されます。件名はオプションですが、電子メール通知に役立ちます。なぜなら、それが電子メールの件名になるからです。
シンプルなテストメッセージの場合、次のように入力することができます:
画像10 – 最初のメッセージ内容
メッセージに満足したら、スクロールしてフォームの下にある「メッセージを公開」ボタンをクリックしてください:
画像11 – コンソールを介してメッセージを公開
クリックした後、SNSはすぐに確認済みのすべての購読者にメッセージを配信します。メール購読を設定している場合、数秒以内に受信トレイにテストメッセージが届きます:
画像12 – メールで受信したメッセージ
簡単でしたね?さらにカスタマイズする方法を見てみましょう。
ステップ2:SMSとメールの通知を送信
SNSを使用すると、異なる種類の購読者にメッセージがどのように表示されるかをカスタマイズできます。
メッセージを公開する際、”メッセージ構造”オプションに気づくでしょう。デフォルトでは、”すべての配信プロトコルに同一のペイロード”に設定されています。これは、すべての購読者がまったく同じメッセージを受信することを意味します。ただし、”各配信プロトコルにカスタムペイロード”を選択することもできます。これにより、各購読者タイプのメッセージ形式を調整できます。
電子メール通知には、2つの形式オプションがあります:
- 電子メール-JSON: メールエンドポイントに生のJSONペイロードを送信します。
- 電子メール: 件名とメッセージ本文を含むフォーマットされた電子メールを送信します。
イメージ13 – ペイロードのカスタマイズ
SMS通知では、160文字の制限があることを考慮してください。SNSは長いメッセージを配信しますが、複数のメッセージとして扱われます。また、SMSメッセージタイプを「プロモーション」または「取引」のいずれかに設定することもでき、配信の最適化に影響します:
イメージ14 – SMSオプション
AWSコンソールを使用して電子メール通知を送信およびカスタマイズする方法をご存知です。次に、同じことをCLIとPythonを使用して行う方法を学びます。
ステップ3: AWS CLIまたはSDKを使用してメッセージを公開
コンソールは手動テストには最適ですが、実際の世界ではメッセージをプログラムで公開したいと思うでしょう。
AWSコマンドラインインターフェース(CLI)を使用すると、ターミナルや自動化スクリプトからSNSメッセージを簡単に送信できます。
前提条件として、AWS CLIがインストールおよび設定されていると仮定して、次のコマンドを実行してCLIを介してメッセージを公開します:
aws sns publish --topic-arn "sns-arn" --subject "CLI Notification" --message "Hello from the AWS CLI!"
画像15 – AWS CLIを介したメッセージの公開
数秒で、受信トレイに類似したメッセージが表示されます:
イメージ16 – AWS CLI経由でメッセージを公開する(2)
より高度なアプリケーションでは、AWS SDKは多くのプログラミング言語でSNSへのプログラムアクセスを提供します。
以下は、boto3
ライブラリを使用してPythonでメッセージを公開する簡単な例です:
import boto3 # SNSクライアントの初期化 sns_client = boto3.client("sns", region_name="eu-central-1") # トピックARN(Amazon Resource Name) topic_arn = "sns-arn" # 簡単なメッセージを公開 response = sns_client.publish( TopicArn=topic_arn, Message="Hello from Python!", Subject="Python Notification" ) # メッセージが正常に送信されたかどうかを確認 if "MessageId" in response: print(f"Message published successfully! Message ID: {response['MessageId']}")
イメージ17 – Python SDKを介したメッセージの公開
再び、メッセージは私の受信トレイに即座に配信されます:
画像18 – Python SDKを通じたメッセージの公開(2)
SNSを使用してメッセージを公開する方法は以上です!簡単なコンソールインターフェースからAWS CLIやSDKを使用したプログラム的な公開まで、複数の方法で通知を送信できるようになりました。
> AWS Boto in Pyに初めて触れる?時間をかけずに習熟するために当社のコースに登録してください。
次のセクションでは、通知をさらに高度なレベルに引き上げるSNSのいくつかの高度な機能を探っていきます。
高度なSNS機能
これまでにSNSの基本を学びました。このセクションでは、SNSを本当に強力にするいくつかの高度な機能を見ていきます。
SNSメッセージフィルタリング
すべての購読者に同じ通知を送信すると、エンドポイントが関心のないメッセージを受信することがよくあります。
メッセージフィルタリングは、購読者がメッセージ属性に基づいて受信するメッセージをフィルタリングできるようにすることで、この問題を解決します。メールフィルターを設定するのと同じように考えてください – 通過するメッセージを決定するルールを作成します。SNSでは、これらのルールを フィルターポリシー と呼びます。
まず、サブスクリプションにフィルターポリシーを設定して、関連するメッセージのみを受信できるようにします。
画像19 – 通知フィルターポリシー
この例では、購読者は属性order_value
が1500以上の数値であるメッセージのみ通知を受け取ります。
このような通知を送信するには、次のPythonコードを使用できます:
import boto3 # SNSクライアントを初期化 sns_client = boto3.client("sns", region_name="eu-central-1") # トピックのARN(Amazonリソース名) topic_arn = "arn:aws:sns:eu-central-1:105036517833:TestTopic" response = sns_client.publish( TopicArn=topic_arn, Message="A new high-value order has been placed", Subject="New Order Notification", MessageAttributes={ "order_value": {"DataType": "Number", "StringValue": "2000"}, "region": {"DataType": "String", "StringValue": "EU"}, "category": {"DataType": "String", "StringValue": "Electronics"}, }, ) print(response)
Pythonスクリプトを実行した後に表示される内容は次のとおりです:
画像20 – Pythonを介した通知の送信
のみ order_value
の値が1500以上の場合に限り、通知を受け取ります:
画像21 – 通知内容
要するに、フィルターポリシーを使うことで、公開コードを変更することなくターゲット通知を送信することができます。最も良いのは、フィルタリングがAWS側で行われ、あなたのアプリケーションでは行われないため、効率が向上し、不必要なトラフィックが削減されることです。
SNSデッドレターキュー(DLQ)
メッセージの配信は、最も信頼性の高いシステムでも失敗することがあります。
デッドレターキュー(DLQ)は、Amazon SQSキューの特別なキューで、SNSがサブスクライバーに配信できなかったメッセージを送信できる場所です。これは、サブスクライバーが利用できないかエラーが発生した場合に通常発生します。失敗したメッセージを永久に失わずに済むように、SNSはこれらのメッセージをDLQにリダイレクトし、後で分析したり再配信を試みたりできます。
DLQの設定には2つのステップが必要です。まず、DLQとして機能するSQSキューを作成します:
イメージ22 – SQSキューの作成
次に、SNSサブスクリプションを構成して、このキューを配信できないメッセージに使用します:
イメージ23 – SQSキューにリドライブポリシーを追加
この構成には適切な権限が必要です。SNSはSQSキューにメッセージを送信できる必要があります。AWSコンソールでは、単純なチェックボックスを介して設定できますが、CloudFormationや他のインフラストラクチャコードツールを使用している場合は、適切なIAM権限を追加する必要があります。
DLQが設定されていると、配信の失敗を監視し、必要に応じて対処できます。たとえば、DLQにメッセージが表示されるとアラームがトリガーされ、購読者に問題がある可能性があることを通知しますが、このセクションの範囲外です。
AWS Lambdaを使用したSNS
Lambda関数は、SNSメッセージを処理するためのさまざまな可能性を提供します。
SNSトピックにLambda関数をサブスクライブすると、メッセージが公開されるたびに関数が自動的にトリガーされます。Lambdaのサーバーレスアプローチは、メッセージ処理のためのインフラを管理する必要がなく、メッセージのボリュームに応じて自動的にスケールします。
まず、Lambda関数を作成します:
画像24 – Lambda関数の作成
次に、以下のようなコードを記入します:
def lambda_handler(event, context): # SNSメッセージは「Records」配列に入ります for record in event["Records"]: # メッセージを抽出します message = record["Sns"]["Message"] subject = record["Sns"]["Subject"] timestamp = record["Sns"]["Timestamp"] # メッセージを処理します print(f"Received message: {message}") print(f"Subject: {subject}") print(f"Timestamp: {timestamp}") # ここにビジネスロジックを記述します # 例えば、メッセージをデータベースに保存する # または別のAWSサービスをトリガーする print("ALL DONE!") # 成功を返します return {"statusCode": 200, "body": "Message processed successfully"}
画像25 – ラムダ関数のコード
コードが準備できたら、「トリガーを追加」ボタンをクリックしてLambda関数をSNSに接続します:
画像26 – SNSをLambdaに接続する
関数は今やキューに接続されており、テスト通知を送信できるようになりました:
画像27 – テスト通知
Lambda関数を使用すると、ログを監視できるため、最近の関数の呼び出しを確認できます – 通知を送信した結果:
画像28 – Lambda関数のログ
Lambda関数は、これらのメッセージに対してほぼすべての操作を行うことができます – データベースに保存したり、他のAWSサービスをトリガーしたり、メールを送信したり、外部APIを呼び出したりすることができます。これにより、SNSとLambdaはイベント駆動型アーキテクチャを構築するための強力な組み合わせとなります。Lambda関数について詳しくは、AWS Lambdaの始め方チュートリアルで学ぶことができます。
次に、SNSの監視とログ記録の基本を学びます。
SNSアクティビティの監視とログ記録
SNSの活動を追跡することは、信頼性のある通知システムを維持するために不可欠です。
Amazon CloudWatchをSNSとともに使用する
Amazon CloudWatchは、SNSを含むすべてのAWSサービスの包括的な監視を提供します。CloudWatchをSNSと設定すると、メッセージ配信率、失敗、API使用パターンなどの重要な運用指標を可視化できます。
SNSのCloudWatch監視を始めるには、AWSアカウントのCloudWatchコンソールに移動します。そこから、AWSが自動的に収集する事前設定されたSNSメトリクスにアクセスできます。
監視する価値のあるSNSメトリクスには以下が含まれます:
- メッセージの発行数: トピックに発行されたメッセージの数を追跡します。
- 通知の配信数: 購読者へのメッセージ配信が成功した回数を示します。
- 通知の配信失敗数: 設定の問題を示すかもしれない配信失敗の試行を強調します。
- PublishSize: 公開されたメッセージのサイズを測定し、サービス制限内に収めるのに役立ちます。
画像 29 – SNS のデフォルト CloudWatch ダッシュボード
CloudWatch アラームの設定により、ユーザーに影響を与える前に潜在的な問題に迅速に対応できます。たとえば、メッセージ配信の失敗が特定の閾値を超えたときにトリガーされるアラームを作成することができます:
- CloudWatch コンソールで、「アラーム」セクションに移動します。
- 「アラームの作成」をクリックし、監視したいSNSメトリクスを選択します。
- 閾値を定義します(例:5分間に5回以上の配信失敗)。
- 通知アクションを構成します。たとえば、運用チームにアラートを送信するなどです。
手順よりも画像を好む場合は、興味のあるメトリクス(例:NumberOfNotificationsFailed
)のアラームを作成して、アラームを起動する閾値を設定します:
画像30 – アラームの作成
以上で、アラームが作成され、アクティブ化されます。
画像31 – アラームの作成(2)
これらのアラームは、問題に積極的に対処するか、不満なユーザーからそれを知るかの違いとなり得ます。
SNSログの確認
AWS CloudTrailは、AWSアカウント内のすべてのAPIアクティビティをキャプチャし、SNSサービス内で実行されたアクションを含みます。
コンソール、CLI、またはSDKを介して実行されるSNSトピック上のすべての操作は、CloudTrailログにエントリを生成します。これらのログは、セキュリティ分析、リソース変更の追跡、コンプライアンス監査に貴重な情報を提供します。
CloudTrailでSNSログにアクセスするには:
- AWSアカウントでCloudTrailコンソールを開きます(おそらく新しいトレイルを作成する必要があります)。
- 最近のSNSアクティビティを確認するには、「イベント履歴」に移動します。
- 「イベントソース」を選択し、「sns.amazonaws.com」と入力してイベントをフィルタリングします。
再度、テキスト指示だけでは不十分な場合は、以下の画像を参照してください。まずは新しいトレイルを作成してください:
画像32 – 新しいトレイルを作成
次に、「イベント履歴」の下で、SNSのイベントのみをフィルタリングします。
画像33 – ログのフィルタリング
ログは自動的にS3バケットに保存されます。これは、このアプローチがログの恒久的な保存を提供し、より高度なクエリ機能を可能にすることを意味します。
> AWSのストレージはどのように機能しますか? S3とEFSに関するガイドをお読みください。
結論として、CloudWatchメトリクスとCloudTrailログを組み合わせることで、SNSインフラストラクチャが信頼性を持って運営されることを保証する包括的な監視システムが作成されます。
AWS SNSのベストプラクティス
AWS SNSの基本機能と高度な機能を理解しました。残るは、トピックの作成とメッセージの送信に関するベストプラクティスについて話し合うことです。
SNSトピックのセキュリティ
SNSインフラを設定する際にはセキュリティを最優先事項とすべきです。適切なコントロールがないと、トピックは不正アクセスの脆弱性にさらされ、それは大きなセキュリティリスクとなります。
AWS Identity and Access Management(IAM)は、SNSトピックを保護するために必要なツールを提供しています。最小特権の原則に従うポリシーを作成して始めましょう。つまり、各ユーザーやサービスに必要な特定の権限のみを付与します。たとえば、一部のアプリケーションにはメッセージの発行のみを許可し、他のアプリケーションにはトピックの登録のみを許可するなどです。
以下は特定のトピックへの発行を制限するサンプルIAMポリシーです。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sns:Publish", "Resource": "sns-arn" } ] }
また、トピックポリシーを使用して、どのAWSアカウントがトピックに登録できるかを制御することもできます。これは、組織間でデータを共有する場合に特に重要です。
AWS CloudTrailを使用して定期的にアクセス許可を監査し、不要なアクセスを削除することを忘れないでください。
メッセージボリュームの管理
高いメッセージボリュームは適切に処理されないと購読者を圧倒する可能性があります。これは、SNSを他のAWSサービスと組み合わせることが不可欠な場面です。
人気のあるパターンの1つは、「ファンアウト」アーキテクチャで、複数のSQSキューが購読しているSNSトピックにメッセージを公開することです。各キューはそれぞれ独自のペースで異なる処理システムにフィードできます。これにより、パブリッシャーとコンシューマーが分離され、トラフィックのスパイク時にバッファが提供されます。
リアルタイム処理が必要な場合は、Lambda関数をトピックにサブスクライブすることを検討してください。Lambdaはメッセージボリュームに応じて自動的にスケーリングされるため、サーバーのプロビジョニングと管理が不要になります。
コストの削減
SNSはコスト効率が高いですが、メッセージのボリュームが増えると費用がすぐに膨らむ可能性があります。戦略的な選択をいくつか行うことでコストを抑えることができます。
まず、サブスクリプションプロトコルを選択する際に慎重になることです。HTTP/HTTPSエンドポイントが一般的に最もコスト効率の良いオプションです。便利なメール通知は高コストがかかるため、適切に使用する必要があります。
メッセージのフィルタリングもコストを節約するための強力なツールです。サブスクリプションにフィルタポリシーを実装することで、メッセージが興味を持つ購読者にのみ配信されるようにします。例えば、すべてのシステムアラート用のトピックがある場合、オンコールエンジニアにはシフト中に重要なアラートのみ受け取ってほしいと考えるかもしれません。:
# フィルタポリシーを使用してサブスクライブ response = sns.subscribe( TopicArn="sns-arn", Protocol="email", Endpoint="[email protected]", Attributes={"FilterPolicy": '{"severity": ["critical"]}'}, )
最後に、AWS Cost ExplorerでSNSの使用状況を定期的に確認し、トピックの統合や未使用のサブスクリプションの削除の機会を探ってください。未使用または重複したリソースは、不必要なコストを追加するだけでなく、アーキテクチャを複雑にします。
これらのベストプラクティスに従うことで、安全でスケーラブル、かつコスト効果の高いSNSの実装を作成できます。予期しない費用やセキュリティの懸念なしに、信頼性の高い通知サービスを持つために必要なすべてが揃います。
まとめ AWS SNS
分散アプリケーション間でリアルタイム通知が必要な場合は、AWS SNS以上のものはありません。使いやすく、他のAWSサービスと良く統合され、ニーズに合わせて無限にスケールします。
SNSのパブリッシュ-サブスクライブモデルは、複数のチャネルに同時に通知を送信するシステムを簡単に実装できるようにします。トピックの作成やサブスクライバーの管理、メッセージフィルタリングやデッドレターキューなどの高度な機能の実装まで、堅牢な通知インフラストラクチャを構築するための知識を得ることができました。
また、プロダクション環境でのSNS実装が信頼性と効率を保つために重要な監視、セキュリティ、コスト管理の重要な側面についても学びました。
アプリケーションがイベント駆動型アーキテクチャを採用し続ける中で、SNSのようなサービスはますます価値が高まります。シンプルなアラートシステムを構築する場合でも、複雑なマイクロサービスを作成する場合でも、このチュートリアルのパターンはシステムコンポーネント間の効果的なコミュニケーションのための基盤を提供します。
AWSについてさらに学ぶには、DataCampのこれらのコースを受講してください:
DataCampを使用してAWS認定試験に備えることもできます – AWS Cloud Practitioner (CLF-C02)。