概要

通知基盤の構築に関してざっくりと考えたことや調べたことなどをまとめておく。

通知基盤とは

ユーザーに通知（メール・プッシュ・SMS・音声など）を行うためのシステム基盤。

クライアント（通知を依頼するシステム）からリクエストを受けて、送信先・送信内容など通知に関する処理を担うシステム。

通知基盤の設計・実装における観点

考えることが一杯ありそうだと思ったので、思いついた順で雑に書いた。整理できていない。

通知メッセージの性質
- 性質
  - 重要なお知らせ
    - ex. 規約変更、決済関連など
  - マーケティング
    - ex. セール情報
- 性質によって、アーキテクチャが重視する特性が変わるかもしれない
  - 例えばメールならお知らせ系はSES、マーケティング関連はAmazon Pinpointにとか、特性に応じて性能やコスト等で最適な形が変わりそう
通知のチャンネル
- メール、プッシュ、SMS、音声など
送信パターン
- 個別送信
- グループ送信
- キャンセル
  - 送信したものを取り消す仕組み
  - フェイルセーフも兼ねる
    - 1件送るはずが1000件に設定してしまった・・！みたいなヒューマンエラーとかを防ぐ仕組み、工夫があると良さそう。こういったミスはコストにダイレクトに響くと思われるため
- 通知優先度
- 条件指定
  - メールで通知できるならSMSは通知しない、など通知を条件分岐できる仕組み
  - この時間帯は送信しない時間指定なども
コスト
- コストを抑える仕組み、工夫
スケーラビリティ
- 通知基盤そのものはともかく、連携する内部システムにも気をつけるところがありそう
  - 例えば、ユーザーに関連する情報をリクエストする必要があるとそちらのパフォーマンスも考慮する必要が出てくる
    - 依存する外部システム（通知基盤外のサービス）は少ないほど良いはず
メッセージング
- キューイング
- スケジューリング
送信先ユーザー情報の管理
- 送信先情報
- オプトイン・オプトアウト
認証
- 個人情報に関わるデータにアクセスする際や認証関連APIとの連携が必要な場合とか？
通知メッセージのテンプレート
- 静的・動的なデータを埋め込むためのテンプレート
- 多言語対応は必要かどうか
エラーハンドリングとリトライ
- 送信失敗などエラーをどうキャッチして、再送信するか
- メールの場合はバウンス処理など
監視
- システムメトリクスだけでなく、通知関連のデータなども（ex. 受信率、クリック率等）
- 通知のトラッキングができるように
  - トレースIDみたいなIDの発行が必要？
拡張性
- 通知チャンネルの追加、テンプレートのカスタマイズ性など
外部サービスとの連携
- 差し替え可能、依存し過ぎない設計にするなど
- 分析基盤との統合・連携など
  - 通知の最適化が何かしらできると人の手で通知の運用をする部分が減って良さそう
  - 自動化できる部分は自動化したいという願い
運用
- 当たり前だが運用（開発者視点、ビジネスサイド視点の両方）まで見据える
  - 今どういう運用がされているのか、これからどういう運用されるのか
テスト
- テストしやすさ、デバッグしやすさ
  - 複数のシステムが連携する構成になりうるので難易度が高い

ソリューション

SaaS

Salesforce、Braze、Airship、OneSignal、SendGridなど色々ある。

単に複数チャンネルの通知が送信できるだけではなく、顧客管理やマーケティングツールだったりなどと連携した通知ができる。

マルチチャンネルをサポートしているサービスは探すと結構色々出てくる。

PaaS

複数チャンネルの通知をサポートしているプラットフォームとしてAWS Pinpointがある。

事例

国内外の事例を漁ってみた。

techblog.zozo.com - リアルタイムマーケティングシステムの紹介とそのリプレイス計画
- AWS Pinpointのようにマルチチャンネルをサポートしつつ、MA要素も含んだ基盤を構築している事例
techblog.zozo.com - マーケティングオートメーションシステムを支えるリアルタイムデータ連携基盤をリプレイスした話
- 上記の続きで、その後リプレースした話
~~techblog.zozo.com - パーソナライズ配信におけるルールベースの最適化改善~~
- すごい。これが通知の真髄だ〜と思った。
- ここまで到達するには通知がビジネスに与える影響が十分見積もられているだろうし、通知の工夫でビジネスインパクトを大きく出せるのだろうと思う
- "真の目的である「ユーザーが本当にほしい通知だけの配信」の実現までには改善の余地が多く残されています。"とのこと
leandrofranchi.medium.com - How to design a Notification System
- マルチチャンネルの通知基盤のシステムアーキテクチャ設計例
- ユーザー関連のデータへのアクセスは特に考慮されていない、あくまで通知の配信のみスコープしている
- 構成は代替こんな感じになるだろうという感想
- 最初から通知の共通インタフェースを用意する必要は必ずしもなくて、通知チャンネルを作っていく度に落ち着いた段階でインタフェースを見出すというのも筋かなと思った
www.notificationapi.com - Notification Service Design - with diagrams
- 上記と同じく、設計例
- 大枠は上記と変わらない。こちらはユーザー設定周りが考慮されていて、上記はロギングが考慮されている設計になっている。
cloudificationzone.com - Notification System Design
- こちらはもう少し具体化された設計例
- Inboundが具体的にどういう通知なのかはちょっとわからなかった
atmarkit.itmedia.co.jp - プッシュ通知の基礎知識＆秒間1万を超えるプッシュ通知基盤のアーキテクチャと仕組みとは
- DynamoDBとNode.jsを活用したプッシュ通知基盤
zenn.dev - 分間10万リクエストを捌く、メール/プッシュ通知大量配信AWSアーキテクチャ
- コストを抑えつつ、よりパフォーマンスの良いアーキテクチャに乗り換えた話
- 一番時間が掛かる配信APIのリクエストを分散してリクエストできるようにすることでスケーラビリティが向上
  - 配信ワーカーの数が増えるとスケーラービリティが線形に上昇
www.slideshare.net - システム高速化フォーラム向けプッシュ通知基盤のアーキテクチャ

AWS Pinpoint

個人的に気になっているAWS Pinpointについて個別に調べてみた。

複数のチャネルに対応したメッセージ（通知）のためのAWSサービス。2016年にリリースされている。
- プッシュ通知、Eメール、SMS、音声メッセージに対応
- 上記に加えて、カスタムチャンネルという機能を使うと通知チャンネルを拡張できる
  - Facebook Messangerを追加するとか
従量課金
- 思ったより高くなさそうな印象
- メールは1万件あたり1.00USD、プッシュ通知は100万件無料、その後は100万件あたり1.00USD
- ユーザー数数百万規模くらいで雑な試算してみるとそれなりの金額になりそうな予感
  - 当たり前だが費用対効果をちゃんと検証する必要がある。結構シビアに。
通知の分析もできる
- マーケティングの施策と連携できそう
  - できることは限られそうではあるので、相性が良いかは要検討事項
スケーラビリティ
- 秒間に送信できる通知件数に上限がある
  - クォータの増加はリクエストできる
- 通知の中で一番時間がネックになるであろう通知を送信する部分のスケールはAWS側にほぼ丸投げできる