Redis名前空間の使い方と開発者が知るべきキー設計のベストプラクティス5選

Redisを使ったアプリケーション開発はとても魅力的ですが、あらゆる技術と同様に、設計段階で押さえておくべき重要なポイントがいくつか存在します。リレーショナルデータベースの開発経験があれば、共通するプラクティスも多いことに気づくでしょう。ただし、Redisはインメモリデータベースであり、ほぼシングルスレッドで動作するという特徴を持っています。本記事では、Redisのキー設計におけるベストプラクティスを詳しく解説します。

こうした特性から、Redisを利用する際には以下のような点に特に注意が必要です。

1. Redis名前空間でキーを適切に管理する

データベースはデータを保存するものですが、アプリケーションの要件変更や保存方式の見直しなどによって、Redisへ投入したデータの一部を誰もが見失うことがあります。EXPIREの設定を忘れてしまったキーや、すでに廃止されたモジュールに関連するキーが残っているケースも少なくありません。

いずれの場合でも、使われていないデータがディスクやメモリのスペースを無駄に占有している可能性は高くなります。Redisはスキーマレスな構造のため、キーに一貫した命名規則を採用しない限り、データセットの中身を把握することは非常に困難です。

そこで役立つのがRedis名前空間です。アプリケーションやサービス単位でキーを名前空間化する際の慣習として、コロン（:）を使ってキー名の各要素を区切る方法が広く採用されています。この命名規則を守ることで、データ移行・変換・削除・移動の際に該当キーを簡単に識別できるようになり、データベースの保守管理が格段に楽になります。

さらに、Redisのもうひとつの一般的なユースケースとして、「ホット」なデータを扱うセカンダリデータストアとして利用し、大半のデータはPostgreSQLやMongoDBなどの別データベースに保管する構成があります。この場合、開発者がプライマリデータストアからデータを移した際に、Redis側のデータ削除を忘れがちになる点に注意しましょう。

このようなクロスデータストア間の依存関係にはカスケードデリートが必要です。具体的には、対象データの識別子をすべてRedisのセットに保持しておくことで実現できます。こうしておけば、プライマリデータストアからの削除後に呼び出されるクリーンアップ処理は、そのセットの内容を走査するだけで、関連するすべてのコピーと付随データ（完了時にはセット自体も含む）を確実に削除できます。

2. キー名の長さに注意する

先述のRedis名前空間の話と矛盾して聞こえるかもしれませんが、キー名自体もメモリを消費するため、できるだけ短く保つ努力が必要です。数百万〜数十億規模のキーを扱うデータセットでは顕著な問題となりますが、実際のところ、長いキー名はどのようなハッシュテーブルにおいてもコストがかかります。

具体例を挙げましょう。32文字の値を持つキーを100万個保存する場合、6文字のキー名なら約96MB、12文字のキー名なら約111MBのメモリを消費します（32ビット版Redisサーバーの場合）。この15%を超えるオーバーヘッドは、キー数の増加に伴って深刻な影響を及ぼします。

3. 適切なデータ構造を選ぶ

メモリ効率やパフォーマンスの観点から、データの特性に応じて最適なデータ構造は変わります。ここでは、覚えておきたいベストプラクティスを紹介します。

• 数千〜数百万個の独立した文字列値としてデータを保存する代わりに、ハッシュ型で関連データをまとめることを検討しましょう。ハッシュは非常に効率的で、メモリ使用量を抑えられるだけでなく、実装の詳細を抽象化してコードの可読性を高めるというメリットもあります。
• 条件が合えば、セットの代わりにリストを使いましょう。一意性の担保やメンバーシップ確認のためにセットの特性が必要ないのであれば、リストの方がメモリ消費が少なく、挿入処理も高速です。
• ソート済みセットは、メモリ消費量および基本操作のコスト（例：ZADDによる新規メンバー追加）の両面で、最も負荷の高いデータ構造です。スコアの参照だけが必要で順序が重要でない場合は、ハッシュの利用を検討してください。
• Redisで見落とされがちな機能のひとつが、ビットマップ（ビットセット）です（v2.2以降で利用可能）。ビットセットを使えばRedisの値に対してビット単位の操作を行え、大量のデータを効率的に保存できます。軽量なアクセス解析などへの活用が可能です。

4. KEYSではなくSCANを使う

SCANコマンドはRedis v2.8以降で利用可能となり、カーソルを使ってキースペースからキーを段階的に取得できます。この挙動はKEYSコマンドとは対照的です。KEYSは一致する全要素を一度に返しますが、Redisサーバーをブロックし、RAMリソースを枯渇させる恐れがあるため、本番環境での使用は危険とされています。一方、SCANならサーバーをブロックするリスクやスレーブへの依存なく、安全にデータを検査できます。

なお、SCANでは次回のSCAN呼び出しに渡すカーソル値を読み取る必要があります。また、キー名のパターンとオプションのCOUNT引数も指定できます。もうひとつの違いとして、SCANでは同一のキー名が複数回返される可能性がある点に留意してください。

さらに、SCANにはSSCAN、HSCAN、ZSCANという仲間があり、それぞれセット・ハッシュ・ソート済みセットの内容を反復処理できます。

5. サーバーサイドのLuaスクリプトを活用する

RedisがLuaスクリプトの実行に対応していることは、開発者にとって大きな武器になります。Luaは習得しやすい言語のひとつで、Redisサーバー内部で動作するコードとして自由にロジックを記述できます。適切に活用すれば、パフォーマンスとリソース消費の両面で劇的な改善が期待できます。アプリケーション側のCPUにデータを引き寄せるのではなく、データの近くでロジックを実行することで、ネットワークレイテンシと冗長なデータ転送を削減できるのです。

Luaの効果が如実に現れる典型例が、Redisから大量のデータを取得してアプリケーション側でフィルタリングや集計を行うケースです。処理フロー全体をスクリプトにカプセル化すれば、呼び出し一回で大幅に小さい結果を、ごくわずかな時間とリソースで取得できます。

プロのコツ： Luaは強力ですが、ワークフローを移行するとエラーの検出やハンドリングが難しくなる場合があります（結局のところRedisサーバー内部で動作しているためです）。これを回避する賢い方法のひとつが、RedisのPub/Subを利用することです。スクリプトから専用チャネルへ「ログ」メッセージをパブリッシュし、サブスクライバーとなるプロセスを用意してメッセージを受け取り、適切に処理する仕組みを作りましょう。

Redisを活用する中で、まだまだ多くの重要なヒントに出会うことでしょうが、このリストは最重要ポイントを押さえる良い出発点となるはずです。他におすすめのTipsやフィードバック、ご質問があれば、ぜひお気軽にお寄せください。