【レポート】 AWS Database Migration Service & Schema Conversion Tool ベストプラクティス／AWS Solution Days 2017 ～AWS DB Day～ #AWSDBDay
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
2017年07月05日(水)に、大崎ブライトコアホールにて『AWS Solution Days 2017』なるイベントが開催されました。
イベントのコンセプトは以下(イベント紹介サイトより抜粋)。当エントリでは『AWS Database Migration Service & Schema Conversion Tool ベストプラクティス』セッションの模様をレポートします。
会場の大崎ブライトコアは大崎駅から5分程歩いた場所にあります。当日は台風も懸念されましたがご覧の様に問題無く良い天気でした！
ちなみに当イベントは
目次
セッションレポート
当基調講演セッションのレポートは以下となります。当エントリではJohn Winford氏が解説した「DMSとSCTのベストプラクティス」についてその内容をレポートします。
登壇者及びセッションの内容詳細は以下の通りです。
John Winford(Amazon Web Services, Inc.)
Sangpill Kim(Amazon Web Services, Korea)
セッション概要：
AWS Database Migration Service と Schema Conversion Tool を活用してデータベースを移行する際のベストプラクティスを解説します。
製品概要
- DMS／SCTとは何か
- DMS＝AWS Database Migration Serviceの略記。簡単かつセキュアにDBとDWHをAWSへ移行、及びレプリケーション。
- SCT＝AWS Schema Conversion Toolの略記。DWHのスキーマをオープンソースエンジンや、Aurora/Redshiftの様なAWSネイティブサービス用のスキーマに変換。
- 上記いずれも多くのお客様に利用頂いており(既に3万データベースを移行済)、更に増え続けている。
- SCTをいつ使うか
- DB間のモダナイズ
- 既存DWHのモダナイズとAmazon Redshiftへの移行
- DMSをいつ使うか
- ビジネスクリティカルなアプリケーションの移行
- DWHのRedshiftへの移行
- マイナーバージョンへのアップグレード
- Auroraへの統合
- NoSQL／SQL、NoSQL同士の環境の移行
- レプリケーション用途
移行手順
DB/DWHへの移行手順を整理し、項目毎にサービスを当てはめていくとマイグレーションの多くのフェーズでDMS/SCTを活用し、作業を効率化・自動化する事が可能。パーセンテージの半分をこの2つのツールで占める形となり、残りの半分は"人"が実際に手を動かすなどの部分となる。マイグレーションを始める前に「何がどうなっていて、何をすべきなのか」を把握しておく事はとても大事。以下表は上記写真の情報を表に起こしたものです。
| フェーズ | 内容 | 自動化 | 工数(%) |
|---|---|---|---|
| 1 | アセスメント | SCT | 2 |
| 2 | データベーススキーマへの変換 | SCT/DMS | 14 |
| 3 | アプリケーションの変換/調整 | SCT | 25 |
| 4 | スクリプトの変換 | SCT | 7 |
| 5 | サードパーティーアプリケーションの統合 | 3 | |
| 6 | データの移行 | DMS | 4 |
| 7 | システム全体の機能テスト | 29 | |
| 8 | パフォーマンスチューニング | SCT | 2 |
| 9 | 統合とデプロイ | 7 | |
| 10 | トレーニングと知識 | 2 | |
| 11 | 文化とバージョン管理 | 2 | |
| 12 | カットオーバー後の運用支援 | 3 |
そして以下が移行作業を進めて行く上でのステップ及びステップ毎のポイントまとめとなります。
ステップ0：担当者
以下の知識を備えた人員を揃えたい。
- 深いDBの知識(複数ならば尚可)
- 深いネットワークの知識
- AWSの知識
- ソフトウェアアーキテクチャの一般知識
ステップ1：マニュアルを読む
シンプルなところだが、とても重要。以下のAWS公式ドキュメントや情報に目を通しておくべき。DB/DWHの場合、フォーラムにはDBエンジニアが回答してくれる事もある。質問があればフォーラムに投げてみる事で、直接回答が得られるかも知れない。
- ご利用開始にあたって
- FAQ
- ベストプラクティス
- フォーラム
- ブログ
- 手順書やデモ
ステップ2：スケジュール計画
以下のポイントを踏まえたスケジューリング、計画作りが大事。
- 移行プロジェクトの場合、数週間〜数ヶ月を要する場合がある
- 何度か繰り返す可能性がある
- 予想より遅くなったり、計画が移行自体より長くなる可能性も
- 移行が完了すべき日程を定めるのは難しい？
ステップ3：データベースを理解する
対象となっているDBの、移行に際するポイントを予め押さえておく。
- DB容量
- スキーマ数、テーブル数
- サイズの大きなテーブルの状況
- トランザクション境界
- DMSがサポートしていないエンジン固有の機能利用有無
- ソースデータベースの利用用途、頻度：移行のタイミングを見極める(作業が出来そうな時間帯はいつか)のに役立つ。
- ソースデータベースのユーザー／ロール／権限
- 対象データベースのメンテナンスに関する懸念/注意事項など：PostgreSQLの場合、いつデータベースをVACUUMしたか？など
ステップ4：ネットワークを理解する
実は一番見落としやすいポイント。ファイアウォール、トンネリング、VPN等、AWS環境下におけるネットワーク関連の項目については入念に確認しておくこと。
ステップ5：要件を理解する
移行前後のポイントについても各種予め整理・把握をしておく。
- ダウンタイムを許容するか否か
- 移行後もソースDBをメンテナンスする必要があるか
- ターゲットDBのエンジン決定理由
- 高可用性要件
- 移行対象は「全てのデータ」なのか否か
- 全てのデータを同じ場所に置く必要があるか
- RDSのメリットや制約をそれぞれ理解しているか
- 関連アプリケーションへの影響
- 切り戻しプラン
ステップ6：ターゲットスキーマ
- DMSとSCTの関連機能について理解しておく。
- DMS：テーブルと主キーのみ作成
- SCT：名前の通り「スキーマ」の変換ツール。
- 同一エンジン間：ほぼ全てのスキーマオブジェクトをコピー
- 異種エンジン間：スキーマオブジェクトを変換
- オーケストレーション：現時点では非対応
- 同一エンジン間移行の場合、標準のネイティブツールを使うという手もある。
- スキーマ変更は移行が終わってから行うこと。(移行と併せて行うと)非常に手間が掛かる。
その他移行の際に気を付けておく事。
- CloudWatchのログを確認する事を怠らない様に。
- タスク監視
- テーブル統計
- いきなり大きなものから、では無く、まずは小さなDB・テーブルから始める事。
- 移行元DBについて、移行前にやっておくべき必要な設定が完了している事。
- 移行には時間が掛かる事を前以て考慮に入れておく。
- 稼働状況の監視
- ログ情報を監視
- エラーの有無
- 切り捨てられた／スキップされたデータが無いか
- データ型が想定通りに移行されているか
- 文字化けや破損がデータに発生していないか
移行時間に影響を与える要素には以下のようなものがある。
- 移行元DBのサイズ＆負荷
- 移行先DBのサイズ
- ネットワーク帯域
- レプリケーションインスタンスのサイズ
- スキーマ構造
- スキーマ内のラージオブジェクト(LOB)の有無
- 大きなトランザクションの実行有無
ユースケース
一口に「移行」と言いつつも、ケースに拠っては"この手法を使ったほうが良い"というものが合ったりします。
ネイティブなレプリケーションが向いているケース
- 移行先DBがネイティブなレプリケーション形式に対応
- 全てのデータを移行
- スキーマやデータの変換が必要無い
- 移行先DBが新規作成の場合
ダンプ＆リストアが向いているケース
- DBサイズがあまり大きくない
- 「ダンプ＋転送＋リストア」のダウンタイムが許容範囲内である
- 移行元DBの全てのデータを移行する場合
- スキーマやデータ型の変換が必要無い場合
ちなみにここでの「大きい」は"5TB"が１つの目安となっている。全データ移行が許容される時間内に終わらない可能性はありえるし、逆にデータ量が小さくても多くの時間が掛かるケースもある。
以下は「大きなデータセット」の移行例。一定データ量を超える場合はSnowballを活用するという方法も検討すべし。
まとめ
という訳で「AWS Solution Days 2017 ～AWS DB Day～」のデータベース移行トラック内セッション「AWS Database Migration Service & Schema Conversion Tool ベストプラクティス」に関するレポートをお届けしました。"ベストプラクティス"という観点ではAWSドキュメントでも以下の様にそれぞれ展開されているものがありますので、実施検討前に併せて読んでおくとより万全且つスムーズな移行作業が行えると思います。移行作業自体はそう頻繁に行うものでは無いですが、だからこそ調査・準備は万端に整えておきたいところですね。
