Redis
 Computer >> コンピューター >  >> プログラミング >> Redis

DynomiteデータベースからRedis Enterprise Active-Activeデータベースへ移行する完全ガイド

本記事の前編「なぜDynomiteデータベースをRedis Enterprise Active-Activeデータベースに移行すべきか？」では、DynomiteとRedis Enterpriseのアーキテクチャや機能を比較しました。Redis Enterpriseを活用すれば、機能が豊富で管理しやすい形でRedisを地理的に分散配置でき、同時書き込みによる競合を心配する必要がないことをご紹介しました。

後編となる本記事では、DynomiteからRedis Enterpriseへの移行オプションについて詳しく解説します。

なお、以降の説明では、Redis Enterpriseのセルフマネージド版を「Redis Enterprise Software」、マネージド版を「Redis Enterprise Cloud」（または「Cloudサブスクリプション」）と呼びます。

Dynomiteデータベースの移行

それでは実践的に、以下の2種類の移行方法を見ていきましょう。

  1. Redis Enterpriseのインポート／エクスポート機能を使った移行
  2. Redis EnterpriseのReplicaOf機能（アクティブ・パッシブとも呼ばれます）を使った移行

説明のため、ここではdc-aとdc-bという2つのデータセンターにまたがるDynomiteクラスタを想定します。各データセンターには1つのラックがあり、各ラックは2つのノードで構成され、その間にデータセットが分散配置されています。

DynomiteデータベースからRedis Enterprise Active-Activeデータベースへ移行する完全ガイド

Dynomiteのアーキテクチャに関する前編の説明を思い出していただければ、各Dynomiteラックにはデータセット全体が格納されていることがわかります。

したがって、インポート／エクスポート方式でもアクティブ・パッシブ方式でも、移行の対象範囲をDynomite構成内の単一ラックに限定できます。

ここではrack-1-dc-aを選び、その2つのノードのIPアドレスは以下と仮定します。

  • a1：10.0.0.1
  • a2：10.0.0.2

わかりやすくするため、今回のDynomite構成のYAML設定ファイルを以下に示します。

#a1
dyn_o_mite:
  datacenter: dc-a
  dyn_listen: 10.0.0.1:7379
  dyn_port: 7379
  dyn_seed_provider: simple_provider
  dyn_seeds:
  - 10.0.0.3:7379:rack1:dc-a:4294967294
  - 10.0.0.4:7379:rack1:dc-b:4294967294
  - 10.0.0.2:7379:rack1:dc-b:2147483647
  listen: 0.0.0.0:8379
  rack: rack1
  servers:
  - 127.0.0.1:6379:1
  timeout: 150000
  tokens: 2147483647
  secure_server_option: datacenter
  pem_key_file: /root/dynomite/conf/dynomite.pem
  data_store: 0
  stats_listen: 127.0.0.1:22222
  read_consistency : DC_QUORUM
  write_consistency : DC_QUORUM

#a2
dyn_o_mite:
  datacenter: dc-a
  dyn_listen: 10.0.0.3:7379
  dyn_port: 7379
  dyn_seed_provider: simple_provider
  dyn_seeds:
  - 10.0.0.1:7379:rack1:dc-a:2147483647
  - 10.0.0.4:7379:rack1:dc-b:4294967294
  - 10.0.0.2:7379:rack1:dc-b:2147483647
  listen: 0.0.0.0:8379
  rack: rack1
  servers:
  - 127.0.0.1:6379:1
  timeout: 150000
  tokens: 4294967294
  secure_server_option: datacenter
  pem_key_file: /root/dynomite/conf/dynomite.pem
  data_store: 0
  stats_listen: 127.0.0.1:22222
  read_consistency : DC_QUORUM
  write_consistency : DC_QUORUM

#b1
dyn_o_mite:
  datacenter: dc-b
  dyn_listen: 10.0.0.2:7379
  dyn_port: 7379
  dyn_seed_provider: simple_provider
  dyn_seeds:
  - 10.0.0.4:7379:rack1:dc-b:4294967294
  - 10.0.0.1:7379:rack1:dc-a:4294967294
  - 10.0.0.3:7379:rack1:dc-a:2147483647
  listen: 0.0.0.0:8379
  rack: rack1
  servers:
  - 127.0.0.1:6379:1
  timeout: 150000
  tokens: 2147483647
  secure_server_option: datacenter
  pem_key_file: /root/dynomite/conf/dynomite.pem
  data_store: 0
  stats_listen: 127.0.0.1:22222
  read_consistency : DC_QUORUM
  write_consistency : DC_QUORUM

#b2
dyn_o_mite:
  datacenter: dc-b
  dyn_listen: 10.0.0.4:7379
  dyn_port: 7379
  dyn_seed_provider: simple_provider
  dyn_seeds:
  - 10.0.0.2:7379:rack1:dc-b:2147483647
  - 10.0.0.1:7379:rack1:dc-a:4294967294
  - 10.0.0.3:7379:rack1:dc-a:2147483647
  listen: 0.0.0.0:8379
  rack: rack1
  servers:
  - 127.0.0.1:6379:1
  timeout: 150000
  tokens: 4294967294
  secure_server_option: datacenter
  pem_key_file: /root/dynomite/conf/dynomite.pem
  data_store: 0
  stats_listen: 127.0.0.1:22222
  read_consistency : DC_QUORUM
  write_consistency : DC_QUORUM

この設定および本チュートリアルの検証環境について、いくつか補足しておきます。

  • Ubuntu 18.04が動作するGCPのVMを4台使用
  • VMは複数リージョンにまたがる同一VPC内に配置
  • Dynomiteがデータ複製に使用するポート7379と7380を開放（YAML設定の「dyn_port」に相当）
  • 各ノードでRedis OSSがポート6379で稼働（YAML設定の「servers」に相当）
  • Dynomiteはクライアントからのリクエストをポート8379で待ち受け（例：redis-cli -h 10.0.0.1 -p 8379）（YAML設定の「listen」に相当）

環境の把握と移行に使うラックの選択が完了したところで、次にRedis Enterpriseデータベースを作成しましょう。

Redis Enterprise Active-Activeデータベースの作成

本記事の目的はクラスタのセットアップやデータベース作成手順の説明ではないため、Active-Activeデータベースを立ち上げて稼働させる方法については、以下のドキュメントをご参照ください。

  • Redis Enterprise Softwareクラスタ
  • Cloudサブスクリプション
  • Softwareでのデータベース作成
  • SoftwareでのActive-Activeデータベース作成
  • Cloudでのデータベース作成

2つの移行シナリオを検証するために、筆者はヨーロッパとアメリカの2つのRedis Enterprise SoftwareクラスタにまたがるActive-Activeデータベースを作成しました。各クラスタはUbuntu 18.04が動作する3台のVMで構成されています。なお、Active-Activeなしでデータベースを作成した場合でも、特記しない限り移行手順は同じです。

それでは、最初の移行方法に進みましょう。

インポート／エクスポート機能を使った移行

Redis OSSには「Redis Database Backup Files（RDB）」と呼ばれる永続化オプションがあります。これは指定した間隔で、またはSAVEコマンドやBGSAVEコマンドの実行時に、データセットの特定時点のスナップショットを作成する機能です。

これらのスナップショットは.rdbファイルとして保存されます（以降「RDBファイル」と呼びます）。このRDBファイルをDynomiteサーバーからエクスポートし、Redis Enterpriseデータベースにインポートします。この手法では差分移行はできない点、またデータサイズによってはインポートに時間がかかる点に注意してください。

重要：地理分散されていないRedis EnterpriseデータベースとActive-Activeデータベースの間には大きな違いがあります。

  • 非地理分散データベース：RDBファイルをインポートすると、既存のデータベース内容はすべて消去されます。
  • Active-Activeデータベース：RDBファイルをインポートして、既存のデータセットにマージできます。つまり、インポートの前や最中にActive-Activeデータベースへ書き込みトラフィックを送り始めることも可能です。ただし注意が必要です。Dynomiteにすでに存在するキーをActive-Activeデータベースに書き込むと、その後のインポートで新しい値が古い値で上書きされる可能性があります。綿密な計画が求められます。

RDBファイルを使ってDynomiteからRedis Enterpriseへデータを移行する手順は以下の通りです。

  • Dynomiteデータベースへのトラフィックを停止する。移行計画が綿密で、Active-Activeデータベースを使用している場合は、この時点でRedis Enterpriseデータベースへ切り替えても構いません。
  • 各ノードのデータ（ここではa1とa2）をRDBファイルとしてエクスポートする。
  • RDBファイルを、Redis Enterpriseクラスタからアクセス可能な場所（Google Cloud Storageバケット、AWS S3バケット、FTPサーバーなど）にアップロードする。
  • RDBファイルをRedis Enterpriseデータベースにインポートする。
  • Redis Enterpriseデータベースへ切り替える。

以下、各ステップを詳しく見ていきます。

（任意）各ノードのRedis OSS設定ファイルの編集

Dynomiteノード上で動作しているRedis OSSインスタンスの設定ファイルは、「apt-get」でインストールした場合はデフォルトで/etc/redis配下に、ソースからビルドした場合はRedisフォルダ内にあります。ファイル名は「redis.conf」です。

お好みのテキストエディタでこのファイルを開き、「dbfilename」ディレクティブを探してください。各ノードでファイル名を変更します。たとえば以下のようにします。

  • node1では「dump1.rdb」
  • node2では「dump2.rdb」

こうすることで、RDBファイルを外部ストレージにエクスポートする際に同名ファイルの衝突を防げます。スナップショット取得後に名前を変更してもよいのであれば、この作業は省略しても構いません。

さらに、必要に応じて以下の設定も行えます。

  • 「dir」ディレクティブでRDBファイルの保存先ディレクトリを変更する。
  • スナップショットの間隔を変更するか、自動スナップショットを無効化する。本チュートリアルではSAVEコマンドでスナップショットを作成するため、トラフィック停止後に確実に全データセットをダンプできます。
DynomiteデータベースからRedis Enterprise Active-Activeデータベースへ移行する完全ガイド

なお、Redis OSSの設定ファイルを編集した後は、変更を反映させるためにRedis OSSサーバーの再起動が必要です。

データのダンプ

まず、ポート8379経由でDynomiteデータベースに入ってくるトラフィックを停止します。繰り返しになりますが、Active-Activeデータベースへインポートする場合で、インポート中に誤った上書きが発生しないよう移行計画を綿密に立てているなら、この時点でActive-Activeデータベースへトラフィックを切り替えても問題ありません。

次にredis-cliを起動します。このとき、Dynomiteの待ち受けポートである8379ではなく、必ずポート6379を使用してください。接続先はDynomiteクラスタではなく、ノード上で動作しているRedis OSSインスタンスである必要があるためです。DynomiteはSAVEコマンドをサポートしていません。引数なしでredis-cliを実行すればOKです。

各ノードでDBSIZEコマンドを実行すると、各Redis OSSインスタンスに保存されているキーの数がわかります。合計がDynomiteデータベース内のキー総数となります。

#a1
127.0.0.1:6379> dbsize
(integer) 1323

#a2
127.0.0.1:6379> dbsize
(integer) 1371

続いてSAVEコマンドを実行し、RDBファイルが/var/lib/redis（または指定したディレクトリ）に作成されたことを確認してください。

2つのダンプファイルを外部ストレージへエクスポート

これで2つのRDBファイルを外部ストレージへエクスポートする準備が整いました。

本チュートリアルではGoogle CloudのCloud Storageへエクスポートしますが、FTPサーバー、他のクラウドプロバイダーのストレージサービス、Redis Enterpriseクラスタからアクセス可能な外付けディスクなども利用できます。各オプションの詳細は以下をご参照ください。

  • Redis Enterprise Software
  • Redis Enterprise Cloud

Google Cloud側では、以下を用意しました。

  • JSONキーを作成したサービスアカウント
  • サービスアカウントに「Storage Legacy Object Reader」権限を付与したCloud Storageバケット

次に、各ノードで以下のコマンドを実行します。

gsutil cp path_to_dump_file gs://your_bucket

これでGoogle Cloudのバケットに2つのRDBファイルが確認できるはずです。

DynomiteデータベースからRedis Enterprise Active-Activeデータベースへ移行する完全ガイド

いよいよActive-Activeデータベースへのインポートを行います。

ダンプファイルをRedis Enterpriseデータベースへインポート

Redis EnterpriseのUIにログインし、Active-Activeデータベースを選択します。本チュートリアルのように複数クラスタにまたがるActive-Activeデータベースを作成した場合は、どちらのクラスタのUIからでもアクセスできます。ここではヨーロッパ（EU）クラスタを使用します。

CloudのActive-Activeデータベースを使用している場合は、Cloud UIに接続してデータベースを選択するだけです。

データベースの設定ページに移動し、「Import」ボタンをクリックします。適切なストレージタイプを選択してください。今回はGoogle Cloud Storageです。

次に、2つのRDBファイルのCloud Storage上のパスを追加します。例：

  • /helene-test/dump1.rdb
  • /helene-test/dump2.rdb

さらに、以下の情報も入力が必要です。

  • client ID
  • client email
  • private key ID
  • private key

これらの情報は、Google Cloudサービスアカウントのキー作成時にダウンロードしたJSONキーファイルに記載されています。

なお、JSONファイル内のprivate keyは引用符や改行を含む特殊な形式になっています。Redis EnterpriseのUIが受け付ける形式に素早く整形するには、Pythonインタプリタを起動してprintするのが簡単です。

print(WHOLE_COPIED_KEY)

以上で、以下のようなインポート設定が完成します。

DynomiteデータベースからRedis Enterprise Active-Activeデータベースへ移行する完全ガイド

「Import」をクリックし、インポートが完了するまで待ちます。所要時間はデータベースのサイズによります。

データベースの確認と切り替え

redis-cliでRedis Enterpriseデータベースのエンドポイントに接続し、いくつかのキーを読み取れること、そしてDBSIZEコマンドでキー総数が正しいことを確認しましょう。

redis-12000.internal.helene-eu-cluster.demo.redislabs.com:12000> dbsize
(integer) 2694

Active-ActiveのGeo-Duplication（地理複製）の確認も忘れずに行いましょう！もう一方のクラスタ（ここでは米国側）のデータベースエンドポイントに接続し、キー数をチェックしてください。

これで移行は完了です。まだトラフィックを切り替えていない場合は、Redis Enterpriseデータベースへ切り替えましょう。

ReplicaOf機能を使った移行

次に、継続的な移行（連続レプリケーションによる移行）を実施してみましょう。

Redis Enterpriseの「ReplicaOf」機能（Redis Cloud UIでは「アクティブ・パッシブ」と呼ばれます）により、2つのRedisデータベース間で継続的にデータを複製できます。最大のメリットは、初期同期完了後は差分のみを複製するため、アプリケーション側でほぼダウンタイムを発生させずに済む点です。

手順は以下の通りです。

  • DynomiteデータベースとActive-Activeデータベースの間にReplicaOfリンクを確立する
  • 初期同期が完了するまで待つ
  • Dynomiteデータベースへのトラフィックを停止する
  • 差分が複製されるまで待つ
  • データベース間のReplicaOfリンクを削除する
  • Active-Activeデータベースへ切り替える

ReplicaOfはアクティブ・パッシブ方式での使用を想定しています。つまり、ターゲット側はパッシブであることが前提で、ターゲットが完全に再同期されること（ターゲットデータベースのフラッシュ＋ソースデータベースからの同期）を許容する必要があります。

移行を始める前に、セキュリティ面についていくつか検討しておきましょう。

Dynomite構成におけるRedis OSSのセキュリティ設定

まず、Dynomiteラックが存在するネットワークに対して、カスタムTCPのポート6379向けインバウンドルールを追加する必要があります。

次に、両方のDynomiteノード上のRedis OSS設定ファイルを更新します。デフォルトでは、RedisはIPv4およびIPv6（利用可能な場合）のループバックインターフェースアドレスのみで待ち受けます。つまり、Redis OSSは自身が稼働しているホストからのクライアント接続しか受け付けられません。Redis Enterpriseクラスタのホストからの接続を受け入れられるよう、Redis OSSの「bind」ディレクティブを更新する必要があります。

方法は2つあります。

  • ピアリングされたVPC内のマシンからの接続のみを受け付けるようにする――推奨され、より安全です
  • すべてのホストからのアクセスを許可する――安全ではありません。特にDynomiteはデータベースパスワードをサポートしていないため危険です

それぞれのオプションを詳しく見ていきます。

オプション1：VPCピアリングを使用する場合

最初のオプションは、Dynomiteラックが存在するVPCと、Redis Enterpriseクラスタが存在するVPCをピアリングすることです。なお、本チュートリアルのようにActive-Activeデータベースを作成した場合、どのクラスタに配置しても構いません。ここでもヨーロッパ（EU）クラスタを使って説明します。

ネットワークのピアリングが完了したら、redis.confファイルの「bind」ディレクティブを編集するだけです。デフォルトのループバックインターフェースアドレスの後に、DynomiteマシンのプライベートIPを追加してください。

DynomiteデータベースからRedis Enterprise Active-Activeデータベースへ移行する完全ガイド

ラック内のすべてのノードでこの作業を行えば完了です。Redis OSSインスタンスの再起動を忘れないようにしてください。

オプション2：VPCピアリングを使用しない場合

ネットワークをピアリングできない、またはしたくない場合は、各ノードのRedis OSS設定ファイルを以下のように更新します。

  • 「bind」ディレクティブをコメントアウトする。これによりRedis OSSインスタンスがインターネット上の全員に公開されます
  • 「protected-mode」を「no」に設定する。これにより、認証が設定されておらず、「bind」ディレクティブで特定のインターフェースが明示されていない場合でも、他のホストのクライアントがRedisに接続できるようになります
DynomiteデータベースからRedis Enterprise Active-Activeデータベースへ移行する完全ガイド

重要：この最後の手順は必須です。DynomiteはRedis OSSのAUTHコマンドをサポートしていないため、データベースにパスワードを設定できません。したがって、ファイアウォールで接続元を制御しない限り、誰でもRedis OSSインスタンスに接続してデータの閲覧・変更・削除ができてしまいます。ポート6379はRedis Enterpriseクラスタのホストに対してのみ開放してください。

どうしてもパスワードを使いたい場合は可能ですが、その場合は継続的な移行は実行できません。以下の手順が必要になります。

  • Dynomiteデータベースへのトラフィックを停止する
  • 「requirepass」ディレクティブを編集してデータベースにパスワードを設定する。以降、AUTHコマンドによる認証が必要になるため、ポート8379経由でDynomiteデータベースに書き込みトラフィックを送ることはできません
  • 後述の通りReplicaOfを使って移行を実施する
  • Redis Enterpriseデータベースへトラフィックを切り替える

セキュリティに関する考慮事項がもう1つあります。それが終われば、いよいよ移行開始です！

（任意）TLSの有効化

データへの不正アクセスを防ぐため、Redis EnterpriseはTLSプロトコルをサポートしています。

Redis Enterprise Softwareを使用している場合は、ReplicaOf通信専用にTLSを設定できます。Redis Enterprise Cloudの場合は、TLSを全般的に有効化できます。

データベース間にReplicaOfリンクを設定する

Redis Enterprise UIでActive-Activeデータベースの設定ページに移動し、「Edit」をクリックします。

アクティブ・パッシブ／ReplicaOfを有効化するオプションがあります。有効にすると、以下の形式でソースを追加できます。

redis://:@IP:port

注意点は以下の通りです。

  • ReplicaOfで指定できるソースは最大32個です。つまり、Dynomiteラック内でデータセットを32ノード超に分散している場合、このオプションは使用できません
  • VPCピアリングを使用した場合は、マシンのプライベートIPを使用してください
  • VPCピアリングを使用しない場合：
    • マシンのパブリックIPを使用してください
    • データベースにパスワードを設定した場合（＝一括移行を実行する場合）、パスワードは redis://:password@IP:port の形式で指定します

本チュートリアルではVPCピアリングを使用しているため、ソースの設定は以下のようになります。

DynomiteデータベースからRedis Enterprise Active-Activeデータベースへ移行する完全ガイド

移行の開始

続いて、以下のステップを実行します。

  • Redis Enterprise UIで「Update」をクリックする
  • 初期同期が完了するまで待つ
  • Dynomiteデータベースへのトラフィックを停止する
  • 差分が同期されるまで待つ
  • Active-Activeデータベースを再度更新し、ReplicaOfを無効化する
  • Active-Activeデータベースでトラフィックを開始する

データの確認

前述と同様に、redis-cliでデータベースに接続し、データが正しく移行されていることを確認します。他のクラスタや他のローカルエンドポイントにも接続して、Active-ActiveのGeo-Duplicationも併せてチェックしましょう。

まとめ

Redisは長年にわたり、開発者から最も愛されているデータベースに選ばれ続けてきました。Dynomiteをお使いの方は、おそらくRedisがお好きなのでしょう。Redis OSSとRedis Enterpriseの本拠地であるRedis社は、競合解決に関する最高水準の学術的基準を維持しながら、より管理しやすい形でRedisを地理分散配置できるよう、貴社を支援いたします。

  1. Redis MOVEコマンドの使い方 – キーを別のデータベースへ移動する方法

    このチュートリアルでは、Redisデータストア上でキーをあるデータベースから別のデータベースへ移動する方法を解説します。キーの移動には、redis-cliで使用できるMOVEコマンドを利用します。 MOVEコマンドは、現在選択されているデータベース（ソース）から指定したキーを削除し、そのキーを移動先（デスティネーション）のデータベースに挿入するために使用されます。なお、以下の場合は操作が実行されず、戻り値として0が返されます。 指定したキーがソースデータベースに存在しない場合 同じ名前のキーがすでに移動先のデータベースに存在する場合 構文 Redis MOVEコマンドの基本構文は以下のとお

  2. WordPressデータベースのクリーンアップ方法｜サイト高速化のための最適化手順とおすすめプラグイン5選

    WordPressサイトを快適に、そして高速に運用したいなら、データベースから不要なデータを取り除く「クリーンアップ」は欠かせません。WordPressデータベースのクリーンアップは、ページの表示速度を改善するために非常に効果的なメンテナンス作業です。キャッシュの活用、画像の最適化、JavaScriptの遅延読み込み、未使用CSSの削除といった他のパフォーマンス対策と併せて定期的に行うことで、より大きな効果が得られます。WordPressのデータベースには、投稿や固定ページなどのコンテンツだけでなく、コメント、リンク、ポートフォリオ項目、フォームの送信内容、プラグイン設定、テーマ設定、メディア