Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行するベストプラクティス: 移行プロセスとインフラストラクチャに関する考慮事項

Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行するベストプラクティス: 移行プロセスとインフラストラクチャに関する考慮事項:

AWS クラウドで Oracle から PostgreSQL に移行するプロセスは何段階もあって複雑になりがちです。評価ステージから切り替えステージまで、さまざまなテクノロジーとスキルが必要になります。このブログシリーズでは、ソースの Oracle データベースとターゲットの PostgreSQL サービス、そして AWS Database Migration (AWS DMS) サービスについて、その環境と構成の設定方法をお伝えしています。特に焦点を当てているのが、ソースおよびターゲットデータベースのインフラストラクチャと設定、そして開発からテスト、本稼働、ステージングデータベースまでの各環境の移行に使用するツールと構成です。まずは、Oracle から、PostgreSQL との互換性がある Amazon RDS for PostgreSQL または Amazon Aurora ベースのデータベースへのデータ移行から始めることにします。

環境はそれぞれ異なりますが、機能は共通です。このシリーズのブログ記事では、各コンポーネントについて、データベースを移行する際に考慮する概要情報をお伝えするにとどめています。アプリケーションのコンポーネントや各種のシナリオについて、込み入った複雑な点までは取り上げていません。利用状況に応じて大きく変わるからです。細かい点まで深く把握する必要がある場合は、AWS Database ブログの記事 Database Migration—What Do You Need to Know Before You Start? をお読みください。

このシリーズには 3 つのブログ記事があり、それぞれで移行の 3 段階を扱っています。

ステージ 1: 移行プロセスとインフラストラクチャに関する考慮事項。この記事では、ソースサーバーのインフラストラクチャ設定について説明しています。移行プロセスの概要レベルについても触れており、Oracle データベースとクライアントハードウェアおよびオペレーティングシステムに適宜アクセスする必要があります。
ステージ 2: Oracle および AWS DMS CDC 環境のソースデータベースに関する考慮事項。次の記事では、1 回限りの移行でも継続的な変更データキャプチャ (CDC) レプリケーションでも、DMS サービスを利用して Oracle のソースデータベース環境を設定する方法について説明しています。
ステージ 3: PostgreSQL 環境のターゲットデータベースに関する考慮事項。ブログシリーズのしめくくりとして、AWS DMS で使用する PostgreSQL ターゲットデータベース環境の設定について説明しています。

このブログシリーズでは、以下の点を取り上げます。

移行プロセスの各段階で使用する設定ツール。
ソース環境、移行ツール、ターゲット環境に適したインスタンスタイプとデータベースのバージョン。
Oracle、AWS DMS、PostgreSQL の環境の構築とテスト。

移行するデータベースとその方法について計画を決めておくと、適切なソリューションの開発に必要な環境を定義しやすくなります。このシリーズで扱うのは、Oracle から PostgreSQL への移行プロセスです。アプリケーションの依存関係など、データベース移行のマニュアルな観点については触れません。Oracle データベースの特定のオブジェクトと機能を Aurora PostgreSQL に手動で移行する手順については、Oracle Database 11g/12c to Amazon Aurora with PostgreSQL Compatibility Migration Playbook を参照してください。

移行プロセス

データベースの移行は、どんな企業でも重要な業務です。失敗すれば、その痛手は計り知れません。組織が新しいテクノロジーを推し進めようとする力は、道なかばで頓挫してしまいます。そうなれば、これまでの膨大な支出がほとんど、あるいはまったく価値を持たなくなります。移行プロセスには多くの変動要因があり、慎重にプロセスの合理化を図ることが必要です。したがって、Oracle から PostgreSQL へのデータ移行を計画するときも、考えられるさまざまな選択肢を考慮しなければなりません。ネットワーク、CPU、メモリ、オペレーティングシステム、システム自体などのほか、移行に用いるツールやプロセスも考慮します。たとえば、AWS Glue のような ETL ツールは使用するのか、ファイルとしてデータをエクスポートするのか、それとも DMS を使用して CDC でデータを PostgreSQL に抽出するのか、といったことです。

移行プロセスで重要なのが、Workload Qualification Framework (WQF) を使用した技術評価のフェーズです。WQF には、セルフサービスのツール、アンケート、設計レビューのガイダンスなどが含まれています。AWS ソリューションのアーキテクト、パートナー、コンサルタントは、これらを利用してワークロードを分類し、移行の規模、必要な人時、移行先の AWS を適切に決定することができます。WQF は、主に 2 種類のデータベースワークロード、OLTP と DW を 5 つのカテゴリーに分類して、データ移行時に必要な負荷を確定します。次の表を参照してください。

カテゴリー	ワークロードの種類	移行の難易度	必要な人時
1	ODBC/JDBC のワークロード	低	少
2	軽度の Oracle 機能のワークロード	低	中
3	Oracle 機能の重度のワークロード	高	多
4	Oracle 固有のアプリケーションフレームワーク	移行は困難	N/A
5	OCI のワークロード	高	多

詳細については、AWS Database Freedom program のウェブサイトを参照してください。

データベースの移行プロセスでは、ステージごとにかなりの計画が必要です。計画しておけば、環境間で互換性がないなど構成上のどんな問題にもあらかじめ効果的に対処できます。たとえば、ローカネットワークで 100 GB のデータを移動している程度であれば、かりに数時間の停電があったとしても、それほど深刻ではありません。では、データベースが 5 TB もあり、2 時間のメンテナンスウィンドウでオンプレミスのハードウェアからクラウド環境に移行する場合を考えてみてください。Oracle から PostgreSQL への移行は大変な作業になることが分かるでしょう。

以下に示すように、データベースの移行プロセスは大きく言って 4 つのステージに分かれています。

移行手順

ステージ 1: インフラストラクチャ

このステージでは、以下の操作を行います。

ソースデータベースとターゲットデータベースを AWS DMS レプリケーションインスタンス (RI) に接続するネットワークを構成します。レプリケーションインスタンスと同じ VPC で 2 つの AWS リソースを接続するだけなので、これは簡単です。オンプレミスのデータベースを VPN 経由で Amazon RDS DB インスタンスに接続するなど、もっと複雑な構成が必要になることもあります。ネットワーク速度は、一般的なインターネットサービスから、AWS Direct Connect を使用した高速度まで、さまざまです。
ターゲットと RI の容量計画を策定します。

今回のブログ記事では、このステージを取り上げています。

ステージ 2: Oracle 環境を設定し、AWS Schema Conversion Tool (AWS SCT) を使用してソースデータをキャプチャ

このステージでは、以下の操作を行います。

パフォーマンスを引き上げ、AWS ツールおよびサービスと統合できるよう適切に Oracle データベース環境を設定します。
既存の Oracle データベーススキーマおよびデータを PostgreSQL データベースに変換する AWS SCT を設定します。リレーショナル OLTP スキーマとデータウェアハウススキーマのどちらも変換できます。SCT は、セカンダリインデックス、シーケンス、デフォルト値、ストアドプロシージャ、トリガー、シノニム、ビューなど、データ移行に直接関係しないスキーマオブジェクトを移行します。データ定義言語 (DDL) のステートメントを生成し、変換後のモデルオブジェクトに基づいて新しい PostgreSQL データベースを作成します。この DDL ステートメントを実行すると、PostgreSQL データベースにオブジェクトが作成されます。
SCT で移行評価レポートを見直して、プロジェクトを始める前に非互換性の問題と技術上の課題を確認します。
サポート対象外のデータデータとオブジェクトを確認します。データ型によっては、ターゲットデータベースで等価のデータ型への変換が必要です。サポートされるデータ型の詳細については、Oracle Database 11g/12c To Amazon Aurora with PostgreSQL Migration Playbook を参照してください。

このステージについては、第 2 シリーズの記事 Source database considerations for the Oracle and AWS DMS CDC environment で扱っています。

ステージ 3: DMS を設定してデータを移行

このステージでは、AWS DMS を設定してデータを移行します。

AWS DMS は、ソースの Oracle からターゲットの PostgreSQL にデータを移行します。また、データ操作言語 (DML) と、ソースデータベースで発生するサポート対象の DDL 変更をキャプチャし、その変更をターゲットデータベースに適用します。このように、AWS DMS はターゲットデータベースとソースデータベースとの同期を保ちます。

このステージについては、第 2 シリーズの記事 Source database considerations for the Oracle and AWS DMS CDC environment で扱っています。

ステージ 4: PostgreSQL データベース環境の設定

このステージでは、移行のパフォーマンスおよび AWS ツールとの統合が最適になるように、PostgreSQL データベース環境を設定します。これで移行プロセスは完了です。このステージについては、最後のシリーズ記事 Target database considerations for the PostgreSQL environment で取り上げます。データベースの移行プロセスには、本稼働の切り替えで問題が発生した場合に備え、ロールバックのプロセスと手法も含まれるのが一般的です。このブログシリーズでは、ロールバックの方法については触れません。

データベースの移行プロセス

Oracle DB から RDS PostgreSQL または Aurora PostgreSQL へのデータベース移行では、あらゆるテーブル構造、データ、関連のインデックス、トリガー、ストアドプロシージャが完全に移行されます。移行後の RDS または Aurora PostgreSQL データベースは、データレプリケーションによって、切り替えまでソースとの同期が維持されます。

異種データベース間でデータを移行する方法はさまざまです。データベースベンダーから提供される専用のデータ移行ツールもあれば、AWS データベース移行ツールを、クロスプラットフォームのデータ移行の設計と実装を前提に開発された手順と組み合わせる方法もあります。

なかでも AWS からは Oracle から PostgreSQL へなど異種データベースを簡素に移行できるツールが 2 種類用意されています。それが AWS SCT と AWS DMS です。

AWS SCT では、Oracle のディクショナリとセカンダリオブジェクトを、サポートされるデータベースターゲットに最小限の作業で変換できます。手動での変更や再作成が必要なオブジェクトとコードを認識する移行評価レポートが作成されます。

このブログ記事では、AWS Database Migration Service (AWS DMS) で変更データキャプチャ (CDC) を使用して、ストレージインフラストラクチャが Oracle ASM の場合に Oracle ソースエンドポイントで作業する方法について説明します。

DMS および SCT サービスを使用した Oracle から PostgreSQL への移行は複数ステージから成るプロセスで、依存関係の要因をいくつか考慮しなければなりません。プロジェクトの計画、リソース、トレーニング、テストプロセスなど、技術的な側面と技術以外の面の両方を考慮する必要があります。

適切な移行方針を立てるために、DMS と SCT を使用する際には以下のような技術的な面も盛り込むようにしてください。

ソース、レプリケーションインスタンス、ターゲットのサーバーの容量計画
ソースオペレーティングシステム (たとえば Linux) とネットワークのチューニング
スキーマおよびデータの移行プロセス
ソース Oracle データベースのパラメータ。たとえば、次のパラメータ
- アーカイブログ
- 補助ログ
- ストレージ
- ターゲット PostgreSQL データベースのパラメータ

データベースサーバーの容量計画では、データプラットフォームのアーキテクチャ、パフォーマンスカウンター、外部の依存関係、DB のバージョンとエディション、移行パス、ハードウェア、仮想化、機能以外の要件、ライセンスなどを知っている必要があります。新しいデータプラットフォーム環境に必要な容量を見積もるうえで重要な点のひとつが、各パフォーマンスカウンターの傾向を理解することです。カウンターには、たとえば Oracle インスタンスの RAM と CPU の使用パターン、データベースの IOPS、ログおよびデータファイルのサイズなどがあります。最適な傾向を基準にして時系列を推定し、季節をふまえた比較もできなければなりません。この推定は、ターゲットデータベースにも Amazon EC2 インスタンスにも適用されます。

CPU 使用率などのパフォーマンスカウンターに関しては、オンプレミスから AWS クラウドへの移行によって、基盤となるハードウェアの変更が予定されている場合にどうなるかを把握する必要があります。たとえば、ソースとターゲットのハードウェアプラットフォームは、パフォーマンスが大きく異なるかもしれません。したがって、現在のソースサーバー環境と、想定しているターゲットサーバー環境との間で、CPU のパフォーマンス比などを計算できなければならないということです。その計算ができれば、インスタンスまたはデータベースレベルのパフォーマンスに関するカウンター時系列を、新しい基準に合わせて推定することもできます。

一方、CPU とメモリに関しては、異種環境間の移行で必要なストレージ要件も分かっていなければなりません。ストレージターゲットで最適になるように、ソースシステムで評価または査定すべきなのは、次のようなポイントです。

ソース Oracle データベースを監査します。各スキーマと、スキーマの全オブジェクトを評価して、使用されなくなったオブジェクトがないかどうか確認してください。ソース Oracle データベースで使用されていないオブジェクトは移行する必要がないので、廃止します。
ロード容量が許す場合は、ソースデータベースで各 LOB タイプの最大サイズをキロバイト数で求めます。後でこの情報が必要になります。

LOB (BLOB、CLOB、NCLOB)、LONG、LONG RAW、XMLTYPE の列は、Amazon S3、Amazon DynamoDB、その他の外部データ型に移行します。

外部 LOB データオブジェクトは、データベースのテーブルスペースではなく、オペレーティングシステムのファイルとして格納されます。したがって、Oracle データベースに格納されるのは LOB ロケータ (ポインタ) だけです。LOB、LONG、LONG RAW の実際の値については、データのすべてが外部に格納されるので、Oracle データベースのストレージ要件が小さくなり、クエリのパフォーマンスも向上します。

たとえば、CLOB (XML ファイル) または BLOB (バイナリデータオブジェクト) を Amazon S3 に格納し、URL 参照をデータベースの S3 オブジェクトに格納することができます。整合性と耐久性のサポートは、基盤となるハードウェアによって提供され、オペレーティングシステムが管理します。このようなアプローチで、ソース Oracle データベースが簡素化されて移行が容易になるわけです。ターゲット PostgreSQL データベースの側でも、容量の要件が小さくなります。

オペレーティングシステムとネットワーク

DB プラットフォームの移行を考えるとき、ユーザーはたいてい、ソース側の CPU 使用率、メモリサイズ、I/O パターンをチェックします。ところが、ネットワークのパフォーマンスの重要性は、特に AWS に移行するときには忘れられがちです。そこで、この記事ではネットワーク検証についてもう少し詳しく踏み込むことにします。もちろん、ネットワークエンジニアやシステムエンジニアにも相談することをお勧めします。

ネットワークにはオーバーヘッドがつきもので、処理には一定の遅延が発生するものです。パフォーマンスを最適化するには、ネットワークのスループットを高くする必要があります。また、ネットワークで送信されるメッセージの数も減らすよう努めましょう。ネットワークで発生する遅延は測定が難しいことも忘れないでください。可能であれば、検証プロセスの早い段階からネットワークエンジニアやシステムエンジニアに相談するとよいでしょう。ソースシステムやデータセンターでネットワークの問題が発生すると、パフォーマンス低下の原因になり、移行が遅くなることがあるからです。

ネットワークのパフォーマンスに対処するときは、ネットワークスニファで追跡を行い、パフォーマンスの低下を分析します。これを分析するには、データをネットワークアナライザー (Wireshark、または同等の商用ソフトウェア) に読み込んで、各種のパケットで手がかりを調べるという方法があります。

また、ソースで移行の準備が万端であることを確認するのが、以下のようなネットワーク監視ツールです。

ネットワーク帯域幅モニタを使うと、ネットワーク、クライアント、サーバーのいずれかで帯域幅のパフォーマンス上限超過による問題を特定できます。問題があれば、次のいずれに関係するかが分かります。
- スロットリング。リクエストは、リクエストのカテゴリーと、そのカテゴリーで顧客が実行したコールの数に基づいてスロットルされます。
- 帯域幅の使用パターン。物理的な上限を示します。
イーサネットの衝突、パケット欠落またはパケットエラーなどを調べます。
WAN リンクの安定性を調べます。WAN 最適化を行って、クリティカルなアプリケーションが応答しない、または WAN で信頼性が低下するなどの原因となる、レイテンシーやパケット損失、帯域幅といった問題に対処してください。
サービス品質 (QoS) または継続的なパケット最適化を確認します。
横断パスのファイアウォールが、特定のポートやプロトコルをブロックしていないかどうか確認します。

ソースデータベースサーバーには、Windows、SunOS、IBM AIX、HP UX、Linux など、メジャーなベンダーのどのオペレーティングシステムも使用できます。各 OS 使用できるコマンドを、ここですべて挙げるつもりはありません。ブログシリーズを通じて、オープンソースの代表である Linux システムから DB を移行することを前提にしています。

そのため、システムを効果的に管理するには最小限の Linux コマンドを知っている必要があります。そのうちで、重要なコマンドを以下に挙げておきます。できれば、使用する前に試してください。

ネットワークコマンド

接続を調べて異常を見つけ出し、トラブルシューティングを行う際には、netstat、traceroute、ipconfig、ポートスキャナといったユーティリティがたくさんあります。重要なコマンドは、以下のとおりです。

ifconfig コマンドは、システムで定義されているネットワークインターフェイスの詳細を表示します。
- 最も頻繁に使うオプションは -a (ifconfig –a) です。すべてのインターフェイスを表示し、パケットの欠落またはパケットエラー、MTU サイズなどを調べます。
- イーサネットのプライマリネットワークインターフェイスは通常、eth0 という名前です。特定のインターフェイス、たとえば eth0 について詳細を調べる場合は、# ifconfig eth0 とします。
/proc/net/dev、netstat、mii-tool はいずれも、ポートの速度に関するコマンドです。
netstat –s または netstat –su を使用して、udpInOverflows、パケットの receive errors、または fragments dropped を調べます。これらのメトリクスが常に高い場合には、問題があることを示しています。
NIC Version : ethtool –driver eth0 は、ポートとパケットの速度設定を調べます。

以下のコマンドでは、現在のネットワークドライバーと BIOS のバージョンに関する情報を取得できます。場合によっては、現在のバージョンを特定した後で検索するだけで、パフォーマンスに問題がある場合のアップグレードに関する提案が表示されることもあります。ネットワークアダプターの名前を検索する手動のコマンドは、次のとおりです (Linux では、コマンドの実行に権限が必要です)。

lspci -v | grep Ethernet -A 1 と入力します。

アダプターの名前を確認し、システムのアダプターとドライバーが正しいことを確かめます。たとえば、Intel PRO/1000 PT Dual Port Server Adapter の場合は、次のようになります。

MyServer:/home/MyUser # lspci -v | grep "Ethernet" -A 1 
02:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 
Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter 
-- 
02:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 
Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter

最高のパフォーマンスを得るには、サポート対象で最新のドライバーをインストールすることをお勧めします。以下のコマンドでドライバーのバージョンを調べ、必要があれば更新してください。
- ethtool -i ethx と入力します。ethx はイーサネットのポートです。
- ドライバーの名前とバージョンを読み取ります (最新、最適なバージョンであることを確認)。イーサネットポートが eth0 の場合なら、次のように入力します。
```
MyServer:/home/MyUser # ethtool -i eth0 
driver: e1000 
version: 7.6.5-NAPI 
firmware-version: 5.6-2 
bus-info: 0000:02:00.0
```

ソースサーバーでネットワークのスループットを改善するには、ホストのネットワークアダプターに jumbo フレームワークを設定し、MTU サイズを常時 9000 にします (再起動後にも有効です)。ただし、ネットワークパスの最初から最後まで jumbo パケットがサポートされる必要があります。そうしないと、パケットの断片化が発生します。

たとえば、ifconfig -a の後に ifconfig -mtu 9000 を使用して、設定の完了を表示できます。jumbo パケットが全ルートを横断したことを確認するには、次のように入力します。

[node01] $ traceroute -F node02-priv 9000 
traceroute to node02-priv (10.10.10.2), 30 hops max, 9000 byte packets 
1 node02-priv (10.10.10.2) 0.232 ms 0.176 ms 0.160 ms 
 
[node01] $ traceroute -F node02-priv 9001 
traceroute to node02-priv (10.10.10.2), 30 hops max, 9001 byte packets 
traceroute: sendto: Message too long 
1 traceroute: wrote node02-priv 9001 chars, ret=-1

また、以下のような操作も可能です。

iperf ツールを使用してネットワークのスループットを確認し、ネットワーク帯域幅の使用率が、確認されている最大スループットに近づいているかどうかを判断します。
ネットワークの最大スループットに対応するには、ネットワークパラメータ値を適切に設定します。帯域幅遅延席 (BDP) の値を探し、それに応じてネットワークバッファのサイズを設定してください。これは、リンク帯域幅とラウンドトリップ時間の積で求められます。たとえば、ネットワークが 1 Gb/秒、ラウンドトリップ時間が 0.1 秒であれば、BDP は (0.1 * 10^9)/8 です。ネットワークがこのような場合は、ファイル /etc/sysctl.conf でパラメータ値を次のように設定します。
```
net.core.rmem_max = 12500000 
net.core.wmem_max = 12500000 
net.ipv4.tcp_rmem = 4096 87380 12500000 
net.ipv4.tcp_wmem = 4096 65536 12500000   
```

また、次のパラメータの値を大きくします。

net.core.netdev_max_backlog = 30000 
net.ipv4.tcp_max_syn_backlog = 4096

帯域幅のレイテンシーと使用率が通常の場合は、クライアントからターゲットサーバーまでのネットワークルートを確認してください。ネットワークの経過時間を確認できれば、トランザクションに要する時間を把握できます。クライアント/サーバーの通信には、小さいパケットが大量に必要です。ネットワークでレイテンシーが大きくなると、リクエストを送信してからレスポンスを受信するまでの間隔が長くなり、トランザクションが遅くなります。横断パスが最適を下回っている場合もあります。たとえば、設定が誤っていると、トランザクションは不要な多くのパスをホップしていかなければなりません。あるいは、パスで繰り返しが発生している、ルート構成の問題が発生しているなどの要因も考えられます。パスの各デバイスについてアドレス情報を取得するには、クライアントからサーバーの間で traceroute または同等のコマンドを使用します。

システムパフォーマンス指標

システムパフォーマンス指標を得るときには、以下のようなコマンドが便利です。

ディスク I/O とメモリ使用率を確認するには、sar、vmstat、iostat を使用します。
CPU については、/proc/cpuinfo、mpstat、top の使用方法を確認してください。
メモリについては、/proc/meminfo、/proc/slabinfo、free の使用方法を確認してください。
カーネルのバージョンとリリースは、cat /proc/version で調べられます。
I/O カードのタイプは、lspci -vv を実行してバージョンとドライバーを確かめます。
すべてのハードウェアの PCI デバイスをリストアップするには、lspci –v を使用します。
カーネルメッセージ: 明らかな問題を確認するに場合は、/var/log/messages や /var/log/dmesg を実行します。

まとめ

今回のブログでは、ネットワークの問題を詳しく取り上げました。CPU、メモリ、I/O については調べますが、ネットワークのパフォーマンスは忘れられがちです。ネットワークのパフォーマンスは DB 移行の方針を左右する大きな要因ですが、本稼働システムの CPU、メモリ、I/O は十分にモニタされ、理解も進んでいます。

データベース移行に使用するインフラストラクチャの設定では、システムおよびネットワークの管理タスクを考慮すべきであるというのが、今回の結論です。次の段階では、ソース Oracle データベースの設定と構成を移行のために準備します。Source database considerations for the Oracle and AWS DMS CDC environment をご覧ください。

著者について

Mahesh Pakala は、2014 年から Amazon に勤務しています。Amazon 入社以前は、Ingres、Oracle Corporation、Dell Inc. など各社で経験を積みました。戦略重視の顧客に向けて、可用性とスケーラビリティの高いアプリケーション、異種クラウドアプリケーションの移行について設計をアドバイスし、システムパフォーマンスの支援を行っています。

このブログを検索

IT音痴アラフィフおやじのストック記事倉庫