Redis プライマリ・レプリカ レプリケーション設定ガイド

replicaof、認証、モニタリング、本番環境の安全確認を含む Redis プライマリ・レプリカ レプリケーションの設定方法。

Redis プライマリ・レプリカ レプリケーション設定ガイド

Redis レプリケーションは、高可用性、データ冗長性、読み取りスケーラビリティを実現するための基本的なパターンです。プライマリ(旧称マスター)と1つ以上のレプリカ(旧称スレーブ)を設定することで、プライマリに書き込まれたデータが接続されているすべてのレプリカに自動的にコピーされるようになります。

このガイドでは、Redis プライマリ・レプリカ レプリケーションの設定方法、同期が正しく行われているかの確認方法、そして Redis を露出させたりレプリカを静かに古いまま放置するようなよくある間違いを避ける方法を説明します。


Redis レプリケーションの基礎を理解する

Redis レプリケーションは非同期(つまり、プライマリはレプリカが書き込みを確認するのを待たない)であり、高いパフォーマンスを可能にします。これは主に、初期同期と継続同期の2つのフェーズで動作します。

完全同期 (SYNC)

レプリカが初めてプライマリに接続するとき、または部分的な再同期が不可能なネットワーク中断の後、完全同期が発生します。

  1. レプリカはプライマリに PSYNC コマンドを送信します。
  2. プライマリはバックグラウンド保存プロセスを開始し、RDB スナップショットファイル (.rdb) を生成します。
  3. プライマリは、RDB が作成されている間に受信したすべての新しい書き込みコマンドをバッファリングします。
  4. RDB ファイルが完成すると、プライマリはそれをレプリカに送信します。
  5. レプリカは RDB ファイルをメモリにロードします。
  6. 最後に、プライマリはバッファリングされたすべての書き込みコマンドをレプリカに送信して追いつかせます。

部分再同期 (PSYNC)

Redis 2.8 以降は部分再同期をサポートしています。プライマリとレプリカ間のリンクが一時的に切断された場合、レプリカはレプリケーションバックログバッファ(プライマリ上の設定可能な循環バッファ)を使用して、リンクが切れてからの不足しているコマンドのみを要求できます。

前提条件とセットアップ

レプリケーションを設定する前に、少なくとも2つの別々の Redis インスタンスが実行されていること(またはテスト用に同じサーバーの異なるポートで実行されている別々の設定)を確認してください。

このガイドでは、以下のセットアップを想定しています。

インスタンス ロール IPアドレス ポート 設定ファイル
プライマリ プライマリ 192.168.1.100 6379 redis-primary.conf
レプリカ 1 レプリカ 192.168.1.101 6380 redis-replica-1.conf

ステップ 2.1: プライマリインスタンスを設定する

プライマリインスタンスがレプリカからの接続を受け入れる準備ができており、プライマリ自身の安定性のために必要な場合、永続性(RDB または AOF)を管理するように設定されていることを確認してください。

重要なプライマリ設定:

  1. バインディング: 複数のマシン間で実行する場合は、プライマリがパブリック IP アドレスまたは 0.0.0.0 にバインドされていることを確認してください。ファイアウォールを使用する場合は、レプリカ IP に対してポート 6379 が開いていることを確認してください。
  2. 永続性: レプリケーション自体には厳密には必要ありませんが、プライマリデータの永続性のために RDB/AOF を有効にすることを強くお勧めします。
# redis-primary.conf
port 6379
bind 0.0.0.0 # すべてのインターフェースにバインド(外部レプリカに必要)
# RDB 永続性を有効にする
save 900 1
save 300 10
save 60 10000

ステップ 2.2: レプリカインスタンスを設定する

レプリカを設定する核心は replicaof ディレクティブにあります。これはインスタンスに、どのプライマリとデータを同期するかを指示します。

重要なレプリカ設定:

  1. ポート: 同じマシンで実行する場合は異なるポートを使用してください。
  2. レプリケーションディレクティブ: replicaof または slaveof(レガシー名)を使用します。
# redis-replica-1.conf
port 6380

# *** 必須のレプリケーション設定 ***
replicaof 192.168.1.100 6379

# レプリカが読み取り専用であることを確認する(Redis 5 以降デフォルト)
replica-read-only yes

# HA が Sentinel/Cluster によって処理される場合、レプリカでの永続性を無効にすることを推奨
# クイック再起動のために永続性が必要な場合は、有効のままにしてください。
save ""

注: プライマリにパスワードが必要な場合は、masterauth <password> でレプリカを設定してください。Redis 6 以降の ACL セットアップでは、レプリケーションユーザーがデフォルトユーザーでない場合に masteruser も設定してください。

実装方法

レプリケーションは、設定ファイルを編集してサーバーを再起動するか、redis-cli から REPLICAOF コマンドを動的に実行することで実装できます。

方法 3.1: 設定ファイル(本番環境推奨)

上記のように redis-replica-1.conf を更新した後、両方のインスタンスを起動します。

# プライマリを起動
redis-server redis-primary.conf

# レプリカ 1 を起動
redis-server redis-replica-1.conf

起動時に、レプリカ 1 はすぐに 192.168.1.100:6379 のプライマリに接続を試み、同期プロセスを開始します。

方法 3.2: 動的設定

Redis インスタンスがすでに実行中で、再起動せずにレプリカに変換したい場合は、redis-cli を介して REPLICAOF を実行します。

  1. レプリカに変換したいインスタンス(この例ではポート 6380 で実行中)に接続します。

    redis-cli -p 6380
    
  2. レプリケーションコマンドを実行します。

    127.0.0.1:6380> replicaof 192.168.1.100 6379
    OK
    

ポート 6380 のインスタンスは、以前のデータをすべて削除し、新しいプライマリとの完全同期 (SYNC) を開始します。

⚠️ 警告: レプリケーションの無効化

レプリカをスタンドアロンのプライマリインスタンスに戻すには、そのインスタンスで replicaof no one を実行します。

4. レプリケーションステータスの監視

データの一貫性を確保するには、接続ステータスの監視が不可欠です。プライマリとレプリカの両方で redis-cli を使用して INFO replication コマンドを実行します。

4.1 プライマリステータスの確認

プライマリ (6379) に接続し、接続されているレプリカの数とそのステータスを確認します。

redis-cli -p 6379 INFO replication

期待される出力スニペット(プライマリ):

# Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.101,port=6380,state=online,offset=2048,lag=0
master_replid:a9b1c2...
master_replid2:000000...
master_repl_offset:2048
  • role:master はそのロールを確認します。
  • connected_slaves:1 はレプリカが認識されていることを確認します。
  • state=online は望ましい安定状態です。
  • lag=0 または低い値は、レプリカが迅速に応答していることを意味します。Redis レプリケーションは依然として非同期であるため、これはデータ損失ゼロの保証ではありません。

4.2 レプリカステータスの確認

レプリカ (6380) に接続し、プライマリリンクステータスを確認します。

redis-cli -p 6380 INFO replication

期待される出力スニペット(レプリカ):

# Replication
role:slave
master_host:192.168.1.100
master_port:6379
master_link_status:up
master_sync_in_progress:0
slave_priority:100
slave_read_only:1
  • role:slave はそのロールを確認します。
  • master_link_status:up は接続がアクティブで正常であることを確認します。
  • master_sync_in_progress:0 は初期同期が完了したことを意味します。

レプリケーションのベストプラクティスと最適化

5.1 レプリカ読み取り専用モード

デフォルトでは、レプリカは読み取り専用です (replica-read-only yes)。これは重要な安全機構です。レプリカに書き込もうとするとエラーが発生し、クラスター全体のデータ一貫性が確保されます。

読み取り専用モードを無効にした場合、レプリカへの書き込みはローカルになり、レプリケーションリンクが切断されて完全同期が発生すると上書きされます。

5.2 同期時間の最適化

データセットが非常に大きい場合、初期 SYNC プロセスは遅くなる可能性があります。以下の要素を考慮してください。

  1. ネットワーク帯域幅: RDB 転送のためにプライマリとレプリカ間の十分な帯域幅を確保してください。
  2. RDB 生成: プライマリは RDB ファイルを生成するために CPU とディスク I/O を必要とします。同期中にサーバーに利用可能なリソースがあることを確認してください。
  3. レプリカでのディスク永続性の無効化(オプション): プライマリがすべての永続性を処理し、レプリカが読み取りスケーリング専用である場合、レプリカで save "" を設定すると、RDB ファイル書き込みの I/O オーバーヘッドを回避し、再起動を高速化できます。

5.3 セキュリティとネットワーク設定

プライマリがレプリケーションポート(6379 など)をインターネットに公開しないことが重要です。レプリカサーバーの指定された IP アドレスからのレプリケーショントラフィックのみを許可するようにファイアウォールルールを設定してください。

5.4 読み取りスケーリングにレプリカを使用する

レプリケーションの主な利点は、読み取り負荷を分散することです。主に読み取り操作を実行するアプリケーションをレプリカインスタンスに直接向け、プライマリを書き込み操作のために予約することで、システム全体のスループットが向上します。

次に行うべきこと

Redis プライマリ・レプリカ レプリケーションの設定は、回復力のある高性能アプリケーションを構築するために不可欠です。replicaof ディレクティブを正しく設定し、INFO replication を使用してリンクステータスを定期的に監視することで、高可用性と効果的な読み取りスケーリングの基盤が作成されます。

このガイドは基本的なセットアップに焦点を当てていますが、本番環境では、自動プライマリ昇格と障害検出のための Redis Sentinel、または複数ノード間での自動パーティショニングとデータ分散のための Redis Cluster など、さらなる自動化レイヤーが統合されることがよくあります。