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