Oracle ワークロードを Azure に移行するためのキャパシティ プランニング
この記事では、Azure クラウド導入フレームワークのガイダンスを構築するために、Microsoft Azure 上の Oracle ワークロード用インフラストラクチャのキャパシティ プランニングに関する考慮事項を提供します。 この記事には、このプランニング プロセスにより支援する推奨事項とツールが含まれています。
Azure 上で Oracle データベース ワークロードを実行するときに、キャパシティ プランニングは効率的なパフォーマンスとコスト管理を実現するために不可欠です。 この記事では、リソースを正確に割り当て、パフォーマンスのニーズのバランスを取り、コストの最適化するためのガイドライン、方法、ツールについて概要を説明します。 具体的な容量の要件は、データベース ワークロードのパフォーマンス特性によって異なります。 これらの特性は、トランザクション、分析、または混合です。 Oracle データベース ワークロードの制約要因は、通常、処理能力、メモリ、スループットです。
キャパシティ プランニングは、Azure 上の Oracle アーキテクチャに適したインフラストラクチャを選択するのに役立ちます。 このプロセスを効果的に実装するには、データベースストレージ容量を理解する必要があります。
容量計画に関する考慮事項
Azure の サービスとしてのインフラストラクチャ (IaaS) 上の Oracle ワークロードのキャパシティ プランニングは、ワークロードの要件と使用できる Azure リソースを深く理解する必要があるプロセスです。
Note
次の考慮事項は、Azure 仮想マシン上で実行される Oracle データベースに関する考慮事項です。 Oracle Database@Azure の場合は、ローカルの Oracle 営業チームに連絡 してサイズ設定のガイダンスを受けます。
全体的なパフォーマンスに関する考慮事項
既存の環境では、Azure 上の Oracle データベース ワークロードの要件に対する正確なサイズ設定尺度として機能しない可能性があります。 Oracle Automatic Workload Repository (AWR) レポートを使って、移行する 1 つ以上のワークロードのパフォーマンス特性を理解する必要があります。 AWR レポートには、Oracle データベース ワークロードのパフォーマンス統計が含まれています。
使用できる AWR のパフォーマンス統計がない場合、アプリケーション サーバーのサイズ設定尺度として既存の環境を使用できます。 アプリケーション サーバーのパフォーマンス メトリックを収集して、アプリケーション サーバーや サービスとしてのプラットフォーム (PaaS) ソリューションのサイズ設定が適切であることを確認する必要があります。
Note
AWR を収集するには、データベース ワークロード用に Oracle Diagnostic Pack ライセンスを購入する必要があります。 AWR の代わりに、Statspack レポートを使用できます。 Statspack レポートは AWR のサブセットであり、Diagnostic Pack ライセンスは必要ありません。
データベース ワークロードの AWR レポートを収集します。
ワークロードでピーク時の負荷が発生したとき。 ピーク時の読み込み時間がわからない場合は、
busiest_awrスクリプト を使用して最も負荷の高い AWR を特定します。ピーク時の負荷を代表する期間。 たとえば、ピーク負荷が月末のプロセスであれば、AWR レポートは月末のプロセス中に生成します。 期間には、ピーク時の読み込み時間のみを含め、低負荷の延長期間を除外する必要があります。 AWR レポートに低負荷期間を含める場合、パフォーマンス統計は実際のワークロードパフォーマンス要件ではなく平均を表します。
バッチ プロセスなどのアクティビティ、またはデータベースに対する大きな負荷を構成するその他のアクティビティの場合。
ピーク時の負荷と同様のシナリオで AWR レポートを収集します。 適切な仮想マシン (VM) SKU とストレージ構成を決定するには、「Oracle AWR レポートに基づく Azure リソースのサイズ変更」を参照してください。 複数の Oracle データベース ワークロードを管理し、同じ VM で複数のワークロードを統合することを検討している場合は、[Oracle Migration Assistant Tool (OMAT)] を使用します。 OMAT は、AWR レポートに基づいてインフラストラクチャ評価を生成し、可能な VM とストレージの構成に関する提案を提供する、自動サイズ設定評価ツールです。
コンピューティングに関する考慮事項
データベース ワークロードの基本的なパフォーマンス要件が決まったら、VM のプランニングについて以下の推奨事項を検討してください:
該当する場合は、制約付きコアを使います。 制約付きコアにより、より大きな VM SKU のメモリとスループットの容量に、より小さな VM SKU の vCPU 容量が与えられます。 Oracle ライセンスはプロセッサ コアに基づいているため、制約付きコアは Oracle ライセンス コストの観点から推奨されます。 Azure 上の Oracle ライセンスのしくみの詳細については、「クラウド コンピューティング環境における Oracle ソフトウェアのライセンス付与」を参照してください。 制約付きコアの詳細については、「Azure VM サイズ」を参照してください。
Oracle ワークロードにはメモリ最適化 VM を使います。 メモリ最適化 VM は、汎用 VM よりも vCPU に対するメモリの比率が高くなります。 これらの VM は Oracle ワークロードに適しており、通常はメモリ負荷が高くなります。 メモリ最適化 VM の詳細については、「メモリ最適化 VM サイズ」を参照してください。
全体的なアーキテクチャを評価するときは、高可用性、非運用環境などのために必要なその他の VM を含めてください。
ストレージに関する考慮事項
Oracle データベース ワークロードのパフォーマンスと信頼性は、基となるストレージ インフラストラクチャの設計と構成によって大きく異なります。 ストレージ プランニングには、次のガイドラインを考慮してください:
マネージド ディスクを使用する場合は、Oracle ワークロード用の Azure Premium SSD、Azure Premium SSD v2、または Azure Ultra Disk Storage を使用してください。 Azure Standard SSD または Azure Standard HDD は、運用環境の Oracle ワークロードには推奨されません。 Premium v2 SSD と Ultra Disk のストレージ上限の詳細については、「Azure マネージド ディスク」を参照してください。
ワークロードの特性によっては、ディスクの待機時間が問題になることがあります。 ディスクの待機時間の詳細については、「Azure マネージド ディスクの種類」をご覧ください。
Premium SSD を使用する場合は、すべてのデータ ディスクの
ReadOnlyと OSDisk クラスReadWriteにホスト キャッシュを構成します。 4095 GB を超えるディスクでは、ホスト ディスク キャッシュはサポートされません。 P50 パラメーターまたは 4 TB (テラバイト)より大きいボリュームを作成するには、複数の Premium SSD ディスクを割り当てて RAID-0 ストライプ論理ボリュームを構築します。 Linux 論理ボリューム マネージャー バージョン 2 (LVM2) などのボリューム マネージャーを使用するか、複数の Premium SSD ディスクを割り当てて、目的の容量または必要なスループットを満たすために Oracle 自動記憶域管理 (ASM) ディスク グループを構築します。マネージド ディスクを使用する場合、VM に接続され、VM SKU により制約を受けるすべてのディスクの累積スループットによってディスク スループットが決まります。 詳細については、「仮想マシンとディスクのパフォーマンス制限」を参照してください。
書き込み負荷の高いワークロードでマネージド ディスクを使う場合は、やり直しログに Ultra Disk Storage を使うことを検討してください。
スループット要件が単一 VM の最大スループットを超える場合は、Azure NetApp Files などのネットワーク ストレージの使うことを検討してください。このような構成では、VM はディスク スループットではなくネットワーク スループット、または Egress の制約を受けるからです。
Oracle の一時ファイルを多用する場合は、一時ディスクがある VM SKU を選ぶことを検討し、一時ディスク上に一時ファイルを配置してください。 この構成により、データ ディスクの入出力 (I/O) の負荷が軽減されます。