Redis Cluster と Redis Sentinel:適切なアーキテクチャを選択するための明確な専門ガイド

実稼働システムでの Redis の使用が増加するにつれて、チームは最終的にアーキテクチャ上の重要な決定に直面します。 Redis は Redis Sentinel または Redis Cluster を使用してスケーリングする必要がありますか?

この決定は、多くの場合、パフォーマンスの問題、メモリの枯渇、または可用性に関するインシデントが発生した後に、遅く、プレッシャーの下で行われます。残念ながら、Redis Sentinel と Redis Cluster は解決する問題が大きく異なるため、間違ったものを選択すると、痛みを伴う再設計が必要になります。

Redis Sentinel は可用性を重視します。 Redis Cluster はスケーラビリティを重視します。この 2 つを混同することは、Redis アーキテクチャで最もよくある間違いの 1 つです。

Redis Sentinel が解決する中心的な問題

Redis Sentinel は、単一の Redis データセットに高可用性を提供するように設計されています。

その主な責任は次のとおりです。

• Redis マスター ノードとレプリカ ノードのモニタリング

• 障害の検出

• 自動フェイルオーバーの実行

• 新しいマスターについてクライアントを更新しています

Redis Sentinel はデータをシャーディングしません。すべてのキーを保持する論理 Redis インスタンスは依然として 1 つだけ存在します。

マスターに障害が発生した場合、Sentinel はレプリカを昇格させます。アプリケーションの観点から見ると、Redis は最小限の中断で動作を継続します。

Redis Sentinel の内部動作

一般的な Redis Sentinel セットアップには次のものが含まれます。

• 1 つの Redis マスター

• 1 つ以上の Redis レプリカ

• 複数の Sentinel プロセスが監視しています

センチネルは常にマスターの健康状態をチェックします。 Sentinel の定足数がマスターがダウンしていることに同意すると、フェイルオーバーがトリガーされます。

1 つのレプリカがマスターに昇格され、残りのレプリカはそれに従うように再構成されます。

重要な点は、データのサイズと形状が同じままであるということです。キーの再配布はありません。

Redis Sentinel が実行しないこと

Redis Sentinel は次のことを行いません:

• 単一ノードを超えてメモリ容量を増やす

• 1 コアを超えて書き込みスループットを向上

• データをシャーディングまたは分散する

Redis インスタンスのメモリまたは CPU が不足している場合、Sentinel を追加しても役に立ちません。 Sentinel は、Redis を大きくするのではなく、利用可能な状態に保ちます。

Redis クラスターが解決する中心的な問題

Redis Cluster は、可用性のみではなくスケーラビリティに対応します。

これで解決します:

• 単一マシンのメモリ制限

• シングルスレッド実行によるスループット制限

Redis Cluster は、複数のマスター ノードにまたがってデータをシャーディングします。各マスターはキースペースのサブセットを所有します。

レプリケーションは可用性のために使用されますが、シャーディングが特徴です。

Redis クラスターの高レベルでの動作

Redis クラスタは、キースペースを 16,384 のハッシュ スロットに分割します。

各マスター ノードは、これらのスロットの一部を所有します。キーはハッシュ関数に基づいてスロットに割り当てられます。

クライアントがコマンドを発行すると、そのスロットを担当するノードにルーティングされます。

マスターに障害が発生した場合、Sentinel と同様に、そのレプリカの 1 つが自動的に昇格されますが、そのシャードのみが対象となります。

可用性モデルの比較

Redis Sentinel は以下を提供します:

• 一度に 1 つのアクティブなマスター

• 単一ノード上の完全なデータセット

• 自動フェイルオーバー

Redis クラスターは以下を提供します:

• 複数のマスター

• データはノード間で分散されます

• シャード レベルでのフェイルオーバー

Sentinel はノード障害から保護します。クラスターは、ノード障害と容量制限の両方から保護します。

スケーリング特性

Redis Sentinel は垂直方向にスケーリングします。

Redis をより大きなマシンに移動したり、メモリを追加したり、より高速な CPU を使用したりすることはできますが、それでも上限に達します。

Redis クラスターは水平方向にスケールします。

ノードを追加してメモリとスループットを向上させます。各ノードはデータセットの一部のみを処理します。

単一の Redis ノードでは不十分になると、Sentinel だけでは不十分になります。

アプリケーション設計への影響

Redis Sentinel はアプリケーションに対してほとんど透過的です。

アプリケーションは依然として 1 つの Redis インスタンスと通信していると認識します。クライアントはフェイルオーバー後に新しいマスターに再接続します。

Redis クラスタにはクラスタ対応クライアントが必要です。

アプリケーションは次のことを行う必要があります。

• リダイレクトを処理する

• ハッシュ スロットの境界を尊重する

• サポートされていない複数キー操作を避ける

クラスタの導入は、主要な設計とデータ モデリングに大きな影響を与えます。

複数キーの操作とトランザクション

Redis Sentinel を使用する場合:

• すべてのキーは 1 つのマスター上に存在します

• マルチキー操作は正常に動作します

• トランザクションと Lua スクリプトは期待どおりに動作します

Redis クラスターの場合:

• キーは別のノードに存在する可能性があります

• マルチキー操作は同じハッシュ スロット内でのみ機能します

• クロススロット操作は失敗します

多くの場合、この 1 つの違いが、Redis Cluster に移行するチームにとって最大のショックとなります。

運用の複雑さ

Redis Sentinel では、運用が適度に複雑になります。

あなたが管理するもの:

• マスターとレプリカ

• センチネル定足数

• フェイルオーバー動作

Redis Cluster では、大幅に複雑さが生じます。

あなたが管理するもの:

• 複数のマスターとレプリカ

• スロットの割り当てとバランス

• リシャーディング操作

• クライアントの互換性

クラスタには、より強力な運用規律が必要です。

Redis Sentinel が正しい選択である場合

Redis Sentinel は次の場合に適しています。

• データセットは 1 台のマシンに快適に収まります

• 書き込みスループットは単一コア内に収まります

• 高可用性が必要です

• アプリケーション ロジックは複数のキー操作に依存します

多くのシステムは Sentinel だけで何年も正常に動作します。

Redis クラスターが正しい選択である場合

Redis クラスターは次の場合に適しています。

• メモリ要件が単一ノードを超えています

• スループットのニーズは増大し続けています

• 水平方向のスケーリングが必要です

• アプリケーションはシャーディング用に設計できます

クラスタは、単なるフェイルオーバー メカニズムではなく、スケーリング戦略です。

移行でよくある間違い

チームはよく次のことを行います。

• Redis Cluster の導入が早すぎる

• Sentinel と Cluster は交換可能であると仮定します

• 重要な設計への影響を無視する

• マルチキーの制限を発見するのが遅すぎる

これらの間違いにより、通常、リファクタリングが急遽行われることになります。

簡単な決定ルール

次の場合に Redis Sentinel を使用します。

• データ モデルを変更せずに高可用性が必要

次の場合に Redis クラスターを使用します。

• Redis は 1 台のマシンを超えてスケールする必要があります

クラスタを選択した場合は、すぐに有効にしなくても、早めに設計してください。

概要

Redis Sentinel と Redis Cluster は、さまざまなシステム圧力に対処する補完的なテクノロジーです。 Sentinel は、単一のデータセットのサービス継続性を保証します。クラスターにより、Redis をマシン間で拡張できるようになります。正しいアプローチを選択するかどうかは、可用性とスケーラビリティのどちらがアーキテクチャ上の主要な要因であるかによって決まります。