Redisのレプリケーションバックログを理解する：PSYNC、サイズ、およびHAの制限

仝 Redisのレプリケーション・バックログ 接続が切断された後、レプリカが欠落している変更のみを取得するか、データ全体を再転送されるかを決定する要因の一つとなります。 実際のレプリケーション量に基づいてバッファの容量を決定すれば、不必要な完全同期を回避できます。ただし、そのためにはレプリケーション履歴、ストレージ予算、運用プロセスも整合性が取れている必要があります。大きなバックログは、データの永続性や堅牢なフェイルオーバー戦略の代わりにはなりません。.

バックログには実際に何が保存されているのか

時点では Redisのレプリケーション プライマリはデータセットへの変更を処理し、そのレプリカに対して連続したコマンドストリームを送信します。これには、クライアントから直接書き込まれた値だけでなく、期限切れになったキーや上書きされたキーも含まれ、これらも変更を引き起こし、その変更をレプリカに伝達する必要があります。 バックログは、このレプリケーションストリームの直近の一部をメモリ内に保持しています。したがって、バックログにはデータベースの完全なコピーが追加で含まれているわけではなく、また、任意の古い書き込み操作のアーカイブでもありません。.

正常な稼働時には、レプリカは現在の流れに従います。接続が切断された場合、プライマリ上の履歴は引き続き蓄積されます。 再接続後、レプリカは以前の時点に追いつこうと試みます。その際、決定的なのは、必要なバイトがまだ保持されているかどうかです。もし保持されており、レプリケーション履歴が一致していれば、Redisはその差分を補完できます。その際、レプリカにすでに存在するデータを完全に置き換える必要はありません。.

その利点は、特に短時間のネットワーク障害、接続の切り替え、および予定されたメンテナンス作業の際に発揮されます。大規模なデータセットの完全な同期には、伝送容量と演算能力が必要となります。構成によっては、ストレージやデータキャリアへの負荷もさらに加わります。 バックログはこの負荷を軽減できますが、あらゆる形態の中断を吸収できるわけではありません。プロセスの再起動や履歴の変更は、一時的に切断されたTCP接続とは異なる観点からの検討を必要とします。.

PSYNCで十分な場合と、フルリシンクが必要な場合

A PSYNC による部分的な再同期 これには、レプリケーションIDとオフセットという2つの関連する情報が必要です。IDは特定のデータ履歴を識別します。オフセットは、レプリケーションストリーム内のバイト位置を表します。 したがって、異なる履歴における同じサイズのオフセットであっても、自動的に比較できるわけではありません。逆に、同じ履歴内でも、利用可能なバックログの容量が限られている場合、わずかな遅れであっても、すでに利用可能なバックログの範囲外にある可能性があります。.

簡単に言えば、レプリカは再接続時に、どこまで処理が進んでいたかを報告します。プライマリは、その後必要なデータを提供できるかどうかを確認します。履歴が不明であるか、必要な部分が欠落している場合は、 完全再同期 必要です。この際、レプリカには完全なデータセットが提供され、その後、同期中に発生した変更が反映されます。転送は、構成に応じて、RDBを介した中間ステップを経由してデータキャリアへ行うことも、その中間ステップを省略して行うことも可能です。.

フェイルオーバー後、必ずしもフル再同期が避けられないわけではありません。転送されたレプリカは、以前のレプリケーションIDとその有効なオフセット範囲を追加で記憶することができます。これにより、適切な条件が整えば、他のレプリカも既知の履歴に接続することが可能になります。 しかし、計画上、これが保証されるわけではありません。関連する範囲が引き続き利用可能である必要があり、具体的な再接続は保存されたIDと一致している必要があります。.

データベースのサイズを推測するのではなく、レプリケーション率を測定する

データセットの規模そのものが、 バックログの規模設定 そうとは限らない。主に読み取りが中心の大型データベースでは、レプリケーショントラフィックはほとんど発生しない。 一方、値が頻繁に変化し、タイムアウトイベントが多い小さなキャッシュは、継続的に膨大な量のデータを転送する可能性があります。また、1秒あたりの操作数の固定値だけでは、必要なストレージ容量を十分に説明することはできません。キーの小さな変更と値の大きな上書きでは、発生するバイト数が異なるからです。.

実用上有用な近似値は、以下の時間的な増加から得られる。 master_repl_offset. 同じプライマリで値を2回取得し、その差を経過秒数で割ってください。その際、レプリケーションIDも確認してください。 ロールチェンジや再起動の後、関連性のない2つの測定値を単純に差し引いてはなりません。また、単一の測定間隔からは、その間隔内の平均レートしか得られず、恒久的に保証された上限値ではありません。.

以下のクエリは診断情報を読み取ります。Redisの設定を変更することはありません。お使いの環境で必要な接続および認証オプションを指定して実行してください。以下に示す呼び出しでは、 redis-cli; 別のホスト、ポート、またはTLSアクセスについては、明示的に設定する必要があります。.

redis-cli INFO replication

通常の日常業務、インポート処理、大規模なキャッシュ更新時など、さまざまな負荷フェーズにわたって測定を行ってください。典型的なレートだけでなく、短時間のピーク値も記録してください。キーの有効期限切れによる変更が多数発生している場合は、内部記事でそのテーマについてさらに詳しく解説しています。 Redisのキーの有効期限を分析する. この関連性は計画立案において重要である。なぜなら、関連する執筆のきっかけのすべてが、必ずしも新しいユーザーからの問い合わせから直接生じるわけではないからである。.

バックログの規模を合理的に算出する

として 計画上の近似値 該当するレプリケーションレートに、対応すべき中断時間を掛け合わせ、その上に合理的な余裕時間を加算することができます。 この所要時間は、実際のネットワーク中断時間だけを考慮すべきではありません。検出、再接続の試行、および接続経路の復旧にも時間がかかる場合があります。どの程度の余裕が適切かは、観測された変動や望ましい運用目標によって決まるものであり、一律のパーセンテージで決まるものではありません。.

意図的に単純化した計算例：対象となる負荷フェーズについて、1秒あたり12 MiBと仮定する。接続が90秒間途切れる可能性があり、さらに30秒が時間的余裕として確保される。これに基づくと、以下のようになる。 12 MiB/s × 120 s = 1.440 MiB, 、つまり約1.41 GiBです。これらの数値は説明のための仮定であり、Redisのベンチマーク結果ではありません。本番環境での導入前には、これらの数値をアプリケーションの実際の測定値に置き換える必要があります。.

逆算を行うことで、既存のバッファの規模を把握するのに役立ちます。256 MiBのバックログが完全に満たされている場合、1秒あたり12 MiBのレートが一定であると仮定すると、計算上は約21秒分の履歴に相当します。1秒あたり2 MiBの場合、約128秒分となります。 しかし、実際の運用では転送レートは変動します。したがって、このような範囲はあくまでその時点での状況を示すものであり、この期間に発生したすべての障害について部分的な同期が可能であるという保証ではありません。.

また、再接続後にレプリカが、新たな変更が生じる速度よりも速く遅れを取り戻せるかどうかを確認してください。 履歴データを削除しても、恒久的に低速なネットワークや、恒久的に過負荷状態にある受信サーバーの問題は解消されません。遅れが解消されない、あるいはさらに拡大し続ける場合は、原因を調査する必要があります。単にストレージ容量を増やし続けるだけでは、問題を先送りするだけであり、システム全体にストレージ負荷をかけることになりかねません。.

Redisの設定を分かりやすく、かつ管理しながら変更する

パラメータ repl-backlog-size そして repl-backlog-ttl それぞれ異なる項目を制御します。1つ目は、想定されるバックログのサイズを指定します。2つ目は、プライマリ上で、接続されたレプリカが存在しない状態がどのくらいの時間続いた後にバックログを解放できるかを決定します。これは PSYNCの最大中断時間なし. バッファが上書きされたり、その他の前提条件が満たされていない限り、TTLを長く設定しただけでは何の役にも立たない。.

以下の行は、Redis 7.2.0 の設定テンプレートから引用した、コメントアウトされたデフォルト設定です。コメント記号は意図的に残されています。これらの行を単にコピーしただけでは設定は有効になりません。また、記載されている値は、本番環境システムに対する一般的な容量の推奨値ではありません。.

# Redis 7.2.0: auskommentierte Vorgaben aus redis.conf
# repl-backlog-size 1mb
# repl-backlog-ttl 3600

と一緒に repl-backlog-ttl 0 すべてのレプリカとの接続が切断された後、時間指定による解放は無効化されます。これにより、履歴が無限に保持されるわけではありません。既存のバッファは、新しいレプリケーションデータによって上書きされる可能性があります。また、これにより、プロセスの再起動を問わずデータが永続化されるわけでもありません。 したがって、追加のメモリ消費量が、想定される再接続の挙動に見合っているかどうかを慎重に評価してください。.

変更を行う前に、実際に有効な値を確認し、デプロイ手順を明確にする必要があります。 コンテナの環境変数、管理対象の設定ファイル、および実行時に変更された設定は、同じものではありません。後でインスタンスが再作成された場合、実行時にのみ行われた調整のみが失われる可能性があります。以下のクエリは読み取り専用ですが、それでも適切なアクセス権限が必要です。.

redis-cli CONFIG GET repl-backlog-size
redis-cli CONFIG GET repl-backlog-ttl

Managed Redis では、プロバイダーは CONFIG 制限を課したり、専用のインターフェースを通じて設定を管理したりすることも可能です。しかし、それを理由に保護メカニズムを迂回してはなりません。その場合は、承認された管理手順に従い、選択したサイズと、その基礎となるレプリケーションボリュームを併せて記録してください。 また、変更計画には、従来の値と現実的な元に戻す方法を明記する必要があります。.

モニタリング：どの数値が関連しているか

〜については Redisのレプリケーションの監視 接続ステータスが「緑」であるだけでは不十分です。レプリカがまだ遅れを取り戻している最中や、データセット全体を読み込んでいる最中でも、リンクは再接続されている可能性があります。逆に、履歴データが十分で、遅れを取り戻す余裕があれば、一時的な接続切断が直ちに深刻な問題になるとは限りません。 したがって、接続状況、同期状態、オフセットの推移、および利用可能な履歴を総合的に評価してください。.

のフィールド INFO- 応答内容は、Redisのバージョン間や、プライマリとレプリカの間で異なる場合があります。そのため、評価を行う際は、欠落しているフィールドを黙ってnullやエラーのない状態として解釈するのではなく、明示的に処理する必要があります。また、名称についても master そして slave 互換性の理由から、フィールド名には引き続き使用されていますが、実行可能コード内では自由に変換してはなりません。.

この遅れを解釈するにあたっては、内部ガイドラインが Redisのレプリケーションオフセットを分析する 適切な補足です。継続的なモニタリングでは、手動で読み取った2つの数値だけでなく、過去の推移も確認する必要があります。距離が拡大している場合は、一時的な停滞の後に徐々に縮まっていくギャップの場合とは異なる対応が求められます。.

適切なアラートは、運用目標に基づいて設定されます。レプリカがアクセス不能になっていてもよい時間はどれくらいか？どれくらいの速さで状態を回復させる必要があるか？完全な同期がどの程度の頻度で発生すれば異常とみなされるか？ 負荷プロファイルやデータ量との関連性を考慮しない固定的な閾値を設定すると、不要なアラートが発生したり、実際のパフォーマンス低下が見過ごされたりすることがよくあります。レプリケーションのメトリクスに加え、RAM使用率、ネットワーク使用率、およびプロセスの再起動の兆候にも注意を払ってください。.

ストレージ予算と動作の遅いレプリカを正しく位置づける

バックログは全体の一部に過ぎない Redisのメモリ使用量. さらに、データセット、管理構造、クライアントバッファに加え、運用状態によっては、永続化や同期処理中に追加のメモリが必要となる場合もあります。 したがって、利用可能なメモリ全体を、ユーザーデータと正確に計算されたバックログの合計として割り当てるような計画は立てないでください。必要な予備容量は、具体的な環境とそこで発生する負荷のピークに基づいて算出する必要があります。.

Redis 7.0 以降、レプリカバッファとレプリケーションバックログはメモリを共有するようになりました。そのため、INFO ドキュメントでは、とりわけ次のように指摘されています。 mem_clients_slaves レプリカバッファがバックログの割り当て容量を超えない場合、null になる可能性があります。しかし、だからといってレプリケーションがメモリを消費しないということにはなりません。このために指定された値を次のように考えてください。 mem_replication_backlog そして mem_total_replication_buffers 文脈を考慮し、重複する数値をむやみに足し合わせないようにする。.

よくある診断ミスの一つは、同期が中断されるたびに、それが大規模なバックログによるものだと見なそうとすることです。レプリカの動作が遅い、ネットワーク帯域幅が限られている、あるいは出力バッファの制限を超えているといった現象には、別の原因が考えられる場合があります。パラメータ client-output-buffer-limit replica 当該クライアントクラスに適用され、 repl-backlog-size 同等と見なされます。制限を変更する前に、ログ、バージョンドキュメント、および他の接続に及ぼす予想される影響を確認してください。.

バックログが膨大であっても、なぜ高可用性が保証されないのか

バックログは再接続を改善しますが、デフォルトで非同期であるレプリケーションを損失のないものにするわけではありません。 プライマリは、レプリカがその書き込み処理を完了する前に、すでにクライアントに対してその書き込みを承認している可能性があります。この期間中にプライマリが障害を起こした場合、後に選択された代替システム上では、当該の処理が存在しない可能性があります。バッファサイズだけでは、この問題を解消することはできません。 フェイルオーバー時のデータ損失リスク ではない。.

また WAIT Redisのトポロジーを、強い一貫性が保証されたシステムに変えるわけではありません。このコマンドはレプリカからの確認を待つことができますが、実際のデータの整合性は、その他の状況、特に永続化やフェイルオーバーの挙動に引き続き依存します。同様に、 min-replicas-to-write そして min-replicas-max-lag それぞれの条件のもとで、新しい書き込み操作を受け入れるが、個々の操作を自動的に複数のインスタンスに永続的に保存することはない。.

～について 高可用性 そのため、一貫性のある決定が必要です。具体的には、許容されるデータ損失、許容ダウンタイム、永続性、障害の検知、新しいプライマリの選定、および復旧です。 この際、SentinelやRedis Clusterは、バックログとは異なる役割を担うことができます。単にバッファのサイズを大きくするだけで、その他の前提条件をすべて変更しないままでは、信頼性の高い復旧計画とは言えません。.

変更点をテストし、繰り返し発生する問題を特定する

同等のRedisバージョンが使用され、書き込み負荷が把握可能な隔離された環境で、制御されたテストを開始してください。中断する前に、レプリケーションID、オフセット、バックログの占有状況、およびメモリ使用量を記録してください。 その後、実稼働環境のファイアウォールやプロセスを検証せずに変更することなく、限定的な接続中断をシミュレートします。再接続後、部分的な同期が行われるか、完全な同期が行われるか、また追いつくまでにどれくらいの時間がかかるかを観察します。.

1回の実験につき、可能な限り関連する変数を1つだけ変更してください。バックログ、書き込み負荷、ネットワーク状況が同時に変化すると、その影響を特定することが困難になります。中断時間を変えたり、負荷の段階を変えたりして、実験を繰り返してください。そうすることで、単一の再接続成功事例から、その挙動について理解しやすい評価を得ることができます。 観測された限界値は文書化すべきですが、そこから将来のあらゆる障害に対する保証を導き出してはなりません。.

フル再同期が繰り返し発生する場合は、まず履歴自体が互換性があるかどうかを確認してください。その後、残っているバイト数、レプリカがない期間、再起動の兆候、および実際の追いつき速度を確認します。 バッファが小さすぎることも原因の一つですが、それだけではありません。特に重要なのは、一時的な長いギャップと、接続が確立されているにもかかわらずレプリカが継続的に遅れをとっている状態とを区別することです。.

適切な設定とは、結局のところ、現実的な負荷条件下で定義したダウンタイム許容範囲をカバーしつつ、残りの運用に必要な十分なメモリを確保できるものである。 測定基準、設定情報、および検証日をまとめて記録しておいてください。書き込み挙動、トポロジー、またはRedisのバージョンに大幅な変更があった場合は、再設計を改めて検討する必要があります。これにより、バックログは一度決定された数値ではなく、根拠に基づいた運用上の意思決定として維持されます。.