Redisは反射的に「Redisを追加するだけ」でスローダウンの解決策として使われがちです。しかし、バックエンドエンジニアのツールキットの中で最も有用なツールの一つであることは確かですが、上手に使うには、Redisが実際に何であるかを理解することから始まります。それは単なるキャッシュではなく、インメモリデータ構造ストアです。高速で汎用的なリアルなデータ構造のストアとして捉えると、解決できる問題の範囲（キャッシング、レート制限、キュー、セッション、リーダーボード、ロック）が寄せ集めのように見えなくなり、一つのアイデアを多方面に応用したものとして見えてきます。

これはRedis Masterclassの冒頭記事であり、PostgreSQLシリーズを基盤としています：Redisは通常、Postgresのようなプライマリデータベースの代わりではなく、併用されます。

インメモリであることがすべて

RedisはRAM内にデータを保持します。この一つの事実が、その特性のほとんどを説明します。メモリからの読み取りはディスクからの読み取りより桁違いに高速であるため、Redisの操作は通常1ミリ秒を大幅に下回る時間で完了し、1インスタンスで非常に高いリクエストレートを処理できます。この速度が、データベースのラウンドトリップが遅すぎるホットパスでRedisがデフォルトの選択肢となる理由です。

トレードオフは、RAMがディスクより小さく高価で、揮発性であることです。Redisは後で説明する永続化オプションで耐久性に対応しますが、最初に持つべきメンタルモデルは、Redisがインメモリであるから高速であり、すべてを永久に保存する場所ではなく、高速アクセスが必要なデータに使用するということです。

単なるキーバリューストアではなく、データ構造ストア

よくある誤解は、Redisが単純なキーバリューストアで、文字列を入れて文字列を出力するだけだというものです。実際ははるかに多機能です。Redisはそれぞれ独自のコマンドを持つ本物のデータ構造を値として保存します：

  • 文字列：単純な値、カウンター、キャッシュされたブロブ用。
  • ハッシュ：ユーザー記録のようなフィールドを持つオブジェクト用。
  • リスト：順序付きシーケンスとシンプルなキュー用。
  • セット：一意なコレクションとメンバーシップチェック用。
  • ソート済みセット：リーダーボードや優先度キューなどのランク付けデータ用。
  • さらにストリーム、ビットマップ、HyperLogLog、地理空間インデックス、確率論的構造など。

これがRedisの汎用性を生み出しています。リーダーボードはソート済みセットです。レートリミッターは有効期限付きのカウンターです。ジョブキューはリストまたはストリームです。これらはすべて、Redisがアトミック操作で既に実装しているデータ構造であり、自前で構築する代わりにその動作を無料で得られます。このシリーズの残りの部分は、主にこれらの構造とそれらが可能にするパターンのツアーです。

Redisが得意なこと

強力なユースケースに共通する形状は、高速アクセスが必要な一時的なデータ、または再構築コストの低い信頼できるデータのコピーです。

  • キャッシング：高コストなクエリや計算の結果を保存して再実行を避ける。最も一般的な用途で、ここではモジュール全体の主題です。
  • セッションストレージ：リクエストごとに高速読み取りが必要で、プライマリデータベースに保存すべきでないユーザーセッション。
  • レート制限：ユーザーごと・ウィンドウごとのリクエスト数をカウントするもので、有効期限付きカウンターであり、まさにRedisが得意とするものです。
  • キューとジョブ処理：リストとストリームが多くのタスクキューシステムを支えています。
  • リアルタイム機能：リーダーボード、カウンター、pub/subメッセージング、プレゼンスなど、サブミリ秒の更新が必要なものすべて。
  • 分散協調：複数のアプリケーションサーバー間でのロックとセマフォ。

Redisが適さない用途

用途と同様に境界を知ることも重要です。Redisが誤ったツールとなるのは次のような場合です：

  • 重要なデータのプライマリデータベースとして必要とする場合。 Redisには永続化機能がありますが、そのモデルはリレーショナルデータベースの耐久性保証よりも速度を優先します。注文、支払い、ユーザーアカウントの信頼できる情報源はPostgresのようなデータベースとし、Redisは高速なレイヤーとして前面に配置すべきです。
  • データがメモリに収まらない場合。 RedisはすべてをRAMに保持するため、利用可能なメモリ予算を大幅に超えるデータセットは慎重な設計なしには適さず、ディスクベースのデータベースの方が適していることが多いです。
  • 複雑なクエリ、結合、またはアドホックレポートが必要な場合。 RedisにはSQL、結合、クエリプランナーがありません。そのデータ構造がサポートするアクセスパターンでは高速ですが、任意のクエリには設計されていません。

繰り返しの原則：Redisはプライマリデータベースを補完するものであり、置き換えるものではありません。Postgresが耐久性がありクエリ可能な信頼できる情報源を所有し、Redisがホットパスを高速化します。

持ち続けるべきメンタルモデル

Redisを、実際のデータベースの隣に置かれた、メモリ内に存在する高速でアトミックなデータ構造の箱として考えてください。問題がこれらの構造の一つ（カウンター、ランク付けセット、キュー、キャッシュ値）にマッピングされる場合、Redisはそれをクリーンに迅速に解決します。問題が耐久性、複雑なクエリ、またはRAMに収まらない量のデータを必要とする場合、それはデータベースの仕事です。よく構築されたシステムのほとんどは、それぞれが得意とする用途で両方を使用します。

この枠組みがあれば、このシリーズの残りの部分は、まずデータ構造自体、次にRedisの最も一般的な仕事であるキャッシングパターン、次にインフラストラクチャ用途（キュー、ロック、レート制限）、そして最後に本番環境でRedisを確実に運用するという進行として理解できます。

次に、文字列、ハッシュ、リスト、セット、ソート済みセットの概要と、それぞれが形作られた実際の問題について、具体的にコアデータ構造を見ていきます。

重要なポイント

  • Redisはインメモリデータ構造ストアであるため、操作はサブミリ秒であり、ホットパスで使用される理由です。
  • 単純なキーバリューストアではなく、文字列、ハッシュ、リスト、セット、ソート済みセットなどの本物のデータ構造をアトミックコマンドで提供します。
  • 強力な用途：キャッシング、セッション、レート制限、キュー、リアルタイム機能、分散協調。
  • RedisはPostgresのようなプライマリデータベースを補完するものであり、重要なデータの耐久性がありクエリ可能な信頼できる情報源ではありません。
  • データセットがメモリを超える場合、複雑なクエリと結合が必要な場合、または重要なデータのシステムレコードとして必要な場合に不向きです。

よくある質問

Redisとは正確には何ですか？

Redisはインメモリデータ構造ストアです。RAM内にデータを保持してサブミリ秒アクセスを実現し、単なるキーバリューストアではなく、文字列、ハッシュ、リスト、セット、ソート済みセットなどの本物のデータ構造をそれぞれ独自のアトミックコマンドで提供します。

Redisは単なるキャッシュですか？

いいえ。キャッシングは最も一般的な用途ですが、Redisはレート制限、セッションストレージ、ジョブキュー、リーダーボード、pub/subメッセージング、分散ロックも駆動します。それぞれが組み込みデータ構造の一つにマッピングされるためです。

Redisは私のデータベースを置き換えられますか？

重要なデータについては通常できません。Redisはリレーショナルデータベースの耐久性とクエリ機能よりも速度を優先し、すべてをメモリに保持します。耐久性のある信頼できる情報源を所有するPostgresのようなプライマリデータベースと併用し、Redisがホットパスを加速させるようにします。

Redisが非常に高速な理由は？

データをメモリに保存し、RAMからの読み取りがディスクからの読み取りよりはるかに高速であるため、操作が1ミリ秒を大幅に下回る時間で完了します。データ構造にも効率的で目的に特化したコマンドがあります。

Redisを使用すべきでない場合は？

データセットが利用可能なRAMよりはるかに大きい場合、複雑なクエリ、結合、アドホックレポートが必要な場合、または重要なデータの耐久性のあるシステムレコードとして必要な場合です。これらはディスクベースのデータベースの仕事です。

参考文献

この記事は元々 amanksingh.com/blog/redis-what-and-why で公開されました。

著者について

Aman Kumar Singhはインド・ノイダを拠点とするチームリード兼シニアソフトウェアエンジニアで、TypeScript、Next.js、NestJS、PostgreSQL、Redisを使用したフルスタックエンジニアリング、システム設計、本番SaaSについて執筆しています。