📅 2025年12月26日 04:04

ローリングデプロイでキャッシュに泣かないための最短ルート — キャッシュキーを「バージョン化」せよ

要約

ローリングデプロイ中に古いインスタンスと新しいインスタンスが混在すると、キャッシュの互換性違反や予期せぬ不整合が発生する。解決策はシンプルで効果的：キャッシュキーにバージョン（ネームスペース）を組み込み、移行を安全に管理すること。

この記事を読むべき理由

日本のサービスでも、ブルー/グリーンやローリングデプロイが一般化しており、キャッシュ不整合による障害は重大な顧客影響を与えます。少しの設計変更でダウンタイムやトラブルシューティングを大幅に減らせるため、実務で即使える手法を押さえておくべきです。

詳細解説

問題の本質

ローリングデプロイでは旧コードと新コードが同時稼働する。キャッシュの構造（シリアライズ形式、キー命名、データモデル）が変わると、旧インスタンスが書いたキーを新インスタンスが誤って読み込み、デシリアライズエラーや論理バグが起きる。
キャッシュのTTLや自動削除に頼るだけでは不十分。短TTLにするとパフォーマンスが落ち、長TTLでは互換性問題が長引く。

バージョン化の考え方

キーにアプリケーションやスキーマの「バージョン文字列」を付与する（例: myapp:v3:user:123）。
デプロイ時に新しいバージョンを切り替え、既存のキーはバックグラウンドで徐々に消す（ガベージコレクション的に整理）。
バージョンはセマンティックに管理する（例えば、後方互換がない変更でのみインクリメント）。

運用上のポイント

新バージョンの導入は「読み取りは新/旧両対応、書き込みは新バージョンのみ」にして段階的移行するか、短時間で完全切替するかを選ぶ。
キャッシュウォームアップ（デプロイ直後に重要キーをプリロード）を組み合わせるとスロースタートを防げる。
メトリクス（ヒット率、エラー、キー数）とアラートを用意して古いキーの退場状況を監視する。

実例（Redisでのキー命名）

// Node.js (redis)
const CACHE_VERSION = process.env.CACHE_VERSION || 'v1';
function userCacheKey(userId) {
  return `myapp:${CACHE_VERSION}:user:${userId}`;
}
await redis.set(userCacheKey(123), JSON.stringify(userObj), 'EX', 3600);

デプロイ運用例（手順）

新バージョンを設定（例: v2）してデプロイ（新インスタンスは v2 を書く）。
読み取りルールを段階的に切り替えるか、新コードはまず v2 を読み書きするようにする。
モニタで旧キーアクセスがゼロになったら旧キーを削除する（スクリプトで自動化）。
必要に応じて短期間は「新->旧フォールバック」を組むが、長期運用は避ける。

注意点

キャッシュ容量が増えるため、キーの寿命管理（TTL/削除スケジュール）を設計する。
マルチサービスで同じキー命名を共有する場合は共通ルールを作る。
セキュリティ面でキー名に機微情報を含めない。

実践ポイント

キャッシュキーに明示的なバージョンプレフィックスを導入する（サービス・スキーマ単位で管理）。
デプロイ手順に「キーのバージョン切替」「ウォームアップ」「古いキーの削除」を組み込む。
キャッシュミス率・読み取りエラーを監視し、バージョン移行の可視化を行う。
小さな互換性変更はライブラリレベルで後方互換にして、バージョンアップの頻度を抑える。

引用元

タイトル: How Versioned Cache Keys Can Save You During Rolling Deployments
URL: https://medium.com/dev-genius/version-your-cache-keys-to-survive-rolling-deployments-a62545326220

📌 引用元:
How Versioned Cache Keys Can Save You During Rolling Deployments
Hacker News Score: | Comments: