グローバルな読み取りトラフィック向けのURL短縮サービスを設計する

## URL短縮サービス設計 ### 1. 高レベルアーキテクチャと主要コンポーネント システムは、高可用性と低遅延を実現するために、複数のアベイラビリティゾーンとリージョンにデプロイされた複数のマイクロサービスで構成されます。 * **APIゲートウェイ:** 受信リクエスト、認証、レート制限を処理し、リクエストを適切なサービスにルーティングします。 * **リンク作成サービス:** 短縮URLの生成、保存、カスタムエイリアスの処理を担当します。ID生成サービスおよびメタデータデータベースと連携します。 * **リンク解決サービス:** リダイレクトリクエストの処理を担当します。キャッシュまたはデータベースからロングURLを取得し、リダイレクトを実行します。クリックイベントも記録します。 * **分析サービス:** クリックログを処理し、データを集計して分析レポートを提供します。 * **ID生成サービス:** URLの一意な短縮IDを生成します。これは、独立した高可用性サービスにすることができます。 * **クリックログ記録サービス:** 生のクリックイベントを取り込むための高スループットサービスです。 * **Web UI/管理パネル:** ユーザーがリンクを作成、管理し、分析を表示するためのインターフェースです。 **アーキテクチャ図（概念）:** ``` +-----------------+ +-----------------+ +-----------------------+ | ロードバランサ |----->| APIゲートウェイ |----->| リンク作成サービス | +-----------------+ | | (リダイレクト) v +-----------------+ +-----------------+ +-----------------------+ | ロードバランサ |----->| リンク解決サービス | +-----------------+ | | (クリックイベント) v +-----------------------+ | クリックログ記録サービス | +-----------------------+ | | (生ログ) v +-----------------------+ | メッセージキュー | +-----------------------+ | | (処理済みデータ) v +-----------------------+ | 分析サービス | +-----------------------+ | | (分析データ) v +-----------------------+ | 分析データベース | +-----------------------+ **データベース:** * **メタデータデータベース:** 短縮URLとロングURLのマッピング、カスタムエイリアス、作成タイムスタンプ、有効期限、ユーザー情報を格納します。 * **分析データベース:** リンクごとのクリックデータを集計して格納します。 * **ID生成データベース/サービス:** 一意なIDを生成するために使用します。 **キャッシュ:** * **読み取りキャッシュ:** よくアクセスされる短縮URLをキャッシュし、リダイレクトを高速化します。 **メッセージキュー/ストリーム:** * クリックログ記録とリダイレクトパスを分離し、分析のための非同期処理を可能にします。

ハイレベルアーキテクチャと主要コンポーネント システムは、グローバルanycast DNSまたはAWS Global AcceleratorやCloudflareのようなグローバルロードバランサーの後ろで、少なくとも2つの地理的リージョン（US-EastおよびEU-West）にデプロイされたいくつかのレイヤーに編成されています。 1. エッジおよびCDNレイヤー：グローバルロードバランサーがユーザーを最も近いリージョナルクラスターにルーティングします。CDNまたはエッジキャッシュ（Cloudflare Workers、CloudFront）は、エッジで一般的なリダイレクトマッピングをキャッシュし、80ms未満のP95レイテンシを実現します。 2. APIゲートウェイおよびレートリミッター：各リージョンは、認証、レート制限、リクエストルーティングを処理するAPIゲートウェイを実行します。レート制限は、Redisをバックエンドとするスライディングウィンドウカウンターを使用し、悪意のある作成パターンをスロットルします。 3. リンク作成サービス：APIゲートウェイの後ろにあるステートレスサービス。長いURL、オプションのカスタムエイリアス、オプションの有効期限を受け入れ、短いコードを返します。プライマリデータベースに書き込み、キャッシュを無効化またはウォームアップします。 4. リダイレクトサービス：最もトラフィックの多いパス。短いコードに対するGETリクエストを受け取り、宛先URL（まずキャッシュ、次にデータベース）を検索し、HTTP 301または302リダイレクトを発行し、クリックイベントを分析パイプラインに発行します。サービスが常に分析のためにリクエストを確認できるように302リダイレクトを使用しますが、ブラウザとCDNエッジがキャッシュできるように短いTTL（例：60秒）のCache-Controlヘッダーを返します。 5. 分析パイプライン：クリックイベントは分散ストリーム（KafkaまたはAWS Kinesis）に発行されます。ストリームプロセッサ（FlinkまたはKafka Streams）は、1分間のタンブリングウィンドウでリンクごとのクリックを集計し、ロールアップを分析ストアに書き込みます。シンプルなAPIが集計された分析を提供します。 6. 悪用防止サービス：リンク作成時に、宛先URLがGoogle Safe Browsing APIおよび内部ブロックリストに対してチェックされます。軽量なMLスコアラーが悪意のあるパターン（一括作成、既知のスパムドメイン）をフラグ付けします。フラグ付けされたリンクはレビューのために保持されるか、拒否されます。 7. 有効期限とクリーンアップワーカー：定期的なジョブ（cronまたはスケジュールされたLambda）が有効期限切れのリンクをスキャンし、ソフト削除してキャッシュから削除します。 コアデータモデルとストレージの選択 プライマリリンクストア：Amazon DynamoDBまたはApache Cassandraのような分散NoSQLデータベース。テーブルはshort_code（パーティションキー）でキー付けされます。スキーマフィールド：short_code（文字列、主キー）、long_url（文字列）、user_id（文字列）、created_at（タイムスタンプ）、expires_at（タイムスタンプ、NULL可能）、custom_alias（ブール値）、updated_at（タイムスタンプ）。DynamoDBは、シングルミリ秒単位の読み取り、グローバルテーブルによる自動マルチリージョンレプリケーション、および管理されたスケーリングのために選択されています。Cassandraは、ベンダーロックインを避けたいチームの代替手段です。 キャッシュレイヤー：各リージョンのRedis Cluster（またはElastiCache）。キャッシュエントリ：short_code -> long_url、リンクの有効期限に一致するTTLまたはデフォルトの24時間。キャッシュアサイドパターン：リダイレクトサービスはまずRedisをチェックします。ミスの場合、DynamoDBから読み取り、Redisに投入します。 分析ストア：時系列または列指向ストア。ClickHouseまたはAmazon Timestreamは、ディメンション（short_code、timestamp_bucket、country、referrer、device_type）を持つリンクごとのクリック集計を格納します。1分、1時間、1日の粒度での事前集計されたロールアップ。 ユーザーおよびアカウントストア：リレーショナルデータベース（RDS経由のPostgreSQL）は、ユーザーアカウント、APIキー、請求情報、リンク所有権メタデータを格納します。これはトラフィックが少なく、強い一貫性とリレーショナルクエリの恩恵を受けます。 API設計 ショートリンクの作成：POST /api/v1/links。リクエストボディ：long_url（必須）、custom_alias（オプション）、expires_at（オプション）。レスポンス：201 Created、short_code、short_url、created_at、expires_at付き。エラー：カスタムエイリアスが使用されている場合は409 Conflict、URLが無効な場合は400、悪用が検出された場合は403。 宛先URLの更新：PATCH /api/v1/links/{short_code}。リクエストボディ：long_url。created_atから10分以内のみ許可されます。レスポンス：200 OK、更新されたレコード付き。エラー：10分経過後または所有者でない場合は403。 解決（リダイレクト）：GET /{short_code}。レスポンス：302 Found、Locationヘッダーがlong_urlに設定されています。期限切れまたは見つからない場合：404。リダイレクトサービスはキャッシュ制御用のレスポンスヘッダーも設定します。 分析の読み取り：GET /api/v1/links/{short_code}/analytics?start=...&end=...&granularity=hour。レスポンス：200 OK、時間バケットごとのクリック数、上位国、上位リファラーの配列付き。 リンクの削除：DELETE /api/v1/links/{short_code}。リンクをソフト削除し、キャッシュを無効化します。 ID生成戦略 短いコードは、base-62アルファベット（a-z、A-Z、0-9）からの7文字で、約3.5兆の可能なコードとなり、長年にわたる予想リンクボリュームをはるかに超えます。生成アプローチ：各サービスインスタンスには、一意のワーカーID（コーディネーションサービスまたは構成から）が割り当てられます。SnowflakeライクなIDジェネレーターは、タイムスタンプコンポーネント、ワーカーID、シーケンス番号を組み合わせた64ビットの一意の整数を生成します。次に、整数はbase-62エンコードされ、7文字に切り捨てまたはパディングされます。これにより、すべての書き込みでのコーディネーションが回避され、一意性が保証されます。カスタムエイリアスの場合は、サービスが一意性制約を伴う挿入を試みます。競合が発生すると409が返されます。 トラフィック増加とバースト処理のためのスケーリング戦略 定常状態の計算：月間15億リダイレクトは約平均580 RPSであり、ニュースイベント中のピークは最大10〜50倍になる可能性があるため、リダイレクトパスはリージョンあたり少なくとも30,000 RPSを処理する必要があります。月間1億2000万のリンク作成は約平均46 RPSです。 リダイレクトパスのスケーリング：リダイレクトサービスはステートレスであり、オートスケーリンググループの後ろで水平にスケーリング可能です。Redisは読み取りの大部分を処理し、DynamoDBのオンデマンドキャパシティはキャッシュミスを処理します。CDNエッジキャッシュは、バイラルリンクの繰り返しリクエストの大部分を吸収し、オリジン負荷を軽減します。 バースト処理：CPUとリクエスト数に基づくオートスケーリングポリシーで、積極的なスケールアウト（60秒で50％の容量を追加）。Redisクラスターはリードレプリカで事前にスケーリングできます。DynamoDBのオンデマンドモードは、事前プロビジョニングなしでバースト書き込みと読み取りを吸収します。CDNは、ホットリンクのバースト読み取りトラフィックを自然に吸収します。 作成パスのスケーリング：バースト性は低いですが、それでもオートスケールされます。書き込みはリージョナルDynamoDBグローバルテーブルに送信され、他のリージョンに非同期でレプリケートされます。 分析パイプラインのスケーリング：Kafkaパーティションは並列処理のためにshort_codeでキー付けされます。Flinkコンシューマーグループは水平にスケーリングされます。ClickHouseクラスターは、クエリのスループットを向上させるためにシャードを追加できます。 信頼性と災害復旧 マルチリージョンアクティブアクティブ：DynamoDBグローバルテーブルは、US-EastとEU-West間でデータをレプリケートし、ラストライターウィン（last-writer-wins）の競合解決を行います。両方のリージョンが読み取りと書き込みを処理します。一方のリージョンが失敗した場合、DNSヘルスチェック（Route 53または同等）により、数秒以内にすべてのトラフィックが生存しているリージョンにルーティングされます。 Redisレプリケーション：各リージョンには、ローカルDynamoDBレプリカから投入される独自のRedisクラスターがあります。Redisが失敗した場合、リダイレクトサービスはわずかに高いレイテンシでDynamoDB読み取りにフォールバックします。 Kafkaの耐久性：Kafkaトピックはレプリケーションファクター3、min.insync.replicas=2です。分析パイプラインが遅延した場合、クリックイベントは再再生のために少なくとも72時間Kafkaに保持されます。 バックアップ：DynamoDBのポイントインタイムリカバリが有効になっています。PostgreSQLは、クロスリージョンレプリケーションを備えた自動日次スナップショットを持っています。ClickHouseデータは毎日S3にバックアップされます。 段階的な機能低下：悪意のあるチェックサービスが遅い場合、作成リクエストはブロックするのではなく、非同期レビュー用のフラグを付けて続行されます。分析パイプラインがダウンしている場合、リダイレクトは影響を受けずに続行されます。クリックイベントはKafkaにキューイングされます。 主なトレードオフ ID生成：SnowflakeライクなIDは、中央集権的なカウンターのボトルネックを回避しますが、ワーカーIDのコーディネーションが必要です。64ビットIDのBase-62エンコーディングは、短くURLセーフなコードを生成します。トレードオフ：衝突を回避し、将来の成長を可能にするために、必要以上にわずかに長いコード（7文字）。 データベース選択：DynamoDBは、管理されたスケーリング、低レイテンシの読み取り、および組み込みのグローバルレプリケーションのために選択されました。トレードオフ：リージョン間の結果整合性（リンク作成はリージョン間でレイテンシが重要ではなく、同じリージョン内のリダイレクトは一貫しているため許容範囲）。Cassandraは、より多くの運用負荷を伴いますが、ベンダーロックインのない同様のプロパティを提供します。 キャッシング：Redisを使用したキャッシュアサイドは、ホットリンクに対してミリ秒未満の読み取りを提供します。トレードオフ：10分以内のURL更新時のキャッシュ無効化は、リージョン間で明示的な無効化が必要であり、一時的な古いデータのウィンドウ（最近作成されたリンクの短いキャッシュTTL、例：10分未満のリンクの場合は30秒で軽減）を導入します。 一貫性：システムは可用性とパーティション耐性（CAPのAP）を優先します。リダイレクトの読み取りは結果整合性がありますが、これは許容範囲です。10分間の更新ウィンドウはアプリケーションレイヤーで強制されます。まれなスプリットブレインシナリオでは、一時的に古いリダイレクトが発生する可能性があります。 分析パイプライン：KafkaとFlinkとClickHouseは、5分間のSLA内でほぼリアルタイムの分析を提供します。トレードオフ：運用上の複雑さが増します。よりシンプルな代替手段は、クリックログをS3に書き込み、Athenaでクエリすることですが、5分間の鮮度要件を満たせません。 302 vs 301リダイレクト：302（一時的）は、サービスが分析のためにすべてのクリックを確認できるように使用されます。トレードオフ：リピート訪問者にとって301よりもわずかにレイテンシが高くなりますが、60秒のTTLを持つCDNエッジキャッシュはこれを軽減しつつ、ほとんどのクリックをキャプチャします。 監視と障害検出 メトリクス：すべてのサービスは、時系列監視システム（PrometheusとGrafana、またはCloudWatch）にメトリクスを発行します。主要なメトリクスには、リダイレクトのP50、P95、P99レイテンシ、キャッシュヒット率（ターゲット95％以上）、DynamoDBの読み取りおよび書き込み消費キャパシティ、Kafkaコンシューマーラグ、エンドポイントごとのエラー率、リンク作成率が含まれます。 アラート：リダイレクトP95レイテンシが80msを超える場合、キャッシュヒット率が90％を下回る場合、Kafkaコンシューマーラグが5分を超える場合（分析SLA）、いずれかのエンドポイントでエラー率が1％を超える場合、およびリージョンヘルスチェックの失敗時にPagerDutyアラートが発報されます。 分散トレーシング：リダイレクトパス（エッジからキャッシュ、データベース、レスポンスまで）全体でOpenTelemetryトレースを実行し、レイテンシの回帰を診断します。 合成監視：複数の地理的場所からのカナリアリクエストが継続的にショートリンクを作成および解決し、エンドツーエンドのレイテンシまたは正確性が低下した場合にアラートを発報します。 ログ集約：構造化ログは、デバッグおよび監査証跡のために中央集権的なシステム（ELKまたはCloudWatch Logs）に出荷されます。 ヘルスチェック：各サービスはヘルスエンドポイントを公開します。ロードバランサーは正常でないインスタンスを削除します。クロスリージョンヘルスチェックはDNSフェイルオーバーをトリガーします。 追加の前提条件：ユーザーは、リンク作成および分析のためにAPIキーを介して認証されます。匿名リンク作成はIPによってレート制限されます。システムはAWS上で実行されますが、設計はポータブルです。短いコードはケースセンシティブです。サービスは、近い将来、数十億の同時アクティブリンクをサポートする必要はありませんが、7文字のコードスペースは数兆までの成長を可能にします。