2017/04/13開催「はじめよう、AWSでデータベース in 福岡」の講演資料です。

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

3. このセッションの⽬的 その1
皆さんの今の気持ち
“Aurora良さそうだけど、
既存がMySQLでもPostgreSQLでも
ないから、移⾏が⼤変そう……”
“AWSのマイグレーション関連サービスを
使えば、移⾏できそう！”

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
コンピテ
ンシー

8. データベースの移⾏の前に確認すべきこと
移⾏データサイズ
許容可能なダウンタイム
AWSとのネットワーク速度
通信経路暗号化の必要性
• SCP、VPN、専⽤線
• ZIPファイルの暗号化など
サイズと時間。
サイズが⼩さく、時間が⻑いほうが
移⾏⽅法の選択肢が多くなる
移⾏元-AWS間通信中の
暗号化⽅法

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

18. データベースの統合
ソース:
オンプレミス、EC2、RDS上の
複数のMySQL
AWS Database
Migration Service
ターゲット:
Amazon Aurora

19. 継続的なデータレプリケーション
ソース:
Amazon Aurora
AWS Database
Migration Service
ターゲット:
異なるリージョンのAurora、
テスト用Aurora、
オンプレミスMySQL

20. AWS Database
Migration Service 詳細

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 タブ

37. データ移⾏ビュー DMSタスクの作成と制御が可能

38. マッピングルールの作成
• SCTのデフォルトマッピングルールを変更可能
• データタイプの変更
INTEGER ← NUMBER(10,0) → NUMERIC(10,0)
• オブジェクトを別スキーマに移動
• オブジェクトの名称変更
• プレフィックスの追加、削除、置換
• サフィックスの追加、削除、置換
• データベース、スキーマ、テーブル、列単位で設定

39. ターゲットがRedshiftの場合
分散キーと分散スタイル & ソートキーの決定を補助
• 最適化戦略の選択
• メタデータ（ソースDB側の索引など）のみを使⽤する
• 統計情報のみを使⽤する
• 統計情報はSCTから取得する
• メタデータと統計情報を使⽤する
• 各情報を考慮する重みの設定が可能
• 複数の提案と各提案の信頼度について提⽰
現⾏のRedshiftをスナップショット経由でコピーし、ソースとターゲット共に
Redshiftにすることで、この機能だけ利⽤することも可能

40. アプリケーションSQLの変換
• アプリケーションソースコードをスキャンし、
SELECTやDMLなどのSQLを抽出して変換
• Java, C++, C# など
• スキーマ同様に評価レポートを作成可能
• 変換されたSQLに⼿動で微調整を加えたあとに、
ソースコードに適⽤することも可能

41. OracleからPostgreSQLへの例

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
• 移⾏にあまり費⽤を
掛けたくない
▶従量制の課⾦体系