グローバルなURL短縮サービスの設計

### 1. ハイレベルアーキテクチャ システムは、低レイテンシーと高可用性を確保するために、グローバルに分散されたマルチリージョンサービスとして設計されています。主要な各リージョン（例：US-East、EU-West、AP-Southeast）に完全なPoint of Presence（PoP）がホストされます。 **コンポーネント:** 1. **グローバルロードバランサー（GLB）:** レイテンシーベースのDNSルーティングを使用して、ユーザーを最も近い正常なリージョンPoPに誘導します。 2. **リージョナルPoPスタック:** * **APIゲートウェイ:** TLSを終端し、リクエストを認証し、適切なバックエンドサービスにルーティングします。 * **リダイレクトサービス:** `GET /{short_alias}`リクエストを処理する、軽量で高度にスケーリングされたサービスです。速度に最適化されています。 * **書き込みサービス:** カスタムエイリアスの検証と一意のID生成を含む、リンク作成（`POST /api/v1/links`）を処理します。 * **アナリティクスサービス:** `GET /api/v1/links/{short_alias}/stats`経由でリンク統計へのアクセスを提供します。 3. **データインフラストラクチャ:** * **グローバルデータベース:** コアとなるリンクマッピングのための、強く一貫性のある分散データベース。 * **リージョナルキャッシュ:** 各リージョンにあるホットリンク用インメモリキャッシュ。 * **アナリティクスパイプライン:** イベント取り込み用のメッセージキュー、集計用ストリームプロセッサ、アナリティクスデータを保存および提供するためのNoSQLデータベース。 **データフロー:** * **リンク作成:** ユーザーの`POST`リクエストは、最も近い書き込みサービスにルーティングされます。サービスはエイリアスを生成または検証し、`short_alias -> long_URL`マッピングをグローバルデータベースに書き込みます。書き込みは2秒以内にすべてのリージョン間で同期的にレプリケートされます。 * **リダイレクト:** `GET`リクエストは、最も近いリダイレクトサービスにルーティングされます。まずリージョナルキャッシュを確認します。キャッシュヒットの場合、直ちに301リダイレクトを発行し、クリックイベントを非同期にアナリティクスキューに送信します。ミスの場合、グローバルデータベースのローカルレプリカにクエリを実行し、キャッシュを投入してから、リダイレクトとイベントロギングを実行します。 * **アナリティクス:** すべてのリージョンからのクリックイベントは、中央メッセージキューに発行されます。ストリームプロセッサはこれらのイベントを消費し、時間ウィンドウ化された統計（総クリック数、24時間クリック数、国別カウント）に集計し、結果をアナリティクスデータベースに書き込みます。 ### 2. ストレージの選択肢 * **リンクマッピング（プライマリストレージ）:** * **テクノロジー:** Google Cloud SpannerやCockroachDBのようなグローバルに分散されたSQLデータベース。 * **正当性:** リダイレクトにおける強い一貫性と、2秒未満のグローバル書き込み伝播要件によってこの選択が推進されています。これらのデータベースは同期レプリケーションと低レイテンシーのリージョナル読み取りを提供し、コアビジネス機能に対する高いコストを正当化します。`short_alias`は高速ルックアップのプライマリキーとして機能します。 * **キャッシュされたホットリンク:** * **テクノロジー:** Redis Clusterのようなリージョナルインメモリ分散キャッシュ。 * **正当性:** 1日あたり80億回の読み取りとヘビーなトラフィックの偏りを考慮すると、キャッシュはP95レイテンシー目標の80ms未満を達成し、データベースを保護するために不可欠です。各リージョンは、キャッシュアサイドパターンを使用して独自のキャッシュを維持します。 * **アナリティクスデータ:** * **取り込みキュー:** Apache KafkaまたはAWS Kinesis。これにより、高スループットのリダイレクトパスとアナリティクス処理が分離され、クリックイベントの耐久性のあるバッファが提供されます。 * **提供データベース:** Apache CassandraやScyllaDBのようなワイドカラムNoSQLストア。アナリティクスの高書き込み、時系列集計ワークロードに最適化されており、これらのクエリパターンに対してリレーショナルデータベースよりもスケーリング時にコスト効率が高いです。 ### 3. ID生成とエイリアス戦略 アルファベット`[a-zA-Z0-9]`から7文字のエイリアスを使用し、`62^7`（3.5兆以上）の一意の組み合わせを提供します。 * **ID生成:** バックグラウンドサービスが大量の一意のランダムIDプールを事前に生成し、専用キュー（例：Redisリスト）に保存します。書き込みサービスは、新しいリンクが作成されるときに、このプールから事前に生成されたIDを単純に取得します。このアプローチは高速でスケーラブルであり、ユーザーリクエスト中のオンザフライでの衝突チェックを回避します。 * **カスタムエイリアス処理:** ユーザーがカスタムエイリアスを送信すると、書き込みサービスはそれをグローバルデータベースに`INSERT`しようとします。`short_alias`列は一意制約を持つプライマリキーです。これにより、チェックアンドセット操作がアトミックに処理されます。エイリアスが使用されている場合、データベースは書き込みを拒否し、サービスはユーザーに`409 Conflict`エラーを返します。 ### 4. API設計 * **リンク作成:** `POST /api/v1/links` * **ボディ:** `{

グローバルURL短縮サービス — システム設計 ───────────────────────────────────────── 1. ハイレベルアーキテクチャとデータフロー ───────────────────────────────────────── システムは3つのプレーンで構成されています：ライトパス（リンク作成）、リードパス（リダイレクト）、アナリティクスパス（イベント取り込みとクエリ）。 主要コンポーネント： - グローバルAnycastロードバランサー / CDNエッジ（例：CloudflareまたはLambda@Edgeを備えたAWS CloudFront） - APIゲートウェイ + 認証レイヤー（レート制限、不正利用防止） - リンク作成サービス（ステートレス、水平スケーラブル） - リダイレクトサービス（ステートレス、極めてレイテンシに敏感） - ID生成サービス（分散型、ユニークなショートコード生成器） - プライマリリンクストア（グローバルにレプリケートされたリレーショナルDB、例：CockroachDBまたはAWS Aurora Global） - ホットリンクキャッシュ（Redis Cluster、リージョンごと） - アナリティクス取り込みキュー（KafkaまたはAWS Kinesis、リージョンごと） - アナリティクス集計ワーカー（ストリームプロセッサ、例：FlinkまたはKafka Streams） - アナリティクスストア（カラムナストア、例：ClickHouseまたはApache Druid） - アナリティクスクエリサービス（読み取り専用API） - コールドバックアップ用オブジェクトストレージ（S3互換） ライトパス（リンク作成）： 1. クライアントが最寄りのリージョナルAPIゲートウェイにPOSTリクエストを送信します。 2. APIゲートウェイがリクエストを認証し、レート制限を適用した後、リンク作成サービスに転送します。 3. リンク作成サービスがID生成サービスを呼び出し、ユニークなショートコードを取得します（またはカスタムエイリアスを検証します）。 4. レコードはローカルリージョンで強力な一貫性をもってプライマリリンクストアに書き込まれます。グローバルDBレプリケーションにより、約1〜2秒以内にレコードが他のリージョンに伝播され、「2秒以内にグローバルで利用可能」というSLAを満たします。 5. 同時に、そのリージョンでの最初のリダイレクトがキャッシュミスしないように、新しいマッピングがリージョナルRedisキャッシュにプッシュされます（ライトスルーまたはパブ/サブ無効化）。 6. ショートURLと共に201レスポンスがクライアントに返されます。 リードパス（リダイレクト）： 1. クライアントが最寄りのエッジノードにGET /{shortCode} を発行します。 2. エッジノードが自身のCDNキャッシュを確認します（極めてホットなリンクの場合、TTLは約5〜10秒で、有効期限のセマンティクスを尊重します）。 3. CDNミスの場合、リクエストはリージョナルリダイレクトサービスに到達します。 4. リダイレクトサービスがリージョナルRedisキャッシュを確認します（ホットリンクの期待ヒット率 > 99%）。 5. Redisミスの場合、リダイレクトサービスはプライマリリンクストアのローカルリードレプリカにクエリします。 6. リンクが期限切れまたは見つからない場合は、404/410を返します。 7. それ以外の場合は、HTTP 301（パーマネント）または302（テンポラリ）リダイレクトを発行します。デフォルトで302を使用するのは、ブラウザが無期限にキャッシュしないようにし、アナリティクスの精度を維持するためです。 8. クリックイベント（shortCode、タイムスタンプ、IPから派生した国、ユーザーエージェント）を非同期にリージョナルアナリティクス取り込みキューに発行します。これはファイアアンドフォーゲットであり、リダイレクトレスポンスをブロックしません。 アナリティクスパス： 1. リージョナルKafkaトピックがクリックイベントを受信します。 2. Flink/Kafka Streamsジョブがイベントを消費し、ローリング集計を維持します：総クリック数（カウンター）、過去24時間のクリック数（スライディングウィンドウ）、上位国（近似ヘビーヒッター スケッチ、例：Count-Min SketchまたはSpaceSaving）。 3. 集計結果は30〜60秒ごとにClickHouse（追記最適化カラムナストア）に書き込まれます。 4. アナリティクスクエリサービスはClickHouseから読み取り、事前に集計された結果を返します。生のイベントもアドホッククエリのためにClickHouseに保持されます。 5. クロスリージョンアナリティクス集計：各リージョンのKafkaクラスタは、Kafka MirrorMaker 2またはKinesisクロスリージョンレプリケーションを介して、中央アナリティクスリージョンにイベントをミラーリングします。中央ClickHouseクラスタがグローバルビューを保持します。 ───────────────────────────────────────── 2. ストレージの選択肢 ───────────────────────────────────────── リンクマッピング — CockroachDB（またはAurora Global DB）： 理由：書き込みの一貫性（重複エイリアスの防止）とグローバルでの低レイテンシ読み取りが必要です。CockroachDBは、マルチリージョンアクティブアクティブサポート、シリアライザブル分離、自動フェイルオーバーを備えた分散SQLデータベースです。Aurora Global DBは、単一のプライマリライターと、約1秒のレプリケーションラグを持つ異なるリージョンの最大5つのリードレプリカを持つ代替手段です。どちらも2秒のグローバル伝播SLAを満たします。 スキーマ（簡略化）： links(short_code VARCHAR(12) PK, long_url TEXT NOT NULL, owner_id BIGINT, created_at TIMESTAMPTZ, expires_at TIMESTAMPTZ, is_custom BOOLEAN) インデックス：short_code (PK, クラスタ化), owner_id + created_at (ユーザーダッシュボード用)。 推定サイズ：120Mリンク/日 × 365日 × 約300バイト/行 ≈ 年間約13TB。created_atによるパーティショニングで管理可能。 ホットリンクキャッシュ — Redis Cluster（リージョンごと）： 各リージョンは3〜6シャードとレプリカを持つRedis Clusterを実行します。キャッシュエントリ：short_code → {long_url, expires_at}。TTLはmin(リンク有効期限, 24時間)に設定されます。期待されるワーキングセット：上位1%のリンク（約120万）がトラフィックの約80%を占めます。エントリあたり約500バイトで、120万エントリ ≈ リージョンあたり600MB — 非常に手頃です。リンク作成時のライトスルー戦略と、最初のリダイレクトミス時の遅延ロードを使用します。 アナリティクスイベント — Kafka + ClickHouse： Kafkaは生のクリックイベントを7日間保持します（再生可能）。ClickHouseは、生のイベント（日付でパーティション化、short_codeでシャード化）と事前に集計されたマテリアライズドビューの両方を格納します。ClickHouseのカラムナストレージとベクトル化実行は、必要な集計クエリ（SUM、COUNT、GROUP BY国、スライディングウィンドウ）に理想的です。 コールドバックアップ — S3互換オブジェクトストレージ： リンクストアのスナップショットとClickHouseの週次エクスポートは、バージョン管理とクロスリージョンレプリケーションを備えたオブジェクトストレージに保存され、災害復旧に使用されます。 ───────────────────────────────────────── 3. ID生成とエイリアス戦略 ───────────────────────────────────────── ショートコード形式： Base62アルファベット（a-z、A-Z、0-9）から7文字を使用します。Base62^7 = 約3.5兆の組み合わせで、予見可能なニーズ（120M/日 × 10年 = 約438Bリンク）をはるかに超えています。 ID生成戦略 — 分散カウンタ + エンコーディング： スケールでの衝突ストームを回避するために、ランダム生成ではなく分散カウンタアプローチを使用します。 ステップ1：各リンク作成サービスインスタンスは、軽量なコーディネーションサービス（例：ZooKeeperをバックエンドとするRedis INCRBYまたは専用IDサービス）からIDブロックを取得します。各インスタンスは一度に10,000 IDのブロックを要求し、コーディネーションオーバーヘッドを削減します。 ステップ2：数値IDをBase62エンコードしてショートコードを生成します。7文字のBase62コードは最大約3.5兆のIDを表すことができます。 ステップ3：列挙攻撃を防ぎ、予測不可能性を追加するために、数値IDを秘密のソルトとXORするか、双対性スクランブル関数（ID空間に対するFeistel暗号）を使用します。 カスタムエイリアス： 1. クライアントが希望するエイリアス（英数字3〜20文字）を送信します。 2. リンク作成サービスは、DBのユニーク制約を使用して、カスタムエイリアスをshort_codeとしてINSERTを試みます。 3. ユニーク制約違反によりINSERTが失敗した場合、HTTP 409 Conflictを返し、別のエイリアスを試すように提案します。 4. カスタムエイリアスはID生成サービスを完全にバイパスします。 5. カスタムエイリアスは、DB書き込み前に別の名前空間チェック（不適切表現リスト、「api」、「admin」、「health」などの予約語）で予約されます。 生成されたコードの衝突処理： 単調増加カウンタと双対性エンコーディングを使用しているため、生成されたコードの衝突は構造的に不可能です。生成されたコードがカスタムエイリアスと一致する場合にのみ衝突が発生する可能性があります — これはユニーク制約によって処理されます。ID生成サービスは単に次のIDにインクリメントして再試行します（極めてまれ）。 ───────────────────────────────────────── 4. API設計 ───────────────────────────────────────── すべてのAPIはHTTPS上のRESTfulです。レート制限はAPIゲートウェイレイヤーで適用されます（例：認証済みユーザーあたり毎分100件の作成、匿名ユーザーあたり毎分10件の作成）。 POST /v1/links — ショートリンクの作成 リクエストボディ（JSON）： long_url: string (必須、有効なURLであること、最大2048文字) custom_alias: string (オプション、英数字3〜20文字) expires_at: ISO 8601 datetime (オプション) owner_id: string (オプション、認証トークンから取得) レスポンス 201 Created: short_code: string short_url: string (例：「https://sho.rt/aB3xY7z」) long_url: string expires_at: string または null created_at: string レスポンス 400: 無効なURLまたはエイリアス形式 レスポンス 409: カスタムエイリアスが既に使用されています レスポンス 429: レート制限を超過しました GET /{shortCode} — リダイレクト リクエストボディなし。パスパラメータ：shortCode。 レスポンス 302 Found、Locationヘッダーにlong_urlを設定。 レスポンス 404: ショートコードが見つかりません。 レスポンス 410 Gone: リンクが期限切れました。 このエンドポイントは、URLを最小限にするために、ルートドメイン（例：sho.rt/{shortCode}）で提供されます。 GET /v1/links/{shortCode}/analytics — アナリティクスの取得 認証必須（オーナーまたは管理者）。 クエリパラメータ： なし（デフォルトの概要を返します） レスポンス 200: short_code: string total_clicks: integer clicks_last_24h: integer top_countries: オブジェクトの配列、各オブジェクトはcountry_code（ISO 3166-1 alpha-2）とclick_countを持ち、降順にソートされ、最大5エントリ last_updated: ISO 8601 datetime（アナリティクスの鮮度を示す） レスポンス 404: リンクが見つかりません。 レスポンス 403: 認可されていません。 GET /v1/links/{shortCode} — リンクメタデータの取得（オプションのユーティリティエンドポイント） 認証必須。 レスポンス 200: long_url、created_at、expires_at、is_customを含む完全なリンクオブジェクト。 DELETE /v1/links/{shortCode} — リンクの削除/無効化 認証必須（オーナーまたは管理者）。 レスポンス 204 No Content。 レコードをソフト削除（deleted_atタイムスタンプを設定）し、パブ/サブ経由でキャッシュエントリを無効化します。 ───────────────────────────────────────── 5. スケーリングアプローチ ───────────────────────────────────────── ホットキー問題： 少数のリンク（バイラルURL、マーケティングキャンペーン）は、毎分数百万のリダイレクトを受け取ります。単純なRedisシャーディングでは、1つのキーのすべてのトラフィックが1つのシャードに配置されます。 緩和策： - 各リダイレクトサービスインスタンス内のローカルインプロセスキャッシュ（例：10,000エントリのLRUを備えたCaffeine、TTL 5秒）。これにより、最もホットなキーをプロセス内で完全に吸収し、Redisへのラウンドトリップを排除します（上位約0.1%のリンク）。 - 短いTTL（5〜10秒）を持つCDNエッジキャッシュ。リダイレクトレスポンス自体に適用されます。1日あたり80億リダイレクトの場合、90%のCDNヒット率でもオリジンからのリクエストを72億件オフロードします。 - Redisリードレプリカ：ホットキーシャードをより多くのレプリカに昇格させ、ラウンドロビンで読み取りをルーティングします。 キャッシュ戦略： 3層キャッシュ：CDNエッジ → インプロセスLRU → Redis Cluster → DBリードレプリカ。 キャッシュのポピュレーション：作成時のライトスルー、最初のミス時の遅延ロード。 キャッシュの無効化：リンクの削除または有効期限切れ時に、Redisパブ/サブチャネルに無効化メッセージを発行します。すべて のリダイレクトサービスインスタンスが購読し、ローカルLRUからキーを削除します。CDNエントリはTTLにより自然に期限切れになります。 パーティショニング： - リンクストア：short_codeハッシュでパーティション化します（CockroachDBは範囲ベースのシャーディングを通じてこれを自動的に処理します）。双対性スクランブル後のショートコードは均一に分散されるため、ホットパーティションはありません。 - Kafka：short_codeハッシュでクリックイベントをパーティション化します。これにより、特定のリンクのすべてのイベントが同じパーティションに送信され、シャッフルなしでリンクごとのステートフル集計が可能になります。 - ClickHouse：short_codeでシャード化し、日付でパーティション化します。単一リンクのアナリティクスに対するクエリは1つのシャードにヒットします。時間範囲クエリはパーティションプルーニングの恩恵を受けます。 マルチリージョントラフィック： 3つのリージョンにデプロイします：US-East、EU-West、AP-Southeast（北米、ヨーロッパ、アジアをカバー）。 - DNSベースのGeoDNSまたはAnycastがユーザーを最寄りのリージョンにルーティングします。 - 各リージョンは、読み取り（リダイレクトサービス + Redis + DBリードレプリカ）に対して完全に独立しています。 - 書き込み（リンク作成）は、最寄りのリージョンのリンク作成サービスに送信され、グローバルに分散されたDBのローカルノードに書き込まれます。CockroachDBは約1〜2秒以内に他のリージョンにレプリケートします。 - アナリティクスイベントはリージョンごとに処理され、グローバル集計のために中央アナリティクスクラスタにミラーリングされます。 容量スケッチ： - 1日あたり80億リダイレクト = 平均約92,500 req/s、ピーク時約300,000 req/s（3倍の係数）。 - 90%のCDNヒット率の場合：オリジンへのリクエストは約30,000 req/s（3リージョン全体）= リージョンあたり約10,000 req/s。 - 各リダイレクトサービスインスタンスは、約5,000 req/sを処理できます（主にキャッシュヒット、最小限のCPU）。平均負荷ではリージョンあたり約2〜4インスタンス、ピーク時には20以上に自動スケーリングします。 - 1日あたり1億2000万件の書き込み = 平均約1,400件/s。リンク作成サービスはボトルネックではありません。 ───────────────────────────────────────── 6. 信頼性戦略 ───────────────────────────────────────── 可用性目標：99.99% = 年間約52分のダウンタイム。 フェイルオーバー： - 各リージョンは、ヘルスチェックを備えたリージョナルロードバランサーの後ろで、複数のステートレスサービスインスタンスを実行します（フェイルオープン：10秒以内に異常なインスタンスを削除）。 - Redis Clusterは自動フェイルオーバーを使用します：プライマリシャードが失敗した場合、約15秒以内にレプリカが昇格されます。このウィンドウ中、リダイレクトサービスはDBリードレプリカにフォールバックします（レイテンシはわずかに高くなりますが、正しいです）。 - リージョン全体が失敗した場合、GeoDNSはヘルスプローブを通じて障害を検出し、約30〜60秒以内に次の最も近いリージョンにトラフィックをリダイレクトします。残りのリージョンは負荷を吸収する必要があります。自動スケーリングがこれを処理します。 - CockroachDB / Aurora Global DB：プライマリリージョンが利用できない場合、別のリージョンのノードに自動フェイルオーバーします。Auroraの場合、これはプライマリへのリードレプリカの手動または自動昇格を含みます（自動化によるRTOは約1分）。 データレプリケーション： - リンクストア：リージョン内では同期レプリケーション（少なくとも2ノード）、クロスリージョンレプリケーションは非同期（CockroachDBのコンセンサスがリージョンをまたぐ、またはAurora Global DBは約1秒のラグ）。2秒の伝播SLAが満たされるため、クロスリージョン読み取りの最終的な一貫性を受け入れます。 - Redis：各シャードは同じリージョンに少なくとも1つのレプリカを持ちます。クロスリージョンRedisレプリケーションはありません（Redisはキャッシュであり、DBが真実の情報源です）。 - Kafka：各リージョン内でレプリケーション係数3。 - ClickHouse：ClickHouse Keeper（ZooKeeperの代替）を使用して、アナリティクスリージョン内でレプリケートされます。アナリティクスは最終的に一貫性があるため、マルチリージョンClickHouseレプリケーションは不要です。 バックアップ： - リンクストアの毎日の論理バックアップをオブジェクトストレージ（S3）に保存し、30日間保持します。 - ClickHouseの週次フルエクスポートをオブジェクトストレージに保存し、90日間保持します。 - Kafkaトピックデータは7日間保持されます（アナリティクス復旧のための再生バッファとして機能します）。 - バックアップ復元のテストは、ステージング環境での自動復元ドリルを通じて毎月実施されます。 劣化時の動作： - Redisが利用できない場合：リダイレクトサービスはDBリードレプリカにフォールバックします。レイテンシは増加しますが、正しさは維持されます。DBリードレプリカのアラートと自動スケーリング。 - アナリティクスキューが利用できない場合：クリックイベントはドロップされます（アナリティクスは最終的に一貫性があるため、この損失は許容されます）。リダイレクトがアナリティクス障害によってブロックされることはありません。キューが正常でない場合、リダイレクトサービス内のサーキットブレーカーがイベント発行を無効にします。 - リンクストアプライマリが利用できない場合：新規リンク作成が失敗します（503を返します）。リダイレクトはキャッシュデータとリードレプリカを使用して継続されます。作成はリダイレクトの可用性よりも重要度が低いため、これは許容されます。 - リージョン全体がダウンした場合：GeoDNSフェイルオーバーが隣接リージョンに切り替わります。ユーザーはレイテンシの増加を経験しますが、サービスは利用可能なままです。 - APIゲートウェイでのレート制限と不正利用検出により、DDoS攻撃がシステムを圧倒するのを防ぎます。 ───────────────────────────────────────── 7. 主要なトレードオフと却下された代替案 ───────────────────────────────────────── トレードオフ1：302 vs. 301リダイレクト デフォルトとして302（一時リダイレクト）を選択しました。301（パーマネント）は、ブラウザが無期限にリダイレクトをキャッシュできるようにし、オリジン負荷を削減します。しかし、301では同じブラウザからの繰り返しクリックの追跡が不可能になり、アナリティクスが壊れ、リンクの更新や期限切れができなくなります（ブラウザはキャッシュされたリダイレクトを永久に提供します）。302のコストはオリジントラフィックの増加ですが、これはCDNとインプロセスキャッシュで緩和します。オーナーによって明示的にパーマネントとしてマークされたリンク（期限切れなし）については、オプトインとして301を提供できますが、デフォルトは302です。 トレードオフ2：ランダムショートコード vs. カウンタベースエンコーディング 却下：ランダムな7文字のBase62文字列を生成し、DBでの衝突を確認する。 却下理由：1日あたり1億2000万リンク、3.5兆コード空間で、衝突確率は低く始まりますが時間とともに増加します。さらに重要なのは、各作成で衝突を確認するためのDB読み取り、次に書き込みが必要になることです — 競合状態下では2回のラウンドトリップです。カウンタベースのアプローチでは、IDは構築によって一意であることが保証されており、衝突チェックは不要です。カウンタサービスはマイナーなコーディネーションオーバーヘッドですが、スケールでのDB衝突チェックよりもはるかに安価です。双対性スクランブルステップは、ランダムコードの予測不可能性の利点を維持します。 トレードオフ3：同期アナリティクス vs. 非同期キュー 却下：リダイレクトリクエスト中にクリックイベントをアナリティクスDBに同期的に書き込む。 却下理由：これにより、すべてのリダイレクトに10〜50ミリ秒のレイテンシが追加されます（クリティカルパスでのClickHouseまたはアナリティクスDBの書き込み）。これはP95 < 80ミリ秒のSLAに違反します。また、リダイレクトの可用性とアナリティクスの可用性の間にハードな依存関係が生じます。非同期キューアプローチは、これらの懸念を完全に分離します。コストは、アナリティクスが最終的に一貫性があること（30〜60秒の遅延）ですが、これは要件に従って明示的に許容されます。 トレードオフ4：単一グローバルDB vs. マルチリージョンアクティブアクティブDB 単一リージョンプライマリとグローバルリードレプリカの代わりに、グローバルに分散されたDB（CockroachDBまたはAurora Global）を選択しました。単一リージョンプライマリは、よりシンプルな一貫性セマンティクスを提供しますが、すべての書き込みが1つのリージョンに送信されることになります（他のリージョンのユーザーがリンクを作成する際の高レイテンシ、および書き込みの単一障害点）。グローバルに分散されたDBはコストが高く、運用上の複雑さが増しますが、リンク作成のレイテンシと書き込みの可用性はユーザーエクスペリエンスと99.99%の可用性目標にとって重要であるため、正当化されます。 トレードオフ5：アナリティクスのためのClickHouse vs. 時系列DB（例：InfluxDB） 却下：アナリティクスストレージのためのInfluxDBまたはTimescaleDB。 却下理由：時系列データベースは、固定タグセットを持つメトリクスに最適化されています。私たちのアナリティクスクエリは、柔軟なGROUP BY国、任意の時間ウィンドウ、およびリンクメタデータとの結合の可能性を必要とします。ClickHouseのカラムナストレージ、SQLインターフェース、およびマテリアライズドビューは、これらのパターンをより自然に、より高いスケールで処理します。ClickHouseはまた、近似集計（分位数、ヘビーヒッター）をネイティブにサポートしており、スケールでの上位5カ国クエリに役立ちます。 ───────────────────────────────────────── 予算正当化の概要 ───────────────────────────────────────── より多くを費やすべき点： - マルチリージョンRedisクラスタ：リダイレクトレイテンシはコアSLAであり、キャッシュミスは高コストです。 - グローバルに分散されたリンクストア（CockroachDB / Aurora Global）：リダイレクトの正確性と2秒のグローバル伝播にはこれが不可欠です。 - CDNエッジ容量：リダイレクトレイテンシと可用性にとって最もレバレッジの高い単一投資です。 - リダイレクトサービスのための自動スケーリング：トラフィックは非常に変動し、スパイクが発生します。 より少なく費やすべき点： - アナリティクスインフラストラクチャ：最終的な一貫性は許容されるため、レプリケーションを備えた単一の中央ClickHouseクラスタで十分です。マルチリージョンアナリティクスレプリケーションは不要です。 - リンク作成サービス：書き込み量は約1,400/秒であり、数インスタンスで容易に処理できます。 - コールドストレージ/バックアップ：オブジェクトストレージは安価です。保持期間は過剰にプロビジョニングする方が、不足するより良いです。 - クロスリージョンRedisレプリケーション：RedisはDBをバックエンドとするキャッシュであり、DBは既にレプリケートされているため、クロスリージョンレプリケーションはコストと複雑さを増加させるだけで、メリットは最小限です。