AWS SAA(Solutions Architect - Associate)対策
SNSとEventBridge
このレッスンを終えると、要件の文が「同じものを全員に配る」話なのか「中身を見て行き先を変える」話なのかを見分け、SNS と EventBridge を迷わず選べるようになります。
要件の文から入ります
ある動画配信サービスが、動画がアップロードされたときに3つの処理を走らせたいと考えています。サムネイル生成、字幕の文字起こし、検索インデックスの更新です。今はアップロード処理の中から3つを順に呼んでいて、1つが遅いと全体が遅くなり、処理を1つ足すたびにアップロード側のコードを直しています。
しばらくして、別の要望が来ました。動画の長さが2時間を超えるものだけ、追加の圧縮処理へ回したいというものです。さらに、毎晩0時に集計バッチを走らせたい、決済 SaaS で返金が起きたら通知したいという話も出てきました。
前半は SNS の問題で、後半は EventBridge の問題です。ここを分けて考えます。
SNS は同じものを多数へ配ります
SNS のトピックに1回発行すると、購読している複数の宛先へ同じメッセージが同時に届きます。これがファンアウトです。冒頭の3つの処理は、それぞれ SQS キューを購読させれば、アップロード側は「発行する」だけで済みます。処理を1つ足すときも、購読を増やすだけでアップロード側は触りません。
実務でよく使うのは SNS と SQS の組み合わせです。SNS だけで Lambda を直接呼ぶこともできますが、間に SQS を挟むと、受け側が落ちていてもメッセージがキューに残り、再試行やデッドレターキューも効きます。「一斉に配りたい」に加えて「取りこぼしたくない」があれば、SNS の下に SQS を置くのが定番の構成です。
SNS にもフィルターポリシーがあり、メッセージ属性による簡単な振り分けはできます。ただし判定できるのは属性であって、本体の中身を細かく条件にしたり、時刻で起動したり、外部サービスからのイベントを受けたりはできません。
EventBridge は中身で行き先を決めます
EventBridge はイベントバスにイベントが届くと、ルールに書いた条件にあてはまるものだけをターゲットへ送ります。条件は JSON の中身に対して書けるので、「動画の長さが2時間超のときだけ圧縮処理へ」という要求はルール1つで表せます。ターゲットは Lambda、Step Functions、SQS、SNS など多数を指定できます。
さらに EventBridge には2つの特徴があります。1つは、cron のような式でスケジュール実行ができることです。毎晩0時の集計はここで組みます。もう1つは、AWS の各サービスが出すイベントや、対応している SaaS のイベントを受け取れることです。決済 SaaS の返金イベントを受けて処理を起動する、という要求はこちらで解けます。
線引きの表
| 見る観点 | SNS | EventBridge |
|---|---|---|
| 基本の役割 | 同じメッセージを多数の購読者へ同報する | イベントの内容を見てルールで振り分ける |
| 振り分け | メッセージ属性によるフィルターポリシー | イベント本文の中身に対する詳細なパターン |
| スケジュール実行 | できない | できる |
| AWS サービスや SaaS のイベント受信 | 受けられない | 受けられる |
| 宛先の例 | SQS、Lambda、HTTPS、メール、SMS | Lambda、Step Functions、SQS、SNS ほか多数 |
| 遅延と規模 | 非常に低遅延で高スループット | ルーティングを挟むぶん SNS より遅延がある |
| 向く要件 | 大量のファンアウト、人へのメールや SMS 通知 | 疎結合なイベント駆動、条件分岐、定期実行、SaaS 連携 |
要件語から構成への対応
| 要件の言い回し | 選ぶもの |
|---|---|
| 1つのイベントで複数の処理を同時に走らせたい | SNS のファンアウト |
| 同報したうえで、受け側が落ちても失わないようにしたい | SNS の下に SQS を置く |
| 携帯電話やメールで人に知らせたい | SNS |
| イベントの中身の条件で処理先を変えたい | EventBridge のルール |
| 毎日決まった時刻に処理を起動したい | EventBridge のスケジュール |
| 外部 SaaS や AWS サービスの状態変化を起点にしたい | EventBridge |
| 送った順序と重複排除まで必要 | SNS FIFO と SQS FIFO の組み合わせ |
よくある引っ掛け
1つ目は、「イベントの内容に応じて処理を振り分けたい」に対して SNS のフィルターポリシーを選ぶことです。属性での振り分けなら成立しますが、設問がイベント本文の複雑な条件を求めていたら EventBridge が正解になります。設問の文が属性の話をしているのか本文の話をしているのかを読み分けます。
2つ目は、定期実行に対して「Lambda を常駐させて時刻を見張る」や「EC2 の cron で起動する」という選択肢です。動きはしますが、サーバーの運用が残ります。「運用の手間を最小に」という制約が付いていたら EventBridge のスケジュールが答えです。
まとめ
- 同じものを多数へ配るのが SNS、中身を見て行き先を決めるのが EventBridge です
- SNS と SQS を組み合わせると、同報しつつ取りこぼしと再試行に強くなります
- スケジュール実行と SaaS や AWS サービスのイベント受信は EventBridge だけができます
- SNS のフィルターは属性まで、本文の細かい条件は EventBridge です
- 人へのメールや SMS という文が出たら SNS を疑います
復習ミニクイズ
ある物流企業が、配送状況の更新イベントを処理しています。イベントの JSON には配送区分と重量が含まれ、重量が50キロを超える配送だけを専用のワークフローへ送りたいという要件があります。加えて、毎朝6時に前日分の集計処理を起動する必要もあります。サーバーを運用せずにこの2つを満たす構成はどれですか。