[Aurora事例祭り]AWS Database Migration Service と Schema Conversion Tool の使いドコロ

[Aurora事例祭り]AWS Database Migration Service と Schema Conversion Tool の使いドコロ

1. 1. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. アマゾン ウェブ サービス ジャパン株式会社 データベース ソリューション アーキテクト 柴⽥⻯典 2017年3⽉7⽇ AWS Database Migration Service と Schema Conversion Tool の使いドコロ #AuroraMatsuri
2. 2. ⾃⼰紹介 柴⽥⻯典［シバタツ］ • データベース関連の 相談ごと何でも担当 • AWSへの移⾏を機に RDBMSをAuroraに 乗り換えたい • オンプレミスOracleを AWSにフォーク リフティングしたい • 好きなAWSのサービス: S3 @rewse
3. 3. このセッションの⽬的 その1 皆さんの今の気持ち “Aurora良さそうだけど、 既存がMySQLでもPostgreSQLでも ないから、移⾏が⼤変そう……” “AWSのマイグレーション関連サービスを 使えば、移⾏できそう！”
4. 4. このセッションの⽬的 その2 皆さんの今の気持ち “既存がMySQL or PostgreSQLだから レプリケーションするだけで 移⾏できるし……” “AWSのマイグレーション関連サービスを 使えば、あのDBとも連携できそう！”
5. 5. マイグレーション実施計画における⼀般的な課題 クラウド検討 マイグレーション実施計画 マイグレーション実施 IT部⾨責任者業務部⾨責任者 ü 移⾏のための業務停⽌はできるだ け短くしてほしい ü インターフェース（SQL含む）を あまり変えないでほしい ü システム停⽌時間が⻑く 取れない ü 移⾏にあまり費⽤を かけたくない クラウド化意思決定
6. 6. マイグレーションの⽅針と実現⽅法 ⽅針 • システム移⾏時の停⽌時間を最⼩限に抑え、 ビジネスへの影響を最⼩化し、新たなITサービスを迅速に提供 実現⽅法 • フレームワーク、パースペクティブ、プロセスの活⽤ • ツールの活⽤、経験ノウハウの蓄積と再利⽤ キーポイント • 移⾏のコスト、リスク、期間を低減 • 安⼼、安全な移⾏ • ⾃動化
7. 7. AWSが提供するマイグレーション関連サービス 計画 移行 運用 ディスカバリー 設計 変換 移行 運用 最適化 ドメイン フェーズ サービス マイグレーションプロセス ü AWS TCO Calculator ü AWS Application Discovery Service ü VM Import/Export ü AWS Server Migration Service ü AWS Database Migration Service ü AWS Storage Gateway ü AWS Snowball ü VMware on AWS ü AWS CloudWatch ü AWS Config ü AWS CloudFormation ü AWS CloudTrail ü AWS Service Catalog ü AWS Trusted Advisor ü AWS サポート マイグレーション コンピテンシー DevOps、Mobile、Security、 Big Data、Storage、 Microsoft、SAP、Oracle コンピテ ンシー
8. 8. AWS Database Migration Service とは 既存のデータベースを 最⼩限のダウンタイムで マイグレーションする サービス 同種はもちろん 異種プラットフォームの 移⾏にも対応 オンプレミスDB DB on EC2 RDS オンプレミスDB DB on EC2 RDS ※オンプレミス to オンプレミスは非対応 DMS
9. 9. AWS Database Migration Service の特徴 使⽤が簡単 MCで数回クリックするだけ 最⼩限のダウンタイム オンラインでの 継続的レプリケーション対応 豊富な 対応プラットフォーム Oracle, Microsoft SQL Server, SAP ASE, MySQL, MariaDB, PostgreSQL, Aurora, Redshift 簡単なセットアップ ソースDBへの変更はほぼ不要 ⾼い信頼性 マルチAZ可能なインスタンス 低コスト c4.largeインスタンスで 0.196USD/時間
10. 10. AWS Schema Conversion Tool とは ソースDBのスキーマ、 ビュー、ファンクション、 ストアドプロシージャの ⼤部分を⾃動的に ターゲットDB互換 フォーマットに変換できる デスクトップ アプリケーション
11. 11. AWS Schema Conversion Tool の特徴 ⼿動変換の補助 ⾃動変換できない個所とその理由を明⽰ 評価レポートの作成 何割のオブジェクトが⾃動変換可能か などのPDFレポートを数クリックで 作成でき、変換⼯数の事前⾒積もりを 補助 アプリケーションSQLに対応 アプリケーションソースコードを スキャンして変換 豊富な対応プラットフォーム Oracle, Microsoft SQL Server, Teradata, Netezza, Greenplum, MySQL, MariaDB, PostgreSQL, Aurora, Redshift
12. 12. 同種DB間で、ダウンタイムを最⼩限に移⾏ ソース: オンプレミス、EC2、 RDS上のOracle AWS Database Migration Service ターゲット: RDS上のOracle ソース: オンプレミス、EC2、 RDS上のMySQL AWS Database Migration Service ターゲット: Amazon Aurora
13. 13. 異なるDB間で、ダウンタイムを最⼩限に移⾏ ソース: オンプレミス、EC2、 RDS上のOracle AWS Schema Conversion Tool ターゲット: Amazon Aurora ソース: オンプレミス、EC2、 RDS上のOracle AWS Database Migration Service ターゲット: Amazon Aurora
14. 14. データベースの統合 ソース: オンプレミス、EC2、RDS上の 複数のMySQL AWS Database Migration Service ターゲット: Amazon Aurora
15. 15. 継続的なデータレプリケーション ソース: Amazon Aurora AWS Database Migration Service ターゲット: 異なるリージョンのAurora、 テスト用Aurora、 オンプレミスMySQL
16. 16. AWS Database Migration Service 詳細
17. 17. 設定の流れ 1. DMSインスタンスの作成 2. エンドポイントの設定 3. タスクの定義 インスタンスサイズ、VPC、 マルチAZ、パブリックアクセス （ストレージサイズ、サブネットグループ、 AZ、セキュリティグループ、KMSキー） ソースとターゲットそれぞれの RDBMSプラットフォーム、 ホスト名、ポート、SSL有効無効、 ユーザー名、パスワード 移⾏タイプ （ターゲットテーブルが存在していた場合、 LOB対応、最⼤LOBサイズ、ログの有効化） 実⾏
18. 18. エンドポイントとのセキュリティ corporate data center Availability Zone security group DMSのパブリックIP → オンプレミスDBのポート へのインバウンドのみ許可 ソースDB FW DMS ターゲットDB DX / VPN / SSLの利⽤ DMSのプライベートIP → ターゲットDBのポートへの インバウンドのみ許可
19. 19. 移⾏タイプ • Migrate existing data (FullLoad) • 現時点でソースDBに⼊っているすべてのデータを ターゲットDBに移⾏する • Replicate ongoing changes only (Change Data Capture / CDC) • ソースDBに対する変更データをキャプチャし、 ターゲットに適⽤する • アプリケーションは稼働したまま移⾏可能 • Migrate existing data and replicate ongoing change
20. 20. FullLoadの仕組み ターゲットがRedshift以外 1. DMSインスタンスがソースDBから 8テーブル並列に、各テーブルから1万⾏ずつSELECT 2. 必要に応じてDMSインスタンスがデータを変換し、 ターゲットDBにINSERT • メモリーだけで処理しきれない場合は、DMSインスタンス のEBSがスワップ領域として使われる • ⾏⻑が⻑く、⾏⻑×1万⾏×8テーブルがDMSインスタンスの メモリーサイズを超える場合は読み取り⾏数単位を⼩さく
21. 21. RedshiftへのFullLoadの仕組み 1. DMSインスタンスがソースDBから 8テーブル並列に、各テーブルから1万⾏ずつSELECT 2. DMSインスタンスが必要に応じてデータを変換し、 Amazon S3 の専⽤バケットにCSVとして出⼒ 3. RedshiftがS3からCOPY（ロード） • Redshift中はCOPY時にテーブル単位で排他ロックを 取る点に注意
22. 22. CDCの仕組み 1. DMSインスタンスがソースDBのトランザクションログ （バイナリログ、WAL、REDOログ）を 5秒間隔でキャプチャ 2. DMSインスタンスがSQLに変換し、 トランザクションCOMMIT順にターゲットDBに実⾏ 3. ターゲットDBに接続できない, 遅い場合 or FullLoad が完了していない場合は、DMSインスタンス内で キューイング
23. 23. 移⾏時のソースDBの停⽌⽅法 1. ソースDBの停⽌準備ができたタイミングで ソースDBにマーカーのトランザクションをINSERT INSERT INTO options VALUES ('the_end', 'true'); COMMIT; 2. ターゲットDBでマーカーの到着を確認 SELECT value FROM options WHERE key = 'the_end'; 3. 確認できれば、マーカー以前のトランザクションは すべてターゲットDBに適⽤されていることが 保証される
24. 24. 対応データベース詳細 プラットフォーム ソース ターゲット Oracle Database 10g R2, 11g, 12c 10g, 11g, 12c Microsoft SQL Server 2005, 2008, 2012, 2014 2005, 2008, 2012, 2014 SAP ASE 15.7以降 15.7以降 MySQL / MariaDB / Aurora 5.5以降 5.5以降 PostgreSQL 9.4以降 9.3以降 Redshift - すべて
25. 25. 東京リージョンでの料⾦ インスタンス + ストレージ + データ転送 t2.micro: 0.028USD/時 から c4.4large: 1.564USD/時 までの8種類 マルチAZの場合は2倍 0.138USD/GB/⽉ マルチAZの場合は2倍 受信: 無料 同⼀AZ内への送信: 無料 別AZへの送信: 0.010USD/GB 別リージョンへの送信: 0.090USD/GB インターネットへの送信: 0.14USD/GB以下
26. 26. 各RDBMSプラットフォームによる制限 AWS Database Migration Service ユーザーガイドをご確認ください
27. 27. AWS Schema Conversion Tool 詳細
28. 28. 設定の流れ 1. デスクトップ環境に インストール 2. ソースDBの設定 3. スキーマの選択 4. 評価レポートの確認 5. ターゲットDBの設定 Window, Mac, Fedora, Ubuntu + JRE 8u45以降 プロジェクト名、OLTP or DW、 RDBMSプラットフォーム、ホスト名、 ポート、ユーザー名、パスワード、 SSL有効無効、JDBCドライバーのパス など RDBMSプラットフォーム、ホスト名、 ポート、ユーザー名、パスワード、 SSL有効無効、JDBCドライバーのパス など
29. 29. メインビュー
30. 30. 評価レポートビュー (1/2)
31. 31. 評価レポートビュー (2/2)
32. 32. 評価レポートビューの Action Items タブ
33. 33. データ移⾏ビュー DMSタスクの作成と制御が可能
34. 34. マッピングルールの作成 • SCTのデフォルトマッピングルールを変更可能 • データタイプの変更 INTEGER ← NUMBER(10,0) → NUMERIC(10,0) • オブジェクトを別スキーマに移動 • オブジェクトの名称変更 • プレフィックスの追加、削除、置換 • サフィックスの追加、削除、置換 • データベース、スキーマ、テーブル、列単位で設定
35. 35. ターゲットがRedshiftの場合 分散キーと分散スタイル & ソートキーの決定を補助 • 最適化戦略の選択 • メタデータ（ソースDB側の索引など）のみを使⽤する • 統計情報のみを使⽤する • 統計情報はSCTから取得する • メタデータと統計情報を使⽤する • 各情報を考慮する重みの設定が可能 • 複数の提案と各提案の信頼度について提⽰ 現⾏のRedshiftをスナップショット経由でコピーし、ソースとターゲット共に Redshiftにすることで、この機能だけ利⽤することも可能
36. 36. アプリケーションSQLの変換 • アプリケーションソースコードをスキャンし、 SELECTやDMLなどのSQLを抽出して変換 • Java, C++, C# など • スキーマ同様に評価レポートを作成可能 • 変換されたSQLに⼿動で微調整を加えたあとに、 ソースコードに適⽤することも可能
37. 37. OracleからPostgreSQLへの例
38. 38. 拡張パック ソースDBにあってターゲットDBにない機能を ターゲットDBで実現するためにインストール • RDBMS on EC2 対象 • Email Sending Service • Job Emulation Service • Functions Emulation • Redshift対象 • Functions Emulation
39. 39. データ移⾏エージェント • ソースDBのデータをテキスト形式でアンロードする エージェント • アンロードしたファイルをSnowbollなどでAWSへ。 DMSでは時間が掛かりすぎる場合の代替案 • Fedora or Ubuntu にデーモンとして常駐。 SCTを終了しても動作続⾏ • 現在対応しているソースDB: Oracle 11g以降, Teradata 15以降
40. 40. DMSとSCTと組み合わせた移⾏の⼿順 1. SCTでテーブル定義とPK制約を移⾏ 2. DMSでFullLoadとCDC開始 3. FullLoad完了後にFK制約とインデックスを定義 4. CDCLatencyが⼩さくなったタイミングで アプリからの書き込み停⽌（ダウンタイム開始） 5. マーカーをソースDBにINSERT 6. マーカーのターゲットDB到着を確認 7. アプリがターゲットDBに接続（ダウンタイム終了）
41. 41. まとめ: マイグレーションにおける課題の解決 業務部⾨責任者 • 移⾏のための業務停⽌は できるだけ短くしてほしい ▶ DMS • インターフェースを あまり変えないでほしい ▶ SCT IT部⾨責任者 • システム時間が⻑く 取れない ▶DMS • 移⾏にあまり費⽤を 掛けたくない ▶従量制の課⾦体系