グローバルなURL短縮サービスを設計する

1. 主要コンポーネントとデータフローを含むハイレベルアーキテクチャ:

• ユーザー/クライアント: サービスと対話します。
• APIゲートウェイ/ロードバランサー: すべてのリクエストのエントリポイントであり、ルーティング、レート制限、SSL終端を処理します。
• 短縮サービス: 短縮URLの作成、更新、管理を担当するマイクロサービスです。リンクメタデータDBおよびキャッシュと対話します。
• リダイレクトサービス: 高スループット、低遅延のリダイレクトに最適化されたマイクロサービスです。主にキャッシュから読み取り、リンクメタデータDBをフォールバックとして使用します。クリックイベントをメッセージキューに発行します。
• 分散キャッシュ (例: Redis Cluster): 高速なリダイレクトのために、ホットな short_code から long_url へのマッピングを格納します。
• リンクメタデータデータベース (例: Cassandra/DynamoDB): すべての短縮URLメタデータ (short_code、long_url、有効期限、ステータスなど) を格納します。
• メッセージキュー (例: Kafka/Kinesis): リダイレクトサービスからの生のクリックイベントを取り込み、非同期処理を行います。
• 分析プロセッサ: メッセージキューから生のクリックイベントを消費し、集計を実行して分析データベースに格納します。
• 分析データベース (例: ClickHouse/Redshift): クエリのために集計されたクリックデータを格納します。
• データレイク (例: S3): 長期保存と詳細な分析のために、生のクリックイベントを格納します。
• 不正検出サービス: 短縮サービスと統合し、新しいURLの悪意のあるコンテンツをスキャンします。
• 監視とアラート: すべてのコンポーネントのオブザーバビリティ。

データフロー:

• 短縮リクエスト: ユーザー -> APIゲートウェイ -> 短縮サービス -> 不正検出 -> リンクメタデータDB (書き込み) -> キャッシュ (書き込み)。
• リダイレクトリクエスト: ユーザー -> CDN (オプション) -> ロードバランサー -> リダイレクトサービス -> キャッシュ (読み取り) -> リンクメタデータDB (フォールバック読み取り) -> メッセージキュー (クリックイベント書き込み) -> 長URLへのリダイレクト。
• 分析処理: メッセージキュー -> 分析プロセッサ -> 分析DB (集計済み書き込み) / データレイク (生データ書き込み)。

2. リンクメタデータ、リダイレクトパス、分析イベントのストレージ選択とその根拠:

• リンクメタデータ (短縮URL -> 長URL、有効期限、ステータスなど):
  • 選択: グローバルに分散されたNoSQLデータベース (例: Apache CassandraまたはAWS DynamoDB Global Tables)。
  • 根拠: 高い読み書きスループット (1日あたり15億リクエスト、1ヶ月あたり1億2000万書き込み) を処理し、複数のリージョンからの低遅延アクセスを提供し、高可用性を実現し、水平スケーリングが可能です。効率的なルックアップのために、プライマリキーは short_code になります。
• リダイレクトパス (高速ルックアップのための短縮コード -> 長URLマッピング):
  • 選択: 分散インメモリキャッシュ (例: Redis Cluster)。
  • 根拠: リダイレクトのp95遅延を80ms未満に抑えるために不可欠です。プライマリデータベースへの負荷を大幅に軽減します。ホットリンクは、適切なTTL (例: リンクの有効期限またはLRUポリシーに基づく) で積極的にキャッシュされます。ローカルアクセス用にリージョン間でレプリケートされます。
• 分析イベント (生のクリック):
  • 選択: 取り込みにはメッセージキュー (例: Apache KafkaまたはAWS Kinesis)、その後ストレージにはデータレイク (例: AWS S3)。
  • 根拠: Kafka/Kinesisは、リダイレクトパスと分析処理を分離することで、膨大な書き込み量 (1日あたり15億イベント) を処理し、リダイレクトの高速性を維持します。S3は、生のイベントに対してコスト効率が高く、耐久性の高いストレージを提供し、90日間保持され、バッチ処理と履歴分析に適しています。
• 集計済み分析:
  • 選択: カラムナ分析データベース (例: ClickHouseまたはAWS Redshift)。
  • 根拠: 大規模データセットに対する複雑な分析クエリと集計に最適化されています。運用データベースに影響を与えることなく、集計データ (例: 日次クリック数、ブラウザ分布) を15分以内に高速にクエリできます。2年間保持されます。

3. 短縮コードの生成戦略、衝突回避とカスタムエイリアスの処理方法を含む:

• 短縮コード生成戦略:
  1. 分散ID生成: 分散型の一意IDジェネレータ (例: SnowflakeライクなIDまたはUUID v7を生成するカスタムサービス) を使用して、グローバルに一意で単調増加する64ビット整数IDを生成します。
  2. Base62エンコーディング: この一意の整数IDをコンパクトなBase62文字列 (0-9、a-z、A-Z) にエンコードします。64ビットIDは、6〜10文字の短いコードを生成でき、広大な名前空間を提供します (例: 6文字で62^6 ≈ 560億の一意のコードを提供し、1ヶ月あたり1億2000万件を長年カバーするのに十分です)。
• 衝突回避:
  • IDベース: 基盤となるIDが一意であることが保証されているため、Base62エンコードされた短縮コードも一意になり、システム生成コードの衝突を本質的に回避します。
  • ランダムフォールバック (堅牢性のため): セカンダリオプションまたは特定のユースケースとして、ランダム文字列ジェネレータを使用できます。この場合、候補の短縮コードを生成し、リンクメタデータDBとキャッシュでクイックルックアップを実行します。衝突が検出された場合は、再生成して数回試行します。これは効率は低いですが、フォールバックを提供します。
• カスタムエイリアス:
  1. ユーザーからの送信: ユーザーは long_url と共に希望する custom_alias を送信します。
  2. 検証: 短縮サービスは custom_alias を検証します (例: 長さ、許可される文字、予約語でない、ブラックリストに載っていない)。
  3. 一意性チェック: 作成前に、短縮サービスはリンクメタデータDBでルックアップを実行し、custom_alias が既に存在するかどうかを確認します。このチェックは強く一貫している必要があります。
  4. 予約: custom_alias が利用可能な場合、リンクメタデータDBに short_code として直接格納されます。利用できない場合は、リクエストは拒否され、ユーザーは別のエイリアスを選択するように促されます。

4. キャッシュ、パーティショニング/シャーディング、マルチリージョン考慮事項を含む、グローバルトラフィックのスケーリング計画:

• キャッシュ:
  • CDN: 短縮リンクの静的アセットおよびDNS解決にコンテンツ配信ネットワーク (CDN) を利用し、ユーザーを最も近いエッジロケーションに誘導します。
  • 分散キャッシュ (Redis Cluster): 主要な地理的リージョンごとにRedisクラスタをデプロイします。これらのクラスタは、最も頻繁にアクセスされる short_code から long_url へのマッピングを格納します。キャッシュエントリには、リンクの有効期限またはLRUポリシーに合わせたTTLがあります。これにより、1日あたり15億件のリダイレクトに対するデータベースの負荷が大幅に軽減されます。
• パーティショニング/シャーディング:
  • リンクメタデータデータベース: short_code (例: 短縮コードのハッシュを使用) によってデータベースをシャーディングします。これにより、データとクエリの負荷が複数のデータベースノードに分散されます。各シャードは、リージョン内の高可用性のためにレプリケートされます。
  • 分析データベース: 生のクリックイベントを時間 (例: 日次または時間ごとのパーティション) でパーティション化し、集計データを short_code と date でパーティション化して、クエリパフォーマンスとデータ保持ポリシーを最適化します。
• マルチリージョン考慮事項:
  • リダイレクトのためのアクティブ-アクティブ: リダイレクトサービス、分散キャッシュ、リンクメタデータデータベース (グローバルレプリケーション付き) を複数の地理的リージョン (例: 北米、ヨーロッパ、アジア太平洋) にデプロイします。Geo-DNSはユーザーを最も近いリージョンにルーティングし、グローバルな低遅延リダイレクトを保証します。
  • 短縮サービスのアクティブ-パッシブ/アクティブ-アクティブ: 短縮サービスは、書き込みの一貫性要件と複雑さに応じて、アクティブ-パッシブ (1つのリージョンにプライマリ、他にはレプリカ) またはアクティブ-アクティブでデプロイできます。書き込みは読み取りよりも頻度が低いため、一貫性を単純化できるのであれば、作成時の遅延が若干高くても許容できます。
  • グローバルデータベースレプリケーション: リンクメタデータデータベース (例: DynamoDB Global TablesまたはCassandraのマルチデータセンターレプリケーション) は、データがリージョン間でレプリケートされることを保証し、リダイレクトのためのローカル読み取りと災害復旧機能を提供します。
  • 分析取り込み: 地域ごとのメッセージキュー (Kafka/Kinesis) はローカルでクリックイベントを集約し、それらは中央のデータレイク/分析データベースにストリーミングされるか、集約分析のためにリージョン間でレプリケートされます。

5. フェイルオーバー、ホットキー、災害復旧、および低下モードの動作をカバーする信頼性計画:

• フェイルオーバー:
  • 冗長性: すべてのサービス (短縮、リダイレクト、分析プロセッサ) は、ロードバランサーの後ろで、各リージョン内の複数のアベイラビリティゾーンにわたってN+1冗長性でデプロイされます。
  • データベースレプリケーション: リンクメタデータDBと分析DBは、アベイラビリティゾーンおよびリージョン間で同期/非同期レプリケーションを使用し、データの耐久性と可用性を保証します。
  • サーキットブレーカーとリトライ: マイクロサービスにサーキットブレーカーと指数バックオフ/リトライメカニズムを実装し、カスケード障害を防ぎ、一時的な問題を適切に処理します。
  • 監視とアラート: システムヘルス、パフォーマンスメトリクス、エラーレートの包括的な監視と、重大な問題に対する自動アラート。
• ホットキー:
  • キャッシュシャーディング: 分散キャッシュ (Redis Cluster) はシャーディングされており、ホットキーを複数のノードに分散して、単一ノードがボトルネックになるのを防ぎます。
  • キャッシュウォーミング: 予想されるホットリンク (例: 大規模キャンペーンから) は、キャッシュに事前にロードします。
  • レート制限: APIゲートウェイとリダイレクトサービスレベルでレート制限を実装し、バックエンドシステムを突然のトラフィックスパイクや特定のリンクを標的とした悪用から保護します。
• 災害復旧:
  • マルチリージョンアクティブ-アクティブ: リダイレクトサービスのアクティブ-アクティブデプロイメントとグローバルにレプリケートされたリンクメタデータDBは、リダイレクトのための本質的な災害復旧を提供します。1つのリージョンが失敗した場合、トラフィックはGeo-DNS経由で自動的に別の正常なリージョンにルーティングされます。
  • データバックアップ: すべての重要なデータベース (リンクメタデータ、集計済み分析) の定期的な自動バックアップを、地理的に分離された耐久性のあるストレージ (例: S3) に保存します。
  • 復旧プレイブック: フェイルオーバー、データ復元、および完全なシステム復旧のための文書化され、定期的にテストされた手順。
• 低下モードの動作:
  • 分析の低下: メッセージキューまたは分析プロセッサに問題が発生した場合、生のクリックイベントは一時的にバッファリングされるか、極端な場合にはドロップされる可能性があります (アラート付き)。リダイレクトは中断なく機能し続ける必要があります。
  • キャッシュミス/障害: 分散キャッシュが失敗したか、高遅延を経験した場合、リダイレクトサービスはリンクメタデータデータベースのクエリにフォールバックします。これによりリダイレクト遅延は増加しますが、サービス継続性は保証されます。サーキットブレーカーはデータベースの過負荷を防ぎます。
  • 短縮サービス低下: 短縮サービスに障害が発生した場合でも、リダイレクトは影響を受けません。ユーザーはリンク作成の遅延や作成APIの一時的な利用不可を経験する可能性がありますが、既存のリンクは引き続き機能します。

6. 主要なAPIとコアデータモデル:

• 主要API:

  • POST /api/v1/shorten
    • 説明: 新しい短縮URLを作成します。
    • リクエストボディ: {"long_url": "string", "custom_alias": "string (optional)", "expiration_date": "ISO 8601 timestamp (optional)", "user_id": "string (optional)"}
    • レスポンス: {"short_url": "string", "long_url": "string", "expires_at": "ISO 8601 timestamp (optional)"}
  • GET /{short_code}
    • 説明: 元の長URLにリダイレクトします。
    • レスポンス: HTTP 301/302 リダイレクトを long_url へ。
  • GET /api/v1/links/{short_code}/analytics
    • 説明: 特定の短縮URLのクリック分析を取得します。
    • レスポンス: {"short_code": "string", "total_clicks": "integer", "daily_clicks": [{"date": "YYYY-MM-DD", "count": "integer"}], "browser_distribution": {"Chrome": 100, "Firefox": 50}, "country_distribution": {"US": 70, "DE": 30}}
  • PUT /api/v1/links/{short_code}/status
    • 説明: 短縮URLのステータスを更新します (例: 無効化)。
    • リクエストボディ: {"status": "enum (active, disabled)"}
    • レスポンス: {"short_code": "string", "status": "string"}

• コアデータモデル:

  • リンクメタデータ (リンクメタデータDBに格納):

    {
        "short_code": "string (Primary Key)",
        "long_url": "string",
        "user_id": "string (Foreign Key, optional)",
        "created_at": "timestamp",
        "expires_at": "timestamp (optional)",
        "status": "enum (active, disabled, expired)",
        "is_custom_alias": "boolean",
        "last_accessed_at": "timestamp (for LRU/cleanup)"
    }
    

  • クリックイベント (生 - データレイクに格納、メッセージキュー経由で取り込み):

    {
        "event_id": "UUID (Primary Key)",
        "short_code": "string",
        "timestamp": "timestamp",
        "ip_address_hash": "string (anonymized/hashed)",
        "user_agent": "string",
        "referrer": "string (optional)",
        "country": "string (derived from IP)",
        "city": "string (derived from IP)"
    }
    

  • 集計済み分析 (分析DBに格納):

    {
        "short_code": "string (Partition Key)",
        "date": "date (Sort Key)",
        "total_clicks": "integer",
        "browser_counts": "map<string, integer>",
        "os_counts": "map<string, integer>",
        "country_counts": "map<string, integer>",
        "referrer_counts": "map<string, integer>"
    }
    

7. 悪用緩和とセキュリティに関する考慮事項:

• 悪意のあるリンク検出:
  • ブラックリスト: 既知の悪意のあるドメイン、フィッシングサイト、スパムURLの継続的に更新されるブラックリストを維持します。新しい long_url の送信は、このリストに対してチェックされます。
  • リアルタイムスキャン: リンク作成プロセス中に、サードパーティの安全ブラウジングAPI (例: Google Safe Browsing API、VirusTotal) と統合し、long_url をスキャンして既知の脅威を検出します。
  • ヒューリスティクス: 疑わしいURLパターン、過剰なリダイレクト、または悪意のあるコンテンツに関連する一般的なキーワードを検出するアルゴリズムを実装します。
• スパムと悪用防止:
  • レート制限: 自動化されたスパム送信を防ぐために、IPアドレスごとおよび/または認証済みユーザーごとの POST /shorten APIに厳格なレート制限を適用します。
  • CAPTCHA/reCAPTCHA: 未認証のリンク作成に対しては、ボットを阻止するためにCAPTCHAチャレンジを実装します。
  • ユーザーアカウント: カスタムエイリアス、より高い作成制限、および分析へのアクセスには、ユーザー認証が必要です。これにより、アカウンタビリティが提供されます。
  • 報告メカニズム: ユーザーが悪意のある短縮リンクを報告するための明確な方法を提供します。報告されたリンクはレビューされ、悪意があると判断された場合は無効化されます。
  • リンク無効化: ユーザーが自身のリンクを手動で無効化できるようにします。システムは、悪用検出によってフラグが付けられたリンクや、他者によって報告されたリンクを自動的に無効化することもできます。
• セキュリティに関する考慮事項:
  • HTTPSの必須化: すべてのAPIエンドポイントとリダイレクトでHTTPSを強制し、転送中のデータの暗号化を保証します。
  • 入力検証とサニタイズ: すべてのユーザー提供入力 (long_url、custom_alias) を厳密に検証およびサニタイズし、XSS、SQLインジェクション、パス・トラバーサルなどの一般的なWeb脆弱性を防ぎます。
  • アクセス制御: 内部管理ツールおよびユーザー固有のリンク管理機能に対して、ロールベースのアクセス制御 (RBAC) を実装します。
  • データ匿名化: クリック分析データ内のIPアドレスやその他の個人識別情報 (PII) を匿名化またはハッシュ化し、プライバシー規制 (例: GDPR、CCPA) に準拠します。
  • 定期的なセキュリティ監査: 定期的なセキュリティ監査、侵入テスト、脆弱性スキャンを実施し、潜在的な弱点を特定して修正します。
  • DDoS対策: エッジでクラウドプロバイダーのDDoS軽減サービス (例: AWS Shield、Cloudflare) を利用します。

8. 下した主なトレードオフとその理由:

• リダイレクトにおける一貫性 vs 可用性/遅延:
  • トレードオフ: リダイレクトの極端な可用性と低遅延を、リンクメタデータに対する強い一貫性よりも優先しました。エイリアスの一意性には強い一貫性が必要ですが、新しく作成または更新されたリンクがすべてのキャッシュとデータベースレプリカにグローバルに一貫して伝播するまで数ミリ秒かかる場合があります。
  • 理由: リダイレクトは最も重要で高負荷な操作です。新しいリンクがグローバルにリダイレクト可能になるまでのわずかな遅延は許容できますが、リダイレクトにおける大幅な遅延やダウンタイムは、ユーザーエクスペリエンスとサービス信頼性目標に深刻な影響を与えます。
• コスト vs パフォーマンス/スケーラビリティ:
  • トレードオフ: マルチリージョン、グローバルにレプリケートされたアーキテクチャを採用し、広範なキャッシュと特殊なデータベースを使用しました。これは、単一リージョン、シンプルなセットアップと比較して、本質的にインフラストラクチャコストが高くなります。
  • 理由: スケールに関する仮定 (1日あたり15億リダイレクト、グローバル分散) とパフォーマンス目標 (p95 < 80ms) は、このレベルの分散インフラストラクチャを必要とします。コモディティクラウドサービスやオープンソースコンポーネント (Kafka、Redisなど) を可能な限り選択することで、パフォーマンスとスケーラビリティの要件を満たしながらコストを最適化しました。
• データ粒度 vs ストレージコスト/クエリパフォーマンス (分析用):
  • トレードオフ: 生のクリックイベントは、より短い期間 (90日間) コスト効率の高いデータレイクに保持し、集計データは、より長い期間 (2年間) パフォーマンスは高いが潜在的に高価な分析データベースに格納します。
  • 理由: 1日あたり15億件の生イベントを2年間保存することは、リアルタイムクエリにとって費用対効果が悪く、遅すぎます。このアプローチは、詳細な履歴分析 (S3の生データ経由) の必要性と、予算制約内での高速な集計インサイト (分析DB経由) の要件のバランスを取ります。
• 短縮コードの長さ vs 衝突確率/推測可能性:
  • トレードオフ: コンパクトな短縮コード (例: 6〜10文字) のためにBase62エンコーディングを選択しました。純粋にランダムな6文字のコードには理論的な衝突リスクがありますが、IDベースの生成戦略はシステム生成コードの衝突を排除します。カスタムエイリアスの場合は、明示的に衝突検出を行います。
  • 理由: コンパクトさはURL短縮器のコア機能です。選択された戦略は、システム生成コードの実用的な衝突を回避するのに十分な広大な名前空間を提供し、短縮の目的を損なうような過度に長く複雑な短縮コードを必要とせずに、カスタムエイリアスの衝突を適切に処理します。
• 複雑さ vs 機能セット:
  • トレードオフ: 短縮、リダイレクト、基本的な分析のための堅牢なコアシステムに焦点を当て、より高度な機能 (例: A/Bテスト、詳細なユーザー管理、複雑なレポート) は反復的な追加機能と見なしました。
  • 理由: コア機能の積極的なパフォーマンスと可用性の目標を、合理的な設計スコープ内で達成するためです。最初から多くの機能を追加すると、複雑さ、潜在的な障害点、開発時間が増加し、コアサービスの安定性を損なう可能性があります。

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 高レベルアーキテクチャとデータフロー
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

コンポーネント

[クライアント]
│
▼
[グローバル Anycast DNS / GeoDNS]
│
▼
[リージョナル エッジ PoP — CDN / Nginx リバースプロキシ]
│ （キャッシュヒット → 即時に 301/302 レスポンス）
│ （キャッシュミス → オリジンへ転送）
▼
[リージョナル API Gateway（レート制限、認証、TLS終端）]
│
├──► [リダイレクトサービス] ──► [Redis Cluster（ホットキーキャッシュ）]
│ │ miss
│ ▼
│ [リンクメタデータストア（Cassandra）]
│
└──► [作成サービス] ──► [IDジェネレーター（Snowflake風）]
│ │
├──► [リンクメタデータストア（Cassandra）]
└──► [カスタムエイリアスチェッカー（Redis SET + Cassandra）]

[リダイレクトサービス] ──► [クリックイベントパブリッシャー（Kafka）]
│
▼
[ストリームプロセッサ（Flink / Spark Streaming）]
│
┌───────────┴────────────┐
▼ ▼
[生イベントストア [集計済み分析
（S3 + Parquet, 90日）] ストア（ClickHouse, 2年）]

データフロー — リダイレクト（クリティカルパス）

1. ユーザーが https://sho.rt/aB3xYz を訪問する
2. GeoDNS が最寄りのリージョナル PoP にルーティングする。
3. エッジ CDN がキー "aB3xYz" のローカルキャッシュを確認する。
   • HIT: HTTP 301（キャッシュ可能）または 302（分析のため非キャッシュ可能）を即時返す。分析パイプラインに非同期ビーコンを送信する。
   • MISS: リージョナルのリダイレクトサービスへ転送する。
4. リダイレクトサービスがリージョナル Redis クラスターを確認する。
   • HIT: 宛先 URL を返し、Kafka イベントを発行し、302 を返す。
   • MISS: Cassandra（最寄りレプリカ）から読み取り、Redis を埋め、302 を返す。
5. Kafka コンシューマー（Flink）が数秒以内にクリックイベントを処理する。集計結果は約5分以内に ClickHouse に入る。最悪ケースは15分。

データフロー — 作成

1. クライアントが API Gateway 経由で作成サービスに POST する。
2. レート制限と認証チェックが適用される。
3. カスタムエイリアスの場合: Redis SET と Cassandra で衝突を確認し、使用済みなら拒否する。
4. 自動生成の場合: Snowflake ID → Base62 エンコード → 7文字コード。
5. Cassandra に書き込む（クォーラム書き込み、RF=3）。
6. 必要に応じて Redis キャッシュを即時ウォームアップする。
7. 短縮 URL をクライアントに返す。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. ストレージの選択
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

リンクメタデータストア — Apache Cassandra

根拠:

• 月間1.2億件の新規リンク ≈ 平均毎秒46リンク、ピーク時は10〜20倍。Cassandra は調整可能な整合性で高い書き込みスループットを処理できる。
• 主なアクセスパターンは short_code による単一キー参照であり、Cassandra のパーティションキーモデルが理想的である。
• マルチデータセンターレプリケーション（リージョンごとに RF=3、3リージョン）により、単一障害点なしで 99.99% 以上の可用性を実現する。
• 水平スケールする。高コストなクロスシャードトランザクションは不要。
• TTL サポートはネイティブであり、期限切れリンクは自動的に tombstone 化される。
• コスト: 汎用ノード、ライセンス費用なし。

スキーマ（簡略化）:
テーブル: links
short_code TEXT PRIMARY KEY
long_url TEXT
owner_id UUID
created_at TIMESTAMP
expires_at TIMESTAMP （nullable; Cassandra TTL を行に設定）
is_disabled BOOLEAN
is_custom BOOLEAN

検討した代替案: DynamoDB — 良いが、この規模ではベンダーロックインとコストが課題。PostgreSQL — この書き込み量に対して、相当なシャーディングの複雑性なしでは水平スケールしない。

リダイレクトパスキャッシュ — Redis Cluster（リージョンごと）

• short_code → {long_url, is_disabled, expires_at} をハッシュとして格納する。
• キャッシュエントリの TTL = min(link expiry, 24時間) とし、古いエントリを避ける。
• 各リージョンで 6ノード（3 primary + 3 replica）のクラスターモード。リージョンあたり約50 GB RAM でホットなワーキングセット（上位約1000万リンク）をカバーする。
• エビクションポリシー: allkeys-lru。
• コストの正当性: Redis のヒット率は >95% を想定。各キャッシュミスは Cassandra 読み取り（約5〜10 ms）に加えレイテンシを伴う。リージョンあたり毎秒17,000リダイレクトでは、Cassandra 読み取り回避が p95 目標にとって重要である。

分析 — 生イベント: Apache Kafka + S3（Parquet）

• Kafka（リージョンごとに3ブローカークラスター、トピック: click_events、64パーティション）がクリックイベントを耐久的にバッファする。
• Flink コンシューマーが Kafka から読み取り、イベントを拡張し（geo-IP、user-agent 解析）、5分ごとに Parquet ファイルを S3 に書き込む。
• S3 ライフサイクルポリシーにより、生ファイルは90日後に削除される。
• コスト: S3 は安価（約$0.023/GB/月）。15億イベント/日 × 約200バイト ≈ 300 GB/日 → 約27 TB/90日 → ストレージ費用は約$620/月。

分析 — 集計済み: ClickHouse

• Flink は、事前集計済み行（short_code ごと、時間ごと、国/デバイスごと）も ClickHouse に書き込む。
• ClickHouse のカラムナーストレージとベクトル化実行により、時系列集計クエリが高速になる。
• リージョンごとにレプリケーション係数2、保存期間2年。
• 推定サイズ: 集計済みは年間約1 TB → 十分に扱いやすい。
• 検討した代替案: Apache Druid — これも優秀だが運用負荷が高い。このユースケースでは ClickHouse の方が単純である。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. ショートコード生成戦略
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

自動生成コード

戦略: Snowflake風分散 ID → Base62 エンコード

1. 各作成サービスインスタンスは一意の worker ID を保持する（起動時に ZooKeeper または単純な DB テーブル経由で割り当て）。
2. 64ビット Snowflake ID を生成する: [41ビット timestamp ms | 10ビット worker ID | 12ビット sequence]。
3. ID を Base62 エンコードする（文字: 0-9, a-z, A-Z）。
4. 64ビット整数は最大11文字の Base62 になる。実運用では、最初の約10年に生成される ID なら 7〜8文字で十分である。
5. Base62 の7文字 = 62^7 ≈ 3.5兆通り — 1.2億/月 × 12か月 × 10年 = 約144億リンクを大きく上回る。

衝突回避:

• Snowflake ID は構造上グローバルに一意である（worker ID + timestamp + sequence）。2つの worker が同じ worker ID を共有しない限り、衝突は不可能であり、これは協調サービスによって防止される。
• 自動生成コードに対しては「check-then-insert」ループは不要。

推測可能性:

• Base62 にエンコードされた連番の Snowflake ID はランダムではないが、単純に列挙可能というわけでもない（timestamp コンポーネントはミリ秒ごとに変化し、sequence はリセットされる）。さらなる難読化のため、エンコード前に下位32ビットをデプロイメントごとの secret と XOR する。これは暗号学的安全性ではないが、列挙攻撃へのハードルを上げる。
• より強い予測不能性が必要なら: 6バイトの乱数を生成 → Base62 → 8文字コード。Cassandra で衝突確認を行う（この規模では稀）。衝突時は再試行する。62^8 ≈ 218兆の空間に対し、既存リンク14億件では期待衝突率は無視できるほど小さい（<0.001%）。

カスタムエイリアス

1. ユーザーが希望するエイリアスを指定する（例: "my-promo-2025"）。
2. 検証: 3〜50文字、英数字 + ハイフン、予約語なし（api, admin, health など）。
3. Redis SET "custom_aliases" で存在確認を行う（O(1) の bloom-filter 的チェック、または Redis SET）。
4. Cassandra INSERT IF NOT EXISTS（軽量トランザクション / compare-and-set）を試みる。
5. 既に使用済みなら HTTP 409 Conflict を返す。
6. カスタムエイリアスは is_custom=true で保存され、自動生成パスで上書きされることはない。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. グローバルトラフィック向けスケーリング計画
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

トラフィック計算

• 15億リダイレクト/日 = 平均約17,400 req/sec、ピークは3倍 = 約52,000 req/sec と仮定。
• 1.2億作成/月 = 平均約46/sec、ピークは10倍 = 約460/sec。作成はボトルネックではない。

キャッシュレイヤー

レイヤー1 — CDN/エッジ（Cloudflare、Fastly、または PoP 上のセルフホスト Nginx）:

• 期限切れにならず、分析が重要でないリンクについては 301 レスポンスをキャッシュする。Cache-Control: max-age=3600。
• クリック単位の分析が必要なリンク（大半のリンク）には 302 を使用する。これらは CDN キャッシュをバイパスするが、それでも地理的近接性の恩恵は受ける。
• 人気リンクに対する推定 CDN ヒット率: オリジンに到達せずにエッジで処理されるトラフィックは 40〜60%。

レイヤー2 — リージョナル Redis Cluster:

• オリジンに到達する残りの約40〜60%のリクエストをカバーする。
• 期待される Redis ヒット率: オリジン到達リクエストの >95%。
• 正味の Cassandra 読み取り: 17,400 req/sec の <5% ≈ 約870 req/sec — Cassandra の容量内に十分収まる。

パーティショニング / シャーディング

Cassandra:

• パーティションキー = short_code。Cassandra のコンシステントハッシュにより、パーティションはノード間に均等に分散される。
• 手動シャーディングは不要。ノード追加で自動的にリバランスされる。
• ホットスポット回避: short_code は高カーディナリティであり、単一パーティションが不釣り合いに大きくなることはない。

Redis:

• Redis Cluster はハッシュスロット（16,384スロット）をノード間に分散して使用する。short_code のハッシュは均等にマップされる。
• ホットキー（バイラルリンク）は別途処理する — 信頼性セクションを参照。

Kafka:

• トピックごとに64パーティション。パーティションキー = short_code。これにより、リンクごとの順序付き処理を保ちつつ、コンシューマー間で並列化する。

マルチリージョンデプロイメント

リージョン: US-East、EU-West、AP-Southeast（99.99% 可用性のため最低3リージョン）。

Cassandra:

• マルチデータセンターレプリケーション: データセンターごとに RF=3、3データセンター。
• 書き込み: 作成では LOCAL_QUORUM（ローカル DC の3ノード中2ノード） — リージョン内で高速かつ一貫。
• 読み取り: リダイレクトでは LOCAL_QUORUM — 最寄り DC から読み取る。
• クロス DC レプリケーションは非同期。リージョン間の結果整合性はリダイレクトに対して許容可能（新規作成リンクのグローバル伝播に <1秒かかる可能性がある — 許容範囲）。

Redis:

• リージョンごとに独立したクラスター。クロスリージョンレプリケーションはしない（コストと複雑性に見合わない）。
• キャッシュミス時はローカル Cassandra レプリカにフォールバックする。

DNS:

• GeoDNS がユーザーを最寄りのリージョナル API Gateway にルーティングする。
• リダイレクトドメインに対する Anycast IP により、最小レイテンシのルーティングを保証する。

作成サービス:

• ステートレス。各リージョンにデプロイする。worker ID はグローバルに一意である（軽量なグローバル ZooKeeper、またはリージョンプレフィックス付きの単純な DB テーブルで調整）。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. 信頼性計画
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

障害シナリオと緩和策

Redis ノード障害:

• Redis Cluster はレプリカを自動昇格する（通常 <30秒）。
• フェイルオーバー中、リクエストは Cassandra にフォールスルーする。Cassandra はそのバーストを処理できる（通常は約870 req/sec、<30秒の間は約17,000 req/sec までバーストしても、適切なプロビジョニングなら対応可能 — 予想ピーク読み取り負荷の2倍で Cassandra をサイジングする）。
• リダイレクトサービスのサーキットブレーカー: Redis が完全に利用不可なら、キャッシュをバイパスして Cassandra から直接読む。

Cassandra ノード障害:

• RF=3 かつ LOCAL_QUORUM は、1ノード障害なら透過的である。2ノード障害では LOCAL_ONE に劣化する（依然として機能するが、整合性はやや低下）。
• Cassandra の gossip プロトコルは数秒以内に障害を検出し、hinted handoff により書き込み消失を防ぐ。

リージョン全体の障害:

• GeoDNS のヘルスチェックが 30〜60秒以内にリージョンの利用不可を検知し、次に近いリージョンへトラフィックを再ルーティングする。
• Cassandra のクロス DC レプリケーションにより、生存リージョンでデータが利用可能である。
• 目標: RTO < 2分、RPO = 0（リンクメタデータについて。DC 内では同期クォーラム書き込み、クロス DC は非同期レプリケーションのため、ごく最近の作成では <1秒の潜在的データ損失があり得る — 許容範囲）。

ホットキー（バイラルリンク）

問題: 1つのバイラル短縮コードが毎秒数百万リクエストを生成し、単一の Redis スロットまたは Cassandra パーティションを圧倒する可能性がある。

緩和策:

1. 各リダイレクトサービスインスタンス内のローカル in-process キャッシュ（例: Caffeine、10,000エントリの LRU、TTL 30秒）。これにより、単一ポッド内の繰り返しリクエストを Redis に到達させず吸収する。
2. Redis キーレプリケーション: 検出されたホットキー（Redis MONITOR またはスライディングウィンドウカウンターで監視）について、サフィックス付きで複数の Redis スロットにキーを複製する（例: aB3xYz:0, aB3xYz:1 ... aB3xYz:N）。読み取り時にはランダムに1つ選択する。
3. CDN キャッシュ: 非分析リンクについては、短い TTL（60秒）でホットリンクを CDN にプッシュし、エッジでトラフィックを吸収する。
4. Cassandra: ホットキーは問題ではない。Redis がホットリンクの読み取りの >99% を吸収するためである。

災害復旧

• Cassandra: 毎日 S3 にスナップショットを取得（nodetool snapshot）。クロスリージョンレプリケーションがライブ DR を提供する。
• Redis: Redis 永続化（AOF + RDB）をローカルディスクへ。Redis はキャッシュであり、喪失は許容可能（Cassandra にフォールバック）。クロスリージョン Redis レプリケーションは不要。
• Kafka: リージョン内でレプリケーション係数3。クロスリージョン Kafka MirrorMaker 2 が分析 DR のためクリックイベントをセカンダリリージョンへ複製する。
• ClickHouse: レプリケートテーブル（ReplicatedMergeTree）。毎日 S3 にバックアップ。

劣化モード時の挙動

• 分析パイプライン（Kafka/Flink）がダウンしている場合: リダイレクトは影響なく継続する。クリックイベントは Kafka にバッファされる（7日保持）。パイプライン復旧時に分析が追いつく。分析の SLA（15分鮮度）は一時的に満たされない可能性がある — 許容範囲。
• 作成サービスがダウンしている場合: 既存のリダイレクトは継続動作する（読み取りパスは独立している）。新規リンク作成は 503 でグレースフルに失敗する。
• Cassandra が劣化している場合（クォーラム利用不可）: リダイレクトサービスは Redis-only モードにフォールバックする。Redis にないリンクは不正なリダイレクトではなく 503 を返す。これは最終手段の劣化モードである。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. 主要 API とコアデータモデル
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

REST API

POST /api/v1/links
リクエスト:
{
"long_url": "https://example.com/very/long/path?q=1",
"custom_alias": "my-promo", // optional
"expires_at": "2026-01-01T00:00:00Z", // optional ISO-8601
"owner_id": "uuid" // from auth token
}
レスポンス 201:
{
"short_code": "aB3xYz",
"short_url": "https://sho.rt/aB3xYz",
"long_url": "https://example.com/very/long/path?q=1",
"expires_at": "2026-01-01T00:00:00Z",
"created_at": "2025-01-15T10:00:00Z"
}
エラー: 400（無効な URL）、409（エイリアス使用済み）、422（URL がブロック済み/悪意あり）、429（レート制限）

GET /{short_code}
レスポンス 302: Location: <long_url>
レスポンス 301: Location: <long_url> （キャッシュ可能で分析対象外のリンク用）
レスポンス 404: リンクが見つからない
レスポンス 410: リンクが期限切れまたは無効化済み

PATCH /api/v1/links/{short_code}
リクエスト: { "is_disabled": true } // または expires_at を更新
レスポンス 200: 更新済みリンクオブジェクト
認証: 所有者のみ

DELETE /api/v1/links/{short_code}
レスポンス 204
認証: 所有者のみ

GET /api/v1/links/{short_code}/analytics
クエリパラメータ: from, to, granularity（hour/day）, group_by（country/device/referrer）
レスポンス 200:
{
"short_code": "aB3xYz",
"total_clicks": 142300,
"series": [
{ "timestamp": "2025-01-15T10:00:00Z", "clicks": 1200, "country": "US" },
...
]
}

コアデータモデル

links（Cassandra）
short_code TEXT PRIMARY KEY
long_url TEXT NOT NULL
owner_id UUID
created_at TIMESTAMP
expires_at TIMESTAMP （nullable; Cassandra の行 TTL としても設定）
is_disabled BOOLEAN DEFAULT false
is_custom BOOLEAN DEFAULT false
abuse_flags INT DEFAULT 0

click_events（Kafka → S3 Parquet、生）
event_id UUID
short_code TEXT
timestamp TIMESTAMP
ip_hash TEXT （プライバシーのための IP の SHA-256）
country_code TEXT （geo-IP 参照から）
user_agent TEXT
referrer TEXT
region TEXT （配信リージョン）

analytics_hourly（ClickHouse、集計済み）
short_code TEXT
hour DateTime
country_code TEXT
device_type TEXT （mobile/desktop/bot）
referrer_domain TEXT
click_count UInt64
unique_ips UInt64 （HyperLogLog 近似）
PRIMARY KEY (short_code, hour, country_code, device_type)
ENGINE = ReplicatedMergeTree

users（PostgreSQL — 小規模テーブル、ホットパス外）
user_id UUID PRIMARY KEY
email TEXT UNIQUE
api_key_hash TEXT
rate_limit_tier TEXT
created_at TIMESTAMP

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
7. 不正利用対策とセキュリティ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

悪意ある URL の検出

1. 作成時の Safe Browsing API チェック: 保存前に long_url を Google Safe Browsing（または同等のもの）に送信する。フラグ付きなら 422 で拒否する。レイテンシ: 約50〜100 ms、300 ms の作成 SLA 内で許容可能。
2. ドメインブロックリスト: 既知の悪性ドメイン（フィッシング、マルウェア）を Redis SET で保持する。作成時に同期的にチェックする。脅威インテリジェンスフィードから毎時更新する。
3. 非同期再スキャン: バックグラウンドジョブが保存済み URL を更新済みブロックリストに対して定期的に再スキャンする。以前はクリーンだった URL が後からフラグされた場合は、is_disabled=true と abuse_flags=1 を設定する。リダイレクトサービスは毎リクエストで is_disabled を確認する（キャッシュから）。
4. URL 正規化: 難読化を防ぐため、作成時に URL を解析し正規化する（例: URL エンコードのトリック、ドメイン名に対するホモグラフ攻撃 — IDN ホモグラフを確認）。

レート制限

• API Gateway での IP ごとのレート制限: 匿名ユーザーは 10 作成/分、認証済みユーザーは 100/分、ティアごとに設定可能。
• IP/ユーザーごとの Redis ベースのスライディングウィンドウカウンター（トークンバケット）。
• グローバルレート制限: システム全体で 10,000 作成/秒（予想ピーク 460/秒を大きく上回る）。
• リダイレクトパス: レート制限なし（公開）。DDoS 防御は CDN（Cloudflare DDoS 緩和または同等のもの）で実施。

列挙防止

• ショートコードは純粋な連番ではない（Snowflake XOR 難読化またはランダム生成）。
• すべてのショートコードを列挙する API エンドポイントは存在しない。
• 未認証の一括リダイレクト試行（1つの IP から >1,000 個の一意コード/分）は CAPTCHA チャレンジまたは一時的 IP ブロックを発動する。

認証と認可

• 作成および管理エンドポイントには API キーまたは OAuth 2.0 JWT を使用する。
• PATCH/DELETE には所有権検証が必要（owner_id がトークンと一致）。
• 不正利用対策チームがリンクを無効化するための Admin API（別の内部エンドポイント）を提供する。

プライバシー

• IP アドレスは分析に保存する前にハッシュ化される（SHA-256 + デプロイメントごとのソルト）。生の IP は決して永続化しない。
• GDPR: ユーザーは自分のリンクと関連分析の削除を要求できる。Cassandra DELETE + 生イベント用の S3 ライフサイクルタグ。

HTTPS の強制

• すべての短縮 URL は HTTPS のみで提供する。HTTP リクエストはエッジで HTTPS にリダイレクトする。
• 短縮ドメインに HSTS ヘッダーを付与する。

オープンリダイレクト防止

• 明示的に登録された URL にのみリダイレクトする。リダイレクト時にユーザー入力から動的に URL を構築しない。
• 作成時に long_url のスキームを検証する: http:// と https:// のみ許可。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
8. 主要なトレードオフとその正当化
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

トレードオフ 1: リダイレクトにおける 302 vs 301

• 301（恒久）はブラウザに無期限でキャッシュされる → 最低レイテンシ、再訪時のサーバー負荷ゼロ。ただし分析は失われる（ブラウザが二度とサーバーを呼ばない）うえ、キャッシュ済みクライアントに対してリンクの無効化/期限切れが不可能になる。
• 302（一時）は毎回サーバーに到達する → 完全な分析、即時の無効化/期限切れ。再訪時のレイテンシはやや高い。
• 判断: デフォルトではすべてのリンクに 302 を使用する。最大限のキャッシュを明示的に望み、分析を必要としないユーザー向けに 301 をオプトインで提供する。分析を販売するサービスとして、これが正しいデフォルトである。

トレードオフ 2: リンクメタデータに対する Cassandra vs リレーショナル DB

• リレーショナル DB（PostgreSQL）は運用がより単純で、より豊かなクエリをサポートする。しかし、平均毎秒46書き込み（ピーク時10〜20倍）と毎秒17,000読み取りの水平スケーリングは、かなりのシャーディング複雑性なしでは困難である。
• Cassandra は、リッチなクエリ機能（結合なし、限定的なセカンダリインデックス）を犠牲にする代わりに、線形な水平スケーラビリティとマルチ DC レプリケーションを提供する。ホットなクエリは short_code による単一キー参照のみなので、このトレードオフは完全に受容可能である。

トレードオフ 3: リージョン間リンク伝播における結果整合性

• US-East で作成されたリンクは、AP-Southeast ですぐには見えない可能性がある（1秒未満の遅延）。リンクを作成して直ちにグローバル共有したユーザーは、遠隔リージョンで短時間 404 を見るかもしれない。
• 代替案: 同期的なクロスリージョン書き込み（EACH_QUORUM）— グローバル整合性を保証するが、作成に 100〜200 ms のレイテンシを追加し（悪条件下では 300 ms SLA に違反）、可用性も下げる。
• 判断: 結果整合性を受け入れる。1秒未満の伝播ウィンドウは受容可能な UX 上のトレードオフである。文書化する。作成 SLA は満たされる。

トレードオフ 4: Snowflake ID vs ランダムコード

• Snowflake ID は単調増加する → やや予測可能だが、衝突リスクはなく、DB チェック不要で、運用的に単純。
• ランダムコード → より高い予測不能性だが、衝突チェックが必要（稀だがレイテンシと複雑性を追加）。
• 判断: 自動生成コードには Snowflake + XOR 難読化を使用する。単純さ、性能、妥当な予測不能性の良いバランスを提供する。セキュリティ感度の高いユースケース向けには、オプションとしてランダムコードを利用可能にする。

トレードオフ 5: 分離された分析パイプライン vs 同期書き込み

• すべてのリダイレクトで分析を DB に同期書き込みすると、クリティカルパスにレイテンシが追加され、毎秒17,000 req/sec における書き込みボトルネックを生む。
• 非同期 Kafka パイプラインは、分析をリダイレクトパスから完全に分離する。代償は、分析における結果整合性（最大15分）と運用複雑性の増加（Kafka + Flink + ClickHouse）である。
• 判断: 非同期パイプライン。15分の分析鮮度要件は明示的にこれを許容している。リダイレクトパスは高速でなければならず、分析は遅延してよい。

トレードオフ 6: CDN キャッシュの適用範囲

• すべてのリダイレクトを CDN でキャッシュ（301）すれば最大性能を得られるが、分析と無効化/期限切れが壊れる。
• 分析対象外かつ期限切れにならないリンクのみを CDN でキャッシュするのは中間案である。
• 判断: CDN は、明示的にキャッシュ可能とマークされたリンク（301 オプトイン）のみをキャッシュする。その他はすべて 302 と Cache-Control: no-store を使用する。分析が中核機能であるサービスにとって、これが正しいデフォルトである。

トレードオフ 7: 分析における ClickHouse vs Druid vs BigQuery

• BigQuery: フルマネージドで運用不要だが、このイベント量ではクエリレイテンシが高い（秒単位）うえ高コスト。
• Druid: リアルタイム分析には優秀だが、運用が複雑（ZooKeeper、Broker、Historical、MiddleManager ノード）。
• ClickHouse: Druid より運用が簡単で、優れたクエリ性能を持ち、汎用ハードウェアでコスト効率が高く、Kafka との統合も良好。
• 判断: ClickHouse。このユースケースにおいて、運用の単純さ、性能、コストの最良のバランスである。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
容量サマリー（3リージョンデプロイメント）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

リダイレクトサービス: 約30ポッド × 3リージョン（オートスケール、ステートレス）
作成サービス: 約5ポッド × 3リージョン
Cassandra: 9ノード × 3リージョン（DC ごとに RF=3）、各約2 TB SSD
Redis Cluster: 6ノード × 3リージョン、各50 GB RAM
Kafka: 3ブローカー × 3リージョン
Flink: 10タスクマネージャー × 3リージョン
ClickHouse: 4ノード × 3リージョン（レプリケート）
S3: 生イベント 約27 TB/90日 + 集計済み 約3 TB/2年

推定月間インフラコスト: $15,000〜$25,000（汎用クラウド VM）、
主に Cassandra ストレージと Redis メモリが支配的である。CDN のエグレスが、
規模に応じた最大の変動コストである。