TTL (Time to Live)とは

概要

TTL (Time to Live) は、データやネットワークパケットに設定される有効期限である。TTL を過ぎたデータは「期限切れ」として自動的に削除されるか、再取得が必要になる。DNS レコード、CDN キャッシュ、データベースのレコード、ネットワークパケットなど、Web 技術のあらゆる層で TTL の概念が使われている。

DNS における TTL

DNS レコードの TTL は、リゾルバ (DNS キャッシュサーバー) がそのレコードをキャッシュする秒数を指定する。TTL が 3600 (1 時間) のレコードは、リゾルバが 1 時間キャッシュし、その間は権威 DNS サーバーに問い合わせない。

TTL の設定はトレードオフである。長い TTL はDNS サーバーへの問い合わせ回数を減らし、名前解決の速度を向上させる。短い TTL は変更の反映を速くするが、DNS サーバーへの負荷が増える。通常運用では 1 時間から 24 時間程度の TTL を設定し、DNS レコードの変更を予定している場合は事前に TTL を短く (300 秒程度に) しておくのが一般的な運用手法である。

データベースにおける TTL

DynamoDB などの NoSQL データベースでは、レコードに TTL 属性 (Unix タイムスタンプ) を設定することで、期限切れのレコードを自動的に削除できる。セッション情報、一時トークン、キャッシュデータなど、一定期間後に不要になるデータの管理に適している。

質問箱サービスでは、セッション ID に TTL を設定してログインセッションの有効期限を管理している。また、Proof of Work のチャレンジトークンにも短い TTL (5 分程度) を設定し、使い回しを防止している。TTL による自動削除は、バッチ処理で定期的に古いレコードを掃除する方式と比べて、運用の手間がかからず、削除漏れのリスクもない。

CDN キャッシュにおける TTL

CDN (Content Delivery Network) では、オリジンサーバーから取得したコンテンツをエッジサーバーにキャッシュする期間を TTL で制御する。静的アセット (画像、CSS、JavaScript) には長い TTL (1 年など) を設定し、動的コンテンツ (API レスポンス) にはキャッシュしないか極めて短い TTL を設定する。

静的アセットに長い TTL を設定する場合、ファイル名にハッシュ値を含める (例: `main.a1b2c3.js`) ことで、コンテンツが更新された際に自動的に新しい URL になり、古いキャッシュが参照される問題を回避できる。この手法はキャッシュバスティングと呼ばれ、Next.js などのフレームワークではビルド時に自動的にハッシュ付きファイル名が生成される。

Web 技術の仕組みを体系的に学びたい方は、Web 技術の入門書籍も参考になります。