スケーラブルなリアルタイム通知システムの設計

デザイン：スケーラブルなリアルタイム通知システム 1. 全体アーキテクチャ システムは、イベントの取り込み、ルーティング、および最小限の遅延で接続されたクライアントへのプッシュを行うために連携する、いくつかの異なるレイヤーで構成されています。 クライアントレイヤー：モバイルおよびWebクライアントは、Connection Gatewayサーバーのフリートと永続的なWebSocket接続を維持します。各クライアントは接続時に認証を行い、ゲートウェイにユーザーIDを登録します。 APIゲートウェイ/ロードバランサー：レイヤー7ロードバランサー（例：AWS ALBまたはNGINX）がConnection Gatewaysの前に配置されます。ユーザーIDの一貫性ハッシュを使用して、新しいWebSocketアップグレードリクエストをルーティングするため、再接続は同じゲートウェイノードに着地する傾向があり、状態の変動を減らします。また、内部サービスがイベントを発行するためのRESTエンドポイントも公開します。 イベント発行サービス：内部プラットフォームサービス（サービス、コメントサービス、フレンドサービスなど）は、中央メッセージブローカーにイベントを発行します。ペイロードを検証し、メタデータ（タイムスタンプ、通知ID）でリッチ化し、ブローカーに書き込む薄い発行APIを呼び出します。 メッセージブローカー（Kafka）：イベントは、ユーザーIDでパーティション化されたKafkaトピックに書き込まれます。これにより、ユーザーごとの順序配信が保証され、コンシューマーの水平スケーリングが可能になります。Kafkaの永続ログは、少なくとも1回の配信保証に必要なリプレイ機能も提供します。 通知ファンアウトサービス：ステートレスなコンシューマーワーカーのプールがKafkaから読み取ります。各イベントについて、ワーカーは高速キャッシュ（Redis）でターゲットユーザーのサブスクリプション設定を検索し、どのユーザーが通知を受信すべきかを判断し、メッセージを正しいConnection Gatewayにルーティングします。高ファンアウトイベント（例：有名人の投稿）の場合、ホットパスをブロックしないように、別の非同期ファンアウトジョブがトリガーされます。 Connection Gateway（WebSocketサーバー）：これらは、開いているWebSocket接続を維持するステートフルサーバーです。各ゲートウェイは、ユーザーIDから接続ハンドルへのインメモリマップを保持します。ルーティングされた通知が（Redis Pub/Subや直接gRPC呼び出しなどの内部Pub/Subチャネル経由で）到着すると、ゲートウェイは適切なWebSocket接続にプッシュします。ユーザーが接続されていない場合、ゲートウェイはプッシュを破棄し、後で配信するために永続化レイヤーに依存します。 プレゼンス＆ルーティングサービス：Redisクラスターは、短いTTLを持つユーザーIDからゲートウェイノードIDへのマッピングを格納し、ハートビートによって更新されます。Fanout Serviceはこれをクエリして、通知をルーティングするゲートウェイを知ります。エントリが存在しない場合、ユーザーはオフラインです。 通知ストレージ（Cassandra）：生成されたすべての通知はCassandraに書き込まれ、ユーザーIDをキーとし、タイムスタンプでソートされます。これは2つの目的を果たします。通知インボックスUIをパワーアップし（ユーザーは過去の通知をスクロールバックできます）、少なくとも1回の配信を可能にします（ユーザーがオンラインになったときに、クライアントはこのストアから未読通知を取得します）。 配信確認：クライアントは、通知を受信した後、WebSocket経由でACKメッセージを送信します。ゲートウェイはこのACKをKafkaに書き込み、コンシューマーはCassandraで通知を配信済みとしてマークします。しきい値よりも古い未確認の通知は、配信のために再キューイングされます。 2. 技術選択と理由 ロングポーリングまたはSSE over WebSocket：WebSocketは、全二重、低オーバーヘッドの永続接続を提供します。ロングポーリングは、繰り返しのHTTPハンドシェイクでサーバーリソースを浪費し、遅延を追加します。Server-Sent Events（SSE）は一方向であり、ACKフローには適していません。100万同時接続では、WebSocketが最もリソース効率の高い選択肢です。各接続は約10〜50 KBのメモリを消費するため、100万接続は適度なサイズのゲートウェイフリートで実現可能です。 RabbitMQ over Kafka：Kafkaは、高スループット（毎秒数百万メッセージ）、永続ログストレージ、コンシューマーグループセマンティクス、およびメッセージのリプレイ機能のために選択されています。RabbitMQはタスクキューに適したブローカーですが、そのメッセージモデルは、ここで必要なファンアウトおよびリプレイパターンにはあまり適していません。ユーザーIDによるKafkaのパーティショニングも、消費を自然に並列化します。毎秒10,000件の通知で、Kafkaはかなりのヘッドルームを持ってこれを処理します。 プレゼンスとPub/SubのためのRedis：Redisは、プレゼンスルックアップ（ユーザーID→ゲートウェイノード）のためにミリ秒未満の読み取りを提供します。Redis Pub/SubまたはRedis Streamsは、Fanout ServiceとConnection Gateways間の内部チャネルに使用でき、配信パスへの遅延を最小限に抑えます。 MySQL/PostgreSQL over Cassandra：通知履歴は、高カーディナリティ（ユーザーごとの1つのパーティション）を持つ書き込み負荷の高い時系列ワークロードです。Cassandraのワイドカラムモデル、チューニング可能な一貫性、および線形水平スケーラビリティは、それを理想的なものにします。リレーショナルデータベースは複雑なシャーディングを必要とし、書き込みスループットに苦労します。Cassandraの最終的な一貫性は、通知履歴がトランザクションレコードではないため、ここでは許容できます。 ステートレスファンアウトワーカー：ファンアウトワーカーをステートレスに保つことで、コンシューマーグループ内のKafkaコンシューマーインスタンスを増やすだけで水平にスケーリングできます。 3. 設計が各要件を満たす方法 スケーラビリティ（100万同時ユーザー、毎秒10,000件の通知）：Connection Gatewaysは水平にスケーリング可能です。1台の最新サーバーで50,000〜100,000のWebSocket接続を保持できるため、10〜20のゲートウェイノードで100万ユーザーを処理できます。ロードバランサーが新しい接続を分散します。Kafkaパーティションがファンアウトワーカーをスケーリングします。Cassandraはノードとともに書き込みを線形にスケーリングします。Redis Clusterはプレゼンスデータをシャーディングします。単一のコンポーネントがボトルネックになることはありません。 遅延（P99 < 200ms）：クリティカルパスは次のとおりです。イベント発行→Kafka書き込み（約5ms）→FanoutワーカーがRedisでプレゼンスを消費してルックアップ（約5ms）→Redis Pub/SubまたはgRPC経由でゲートウェイにルーティング（約5ms）→ゲートウェイがWebSocket経由でプッシュ（ネットワーク約10ms）。中央値ケースでは合計で50msをはるかに下回ります。200msのP99予算は、ピークロード時のKafkaコンシューマーラグとネットワークジッターを考慮に入れています。Fanoutワーカーロジックをシンプルに保ち、Redisルックアップをキャッシュすることで、ホットパスが高速に保たれます。 信頼性（少なくとも1回の配信）：通知は、プッシュ試行の前または同時にCassandraに永続化されます。WebSocketプッシュが失敗した場合、またはクライアントがACKを送信しない場合、通知はCassandraで未読状態のままになります。再接続時に、クライアントは未読通知を取得します。Kafkaのコンシューマーオフセットコミットは、ファンアウトワーカーがメッセージのルーティングに成功した後のみ行われるため、イベントがサイレントにドロップされることはありません。これにより、エンドツーエンドで少なくとも1回のセマンティクスが提供されます。 可用性（99.95％の稼働時間）：すべてのコンポーネントは複数のアベイラビリティゾーンにデプロイされます。ロードバランサー、Kafkaブローカー、Redis Clusterノード、Cassandraノード、およびファンアウトワーカーはすべてN+1またはN+2の冗長性で実行されます。ゲートウェイノードの障害は、クライアントが再接続（指数バックオフ付きのWebSocket再接続ロジック）し、数秒以内に正常なノードに着地する原因となります。Kafkaのレプリケーションファクター3により、ブローカー障害によるデータ損失を防ぎます。Cassandraのレプリケーションファクター3とクォーラム読み取り/書き込みにより、ノード障害に耐えられます。このアーキテクチャは、99.95％の稼働時間を容易に達成します。 4. トレードオフ 複雑さとシンプルさのトレードオフ：この設計には、Kafka、Redis、Cassandra、WebSocketゲートウェイ、ファンアウトワーカー、プレゼンスサービスなど、多くの稼働部品があります。これは、単純なポーリングシステムや単一ブローカーセットアップよりも運用が大幅に複雑になります。トレードオフは、スケールの要件によって正当化されますが、成熟したDevOpsプラクティス、優れたオブザーバビリティ（分散トレーシング、コンポーネントごとのメトリクス）、およびオンコール専門知識が必要です。 少なくとも1回 vs. 厳密に1回：厳密に1回の配信には、Kafka、Cassandra、およびゲートウェイ間の分散トランザクションが必要になり、遅延と複雑さが大幅に増加します。代わりに少なくとも1回が選択されます。これは、ユーザーが時折重複した通知を目にする可能性があることを意味します。これはクライアント側で通知IDによる重複排除によって処理されます。ソーシャルメディア通知（いいねやコメント）の場合、重複は軽微なUXの迷惑であり、重大な障害ではありません。これは許容できるトレードオフです。 ステートフルゲートウェイ：WebSocketゲートウェイはステートフルです（ライブ接続を保持します）。これにより、ローリングデプロイメントと障害復旧が、完全にステートレスなサービスよりもわずかに複雑になります。クライアントは再接続ロジックを実装する必要があります。トレードオフは、リアルタイムプッシュにはステートフルゲートウェイが必要であるということです。永続接続なしでクライアントにプッシュする方法はありません。 読み取り時 vs. 書き込み時のファンアウト：この設計は書き込み時にファンアウトします（ファンアウトワーカーは各受信者のゲートウェイに即座にプッシュします）。フォロワーが数百万人のユーザーの場合、これはホットパスの問題（有名人の投稿が数百万のファンアウト操作を引き起こす）を作成します。軽減策は、フォロワー数がしきい値を超えるアカウントのために別の高ファンアウトジョブキューを使用し、非同期で処理することです。トレードオフは、フォロワーが多いユーザーは通知遅延がわずかに高くなる可能性があることですが、これは一般的に許容できます。 Redis Pub/Subの信頼性：Redis Pub/Subはメッセージを永続化しません。メッセージが発行されたときにゲートウェイがRedisから一時的に切断された場合、そのメッセージを見逃します。これは、Cassandra永続化レイヤーによって軽減されます（クライアントは再接続時に通知を取得します）が、リアルタイムプッシュはベストエフォートであり、永続ストアがセーフティネットとなります。Pub/Subの代わりにRedis Streamsを使用すると、わずかに複雑さが増す代わりに永続性が追加されます。 コスト：Kafka、Redis Cluster、Cassandra、および大規模なWebSocketゲートウェイフリートの実行は高価です。小規模なプラットフォームでは、マネージドサービス（AWS SNS/SQSまたはFirebase Cloud Messagingなど）を使用して運用上の負担を軽減できます。説明されている規模（100万同時ユーザー）では、カスタムスタックの制御とパフォーマンスがコストを正当化します。

概要 水平スケーラブルで低遅延なリアルタイム通知プラットフォームを提案します。このプラットフォームは、(1) イベントとクライアント接続を受け入れるエッジ/ゲートウェイインフラストラクチャ、(2) 関心のある購読者にイベントをルーティングするための耐久性のあるパブ/サブバックボーン、(3) ライブクライアント接続を維持し、ファンアウトを実行する接続マネージャー/WebSocketワーカー、(4) 信頼性とオフライン配信のための高速プレゼンスストアと耐久性のある通知ストアを中心に構築されます。システムは、スループットと可用性の目標を達成するためにパーティショニングとレプリケーションを使用し、エンドツーエンドのインストルメンテーション、バックプレッシャー、べき等性により、少なくとも1回の配信と低遅延を保証します。 1) 全体アーキテクチャ（コンポーネントとリクエストフロー） コアコンポーネント - APIゲートウェイ/イングレ ス: イベント発行（内部サービスから）とクライアント接続のアップグレードを受け入れます。イベント発行者向けのREST/gRPCエンドポイントを公開し、認証とレート制限を処理します。グローバルLBとリージョンごとのエンドポイントの背後にデプロイされます。 - 接続レイヤー（WebSocket / GRPCストリーム）: クライアントとの永続的な接続を維持するステートレス接続サーバー（WebSocket/HTTP2またはgRPC）のフリート。軽量なルーティングと確認応答処理を実行し、プレゼンスストアにサブスクリプションの変更を転送します。 - プレゼンス＆ルーティングストア: オンラインユーザーと購読しているトピックを現在ホストしている接続サーバーを追跡する低遅延キーバリューストア（Redisクラスター）。通知を正しい接続ワーカーにルーティングするために使用されます。 - パブ/サブバックボーン: 発行者から通知ワーカーへのイベント配布に使用される耐久性のあるパーティション化されたメッセージバス（KafkaまたはApache Pulsar）。トピックは論理キー（ユーザーID、トピックID）でパーティション化され、キーごとの順序処理とスケーラブルなスループットを保証します。 - 通知サービス/ワーカープール: イベントのエンリッチメント、フィルタリング、配信ルーティングを実行するパブ/サブトピックのコンシューマー。ワーカーはプレゼンスストアを参照してターゲット接続サーバーを見つけ、高速配信パスに配信タスクをプッシュします。 - 配信レイヤー/ファンアウトエンジン: 接続サーバーは、配信リクエスト（直接または高速RPC経由）を受信し、永続的な接続を介してクライアントに通知をプッシュします。これらは、接続ごとのフロー制御、バッチ処理、およびクライアントからのACKを処理します。 - 耐久性のある通知ストア（NoSQL）: オフラインユーザー、リトライ、監査のための通知を永続化する書き込み最適化されたレプリケートされたストア（例：Cassandra / DynamoDB）。通知ペイロード、配信試行、タイムスタンプ、TTLを格納します。 - 重複排除＆べき等性ストア: 少なくとも1回のセマンティクスが重複を引き起こす場合に、最近のメッセージIDを記録して重複排除するための小さなキーバリューストア（RedisまたはRocksDB）。 - モニタリング＆コントロールプレーン: メトリクス、トレーシング、SLO/アラート、サーキットブレーカー、スロットリング。 通常のフロー - 発行フロー（イベントプロデューサー -> ユーザー）: 1) 発行者がAPIゲートウェイ（REST/gRPC）にイベントを投稿します。2) ゲートウェイはメッセージをパブ/サブトピック（ターゲットトピック/ユーザーIDでパーティション化）に書き込みます。3) 通知ワーカーはイベントを消費し、エンリッチメントと購読リストの解決（または購読DBのクエリ）を行い、プレゼンスストアを参照してオンライン受信者を見つけ、各オンライン接続に対して適切な接続サーバーにプッシュします。4) 接続サーバーはWebSocket/gRPCストリームを介してクライアントにプッシュし、軽量ACKを待ちます。5) ユーザーがオフラインの場合（プレゼンスミス）、オフライン取得のために耐久性のある通知ストアに書き込みます。 - 購読フロー: クライアントは永続的な接続を介して購読/購読解除メッセージを送信します。接続サーバーはプレゼンスストアをアトミックに更新するため、ワーカールーティングは迅速に更新された購読を確認できます。 - 回復とリプレイ: 耐久性のあるパブ/サブと通知ストアにより、失われたイベントのリプレイが可能になります。接続サーバーは再接続時にプレゼンスを再登録します。 2) 技術選択と根拠 - クライアント接続: WebSocketまたはHTTP/2（gRPC）ストリーム - 選択: モバイル/Webを含む幅広いクライアント互換性のためにWebSocket。それをサポートする内部/モバイルアプリの場合は、HTTP/2 gRPCストリームを検討します。どちらも永続的なTCP/TLS接続を維持し、<200msの遅延を満たします。 - 理由: ポーリングは遅すぎ、非効率的です。ロングポーリングは遅延とリソース使用量を増加させます。WebSocketはプッシュ、低RTT、および小さなオーバーヘッドでバイナリメッセージを配信する機能を提供します。 - パブ/サブバックボーン: Apache KafkaまたはApache Pulsar - 選択: Kafka（Confluent Cloudのようなマネージドサービスまたはセルフホスト）または、マルチテナンシーとジオレプリケーションのニーズが支配的な場合はPulsar。 - 理由: どちらもパーティション化され、耐久性があり、高スループットのメッセージングを提供します。Kafkaは成熟したツール、強力なスループット、予測可能な遅延、および発行者におけるExactly-onceセマンティクスサポートを備えています。パーティショニングにより、10k msg/sまで容易にスケールできます。Pulsarは、マルチリージョンが必要な場合に組み込みのジオレプリケーションを提供します。 - プレゼンスストア＆ルーティング: Redisクラスター（インメモリ）とレプリケーション - 理由: ユーザー -> 接続サーバー、購読、接続メタデータをマッピングするためのサブ1msの読み書き。Redisは、200msの予算内でイベントをルーティングするために必要なクラスター化、永続性（AOF/RDB）、および高速ルックアップをサポートします。 - 永続通知ストア: Cassandra / DynamoDB（NoSQL） - 選択: CassandraまたはDynamoDBのようなキーバリューストア。 - 理由: 高い書き込みスループット、線形スケーラビリティ、および設定可能なTTLは、毎秒多数の書き込みを格納し、オフライン読み取りを提供するのに理想的です。SQLシステムは、この規模の書き込みと水平シャーディングの複雑さでは苦労します。 - 接続サーバーとワーカー間の通信: gRPC/内部RPC + protobuf - 理由: 低オーバーヘッドのバイナリメッセージ、バックプレッシャーサポート、強力な型付け、および高パフォーマンス。 - ロードバランシング＆ルーティング: WebSocket用のL4（TCP）ロードバランサー+ REST API用のL7 LB。一貫性ハッシュまたはセッションアフィニティを使用したスティッキーなルーティングを使用して、再接続を同じリージョンにルーティングします。 - クライアントペイロード形式: より小さなペイロードと高速なシリアライゼーションのためのコンパクトなバイナリ（protobuf/flatbuffers）。 3) 設計が非機能要件をどのように満たすか - スケーラビリティ（100万同時ユーザー、ピーク時10k通知/秒） - ステートレス接続サーバー: 水平スケールアウト。各サーバーはN個の同時WebSocket接続を処理します。最新のマシン（例：適切なチューニングでマシンあたり10万ソケット）を使用すると、数十から数百のサーバーで100万同時ソケットを処理できます。オートスケーリンググループ+コンテナオーケストレーションが容量を管理します。 - パーティション化されたパブ/サブ（Kafka）: パーティション/ワーカーを追加することで、発行者とコンシューマーをスケールします。ターゲットユーザーIDまたはトピックでパーティション化することで、均一な負荷分散が保証されます。10k msg/sは、適切にサイジングされたKafkaクラスター（数十のブローカー）にとっては控えめな値です。 - シャード化されたプレゼンスストア: Redisクラスターはユーザー空間をシャード化するため、ルックアップはO(1)のままでスケールします。 - パーティション化された耐久性ストア: Cassandraはノードを追加することで書き込みと読み取りに対して線形にスケールします。 - 遅延（99%が200ms以内） - 永続接続はTCPハンドシェイクのオーバーヘッドを排除します。確立されると、イベント発行からクライアントへのプッシュは次のようになります：APIゲートウェイ -> Kafkaアペンド（チューニングに応じてサブミリ秒〜10ミリ秒）-> ワーカー消費 -> プレゼンスルックアップ（サブミリ秒）-> 接続サーバーへのRPC -> WebSocket経由でのプッシュ（サブミリ秒〜数ミリ秒）。適切な配置（ワーカーと接続サーバーを同じリージョン/AZにデプロイ）により、ネットワーク遅延は小さくなります。バッチ処理をほぼ瞬時の配信に近い値にチューニングし（バッチ遅延を回避）、Kafkaコンシューマー設定（low linger.ms）をチューニングして、エンドツーエンド遅延を低く保ちます。 - エッジ/リージョンデプロイメント: クライアントの近く（リージョンレベル）に接続サーバーを配置し、ラストマイルの遅延を最小限に抑えます。 - バイナリシリアライゼーションと小さなペイロードを使用して、シリアライゼーション/ネットワーク時間を短縮します。 - 信頼性（少なくとも1回の配信） - 耐久性のある書き込み: 発行者はイベントをKafka（耐久性）に書き込み、ワーカーはオフセットを追跡します。メッセージは、コンシューマー処理によって確認されるまで耐久性があります。 - 少なくとも1回: 配信に失敗した場合（接続サーバーのクラッシュ、ネットワーク障害）、パブ/サブはメッセージを保持し、ワーカーは処理の成功後にのみオフセットをコミットするため、ワーカーは再エンキューまたはリトライできます。クライアントは受信を確認しますが、ACKはクライアントの受け入れを確認するだけで、サーバー側の永続化によりリトライが可能になります。 - 重複排除: 少なくとも1回は重複を生成する可能性があるため、一意のメッセージIDを含め、クライアント側または最近のIDキャッシュを使用したサーバー側の重複排除により、重複を抑制します。 - 耐久性のある通知ストア: ユーザーがオフラインの場合、または永続的な確認が必要な場合、イベントを確認する前に通知をCassandraに書き込み、後で配信できるようにします。 - 可用性（99.95%アップタイム） - マルチAZおよびマルチリージョンデプロイメント: クリティカルなコンポーネントをレプリケートします。レプリケーションファクター>2のKafka、マスターレプリカとフェイルオーバーを備えたRedis、複数のレプリカとチューナブルな一貫性を備えたCassandraを使用します。 - ステートレスフロントエンドとオートスケーリング: いずれかの接続サーバーが失敗した場合、クライアントは次に利用可能なサーバーに再接続します。ヘルスチェックと高速フェイルオーバーを使用します。 - グレースフルデグラデーション: 配信過負荷が発生した場合、イベントをドロップするのではなく、後で配信するために保存して受け入れます。スロットリングとバックプレッシャーがシステムを保護します。 - 可観測性と自動化: 自動再起動、サーキットブレーカー、オペレーター介入のためのランブック。SLOとアラートは、99.95%の可用性を維持するように調整されます。 4) 運用上の詳細と最適化 - パーティショニングキーとルーティング: ユーザーターゲットメッセージの場合はユーザーIDで、トピックブロードキャストの場合はトピックIDでパブ/サブをパーティション化します。多数のユーザーへのファンアウト（例：数千人がいいねした投稿）の場合、階層的なファンアウトを実行します：1）受信者を決定します；2）受信者を接続サーバーごとにグループ化します；3）NRPC呼び出しを回避するために、グループ化された配信メッセージを各接続サーバーに送信します。 - ファンアウト戦略 - 書き込み時のファンアウト（プッシュ）: リアルタイムのオンライン配信に推奨。ワーカーはプレゼンスストアを介して見つかったオンライン接続にのみプッシュします。 - 読み取り時のファンアウト（プル）: 大量のオフラインファンアウトまたは頻繁にオンラインにならないユーザーに使用します。通知を保存し、クライアントがオンライン時に取得できるようにします。 - バッチ処理と集約: 大量の類似イベントの場合、安全な場合に複数のイベントを1つのコンパクトな通知に集約します（例：「あなたの投稿に3人がいいねしました」）。これにより、負荷が軽減され、ユーザーエクスペリエンスが向上します。 - バックプレッシャーとスムージング: 接続サーバーまたはクライアントがメッセージを受け入れられない場合、バックプレッシャーを適用します：コンシューマーを遅くし、耐久性のあるストアにバッファリングし、リトライします。クライアントごとのレート制限を実装します。 - クライアントACKモデル: 受信成功のための軽量ACKを使用します。タイムアウト内にACKが受信されない場合は、配信をリトライします。配信試行回数カウンターを維持し、N回の試行後にデッドレターストアに送信します。 - セキュリティとプライバシー: ゲートウェイでのエンドツーエンド認証、発行者の発行権限の検証。トランスポートの暗号化（TLS）、ペイロードのサニタイズ。 5) トレードオフと考察 - 複雑さとシンプルさ - トレードオフ: Kafkaベースのマルチコンポーネントシステムは、単純なプッシュサーバーよりも運用が複雑ですが、スケールと信頼性には必要です。運用コストとエンジニアリングの複雑さが増加します（Kafka、Redisクラスター、Cassandraの管理）が、耐久性、リプレイ、ファンアウト制御を提供します。 - 少なくとも1回 vs 厳密に1回 - 選択: 重複排除を備えた少なくとも1回の配信が選択されます。エンドツーエンドでの厳密に1回の配信は非常にコストがかかり（サービス間およびクライアント間の調整が必要）、重複が許容される通知にはしばしば不要です。重複排除キャッシュとクライアント側のべき等性により、実用的な軽減策が提供されます。 - WebSocket vs HTTP/2 gRPC - トレードオフ: WebSocketは互換性を最大化しますが、より多くのLBと接続チューニングが必要です。gRPCは、それをサポートするクライアントに対して、より優れたフロー制御と型安全性を提供します。両方をサポートすると複雑さが増しますが、最高のカバレッジが得られます。 - リアルタイムプッシュ vs 保存優先 - プッシュ優先は、遅延を満たすためにオンラインユーザーに優先されます。ただし、保存優先（最初にDBに永続化する）は、追加の書き込み遅延を犠牲にして耐久性を向上させます。バランスを取ります：Kafka（耐久性）に迅速に書き込み、信頼性ポリシーに応じてCassandraにオプションで永続化します。 - Redisプレゼンスの最終整合性 - エッジケースではプレゼンスがわずかに古い場合があります。偽陽性/偽陰性の小さなウィンドウは、耐久性のある通知ストアから回復される単一の通知の欠落を引き起こす可能性があります。この設計は、厳密に同期されたグローバルなプレゼンス値よりも、低遅延のプレゼンスルックアップを優先します。 6) 容量計画と数値（概算） - 100万同時ユーザー: 各接続サーバーが約1万の同時WebSocketを処理する場合、約100の接続サーバーが必要です。ピーク時の安全率（2倍）を追加 -> リージョン全体で約200インスタンス。 - 10k通知/秒: 10〜50パーティションのKafkaクラスターは、メッセージサイズとレプリケーションに応じて十分です。ブローカー数は約5〜10（レプリケーションファクター3）を目標とします。コンシューマーグループは水平にスケールします。 - ストレージ: 10k notif/秒で、約8億6400万通知/日（すべてのメッセージが永続化された場合）— TTLと集約を使用してストレージを削減します。Cassandraノードはそれに応じてサイジングされます。 7) 障害モードと緩和策 - 接続サーバーのクラッシュ: クライアントは他のサーバーに再接続します。プレゼンスストアは再接続時に更新されます。ワーカーにバッファリングされたメッセージはリトライされます。スティッキーな再接続戦略を使用して、状態の乱れを減らします。 - Kafkaブローカー障害: パーティションレプリケーションにより、レプリケーションファクター>=3でISRが設定されている場合にデータ損失はありません。アンダーレプリケートされたパーティションを監視します。 - Redisフェイルオーバー: レプリカと自動フェイルオーバー（Sentinelまたはマネージドサービス）を備えたRedisクラスターを使用します。大規模なフェイルオーバー時に接続サーバーからプレゼンスを再構築します。 - 大規模ファンアウト（バイラルイベント）: 階層的なファンアウトとバッチ処理を使用します。バックグラウンドワーカーにオフロードし、リアルタイム配信が遅延違反を引き起こす場合は、後で配信するために通知を永続化します。 結論 この設計は、永続接続（WebSocket/gRPC）、耐久性のあるパーティション化されたパブ/サブ（Kafka/Pulsar）、低遅延のプレゼンスストア（Redis）、およびスケーラブルなNoSQLストア（Cassandra/DynamoDB）を使用して、100万同時接続、10k通知/秒、99%が200ms以内、少なくとも1回の信頼性、および99.95%の可用性の目標を満たします。主なトレードオフは、運用上の複雑さの増加と重複の処理です。慎重なパーティショニング、レプリケーション、監視、および各コンポーネントのチューニング（コンシューマー設定、バッチ処理、バックプレッシャー）により、このアーキテクチャはスケーラビリティを発揮し、プラットフォームが必要とする低遅延で信頼性の高いリアルタイム通知を提供します。