短縮 URL のアーキテクチャとは、URL 短縮サービスの内部設計と技術的な仕組みの全体像です。システム設計の面接問題としても頻出するテーマで、スケーラブルな Web サービスの設計原則を学ぶ好例です。
基本的なアーキテクチャは 3 つのコンポーネントで構成されます。第一に URL 短縮エンジン (長い URL を受け取り、ユニークなショートコードを生成してデータベースに保存)、第二にリダイレクトエンジン (短縮 URL へのアクセスを受け、データベースからリダイレクト先を取得して 301/302 レスポンスを返す)、第三にアナリティクスエンジン (クリックデータを収集・集計して統計情報を提供) です。
ショートコードの生成方式は主に 3 つあります。カウンターベース (連番 ID を Base62 に変換)、ハッシュベース (URL の MD5/SHA256 ハッシュの先頭 N 文字を使用)、ランダム生成 (ランダムな文字列を生成して衝突チェック) です。カウンターベースは実装が最も単純で衝突が起きないため、設計の出発点として選ばれることが多い方式です。ただしコードが順番に並ぶため、他人が作った短縮 URL を機械的に走査されやすいという弱点があります。公開を前提としない URL を扱う場合は、連番をそのまま出さずに変換をかけるか、ランダム生成に衝突チェックを組み合わせる設計が採られます。カウンターを複数のサーバーで使う構成では、ID の払い出しをどこで一意に保つかという調整も必要になります。
スケーラビリティの鍵はキャッシュ戦略です。短縮 URL のリダイレクト処理は、1 件の登録に対して読み取りが何度も繰り返される形になり、読み取りが書き込みを大きく上回ります。そのため Redis や Memcached によるキャッシュが効果的です。よく開かれる短縮 URL をキャッシュに保持することで、データベースへのクエリを大幅に削減し、リダイレクト先を引くまでの時間を短縮できます。なお利用者が体感する待ち時間には端末とサーバーの間の通信の往復が含まれるため、キャッシュだけで決まるわけではありません。
データベース設計では、キーバリューストア (DynamoDB、Redis) が短縮 URL のルックアップに適しています。ショートコードをキー、元の URL と付随情報を値として保存するシンプルな構造です。1 台では読み書きが収まらない規模になると、ショートコードを基準にデータを複数のノードへ振り分けるシャーディングも検討されます。このとき先頭の 1 文字だけで分けると、コードの生成方式によっては特定のノードにデータが偏るため、分布が均等になる分け方を選ぶ必要があります。