AWS DMS を使用して Oracle から Amazon Aurora に移行する継続的なデータベースレプリケーション

これは IPG のゲスト投稿です。同社の説明によれば、「IPG は日本に拠点を置いており、テレビ関連のデータを専門に取り扱っています。日本全国の放送局から送られてきたデータを使用し、使いやすく理解しやすいようにフォーマットし、メタタグで構造化し、スマートフォンなどのプラットフォームで簡単に利用できるようにしています」

この記事では、AWS DMS を使用して、Oracle から Amazon Aurora への移行中にテストしたさまざまな最適化および MySQL 互換性について説明し、各ソリューションの欠点と利点を示し、取り扱うユースケースに最適なソリューションについて説明します。

次の図は、衛星、放送局、コンテンツプロバイダーから送られてきたデータを IPG がどのように移転させているかを示しています。

最初に Oracle データベースを使用して、テレビ番組のデータとそのさまざまな関連情報を保存および管理しました。入力データの詳細は次のとおりです。

EPG データ – 約 250,000 の番組 (地上波、BS、CS100°、新しい 4K8K の衛星放送を含む 8 日先までのテレビ番組情報)
放送局 – 約 200 の放送局と約 1000 のチャンネル
コンテンツプロバイダー – 約 10 社

このデータは 30 の企業に送信され、それらの企業のサービスで使用されます。

システム操作には、40 個のバッチプログラム、10 個の操作 UI、40 個の API サービスを含むソフトウェアプログラムの複雑なネットワークを使用しました。

Oracle に関する懸念事項

このシステムは耐久性があり安定していますが、次の点に懸念がありました。

Oracle はコンポーネントを緊密にカップリングし、スケーリングと進化が困難であることに鑑み、データベースが経時的なスケーリングと更新にどのように対応するかという点。
Oracle データベースについて知識があるのは、当社のチームの一握りのエンジニアだけだという点。

移行を決定する

懸念事項を踏まえて、変更や予測できないビジネス要件に迅速に対応できるシステムに移行することにしました。当社は既存のデータを使用する消費者サービスおよび API サービスの開発を可能にする新しいシステム環境を模索しました。また、移行中は既存のシステムを完全に安定運用し続けられる必要がありました。そして巡り合ったのが AWS DMS です。AWS DMS は、既存のデータを継続的にレプリケートし、さまざまなデータベースシステム間で継続的に操作できます。

企業はよく、PostgreSQL は Oracle の機能と互換性があるため、Oracle から移行する際にターゲットデータベースとして PostgreSQL を選択しています。けれども、当社はすでに MySQL データベースを使用しており、社内に MySQL の専門知識が蓄えれれているため、MySQL をターゲットにしました。AWS SCT を使用して、MySQL が当社の Oracle データベースと互換性があることを確認しました。AWS SCT は、データが物理的に適合するスキーマを生成するツールですが、ターゲットデータベース用に最適化されたスキーマを生成するように特に設計されていません。 AWS SCT で移行する場合は、常に最適化する必要があります。AWS SCT の実行結果によると、データベースストレージオブジェクトを 100% 自動的に変換できることがわかりました。データベースコードオブジェクトのうち、ビューオブジェクトの 100% と関数オブジェクトの 67% を変換できます。

この結果に基づいて、ターゲットデータベースとして MySQL を選択し、Aurora と MySQL の互換性を利用することで、パフォーマンスとスケーラビリティを改善することにしました。

障害を発見する

AWS Japan が開催した無料のハンズオン AWS DMS ワークショップに参加しました。基本的な AWS DMS 操作を学び、シンプルで簡単な移行を実現するには、AWS DMS と AWS SCT の助けが本当に必要であることを確認しました。AWS Japan が AWS CloudFormation を使用して AWS DMS の機能について教えてくれたおかげで、重複するたびにゼロから作業することなくインフラストラクチャのテンプレートを作成できました。詳細については、「AWS Database Migration Service および AWS Schema Conversion Tool ハンズオンガイド」(日本語ガイド) を参照してください。

オフィスに戻って、ステージングシステムを作成しようとしましたが、次の障害が発生しました。

初期ロードの全ロード中、このプロセスではソースデータベース (Oracle) をオーバーロードしたため、好ましい結果は得られませんでした。この原因は、ソースデータベースの読み取りスループットが高く、ネットワーク帯域幅が上限値に達したためです。
10 時間後、次の要因により全ロードを完了できませんでした。
- 外部キーとインデックスがまだ設定されていたため、AWS SCT が自動的に生成したスキーマにより、冗長な全ロードが発生しました。
- テーブルマッピングを明示的に指定しなかったため、一時テーブルが自動的に作成されました。これにより、ターゲットテーブルでエラーが発生しました。
- ターゲットデータベースのインスタンスサイズが小さく、書き込みの処理速度に影響しました。
- 移行に必要なデータのサイズが大きかった。

ソリューションの実装

前述の問題が明らかになった後、移行プロセスの最適化に取り組みました。

その時は、既存の Oracle 環境を維持しながら、新しい MySQL 環境を並行して実行していました。したがって、インフラストラクチャコストは 2 倍でした。インフラストラクチャの設定を最小限に抑えた新しい環境では、運用コストを低く抑える必要があることに気付きました。また、既存の Oracle 環境を簡単にシャットダウンまたは設定できないことにも気付きました。障害が発生し、初期ロードから再実行する必要がある場合でも、Oracle 環境は最小限の影響で実行する必要がありました。最後に、初期ロード時間を短縮すると、災害復旧における目標復旧時間 (RTO) が短縮され、サービスレベルが向上することがわかりました。

これらのレッスンを念頭に置いて、次の調整を行いました。

ソース、レプリケーション、ターゲットの適切なインスタンスサイズを選択する
移行用のテーブルをリストアップする
ターゲットデータベース内の外部キーとインデックスを削減する (データを移動している間にインデックスの数を減らし、後でそれらを再作成しました)

全ロードに必要な時間を短縮するために、AWS で必要なインフラストラクチャ設定を、全ロード操作中に大きなインスタンスサイズから 4xlarge サイズに変更しました。差分を適用するための変更データキャプチャ (CDC) では、最小インスタンスサイズで設定することにより、実行コストを削減する必要がありました。全ロード操作時に Oracle 環境インスタンスの設定を変更できないという制限があります。これらの問題を解決し、効率的に運用するために、次の手順を完了しました。

ソースデータベース (Oracle) のスナップショットを作成し、スナップショットから全ロードのために Oracle インスタンスを復元します。その際以下が含まれます:
• スナップショット作成の開始時間を記録する
• 既存のビジネスシステムを復元された Oracle インスタンスに接続しない
• 全ロードのために、Oracle インスタンスの大きなインスタンスサイズを選択する
次の図は、スナップショットと復元のアーキテクチャを示しています。
ソースデータベースとして全ロードの Oracle インスタンスを使用して、全ロードタスクを実行します。レプリケーションおよびターゲットデータベースインスタンスのために大きなインスタンスサイズを選択します。
次の図は、全ロードタスクのアーキテクチャを示しています。
全ロードが完了したら、全ロードの Oracle インスタンスを削除し、レプリケーションおよびターゲットデータベースのインスタンスサイズを縮小します。
次の図は、アーキテクチャがどう変化したかを示しています。
既存の環境の Oracle インスタンスをソースデータベースとして使用して、CDC タスクを実行します。手順 1 で取得したスナップショット作成時間からシステム変更番号 (SCN) を計算します。次のサンプルコードを参照してください。
```
SELECT timestamp_to_scn(to_timestamp('16/04/2019 13:46:51','DD/MM/YYYY HH24:MI:SS')) as scn from dual;
SCN
------------
12345678
```
[Specify log sequence number for CDC start mode] を選択し、SCN を計算した値に設定します。
次の図は、CDC タスクのアーキテクチャを示しています。
次の図は、新しいソリューションアーキテクチャを示しています。

ソースデータベースには、データボリュームにして約 500 のテーブルと 15 億行 (240 GB) のデータがありました。サービスを利用するのに必要なテーブルを選択し、不要なテーブルを Oracle に残すことで、テーブルの数を約 160 テーブルと 3 億 5000 万行 (65 GB) に減らしました。移行タスクに設定されたマッピングルールを使用して、すべてのテーブルのルールを作成しました。各テーブルのルールアクションとして明示的に include (移行) または exclude (移行しない) を設定しました。

全ロード操作時にターゲットデータベーススキーマからすべての外部キー制約とインデックスを削除し、全ロードを実行しました。次に、外部キー制約とインデックスを元のテーブルに返しました。

実装結果

実装から肯定的な結果が得られました。まず、ソリューションでは、全ロード時にソースデータベースのスナップショットから復元されたインスタンスを使用し、(ソース、レプリケーション、ターゲットの) 各インスタンスサイズを増やしました。さらに、全ロード時間は約 6 時間短縮されました。全ロード時には、ソース、レプリケーション、ターゲットのインスタンスサイズとして 4xlarge を使用しました。CDC の実行時に、レプリケーションインスタンス (4xlarge から large) とターゲットデータベース (4xlarge から 2xlarge) のインスタンスサイズを縮小し、実行しました。

次のテーブルは、インスタンスのサイズと全ロード時間をまとめたものです。

インスタンスサイズ	全ロード時間
ソースデータベース: 大レプリケーションインスタンス: 大ターゲットデータベース: 大	7 時間 36 分
ソースデータベース: 2xlarge レプリケーションインスタンス: 2xlarge ターゲットデータベース: 2xlarge	2 時間 30 分
ソースデータベース: 4xlarge レプリケーションインスタンス: 4xlarge ターゲットデータベース: 4xlarge	1 時間 46 分

データ量を調整することにより、全ロード時間を約 5 時間短縮しました。移行時間を短縮しようと考えていました。特に CDC 操作に問題がある場合、全ロード操作が複数回発生する可能性があるためです。

次のテーブルは、この調整を行った後の全ロード時間をまとめたものです。

データ量調整	全ロード時間
不適用	12 時間
適用済み	7 時間

全ロード時間を約半分以下に短縮することはできませんでしたが、全ロード後に外部キー制約とインデックスを再割り当てする時間は、全ロード時間よりも長くかかりました。テーブルあたりの行数が少ない場合に便利かもしれませんが、このユースケースではそうではありません。そのため、外部キーの制約とインデックスを使用して全ロードを実行しました。

次のテーブルは、インデックスを使用した場合と使用しない場合の全ロード時間をまとめたものです。

実行方法	全ロード時間
インデックスありの全ロード	12 時間
インデックスなしの全ロード	5 時間
すべてのプロセスにインデックスが追加された全ロード (8 プロセス、並行)	13 時間

まとめ

この実験とテストのプロセス全体を通じて、最初のいくつかの実装で試みたマイクロ最適化にはわずかなメリットがあることが分かりました。けれどもそのいずれもインスタンスのスケーリングの最終的な実装ほど影響はありませんでした。この実装では、次の優れた結果を達成しました。

同じ量の全ロードを既存の環境に読み込む必要はありませんでした
インスタンスリソースを増やし、短時間で全ロードタスクを実行することにより、全ロード時の RTO を短縮しました
タスクに必要な最小インスタンスサイズを選択することにより、CDC 実行時の運用コストを最小化しました

次の図は、新しいシステムのアーキテクチャを示しています。

また、今後の改善も計画しています。まず、CDC の開始点があいまいであるために失われたり重複したりしたデータに対処する予定です。AWS DMS では、CDC 起動モードで SCN を使用して移行できます。AWS DMS は論理レプリケーションツールで、最終的にソースと一貫したターゲットを取得できます。間違った SCN を使用すると、データが失われる可能性があります。ただし、少数のトランザクションが再実行された場合でもターゲットが最終的に一貫性を保つように、以前の SCN に言及することをお勧めします。

また、全ロードを再度実行する際の手順を改善する予定です。全ロードを再度実行すると、ターゲットデータベースのデータは一度クリアされます。RTO を短縮できるため、データ損失時間 (全ロード時の期間) も短縮できます。けれども、可能であれば、さらに短縮したいと思います。たとえば、CDC が停止した時点のデータをターゲットデータベース内で保持しながら、サービスの動作を継続できます。また、別のクラスターで全ロードを完了した後にクラスターを切り替えることができるかどうかなども検討できます。

これは当社にとって大規模でワクワクするようなプロジェクトでした。そしてそこで培った経験を他の人と喜んで共有したいと思います。詳細については、IPG 開発者向け日記ウェブサイトにある 2019 年 10 月の AWS DMS セミナーの要約 (日本語) を参照してください。何より、AWS ソリューションを効率的に使用することで、ユーザーにサービスと価値を提供できます。

著者について

木村徹氏は、IPG, Inc. に勤務するテクニカルプログラムマネージャーです。彼は、テレビ番組情報を管理するプラットフォームシステム (マインド) のデプロイを担当し、機械学習プロジェクトチームを率いています。

Amazon Web Services ブログ