こんにちは、技術４課の多田です。
飯田橋のオフィスの前の桜並木がちらほら咲き始めて、今年もオフィスからの桜の眺めは最高です！
ぜひ、飯田橋オフィスのお越しの際は見ていただければと思います。
さて、今回から複数回に分けてDatabase Migration Service(以下、DMS)に関するブログを投稿していきます。
案件にてオンプレミスのデータベースをAuroraに移行するにあたり、DMSを使って得た経験(設計,注意点)を書いていければと思います。
今回は、DMSによる移行を行うための「準備編」となります。
DMSとは？
そもそも、DMSとは、オンプレミス/クラウド環境問わず、最小のダウンタイムでデータベースを移行するためのサービスになります。
特徴的なのは、データベースエンジンの差異を吸収し、移行支援してくれるところです。
具体的な機能でいうと、移行元のデータベース(ソースデータベース)のテーブルやプロシージャなどを移行先のデータベース(ターゲットデータベース)で利用できるものに変換するSchema Conversion Tool(以下、SCT)です。このツールがデータベースエンジンの差異を吸収した移行支援をしてくれます。
また、SCTによる変換をかけた後にDMSで移行できる/できないテーブルやプロシージャなどを抽出し、レポートとして出力もしてくれます。具体的なレポートの内容については次回の検証編でご紹介予定です。
出力されるレポートのイメージは、こちらのドキュメントに掲載されているのでご覧いただけますと幸いです。
私が関わった案件では、オンプレミスのMicrosoft SQL ServerからAuroraへの移行でしたので、こういったデータベースエンジンが違っていても移行できるのは非常に魅力的です。
DMSの利用料金
レプリケーションインスタンスの利用料金
| インスタンスタイプ | 時間当たりの料金(シングルAZ) | 時間当たりの料金(マルチAZ) |
| t2.micro | $0.028 | $0.056 |
| t2.small | $0.056 | $0.112 |
| t2.medium | $0.112 | $0.224 |
| t2.large | $0.224 | $0.448 |
| c4.large | $0.196 | $0.392 |
| c4.xlarge | $0.391 | $0.782 |
| c4.2xlarge | $0.783 | $1.566 |
| c4.4xlarge | $1.564 | $3.128 |
ストレージの料金
データ転送の料金
移行に向けての準備
移行に向けての準備として、次のことを行いました。
- 移行検証用のデータベースの準備
- オンプレミスとAWSを繋ぐネットワークの確保
- ターゲットデータベースの作成
- ソースデータベース側の制限確認や設定確認
- DMSのパラメーター設計
上記の準備で行ったことについて以下で個別に記載していきます。
なお、案件における構成イメージとしては以下のようなもので、検証用データベースをAuroraへ移行しました。
1.移行検証用のデータベースの準備
こちらはいきなり本番環境の移行というのはハードルが高くなるため、お客様に本番用データベースよりも小さな検証用のデータベースを作成いただきました。
このデータベースを使ってAuroraへ移行の検証を行いました。
2.オンプレミスとAWSをつなぐネットワークの確保
オンプレミスとAWSを繋ぐためにネットワークの確保を行います。
AWS環境へ接続するには次のようにいくつか方法があります。なお、案件では、VPNを使った経路を確保しました。
- インターネット経由での接続
- この場合、DMSとソースデータベースにパブリックIPアドレスの付与が必要となります。
- SSL通信を行うためには、SSL証明書をDMSに登録する必要があります。
- VPN経由での接続
- 専用線(Direct Connect)経由での接続
- VPN/Direct Connect経由での接続であれば、ローカルIPアドレスで接続可能です。
移行するデータベースのデータ量にもよると思いますが、大量のデータを移行する場合、例えば、専用線で帯域幅を確保して継続したレプリケーションを行える環境を整えるべきです。
参考値となりますが、検証用データベース(1GB未満のデータ量)をVPN経由で移行した場合、3~4分ほどで移行が完了しました。また、数百件のデータの変更についても数十秒以内に検知し、Auroraに同期されました。
詳しくは、こちらを合わせてご覧ください。
3. ターゲットデータベースの作成
DMSで移行するターゲットデータベースのAuroraも事前に構成しておきます。
検証用データベースを移行するため、最小の構成で設計しました。
以下がAurora設計で気にした点となり、他のパラメーターは基本的にデフォルト定義を行っております。
- 構成
- Auroraレプリカは作成せず、プライマリインスタンスのみの構成としました。
- インスタンスタイプ
- t2.mediumで構成しました。
- AZオプション
- シングルAZで構成しました。
- 管理者ユーザー/パスワード
- お客様指定のものを設定しました。
- 自動バックアップ取得時間及びメンテナンス時間
- こちらもお客様指定のものを設定しました。
4.ソースデータベース側の制限確認や設定確認
移行対象のデータベースがDMSで移行できるのかも確認する必要があり、こちらはお客様に用意していただ検証データベースの確認を依頼しました。
依頼に際しては、こちらのドキュメントに移行対象のデータベースエンジンごとの案内がありましたので、「Microsoft SQL Server データベースの AWS Database Migration Service のソースとしての使用」の確認依頼を行いました。
また、ソースデータベースでSCTを使うためのセットアップ依頼も合わせて行いました。
SCTのセットアップには、２つの条件を満たす必要があります。
- ソースデータベースへの権限付与
- こちらに記載の各ソースデータベースの権限の記載がありますので、必要な権限付与依頼を行いました。今回は、MS SQL Serverなので、移行するデータベースに「VIEW DEFINITION」と「VIEW DATABASE STATE」の付与を依頼しました。
- データベースのドライバーのダウンロード
- こちらの「必要なデータベースドライバのインストール」からソースデータベース/ターゲットデータベース(移行先データベース)のドライバーをソースデータベース環境にダウンロードします。
尚、DMS自体の制限事項もありますので(こちら)、ソースデータベースが制限に該当しないことの確認を行いました。
5.DMSのパラメーター設計
最後に、DMSを利用するためのパラメーターを設計していきました。尚、DMSを構成するための各パラメータの説明は、こちらに記載されているので合わせてご覧ください。
検証用のデータベースはあまりデータ量が多くなかったため、設計で注意したのは以下の点です。
- レプリケーションインスタンスタイプ
- データベースのレプリケーションを行うEC2ですが、移行検証の目的での利用でしたので、t2のインスタンスタイプを選択しました。
- ストレージボリュームサイズ
- 検証用データベースのサイズは小さかったので、できる限りボリュームサイズも小さくしようと思いました。
- t2インスタンスのデフォルトが50GBですが、最小のボリュームサイズが調べてみたところ10GBまで選択できたので、10GBで設計しました。
- レプリケーションインスタンスのセキュリティグループ/ターゲットデータベースのセキュリティグループ
- 今回はVPN経由での移行でしたので、ソースデータベースのIPアドレスを確認し、デフォルトですべての通信を許可するルールを採用して、設定し、移行検証中に調整することにしました。
- ターゲットデータベースのセキュリティグループは、DMSのサブネットからのMYSQLの通信を許可するようにして設計しました。
- レプリケーションタスク
- 基本的にタスクはデフォルト設定ですが、移行形式は今回はデータベースを一度フルロードし、ソースデータベース側に変更があったら、都度レプリケーションを行うもの(Migrate existing data and ongoing changes)を選択しました。この移行方式を行う場合、ソースデータベース側でレプリケーション設定を有効化する必要があります。MS SQLの場合は、こちらとこちらを合わせてご覧ください。
- また、何か移行中にエラーが発生した場合に備え、CloudWatch Logsの記録を有効化しました。ログは移行タスクを削除しても残り続けるため、万が一に備え有効化しておくと良いと思いました。
まとめ
以上がDMSを利用するための準備で行ってきたことをまとめたものになります。
なお、上記の設計で検証中にパフォーマンスに問題があれば適宜パラメーターを変更を行う想定でしたが、データ量が多くなかったためか、検証段階ではDMSやAuroraのパフォーマンスは特に問題とはなりませんでした。
さて、準備ができたら実際の移行を行っていきますが、その内容は次回「移行編」で書いていきます！
データベースを移行した時のTipsや考慮点を書いていけたらと思います。
ご期待ください！
この記事で何かの役に立てば幸いです、それでは！
