リアルタイム通知サービスの設計

リアルタイム通知サービス — システムハイレベル設計 ================================================================================ 0. 目算 ================================================================================ - 10M DAU × 1日あたり20件の通知/ユーザー = 1日あたり2億件の通知 - 2億件 / 86,400秒 ≈ 2,315件/秒（平均） - ピーク負荷（平均の5倍と仮定） ≈ 11,575件/秒 - 各通知ペイロード約1KB → 1日あたり約200GBの生データ取り込み - レイテンシ予算：エンドツーエンドで2秒未満（取り込み → デバイスへの配信） ================================================================================ 1. コアアーキテクチャ ================================================================================ システムは、イベント駆動型のマイクロサービスアーキテクチャを採用しており、以下の主要コンポーネントで構成されています。 ┌──────────────┐ │ プロデューサー │ （投稿サービス、いいねサービス、コメントサービス、フォローサービスなど） └──────┬───────┘ │ 通知イベント（gRPC / 非同期メッセージ） ▼ ┌──────────────────┐ │ APIゲートウェイ / │ レート制限、認証、ルーティング │ ロードバランサー │ （例：AWS ALB / Envoy / Kong） └──────┬───────────┘ │ ▼ ┌──────────────────┐ │ 通知サービス (NS) │ ステートレスサービス（水平スケーリング可能） │ │ - イベントの検証と重複排除 │ │ - ユーザー設定によるエンリッチメント │ │ - チャネルごとのキューへのファンアウト └──────┬───────────┘ │ 通知レコードをDBに書き込み │ メッセージキューに発行 ▼ ┌──────────────────────────────────────────────────┐ │ メッセージキュー / ブローカー │ │ （Apache Kafka — user_idハッシュでパーティション分割） │ │ │ │ トピック： push_notifications │ │ email_notifications │ │ in_app_notifications │ └──┬──────────────┬─────────────────┬──────────────┘ │ │ │ ▼ ▼ ▼ ┌────────┐ ┌──────────┐ ┌────────────────┐ │ プッシュ │ │ メール │ │ アプリ内 │ │ ワーカー │ │ ワーカー │ │ ワーカー │ │ プール │ │ プール │ │ プール │ └───┬────┘ └────┬─────┘ └───────┬────────┘ │ │ │ ▼ ▼ ▼ ┌────────┐ ┌──────────┐ ┌────────────────┐ │ APNs / │ │ SES / │ │ WebSocket │ │ FCM │ │ SendGrid │ │ ゲートウェイ │ └────────┘ └──────────┘ │（永続的な接続）│ └────────────────┘ コンポーネントの説明： A) APIゲートウェイ / ロードバランサー - 内部プロデューサーサービスおよび外部APIコール（例：既読マーク）のエントリポイント。 - レート制限、認証、リクエストルーティングを処理。 - 複数の通知サービスインスタンスにトラフィックを分散。 B) 通知サービス (NS) - ロードバランサーの後ろにデプロイされたステートレスマイクロサービス。 - 通知イベントを受信し、検証し、重複排除（べき等キーチェック）を実行。 - キャッシュ（Redis）またはデータベースからユーザーの通知設定をルックアップ。 - 設定に基づいて、どのチャネル（プッシュ、メール、アプリ内）で配信するかを決定。 - 通知レコードをデータベースに永続化。 - Kafkaトピックにチャネル固有のメッセージを発行。 C) メッセージキュー（Apache Kafka） - 通知作成と配信を分離し、トラフィックの急増を吸収。 - ユーザーごとの順序保証のため、user_idハッシュでパーティション分割。 - 耐久性（レプリケーションファクター=3）とリプレイ機能を提供。 - チャネルごとの独立したトピックにより、コンシューマーの独立したスケーリングが可能。 D) チャネルワーカー（コンシューマーグループ） - プッシュワーカープール：push_notificationsトピックから消費し、リクエストをバッチ処理してAPNs（iOS）およびFCM（Android）に送信。トークン管理とリトライロジックを処理。 - メールワーカープール：email_notificationsトピックから消費し、テンプレートをレンダリングしてSES/SendGrid経由で送信。一時的な障害に対して指数バックオフを実装。 - アプリ内ワーカープール：in_app_notificationsトピックから消費し、WebSocketゲートウェイにプッシュしてリアルタイム配信。WebSocketが切断された場合はポーリングにフォールバック。 E) WebSocketゲートウェイ - オンラインユーザーとの永続的なWebSocket接続を維持。 - 水平スケーリング。Redis Pub/Subまたは共有メッセージバスを使用し、どのゲートウェイノードでもどの接続済みユーザーにも配信可能。 - Redisに接続レジストリを保存（user_id → gateway_nodeマッピング）。 F) 通知既読API - 通知履歴の取得、既読マーク、設定管理のための独立した読み取りパス。 - 書き込みパスに影響を与えないように、読み取りレプリカ/キャッシュから提供。 ================================================================================ 2. データベーススキーマ ================================================================================ プライマリデータストア：PostgreSQL（設定とメタデータ用）+ Cassandra（大規模通知ストレージ用）。 --- PostgreSQL（ユーザー設定とメタデータ）--- TABLE: users user_id UUID PRIMARY KEY email VARCHAR(255) phone VARCHAR(50) created_at TIMESTAMP updated_at TIMESTAMP TABLE: notification_preferences user_id UUID PRIMARY KEY REFERENCES users(user_id) push_enabled BOOLEAN DEFAULT TRUE email_enabled BOOLEAN DEFAULT TRUE in_app_enabled BOOLEAN DEFAULT TRUE quiet_hours_start TIME NULLABLE quiet_hours_end TIME NULLABLE email_digest_freq ENUM('instant', 'hourly', 'daily') DEFAULT 'instant' -- カテゴリごとのオーバーライド likes_push BOOLEAN DEFAULT TRUE likes_email BOOLEAN DEFAULT FALSE comments_push BOOLEAN DEFAULT TRUE comments_email BOOLEAN DEFAULT TRUE follows_push BOOLEAN DEFAULT TRUE follows_email BOOLEAN DEFAULT FALSE mentions_push BOOLEAN DEFAULT TRUE mentions_email BOOLEAN DEFAULT TRUE updated_at TIMESTAMP TABLE: device_tokens token_id UUID PRIMARY KEY user_id UUID REFERENCES users(user_id) platform ENUM('ios', 'android', 'web') device_token VARCHAR(512) is_active BOOLEAN DEFAULT TRUE created_at TIMESTAMP updated_at TIMESTAMP INDEX idx_device_user (user_id) --- Cassandra（通知ストレージ — 時系列読み取りに最適化）--- TABLE: notifications user_id UUID -- パーティションキー created_at TIMEUUID -- クラスタリングキー (DESC) notification_id UUID type TEXT -- 'like', 'comment', 'follow', 'mention', 'system' actor_id UUID target_entity_type TEXT -- 'post', 'comment', 'profile' target_entity_id UUID message TEXT is_read BOOLEAN channels_delivered SET<TEXT> -- {'push', 'email', 'in_app'} metadata TEXT -- 拡張性のためJSONブロブ PRIMARY KEY ((user_id), created_at) WITH CLUSTERING ORDER BY (created_at DESC) AND default_time_to_live = 7776000 -- 90日間のTTL TABLE: notification_counts (マテリアライズド/カウンターテーブル) user_id UUID PRIMARY KEY unread_count COUNTER --- Redis（キャッシュレイヤー）--- - ユーザー設定キャッシュ：キー = pref:{user_id}, TTL = 10分 - 未読カウントキャッシュ：キー = unread:{user_id}, TTL = 5分 - 重複排除セット：キー = dedup:{idempotency_key}, TTL = 24時間 - WebSocket接続レジストリ：キー = ws:{user_id} → gateway_node_id ================================================================================ 3. スケーリング戦略 ================================================================================ A) ステートレスサービスの水平スケーリング - 通知サービス、全ワーカープール、WebSocketゲートウェイはステートレスであり、水平スケーリング可能です。 - CPU、メモリ、キューラグメトリクスに基づく自動スケーリンググループ（Kubernetes HPA）。 - 目標：各NSインスタンスは毎秒約500リクエストを処理。ピーク時には約25インスタンスが必要。 B) Kafkaパーティショニング - 各トピックに64パーティションから開始（最大64コンシューマー/グループを許可）。 - ユーザーごとの順序保証のため、user_idハッシュでパーティション分割。 - スループットの増加に伴いパーティションをスケール（注意して再パーティション）。 - チャネルごとの独立したコンシューマーグループにより、独立したスケーリングが可能。 C) データベーススケーリング - Cassandra：自然に水平スケーリング可能。6ノードクラスター（RF=3）から開始。 データ量が増加するにつれてノードを追加。パーティションキー=user_idが負荷を均等に分散。 - PostgreSQL：設定（比較的小さなデータセット：10M行）には初期段階で垂直スケーリング。 読み取り負荷の高い設定ルックアップのために読み取りレプリカを追加。必要に応じてuser_idによるシャーディングを検討。 - Redisクラスター：キャッシュと接続レジストリのための自動シャーディングを備えた3ノード以上。 D) WebSocketゲートウェイスケーリング - 各ゲートウェイノードは、約10万の同時接続を処理。 - 10M DAUで約30％が同時オンライン = 300万接続 → 約30のゲートウェイノード。 - ノード間メッセージルーティングのためのRedis Pub/Subまたは軽量メッセージバス（例：NATS）。 - グレースフルな再バランシングによるユーザーからノードへのマッピングのためのConsistent Hashing。 E) レート制限とバックプレッシャー - 悪用を防ぐため、通知プロデューサーのレート制限（例：プロデューサーあたり毎秒最大1000イベント）。 - Kafkaコンシューマーラグの監視とアラート。ラグがしきい値を超えた場合にコンシューマーを自動スケール。 - カスケード障害を防ぐための外部サービス（APNs、FCM、SES）へのサーキットブレーカー。 F) 将来の成長パス - Kafka MirrorMaker 2によるクロスリージョンレプリケーションを備えたマルチリージョンデプロイメントへの移行。 - 通知集約/バッチ処理レイヤーの導入（例：「Xさんと他の5人があなたの投稿にいいねしました」）。 - 時間に敏感な通知のための優先度付きキューの追加（例：ダイレクトメッセージ vs いいね通知）。 ================================================================================ 4. 信頼性と耐障害性 ================================================================================ A) データ耐久性 - Kafka：レプリケーションファクター=3、min.insync.replicas=2、acks=all。 ブローカーが1台故障してもデータ損失がないことを保証。 - Cassandra：レプリケーションファクター=3、書き込み整合性=QUORUM（3台中2台）。 単一ノード障害をデータ損失なしで許容。 - PostgreSQL：少なくとも1台のスタンバイへの同期レプリケーション。 B) 少なくとも1回の配信 - Kafkaコンシューマーは、処理が成功した後のみオフセットをコミット。 - ワーカーは、通知IDを重複排除キーとして使用し、べき等配信を実装。 - プッシュ/メール配信が失敗した場合、メッセージはリトライのためにKafkaに残る。 - N回のリトライ後（例：指数バックオフで5回リトライ）に失敗したメッセージのためのデッドレターキュー（DLQ）。 C) 高可用性（目標99.9% = 年間最大8.76時間のダウンタイム） - 全てのサービスは3つのアベイラビリティゾーン（AZ）にまたがってデプロイ。 - Podのアンチアフィニティルールを持つKubernetesにより、レプリカがAZに分散されることを保証。 - データベースクラスターは複数のAZにまたがり、自動フェイルオーバー。 - ロードバランサーのヘルスチェックにより、異常なインスタンスを自動的に削除。 - デプロイメント関連のダウンタイムを最小限に抑えるためのブルーグリーンまたはカナリアデプロイメント。 D) グレースフルデグラデーション - プッシュ通知サービス（APNs/FCM）がダウンした場合、通知はKafkaにキューイングされ、リトライされる。 - WebSocketゲートウェイが過負荷の場合、クライアントは通知既読APIのポーリングにフォールバックする。 - Cassandraが一時的に利用できない場合、通知はKafkaにバッファリングされる（Kafkaは数日間の保持期間がある）。 - 全ての外部依存関係に対するサーキットブレーカーパターンとフォールバック動作。 E) モニタリングとアラート - エンドツーエンドのレイテンシ追跡：作成時のタイムスタンプ → 配信時のタイムスタンプ（P50、P95、P99）。 - トピックおよびコンシューマーグループごとのKafkaコンシューマーラグ監視。 - チャネルごとのエラーレートダッシュボード（プッシュ失敗率、メールバウンス率）。 - アラート対象：P95でレイテンシ > 2秒、コンシューマーラグ > 10Kメッセージ、エラーレート > 1%、可用性 < 99.9%。 F) ディザスタリカバリ - Kafkaトピックデータは7日間保持され、任意の時点からのリプレイが可能。 - Cassandraのスナップショットは毎日取得され、S3にクロスリージョンレプリケーションで保存。 - PostgreSQLのWALアーカイブをS3に保存し、ポイントインタイムリカバリを可能にする。 - 目標RTO < 1時間、RPO < 5分での完全なクラスターリカバリのためのランブック。 ================================================================================ 5. 主要なトレードオフ ================================================================================ トレードオフ1：可用性 vs. 厳密な整合性（AP対CP） 決定：通知配信と既読ステータスには、結果整合性を選択しました。 - QUORUM書き込みを備えたCassandraは、可用性とパーティション耐性を優先しながら、通知に対して十分に強力な整合性を提供します。 - ユーザーは一時的に古い未読カウント（5分TTLでRedisにキャッシュ）を見る可能性がありますが、これは通知システムでは許容範囲です。カウントの完全なリアルタイム精度は重要ではありません。 - 代替案 — PostgreSQLのような厳密に整合性の取れたデータベースを全ての通知ストレージに使用する — は、1日あたり2億件の書き込みに対するスケーリングのボトルネックとなり、ネットワークパーティション中の可用性を危険にさらす可能性があります。 - 影響：ユーザーは、数秒間、通知カウントが1〜2件ずれている場合があります。これは、通知システム全体が利用できなくなるリスクと比較して、軽微なUXの問題です。 トレードオフ2：アプリ内通知のためのプッシュモデル（WebSockets） vs. プルモデル（ポーリング） 決定：ポーリングをフォールバックとしたプッシュファーストモデルとしてWebSocketsを選択しました。 - WebSockets経由のプッシュは、レイテンシ要件の2秒未満を満たすリアルタイム（サブ秒）配信を実現します。 - しかし、数百万の永続接続を維持することはリソース集約的であり（300万同時接続に対して約30のゲートウェイノード）、運用上の複雑さ（接続管理、ハートビート、再接続ロジック）が増加します。 - 代替案 — 純粋なポーリング — は運用が簡単ですが、レイテンシが増加する（ポーリング間隔が長い場合）か、サーバー負荷が劇的に増加する（ポーリング間隔が短い場合）かのどちらかになります。300万同時ユーザーが2秒ごとにポーリングする場合、ポーリングだけで毎秒150万リクエストとなり、WebSocket接続を維持するよりもはるかに高コストです。 - 妥協案：オンラインユーザーにはWebSocketsを使用し、WebSocket接続が確立できない場合（例：制限の厳しいファイアウォール）はポーリング（より長い間隔で）にフォールバックします。ユーザーがオフラインの場合のシナリオは、APNs/FCM経由のプッシュ通知で処理されます。 トレードオフ3：単一通知ストア（Cassandra） vs. ポリグロット永続化 決定：通知ストレージにはCassandraを、ユーザー設定/メタデータにはPostgreSQLを使用することを選択しました。全てを単一のデータベースで行うのではなく。 - Cassandraは、高スループットの時系列書き込み（1日あたり2億件）とパーティションキーベースの読み取り（ユーザーの通知取得）に優れており、これが主要なアクセスパターンです。 - PostgreSQLは、ユーザー設定の関連性（ユーザーテーブルとの結合、設定のトランザクション更新）により適しています。 - トレードオフは、運用上の複雑さの増加（維持、監視、バックアップが必要な2つのデータベースシステム）と、システム間でデータを整合させる必要性（例：ユーザーが削除された場合、Cassandraの通知をクリーンアップする必要がある）です。 - イベント駆動型のクリーンアッププロセスによりこれを軽減します。ユーザー削除イベントは、非同期Cassandraクリーンアップジョブをトリガーします。 トレードオフ4：少なくとも1回の配信 vs. 厳密に1回の配信 決定：アプリケーションレベルの重複排除を備えた、少なくとも1回の配信セマンティクスを選択しました。 - 分散システム全体での厳密に1回の配信は、非常に高コストで複雑です（分散トランザクションまたはKafkaの厳密に1回のセマンティクスが必要で、大幅なパフォーマンスオーバーヘッドが発生します）。 - 少なくとも1回は、よりシンプルでパフォーマンスが高いです。重複通知は、べき等キー（配信前にチェックされる通知ID）を使用してアプリケーションレイヤーで処理されます。 - リスクは、まれな障害シナリオでは、ユーザーが重複プッシュ通知を受信する可能性があることです。これは、通知の損失（最大1回）や、厳密に1回の配信の複雑さ/パフォーマンスコストと比較して、軽微な迷惑です。 ================================================================================ 概要 ================================================================================ この設計は、2秒未満の配信レイテンシで3つのチャネルにわたる1日あたり2億件の通知を処理します。Kafkaを中心神経系とするイベント駆動型アーキテクチャは、耐久性、分離、および自然なバックプレッシャー処理を提供します。Cassandraは水平スケーリング可能な通知ストレージを提供し、WebSocketゲートウェイはリアルタイムのアプリ内配信を可能にします。システムは、マルチAZデプロイメント、各レイヤーでのレプリケーション、およびグレースフルデグラデーションパターンを通じて、99.9%の可用性を持つように設計されています。主要なトレードオフは、厳密な整合性と厳密に1回の配信セマンティクスよりも、可用性、スケーラビリティ、および運用上のシンプルさを優先しており、これらはまれな重複が許容される通知システムにとって適切な選択です。

ハイレベルデザイン 1. コアアーキテクチャ 優れたデザインは、イベント駆動型、チャネル認識型、そして耐久性優先です。 メインフロー - 「いいね」、コメント、フォロー、メンション、メッセージなどのプロダクトサービスが、通知に値するイベントを発行します。 - APIゲートウェイまたは内部イベント取り込みAPIは、必要に応じて直接リクエストを受け付けますが、ほとんどのトラフィックは内部イベントストリームから来るべきです。 - 通知オーケストレーターは、イベントを検証し、重複排除し、受信者を展開し、ユーザー設定を確認し、耐久性のある通知レコードを作成し、チャネル配信ジョブを発行します。 - メッセージキュー/イベントバスは、下流のチャネルワーカーのために作業をバッファリングします。 - チャネルワーカーは、プッシュ、メール、アプリ内配信を独立して処理します。 - 配信ステータスサービスは、通知の状態を更新し、必要に応じて再試行します。 - 読み取りAPIは、クライアントに通知インボックスと未読カウントを提供します。 - WebSocket/SSEゲートウェイは、オンラインユーザーにリアルタイムでアプリ内更新をプッシュできます。 主要コンポーネント - APIゲートウェイ - 認証、レート制限、ルーティング、オブザーバビリティ。 - クライアント読み取りAPIおよび管理APIに使用されます。 - イベントバス/取り込みストリーム - Kafka/Pulsarスタイルの耐久性のあるログ。 - プロデューサー：ソーシャルグラフ、コンテンツ、メッセージング、モデレーションなど。 - ユーザーごとの順序性を必要に応じて維持するために、recipient_user_idでパーティション化されたトピック。 - 通知オーケストレーター - イベントを消費するステートレスサービス。 - 責任： - スキーマ検証 - event_idまたは重複排除キーを使用した冪等性チェック - ファンアウト決定 - 設定ルックアップ - テンプレート選択 - 優先度分類 - カノニカル通知レコードの永続化 - チャネルごとの配信タスクのエンキュー - データが失われないように、まず書き込みを行い、次に配信をスケジュールします。 - 設定サービス - ユーザーレベルのチャネル設定、サイレントアワー、デバイス トークン、ロケール、メール検証ステータスを返します。 - 強力な整合性を持つユーザー設定ストアとキャッシュによってバックアップされます。 - 通知ストア - 通知メタデータとユーザーインボックスレコードのカノニカルな耐久性ストア。 - 書き込みと最近の読み取りに最適化されています。 - 配信キュー - チャネルごとの別個のキュー/トピック：プッシュ、メール、アプリ内。 - 異なる再試行およびスループットポリシーを可能にします。 - プッシュワーカー - APNS/FCMと統合します。 - トークン無効化、プラットフォーム固有のペイロード、指数バックオフを処理します。 - メールワーカー - メールプロバイダーと統合します。 - ほとんどのソーシャルイベントでは、プッシュ/アプリ内よりも優先度が低いです。 - バウンス、苦情、抑制リストを追跡します。 - アプリ内配信ワーカー - インボックスストアに書き込み、ユーザーがオンラインの場合はWebSocket/SSE経由でプッシュします。 - オフラインの場合は、インボックスAPIからのプルを通じて通知が引き続き利用可能です。 - リアルタイムゲートウェイ - アクティブユーザーのために永続的なクライアント接続を維持します。 - アプリ内配信イベントをサブスクライブし、2秒未満で送信します。 - 読み取りAPI/インボックスサービス - 通知のリスト表示、既読マーク、未読カウント、ページネーション。 - 通知インボックスストアとキャッシュから読み取ります。 - 再試行/デッドレタープロセッサー - 一時的な失敗を再試行します。 - ポイズンメッセージまたは永続的な失敗のためのDLQ。 - リプレイをサポートします。 - オブザーバビリティスタック - メトリクス：エンキューから配信までのレイテンシ、チャネルごとの成功率、再試行回数、キューラグ。 - ログと分散トレーシング。 - SLA違反のアラート。 インタラクションシーケンス - コメントサービスがCommentCreatedイベントを発行します。 - イベントバスがイベントを耐久性のある方法で保存します。 - 通知オーケストレーターがイベントを消費し、受信ユーザーを決定し、設定を確認し、通知行を作成し、以下にジョブを発行します： - アプリ内キュー - 有効で十分な緊急度があればプッシュキュー - 設定されていればメールキュー - アプリ内ワーカーがインボックスアイテムを保存し、ユーザーがオンラインの場合はWebSocket経由でプッシュします。 - プッシュワーカーがFCM/APNSに送信します。 - 配信確認/ステータス更新が書き戻されます。 - ユーザーは読み取りAPI経由で完全なインボックスを取得できます。 スループット見積もり - 10M DAU × 20 通知/日 = 200M 通知/日。 - 平均スループット = 約 2,315 通知/秒。 - 実際のシステムにはスパイクがあるため、少なくとも10倍のピークヘッドルームを設計します：1秒あたり20kから30kの通知作成、チャネルファンアウトにより下流の配信はさらに増加します。 - この規模は、パーティション化されたキューと水平にスケールされたステートレスワーカーで非常に管理可能です。 2. データベーススキーマ 分割モデルを使用します： - カノニカル通知レコードと設定のためのトランザクション耐久ストア - ホットリードのためのキャッシュ - 高度なインボックスクエリのためのオプションの検索/インデックスストア 基本スキーマ users_notification_preferences - user_id PK - push_enabled boolean - email_enabled boolean - in_app_enabled boolean - quiet_hours_start - quiet_hours_end - timezone - locale - email_address - email_verified boolean - push_tokens json / 別テーブル - notification_type_settings json または正規化された子テーブル - updated_at user_device_tokens - token_id PK - user_id - platform - device_token - app_version - last_seen_at - is_active - unique(device_token) - index(user_id) notifications - notification_id PK - recipient_user_id - actor_user_id nullable - type - object_type - object_id - dedupe_key - title - body - payload json - priority - created_at - expire_at nullable - aggregation_key nullable - source_event_id unique - indexes: - (recipient_user_id, created_at desc) - (recipient_user_id, notification_id) - unique(source_event_id) または unique(dedupe_key) notification_deliveries - delivery_id PK - notification_id - channel enum(push, email, in_app) - status enum(pending, sent, delivered, failed, suppressed) - provider_message_id nullable - attempt_count - last_attempt_at - next_retry_at nullable - failure_reason nullable - delivered_at nullable - indexes: - (notification_id) - (channel, status, next_retry_at) notification_reads - notification_id - user_id - read_at - primary key(notification_id, user_id) - index(user_id, read_at) オプションの最適化：user_inbox テーブル - user_id - notification_id - created_at - read_state - primary key(user_id, created_at, notification_id) これは、インボックス取得のためのワイドカラムストアのメインテーブルになり得ます。 ストレージの選択肢 - 設定：リレーショナルDBまたは強力な整合性を持つキーバリューストア。 - 通知/インボックス：Cassandra/DynamoDB/BigtableスタイルのワイドカラムKVは、アクセスパターンが主にuser_idと最近の時間順の読み取りであり、書き込み量が非常に多いため魅力的です。 - 配信監査/ステータス：レポート要件に応じてリレーショナルまたはKVストア。 - キャッシュ：未読カウントと最近のインボックスページにはRedis。 3. スケーリング戦略 水平スケーリング - すべてのステートレスサービスは水平に自動スケールします：オーケストレーター、チャネルワーカー、読み取りAPI、WebSocketゲートウェイ。 - ロードを均等に分散し、ユーザーごとの順序性を維持するために、recipient_user_idでイベントトピックをパーティション化します。 - メールバックログがプッシュレイテンシに影響を与えないように、チャネルと優先度ごとにキューを分離します。 データスケーリング - user_idで通知データをシャードします。 - 非常に大規模なユーザーの場合、必要に応じて時間バケットを使用します。たとえば、パーティションキー（user_id、month）です。 - ビジネスが許可する場合、保持ポリシーに従って古い低価値の通知をTTLで削除し、安価なオブジェクトストレージにアーカイブします。 - 未読カウントと最新のN件の通知をキャッシュします。 トラフィックシェーピング - 優先度レーン： - 高：直接メンション、メッセージ、セキュリティアラート - 中：コメント、いいね - 低：ダイジェスト可能なアクティビティまたはプロモーションアイテム - スパイク時には、まず高優先度の通知を保護します。 - 低優先度のメール生成をバッチ処理します。 ファンアウト戦略 - レイテンシターゲットが2秒未満であるため、ユーザーごとのインボックスとリアルタイムチャネルでは、書き込み時のファンアウトを優先します。 - 非常に大規模なファンアウトイベント（例：何百万人ものセレブリティ投稿）の場合、ハイブリッド処理を使用します： - 粗いイベントを一度作成します。 - 非同期にバッチでファンアウトします。 - 非クリティカルなチャネルをダイジェストまたは遅延配信に低下させる可能性があります。 これにより、スタンプede（同時アクセスによる過負荷）を防ぎます。 ジオスケーリング - 取り込みおよび配信APIのためのマルチリージョンアクティブアクティブ。 - クロスリージョン書き込みを削減するために、可能な限りユーザーアフィニティをホームリージョンに維持します。 - クリティカルなメタデータをグローバルにレプリケートします。 - チャネルプロバイダーは最も近いリージョンから呼び出されます。 キャパシティプランニング - 1日あたり2億件のカノニカル通知。 - 各通知が平均2〜3回のチャネル試行を作成する場合、下流の配信レコードは1日あたり4億〜6億件になる可能性があります。 - ピークスループットに合わせてキューパーティションのサイズを設定します。例えば、ブローカーに応じて数十から数百のパーティションです。 - WebSocketゲートウェイは、DAUではなく、同時オンラインユーザー数に合わせてサイズ設定します。 4. 信頼性と耐障害性 可用性ターゲット：99.9% - すべてのティアでマルチAZデプロイメント。 - 単一障害点はありません。 - インスタンス間のロードバランサー。 - レプリケーションを備えたマネージドブローカーとDB。 通知データの損失なし - 配信試行の前にカノニカル通知を永続化します。 - レプリケーション係数 >= 3 の耐久性のあるログ/キューを使用します。 - 冪等なコンシューマーとプロデューサーの再試行。 - トランザクション操作から通知イベントを発行する場合、アップストリームプロデューサーサービスのアウトボックパターン。 - 例：コメントの書き込みと通知イベントは、イベントの損失を防ぐためにDBトランザクション+アウトボックを使用してリンクされます。 - イベントログとDLQからのリプレイ機能。 障害処理 - 内部的には少なくとも1回の配信を行い、オーケストレーターとチャネルレイヤーで重複排除を行います。 - 一時的なプロバイダー障害に対する指数バックオフ再試行。 - フォーマットエラーまたは繰り返し失敗するタスクのためのDLQ。 - APNS/FCM/メールプロバイダーのサーキットブレーカー。 - フォールバック動作： - プッシュプロバイダーが劣化した場合でも、アプリ内通知を保存します。 - メールプロバイダーがダウンした場合、キューに入れて後で再試行します。 データの一貫性と整合性 - 一意のsource_event_idまたはdedupe_keyにより、重複通知の作成を防ぎます。 - 配信ステートマシンは、無効な遷移を防ぎます。 - 設定更新が即時の効果を必要とする場合は強力な整合性を使用します。それ以外の場合は、キャッシュ無効化によるバウンドされた遅延を使用します。 災害復旧 - クロスリージョンでレプリケートされたメタデータとバックアップ。 - 定期的なスナップショットとWAL/バイナリログまたはストリーム保持。 - レプリケートされた耐久性のあるログを使用したRPO（目標復旧時点）はほぼゼロ。 - インフラストラクチャ・アズ・コードとウォームスタンバイ/アクティブアクティブ設計によるRTO（目標復旧時間）の最小化。 運用の信頼性 - エンキューから永続化まで、および永続化から配信までのレイテンシに対するSLO。 - キューラグのアラーム。 - プッシュ/メール/アプリ内パスの合成プローブ。 - 下流プロバイダーがスロットリングした場合のバックプレッシャー制御。 - 悪用を封じ込めるためのテナント/イベントタイプごとのレート制限。 5. 主要なトレードオフ トレードオフ1：少なくとも1回の配信 vs 厳密に1回の配信 - 選択：冪等性を持つ少なくとも1回の配信。 - 理由：ブローカー、データベース、APNS/FCM/メールなどの外部プロバイダー全体での厳密に1回の配信は、コストが高く、しばしば非現実的です。 - 影響：重複した試行が時々発生する可能性がありますが、重複排除キーと冪等な書き込みにより、ユーザーに見える重複はまれになります。 - 利点：障害下での信頼性がはるかに高く、よりシンプルです。 トレードオフ2：通知インボックスのためのワイドカラム/KVストア vs リレーショナルDB - 選択：インボックスにはワイドカラムまたはDynamoスタイルのストア、設定や一部のメタデータにはリレーショナル。 - 理由：通知ワークロードは書き込みが多く、追加が中心で、ほとんどの読み取りはユーザーと最近の順序で行われます。 - 影響：アドホックなクエリ機能が弱まり、データモデリングがより慎重になります。 - 利点：水平スケーラビリティと予測可能なパフォーマンスがはるかに優れています。 トレードオフ3：書き込み時のファンアウト vs 読み取り時のファンアウト - 選択：主に書き込み時のファンアウト。 - 理由：2秒未満のレイテンシ要件と、プッシュ/アプリ内での即時性の必要性。 - 影響：特に高ファンアウトイベントの場合、書き込み増幅が大きくなります。 - 緩和策：メガファンアウトケースのためのハイブリッドアプローチ。 トレードオフ4：リアルタイムプッシュ配信 vs プルのみのインボックス - 選択：ハイブリッド。 - 理由：プッシュ/WebSocketはアクティブユーザーに低レイテンシを提供し、プルAPIはオフラインユーザーに回復性を提供します。 - 影響：接続状態とインボックスの永続性の両方が必要になるため、システムの複雑さが増します。 - 利点：最高のユーザーエクスペリエンスと信頼性。 推奨される最終アーキテクチャ概要 - 耐久性のあるイベントバスを通じてイベントを取り込みます。 - ステートレスな通知オーケストレーターを使用して、重複排除、設定確認、通知レコードの永続化、チャネル固有のジョブの発行を行います。 - 水平スケーラブルなユーザーパーティションストアにインボックスデータを格納し、設定にはリレーショナルまたは強力な整合性を持つKVを使用します。 - 専用のプッシュ、メール、アプリ内ワーカーを通じて配信します。 - リアルタイムのアプリ内更新にはWebSocket/SSEを使用し、インボックス取得には通常の読み取りAPIを使用します。 - マルチAZデプロイメント、レプリケートされたキュー、耐久性優先の書き込み、冪等性、再試行、DLQ、リプレイ、およびクロスリージョン災害復旧を通じて信頼性を確保します。 この設計は、10M DAUと1日あたり2億件の通知を余裕をもってサポートし、ほとんどのリアルタイム通知で2秒未満の配信を満たし、データ損失なしで99.9%の可用性を維持します。