Oracle Exadata Database と Amazon RDS for Oracle 性能比較

本記事は、「Comparing Oracle Exadata Database Performance with Amazon RDS for Oracle」を翻訳したものです。著者は、以下３名です。

By Indranil Banerjee, Transformation Lead – TCS
By Sanjay Gupta, Sr. Partner Solutions Architect – AWS
By Debashish Pradhan, AWS Architect – TCS

Tata Consultancy Services (TCS)

多くの組織は、新しいテクノロジーをお客様に迅速に展開するための俊敏性、弾力性、スケーラビリティ機能をますます求めています。アマゾンウェブサービス（AWS）へのデータベース移行は、デジタル化にとって優先事項の 1 つであり、多くの場合、Oracle Exadata から AWS への移行が含まれます。以下の通り、デジタル化の課題と制限があります。

• 将来のキャパシティを予測し、利用しない場合でも投資する CapEx モデル （訳注：設備投資、資産計上)
• 年間のライセンス監査にかかる諸経費
• 複数年にわたるベンダーロックイン
• ピーク時にあわせたIT機器の購入

お客様は、Oracle Exadata から AWS への移行がデータベースのパフォーマンスに影響するのではないかと心配することがよくあります。それゆえ、ミッションクリティカルなアプリケーション向けに、オンプレミスの Oracle Exadata データベースを AWS へ移行して稼働させている事例に関心があると思います。

この記事では、タタコンサルティングサービス（ 以降、TCS ）が、オンプレミスの Oracle Exadata データベースと Amazon RDS for Oracle のパフォーマンスを比較して、英国を拠点とする公益事業者のデジタル化への取り組みをどのようにサポートしたのかを紹介します。

TCS は AWS Premier Tier Services Partner であり、マイグレーションコンピテンシーを持つマネージドクラウドサービスプロバイダー ( MSP ) です。

公益事業のお客様ユースケース

英国に拠点を置くある公益事業のお客様は、旧バージョンの Oracle Utilities で事業運営しており、将来のビジネス拡大とパフォーマンス向上を目指すためのアップグレードを必要としていました。アップグレードには Oracle Utilities Customer to Meter（ C2M ）への移行が必要で、アプリケーションのデータベース処理は、Oracle Exadata データベース上で実行されます。

AWS は、お客様にとって好ましいクラウドプラットフォームでしたが、Oracle Exadata から Amazon RDS for RDS への移行は、パフォーマンスの低下が懸念されるため困難であることが判明しました。このようなシナリオでは、TCS は意思決定を迅速に行うために、期限付きの概念実証（ PoC ）を提案します。

PoC の目的は、現在のワークロードが Amazon RDS for RDS でサポートできることを証明し、Oracle Exadata から Amazon RDS for Oracle に移行しても同じレベルのデータベースパフォーマンスを達成できることをお客様に確信いただくことでした。
PoC の主な原則は以下のとおりです。

• パフォーマンス検証の評価基準を定義するには、本番環境のワークロードを注意深く分析する必要があります。
• ターゲット環境のベースラインを決定するには、適切なサイジング分析を行う必要があります。
• ワークロードシミュレーションには高い精度が必要です。
• 性能要件達成基準は明確に定義され、測定可能である必要があります。
• 検証結果は、本番環境と同じ設定で、比較しなければなりません。

このシナリオでは、Oracle Exadata データベースとターゲット Amazon RDS for Oracle の間でデータベースのパフォーマンスのみを比較し、アプリケーションレイヤーでの検証は実施しませんでした。

検証の成功基準

この PoC では、以下のパフォーマンスパラメータを使用して Amazon RDS for Oracle とオンプレミスの Oracle Exadata のパフォーマンスを比較しました。

検証のアプローチ

検証評価基準は、市販のツールから生成される合成的なワークロードではなく、ピーク時に正確な本番環境のワークロードを取得し、検証環境で再現することでした。

TCS は、Oracle が提供する　Real Application Testing（ 以降、RAT ）ツールをパフォーマンスのベンチマークに利用しました。RAT では、技術的な指標 ( ディスクパフォーマンス、CPU 速度 ) や重要なビジネスプロセス (特定の期間内に完了する必要がある給与計算や請求処理) について、より詳細なレベルのテスト、分析、検証を行うことができます。

RAT では、特定のワークロードのパフォーマンス、容量、速度、またはその他の基準についてストレステストが行われます。特定のプロセスをオンプレミスの運用環境で記録し、Amazon RDS for Oracle で再現して、特定の技術要件やユーザーエクスペリエンス要件を満たしていることを確認しました。

図 1 — PoC に関連する検証手順概要

パフォーマンステストに関する考慮事項

ソースの Exadata アプライアンスはクォーターラックで、データベースサーバ用に 48 個のCPUコア（ 96 個の vCPU に相当）を搭載し、複数のデータベースをホストするように構成されていました。テスト対象のワークロードは、リソースの 33% を消費していました。そのため、この実証実験の環境として、Amazon RDS インスタンスタイプ db.r5.12xlarge ( 24 CPU コア、384 GB メモリ ) をテスト対象としました。

オンプレミスで実行される検証手順

datapump ユーティリティを使用して、Oracle データベースをエクスポートし、Amazon Simple Storage Service ( Amazon S3 ) バケットにアップロードしました。バックアップ完了後、RAT を使用して、inclusion/exclusion フィルターを使用してユーザー、プログラム、およびセッションのワークロードを記録しました。

AWS で実行される検証手順

Amazon RDS for Oracle インスタンス db.r5.12xlarge が作成します。次に、datapump のデータベースダンプファイルと RAT で再現可能なファイルを Amazon RDS データベースディレクトリにアップロードします。そして、データベースダンプを Amazon RDS for Oracle にインポートし、RDS インスタンスのスナップショットを作成します。2 – 5 回目の繰り返しテストでは、このスナップショットからリストアして検証を行いました。

定義済みの SQL スクリプトを使用して RDS インスタンスをウォームアップし、RAT データベースクライアントが RDS 上の RAT 再現可能なファイルを再生しました。Amazon CloudWatch、Automatic Workload Repository ( AWR )、Active Session History ( ASH )、および　Automatic Database Diagnostic Monitor ( ADDM ) ツールを使用して、記録された出力を分析しました。次の繰り返しテストでは、Amazon RDS スナップショットを復元し、パラメータを微調整してデータベースのリプレイランタイムを微調整しました。

パフォーマンステストのサイクル

テスト中、RDS Oracle 19c のインスタンスタイプは db.r5.12xlarge でした。Exadata 上のオンプレミス Oracle データベースと Amazon RDS の Oracle データベースをベンチマークすることが目的であったため、すべての繰り返しテストにおいてアプリケーションのチューニングは、意図的に実施しませんでした。

今回のPoCでは、Oracle 19c で 4 週間以内に 5 回のテストを繰り返しました。

構成とチューニング

RAT Reply は次の 3 つの条件で実行可能です。

1. 同期モード (SCN) では、取得したワークロード内のCOMMITの順序がリプレイ時に確認され、すべてのリプレイ・アクションがすべての依存COMMITアクションの完了後にのみ実行されます。この同期方法では、ほとんどのワークロードで大幅な遅延が生じる可能性があります。この場合は、synchronizationパラメータとしてTIMEを使用することをお薦めします。 同期モード (TIME) では、リプレイでは取得と同じ実時間が使用されます。すべてのデータベース・セッション・ログイン時間は、取得どおり正確にリプレイされます。同様に、データベース・セッション内のトランザクション間のすべてのタイミングは、取得どおり維持およびリプレイされます。この同期方法により、ほとんどのワークロードで適切なリプレイが実行されます。
2. 思考時間:データベース呼び出し間の思考時間を制御します。100% の値はデータベース呼び出し間の正確な思考時間を示し、データベース呼び出しのリクエスト率が高い場合は 100% 未満にすることをお勧めします。最後の繰り返しテストを除く繰り返しテスト #1 – 4 の思考時間を 100% にしました。繰り返しテスト #5 では、思考時間を短縮したシナリオをシミュレートすることで、実行時間が大幅に短縮することができました。
3. リプレイクライアントとインスタンスサイズ:リプレイドライバーは、処理されたワークロードを消費してリプレイシステムにリクエストを送信する特別なクライアントプログラムです。記録されたシステムのタイミング、同時実行性、依存関係が保持されます。TCS プロジェクトチームは、インスタンスサイズが r4.xlarge と r4.2xlarge の 1 ～ 4 のリプレイクライアントを試しました。同時実行数の多いワークロードでは、複数のクライアントを並行して使用してワークロードを処理すると便利です。

ワークロードには、複雑な依存関係を持つバッチが多数含まれていました。TCS プロジェクトチームは、より質の高い結果を得るために、同期モード (SCN) に基づく結果をより重視することにしました。より独立したトランザクションをシミュレートするお客様は、同期モード (TIME) を使用します。

以下は、いくつかのパラメーターとその値です。これらは繰り返しテストの合間に微調整され、望ましい結果が得られました。

• SGA と PGA を増やすことで SQL の効率が向上しましたが、最もパフォーマンスの悪い SQL に対処するインデックスを作成することでさらに改善されました。
• 同期モード (TIME) にすると、リプレイの実行時間が大幅に改善されましたが、リプレイのばらつきが増えたため、このパラメーターは次の繰り返しテストで元に戻されました。
• リプレイクライアント数を 1 から 4 に増やすと、リプレイの実行時間が改善されました。
• 思考時間の変更により、リプレイの実行時間が 4 時間 55 分に 50% 向上しました。

繰り返しテストの結果

5 回の繰り返しを行い、検証の成功基準セクションで事前に定義したパラメータに基づいて結果を測定しました。

結論

Exadata ベースの Oracle データベースを AWS に移行すると、組織は俊敏性、弾力性、コスト削減の面で大きなメリットを得ることができます。

組織が Oracle Exadata でミッションクリティカルなデータベースを運用するにつれて、これらのデータベースが AWS 上で同様のパフォーマンスを発揮する証拠を求める企業が増えています。この記事を参考にして、簡単な PoC を通じて Amazon RDS for Oracle のパフォーマンスを証明し、全社的な移行への道を開くことができます。

TCS には、AWS サービスのトレーニングと認定を受けたアソシエイトとともに、ミッションクリティカルなデータベースを Exadata から AWS に移行した実績があります。Oracle Exadata から AWS へのデータベースの移行の詳細および移行については、TCS チームにお問い合わせください。

.

.

TCS – AWS Partner Spotlight

TCS は AWS Premier Tier Services Partner であり、MSP でもあります。 ITサービス、コンサルティング、ビジネスソリューションを提供する TCS は、過去50年間、世界の多くの大企業と提携して変革を進めてきました。

Contact TCS | Partner Overview

本記事は、ソリューションアーキテクトの青山智が翻訳しました。原文は、「Comparing Oracle Exadata Database Performance with Amazon RDS for Oracle」を参照ください。