この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは、崔です。
セッションDAT362-R：Dive deep into AWS SCT and AWS DMSに参加しましたので、そのレポートをお届けします。
セッション概要
In this session presented by AWS and Autodesk, learn how to convert and migrate your relational databases, non-relational databases, and data warehouses to the cloud. AWS Schema Conversion Tool (AWS SCT) and AWS Database Migration Service (AWS DMS) can help with homogeneous migrations as well as migrations from different database engines, such as Oracle or SQL Server, to Amazon Aurora. We demo the latest features added to AWS DMS and AWS SCT.
AWSとオートデスクが提供するこのセッションでは、リレーショナルデータベース、非リレーショナルデータベース、およびデータウェアハウスをクラウドに変換および移行する方法を学びます。 AWS Schema Conversion Tool（AWS SCT）およびAWS Database Migration Service（AWS DMS）は、同種の移行だけでなく、OracleやSQL Serverなどの異なるデータベースエンジンからAmazon Auroraへの移行にも役立ちます。 AWS DMSおよびAWS SCTに追加された最新の機能をデモします。
スピーカー
- Arun Thiagarajan - Senior Product Manager, Amazon Web Services
- Abhinav Singh - Database Engineer, Amazon Web Services
- Tulika Shrivastava - Software Architect, Autodesk
セッションメモ
Agenda
- AWS DMSとAWS SCTの紹介
- AWS DMSとAWS SCTの製品ハイライト
- 事例：SQL ServerからAurora MySQLへの移行
- Q&A
Introduction to AWS DMS and AWS SCT
AWS migration tooling
- AWS SCT
- 商用データベースとデータウェアハウスのスキーマをオープンソースエンジンのDBもしくは、Aurora/Redshiftに変換するツール
- 移行が容易か困難なのかというアセスメントレポートを出力することが可能
- AWS DMS
- 容易にかつ安全にデータベースやデータウェアハウスをAWSにレプリケートするサービス
データベース移行のプロセス
- Step1:ソースDBのスキーマを変換もしくはコピーする
- AWS SCTの利用もしくはDBのツール
- Step2:ソースDBからデータを移行する
計画、アセスメント、移行
Workload Qualification Framework(WQF)
- 移行の最も重要なフェーズ
- どのように計画、評価するか、実行可能性をどう見るか
- ワークロード認定フレームワーク
- インベントリレポートを提供、ソースDBに関する重要な情報
- 使用されているメモリ、使用されているディスク容量などの物理的特性
- WQFはOLTPワークロードを5つのカテゴリに分類する
AWS SCT
- 異種間DBの移行のアセスメントレポートの作成
- DB/DWHスキーマの作成
- アプリケーションコードの変換
AWS SCT 製品ハイライト
- 評価、結果
- スキーマとコードの変換
- 最適化
- 移行
AWS SCT data extractors
- DWHからRedshiftへの変換
- データ形式はRedshiftに最適化される
- ファイルはS3もしくはSnowballに移行してからRedshiftに移行される
Migrate
サポートしているソースとターゲット
- ソース
- RDB
- Oracle, SQL Server...
- SAP
- DB2
- SQL Azure
- Aurora
- NoSQL
- MongoDB, Casandra
- アナリティクス
- S3, Snowball
- DWH
- Netezza, Teradata, Vertica,
- RDB
- ターゲット
- Aurora, SAP
- DynamoDB, DocumentDB
- ElastiCache, Kinesis Data Streams, S3
- Redshift
データ移行プロセス
- レプリケーションインスタンスの開始
- ソースDBとターゲットDBへの接続
- 移行したいテーブル、スキーマ、データベースを選択
- DMSによるデータ同期
- 同期完了後、アプリケーションをターゲットDBに切替
DMSの製品ハイライト
- 安全、評価、検証
- Snowballの統合
- 監視、低コスト
- ストリームデータ
- 複数の選択肢
Use case
- Migrate
- ミッションクリティカルなアプリケーションの移行
- DWHのRedshiftへの移行
- メジャー／マイナーバージョンアップ
- Auroraへのシャーディング
- 古いデータのS3へのアーカイブ
- NoSQLとSQLの変換
- Replicate
- クラウド上での分析
- データレイクへの蓄積
- リードレプリカの作成
- ストリーミングプラットフォームへのレプリケート
Autodesk のDB移行事例
移行の理由
- インフラ
- 異なるレイヤーでのエラー
- バックアップマネジメント
- パッチ適用
- 新規ノードへのデプロイ
- スケーラビリティ
- プライマリーノードがボトルネックだった
- 最大8台までのリードレプリカだった
- コスト
- 40-50%のコストダウン
Migration Strategy
- スキーマ移行
- アプリケーション移行
- データ移行
- ロールバックプラン
SQL ServerからAurora MySQLへのスキーマ移行
- スキーマ変換
- 挑戦
- 文字セットと称号
- 日時データ
- プロシージャ、関数
- スキーマ評価ツール
- テーブル評価
- カラム評価
- インデックス、制約評価
アプリケーション移行
- 機能フラグ
- リード／ライト トラフィックパターンの制御
- データベースの動的スイッチをマネージ
- 継続的なデプロイをサポート
- ダウンタイムの削減
- Aurora MySQLのゼロダウンタイムを設計
- .net driverがAurora MySQLをサポートしていない
- フェイルオーバー時のゼロダウンタイムをカスタムサポート
データ移行
- DMSによるソースDBからAurora MySQLへの移行
- DMSによるAurora MySQLからSQL Server（ロールバック用DB）への移行
- 一度、Auroraへの移行を止めて、SQL Serverへフルロード
- 完了後、CDCによる移行の再開
- データ移行を止めてアプリケーションをターゲットDBに変更
Lessons learned
- 複数回のテスト実行
- 性能テスト
- 構成パラメータの調整
- 自動化
- アラートと監視
what's next
- さらなるコスト最適化
- Aurora MySQLのインスタンスサイズ最適化
- レプリカのより良い利用
- リードクエリはリードレプリカを使うように
- Auroraのオートスケール
- グローバルデータベース
- ゼロダウンタイムパッチ
- High Availability
- マルチマスター
まとめ
DB移行の事例の中で、移行後のAurora MySQLからSQL ServerへDMS移行を実施しているのが参考になりました。
ロールバック時にアプリケーションの向き先を移行元のSQL Serverに戻すのではなく、AuroraからCDCしているSQL Serverに戻すという方法を実施するということです。
また、今後の対応として、リードクエリをリードレプリカを使うようにし、ライターノードのサイズ最適化を目指すというものが入っていました。
これら2点は今後の案件にも反映していきたいです。