Redis レプリケーションと高可用性をマスターする:実稼働環境のための実践ガイド

はじめに

すべてが正常であれば、Redis は盤石であると感じます。本当の試練は何かが壊れたときに始まります。ノードがクラッシュしたり、仮想マシンが再起動したり、コンテナが消失したり、ネットワークの問題によりシステムの一部が切り離されたりします。

次に何が起こるかは、レプリケーションと高可用性がどのように設計されているかに完全に依存します。多くのチームは、Redis が障害を自動的に処理すると想定していますが、そうではありません。 Redis は完成したソリューションではなく、構築ブロックを提供します。

レプリケーションと高可用性はさまざまな問題を解決します。 Redis は両方をサポートしていますが、復元力のある本番システムを構築するには、違いを理解することが重要です。

Redis レプリケーションが実際に行うこと

Redis レプリケーションの核心は、あるノードから別のノードにデータをコピーすることです。一般にマスターと呼ばれるプライマリ ノードは、すべての書き込み操作を処理します。 1 つ以上のレプリカ ノードは継続的な変更ストリームを受信し、データの同期を維持します。

レプリケーションが存在する主な理由は、読み取りスケーリング、フェイルオーバーの準備、データの冗長性という 3 つです。ただし、レプリケーションだけでは高可用性が保証されません。構築するために必要な材料のみが提供されます。

内部でレプリケーションがどのように機能するか

レプリカがマスターに接続すると、初期同期プロセスが開始されます。マスターは現在のデータのスナップショットを作成し、それをレプリカに送信します。レプリカはこのスナップショットをメモリにロードします。

最初の同期の後、マスターは後続のすべての書き込みコマンドをレプリカにストリーミングします。レプリカは、一貫性を保つためにこれらのコマンドを同じ順序で適用します。

このアプローチは効率的でシンプルですが、重要なトレードオフが生じます。レプリケーションはデフォルトで非同期です。つまり、データがマスターには存在するがレプリカにはまだ存在しない小さなウィンドウが常に存在します。

非同期レプリケーションとデータ損失のリスク

非同期レプリケーションにより、Redis は高速かつ応答性を維持できますが、マスターに障害が発生した場合には一部のデータが失われる可能性もあります。

レプリカが最新の書き込みを受信する前にマスターがクラッシュすると、それらの書き込みは失われます。 Redis はこの現実を隠そうとしません。キャッシュ データの場合、これは通常許容されます。重大な状態の場合は、そうでない可能性があります。

Redis にはレプリケーションをより厳密にするオプションが用意されていますが、保証を厳密にするとレイテンシが増加し、可用性が低下します。どの程度のデータ損失を許容できるかを決定することは、アーキテクチャ上の重要な決定です。

レプリカを使用して読み取りをスケールする

Redis レプリケーションを使用する一般的な理由の 1 つは、読み取りトラフィックを拡張することです。アプリケーションは書き込み操作をマスターに指示し、読み取り操作をレプリカ全体に分散できます。

これにより、マスターの負荷が軽減され、全体的なスループットが向上します。ただし、レプリケーションは非同期であるため、レプリカはわずかに古いデータを返す可能性があります。

プロファイルや構成のキャッシュなどの使用例では、通常はこれで問題ありません。強い整合性が必要なシナリオでは、受け入れられない可能性があります。チームはこのトレードオフを意図的に行う必要があります。

マスターに障害が発生した場合に何が起こるか

レプリケーションだけではマスター障害に対処できません。マスターがダウンしても、レプリカは同期を保ちますが、外部フェイルオーバー メカニズムがなければ自動的に昇格されません。

高可用性には、障害を検出し、決定を調整し、新しいマスターを昇格するための何かが必要です。ここでフェイルオーバー システムが活躍します。

Redis Sentinel と高可用性

Redis Sentinel は、Redis に高可用性を追加するための従来のソリューションです。 Sentinel プロセスは Redis インスタンスを監視し、障害を検出し、相互に通信して合意に達します。

Sentinel がマスターがダウンしていることに同意すると、レプリカの 1 つが新しいマスターに昇格します。また、センチネルはクライアントに通知して、クライアントが正しいノードに再接続できるようにします。

Sentinel では、追加のコンポーネントと複雑さが導入されています。有効にするには、複数の Sentinel ノードが実行されている必要があります。真の高可用性を実現するには、単一の Sentinel では十分ではありません。

Sentinel がフェイルオーバーを決定する方法

Sentinel はタイムアウトとクォーラムを使用して、誤ったフェイルオーバーを回避します。昇格が発生する前に、複数のセンチネルがマスターに到達できないことに同意する必要があります。

この設計により信頼性は向上しますが、フェイルオーバーは即時ではないことを意味します。マスターが利用できなくなり、代わりのアクティブなマスターが存在しない時間は常に短期間存在します。

アプリケーションは、このウィンドウを適切に処理できるように設計する必要があります。再試行、タイムアウト、フォールバック動作は不可欠です。

Redis クラスターと組み込みの高可用性

Redis Cluster は、レプリケーションとフェイルオーバーをシステムに直接統合します。各シャードにはマスターとレプリカがあり、マスターに障害が発生するとフェイルオーバーが自動的に発生します。

これにより Sentinel の必要性がなくなりましたが、他の制約が生じます。キーの配布、クライアントの動作、シャード間の操作には慎重な設計が必要です。

Redis Cluster は、より厳格なアーキテクチャ境界を課しながら、高可用性を簡素化します。

フェイルオーバーはダウンタイムゼロを意味するわけではありません

よくある誤解は、Redis フェイルオーバーはダウンタイムゼロを保証するというものです。実際には、フェイルオーバーは高速ですが、瞬時ではありません。

フェイルオーバー中、一部のリクエストは失敗するか、再試行が必要になります。適切に設計されたシステムは、この動作を予期し、正常に回復します。システムの設計が不十分だと、クラッシュしたり、連鎖的な障害が発生したりする可能性があります。

高可用性は、完璧ではなく回復力を向上させます。

スプリット ブレインとそのリスク

スプリット ブレインは、複数のノードが自分がマスターであると信じている場合に発生します。 Redis と Sentinel はこれを防ぐように設計されていますが、ネットワークの分割や構成ミスが原因で発生する可能性は依然としてあります。

スプリット ブレインにより、書き込みの競合やデータの破損が発生する可能性があります。このリスクを軽減するには、適切な Sentinel クォーラム、正しいネットワーク設定、適切なタイムアウトが必要です。

これらの詳細を無視すると、まれではあるが重大なインシデントが発生する一般的な原因になります。

レプリケーションの遅延とパフォーマンスへの影響

通常、レプリケーション ラグは小さいですが、ゼロになることはありません。書き込み負荷が高い場合、レプリカはマスターに遅れる可能性があります。

遅延が大きい期間にフェイルオーバーが発生すると、データ損失が増加します。レプリケーション ラグの監視は、データの整合性が重要なシステムにとって不可欠です。

ラグの突然の増加は、多くの場合、根本的なパフォーマンスまたはリソースの問題を示しています。

レプリケーションがバックアップではない理由

レプリケーションをバックアップと混同しないでください。マスター上でデータが削除されると、その削除はすぐに複製されます。

バックアップは人的エラーや論理的な破損から保護します。レプリケーションはハードウェアまたはプロセスの障害から保護します。 Redis が貴重なデータを保存する場合は両方が必要です。

Redis HA でよくある間違い

チームは、Redis の高可用性を設計する際に、同じ間違いを頻繁に犯します。これには、レプリケーションが高可用性であると仮定すること、Sentinel を 1 つだけ実行すること、レプリケーションのラグを無視すること、フェイルオーバーのテストに失敗すること、Redis エラーでアプリケーションがクラッシュすることを許可することが含まれます。

こうした間違いは、現実世界の停止レポートで繰り返し現れます。

設計の一部としてのテストの失敗

決してテストされていない高可用性は、紙の上でのみ存在します。チームは、制御された環境でマスターを停止して、障害を定期的にシミュレートする必要があります。

フェイルオーバーの動作を観察し、回復時間を測定し、アプリケーションの応答を理解することにより、いかなる文書にも代わることのできない貴重な洞察が得られます。

Redis HA の実践的なメンタル モデル

Redis の高可用性は、正常な劣化を実現します。 Redis が正常であれば、システムは良好に動作します。 Redis が異常になると、パフォーマンスが低下する可能性があります。 Redis が利用できない場合でも、システムは存続するはずです。

Redis のダウンによりシステム全体が停止した場合、高可用性は不完全になります。

概要

Redis レプリケーションと高可用性は、ストレス下でシステムがどのように動作するかを形成します。レプリケーションはデータのコピーを提供し、高可用性はサービスの継続性を提供します。

どちらも慎重な設計、現実的な期待、継続的なテストが必要です。正しく実装すると、Redis の障害は重大なインシデントではなく日常的なイベントになります。それが Redis の高可用性の目標です。