SCSKの畑です。
とある案件において 他クラウド IaaS 上の Redis から Amazon Elasticache（Redis OSS）へのデータ移行要件があったため、移行方式についてどの方式を採用したのかを含めてまとめてみました。
背景
前回のエントリでも軽く触れた通り Redis は KVS のため、例えばキャッシュのような揮発性の高いデータのみが格納されているようなケースではデータの移行要件がないこともありますし、移行対象のデータがあるとしても新しく立てた Elasticache にアプリケーション/バッチなどから必要なデータを改めて入れ直すなど、現行の Redis からデータを移行する必要がないことも多いと思います。
ただ今回の案件については、現行の Redis からデータを移行する要件がお客さんとの会話等などから明確であったため、それを踏まえて Redis から Elasticache（Redis OSS）へのデータ移行方式を検討することとなりました。
Amazon Elasticache の移行方式
Elasticache への移行方式は以下3種類となります。一括移行 or 初期移行＋差分移行という考え方そのものは RDBMS などと同じですね。
ちなみに、初期移行は差分移行を開始する前に現行環境から新環境にデータを移行する工程、差分移行は現行環境の更新データを初期移行直後の時点から新環境に対して継続的にレプリケーションする工程をそれぞれ指します。一括移行は言葉通りの意味ですね。
- 一括移行
- 初期移行＋差分移行（AWS マネージド）
- 初期移行＋差分移行（RIOT などの外部移行ツール）
当初は初期移行＋差分移行の選択肢として DMS を使えると思っていたのですが、改めて調べるとサポートされているのは移行ターゲットのみであることが分かり、今回のケースでは採用できませんでした。
Elasticache における一括移行は、移行元の Redis で save コマンドなどで rdb ファイルのバックアップを取得して S3 に転送・配置した上で、そのバックアップを使用して新しく Elasticache のインスタンスを立ち上げる流れとなります。
対して、初期移行＋差分移行の方式は、AWSマネージドの方式と、RIOTなどの外部移行ツールを使用する方式の2種類があります。AWSマネージドの方式については、以下 AWS ドキュメントに一通りの記載があります。
外部移行ツールを使用する場合は、ある意味当然ながらそのツール仕様に準じます。今回移行方式としては採用しなかったのでざっくり調べた程度ですが、ツールとしては Redis 公式？の RIOT が最もメジャーなようです。
必ずしも Elasticache 固有の内容ではありませんが、それぞれの移行方式の特徴についても簡単にまとめておきます。
- 一括移行
- メリット
- 移行（切替）当日に移行対象の全データを現行環境から新環境に移行する方式のため、初期移行＋差分移行と比較して相対的に手順がシンプル
- 移行に要するトータルの工数も（一般的に）少ない
- デメリット
- 移行（切替）当日の所要時間・工数は初期移行＋差分移行と比較すると多くなる
- このため、移行（切替）時のスケジュールが一括移行の所要時間に収まらない場合は、スケジュールを見直す or 初期移行＋差分移行方式を採用する、の2択となる
- 移行（切替）当日の所要時間・工数は初期移行＋差分移行と比較すると多くなる
- メリット
- 初期移行＋差分移行
- メリット
- 一括移行と比較して、移行（切替）当日の所要時間・工数は少ない
- 差分移行に使用する製品・サービス（例えば DMS など）によっては差分移行中に現行環境/新環境間のデータ整合性チェックを実施することも可能
- 移行（切替）当日に現行環境/新環境間でデータの整合性をチェックできるのが理想だが、移行対象のデータが大きい場合は移行（切替）時のスケジュールに収まらなくなる可能性があるため、このような方式で整合性チェックを行うことも選択肢に入ってくる
- デメリット
- 移行方式における制約や注意すべき事項が多い
- 初期移行において現行環境からデータを移行する際、現行環境への影響を考慮の上で具体的な方式・手順を決定する必要がある
- 初期移行は現行環境のシステムが稼働している状態で実施することが方式の特性上ほぼ前提となるため
- 逆に言うと、初期移行時に現行環境のシステムを停止できるのであれば事実上一括移行が可能と言えるため、この移行方式をわざわざ採用する必要がない
- 差分移行に使用する製品・サービスにおける各種制約に抵触していないかを確認する必要がある
- 制約に抵触することの影響度合いはケースバイケースだが、方式自体の採用可否に影響する場合もある
- 差分移行の特性上現行環境と新環境が相互通信できる必要があるため、通信経路の確立や帯域制限などが方式上のネックになる場合もある
- 初期移行において現行環境からデータを移行する際、現行環境への影響を考慮の上で具体的な方式・手順を決定する必要がある
- 上記内容も相まって、移行に要するトータルの工数は（一般的に）多い
- 移行方式における制約や注意すべき事項が多い
- メリット
今回採用した Amazon Elasticache の移行方式
結論から言うと、今回は「一括移行」を採用しました。上記で移行方式の特徴をまとめた通り、一括移行の採用可否は実質的に移行（切替）当日の想定スケジュールに一括移行の所要時間が収まるかどうかですが、検証環境で時間を計測したところ無事に収まりそうなことが分かったためです。具体的な所要時間の試算は以下のような流れで行いました。
まず、今回移行対象となる Redis は 2 個あります。キャッシュサイズはそこそこ差があり、大きい方が約 100 GB だったため、ほぼ同じサイズのキャッシュデータをオンプレミス仮想環境上の Redis に用意した上で、Redis から rdb ファイルにバックアップする所要時間、及び S3 上のバックアップを Elasticache for Redis OSS にリストアする所要時間をそれぞれ計測しました。
- Redis から rdb ファイルにバックアップ： 20 分
- rdb ファイルのサイズは約 98 GB
- お客さんの IaaS 環境上ではもう少し早くなりそうですが（10-15分程度）、試算では上記計測値を使用
- rdb ファイルのサイズは約 98 GB
- S3 から Elasticache for Redis OSS にリストア： 35 分
- インスタンスサイズは cache.r7g.8xlarge
一括移行の所要時間としては上記に加えて Redis サーバから S3 へのバックアップファイル転送時間がプラスされますが、こちらはお客さんの IaaS 環境上で試算したところ 20 分程度見ておけば良さそうということで、合計で 20 + 20 + 35 = 75 分となりました。もう 1 個のキャッシュサイズは小さいため、トータルの所要時間への影響はほぼないと判断しています。
また、先述の通りバックアップを使用して Elasticache インスタンスを新しく作成する手順となるため、作成後に単体テスト・動作確認を実施する方針となりました。直列で作業する前提で 1 個につき 30 分かかるとしても 2 個で 60 分、合計すると 135 分となります。
移行（切替）当日の想定スケジュールにおいて、データベース/Elasticache の移行に使用できる時間は最大 6 時間であるため、無事 Elasticache については時間内に一括移行できる見立てとなりました。
なお、このような検討過程であったため差分移行については真剣に検討するまで至らなかったのですが、ざっくり調査した内容及び所感を以下にまとめておきます。（真剣に検討していないのであくまでも参考程度で・・）
- AWS マネージド
- 初期移行および差分移行の両方をカバーしており、使用方法自体も非常に簡単
- そもそもコンソール/コマンドから設定できる項目も必要最低限（実質的に移行元 Redis への接続情報のみ）
- https://docs.aws.amazon.com/cli/latest/reference/elasticache/start-migration.html
- そもそもコンソール/コマンドから設定できる項目も必要最低限（実質的に移行元 Redis への接続情報のみ）
- その反面、使用に際しては様々な制約があるため、特に本番環境の移行で使用できるケースは限定的と思われる
- 特に「転送（接続）時のSSL無効化」や「認証の無効化」が必要なため、移行元の Redis でこれらの制約を満たさない場合は使用できない（今回の案件でもこの時点で採用 NG）
- https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/Migration-Prepare.html
- 特に「転送（接続）時のSSL無効化」や「認証の無効化」が必要なため、移行元の Redis でこれらの制約を満たさない場合は使用できない（今回の案件でもこの時点で採用 NG）
- 移行対象の論理データベースやデータをフィルタリングするような機能はない
- レプリケーション開始時にターゲットとなる Elasticache のキャッシュデータが削除される仕様も良し悪し
- レプリケーションが失敗した場合の再試行自体は行いやすい反面、失敗した時点から再開するようなことはおそらくできないものと思われる（自動復旧した場合は別かも？）
- 初期移行および差分移行の両方をカバーしており、使用方法自体も非常に簡単
- 外部ツール（RIOT）
- AWS マネージドの場合と比較して、認証や転送（接続）時の SSL が有効な場合も対応可能
- RIOT が動作する中間サーバを用意する必要あり
- レプリケーション動作モードに scan と liveonly、及び 両方を併用した live の3種類がある
- scan は実質的な初期移行、対象の key や type、回数などをオプションとして指定可能
- liveonly は実質的な差分移行（レプリケーション）だが、ドキュメント曰くデータの整合性を保証しないとのこと
- NW 障害時に Redis 上データの更新通知を RIOT が受け取れなかったり、Redis 上の大量データ更新時に Redis 自身が大量データの更新に追随できない（更新通知を送れない）可能性がある
- レプリケーション動作時の挙動も dump/restore コマンドを使用するモード、及びデータタイプにより異なるコマンドを使用するモードの 2 種類がある模様
- こちらは特別な理由がない限り前者で良さそう（デフォルトも前者）
もし今回の案件で使用せざるを得ない場合は上記制約との兼ね合いで RIOT になりますが、設計には正直骨が折れそうです。。
まとめ
Elasticache に限った話ではありませんが、このようなデータ移行についてはまず一括移行できないかどうかを優先して考えるべきです。逆に言うと、初期移行＋差分移行は対象システムの重要度や特性に基づく移行要件、及びデータ量などを鑑みた場合に（ある意味）やむを得ず選択する方式というくらいの位置づけで考えて良いと思っています。もちろん、DMS を始めとして初期移行＋差分移行に使用できる製品・サービスはここ 10 年くらいで大分充実してきているので、取り得る選択肢が広がっているのはいいことですが。
最も、Elasticache（Redis）はインメモリベースであるため、一般的な RDBMS のようなディスクベースの製品・サービスと比較して相対的に高速にデータ移行できるであろう点も踏まえると、一括移行する方針により倒しやすいとは思います。。
本記事がどなたかの役に立てば幸いです。