通知基盤構築についてのメモ書き

bmf-san アーキテクチャ
#通知

概要

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

通知基盤とは

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

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

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

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

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

ソリューション

SaaS

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

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

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

PaaS

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

事例

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

AWS Pinpoint

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

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

参考

所感

誰が（運営、管理者、マーケティング担当者、開発者・・etc）、何を（メッセージ内容）、誰に、どの通知チャンネルで、いつ（いつまでに）通知したいのか、通知の総量はどれくらいなのか、ということあたりがまず整理されている必要があると思った。（そりゃそうだという感じだけど・・）