はじめに
本書の目的
本ドキュメントは、CDN（コンテンツデリバリーネットワーク）に関わるデータベーステーブル構造を分かりやすく整理することを目的としています。コンテンツ管理やエッジサーバー運用、ユーザーリクエスト記録、トラフィックログ、キャッシュ状態など、実運用で必要となる情報をテーブル単位で体系化します。
背景と意義
CDNは、利用者に近い場所からコンテンツを届ける仕組みです。図書館の分館や配送センターに例えると理解しやすいです。適切なデータ設計は、配信速度の改善や障害対応の効率化に直結します。本書は設計段階での判断材料と、実装・運用での参照資料を兼ねます。
対象読者
バックエンドエンジニア、SRE、システム設計者、運用担当者、学習中の学生などを想定しています。専門用語は必要最小限に留め、具体例を交えて説明します。
本書の構成と読み方
第2章以降で各テーブル（コンテンツ、エッジサーバー、ユーザーリクエスト、トラフィックログ、キャッシュ）を順に解説します。各章はフィールド定義、役割、設計上の注意点を扱います。実装例や運用例は適宜示しますので、目的に応じて参照してください。
CDNの基本概念と役割
概要
CDN（Content Delivery Network）は、世界中に分散したサーバーの集まりです。画像や動画、Webページのファイルを複製して戦略的な場所に置き、利用者に近いサーバーから配信します。これにより表示が速くなり、安定して配信できます。
仕組み（簡単な流れ）
- オリジンサーバーにコンテンツを用意します。
- CDNはそのコンテンツを複製してエッジサーバーに保存します。
- ユーザーがリクエストすると、CDNは最も応答が速いエッジを選び配信します。したがって遅延を減らせます。
主な利点
- レイテンシーの低減：距離が短いほど早く届きます。
- 負荷分散：トラフィックを複数のサーバーに分散します。
- 可用性の向上：一部のサーバーに障害が出ても他で対応できます。
- スケーラビリティ：アクセス増加時も対応しやすくなります。
実際の例
Webサイトの画像配信、動画ストリーミング、ソフトウェア配布などで効果を発揮します。例えば同じ動画を多くの人に同時配信するとき、CDNが負担を分けて配信を安定させます。
注意点
コンテンツの更新（キャッシュの削除や期限設定）が必要です。動的に変わる情報は毎回オリジンから取得する工夫が求められます。
コンテンツテーブル（Content Table）
概要
コンテンツテーブルは、CDNで配信するファイルのメタデータを一元管理します。各コンテンツの基本情報を持つことで、配信・検索・消去の操作を素早く行えます。具体的にはファイルの識別、種類、保存場所、サイズ、更新時刻を管理します。
主なカラムと説明
- Content_id: 一意の識別子（例: UUID）。主キーにします。
- Content_name: 説明的なタイトル（例: “home_banner.jpg”）。
- Content_type: 画像・動画・スクリプトなど（例: image/png）。
- Content_url: CDN上のパスやフルURL（例: /cdn/images/home_banner.jpg）。
- Content_size: ファイルサイズ（バイト）。集計や転送料金計算に使います。
- Last_updated: 最終更新のタイムスタンプ。差分同期や無効化に使います。
実運用での使い方
- 配信先サーバーはContent_urlで参照し、Content_idでキャッシュを識別します。
- 更新時はLast_updatedを更新し、該当コンテンツのキャッシュを削除します。
- サイズや種類で帯域の見積もりやフィルタを行います。
設計のポイント
- Content_idとContent_urlにインデックスを付けます。
- Content_typeは定義済みの列挙にし、正規化します。
- 実ファイルはストレージに置き、テーブルにはパスのみ保存します。
- Last_updatedは変更ごとに確実に更新してください。
運用上の注意
メタデータが最新でないと誤配信につながります。更新フローを自動化し、サイズやURLの整合性を定期的にチェックしてください。
エッジサーバーテーブル（Edge Server Table）
概要
エッジサーバーテーブルは、CDNを構成する各エッジサーバーの情報を整理するための一覧表です。エッジサーバーはユーザーに近い場所でキャッシュを配信し、オリジンサーバーへの負荷を軽減します。テーブルを使うと運用や障害対応がスムーズになります。
各カラムの説明
- Server_id：各サーバーの一意の識別子（例: srv-01）。管理とログ検索に使います。
- Server_location：地理的位置（例: Tokyo、New York）。配信先の近さで優先度を決めます。
- Server_capacity：CPU、RAM、ストレージなどのリソース量をまとめて示します（例: 8CPU/32GB/1TB）。スケーリング判断に役立ちます。
- Current_load：現在の使用率を示します。%で管理することが多く、例として65%などで閾値を設定します。
- Status：運用状態（Active、Standby、Offline）。メンテナンスや障害時の切替に使います。
運用での使い方（具体例）
- 負荷分散：ある地域のCurrent_loadが高ければ、近隣のServer_locationのActiveサーバーにトラフィックを振ります。例: Tokyoのsrv-01が90%なら、同地区のsrv-02へ振替えます。
- 障害対応：StatusがOfflineになったら、StandbyをActiveに切り替えてサービスを継続します。
- 伸縮管理：Server_capacityとCurrent_loadを見て、リソースが不足する前に新しいサーバーを追加します。
注意点
Server_capacityはスペックだけでなく、ネットワーク帯域も考慮してください。Current_loadは瞬間値と平均値の両方を監視すると誤判断を防げます。
ユーザーリクエストテーブル（User Request Table）
概要
ユーザーリクエストテーブルは、各ユーザーからのアクセスを時系列で記録するための表です。どのユーザーがどのコンテンツを、どのエッジで、どれくらいの時間で受け取ったかを追跡できます。運用や解析に直接役立つ情報をまとめます。
各フィールドの説明
- Request_id: リクエストごとの一意の識別子。例: 12345。
- User_id: リクエストを行ったユーザーのID。匿名化して保存することも可能です。
- Content_id: 要求されたコンテンツのID。どのファイルや配信物か判別します。
- Request_timestamp: リクエスト時刻（UTC推奨）。例: 2025-01-01 12:00:00。
- Edge_server_used: リクエストを処理したエッジのID。特定の地域やサーバーを示します。
- Response_time: 処理にかかった時間（ms）。高速化や障害検知に使います。
活用例
- 平均応答時間をエッジごとに算出し、遅いエッジを特定します。
- 人気コンテンツのアクセス集中を把握し、配信計画に反映します。
- 特定ユーザーのアクセス傾向を分析し、パーソナライズや不正検知に活用します。
運用上の注意
インデックスを張ることで検索を速くできます。個人情報は必要最小限にし、保存期間を定めて管理してください。ログ量が多くなるため、集計用のバッチ処理やサンプル保存も検討すると運用が楽になります。
トラフィックログテーブル（Traffic Log Table）
概要
トラフィックログテーブルは、CDNの動きを記録する中心的なテーブルです。リクエストやイベントごとに1行ずつログを残し、運用監視や障害対応、利用傾向の把握に使います。具体例を交えて分かりやすく説明します。
主なカラム
- Log_id：各ログの一意識別子（例：log_0001）。検索や相関分析で使います。
- Timestamp：ログ作成時刻。UTCなどで保存します（例：2025-01-01T12:00:00Z）。
- Request_type：リクエストの種類（例：コンテンツ取得、キャッシュパージ、ヘルスチェック）。
- Details：追加情報。クライアントIP、エッジサーバーID、HTTPステータス、キャッシュ状態（HIT/MISS）などを含めます。
利用例
- 障害対応：あるエッジで500エラーが増えれば、TimestampとEdge IDで原因を特定します。
- パフォーマンス分析：短時間に同一コンテンツへのアクセスが集中すれば、キャッシュ設定の見直しを行います。
- セキュリティ確認：異常なリクエストパターンを検出してブロックできます。
運用上の注意
ログは書き込みが多いため、インデックス設計（TimestampやRequest_type）を工夫します。個人情報保護のためにIPはマスクするかハッシュ化してください。生ログは保管期間を短くし、必要な指標は集計して長期保存します。
キャッシュテーブル（Cache Table）
目的と役割
キャッシュテーブルは、どのコンテンツがどのエッジサーバーにどれだけの期間保存されているかを管理します。たとえば動画ファイルAがエッジXに90分間保存される、といった情報を記録します。
主要カラムと説明
- Cache_id：各キャッシュエントリの一意のIDです。
- Content_id：キャッシュ中のコンテンツを識別するIDです。
- Edge_server_id：コンテンツが置かれているエッジサーバーのIDです。
- Expiration_timestamp：キャッシュの有効期限を示す日時です。
- Status：キャッシュ状態（例：valid/invalied/refresh中）を示します。
- Size：保存サイズ（バイト）やストレージ種別を記録します。
操作例（具体例）
- 取得：Content_idとEdge_server_idで検索して、現在有効なキャッシュを返します。
- 期限切れ処理：Expiration_timestampを過ぎた行を削除または再取得フローに回します。
運用上の注意点
- TTL（有効期限）を適切に設定すると、不要な転送を減らせます。
- コンテンツ更新時はインバリデーションを実行して古いキャッシュを無効化してください。
- インデックスを張ると検索が速くなりますが、書き込み負荷が増える点に注意です。
- 監視とログを組み合わせて、ヒット率や異常を早く検出しましょう。
