URL短縮サービスの設計

システム設計：URL短縮サービス

A. ハイレベルアーキテクチャ

システムは以下の主要コンポーネントで構成されます。

1. ロードバランサー (LB): 短縮リクエストとリダイレクトリクエストの両方の着信トラフィックを、複数のAPIサーバーに分散させます。グローバルLB（例：AWS Route 53）でDNSベースのルーティングを行い、次にリージョナルLB（例：AWS ELB/ALB）でリージョン内のトラフィックを分散させるなど、複数のレイヤーのLBを使用します。
2. APIサーバー (Webサーバー): 短縮URLの作成 (POST /shorten) と短縮URLのリダイレクト (GET /{short_code}) の両方の着信リクエストを処理します。これらのサーバーはステートレスです。
3. URL短縮サービス (ビジネスロジック): 短縮コードの生成、データベースとの連携、およびキャッシュの可能性を担当するマイクロサービスです。
4. データベース: 短縮コードと元のURLのマッピングを格納します。選択については、セクションCで詳しく説明します。
5. キャッシュ: データベースの負荷とリダイレクトのレイテンシを削減するために、頻繁にアクセスされる短縮URLマッピングを格納します。RedisまたはMemcachedを使用します。
6. メッセージキュー (オプションですが、スケールのため推奨): 分析の更新や潜在的なリトライ処理などの非同期タスクに使用しますが、コア機能には厳密には必要ありません。

リクエストフロー:

• URL作成 (POST /shorten):

  1. クライアントは、元のURLを含むPOSTリクエストをAPIゲートウェイ/ロードバランサーに送信します。
  2. LBはリクエストを空いているAPIサーバーに転送します。
  3. APIサーバーはURL短縮サービスを呼び出します。
  4. URL短縮サービスは一意の短縮コードを生成します（セクションBを参照）。
  5. サービスはマッピング（short_code -> original_url）をデータベースに格納します。
  6. サービスはマッピングをキャッシュにも書き込む可能性があります。
  7. APIサーバーは短縮URL（例：https://short.url/{short_code}）をクライアントに返します。

• URLリダイレクト (GET /{short_code}):

  1. ユーザーがブラウザに短縮URLを入力します。
  2. リクエストがロードバランサーに到達します。
  3. LBはリクエストを空いているAPIサーバーに転送します。
  4. APIサーバー（または専用のリダイレクトサービス）は、まずキャッシュで short_code を確認します。
  5. キャッシュヒット: 見つかった場合、元のURLがキャッシュから取得され、APIサーバーは元のURLを含むHTTP 301（恒久的リダイレクト）または302（一時的リダイレクト）レスポンスをクライアントに発行します。
  6. キャッシュミス: キャッシュで見つからなかった場合、APIサーバーはデータベースに short_code を問い合わせます。
  7. データベースは元のURLを返します。
  8. APIサーバーは将来のリクエストのためにマッピングをキャッシュに追加します。
  9. APIサーバーはHTTPリダイレクトレスポンスを発行します。

B. 短縮URL生成戦略

一意で、短く、できればある程度ランダムに見えるコードを生成する戦略が必要です。主な目標は、一意性と効率性です。

• ハッシュ化（例：MD5、SHA-1）:

  • 長所: 決定論的であり、一意のコードを生成できます。切り捨て可能です。
  • 短所: 衝突の可能性があります（ただし、優れたハッシュ化と切り捨てではまれです）。コードは均一に分散されない可能性があり、ホットスポットにつながります。人間が読んだり覚えたりするのは容易ではありません。

• カウンターベース（例：自動インクリメントID）:

  • 長所: 一意性を保証します。実装が簡単です。
  • 短所: 中央集権化されたカウンターがボトルネックになる可能性があります。シーケンシャルIDは予測可能であり、使用パターンが明らかになる可能性があります。高可用性とスケールのためには、分散カウンターシステムが必要です。

• 事前生成キープール:

  • 長所: 生成負荷を分散します。多数の一意のコードを事前に生成できます。
  • 短所: プールを管理し、重複がないことを確認し、潜在的に大量のキーを事前に生成する必要があります。

• カウンターのBase-62/Base-64エンコーディング:

  • 長所: 単調増加するカウンター（例：64ビット整数）を一意の短縮コードにエンコードすることで、短く一意のコードを生成します。これは効率的で、比較的短い文字列を生成します。カウンターが適切に管理されていれば、一意性を保証します。
  • 短所: 複数のAPIサーバー間でボトルネックを回避し、一意性を確保するために、分散カウンターサービスが必要です。

選択した戦略：カウンターのBase-62エンコーディング

このアプローチは、一意性、短さ、スケーラビリティの最適なバランスを提供します。分散ID生成サービス（TwitterのSnowflakeやApache ZooKeeperなど）を使用して、一意でシーケンシャルな64ビットIDを生成します。各IDは、その後Base-62文字列にエンコードされます。これにより、短く一意のコードが得られます。IDのシーケンシャルな性質は、ID生成にランダムなコンポーネントを使用するか、後でマッピングをシャッフルすることで、予測可能なパターンを回避するように管理できます。

C. データストレージ

データベース技術: Cassandra や ScyllaDB （高性能なCassandra互換データベース）のようなNoSQLデータベースは、その分散性、高可用性、およびURL作成に不可欠な優れた書き込みパフォーマンスにより、有力な候補です。あるいは、シャーディングされたリレーショナルデータベース（Citus搭載のPostgreSQLやVitess搭載のMySQLなど）も機能しますが、この種のキーバリュー検索のスケーリングにはNoSQLの方が一般的に簡単です。

ここでは、その線形スケーラビリティと耐障害性のため、Cassandra を想定します。

スキーマ:

読み取り用に最適化されたキースペースにシンプルなスキーマを使用します。

CREATE TABLE url_mappings (
    short_code text PRIMARY KEY,
    original_url text,
    created_at timestamp
);

• short_code: 生成された一意の短縮コード（例：aBcDeF）。これが主キーです。
• original_url: リダイレクト先の長URL。
• created_at: URLが短縮されたタイムスタンプ。

ストレージ要件の見積もり（5年間）:

• 月あたりの新規URL数: 1億
• 5年間の総URL数: 1億/月 * 12ヶ月/年 * 5年 = 60億URL
• 平均短縮コード長: 64ビット整数のBase-62エンコーディングは約11文字になります。short_code のオーバーヘッドを含めて15バイトと仮定します。
• 平均元のURL長: URLは非常に長くなる可能性があるため、2000バイトと仮定します。
• オーバーヘッド: データベースストレージ（レプリケーション、インデックスなど）の10%のオーバーヘッドを仮定します。

総ストレージ:

(60億URL) * (15バイト/short_code + 2000バイト/original_url) * 1.10 (オーバーヘッド)

= 6 * 10^9 * 2015バイト * 1.10

≈ 13.3 * 10^12 バイト

≈ 13.3 テラバイト (TB)

これは、ノードを追加することで水平にスケールできるCassandraのような分散NoSQLデータベースにとって、管理可能な量です。

Cassandra を選択する理由:

• スケーラビリティ: ノードを追加することで線形にスケールし、大量のデータとトラフィックを処理できます。
• 可用性: 単一障害点のない高可用性で設計されています。データは複数のノードとデータセンターにレプリケートされます。
• 書き込みパフォーマンス: URL作成部分に不可欠な、優れた書き込みスループット。
• 読み取りパフォーマンス: キーバリュー検索に必要な、高速な読み取りパフォーマンスに最適化できます。

D. スケーリング戦略

1. キャッシュ戦略:

• レベル1キャッシュ (分散キャッシュ): RedisまたはMemcachedクラスターを使用します。short_code -> original_url マッピングを格納します。これにより、読み取りリクエストの大部分（トラフィックの99％、100:1の読み書き比率を考慮）に対応できます。
• キャッシュ無効化/有効期限: 簡単のため、および5年間のライフサイクルを考慮すると、予想されるアクセスパターンよりもわずかに長いTTL（Time-To-Live）を使用するか、短縮URLが作成されるとマッピングが変更されることはめったにないという事実に依存できます。一般的な戦略は、アプリケーションが再起動されるか、手動無効化がトリガーされるまで無期限にキャッシュすることです（ただし、URL短縮サービスではこれはまれです）。
• キャッシュのポピュレーション: リダイレクトリクエストがキャッシュでヒットしなかった場合、元のURLはデータベースから取得され、リダイレクトを返す前にキャッシュに書き込まれます。

2. データベースパーティショニング/シャーディング:

• Cassandra: Cassandraは主キー（short_code）に基づいてパーティショニングを自動的に処理します。データは一貫性ハッシュアルゴリズムを使用してノード全体に分散されます。これにより、データは本質的にシャーディングされます。
• リレーショナルDB（選択した場合）: short_code に基づいてデータベースをシャーディングします（例：short_code のハッシュを使用してシャードを決定）。これにより、複数のデータベースインスタンスに負荷とデータを分散させます。

3. ホットキー（バイラルURL）の処理:

• キャッシング: ホットキーに対する主な対策は、積極的なキャッシングです。バイラルURLはRedis/Memcachedに大量にキャッシュされるため、後続のリクエストはデータベースを完全にバイパスしてメモリから直接提供されます。
• データベース読み取りレプリカ（RDBMSを使用する場合）: キャッシュがあってもデータベースがボトルネックになった場合、読み取りレプリカを使用できますが、Cassandraの分散性はすでにこれをうまく処理しています。
• コンテンツデリバリーネットワーク (CDN): 極めて高いトラフィックの場合、リダイレクトレスポンス自体をエッジでCDNを使用してキャッシュできる可能性がありますが、これは複雑さを増し、すべてのリダイレクトタイプ（例：302）に適しているとは限りません。ただし、APIサーバー自体はCDNの背後に配置して、グローバルアクセスを高速化できます。
• 専用読み取りパス: 極端なケースでは、別の読み取り最適化データストアまたはキャッシュレイヤーを検討できますが、プライマリキャッシュはほとんどのホットキーシナリオに対応する必要があります。

E. 信頼性と耐障害性

1. 高可用性 (99.9%アップタイム):

• 冗長性: 複数のアベイラビリティゾーン（AZ）またはリージョンにわたって、各コンポーネント（APIサーバー、キャッシュノード、データベースノード）の複数のインスタンスをデプロイします。
• ロードバランサー: LBは、正常でないインスタンスから自動的にトラフィックをルーティングします。
• ステートレスAPIサーバー: APIサーバーはステートレスであるため、どのサーバーでもどのリクエストも処理できます。1台が失敗しても、他のインスタンスがシームレスに処理を引き継ぎます。
• データベースレプリケーション: Cassandraは組み込みのデータレプリケーションを提供します。レプリケーションファクター（例：3）を複数のノードとデータセンターに設定します。ノードが失敗しても、他のノードのレプリカがデータをサービスします。
• キャッシュレプリケーション/クラスタリング: Redis SentinelまたはRedis Clusterは、キャッシュの高可用性を提供できます。

2. コンポーネント障害の処理:

• APIサーバー障害: LBは障害を検出し、正常でないインスタンスへのトラフィック送信を停止します。他のインスタンスはリクエストのサービスを続行します。
• キャッシュノード障害: Redis ClusterまたはSentinelを使用している場合、システムは自動的にレプリカを昇格させるか、クラスターを再構成します。単一ノードが失敗した場合、一部のキャッシュデータが一時的に利用できなくなる可能性がありますが、システムはデータベースにフォールバックします。
• データベースノード障害: Cassandraはノード障害を自動的に処理します。データは他のノードのレプリカから利用可能です。AZ全体が失敗した場合でも、他のAZのノードからデータは利用可能です（マルチAZデプロイの場合）。

3. データレプリケーションとフェイルオーバー:

• データベース: Cassandraのレプリケーション戦略は、データの耐久性と可用性を保証します。レプリケーションファクター3を使用し、レプリカを異なる物理的な場所（ラック/AZ）に分散させます。ノードが失敗しても、他のレプリカが読み書きをサービスできます。
• キャッシュ: Redis SentinelまたはClusterは、キャッシュノードの自動フェイルオーバーを提供します。
• アプリケーションレベル: サービス間の通信における一時的なネットワーク問題に対して、リトライメカニズムを実装します。

F. 主要なトレードオフ

1. 一貫性 vs. 可用性 (CAP定理):

   • 選択: リダイレクトサービスについては、強い一貫性よりも可用性とパーティション耐性を優先します。URL作成については、一意の短縮コードを保証するために強い一貫性が必要です。リダイレクトについては、データベースレプリカが一時的に利用できない場合でも、リクエストをブロックするよりも、キャッシュから古いエントリを提供するか、エラーを返すことを優先します。
   • 正当化: URL短縮サービスのコア機能は、ユーザーを迅速かつ確実にリダイレクトすることです。一時的なキャッシュエントリの不正確さや特定短縮URLマッピングの一時的な利用不可（適切なレプリケーションがあればまれですが）は、広範なサービス停止よりも許容できます。URL作成については、分散IDジェネレーターが強い一貫性保証とともに使用され、一意性が保証されます。

2. レイテンシ vs. コスト/複雑さ (キャッシュ戦略):

   • 選択: リダイレクトの50ms未満のレイテンシ要件を満たすために、積極的なマルチレイヤーキャッシング戦略（Redis/Memcachedのようなインメモリキャッシュ）を選択しました。
   • 正当化: 100:1の読み書き比率と厳格なレイテンシ要件（99.9%アップタイム、95パーセンタイルで50ms未満のレイテンシ）は、キャッシングを不可欠なものにします。ほとんどのリクエストをRAMから直接提供することで、データベースの負荷と応答時間が大幅に削減されます。キャッシングは複雑さ（キャッシュ無効化、一貫性の懸念、追加インフラコスト）を追加しますが、パフォーマンスと可用性の目標を満たすためには必要なトレードオフです。これなしでは、データベースは読み取りトラフィックに圧倒され、レイテンシの増加や潜在的な障害につながります。

A) 高レベルアーキテクチャ

コンポーネント

1. エッジ

• DNS + CDN/Anycastエッジ（オプションですが、グローバルでp95が50ms未満の場合は強く推奨）
• WAF + DDoS保護
• グローバルロードバランサー（GSLB）による最寄りのリージョンへのルーティング

2. リージョンスタック（少なくとも2つのリージョン、アクティブ-アクティブ）

• L7ロードバランサー（ALB/Envoy）
• ステートレスAPIサービス（URL短縮）
  • APIの作成（書き込みパス）
  • リダイレクトAPI（読み取りパス）
• キャッシュ層
  • L1インプロセスキャッシュ（非常に小さい、インスタンスごと、非常にホットなキー）
  • L2分散キャッシュ（Redis/Memcachedクラスタ）
• 永続ストレージ
  • 短縮コードから長URLへのマッピング用のプライマリKVストア（DynamoDB/Cassandra/ScyllaDBスタイル）
  • 分析、ユーザーアカウント、カスタムエイリアス用のオプションのリレーショナルストア（クリティカルなリダイレクトパスには含まれない）（Postgres/MySQL）
• 非同期パイプライン（クリティカルではない）
  • クリックイベント、ログ、不正信号用のKafka/Kinesis/PubSub
  • ストリームプロセッサ / OLAPシンク（ClickHouse/BigQuery/S3）

リクエストフロー：URL作成（書き込み）

1. クライアントが長URL（+オプションのカスタムエイリアス、TTLポリシー、ユーザー認証）を指定してPOST /api/shortenを呼び出します。
2. リクエストはGSLB -> リージョンLB -> APIサーバーに到達します。
3. APIはURLを検証（形式、許可/拒否リスト、セーフブラウジング）、正規化し、レート制限を適用します。
4. 短縮コード生成サービスがユニークなコードを割り当てます（詳細はセクションBを参照）。
5. APIはKVストアにマッピングを書き込みます（短縮コードをパーティションキーとして）。
   • 書き込みには、created_at、expire_at（>=5年）、long_url、owner_id、フラグが含まれます。
   • クォーラム書き込み（またはストアに応じて強く一貫した書き込み）を使用します。
6. APIは短縮コードから長URLへのマッピングをL2キャッシュに（ライトスルーで）格納し、短縮URLを返します。
7. 非同期イベント（作成、ユーザー、スパムスコアリング）をストリームに発行します。成功レスポンスには必須ではありません。

リクエストフロー：URLリダイレクト（読み取り）

1. ブラウザがGET /{code}をリクエストします。
2. エッジが最寄りのリージョンにルーティングします。オプションのCDNは、ポリシーで許可されている場合、301/302レスポンスをキャッシュできます。
3. APIサーバーがコードを解析します。
4. 検索順序：
   a) L1インプロセスキャッシュ
   b) L2 Redis/Memcached
   c) KVストア（キャッシュミスの場合）
5. 見つかり、期限切れまたはブロックされていない場合：Location: long_url を指定してHTTP 301/302リダイレクトを返します。
   • ミス時にキャッシュをフィルします（L2に設定、オプションでL1にも）。
6. クリックイベントを非同期に発行します（ファイアアンドフォーゲット）。
7. 見つからない場合：404（リージョン分離を使用している場合は、オプションでオリジンリージョンにフォールバック）。

レイテンシターゲット

• L2キャッシュヒットが支配的であるべきです（リージョン内でミリ秒未満から数ミリ秒）。エッジルーティングと高いキャッシュヒット率により、p95が50ms未満で実現可能です。

B) 短縮URL生成戦略

要件

• 月間1億件の新規短縮 ~ 1日あたり330万件 ~ 平均約38.6書き込み/秒（ピークはさらに高い）。
• 一意で、短く、URLセーフなコードを、低い衝突リスクと調整のボトルネックなしで生成する必要があります。

オプション

1. Hash(long_url)

• 利点：決定的であり、重複排除が可能です。
• 欠点：衝突の処理が必要。パターンが明らかになる。異なるユーザーに対して複数の同一の長URLをサポートするのが難しい。正規化の変更が安定性に影響する。

2. 中央カウンター（自動インクリメント）+ base62エンコーディング

• 利点：コンパクト。衝突なし。シンプル。
• 欠点：単一の論理的ボトルネック（シャーディングしない限り）。シーケンシャルなコードは推測可能（セキュリティ/不正利用）。

3. 分散ID（Snowflake風：時間 + ワーカー + シーケンス）その後base62エンコーディング

• 利点：中央調整者なし。スケーラブル。一意。サイズが限定されている。
• 欠点：コードがわずかに長くなる。時間ベースの順序付けが一部の情報漏洩する。

4. 事前生成キープール

• 利点：最速の割り当て。作成とID生成を分離する。
• 欠点：プールの管理、ストレージ、再利用の回避が必要。運用の複雑さ。

選択されたアプローチ

• 各APIノード（または専用IDサービス）によって生成されるSnowflake風の64ビット一意IDを使用し、base62/base64urlにエンコードします。
  • base62での64ビットは、最悪の場合最大11文字になります。通常は10〜11文字で、許容範囲です。
  • より短いコードが必要な場合は、エポック/時間ウィンドウとワーカービットを慎重に設定して、56〜60ビット（それでも十分）を使用します。
• 予測可能性を減らすために、オプションで、base62エンコーディングの前に64ビットIDに可逆置換（例：Feistelネットワーク）を適用します。一意性は維持されますが、コードは非シーケンシャルになります。

この選択の理由

• 単一カウンターのボトルネックを排除します。
• 衝突処理は不要です。
• マルチリージョンアクティブ-アクティブでうまく機能します。
• 予測可能性は置換によって緩和されます。

カスタムエイリアス

• ユーザーがカスタムコードをリクエストした場合、KVストアでの条件付き書き込み（存在する場合のみ書き込み）で利用可能性を検証します。競合があった場合は拒否します。

C) データストレージ

データベースの選択

• プライマリストア：高可用性、水平スケーラブルなKVデータベース（DynamoDBまたはCassandra/ScyllaDB）。
• 理由：
  • アクセスパターンは短縮コードによるキーベースの読み取りです。
  • 高QPSでの読み取り負荷が高いため、KVストアは低レイテンシのポイントルックアップに優れています。
  • 組み込みのレプリケーション、パーティショニング、運用の成熟度。

スキーマ（単一テーブル）
テーブル：url_mapping

• パーティションキー：short_code（文字列）
• 属性：
  • long_url（文字列）
  • created_at（タイムスタンプ）
  • expire_at（タイムスタンプ、created_at + 5年以降である必要があります。nullは「無期限」を意味できますが、要件は少なくとも5年です）
  • owner_id（文字列、オプション）
  • status（active/disabled/malicious）
  • meta（オプション：タイトル、キャンペーンなど）
    インデックス（オプション）
• owner_id + created_at のGSI/セカンダリインデックス（ユーザーリンクの一覧表示用、リダイレクトパスには使用しない）。

ストレージ推定（5年間）

• 新規URL：月間1億件 * 12ヶ月 * 5年 = 60億件のマッピング。
• レコードあたりのサイズ概算：
  • short_code：10〜11バイト（オーバーヘッド込みで約16バイトとして保存）
  • long_url：平均100バイトと仮定（50〜200バイトの可能性あり。オーバーヘッド込みで120バイトを使用）
  • タイムスタンプ/ステータス/owner_id：平均約40バイト（owner_idはオプション）
  • DBオーバーヘッド（キー、レプリケーションメタデータ、圧縮）：変動しますが、約100バイトのオーバーヘッドと仮定します。
  • 合計論理サイズ（各アイテムあたり）約250バイト（控えめな見積もり）。
• 生論理ストレージ：60億 * 250バイト = 1.5 TB。
• レプリケーションファクター3（Cassandra/Scyllaで一般的）の場合：約4.5 TB。
• インデックスとヘッドルームを追加：5年間でクラスタ全体で6〜10 TBを計画します。

注記

• 長URLはアプリケーションレイヤーで圧縮（辞書/deflate）してサイズを削減できますが、レイテンシを追加しない場合に限ります。多くのKVストアはSSTableも圧縮します。

D) スケーリング戦略

トラフィック推定

• 書き込み：平均約38.6/秒。ピークを10倍と仮定 => 約400/秒。
• 読み取り：100:1 => 平均約3,860読み取り/秒。ピークはさらに高くなる可能性あり（例：使用状況の急増に応じて50k〜200k/秒）。

読み取りのスケーリング

1. キャッシュ

• L1インプロセスキャッシュ：非常に小さい（例：1万〜10万エントリ）、短いTTL（30〜120秒）で、マイクロホットスポットを吸収し、RedisのQPSを削減します。
• L2 Redis/Memcached：
  • キャッシュ値：long_url + status + expire_at。
  • TTL戦略：
    • リンクが不変（一般的）な場合、長いTTL（数時間〜数日）を設定します。
    • expire_atを尊重するために、TTL = min(設定された最大TTL, expire_at - now) を設定します。
  • キャッシュアサイドとネガティブキャッシュを使用：
    • スキャナーからのDBヒットを減らすために、「見つからない」ことを短いTTL（例：30〜60秒）でキャッシュします。
• リダイレクトで95〜99%以上のキャッシュヒット率を目指します。

2. CDNキャッシュ（オプションですが強力）

• 安定した301リダイレクトの場合、CDNは人気のあるコードのリダイレクトレスポンスをキャッシュできます。
• リンクを迅速に無効化する能力を考慮する必要があります。緩和策：
  • 短いCDN TTL（例：60〜300秒）+無効化時のパージ
  • または、オリジンでリダイレクトロジックを維持しますが、エッジKVでマッピングをキャッシュします（高度）。

データベースのパーティショニング/シャーディング

• short_codeによるパーティショニング（一貫性ハッシュ/トークンリング）。
• コードは擬似ランダム（置換後）であるため、均等な分散が期待されます。
• ノードを追加して線形にスケールします。

ホットキー（バイラルURL）の処理

• マルチレイヤーアプローチ：
  1. エッジ/CDNは、最もホットなキーのリダイレクトレスポンスを短いTTLでキャッシュします。
  2. L1 + L2キャッシュは、オリジンDBの負荷を軽減します。
  3. Redisクラスタのスケーリング：キーでシャーディング。クライアントサイドハッシュを有効にします。
  4. キャッシュミス時のリクエスト合算/シングルフライト：同じキーに対する複数のリクエストが同時にミスした場合、1つのリクエストがキャッシュをフィルし、他は短時間待機します。
  5. 極端なケースでは、キャッシュ内の「ホットキーレプリケーション」（同じキーを複数のシャードに保存）を許可するか、専用の「ホットキャッシュ」層を使用します。

書き込みのスケーリング

• 書き込みは控えめです。一意性と冪等性を確保するために条件付き書き込みを使用します。
• ボットからの書き込み増幅を避けるために、レート制限と不正防止を使用します。

E) 信頼性と耐障害性（99.9%の稼働時間）

マルチリージョン

• 少なくとも2つのリージョンでアクティブ-アクティブ。
• GSLBヘルスチェックは、正常でないリージョンからトラフィックをルーティングします。

ステートレスサービス

• APIサーバーはステートレスです。水平にスケールし、複数のAZにデプロイします。

キャッシュ層

• Redis/Memcachedを、各シャードにレプリカを持つシャーディングクラスタとしてデプロイします（またはレプリカを持つRedis Cluster）。
• キャッシュが失敗した場合：システムはDBにフォールバックします。レイテンシは増加しますが、機能は維持されます。
• キャッシュ障害がスレッディングハー ドを引き起こす場合、サーキットブレーカーと適応型レート制限でDBを保護します。

データベースのレプリケーションとフェイルオーバー

• DynamoDBオプション：
  • マルチリージョンアクティブ-アクティブレプリケーションにグローバルテーブルを使用します。
  • オンデマンドまたはプロビジョニング済みキャパシティを自動スケーリングで設定します。
• Cassandra/Scyllaオプション：
  • リージョン内のマルチAZレプリケーション（RF=3）。
  • NetworkTopologyStrategyを介したマルチリージョンレプリケーション。レイテンシを低く保つために整合性（例：読み書きにはLOCAL_QUORUM）を調整します。
• 障害モード：
  • 単一ノード障害：レプリカの読み書きは継続します。
  • AZ障害：残りのAZがトラフィックを提供します（AZ間のRF）。
  • リージョン障害：GSLBが正常なリージョンに切り替わります。データはレプリケートされたストアを介して利用可能です。

データの耐久性

• オブジェクトストレージ（S3/GCS）への定期的なバックアップ/スナップショットとポイントインタイムリカバリ。
• ディザスタリカバリ訓練と復元テスト。

デプロイメントの安全性

• ローリングデプロイメント+カナリアリリース。
• 機能フラグ。
• エラーバジェットの消費に対する自動ロールバック。

運用管理

• SLI：リダイレクトp95レイテンシ、キャッシュヒット率、DB p95、エラー率、レプリケーションラグ。
• SLO：99.9%の可用性。段階的な低下（例：分析書き込みの一時的な無効化）を考慮した設計。

F) 主要なトレードオフ

1. コードの短さと分散生成

• トレードオフ：中央集権的なカウンターは非常に短いコード（初期はしばしば6〜8文字）を生成できますが、調整を追加し、マルチリージョンでは難しくなります。
• 選択：分散型Snowflake風ID + base62（10〜11文字）を使用して、スケーラビリティ、一意性、マルチリージョン互換性を確保し、レイテンシ/可用性要件を満たします。

2. 強整合性と低レイテンシ/高可用性

• トレードオフ：グローバルでの強く一貫した読み取りは、レイテンシを増加させ、パーティション中の可用性を低下させます。
• 選択：リダイレクトルックアップにはローカルクォーラム/リージョンローカル整合性（高速）を使用し、マルチリージョンレプリケーションを行います。作成操作については、条件付き書き込みで一意性を確保し、リージョン間での最終的な伝播を受け入れます。リダイレクトは、権威あるマッピングが少なくとも1つのリージョンに存在し、迅速にレプリケートされるため、正しいままです。

3. 積極的なキャッシュと迅速な無効化/不正対応

• トレードオフ：長いキャッシュTTLはレイテンシを改善し、DB負荷を軽減しますが、悪意のあるリンクを即座に無効化することをより困難にします。
• 選択：適度なTTL + パージメカニズム、キャッシュされた値でのステータスチェック、CDNの短いTTL。高優先度で無効化されたステータスをキャッシュすることにより、「キルスイッチ」を許可します。

要約

• エッジルーティング+ヘビーキャッシュを使用して、リダイレクトを50ms p95未満に保ちます。
• スケーラブルなコード生成のために、分散一意ID生成（Snowflake + 置換）を使用します。
• マッピングは、短縮コードによるシャーディングとマルチリージョンフェイルオーバーを備えたレプリケートされたKVストアに格納します。
• マルチAZ + マルチリージョン、ステートレスサービス、レプリケートされたストレージ、および段階的な低下パスにより、99.9%の稼働時間を維持します。