目次
記事説明
この記事では、「Migration & Transfer」分野の重要なサービスである、
AWS DMS（Database Migration Service）について説明します。
↓Migration & Transferの重要なサービス一覧
・AWS Application Discovery Service
・AWS Server Migration Service
・AWS Snow Family
・AWS DMS
↓参考：【AWS Black Belt Online Seminar】AWS Database Migration Service
https://d1.awsstatic.com/webinars/jp/pdf/services/20170919_AWS-BlackBelt-DMS.pdf
実施プロセスのおさらい
移行の実施プロセスのおさらいです。
ディスカバリー ・・・ 移行対象機能の洗い出しなど
↓
設計 ・・・ 計画、手順設計、作業見積もりなど
↓
変換 ・・・ ネットワーク、アプリケーションの実装、単体テストなど
↓
移行 ・・・ パイロットテスト（受け入れテスト）、リリース準備など
↓
運用 ・・・ プロビジョニング、利用者研修、インシデント対応など
↓
最適化 ・・・ 移行後の評価と最適化、継続的なアップデートなど
変換・移行のフェーズにおいて、利用できるサービスが
「Database Migration Service」となります。
Database Migration Service（DMS）の概要
概要としては、
「既存のデータベースを最小限のダウンタイムでマイグレーションする」
サービスで、異種プラットフォーム間の移行にも対応しております。
| From | To オンプレミス | To DB On EC2 | To RDS | To S3 |
| オンプレミス | × | 〇 | 〇 | 〇 |
| DB On EC2 | 〇 | 〇 | 〇 | 〇 |
| RDS | 〇 | 〇 | 〇 | 〇 |
※オンプレミス ⇒ オンプレミスは対応不可です。
下記がおおまかなデータ移行の流れとなります。
①DMSがソースDB（Oracle）とターゲットDB（Aurora）に接続
②対象のテーブル、スキーマ等を選択
③DMSがターゲットDBに対し、テーブルを作成し、データをロードしてレプリケーションを開始
なお、DMS以外のデータ移行方法を知ったうえで、
DMSを利用するべきかどうかを検討するのが良いです。
下記のケースにおいては、DMSを利用するメリットを享受できます。
・十分な停止時間が取れない
・移行元DBと移行先DBが別のエンジン（別プラットフォーム）である
引用元：https://d1.awsstatic.com/webinars/jp/pdf/services/20170919_AWS-BlackBelt-DMS.pdf
Database Migration Serviceの特徴
１．最小限のダウンタイム
オンラインでの継続的レプリケーション対応
２．利用が簡単
コンソールで数回クリックするだけ
３．豊富な対応プラットフォーム
Oracle, Microsoft SQL Server, SAP ASE, MySQL, MariaDB,
PostgreSQL, Aurora, Redshift, S3, MongoDB, DynamoDB
４．簡単なセットアップ
ソースDBへの変更はほぼ不要
５．高い信頼性
マルチAZ可能なインスタンス
６．低コスト
データ移行タイミングでのみ、インスタンスの従量課金が発生
データ移行におけるセキュリティ
データ移行時のセキュリティを担保するために、オンプレミス側のファイヤーウォールと、
AWS側のセキュリティグループに対して、透過設定を行う必要があります。
移行タイプについて
１．FullLoad ・・・ 既存のデータを移行する
現時点でソースDBに入っているすべてのデータをターゲットDBに移行します。
DMSインスタンスがソースDBのテーブルをSELECTし、必要に応じてデータ変換した後、
ターゲットDBにINSERTを行います。
※DMSインスタンスはEC2インスタンスなので、
メモリだけで処理しきれない場合は、EBSがスワップ領域として使われます。
２．Change Data Capture(CDC) ・・・ データ変更のみをレプリケートする
ソースDBに対する変更データをキャプチャし、ターゲットに適用します。
ソースDBのトランザクションログ（バイナリログ、WAL、REDOログ）を5秒間隔で
DMSインスタンスがキャプチャし、SQLに変換した後、ターゲットDBに実行します。
※ターゲットDBに接続できない、遅延が発生、FullLoadの完了待ちの場合は、
DMSインスタンス内のキューに保存されます。
３．既存のデータを移行して、継続的な変更をレプリケート（1+2のイメージ）
監視すべきメトリクスについて
１．CPUUtilization（CPU使用率）
ボトルネックになりやすい部分なので、
もし高ければ、より大きなインスタンスに変更することを検討した方が良いです。
２．FreeableMemory / SwapUsage / FreeStorageSpace
メモリ使用率は、CPU使用率の次にボトルネックになりやすいので、
GB単位でスワップしていた場合はより大きなインスタンスに変更するか、
読み取り行単位を減らしたりする必要があります。
３．NetworkTrasmitThroughput / NetworkReceiveThroughput
タスクが多く、ネットワーク帯域が不足している場合は、
帯域確保のためにインスタンスを分割した方が良いです。
４．CDCChangesDiskSource
ソースDBのCOMMIT待ち。トランザクションが長い場合は
ディスクサイズを大きくするか、チューニングする必要があります。
５．CDCChangesDiskTarget
増え続ける場合、ターゲットDBが処理しきれていないことが原因となります。
放置しているとディスクフルで停止してしまいますので、要チューニングです。
※チューニング方法例
対象スキーマやテーブルを絞り込んで一度に処理するデータ量を少なくしたり、
一度にSELECTするデータ量を少なくする。等
AWS Schema Conversion Toolについて
ソースDBのスキーマ、ビュー、ファンクション、ストアドプロシージャを
自動的にターゲットDBの互換フォーマットに変換できるアプリケーションです。
WindowsやMac、Linux等にインストールして利用します。
特徴を以下にまとめます。
１．手動変換の補助
自動変換できない箇所とその理由を明示してくれます。
２．評価レポートの作成
何割のオブジェクトが自動変換可能かなどのレポートを作成できます。
３．アプリケーションSQLに対応
Java,C++などのアプリケーションソースコードをスキャンしてSQLに変換します。
まとめ
DMSとSCTを組み合わせてデータ移行を行う一般的な流れは、下記の通りとなります。
１．SCTでテーブル定義とPK制約を移行
２．DMSでFullLoadとCDC開始
３．FullLoad完了後にセカンダリインデックスを定義
４．CDCLatencyが小さくなったタイミングでアプリからの書き込み停止（ダウンタイム開始）
５．endマーカーをソースDBにINSERT
６．endマーカーのターゲットDB到着を確認（マーカー以前のトランにおいて、完了を保証）
７．アプリをターゲットDBに接続（ダウンタイム終了）
それでは、お読みいただきありがとうございました。
