SNSを理解する

SNSは通知を発行する側と購読する側を分けるサービスです。トピック、購読、フィルター、SQSとの組合せを学び、通知を受け付けたことと利用者が処理したことを区別します。

この単元で学ぶこと

SNSのトピックと購読の役割を説明する
フィルターとファンアウトを使い分ける
配信・業務完了・アクセス許可を区別する

本文解説

1. トピックを仲介にする注文サービスが通知先を直接一つずつ呼び出す代わりに、SNSのトピックへ発行します。在庫、配送、分析の担当システムはそれぞれ購読先として登録します。発行者は通知を発行する役割を持ち、購読者は受け取った後の処理を担当します。新しい受取先を加えるときも、発行者と全受取先を強く結び付けない構成を作れます。

2. 通知先は同一とは限らない SNSはSQS、Lambda、HTTP/S等のアプリケーション向けの配信や、人へのメール等の通知に利用できます。トピックの種類やプロトコルによって利用できる組合せ・機能が異なるので、全種類で同じ宛先と保証を使えるとは考えません。本単元の基本例はStandardトピックから複数SQSキューへの通知です。

3. ファンアウトと仕事分担ファンアウトでは一つの通知を複数の購読先へ分配します。在庫用キューと配送用キューがそれぞれ通知を受け取り、後段は独立した速度で処理できます。一つのSQSキューを二つのワーカーが受信するだけなら仕事の分担であり、両業務が各注文を受け取るファンアウトとは違います。コピーの受取先と、その後の並列ワーカーを分けて描きます。

4. 購読フィルター受取先によって必要な通知が違う場合、購読にフィルターポリシーを指定します。例えばregionがJPの注文だけを国内配送用へ送ります。フィルターのスコープに応じてメッセージ属性またはJSON本文の内容を照合します。フィルターで除かれた通知と、権限等で配信に失敗した通知は別の原因なので、調査でも区別します。

5. 件数の計算全通知を受け取る独立した三つの購読用キューへ、100件の発行をそれぞれ一度ずつ配信したなら、キューへの配信総数は300件です。一つのキューにだけ100件を入れて三つのワーカーで分担する場合、三つの業務へ各100件を渡したことにはなりません。実際には再試行やフィルターを考え、理想化した計算と運用の観測値を分けます。

6. 配信成功の先 SNSが発行を受け付けた後、配信先で障害が起こる場合があります。再試行や失敗時の扱いはプロトコルに応じて確認します。SQSへ通知が届いても、消費者の業務処理が完了したとは限りません。注文ID等を使って重複に備え、各段階の失敗を監視し、必要なら配信失敗のDLQと業務ワーカー用DLQを役割別に設計します。

7. 購読と許可トピックを作っただけで、任意のキューへ送信できるわけではありません。購読設定に加えて、SQSキュー側で対象SNSトピック等からの送信を許可する設定を確認します。メール等では購読の確認が必要な方式もあります。フィルターは受け取る内容を選ぶ機能で、発行や受信のアクセス許可の代わりにはなりません。

8. SESやEventBridgeとの比較 SNSは通知の発行・購読を中心に選びます。自社ドメインで注文確認メール等の配信を作る場合はSES、AWSや外部システムのイベントを内容に応じて多様な対象へ振り分ける場合はEventBridgeを比較します。SNSにもフィルターがあるので「内容で絞るならSNSでは不可能」と断定しません。中心となる連携方式と必要な宛先・機能から選びます。

図解

二つの業務へ独立して通知する — 各キューの中でさらにワーカーを増やせます。SNSの配信成功と各業務の完了は別です。

重要ポイント

購読先へ配ることと、その先で仕事を分担することは別。
SNSにも属性・本文を使う購読フィルターがある。
発行受付・配信・業務処理完了を分けて観測する。

間違えやすい点

購読フィルターをアクセス権限として使う。
通知が届いたことを注文の発送完了と読み替える。

用語解説

トピック: 発行者からの通知を受け取り、購読先へ配信する単位。
購読: トピックから通知を受け取る宛先と関連設定。
ファンアウト: 一つの通知等を複数の独立した受取先へ分配する構成。
フィルターポリシー: 購読者が受け取るメッセージの条件を定める設定。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。