IPGの木村です。
今回は、AWS DMS（Database Migration Service）を使った話を紹介していきたいと思います。
実は、使い始めてわかったのですが、あまり DMS を使った事例や Tips がネットに乗っておらず、
1つの事例として参考になれば嬉しいなと思っています。
先日、AWSさんの本国のプロダクトマネージャが来社されて、AWSのDMSのBest Practiceに沿った素晴らしい事例、 と太鼓判押してもらいましたので、自信をもって紹介させてもらいたいと思います。
※ 追記 ※
この話は、本国のAWS Blogでも事例紹介して頂いています。
また、本内容はAWS Japan主催のセミナーでも講演させて頂いています。そのときの内容はこちらでスライドでも紹介させて頂いています。
Introduction
弊社は、日本全国の放送局様よりお預かりした様々な番組データを元に、番組情報をわかりやすく整え、コンテンツデータやメタ情報を加え、テレビやスマートフォーンなどのアプリに対応した番組表を作成しています。
これらを実現しているインフラシステムとして、Amazon RDS for Oracle を利用したデータベースシステムがあります。この Oracle データベース に、番組情報と、それに関わる様々な番組関連情報が入力されて管理しています。
- 入力データ:
- 番組情報： 約 25 万番組 *1
- 放送局： 約 200 局、約 1000 チャンネル
- コンテンツプロバイダー： 約 10 社
- 出力先:
- サービスプロバイダー： 約 30 社
これらのサービスを運営するために、可動しているソフトウェアは、以下の通りです。
- バッチプログラム: 約 40 programs
- オペレーションUI: 約 10 programs
- APIサービス: 約 40 programs
これらのシステムは、堅牢で安定的に稼働しています。
しかしながら、以下の課題を内在していました。
システムが密結合となっており変更に対する影響範囲が大きい
社内に Oracle に精通しているエンジニアが少ない
こういった課題を抱えつつも、様変わりするビジネス要件に即座に対応できる体制も必要でした。
検討
一番いい方法は、システム全体をリプレースするというプランですが、これほどのシステムをリプレースしようとすると、莫大な開発リソースと期間を要することが明白でした。
そのため、既存システムは、安定的に維持をしながら、新たな環境で既存データを利用したAPIサービスやコンシューマサービスの開発ができないかと模索しているとき AWS Database Migration Service（DMS）で、継続的にデータをレプリケーションして運用できるということを知りました。
これは、異なるデータベースシステムでデータレプリケーションができるということで、このソリューションの導入を検討しました。
ターゲットデータベース の選定
Oracle からの移行先として、機能互換性の観点から一般的には PostgreSQL が選ばれるケースが多いようです。一方で、社内でよく利用していた データベースエンジン は、MySQL でした。
そこで、移行対象であったシステムで利用している Oracle データベースを AWS Schema Conversion Tool（SCT） でチェックし、それぞれのエンジンの互換性を確認し、移行ターゲットを決めることにしました。
AWS SCT の結果、
- Database Storage Object(s)：100 %
- Database Code Object(s)
- View： 100 %
- Function： 67 %
を、AWS SCT により自動で変換できることがわかりました。
この結果から、移行先のターゲットデータベースのデータベースエンジンとして、 MySQL を選択し、パフォーマンスとスケーラビリティに優れている Amazon Aurora with MySQL Compatibility に決定しました。
検証
AWS Japan で無償で開催して頂いているハンズオンに参加し、基本的な DMS の操作方法を習得しました。
このハンズオンは、 AWS CloudFormation を利用していて、とても簡単に習得することが可能です。
次に、ステージングシステムで試してみたところ、以下の問題が顕在化しました。
(a) 初期ロードであるフルロード時にソースデータベース(Oracle) の負荷が上がることで業務影響が発生
(b) フルロードが、10時間を経過しても終わらない
導入
上記の問題が顕在化したことで、改めて以下整理の上、導入構成の検討を実施しました。
今回の我々のユースケースでは、既存の Oracle 環境を維持しながら、 新しい MySQL 環境も並行で運用するというものです。そのため、インフラに関しては、ダブルコストになることが明白です。新しい環境は、できる限り最低限のインフラ構成でランニングコストを抑えるという点を考えなければなりません。
既存の Oracle 環境は、システム停止や構成変更が容易には行えないという点も考慮すべき重要なファクターです。
障害などが発生して、初期ロードから再実行が必要になったようなケースでも、 Oracle 環境には最低限の影響で実行ができることが要求されます。
また、初期ロードの時間が短くなることは、障害復旧におけるRTO（Recovery Time Objective）を短くし、サービスレベルを向上させることに寄与します。
これら念頭におき、以下の調整を実施していきました。
(1) 移行テーブルの明示化
移行タスクに設定する Mapping rule で、すべてのテーブルに対してルールを作成し、各テーブルの "rule-action" として "include"（移行する） or "exclude"（移行しない） を明示的に設定しました。
(2) ターゲットデータベースでの外部キーとインデックスの調整
(3) ソース/レプリケーション/ターゲットのそれぞれのインスタンスサイズの調整
これらを解決し効率的に運用するために、以降のようなステップで構築をする形としました。
ex)
SELECT timestamp_to_scn(to_timestamp('16/04/2019 13:46:51','DD/MM/YYYY HH24:MI:SS')) as scn from dual;
SCN
------------
12345678
全体像
結果
以下に、それぞれの導入結果を記載します。
(1) 移行テーブルの明示化 による効果
| データ量調整 | 所要時間 |
|---|---|
| 無し | 12 時間 |
| 有り | 7 時間 |
(2) ターゲットデータベースでの外部キーとインデックスの調整 による効果
もしかすると、1テーブルあたりの行数が少ないケースでは有用かもしれませんが、我々のケースでは有用ではありませんでした。
そのため、今回は外部キー制約及びインデックスを付けたままフルロードを実施しました。
| 実行方法 | 所要時間 |
|---|---|
| インデックスを付けたままのフルロード | 12 時間 |
| 実行方法 | 所要時間 |
|---|---|
| インデックスをすべて外してフルロード | 5 時間 |
| インデックスをすべてに付与（8プロセス並列） | 13 時間 |
(3) ソース/レプリケーション/ターゲットのそれぞれのインスタンスサイズの調整 による効果
| インスタンスサイズ | 所要時間 |
|---|---|
| ソースデータベース: large レプリケーションインスタンス: large ターゲットデータベース: large | 7 h 36 m |
| ソースデータベース: 2xlarge レプリケーションインスタンス: 2xlarge ターゲットデータベース: 2xlarge | 2 h 30 m |
| ソースデータベース: 4xlarge レプリケーションインスタンス: 4xlarge ターゲットデータベース: 4xlarge | 1 h 46 m |
結論
これらにより以下の実現ができました。
・既存環境にフルロード時の負荷を与えない。
・フルロード時に、インスタンスのリソースを多く取り、フルロードタスクを短い時間で実行することで、RTOを短くする。
・CDC時には、最低限のインスタンスサイズに変更することで、ランニングコストを最小限に抑える。
今後の課題
(A) CDC の スタートポイントが曖昧
(B) 再フルロード時の対応
こういった問題も解決できないか、AWSさんとも相談しつつ進めております。
今後の課題解決の状況も紹介していきますので、引き続き、宜しくお願いします。
エンジニア募集中！
現在IPGでは、機械学習エンジニア、アプリエンジニア、Webエンジニアを募集しています。
こんなエンジニア募集中です。気軽にオフィスに遊びに来てください！ご連絡はこちらまで
- 生涯エンジニアを希望している人。
- 何事も「変化すること」を前提に、変化を受け入れ、柔軟に物事を進める事ができる人。
- 常に新しい技術分野にチャレンジし、良い物はチームや世間に広げたい人。
- ユーザーファーストで物事を思考している人。
- チームワークを大事にしている人。
- 効率化のために何でも自動化したくなる人。
