AWSホワイトペーパー「Amazon Aurora へのデータベース移行」の紹介

ホワイトペーパー概要

「Amazon Aurora へのデータベースの移行("Migrating Your Databases to Amazon Aurora")」は2015年6月にAWSが発行したホワイトペーパーです。

このホワイトペーパーは以下をカバーします

• Auroraの利点を学ぶ
• Auroraを起動し接続する手順
• Auroraのアーキテクチャ、スケーラビリティ、パフォーマンスについて学ぶ
• 他のDBからの移行手順

なかでも、非 MySQL 系 データベースを Amazon Aurora に移行する担当者向けに

• AWS Schema Conversion Tool(スキーマの変更)
• AWS Database Migration Service(データの移行)

を活用したデータ移行方法とデータ移行プロジェクトの計画・遂行方法が具体的にカバーされています。

全体で42ページあり、2016/07/08 時点では英語でしか提供されていていないため、ホワイトペーパーの概要をダイジェストでご紹介します。

目次

ホワイトペーパーの目次は以下の通りです。

• Contents
• Abstract
• Introduction to Amazon Aurora
• Database Migration Considerations
  • Migration Phases
  • Application Considerations
  • Sharding and Read-Replica Considerations
  • Reliability Considerations
  • Cost and Licensing Considerations
  • Other Migration Considerations
• Planning Your Database Migration Process
  • Homogenous Migration
  • Heterogeneous Migration
  • Migrating Large Databases to Amazon Aurora
  • Partition and Shard Consolidation on Amazon Aurora
  • Migration Options at a Glance
• RDS Snapshot Migration
• Migrating the Database Schema
  • Homogenous Schema Migration
  • Heterogeneous Schema Migration
  • Schema Migration using AWS Schema Conversion Tool
• Migrating Data
  • Introduction and General Approach to AWS DMS
  • Migration Methods
  • Migration Procedure
• Testing and Cutover
  • Migration Testing
  • Cutover
• Conclusion
• Contributors
• Further Reading
• Notes

Introduction to Amazon Aurora

Amazon Aurora がミッションクリティカルなアプリケーションにも向いたデータベースであると認識され、結果として、他の RDB から Amazon Auroraへの移行が進むように、Amazon Aurora の機能について様々な角度から解説されています。

Amazon Aurora 製品の詳細は次の URL から参照下さい。

https://aws.amazon.com/rds/aurora/

次の AWS Summit 2016での発表資料「Amazon Aurora Deep Dive ～性能向上の仕組みと最新アップデート～」も参照下さい。

PDF : http://media.amazonwebservices.com/jp/summit2016/2D-02.pdf

YouTube 動画

Database Migration Considerations

この章は Amazon Aurora 移行時にまず検討すべき項目について述べられています。

Migration Phases

データ移行プロジェクトをフェーズ分割し、移行と移行データの検証を何度も繰り返します。

※ 図はホワイトペーパーのFig.1 から

Application Considerations

既存アプリケーションと Amazon Aurora の相性はどうでしょうか?

親和性の高い MySQL 5.6 であっても、ストレージエンジンに MyISAM を使っていたり、サードパーティーのツールやプラグインを活用している場合は、Amazon Aurora への移行はスムーズには行えません。

Amazon Aurora の驚異的なベンチマーク結果に惹かれて移行を検討している方がいらっしゃるかもしれません。

アプリケーションごとにデータベースのアクセスパターンは異なるため、移行するアプリで検証するのが一番です。

MySQL 系データベースをご利用の場合は、スナップショットから Aurora を起動し、ワークロードを流して評価しましょう。 非 MySQL 系データベースをご利用の場合は、まずは取っ掛かりとして、一部のテーブルに限定して SQL を流して評価しましょう。

Amazon Aurora は並列度の高いクエリーで特に性能が高いです。

Sharding and Read-Replica Considerations

データベースを複数ノードでシャーディングしている場合、コスト・性能の観点から1インスタンスに集約することも検討して下さい。

参照系クエリーはスレーブ(レプリカ)インスタンスに任せましょう。スレーブインスタンスはフェイルオーバー先としての役割も担っています。

Reliability Considerations

Amazon Aurora は高可用性やディザスタリカバリーの観点ではどうでしょうか?

Amazon Aurora は

• RTO(recovery time objective)
• RPO(recovery point objective)

の点において、既存の RDS より優れています。

Cost and Licensing Considerations

データベースを移行する上では TCO(total cost of ownership) の評価は欠かせません。

Oracle/SQL Server/DB2 のような商用データベースをお使いの場合、コストのかなりの部分をライセンス費が占めていることでしょう。Amazon Aurora を使うと、商用エンタープライズ DB と同等の機能を提供しつつ、TCO を大幅に削減できます。

Other Migration Considerations

• アプリケーションの Amazon Aurora 対応の手間
• Amazon Aurora のパフォーマンス
• TCO
• 可用性

などの評価が終われば、データベース移行に伴う作業を検討します。

非 MySQL エンジンから移行する場合は、スキーマやコードの変更が発生します。 AWS Schema Conversion Tool を使ったスキーマ変更について、あとの章で解説します。

データ移行にあたっては

• サービスを一時的に停止する方法
• サービスダウンタイムをほぼ発生させずに移行する方法

があります。アプリケーションとビジネスの両面から方針を検討しましょう。

Planning Your Database Migration Process

Amazon Aurora への移行が決まれば、移行方針と移行計画を立てます。 その手助けをするのがこの章です。

ホワイトペーパーP.14-15 の”Migration Options at a Glance”には、移行パターンごとに選択肢がまとめられています。

表を再掲します。

※ネイティブツールは mysqldump, SELECT INTO OUTFILE、mydumper/myloader などのこと

• 移行元データベースが MySQL 系(homogeneous) VS 非 MySQL 系(heterogeneous)
• ダウンタイムあり VS ダウンタイムなし

によって移行方法は分かれます。

MySQL 系データベースからダウンタイムを伴う移行が一番シンプルで、その対極にあるのが、非 MySQL 系データベースからのダウンタイムを伴わない移行です。

主要パターンに対して、推奨される移行方法をまとめると、次の表のようになります

データ量の多いデータベースを移行する場合は

• スナップショットとレプリケーションを組み合わせる
• 変更があまり発生しないテーブル(たとえばマスタ系)は先に移行を済ませる
• 段階的に移行する
• 要らなくなったデータは捨てる

といったことも検討します。

シャーディング・パティショニングといったテーブル分割をしている場合、Aurora 移行を期にテーブルを一つにまとめると、パフォーマンスの観点でもTCOの観点でもメリットが出てくるかもしれません。

RDS Snapshot Migration

この章ではスナップショットを使った移行方法を解説しています。

RDS スナップショット方式はダウンタイムを伴いますが、スキーマとデータもまとめて移行できるので、単純明快なことです。

大前提として移行元で～tベースは RDS MySQL 5.6 で運用されている必要があります。

以下にご注意下さい。

• MyISAM を利用していて、テーブルを rOW_FORMAT=COMPRESSED オプションで圧縮していると、RDSインスタンスのローカルストレージを大量に消費するため、ディスク容量確保のために、一時的にインスタンスサイズを上げざるをえない可能性がある
• Aurora のストレージは 64 TB まで可能だが、スナップショットのサイズは EBS の制限から 6TB に制限される。

Migrating the Database Schema

スキーマとデータがまとめて移行する RDS スナップショット方式が使えない場合、まずスキーマを移行し、次にデータを移行する2段階方式となります。 この章ではスキーマ移行について解説し、次の章(“Migrating Data”)でデータ移行について解説します。

Homogeneous Schema Migration

MySQL 系の場合は MySQL のエコシステム内(mysqldump などのツール群)で解決します。

以下にご注意下さい。

• ストアドプロシージャ、トリガー、ビューのダンプ結果から、識別子 DEFINER を削除する(ホワイトペーパー内に削除する perl ワンライナーあり)
• MyISAM エンジンのテーブルは、Aurora 移行時に InnoDB エンジンに変更される
• 圧縮テーブル(ROW_FORMAT=COMPRESSED)は、Aurora 移行時に ROW_FORMAT=COMPACT に変更される。

Heterogeneous Schema Migration

非 MySQL 系の場合は

• AWS Schema Conversion Tool
• サードパーティーツール
• 手動でスキーマ変更

でスキーマ変更します。

AWS Schema Conversion Tool を使うと、データベーススキーマのみならず、ビュー、ストアドプロシージャ、関数の多くもよしなに変換され、変換できなかったものは警告メッセージが表示されるため、手動で対応します。

AWS Schema Conversion Tool の使い方は P.23 からの “Schema Migration using AWS Schema Conversion Tool” の節をご確認下さい。

Migrating Data

スキーマ移行が完了すれば、次はデータの移行です。

この章では、簡単・便利にデータ移行する AWS Database Migration Service(AWS DMS) について解説します。

Introduction and General Approach to AWS DMS

AWS MDS は以下の特徴があります。

• Oracle、SQL Server、MySQL、PostgreSQL、Amazon Aurora、MariaDB、Amazon Redshift に対応
• Oracle から Oracle のような同一な(homogeneous)エンジンへの移行だけでなく、Oracle から Amazon Aurora のような異なる(heterogeneous)エンジンへの移行にも対応します。
• データソース、ターゲットの両方がオンプレミス環境の場合は動作しません。

このホワイトペーパーでは、数ある組み合わせの中から Amazon Aurora への移行に絞って解説しています。

Migration Methods

移行方針は以下の3パターンがあります。

• 既存データの移行(“full load”とも呼ばれる)
• 既存データの移行 + 変更データのレプリケート移行
• 変更データのレプリケート移行

Migration Procedure

AWS DMS を使った移行手順は以下です

1. ターゲットデータベースの作成
2. スキーマのコピー
3. AWS DMS レプリケーションインスタンスの作成
4. 移行元データベースと移行先データベースの設定の設定
5. 移行タスクの実行

図はホワイトペーパー Figure 11: AWS Database Migration Service から

具体的な手順は、ホワイトペーパーを参照下さい。

注意点としては以下があります。

• レプリケーションインスタンスのスペックを上げたほうが、データ移行は早くなります。
• T2/C4 インスタンスタイプから選択可能です。
• T2 は検証やCPU バーストがあるようなデータ移行にむいています。
• C4 はデータ量が大きいデータベースに対して、移行時間を短く済ませるのに向いています。
• データ量が大きく、移行時も更新データが大量に発生するようなケースでは、インスタンスのストレージが十分にあるインスタンスを選んで下さい。
• DMS の設定により、データ移行時に、外部キー制約のチェックを外す事もできます。
• データの移行状況は AWS DMS の管理画面からモニターできます。

Testing and Cutover

この章は移行データの検証とカットオーバーまでの流れについて解説しています。

Migration Testing

移行データに対しては、次の表にあるようなアプローチの異なる複数のテストを実施します。

Cutover

最終的なデータ移行と移行データの確認が完了すれば、最後はカットオーバー、つまり、アプリケーションの向き先を移行先データベースに変えます。

Pre-cutover Actions -> Cutover -> Post-cutover Checks の順に行います。

Pre-cutover Actions

1. カットオーバーする時間帯を決める。データベースの更新が活発でない時間帯を選びます。
2. 変更データが滞り無く移行されていることを確認します。
3. アプリケーションのデータベース設定切り替えを行うスクリプトを用意します。
4. アプリケーションのデータベース更新を止めます
5. データ移行が完了していることを確認する自動テストを流します

Cutover

1. カットオーバー(アプリケーションを移行先データベースに向けます)
2. アプリケーションを再開する

Post-cutover Checks

1. カットオーバーが期待通り動作していることを確認するテストを流す。データベースの読み取りテストのあとで書き込みテストをすると良いでしょう
2. カットオーバー完了後、しばらくはアプリケーションと新しいデータベースを注意深く監視する

おわりに

Amazon Aurora は MySQL 互換のため、MySQL 系データベースエンジンから Amazon Aurora への移行では、 MySQL の機能を使うとスムーズに移行できます。

Oracle/SQL Server など MySQL 系以外のデータベースエンジンから Amazon Aurora への移行では、 AWS Database Migration Service(AWS DMS)と AWS Schema Conversion Tool を利用すると、移行時に伴う費用や複雑な作業を軽減することができます。

このホワイトペーパーでは、単純なデータ移行処理だけでなく、データ移行計画の立て方、移行データの検証、データベースの切り替えなど、データ移行プロジェクトの全工程がカバーされています。

多くのエンジニアにとって、データ移行プロジェクトに関わる回数はそれほど多くないと思います。 Amazon Aurora へのデータ移行を検討している、あるいは、移行中のプロジェクト関係者にとっては、データ移行の概要を把握する上で非常に有益なホワイトペーパーではないでしょうか。

なお、AWS Database Migration Service(AWS DMS)と AWS Schema Conversion Tool(AWS SCT) はまだ誕生して間もなく、発展途上中のサービスです。 これらサービス・ツールの機能拡充に伴い、Amazon Aurora への移行は、本記事で紹介したものよりもより楽になっていくものと思われます。

データベース移行の大方針はホワイトペーパーを参考にし、最新情報はこれらサービス・ツールのドキュメントで補完していただければと思います。

参照

• Amazon Aurora
• Whitepaper : Migrating Your Databases to Amazon Aurora
• AWS Database Migration Service(AWS DMS)
• AWS Schema Conversion Tool