ETagが使えない現場の救世主：Last-ModifiedとIf-Modified-Sinceで「無駄なパケット」を削ぎ落とせ
ネットワークエンジニアの諸君、今日もパケットの海を泳いでいるか？
Web APIの設計において「キャッシュ」は避けて通れない道だ。APIを叩くたびにDBをフルスキャンさせてレスポンスを返すような設計は、インフラエンジニアとしては悪夢以外の何物でもない。多くの現場では ETag を使った検証が推奨されるが、動的に生成されるコンテンツや、DBのスキーマ制約でハッシュ値を計算するコストすら惜しい場合がある。そんな時、古き良き Last-Modified と If-Modified-Since のペアが、渋い働きを見せてくれる。
今日は、この「時刻ベースのキャッシュ検証」の深淵に触れ、現場でハマりやすい罠について語っていこうと思う。
—
1. RFC 7232が定義する「時刻による検証」の基本フロー
HTTPにおいて、キャッシュの鮮度を検証するメカニズムはシンプルだ。ETag が「内容の指紋」なら、Last-Modified は「最後の更新証明書」だ。
通信フローの極意
1. 初回リクエスト: クライアントがリソースを取得。サーバーは Last-Modified: <Date> をレスポンスヘッダーに付与する。
2. 2回目以降のリクエスト: クライアントは、直前に受け取った時刻を If-Modified-Since ヘッダーに乗せてサーバーに送る。
3. 検証: サーバーは、現在のリソースの更新時刻が If-Modified-Since より新しいか判定する。
- 更新なし: サーバーは
304 Not Modifiedを返す。ボディは空だ。帯域とCPU負荷が劇的に下がる。 - 更新あり: サーバーは
200 OKと新しいリソースを返す。
シンプルだろう？ だが、この「シンプルさ」の裏には、ネットワーク越しならではの残酷な落とし穴が潜んでいる。
—
2. 現場を凍りつかせる「時刻ズレ」のリスク
「時刻による検証」最大の敵は、サーバー・クライアント間の時刻同期（NTP）のズレだ。
例えば、クライアント側の時計がサーバーより1秒進んでいるとする。この状況で、サーバー側でリソースが更新された直後にリクエストを送ると、本来は更新されているのにキャッシュと見なされてしまう（あるいはその逆の不整合）が起きる可能性がある。
また、Last-Modified は「HTTP-date」形式（例: Wed, 21 Oct 2023 07:28:00 GMT）でやり取りされるが、このフォーマットは秒単位だ。1秒間に複数回更新されるような高頻度APIでこれを使うと、キャッシュの整合性が崩壊する。高頻度アクセス環境なら、迷わず ETag （Strong Validator）を使うべきだ。
—
3. 実践：Pythonで組む「条件付きGET」のサーバーロジック
理屈はわかった。では、実務でどう実装するか。PythonのWebフレームワーク（ここでは簡潔にFlask風の擬似コード）を例に見てみよう。
from datetime import datetime
from flask import request, make_response
def get_resource():
# 1. データベースから最終更新時刻を取得
last_modified_db = get_latest_updated_time_from_db() # datetimeオブジェクトを想定
# 2. クライアントからのIf-Modified-Sinceを取得
if_modified_since = request.headers.get('If-Modified-Since')
if if_modified_since:
# パースして比較可能な形式へ（簡易的な比較ロジック）
client_time = parse_http_date(if_modified_since)
# サーバーの時刻がクライアントの時刻より新しければ更新とみなす
if last_modified_db <= client_time:
# 3. 304 Not Modified を返す（ボディは送らない）
return make_response('', 304)
# 4. 通常の200 OKレスポンス
response = make_response(render_data())
response.headers['Last-Modified'] = format_http_date(last_modified_db)
return responseポイントは、304 を返す際にレスポンスボディを空にすることだ。ここで誤ってデータを流すと、帯域制限の意味がなくなる。
—
4. デバッグの現場：curlで検証する
障害対応中、ブラウザのデベロッパーツールだけで追うのは甘い。CLIでパケットを制せ。
# まずは普通にリクエストして、Last-Modifiedを確認する
curl -I https://api.example.com/data/1
# 取得した日付をIf-Modified-Sinceにセットして再送する
curl -I -H "If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT" https://api.example.com/data/1もし 304 Not Modified が返ってこない場合、以下の項目を疑え。
- 時刻フォーマット:
RFC 7231形式に従っているか？（曜日表記の有無やスペースの扱い） - タイムゾーン: 全て
GMTで統一されているか？（UTCとGMTの混同はトラブルの元だ） - Proxyの介在: 前段のロードバランサーやCDNが
Last-Modifiedを剥がしていないか？
—
最後に：ネットワークスペシャリストからの助言
Last-Modified は枯れた技術だが、だからこそ現代のモダンなAPIでも「縁の下の力持ち」として輝く。APIの設計において、何でもかんでも最新技術を詰め込めばいいというものではない。
「そのAPIは、1秒間に何回更新されるのか？」「ETagを生成する計算コストは許容できるか？」
これらを問い続け、環境に最適なプロトコルを選択する。それこそが、設計者の腕の見せ所だ。次にAPIを叩くとき、Last-Modified ヘッダーを見て「パケットの無駄を省いてくれているな」とニヤリとできれば、君も一人前のエンジニアだ。
もし大規模システムで深刻なキャッシュの不整合に悩んでいるなら、迷わずシステムクロックの同期を見直すか、素直に ETag へ移行せよ。それが遠回りに見えて、実は最も近道なのだから。
それでは、また現場で会おう。
コメント