大規模なURL短縮サービスの設計

### A. ハイレベルアーキテクチャ システムは、高可用性と低レイテンシを確保するために、複数の地理的リージョンにデプロイされた分散型ステートレスマイクロサービスのセットとして設計されています。主なコンポーネントは以下の通りです。 1. **グローバルロードバランサー (GLB)**: DNSベースのルーティング（例：AWS Route 53、Google Cloud Load Balancing）を使用して、最も近く、正常なリージョンにユーザートラフィックを分散します。 2. **リージョナルロードバランサー (RLB)**: 単一リージョン内のトラフィックを、Webサーバーのフリートに分散します。 3. **APIゲートウェイ / Webサーバー**: TLSを終端し、書き込み（短縮）と読み取り（リダイレクト）の両方のHTTPリクエストを処理するステートレスサーバーのレイヤーです。 4. **リダイレクトサービス（読み取りパス）**: 短縮コードを検索し、HTTP 301/302リダイレクトを発行する、高度に最適化されたサービスです。主にキャッシュレイヤーと連携します。 5. **URL短縮サービス（書き込みパス）**: 新しい短縮URLの作成を処理するサービスです。キー生成サービスとプライマリデータベースと連携します。 6. **分散キャッシュ**: 各リージョンにあるインメモリキャッシュ（例：Redis Cluster）で、ホットなURLマッピングを格納し、リダイレクトの厳密な低レイテンシ要件を満たします。 7. **プライマリデータベース**: すべてのURLマッピングの永続的な信頼できる情報源として機能する分散型NoSQLデータベース（例：Apache Cassandra、Amazon DynamoDB）で、すべてのリージョンにレプリケートされます。 8. **キー生成サービス (KGS)**: 書き込み時の競合とレイテンシを排除するために、一意の7文字の短縮コードのバッチを事前に生成する、専用の高可用性サービスです。 9. **アナリティクスパイプライン**: リダイレクトサービスのパフォーマンスに影響を与えることなくクリックストリームデータを収集するためのメッセージキュー（例：Apache Kafka）から始まる非同期データパイプラインです。このデータはその後、別の分析データベースで処理および格納されます。 ### B. URL生成戦略 **アプローチ**: 専用のキー生成サービス（KGS）を使用して、一意のキーを事前に生成します。 **メカニズム**: 1. KGSは、分散型で耐障害性のある方法（例：ZooKeeperまたはRedisのようなデータベースのアトミックカウンターを使用）でカウンターを維持します。 2. 大きな順次数値IDを生成します。高可用性を確保するために、複数のKGSインスタンスを実行でき、それぞれが異なるID範囲を担当します（例：サーバー1は1から1,000,000、サーバー2は1,000,001から2,000,000を処理）。 3. 各数値IDは、base-62文字列（[a-z、A-Z、0-9]）に変換され、7文字の短縮コードが生成されます。62^7のスペースは、約3.5兆の一意のコードを提供し、これは十分に十分です。 4. KGSはこれらのコードをバッチで生成し、URL短縮サービスが消費できるようにキュー（例：Redisリスト）に入れます。 **正当化**: このアプローチにより、書き込み操作中にメインデータベースで競合を確認する必要がなくなり、これは遅く、競合のポイントとなります。短縮サービスはKGSから確実に一意のキーを取得するだけでよいため、書き込みパスは非常に高速で予測可能になります。 ### C. データモデルとストレージ **プライマリストレージ（URLマッピング）**: * **テクノロジー**: Apache CassandraまたはAmazon DynamoDB。 * **理由**: これらのNoSQLデータベースは、優れた水平スケーラビリティ、ネイティブなマルチリージョンレプリケーション、高可用性、および低レイテンシのキーバリュールックアップを提供し、スケールと耐障害性の両方の要件に完全に適合します。 * **スキーマ**: * テーブル名: `url_mappings` * パーティションキー: `short_code` (文字列) * カラム: * `long_url` (文字列) * `user_id` (文字列、所有権用) * `created_at` (タイムスタンプ) **キャッシュストレージ**: * **テクノロジー**: Redis Cluster。 * **理由**: Redisは、非常に低いレイテンシ（ミリ秒未満）のインメモリデータアクセスを提供し、これは<10msのリダイレクト要件を満たすために不可欠です。スケーラビリティと高可用性のためにクラスタ化できます。 **アナリティクスストレージ**: * **テクノロジー**: Apache Druid、ClickHouseのようなカラム指向データベース、またはGoogle BigQueryのようなクラウドデータウェアハウス。 * **理由**: これらのシステムは、大量のデータに対する高速な集計と分析クエリに最適化されており、分析ダッシュボードの実行に理想的です。 ### D. 読み取りパスの最適化 読み取りパスは、ピーク時40,000 QPSに対応するために、多層キャッシュ戦略を使用してレイテンシのために高度に最適化されています。 1. **CDN/エッジキャッシュ**: 非常に人気のあるURLの場合、CDNはエッジロケーションで301/302リダイレクト応答をキャッシュでき、コアインフラストラクチャにヒットすることなく、最も近いプレゼンスポイントからユーザーにサービスを提供します。 2. **分散インメモリキャッシュ（Redis）**: 低レイテンシの主要な処理装置です。リダイレクトサービスは最初にリージョナルRedisクラスタにクエリします。キャッシュヒットは即座のリダイレクトにつながります。 * **キャッシュサイズの見積もり**: 5年間のURLの20％（100M/月 * 12 * 5 * 0.2 = 1.2B URL）をキャッシュするため。エントリあたり約600バイト（短縮コード、長URL、オーバーヘッド）で、リージョンあたり約720 GBのRAMが必要であり、これはRedisクラスタでは実現可能です。 3. **データベースルックアップ**: キャッシュミスの場合、サービスはプライマリCassandra/DynamoDBデータベースにクエリします。結果は、キャッシュが頻繁にアクセスされるアイテムで満たされていることを保証するために、Time-To-Live（TTL）とともにRedisキャッシュに書き戻されます。 このアーキテクチャにより、ほとんどのリクエストがメモリから提供され、<10msのp99レイテンシ目標を容易に達成できます。 ### E. 書き込みパス 書き込みパスは、信頼性とスループット（約400ピーク書き込み/秒）のために設計されています。 1. ユーザーは、長URLを含むPOSTリクエストをAPIゲートウェイに送信します。 2. リクエストは、URL短縮サービスのインスタンスにルーティングされます。 3. サービスは長URLを検証します。 4. キー生成サービス（KGS）に一意の短縮コードを要求します。 5. サービスは、新しいマッピング（`short_code`、`long_url`）をプライマリデータベース（Cassandra/DynamoDB）に、ローカルリージョンに対して高い一貫性レベルで書き込みます。 6. データベースは、この書き込みを他のリージョンに非同期でレプリケートします。 7. データベース書き込みが成功すると、サービスは新しい短縮URLをユーザーに返します。 ### F. スケーリング戦略 システムは、すべてのレイヤーで水平スケーリングできるように設計されています。 * **ステートレスサービス**: APIゲートウェイ、リダイレクトサービス、短縮サービスはステートレスです。ロードバランサーの後ろに仮想マシンやコンテナを追加することでスケールできます。 * **データベース**: CassandraとDynamoDBは、クラスタにノードを追加することで水平スケーリングできるように設計されています。データと負荷は自動的に再分散されます。 * **キャッシュ**: Redis Clusterは、ノードを追加し、キー空間を再シャーディングすることでスケールできます。 * **アナリティクスパイプライン**: Kafkaは、ブローカーとパーティションを追加することでスケールします。データを処理するコンシューマーサービスも水平スケーリングできます。 ### G. 信頼性と耐障害性 高可用性は、複数の地理的リージョン（例：US-East、US-West、EU-West）にわたる冗長性によって達成されます。 * **マルチリージョンデプロイメント**: スタック全体が少なくとも2つの独立したリージョンにデプロイされます。 * **グローバルフェイルオーバー**: グローバルロードバランサーは、各リージョンのヘルスを継続的に監視します。リージョン全体が利用できなくなった場合、GLBは自動的にすべてのトラフィックを正常なリージョンにリダイレクトします。 * **データレプリケーション**: プライマリデータベース（Cassandra/DynamoDB）は、マルチリージョンレプリケーション用に構成されています。これにより、リージョナルデータベースが失われた場合でも、データは他のリージョンに保持されます。書き込みは、残りのアクティブなリージョンで継続して提供できます。 * **単一障害点なし**: ロードバランサーからKGS、データベースに至るまで、すべてのコンポーネントはクラスタ化された耐障害性のある構成でデプロイされています。 ### H. アナリティクスパイプライン アナリティクスパイプラインは、パフォーマンスの低下を防ぐために、クリティカルなリダイレクトパスから完全に分離されるように設計されています。 1. **データ取り込み**: リダイレクトの提供に成功した後、リダイレクトサービスはKafkaトピックにメッセージを発行します。このメッセージには、`short_code`、`timestamp`、`IPアドレス`、`User-Agent`、`Referrer`などのイベントデータが含まれます。これは非同期のノンブロッキング操作です。 2. **データ処理**: ストリーム処理ワーカーの別のフリート（例：Spark Streaming、Flink、またはカスタムコンシューマーを使用）が、Kafkaトピックからバッチでメッセージを読み取ります。 3. **データエンリッチメントと集計**: これらのワーカーは、データをエンリッチし（例：IPをジオロケーションに変換）、リアルタイム集計（例：時間ごと、国ごとのクリック数をインクリメント）を実行します。 4. **データストレージ**: 処理および集計されたデータは、ユーザーインターフェースのダッシュボードクエリを効率的に実行するために最適化された分析データベース（ClickHouse/Druid）にロードされます。 この非同期アーキテクチャにより、トラフィックの大量のスパイクやアナリティクスパイプラインの障害が発生しても、URLリダイレクトの速度と可用性には全く影響がないことが保証されます。 ### I. 主要なトレードオフ 1. **結果整合性 vs. 強整合性**: リージョン間での結果整合性のあるデータレプリケーションモデルを選択しました。あるリージョンで作成されたURLが、別のリージョンで利用可能になるまで数ミリ秒かかる場合があります。このトレードオフは、このアプリケーションにとってより重要な書き込みレイテンシとシステムの可用性を大幅に向上させます。即時のグローバル整合性よりも重要です。 2. **コスト vs. パフォーマンス**: 厳密な<10msのp99レイテンシ要件を満たすために、大規模で高価なインメモリRedisキャッシュを使用しています。より安価なディスクベースのソリューションでは、このコアパフォーマンスSLAを満たすことはできません。クリティカルな読み取りパスでの保証された低レイテンシのために、より高い運用コストを犠牲にしています。 3. **複雑性 vs. スケーラビリティ（KGS）**: オンザフライでハッシュやランダム文字列を生成する代わりに、独立したキー生成サービス（KGS）を導入しました。これにより、構築および保守するコンポーネントが増え、システムの複雑性が増します。しかし、書き込みパスでのデータベースホットスポットと競合チェックロジックを完全に排除できるため、大規模な高スループットと低レイテンシの書き込みを保証するための重要なトレードオフとなります。

概要 グローバルに分散されたキャッシュファーストのURL短縮サービスを提案します。軽量なエッジリダイレクトパス（CDN + エッジ関数 + ローカルキャッシュ）により、99パーセンタイルで10ミリ秒未満のリダイレクトレイテンシ要件を満たします。永続的なマルチリージョンプライマリストアには正規のマッピングを格納し、分散ID割り当てサービスにより一意の短縮コード（base62エンコード、7文字以下）を生成します。非同期分析パイプライン（Kafka/Kinesis → ストリームプロセッサ → OLAPストア）は、リダイレクトパスから厳密に分離されます。また、データセンター全体の障害時にも利用可能にするためのマルチリージョンレプリケーションとフェイルオーバーを備えています。 A. 高レベルアーキテクチャ（コンポーネントと相互作用） - エッジレイヤー（CDN）：すべてのGET /{code} リダイレクトリクエストは、Cloud CDN（例：Amazon CloudFront、Fastly）によってフロントされます。ほとんどのリクエストは、キャッシュされた301/302レスポンスとともにCDNエッジキャッシュから提供されます。 - エッジ関数（CloudFront Function / Fastly Compute / Lambda@Edge）：キャッシュミスの場合、小さなエッジ関数がリージョナルリダイレクトAPI（短いRPC/HTTP経由）を呼び出して正規の宛先URLを取得し、301/302を返します。エッジ関数は、適切なキャッシュTTLの選択と、削除済み/存在しないコードの処理のための最小限のロジックを追加します。 - リージョナルリダイレクトAPI / 読み取りキャッシュ層：各リージョンにあるステートレスな読み取りサーバーが、まずリージョナルインメモリキャッシュ（Redisクラスタ / ElastiCacheまたはMemcached）を参照し、必要に応じて永続的なキーバリューストアにフォールバックします。 - 永続キーバリューストア（プライマリDB）：短縮コード -> 長いURLとメタデータを正規の真実の情報源として格納するDynamoDB Global TablesまたはCassandra（マルチリージョン）。 - ID割り当てサービス（レンジアロケータ）：書き込みAPIサーバーにIDブロックを配布し、ローカルでの短縮コード生成を可能にする小さなサービス（書き込みごとの中央ロックなしで一意性を保証）。 - 書き込みAPI：作成リクエストを処理し、短縮コードを予約/生成（IDブロック経由）、プライマリDBに永続化し、キャッシュとCDNへの無効化を伝播します。書き込みは永続性のためにプライマリDBに対して同期的に行われます。 - キャッシュ無効化と伝播：作成/更新/削除時に、書き込みAPIはリージョナルキャッシュを更新し、CDN無効化APIを介して、またはキャッシュ制御ヘッダーを書き込み、必要に応じてURLにバージョン・トークンを使用してCDNエッジエントリを無効化します。 - 分析パイプライン（非同期）：リダイレクトイベントは非同期に記録されます（同期リダイレクトパスには含まれません）。エッジロガーまたはリージョナル読み取りサーバーは、軽量なクリックイベントをメッセージバス（Kafka / Kinesis）にプッシュします。ストリーム処理（Flink / Spark Streaming）は、集計して分析ストア（ClickHouse / BigQuery）に書き込み、ダッシュボード用に読み取り最適化ストアに事前集計されたカウンターを格納します。 - ダッシュボードAPIとUI：OLAP/集計ストアから集計された分析を読み取り、ユーザーダッシュボードを提供します。ダッシュボードクエリはリダイレクトパスにヒットしません。 B. URL生成戦略 目標：一意性、コンパクトさ（7文字以下の英数字）、高スループット、低競合。 採用アプローチ：分散IDブロックで割り当てられた連番数値IDをbase62エンコードして短縮コードを生成します。 - なぜbase62連番IDか：base62（a–z、A–Z、0–9）は、最大7文字の文字列で62^7 ≈ 3.52 × 10^12 の可能なコードを提供し、予想される寿命のニーズをはるかに上回ります。連番IDはコンパクトにエンコードされ、必要に応じて数値に逆変換しやすいです。決定論的なマッピングによりハッシュ衝突を回避できます。 - ID割り当ての実装：中央アロケータが、各書き込みサーバークラスタに単調増加するID範囲（例：100万件のブロック）を配布します。各書き込みサーバーは、リモート調整なしでローカルIDをブロックから発行し、一意性と非常に低いレイテンシを保証します。アロケータ自体は小さく、高可用性ストア（RDSまたは軽量なZooKeeper/etcdベースのカウンター）でバックアップでき、ブロック補充（低QPS）にのみ使用されます。 - エンコーディング：数値ID -> base62文字列。数値ID < 62^7 の場合、エンコード長は7文字以下になります。月間1億件の新規短縮（年間12億件）の場合、62^7 の容量は2,900年以上のスペースを提供します。 - 衝突の処理：数値IDが一意であるため、衝突は予期されません。それでも、書き込みAPIはプライマリDBに対する条件付き挿入（短縮コードを主キーとするPUT）を使用し、まれなプライマリDB競合（アロケータが正しい場合は発生しないはず）に対してリトライします。ユーザーが要求したカスタムエイリアスの場合は、既に存在するかどうかを確認し、存在する場合はエラーを返します。 - オプションの重複排除：同じURLが以前に同じユーザーによって短縮された場合に既存の短縮コードを返すために、セカンダリハッシュインデックス（例：long_urlのSHA-256）をオプションで維持します。これはアプリケーションレベルの動作であり、オプションです。 C. データモデルとストレージ プライマリデータストアの選択肢：DynamoDB Global Tables（マネージド、マルチリージョン、シングルディジットミリ秒の読み書き）、またはApache Cassandra / ScyllaDB（セルフマネージドマルチリージョン）を正規の選択肢とします。運用が容易で、マルチリージョンレプリケーションが高速なため、DynamoDB Global Tablesを推奨します。ただし、クラウドに依存しない必要がある場合はCassandraを選択します。 プライマリマッピングテーブルスキーマ（キーバリュー最適化）： - テーブル名：URL_Mapping - 主キー：short_code（文字列、PK） - 属性：long_url（テキスト）、user_id（文字列）、created_at（タイムスタンプ）、custom_alias_flag（ブール値）、deleted_flag（ブール値）、metadata（JSON/Sparse map）、analytics_enabled（ブール値）、version（整数）。 - セカンダリインデックス（オプション）：user_id -> short_codesのリスト（GSI）（管理UI用）；long_hash -> short_code（必要に応じた重複排除用）。 ストレージ推定：各レコードは平均200バイトを格納すると仮定します（short_code 約7バイト、URL平均200バイト？圧縮可能ですが、保守的に200〜400バイトと仮定）。月間1億件の新規行：1億 * 200バイト = 月間20GB。年間約240GB。10年間で約2.4TB。DynamoDB/Cassandraは容易にこのスケールに対応できます。 分析ストア：生のクリックイベントは追記専用システム（Kafka/Kinesis）に入り、その後、集計とダッシュボード用の長期分析ストア（ClickHouseまたはBigQuery）に入ります。事前集計されたカウンター（short_codeごと、時間バケットごと）はClickHouseに格納し、ホットカウンターはダッシュボードクエリ用にRedisにキャッシュできます。 D. 読み取りパスの最適化（99ミリ秒未満のリダイレクト達成） 目標は、リクエスト到着から301/302発行まで、99パーセンタイルリダイレクトを10ミリ秒未満で提供することです。 使用技術： 1) CDN + エッジキャッシュ（主要な最適化）：ほぼすべてのリクエストで、完全な301レスポンスをCDNエッジにキャッシュします。マッピングは期限切れにならないため、非常に長いTTL（実質的に期限なし）を設定しますが、マッピングが更新/削除された場合の即時無効化をサポートします。 - CDNエッジヒットの場合、クライアントへのレイテンシは通常、グローバルで10ミリ秒未満です。 2) キャッシュミス検索のための非常に小さなエッジ関数：CloudFront FunctionまたはFastlyのエッジコンピューティングを使用して、ランタイムオーバーヘッドを最小限に抑えます（約サブミリ秒）。キャッシュミスの場合、エッジ関数はリージョナルリダイレクトAPIに短いTCP接続（キープアライブ）経由で呼び出し、CDNに301を返します。 3) リージョナル読み取りキャッシュ（各リージョンのRedis）：リージョナルキャッシュは、マッピング検索のためのメモリファーストストアです。通常のRedis GETは1ミリ秒未満です。キャッシュヒット率目標：ホットコードで99%以上。LFU/LRUエビクションとサイズを使用してワーキングセットを保持します。 - キャッシュサイジング例：ピークグローバルRPS = 40,000リクエスト/秒と仮定。上位5000万コード（ホットテール）のワーキングセット — 短縮コード->長URLペア（平均200バイト）を格納。メモリ = 5000万 * 200バイト ≈ 10GB。小規模なマルチシャードRedisクラスタ（例：32GBノード4〜8台）を各リージョンに配置すれば対応可能です。 4) キャッシュミス時のオリジンDBアクセスのみ：DynamoDBの単一行GetItemは通常低ミリ秒（1〜10ミリ秒）ですが、キャッシュを多用することでp99のクリティカルパスにならないように設計します。 5) エッジ関数 + HTTPパスを最小限に保つ：CDNとオリジン間のHTTP/2またはHTTP/3を使用して、ハンドシェイクレイテンシを削減し、接続再利用を可能にします。 6) ローカルAnycast + geo認識ルーティング：クライアントを最も近いエッジ/リージョンに送信し、RTTを低く保ちます。 測定とSLA：合成トラフィックでテストし、99パーセンタイルレイテンシ予算を割り当てます：CDNヒット（目標<5ミリ秒）、エッジ関数+Redis <10ミリ秒、オリジンフォールバックは低パーセンタイルでは許容されますが、監視および調整されます。 E. 書き込みパス：作成と永続化 1) クライアントは、書き込みAPI（リージョン認識エンドポイント）にPOST /create（またはUI経由）を送信します。書き込みAPIレイヤーはステートレスで自動スケーリングされます。 2) 書き込みAPIは、ローカルで割り当てられたブロック（レンジアロケータ）から数値IDを取得します。ブロックが枯渇した場合、アロケータから新しいブロックを要求します。 3) 数値IDをbase62短縮コードにエンコードします。 4) 条件付き挿入でプライマリDBに永続化します：PutItem(short_code, long_url, metadata) を、short_codeが存在しないという条件式付きで実行します（カスタムエイリアスの誤った上書きを防ぐため）。永続性のためにアトミック書き込みを保証します。 5) 書き込み成功後： - リージョナル読み取りキャッシュを更新（ライトスルー）し、後続のリダイレクトがキャッシュにヒットするようにします。 - CDNキャッシュのプリウォームリクエストを送信するか、このshort_codeの無効化をCDNに発行して、新しいマッピングがエッジに即座にキャッシュされるようにします（または、CDNのキャッシュ制御+バージョニングを活用して効果的にします）。 6) 作成されたshort_codeをユーザーに返します。 永続性と一貫性：プライマリDBへの同期書き込みと、リージョン間レプリケーション（DynamoDBグローバルテーブルまたはマルチDCレプリケーションを備えたCassandra）。DynamoDBを使用する場合、読み取りの一貫性モデルは結果整合性で構いませんが、書き込みは永続的でレプリケートされます。 運用上の数値：書き込みQPS平均約40書き込み/秒（月間1億件 ≈ 38.6/秒）。ピーク時のバーストも可能。書き込みパイプラインは水平スケーリングが容易です。 F. スケーリング戦略（水平スケーリング） - ステートレスAPI / リダイレクトサーバー：グローバルロードバランサー（ALB / GCLB）の後ろで水平に自動スケーリングします。サーバーをステートレスに保つことで、スケーリングが容易になります。 - IDアロケータ：QPSが低いため、耐障害性（アクティブ/パッシブ+永続カウンターまたは委譲されたレンジ割り当て）を持たせることでスケールします。アロケータの負荷を減らすために大きなブロックを割り当てます。 - キャッシュ：各リージョンにRedis/ElastiCacheクラスタ、シャード化（一貫性ハッシュ）。メモリとスループットを増やすためにシャードを追加します。 - プライマリDB：DynamoDBの自動スケーリングまたはノードを追加してスループットを増やすことができるCassandraクラスタ。読み書き容量を満たすためにインスタンスサイズとレプリケーションファクターを選択します。 - メッセージバス（Kafka/Kinesis）：取り込みをスケーリングするために、short_codeハッシュでクリックストリームをパーティション化します。ピークスループット（例：ピークリダイレクト38k RPSが毎秒38kイベントを生成する場合、毎秒50〜100kイベントに対応できるKafkaパーティションとブローカーをプロビジョニングし、レプリケーションファクター3を設定）を満たすのに十分なパーティションを使用します。 - 分析コンピューティング：イベント量に基づいてFlink / Sparkクラスタを水平にスケールします。 - CDNは自動的にスケールします。CDN設定はリクエストレートに合わせて調整する必要があります。 G. 信頼性と耐障害性 目標：データセンター全体のオフライン状態を乗り越え、データ損失を保証しない。 - マルチリージョンデプロイメント：少なくとも2つのアクティブリージョン（アクティブアクティブ）をグローバルルーティングでデプロイします。グローバルロードバランシング+ヘルスチェックを使用して、障害のあるリージョンを迂回します。 - プライマリDBレプリケーション：DynamoDB Global Tablesはリージョン間のアクティブアクティブレプリケーションを提供します。Cassandra/Scyllaはデータセンターをまたいだレプリケーションファクターで設定できます。これにより、1つのDCが失われても永続性が保証されます。 - リージョナルキャッシュはウォーム状態：リージョンが障害を起こした場合、トラフィックは次のリージョンにルーティングされ、そのリージョンには独自のキャッシュがあります。フェイルオーバー後のリージョンのコールドフロントは、キャッシュがウォームアップするまでオリジンからの読み取りが増加する可能性がありますが、可用性は維持されます。 - IDアロケータの耐障害性：アロケータの状態は高可用性ストアに永続化されます。フェイルオーバー時のアロケータへのアクセスを減らすために大きなブロックを割り当てます。 - メッセージバスレプリケーション：永続性のために、ラック/リージョンをまたいだレプリケーションファクター>=3のKafka、またはクロスリージョンレプリケーションを備えたマネージドKinesis。 - ヘルスチェックと自動フェイルオーバー：アクティブな監視、サーキットブレーカー、レート制限により、フェイルオーバー中の過負荷を防ぎます。 - バックアップ：プライマリDBの定期的なスナップショットとメタデータのエクスポート。DynamoDBの場合はポイントインタイムリカバリを有効にし、Cassandraの場合は定期的なスナップショットを取得します。 H. 分析パイプライン（リダイレクトに影響を与えずに収集/処理/提供） 設計原則：分析の書き込みは非同期であり、リダイレクトをブロックしてはなりません。 1) 軽量イベント生成：エッジ（CDN/エッジ関数）は、各リダイレクトに対して小さなイベント（short_code、タイムスタンプ、クライアントIPまたはジオタグ、リファラー、ユーザーエージェント）を発行します。リダイレクトレイテンシを最小限に抑えるため、発行はローカルプロキシへの非常に高速なUDPライクなプッシュ、または読み取りサーバーでのメモリ内バッチ処理を通じて非同期に行われます。 2) メッセージバス：イベントは、スケーラブルな並列処理をサポートするために、short_code（またはハッシュ）でパーティション化されたKafkaまたはKinesisトピックにプッシュされます。プロデューサーは非同期でノンブロッキングである必要があります。ローカルKafkaバッファがいっぱいの場合、サンプリングにフォールバックするか、低価値フィールドをドロップして、リダイレクトレイテンシに影響を与えないようにします。プロデューサーはローカルバッファリングとバックプレッシャーポリシーを使用します。 3) ストリーム処理：Flink / Kafka Streams / Spark Streamingはイベントを消費し、エンリッチ（ジオIPルックアップ、UA解析）し、リアルタイム集計（クリック数、ジオ分布、リファラー）を分単位/時間単位で計算します。short_codeごと、時間ウィンドウごとに事前集計します。 4) OLAPストアと集計：集計データをClickHouseまたはBigQueryに書き込み、高速な分析クエリと長期保存を行います。ダッシュボード提供のため、最近の集計は高速読み取りストア（RedisまたはDruid）に格納し、インタラクティブなクエリに使用します。 5) ダッシュボードAPI：集計/OLAPストアからのみ読み取ります。分析ストアからリダイレクトパスへの直接クエリはありません。ダッシュボードクエリにはレート制限とユーザーごとのクォータを実装します。 6) サンプリングと階層型ロギング：非常に高トラフィックのshort_codeの場合、パイプライン負荷を削減するためにオプションでイベントをサンプリングし、代表的な分析を維持します。 パフォーマンス例：ピークリダイレクト約40,000/秒 -> イベント40,000/秒 -> Kafka取り込みは100パーティションと数台のブローカーで容易に管理可能。ストリームプロセッサは水平にスケールしてこのボリュームを処理し、毎分要約された集計をClickHouseに書き込みます。 I. 主要なトレードオフ（少なくとも3つ）とその正当化 1) CDNエッジキャッシュ vs 削除/更新の即時整合性 - トレードオフ：長寿命のCDNエッジキャッシュを使用すると、リダイレクトレイテンシは非常に低くなりますが、更新/削除の伝播がやや複雑になり、すべてで即時ではなくなります。 - 正当化：リダイレクトレイテンシSLAは厳格（99パーセンタイルで10ミリ秒未満）です。短縮URLを変更/削除する一般的な操作は、リダイレクトと比較してまれです。リダイレクトの超低レイテンシを優先し、キャッシュ無効化の遅延（重要なケースには即時無効化APIを提供）を受け入れます。重要な更新のために、バージョン・トークンまたは短いTTL無効化戦略も含まれます。 2) 連番ID割り当て（レンジブロック+base62） vs 完全ランダム/ハッシュ方式 - トレードオフ：ブロックによる連番割り当ては、小さなアロケータサービスとクロスリージョンフェイルオーバー時の慎重な処理が必要ですが、ハッシュ/ランダム生成は完全にステートレスにでき、衝突解決または衝突を減らすためのより大きなコード長が必要です。 - 正当化：連番IDは、コンパクトで非常に短いコードを決定論的に生成し、書き込み時の衝突処理を回避します。ブロック割り当てにより、アロケータの負荷は最小限でスケーラブルです。非常に大きなキー空間（62^7）があるため、衝突を回避するためにランダム性は必要ありません。 3) DynamoDB（マネージド、マルチリージョン） vs セルフホストCassandra - トレードオフ：DynamoDBは運用上の負担を軽減し、マネージドなマルチリージョンレプリケーションを提供しますが、コストが高くなる可能性があり、クエリパターンではセルフホストCassandra/Scyllaよりも柔軟性がやや劣ります。 - 正当化：システムのアクセスパターンは単純な主キーの読み書きです。運用上のシンプルさ、信頼性、自動スケーリングを重視するため、コスト制約でCassandraが必須でない限り、DynamoDB Global Tablesを推奨します。 4) 同期ライトスルーキャッシュ vs キャッシュへの最終的な伝播 - トレードオフ：キャッシュへの同期ライトスルーは書き込みレイテンシをわずかに増加させますが、読み取りキャッシュでの即時利用可能性を保証します。最終的な伝播は書き込みレイテンシを低下させますが、キャッシュミスが発生する短いウィンドウが発生する可能性があります。 - 正当化：書き込みはQPSが低い（約40/秒）ため、作成時のキャッシュ書き込みは、新しく作成されたリンクがリダイレクトで即座に利用可能であることを保証し、新しく作成された短縮コードのコールドキャッシュミスを回避するために許容されます。 運用上の考慮事項とテレメトリ - 監視：99パーセンタイルリダイレクトレイテンシ、キャッシュヒット率、オリジンRPS、書き込みレイテンシ、メッセージバスラグ、分析パイプラインラグ。クロスDCレプリケーションラグのアラート。 - 容量計画：ピーク時の10倍の安全率を計画します。例： - 読み取りQPS（平均）：3,858 RPS = 月間100億件。ピーク想定10倍 => 約38,600 RPS。 - CDNエッジヒット目標：99% → オリジンRPS ≈ 386 RPS。ホットワーキングセットを保持するためにキャッシュサイズを調整。 - キャッシュサイジング：上位5000万キーを各200バイトで保持 → 10GB。リージョンごとに複数のシャードを使用。 - Kafkaスループット：ピーク時40,000イベント/秒、平均イベントサイズ500バイト => 約20MB/秒の取り込み。レプリケーションファクター3とオーバーヘッドを考慮して、約60MB/秒のクラスタスループットを計画。 - プライマリDBスループット：書き込み約40/秒、キャッシュミス後のオリジンからの読み取り約386/秒（集計値、またはリージョン分割）。DynamoDBの容量自動スケーリングはこれらのレベルを容易にサポートします。 セキュリティと運用機能 - スパムやボットを軽減するためのエッジでのレート制限と不正利用検出。 - オーバーロード時の分析書き込みのスロットリング、非常にホットなコードのサンプリング。 - 短縮URLの作成と管理のためのアクセス制御（OAuth/APIトークン）。 - 明示的に削除されない限り、非期限切れ保証を満たすための削除監査ログ。 結論 この設計は、CDNエッジキャッシュ+最小限のエッジロジック、永続的なマッピングのための耐久性のあるマルチリージョンストレージ、衝突がなく7文字以下のコードを保証するシンプルで堅牢なID割り当てとbase62エンコーディングスキーム、そして分析がリダイレクトパフォーマンスを低下させない完全に非同期な分析パイプラインを通じて、リダイレクトレイテンシと可用性を優先します。アーキテクチャは水平にスケーリングし、マルチリージョンレプリケーションによるデータセンター全体の障害を乗り越え、運用上のレバー（キャッシュサイジング、CDN無効化、サンプリング）を提供してコストとパフォーマンスのバランスを取ります。