翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ターゲットプラットフォームのリソース要件

ターゲットデータベース環境のサイズは、設定ではなくソースの Exadata 使用率 AWS に基づいて設定することをお勧めします。多くのお客様は、今後 3～5 年間の予想される成長に対応するために、追加の容量を持つ Exadata システムを購入します。通常、Exadata ワークロードを に移行すると AWS、ソース Exadata システムの設定と比較してデプロイされるリソースが少なくなるため、元の設定を使用して AWS リソースを予測することは誤解を招くことになります。

ターゲットインスタンスに必要なリソースを見積もるには、AWR、データベースビュー、OEM、CellCLI など、前のセクションで説明したツールを使用できます。では AWS、ソース Exadata プラットフォームと比較して、リソースをより簡単にスケールアップまたはスケールダウンできます。以下のセクションでは、ターゲットプラットフォームの CPU、メモリ、IOPS などのリソースを推定するためのベストプラクティスについて説明します。さらに、Exadata 移行で顧客を支援した豊富な経験を持つ AWS アカウントチームやデータベーススペシャリストは、ターゲット環境のサイズ設定に役立ちます。AWS には、AWS アカウントチームが必要なリソースを見積もり、AWS 上のターゲット環境を適切にサイズ設定するために使用できる内部ツールがあります。

CPU とメモリの要件

Exadata ワークロードを Amazon RDS for Oracle AWSなどの の Oracle データベースデプロイオプションに移行する場合、Exadata データベースサーバーの使用率統計のみに基づいてコンピューティングレイヤーリソース (CPU とメモリ) をベースにしないでください。ワークロードには、スマートスキャンやストレージインデックスなどの Exadata 固有の機能も役立ちます。この機能は、処理をストレージセルにオフロードし、ストレージサーバーのリソースを使用します。したがって、Exadata 固有の機能の使用状況と、移行中に可能なワークロードの最適化の程度に基づいて、追加の CPU リソースとメモリリソースを使用して、ターゲットインスタンスにコンピューティングレイヤーをプロビジョニングする必要があります。

必要な追加の CPU リソースを正確に見積もることは困難です。検出結果をターゲット環境のサイズ設定の開始点として使用します。大まかな計算では、コンピューティングレイヤーに必要な vCPU の合計に、スマートスキャンワークロード 500 MBps ごとに 1 つの vCPUs を追加することを検討してください。

もう 1 つの方法は、ストレージサーバーの CPU 使用率を考慮することです。ストレージサーバーで使用されている CPUs の合計の約 20% を、コンピューティングレイヤーに必要な vCPUs の合計に開始点として追加できます。この割合は、AWR や CellCLI などのツールによって決定される Exadata 機能の使用に基づいて調整できます。たとえば、使用量が少ない場合は、使用量が少ない場合は 10%、中程度の場合は 20%、使用量が多い場合は 40% を追加できます。すべてのストレージサーバーで合計 20 個の CPU スレッドを使用し、Exadata 機能の使用状況が中程度と観察された場合は、ターゲット環境で欠落している Exadata 機能を補うために 4 つの追加の vCPUs を検討してください。

これらの最初の見積もりの後、ターゲット環境でパフォーマンステストを実施して、割り当てられたリソースをスケールする必要があるかどうかを判断する必要があります。パフォーマンステストでは、必要なリソースを削減できるワークロード最適化の機会がさらに増える可能性もあります。

キャッシュヒット率を向上させ、I/O フットプリントを減らすには、Oracle インスタンスへのメモリ割り当てを増やす必要がある場合があります。ソース Exadata プラットフォームには、特に統合シナリオでは、大規模な SGA 割り当てに十分なメモリがない可能性があります。I/O オペレーションは一般的に高速であるため、Exadata でパフォーマンスの問題が発生しない可能性があります。以下のメモリ割り当てをサポートするインスタンスから開始することをお勧めします。

Target memory required = larger of (8 GB per vCPUs required, two times the SGA+PGA allocation in the source)

SGA+PGA allocation = ~80% of available memory on the instance

パフォーマンステスト中、バッファプールアドバイザリ、SGA ターゲットアドバイザリ、PGA メモリアドバイザリなどの Oracle 機能を使用して、ワークロードの要件を満たすように SGA と PGA の割り当てを微調整できます。

Amazon EC2 または Amazon RDS インスタンスには、予想されるデータベースワークロードを処理するのに十分な CPU、メモリ、および I/O リソースが必要です。ワークロードをホストするには、現行世代のインスタンスクラスを使用することをお勧めします AWS。Nitro System 上に構築されたインスタンスなどの現行世代のインスタンスタイプは、ハードウェア仮想マシン (HVMsをサポートしています。強化されたネットワークとセキュリティを活用するには、HVMs に Amazon マシンイメージ (AMIs) を使用できます。Amazon RDS for Oracle は現在、最大 128 個の vCPU と 3,904 GBsメモリをサポートしています。Amazon RDS for Oracle で使用できるインスタンスクラスのハードウェア仕様については、「Amazon RDS ドキュメント」の「DB インスタンスクラス」を参照してください。リソースの詳細を含む EC2 インスタンスのリストについては、「Amazon EC2 インスタンスタイプ」を参照してください。 EC2

I/O 要件

AWR レポートを使用してリソース要件を見積もるには、ピーク時、オフピーク時、平均負荷タイミングのワークロードパターンに精通している必要があります。ピーク期間中に収集された AWR レポートに基づいてワークロードの IOPS 要件を推定するには、次の手順に従います。

AWR 統計の物理読み取り I/O リクエスト、物理書き込み I/O リクエスト、物理読み取りバイト、および物理書き込みバイトは、ワークロードの I/O アクティビティを反映しています。ただし、RMAN バックアップなどの非アプリケーションコンポーネントや、expdp や sqlldr などの他のユーティリティによって提供される I/O は除きます。このような場合は、AWR 統計の物理読み取り合計 I/O リクエスト、物理書き込み合計 I/O リクエスト、物理読み取り合計バイト、および物理書き込み合計バイトを考慮してIOPs とスループット要件を推定できます。

Exadata で実行されるデータベースは通常、前のセクションで説明した要因により、数十万 IOPS と非常に高いスループット (50 Gbps 以上) を生成します。ただし、ほとんどの場合、チューニング手法とワークロードの最適化により、ワークロードの I/O フットプリントが大幅に削減されます。

I/O 要件が非常に高い場合は、Amazon EC2 と Amazon RDS の制限に注意してください。Amazon EBS ボリュームのスループットを高めるには、x2iedn、x2idn、r5b などの Amazon EC2 インスタンスクラスを使用することを検討してください。これは、スループットが 10,000 MBps で最大 260,000 IOPS をサポートします。さまざまなインスタンスでサポートされている最大 IOPS とスループットを確認するには、Amazon EC2 ドキュメントの「Amazon EBS 最適化インスタンス」を参照してください。 Amazon EC2 Amazon RDS for Oracle の場合、rb5 インスタンスクラスは最大 256,000 IOPS をサポートし、スループットは 4,000 MBps です。Amazon RDS for Oracle で使用できる Amazon EBS 最適化インスタンスについては、「DB インスタンスクラス」を参照してください。

また、ターゲット環境で使用可能なさまざまな EBS ボリュームの場合の IOPS とスループットの測定方法も理解する必要があります。場合によっては、Amazon EBS は I/O オペレーションを分割またはマージしてスループットを最大化します。詳細については、Amazon EC2 ドキュメント」の「I/O の特性とモニタリング」および「 AWS ナレッジセンター」の「Amazon EBS プロビジョンド IOPS ボリュームのパフォーマンスを最適化するにはどうすればよいですか？」を参照してください。