【実務・中級編】 TOUCHとCOPY – Redis

Redisの裏側を知り尽くせ：`TOUCH`と`COPY`がもたらす設計のパラダイムシフト

こんにちは。テックリードの私だ。今日のコードレビューで、あるジュニアエンジニアが「キーの存在確認とTTLの延命のために、わざわざ `GET` を叩いて値をアプリケーションにロードしている」のを見かけた。

……待て待て。それ、ネットワーク帯域とメモリの無駄遣い、そして何より「不要なデシリアライゼーションの負荷」をアプリケーションサーバーに強いていないか？

Redisは単なる「キーバリューの置き場」ではない。メモリ上のデータ構造を極限まで効率よく操作するための洗練されたマシーンだ。今回は、Redis 6.0以降で静かに、しかし確実に我々のアーキテクチャの選択肢を広げた2つのコマンド、`TOUCH` と `COPY` に焦点を当てる。

表面的な使い方ではなく、「なぜそれが設計上有利なのか」「裏で何が起きているのか」というプロダクション環境で本当に必要な知見を叩き込む。

—

1. `TOUCH`: アプリケーションのメモリを汚さずに「アクセス」を刻む

概要と内側の挙動

`TOUCH key [key …]` は、指定したキーが存在する場合に、そのLRU/LFU等のアクセス統計（Idle TimeやAccess Frequency）を更新し、LRUアルゴリズム上における「最近使われたキー」へと昇格させるコマンドだ。

多くの開発者は、キーの生存確認やアクセス時間の更新に `EXPIRE` や `GET` を使いがちだ。しかし、考えてみてほしい。数メガバイトもあるJSON文字列や巨大なハッシュ構造を、単に「まだこのデータは生きていますよ、LRUで追い出さないでくれ」という理由だけでネットワーク経由でクライアントに引き抜く必要があるか？

答えはNOだ。

`TOUCH` の真価は、「データを1バイトたりともペイロードとして動かさず、Redisのメタデータのみを更新する」点にある。

実務でのユースケース：セッションストアの動的延命

例えば、ユーザーがアクティブであることを示すためにセッションの有効期限をスライドさせたいケースを想像してほしい。

ユーザーID: 10045 のセッション生存確認＆LRUの優先度を最大化
127.0.0.1:6379> TOUCH session:10045
(integer) 1

ここで重要なのは、もしこのセッションが `allkeys-lru` や `volatile-lru` のようなメモリ eviction ポリシーで管理されている場合、`TOUCH` によってこのキーの「最終アクセス時刻」が現在時刻に書き換わり、メモリ逼迫時に犠牲になる確率が劇的に下がるという点だ。

設計上の注意点（O(N)の罠）

ここでチーフとして厳しく釘を刺しておこう。`TOUCH` は可変長引数を受け取れるため、ついつい数万件のキーを一度に渡したくなる。

⚠️ アンチパターン：一度に膨大なキーを指定するな
127.0.0.1:6379> TOUCH key1 key2 key3 … (数千件)

Redisはシングルスレッドで動作する。大量のキーを一度に `TOUCH` しようとすると、ハッシュテーブルのルックアップコストが累積し、その瞬間に他のすべてのリクエストをブロックする（レイテンシスパイクを引き起こす）。パイプラインを使うか、バッチサイズを適切に制御（せいぜい数十〜数百件程度に留める）するのがプロの仕事だ。

—

2. `COPY`: Redis 6の隠れた名機能によるアトミックな複製

概要と内側の挙動

Redis 6.0で導入された `COPY source destination [DB destination-db] [REPLACE]` は、長年エンジニアを悩ませてきた「ある問題」に終止符を打った。

それまでは、あるキーの値を別のキーに複製したい場合、以下のような面倒な手順を踏む必要があった。
1. `DUMP source` でバイナリ表現を取得する。
2. アプリケーション層でそのバイナリを受け取る。
3. `RESTORE destination 0 serialized-value` で書き込む。

これはネットワーク帯域を無駄に消費するだけでなく、途中でエラーが起きた場合の整合性担保（トランザクション管理）がアプリケーション側に委ねられるという悪夢を生んでいた。

`COPY` はこれをRedisのサーバー内部だけで（In-Memoryで）完結させる。

実務でのユースケース：ミュータブルな設定値の「シャドウコピー」

本番環境で動いている重いキャッシュ構造（例えば、複雑な計算結果のキャッシュや、マスタデータのスナップショット）を、デバッグや一時的な別処理のために安全に別名で退避させたいときはないか？

既存のマスター設定をバックアップキーへ瞬時にコピー（同名が存在する場合は上書きしない）
127.0.0.1:6379> COPY config:master config:backup
(integer) 1

強制的に上書き（REPLACEオプション）したい場合
127.0.0.1:6379> COPY config:master config:backup REPLACE
(integer) 1

パフォーマンスとメモリの深淵：Copy-on-Writeの誤解を解く

ここでシニアエンジニアなら一歩踏み込んで考えるべきだ。「OSの `fork()` のような Copy-on-Write（CoW）がRedisのメモリ内データ構造でも起きるのか？」と。

答えは「否（No）」だ。

Redisの `COPY` は、基本的にはオブジェクトのシャローコピー（場合によっては深い構造の複製）をメモリ上に新しくアロケートする。つまり、コピー元のサイズが2GBあるなら、コピー実行瞬間にRedisはさらに2GBのメモリを消費する。

[メモリ上]
config:master (2GB) ──(COPY実行)──> config:backup (新しく2GBアロケート)

もしRedisの `maxmemory` 制限の天井ギリギリで運用している環境において、巨大なデータ構造に対して安易に `COPY` を叩くと、一瞬で `OOM (Out Of Memory)` エラーを引き起こすか、maxmemory-policy による予期せぬキーの削除（Eviction）の連鎖を引き起こす。

設計ルール:

• 巨大な Hash, Sorted Set, Stream に対して `COPY` を使う際は、必ずメモリの空き容量（`INFO memory` の `used_memory` と `maxmemory` のデルタ）を監視・計算した上で実行すること。

—

3. コードレビューの現場から：どう設計に落とし込むか

実際のマイクロサービスアーキテクチャにおいて、これらをどうコードに落とし込むべきか。TypeScript（Node.js / ioredis）を例に、正しい設計パターンを示そう。

❌ 悪い設計（アンチパターン）

// データの生存確認のために、わざわざ中身をFETCHしてアプリケーション側で保持する
async function keepSessionAlive(redis: Redis, sessionId: string): Promise {
const data = await redis.get(`session:${sessionId}`);
if (!data) return false;

// 値を再設定してTTLを延命（無駄なシリアライズ・ネットワークコスト）
await redis.set(`session:${sessionId}`, data, ‘EX’, 3600);
return true;
}

• 問題点: ネットワーク帯域の無駄遣い、CPUの無駄（JSON.parse / stringify が隠れている場合さらに悪化）。

⭕ 正しい設計（プロフェッショナル・パターン）

/

• ペイロードを一切動かさず、メタデータのみでセッションを延命しつつLRUの優先度を上げる

/
async function keepSessionAliveOptimized(redis: Redis, sessionId: string): Promise {
// TOUCHでアトミックにアクセス時間を更新し、EXPIREでTTLを再設定
// 実際にはパイプラインを使って1往復のネットワークで処理する
const pipeline = redis.pipeline();
pipeline.touch(`session:${sessionId}`);
pipeline.expire(`session:${sessionId}`, 3600);

const results = await pipeline.exec();

// TOUCHの結果（キーが存在したかどうか）を評価
const exists = results?.[0]?.[1] === 1;
return exists;
}

—

まとめ

Redisにおける `TOUCH` と `COPY` は、単なる便利コマンドではない。

• `TOUCH` は、「データを動かさずにコンテキスト（アクセス統計）だけを更新する」というネットワークとCPUの最適化の手段。
• `COPY` は、「サーバー内部で安全かつアトミックにデータを分岐させる」というデータ管理の柔軟性をもたらす武器。

これらを適切に使いこなせるかどうかが、ジュニアな「APIのラッパーとしてRedisを使うエンジニア」と、ハードウェアの特性から逆算してシステムを組み上げる「真のアーキテクト」の境界線だ。

次の設計レビューでは、不要な `GET` やアプリケーション層でのデータ複製コードを見つけ次第、迷わずこのコマンドへの置き換えを指示してほしい。君たちのシステムのレイテンシとメモリ効率は、確実に次のステージへ到達する。