「商品ページが表示されないんだけど」
リリース直後のテストで、先輩から声がかかった。開発チームが集まって原因を探り始める。誰かが「Redisのキャッシュ見てみようか」と言っている。
当時の俺は、Redisという単語は聞いたことがあったが、実際に何をするものなのか、どう確認すればいいのか全く分からなかった。結局、その場では何もできず、ただ見ているだけだった。
後で聞いたら、原因はRedisのキャッシュ設定ミスだったらしい。もし基礎知識があれば、もっと早く原因特定に貢献できたはずだ。
あの日から、Redisは避けて通れない技術だと痛感している。今回は、現場で実際に使っているRedisについて共有したい。
Redisって結局何なの？
Redisはインメモリ型のKey-Valueストアだ。簡単に言えば、データベースとアプリケーションの間に挟まる「高速キャッシュ層」として機能する。
例えば、ECサイトで商品情報を取得するAPIがあるとする。
Redisなしの場合：
- ユーザーがリクエスト
- 毎回データベースにアクセス
- レスポンスが遅い
Redisありの場合：
- 初回リクエスト → データベースから取得 → Redisに保存
- 2回目以降 → Redisから高速取得
- レスポンスが劇的に速くなる
つまり、よく使うデータをメモリに置いておくことで、システム全体のパフォーマンスを向上させる仕組みだ。
TTL（有効期限）の仕組み
Redisに保存したデータは、TTL（Time To Live）を設定できる。
# 商品情報を60秒間キャッシュ
SET product:1001 "{\"name\":\"ノートPC\",\"price\":89800}" EX 60
60秒経過すると、このキーは自動で削除される。古いデータがずっと残らないようにする仕組みだ。
なぜQAエンジニアがRedisを理解すべきなのか？
正直、最初は「開発者が使うものでしょ？」と思っていた。でも、実際の現場では違った。
1. 性能テストで必須
負荷テストを実施するとき、Redisの状態を確認できないと話にならない。
「なぜレスポンスが遅いのか？」
「Redisのヒット率は？」
「キャッシュが効いているのか？」
こういった質問に答えられないと、性能ボトルネックの特定ができない。
2. 画面に表示されないデータの検証
ユーザーセッション、在庫数、ログイン状態——これらはUIに直接表示されないが、Redisに保存されている。
画面だけ見ていても、内部で正しくデータが保持されているかは分からない。Redisを直接確認する必要がある。
3. 障害の原因切り分けが速くなる
「商品が表示されない」という不具合が発生したとき、
- データベースの問題？
- Redisのキャッシュ問題？
- アプリケーションのバグ？
Redisを確認できれば、原因の切り分けが圧倒的に速くなる。
4. 開発者との会話がスムーズになる
「ホットキーの期限切れ対策してる？」
「Cache Avalancheのリスクは？」
こういった会話に参加できると、開発チームからの信頼も上がる。
押さえておきたいRedisの基本
Key-Valueストアの仕組み
すべてのデータはKey（キー）でアクセスする。
# ユーザー情報のキー例
user:123:profile
user:123:cart
session:abc123
コロン（:）で区切るのが一般的で、可読性が高くなる。
インメモリだから速い、でも揮発性
Redisはメモリ上にデータを保持するため、読み書きが超高速だ。
ただし、サーバーが再起動するとデータは消える（永続化設定をしていない場合）。
これがRedisの特徴であり、制約でもある。
データ型は5種類を押さえておけばOK
Redisは単なる文字列だけでなく、複数のデータ型をサポートしている。
| データ型 | 特徴 | 使用例 | テストで確認すること |
|---|---|---|---|
| String | シンプルなKey-Value | カウンタ、HTML断片、分散ロック | 値の正しさ、数値の増減 |
| Hash | 複数フィールドを持つ辞書型 | ユーザー情報、設定情報 | 特定フィールドの値 |
| List | 順序付きリスト | キュー、タイムライン | 順序、要素数 |
| Set | 重複なしの集合 | タグ、抽選、重複排除 | 要素の存在確認 |
| Sorted Set | スコア付き集合 | ランキング、優先度付きキュー | 並び順とスコア |
現場で使うRedisコマンド
テスト環境では、redis-cliやGUIツール（AnotherRedisDesktopManagerなど）を使う。
基本コマンド
# キーの存在確認
EXISTS user:123
# キーの型を確認
TYPE user:123
# TTLを確認（-1:期限なし、-2:存在しない）
TTL session:abc123
# キーを削除
DEL test:user:999
# パターンマッチでキーを検索（本番環境では注意）
KEYS user:*
データ型別のコマンド
String型
# 値を取得
GET product:1001
Hash型
# 全フィールドを取得
HGETALL user:123:profile
# 特定フィールドを取得
HGET user:123:profile email
List型
# 全要素を取得
LRANGE queue:orders 0 -1
Set型
# 全要素を取得
SMEMBERS tags:article:1001
Sorted Set型
# スコア降順で取得（ランキング確認）
ZREVRANGE ranking:daily 0 9 WITHSCORES
実際のテストケース
ケース1：商品キャッシュの検証
商品詳細APIを叩いた後、Redisに正しくキャッシュされているか確認する。
# APIリクエスト後
GET product:detail:1001
# 期待結果：商品情報のJSON
もしキャッシュされていなければ、キャッシュロジックに問題がある可能性が高い。
ケース2：在庫数の確認
セール商品の在庫をRedisで管理している場合、購入前後で数値が正しく減っているか確認する。
# 購入前
GET seckill:stock:1001
# 結果：100
# 購入後
GET seckill:stock:1001
# 結果：99
ケース3：セッション情報の検証
ログイン後、セッション情報がRedisに保存されているか確認する。
HGETALL session:abc123
# 期待結果
# user_id: 123
# login_time: 2025-12-02 10:00:00
# role: admin
ケース4：テストデータのクリーンアップ
テスト終了後は、テストデータを削除する。
DEL test:user:999
DEL test:order:*
注意： FLUSHDBは全データを削除するので、本番環境では絶対に使わないこと。
現場でよく遭遇する4つの問題
Cache Penetration（キャッシュ貫通）
問題：
存在しないデータへのリクエストが大量に来ると、Redisをスルーしてデータベースに直接アクセスしてしまう。
テスト方法：
存在しないIDで連続リクエストを送り、データベース負荷を確認する。
# 存在しない商品IDで連続リクエスト
for i in {9999..10099}; do
curl "https://api.example.com/product/$i"
done
対策：
- 存在しないデータもRedisに「null」として保存
- Bloom Filterで事前チェック
Cache Breakdown（ホットキー期限切れ）
問題：
人気商品のキャッシュが期限切れになった瞬間、大量のリクエストがデータベースに殺到する。
テスト方法：
TTLが切れるタイミングで同時リクエストを発生させる。
# TTL確認
TTL product:hot:1001
# 期限切れ直前に負荷テスト
ab -n 1000 -c 100 https://api.example.com/product/1001
対策：
- 分散ロックで再取得を1リクエストに制限
- TTLをランダム化
Cache Avalanche（キャッシュ雪崩）
問題：
大量のキーが同時に期限切れになり、システム全体がダウンする。
テスト方法：
同じTTLを持つキーを大量に作成し、期限切れ時の挙動を確認する。
対策：
- TTLにランダムな値を追加（例：300秒 + ランダム0〜60秒）
- Redis Clusterで負荷分散
データ不整合
問題：
データベースを更新したのに、Redisのキャッシュが古いまま。
テスト方法：
- データベースを直接更新
- APIで取得した値を確認
- Redisの値を確認
# データベース更新後
GET product:1001
# 古い値が返ってきたら不整合
対策：
- Write-Through（書き込み時にキャッシュも更新）
- Cache-Aside（更新時にキャッシュを削除）
ApidogでRedis検証を自動化する
手動でRedisを確認するのは面倒だし、ミスも起きやすい。
Apidogを使えば、APIテストとRedis検証を一つのワークフローで自動化できる。
実際の使い方：
- APIリクエストを実行
- レスポンスを検証
- Redisの値を確認（カスタムスクリプトで実装）
- 結果を比較
これで、「APIは正常だけどRedisに保存されていない」といった問題を早期に発見できる。
手動CLIよりも再現性が高く、チーム全体で共有できるのが大きなメリットだ。
まとめ：Redisを理解すればテストの質が上がる
Redisは、もはやテストエンジニアにとって必須の技術だ。
最低限押さえておくべきこと：
- テスト環境のRedisに接続できる
-
KEYS、TYPE、TTLで基本情報を確認できる - データ型に応じたコマンドを使える（
GET、HGETALL、SMEMBERSなど） - Cache Penetration、Breakdown、Avalancheの概念を理解している
これができれば、性能テストも障害調査も、今よりずっとスムーズになる。
開発者との会話も噛み合うようになるし、「このQAエンジニア、分かってるな」と思われるはずだ。
Redisを理解することで、テストの質が一段階上がる。ぜひ、実際の現場で試してみてほしい。
この記事が役に立ったら、ぜひシェアしてくれ。質問やコメントがあれば、気軽に教えてほしい。
Top comments (0)