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

「2015年3月にObjectRocket.com/blogで初公開」

Redis®は素晴らしいツールであり、テックコミュニティから絶大な支持を受けています。Antirezによる個人的な小規模プロジェクトとして始まったRedisは、今や業界標準のインメモリデータストアへと成長しました。その発展に伴い、Redisを正しく運用するためのベストプラクティスも確立されてきました。本記事では、Redisを正しく活用するための10の実践的なヒントを紹介します。

1. KEYSコマンドの使用をやめる

いきなり強い口調で始めるのは良くないかもしれませんが、これはおそらく最も重要なポイントです。Redisのインスタンスを調査する際、commandstatsを確認すると、KEYSコマンドが頻繁に実行されているケースをよく目にします。プログラマーの視点からすると、以下のような擬似コードは理にかなっているように思えるでしょう。

for key in 'keys *':
  doAllTheThings()

しかし、キー数が1,300万件にもなるような環境では、処理速度は大幅に低下します。KEYSコマンドの計算量はO(n)(nは返されるキーの数)であるため、複雑さはデータベースのサイズに依存します。さらに問題なのは、この操作が実行されている間、インスタンスに対して他のコマンドを一切実行できないという点です。

代わりに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. ハッシュを最大限に活用する

ハッシュは積極的に使いましょう。適切に活用すれば、その利便性に驚くはずです。筆者は以下のようなキー構造を何度も目にしてきました。

foo:first_name
foo:last_name
foo:address

この例では、fooがユーザーのユーザー名だとすると、各行が個別のキーになっています。この構造はミスを招きやすく、不要なキーが増えてしまいます。代わりにハッシュを使えば、キーはたった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(Time To Live)を設定する

可能な限り、キーに有効期限を設定しましょう。代表的な例が、一時的な認証キーの保存です。OAUTHなどを例にとると、認証キーを取得する際に有効期限が付与されるのが一般的です。キーを保存するときに同じ有効期限を設定しておけば、Redisが自動的にクリーンアップしてくれます。KEYSで全キーを走査して削除する必要はもうありません。

6. 適切な退避(エビクション)ポリシーを選ぶ

キーのクリーンアップに関連して、退避ポリシーについても触れておきましょう。Redisインスタンスが容量上限に達すると、Redisはキーの退避を試みます。ユースケースによりますが、有効期限付きのキーを使用している場合はvolatile-lruを強く推奨します。キャッシュのように有効期限を設定せずに運用している場合は、allkeys-lruの検討も有効です。利用可能なオプションについては、公式ドキュメントで必ず確認してください。

7. 重要なデータにはtry/exceptを入れる

データが確実にRedisインスタンスへ書き込まれることが極めて重要な場合は、try/exceptによる例外処理を強く推奨します。多くの開発者はRedisクライアントをfire-and-forget(送信後は結果を確認しない)モードで設定しているため、キーが実際にはデータベースに届かなかった場合への備えが必要です。この場合に追加される処理のオーバーヘッドはごくわずかであり、重要なデータが確実に正しい場所に保存されることを保証できます。

8. 1つのインスタンスに負荷を集中させない

可能な限り、ワークロードを複数のRedisインスタンスに分散させましょう。バージョン3.0.0以降ではRedis Clusterが利用可能です。Redis Clusterを使えば、キーの範囲に基づいてプライマリとセカンダリのセット間でキーを分割できます。クラスタリングが選択肢に入らない場合は、ネームスペースを活用してキーを複数インスタンスに分散させることを検討してください。データのパーティショニングについては、redis.ioの公式サイトに優れた解説記事があります。

9. コア数が増えればパフォーマンスは向上する?

答えはノーです。Redisはシングルスレッドのプロセスであり、永続化を有効にした場合でも、消費するコアは最大で2つ程度です。同じホスト上で複数のインスタンスを実行する予定がない限り(それは開発・テスト用途のみに留めるべきですが)、Redisインスタンスに2つ以上のコアは必要ありません。

10. 高可用性(HA)構成を導入する

Redis Sentinelは現在十分に検証されており、多くのユーザーが本番環境で稼働させています(Rackspace ObjectRocketもその一つです)。アプリケーションがRedisに大きく依存しているのであれば、サービスを止めないために高可用性(HA)ソリューションの導入を検討すべきです。もちろん、自分で運用管理したくない場合は、Rackspace ObjectRocketが24時間365日のサポート付きHAプラットフォームを提供しています。ぜひ試してみてください。

Rackspace DBA Servicesの詳細については、公式サイトをご覧ください。

コメントやご質問がある場合は、フィードバックタブをご利用ください。また、Sales Chatをクリックして、今すぐチャットで会話を始めることもできます。