Amazon RDS for MySQL から Amazon Aurora 移行の概要について

Amzon RDS for MySQL から Amazon Aurora への移行は、非常に需要の高く “実施したい施策” の一つとして挙げられます。
今回は、そんな移行作業はどのように行うのが得策か。また、その他 TIPS について整理していきます。

—

なぜ Amazon RDS for MySQL から Amazon Aurora へ移行するのか
移行に伴う考慮点について
移行手順について
移行ツール/サービスについて
最後に

■ 1. なぜ Amazon RDS for MySQL から Amazon Aurora へ移行するのか

MySQL は世界で最も普及しているオープンソースデータベースです。しかしながら、MySQL の多くの利用者・運用管理者は、日々の運用としてバックアップや高可用性の確保に多くの時間がかかっています。また MySQL のスケーリングは複雑であり、時間がかかることに苦労するケースが散見されます。

Amazon RDS for MySQL から Amazon Aurora へ移行したい、と戦略をもって計画されるお客様の中には、DBA エンジニアや MySQL 利用者の時間を削減したい場合があります。

なお、Amazon Aurora ではポイントインタイムリカバリや高可用性などのオプションに対して、複雑な設定など一切なしですぐに使用できる機能を提供しています。
さらに、ソースあたり 5 つのリードレプリカに対応しています。Amazon Aurora ではバイナリログ (binlog) レプリケーションを手動で設定したり、保守したりする必要なく、簡単にワークロードをスケール可能です。

MySQL との互換性を持つ Amazon Aurora を使用することで、fast database clones および autoscaling replicas などの機能が利用できます。また、AWS Lambda および Amazon CloudWatch Logs といった他の AWS サービスとの連携も可能になります。これらの機能に加えて、Amazon Aurora はまた、3 つのアベイラビリティーゾーンをまたぐデータのレプリケーションが可能となります。また、最大で 15 個の Aurora レプリカに対して、基本的には 20 ミリ秒未満のレイテンシーでスケール可能です。

■ 2. 移行に伴う考慮点について

Amazon RDS for MySQL から Amazon Aurora へ移行にともなう考慮点について整理していきます。

移行するデータベースに依存するアプリケーションや、DB 移行中の可用性については、お客様のビジネス要件（ダウンタイム許容時間など）を事前に考慮する必要がが考えられます。

また、Amazon Aurora の MySQL エディションへ移行するときは、Aurora が MySQL 5.6 または MySQL 5.7 とワイヤー互換であることが重要です。これは、アプリケーションの視点からは MySQL 5.6 または 5.7、Aurora 5.6 または 5.7 との間に差異はありません。そのため、移行工程において、既存のアプリケーションコードを変更する必要はありません。しかしながら、この点については、事前にテスト環境等で、動作検証を行うことをおすすめいたします。

なお、アプリケーション上のコードに変更は不要であった場合でも、アプリケーションから新しいデータベースをポイントする方法が必要になります。その際の一般的なアプローチの一つとして、DNS を DB 接続先としてポイントする方法が考えられます。この方法の場合は DB 接続文字列にデータベースインスタンスのホスト名を使用しません。代わりに、データベースインスタンスのホスト名をポイントする正規名 (CNAME) レコードを作成するアプローチが考えられます。これを実行することで、複数の接続文字列設定を変更するのではなく、アプリケーションがポイントする 1 つのロケーションへのエンドポイントを変更できるようになります。

この方法を使用する場合には CNAME レコードの有効期限 (TTL) 設定を慎重に定義する必要があります。この設定値が高すぎる場合は、この CNAME によってポイントされるホスト名が求めるより長くキャッシュされる可能性があります。一方、この設定値が低すぎると、クライアントアプリケーションは、この CNAME を繰り返し解決しなくてはならなくなり、クライアントアプリケーションに余分なオーバーヘッドがかかる可能性があります。ユースケースごとに状況は異なるものの、TTL は最初 5 秒から始めるのがベストプラクティスです。

■ 3. 移行手順について

移行手順については、Aurora リードレプリカを使用した方法で、DB 移行手順の概要を確認していきます。下記の 1)〜5) の手順に沿って移行作業を行います。

1) Aurora リードレプリカの作成

既存の Amzon RDS for MySQL インスタンスを Amazon Aurora クラスターへ移行する最初のステップは、Amazon RDS マネジメントコンソールでインスタンスを選択することです。その後、インスタンスアクションで [Aurora リードレプリカの作成] を選択します。

次に Aurora クラスターを定義する「DB エンジンのバージョン」などの各種パラメータを選択します。ここでは、今後のメンテナンス運用も考慮し、なるべく新しいマイナーバージョンをご選択いただくことをお勧めいたします。また、Amazon Aurora クラスターにはソースインスタンスと同一のマスターユーザー名とマスターパスワードとなります。

移行の工程を始めると、既存の Amzon RDS for MySQL インスタンスのスナップショットを作成し、スナップショットからのデータを新しく作成した Amazon Aurora クラスターへ復元します。ソースデータベースのサイズにも依存しますが、この処理には数時間かかる可能性があります。

Amazon Aurora クラスターが作成され、初期セットのデータがロードされると、Amzon RDS for MySQL インスタンスから Amazon Aurora クラスターへの binlog レプリケーションを確立します。

2) データ移行中のモニタリングについて

binlog レプリケーションが確立され、レプリケーションが始まったら、Amazon Aurora クラスター上で CloudWatch メトリクス Aurora Binlog Replica Lag のモニタリングを開始することをお勧めします。

CloudWatch は binlog レプリカラグの俯瞰的なビューを提供しますが、新しく作成された Amazon Aurora クラスターにログインすることで、より詳細な測定値を見ることが可能です。そのためには、MySQL クライアントからコマンド “show slave status\G” を実行してください。

このコマンドは非常に多くの有用な情報をレスポンスしますが “Seconds_Behind_Master” のメトリクスが “0” になると、新しく作成した Amazon Aurora クラスターはオリジナルの Amazon RDS for MySQL インスタンスと同期されることを確認できます。

3) Amazon RDS for MySQL の停止

新しい Amazon Aurora クラスターと、オリジナルの RDS for MySQL インスタンスとの同期が取れたことを確認します。RDS インスタンスを停止することで Amazon RDS for MySQL インスタンスへの書き込みを停止します。これによって、追加的な書き込みを回避します。ここからは、新しい Amazon Aurora クラスターへの書き込みを開始します。

4) 停止後のモニタリング

RDS インスタンスが停止したことを確認し、再度上記の MySQL コマンド発行にて “Seconds_Behind_Master” の値をもう 1 度確認し、すべての binlog が適用されていることを確認します。

5) Aurora リードレプリカの昇格

最後にAurora のリードレプリカをライターに昇格します。これを実行するには、ターゲットの Aurora クラスターを選択し、[インスタンスの操作] で [リードレプリカの昇格] を選択します。これを選択してから処理が完了するまで数分かかります。この時点でアプリケーションの DB 接続先となる CNAME を変更します。

その後、新しい Amazon Aurora のクラスターの [最新のイベント] を確認することで、これらの移行プロセスが完了したかを確かめることができます。

■ 4. 移行ツール/サービスについて

データベースの移行ツール・サービスとして AWS Database Migration Service (AWS DMS) および AWS Schema Conversion Tool(AWS SCT) はよく利用されます。それぞれのツールまたはサービスは、ユースケースやワークロードにあわせて適宜利用すると便利です。

[AWS Database Migration Service (AWS DMS)]

リレーショナルデータベースや、データウェアハウス、NoSQL データベース、その他の種類のデータストアを移行する際に役立つサービスです。
AWS DMS では、既存のデータをロードすることが可能です。また、移行を実施したり継続的な変更・更新をレプリケートとしてソースとターゲットの同期を維持することができます。

なお、異なるデータベースエンジンに移行を実施することができます。

参照：https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/Welcome.html

[AWS Schema Conversion Tool(AWS SCT)]

データベーススキーマを新しいプラットフォームに変換できるツールです。なお、ターゲットテーブル、インデックス、ビュー、トリガーなどの一部またはすべてを作成することができます。

変換されたスキーマは、Amazon EC2 インスタンスでデータベースと共に使用するか、Amazon S3 バケットでデータとして保存することもできます。

■ 5. 最後に

いかがでしたでしょうか。今回は需要の高い Amzon RDS for MySQL から Amazon Aurora への移行について、軽くふれていきました。DB 移行の概要についてイメージできたのではないかと思います。これから移行を検討されている方や、移行設計を作成されている方などにご参考になればと思います。