Redisを正しく使いこなすための10の実践テクニック

Redisは現在、技術コミュニティで非常に高い注目を集めています。Salvatore Sanfilippo（Antirez）氏の個人的な小さなプロジェクトとして始まったRedisは、今やインメモリデータストレージの業界標準へと成長しました。普及に伴い、Redisを適切に運用するためのベストプラクティスも確立されつつあります。本記事では、Redisを正しく活用するための10のヒントをわかりやすく解説します。

1. KEYS * の使用をやめる

冒頭から強い口調で申し訳ありませんが、これはおそらく最も重要なポイントです。Redisインスタンスのcommandstatsを確認すると、KEYSコマンドが頻繁に実行されているケースをよく目にします。プログラムの観点からは、次のような擬似コードは一見理にかなっているように思えるかもしれません。

for key in 'keys *':
  doAllTheThings()

しかし、たとえば1300万件ものキーが存在する場合、処理速度は大幅に低下します。KEYSは計算量がO(n)（nは返却されるキーの数）であり、その複雑さはdbsizeに依存します。さらに厄介なことに、この操作の実行中はインスタンスに対して他のコマンドを実行できません。

代わりにSCANを使いましょう。SCANはデータベースを増分方式でスキャンできるコマンドで、イテレータとして動作するため、必要に応じて処理を中断・再開できます。

2. Redisの遅延原因を特定する

Redisのログはあまり詳細ではないため、インスタンス内部で何が起きているのかを把握するのは容易ではありません。幸い、Redisにはcommandstatsという便利な機能が用意されています。

127.0.0.1:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10

この出力により、各コマンドの実行回数や、実行にかかった時間（合計および1回あたりの平均、単位はマイクロ秒）を詳細に把握できます。

統計をリセットしたい場合はCONFIG RESETSTATを実行するだけで、まっさらな状態から計測し直せます。

3. Redis-Benchmarkは基準として使い、絶対視しない

Redisの生みの親であるSalvatore氏は、こう語っています。「GET/SETでRedisをテストするのは、雨の日にフェラーリがサイドミラーをどれだけきれいに拭けるかを測るようなものだ」。実際、「Redis-Benchmarkの結果が期待より劣るのはなぜか」という相談を受けることが少なくありません。しかし、結果を評価する際には次のような要素を考慮する必要があります。

• クライアント側の制限（帯域や接続数など）に達していないか？
• テスト環境と本番環境でバージョンの違いはないか？
• 実施しているテストは、アプリケーションの実際のワークロードに関連しているか？

Redis-Benchmarkは、redis-serverが異常な動作をしていないかを確認するための優れた基準（ベースライン）になりますが、決して本物の「負荷テスト」として扱うべきではありません。本来の負荷テストは、本番環境にできるだけ近い環境で、実際のアプリケーションの振る舞いを反映したものであるべきです。

4. ハッシュ型を積極的に活用する

Redisの「ハッシュ（Hash）」は非常に強力なデータ構造です。以下のようなキー設計をよく見かけます。

foo:first_name
foo:last_name
foo:address

この例では、fooがユーザーIDなどを表し、属性ごとに個別のキーが作られています。この設計はミスの原因になりやすく、不要なキーが増えて管理も煩雑になります。代わりにハッシュを使えば、キーは1つで済みます。

127.0.0.1:6379> HSET foo first_name "Joe"
(integer) 1
127.0.0.1:6379> HSET foo last_name "Engel"
(integer) 1
127.0.0.1:6379> HSET foo address "1 Fanatical Pl"
(integer) 1
127.0.0.1:6379> HGETALL foo
1) "first_name"
2) "Joe"
3) "last_name"
4) "Engel"
5) "address"
6) "1 Fanatical Pl"
127.0.0.1:6379> HGET foo first_name
"Joe"

5. TTL（有効期限）を必ず設定する

可能な限り、キーに有効期限を設定しましょう。代表的なユースケースが、一時的な認証キーの保存です。認証キー（例：OAuthトークン）を取得する際、通常は有効期限が発行されます。キーを登録するときに同じ有効期限をSETEXなどで設定すれば、期限切れのキーをRedisが自動的に削除してくれます。こうすれば、KEYS *で全キーを走査してクリーンアップする必要はなくなります。

6. 適切なエビクションポリシーを選択する

キーのクリーンアップに関連して、メモリが満杯になったときの「エビクション（追い出し）ポリシー」にも触れておきましょう。Redisインスタンスのメモリが上限に達すると、設定されたポリシーに従ってキーが削除されます。有効期限付きのキーを運用しているならvolatile-lruを強くお勧めします。キャッシュ用途などで有効期限を設定していない場合はallkeys-lruの検討をおすすめします。その他のオプションについては、公式ドキュメントで各ポリシーの特性を確認してください。

7. 重要なデータにはtry/exceptでエラー処理を行う

データが確実にRedisへ書き込まれることが極めて重要な要件であるなら、try/exceptによる例外処理の実装を強く推奨します。多くのRedisクライアントは「fire-and-forget（送りっぱなし）」モードで動作するよう設定されているため、書き込みが実際には失敗するケースを常に想定しておくべきです。追加されるコードの複雑さはごくわずかですが、重要なデータが確実に保存先へ到達することを保証できます。

8. 単一インスタンスに負荷を集中させない

可能な限り、ワークロードを複数のRedisインスタンスへ分散させましょう。バージョン3.0.0以降、Redis Clusterが正式に利用可能になりました。Redis Clusterを使えば、キーの範囲（スロット）に基づいて、複数のマスター/スレーブ群にキーを自動的に分散できます。クラスタリングが採用できない環境では、名前空間（プレフィックス）を活用してキーを複数インスタンスへ手動で振り分ける方法もあります。データのパーティショニング手法については、redis.io公式サイトの解説が非常に参考になります。

9. CPUコアは多いほど良い？

答えはノーです。Redisはシングルスレッドで動作するプロセスであり、永続化（RDB/AOF）を有効にしても消費するのは最大2コア程度です。同一ホスト上で複数インスタンスを稼働させる予定でもない限り（それも開発・テスト用途に限るべきです）、Redisインスタンスに2コア以上を割り当てる必要性は基本的にありません。

10. 高可用性（HA）構成を導入する

Redis Sentinelは現在十分に検証されており、多くの企業が本番環境で運用しています。アプリケーションがRedisに大きく依存しているのであれば、サービスを止めないためにHA（High Availability／高可用性）ソリューションの導入を検討すべきです。Sentinelによる自動フェイルオーバー構成を組むことで、障害発生時にも迅速な復旧が可能になります。自前での運用が難しい場合は、24時間365日サポート付きのマネージドHAプラットフォームを提供しているサービス（ObjectRocketなど）を活用するのも一つの手です。