specsfy-specialist-redis

Redis

使用するタイミング

• Redis／Valkey を使ったキャッシュ、セッション、レートリミッター、分散ロック、シンプルなキューまたはストリームの設計や、キャッシュスタンピード、ホットキー、予期しないエビクション、可用性の問題の診断に使用します。
• 本番環境での永続化（RDB／AOF）、Cluster／Sentinel、メモリポリシーの設定を確認する場合にも使用します。
• 永続データのモデル化には使用しません。Redis は高速化のための仕組み、または一時的なデータ構造です。正とするデータソースとその整合性は、$specsfy-specialist-postgres（または該当するデータベース）の担当です。
• 本番環境のキャッシュメトリクスとアラートには $specsfy-specialist-observability と連携し、アプリケーションのキャッシュ／キュードライバーが Redis の場合は $specsfy-specialist-laravel／他のフレームワークとも連携します。

フロー

1. データの目的（キャッシュ、セッション、キュー、ロック、カウンター）、source of truth、必要な一貫性、Redis が空の状態で再起動した場合にそのデータを失っても許容できるかを定義します。
2. カーディナリティ、値の平均サイズ、読み書きの頻度、必要な TTL、アクセスパターン（ランダム、連続、ホットキーへの集中）を見積もります。
3. データ構造と、名前空間を持つ安定したキーのスキーマ（app:recurso:id）を選びます。キーのカーディナリティが爆発するほど動的なキーは避けます。
4. キャッシュスタンピード、無効化戦略、再試行、Redis が利用できない場合のアプリケーションの動作（fail open と fail closed）を明示的に設計します。
5. データの役割に応じて、メモリ上限、エビクションポリシー、永続化の有無を設定します。キャッシュは消失を許容できますが、ロックや業務カウンターは許容できません。
6. 同時実行（同じキーへの同時書き込み）、操作中の有効期限切れ、Redis の停止、復旧（再起動／フェイルオーバー後のコールドスタート）をテストします。
7. 解決策の準備が整ったと判断する前に、ヒット率、レイテンシ（p50／p99）、メモリ使用量、接続数、ホットキーを測定します。

パターン

• すべてのキャッシュキーに明示的な TTL を設定し、キーごとに無効化の責任者を定めます（書き込みイベント、短い TTL、またはその両方）。
• 本番環境で Redis のシングルスレッドのイベントループをブロックするコマンドは避けます。KEYS *、制御されたメンテナンス以外での FLUSHALL／FLUSHDB、大規模コレクションに対する LIMIT のない SORT は使用せず、反復処理にはカーソルを使う SCAN を使用します。
• 不変条件のために競合状態なしで「読み取りと書き込み」を行う必要がある場合は、ネイティブのアトミック操作（INCR、SETNX、GETEX）または Lua スクリプト（EVAL／EVALSHA。Redis がアトミックに実行）を使用します。
• 分散ロックはタイムアウトと検証可能な所有者を持つリースとして扱います。一意のトークンを SET key token NX PX ttl で生成し、GET key == token を確認してから DEL するスクリプトでのみ解放します。無条件の DEL は決して使用しません。
• 互換性のないワークロードでは、名前空間／論理データベースとエビクションポリシーを分離します。揮発性キャッシュと、エビクションできないデータ（キュー、ロック）を同じメモリポリシーで競合させません。
• スキーマのバージョンを埋め込まずにオブジェクトをシリアライズしないでください（将来の形式移行が困難になります）。また、必要性なく秘密情報（パスワード、生のトークン）を値に保存しないでください。Redis は秘密情報の保管庫ではありません。
• Redis をキューとして扱う前に、配信のセマンティクスを確認します。Pub/Sub は fire-and-forget 方式のため、購読者が不在の場合はメッセージが失われます。Streams のコンシューマーグループは、明示的な ACK を伴う at-least-once 配信を提供し、コンシューマー側で冪等な再処理が必要です。

アンチパターン

• TTL にジッターを加えないキャッシュ：多くのキーが同時に期限切れになると、データベースに対して thundering herd が発生します。TTL にランダムなばらつきを加えるか、 ロック／事前更新を使うことで、同時に発生するピークを避けられます。
• タイムアウト後に非冪等コマンドを無条件に再試行する：元のコマンドが 処理済みでも応答が失われていた場合、再試行によって 作用が重複します。冪等な操作または重複排除トークンを使用してください。
• 有効期間を制御していないキー（TTL なしの session:<uuid> が 永続的に蓄積するなど）：Redis が eviction を開始するか OOM で停止するまで、メモリが際限なく増加します。
• TTL なしで SETNX と DEL のみを使って分散ロックを実装する：DEL の前に プロセスがハングまたは停止すると、ロックが 無期限に残ります。
• デフォルトの maxmemory-policy（noeviction）を自動キャッシュとして扱う：noeviction では、 メモリ上限に達すると Redis は eviction せずに書き込みを拒否するため、 このエラーを処理しない場合、アプリケーションが停止します。

検証

• キャッシュミス、キャッシュヒット、操作中の期限切れ、シミュレーションした cache stampede、 Redis が利用できない状態をテストします。それぞれのシナリオについて、期待される動作を 「動くはず」ではなく、文書化します。
• 実際のトポロジーを再現する環境で、メモリ上限、eviction ポリシー、永続化、 フェイルオーバー（Sentinel／Cluster）を検証します。開発用の単一インスタンスだけで 検証してはいけません。
• 機密値をログに出力せずに、INFO、slow log（SLOWLOG GET）、クライアントの メトリクスを確認します。
• アプリケーションの動作をキャッシュあり／なしで比較し、キャッシュによって クリティカルパスに古いデータや不整合が持ち込まれていないことを確認します。
• 同じキーを競合する 2 つのプロセスで争うテストなしにロックを「安全」と宣言してはいけません。また、 再配信による再処理のテストなしにキューを「信頼できる」と宣言してはいけません。

関連スキル

• $specsfy-specialist-performance-engineering は、Redis によってボトルネックが軽減されるかを測定し、 負荷時のコスト、レイテンシのテール、リグレッションを確認します。
• $specsfy-specialist-postgres は、Redis が、真実の情報源と整合性をリレーショナルデータベースが担う データから派生したキャッシュである場合に使用します。
• $specsfy-specialist-observability は、本番環境のキャッシュのメトリクス、アラート、 ダッシュボードに使用します。
• $specsfy-specialist-laravel は、クライアントがフレームワークのキャッシュ／ キュー／セッションドライバーである場合に使用します。
• $specsfy-specialist-docker／$specsfy-specialist-docker-swarm は、 Redis／Sentinel／Cluster のパッケージ化と運用に使用します。

references/standards.md を読んで、データ構造、永続化、クラスター、 セキュリティ、キャッシュのパターンを確認してください。