Oracle Database 19c のダイナミック CPU スケーリング (2020/05/25)

https://blogs.oracle.com/database/post/dynamic-cpu-scaling-in-oracle-database-19c

投稿者：Christian Craft

Oracle Database 19c のダイナミック CPU スケーリング

 

Oracle Database 19c（リリース19.4以降）には、CPUの最小値/最大値の範囲を使用して、ワークロードの要求に応じてPluggable Databaseのコンピュートを動的にスケールアップ/スケールダウンする機能が搭載されています。 Pluggable Databaseで利用可能なコンピュートリソースのスケールアップとスケールダウンは、介入なしで自動的に、瞬時に、かつダイナミックに行われるように構成できます。

なぜこれが重要なのか？すべてのシステム（ベアメタル、仮想マシンを問わず）には、ある時点で未使用のコンピュートキャパシティがあります。 データベースのワークロードは一定ではなく、1日の中で大きく変化する可能性があります。ダイナミックCPUスケーリングにより、プラガブルデータベースは、システムに空き容量があれば、必要なときに自動的に余分な容量を消費します。この機能により、システムレベルでのオーバープロビジョニングの必要性がなくなり、未使用のコンピュートキャパシティを活用しながら、より予測可能なパフォーマンスが得られます。クラウドのサブスクリプションモデルで稼働しているデータベースの場合、ダイナミック CPU スケーリングはプロビジョニングされた容量をより効果的に使用するため、サブスクリプションコストを削減できます。

ノイジーネイバーの問題に対するより良いアプローチ

この新機能が導入される前は、DBA はデータベースのピーク負荷に合わせてリソースを割り当て、確実にスケールアップできるようにしたり、必要なリソースが他のアプリケーションに取られないようにしなければなりませんでした。Oracle Database 19.4 の min/max レンジを使用する機能は、制御が困難で深刻なパフォーマンス問題を引き起こす可能性のあるオーバープロビジョニングに依存しないため、「Noisy Neighbor」問題に対するより良いアプローチとなります。 「Noisy Neighbor」 問題は、後述するように、リソースの過剰プロビジョニングによって引き起こされます。

まず、基本的なことを説明します。

サーバーは、ベアメタルまたは仮想マシンとして構成することができます。ベアメタルサーバーでは、チップ上のすべてのCPUコアを使用することができますが、システムBIOSでアクティブコアの数を制限することもできます。また、各プロセッサコアは複数のハイパースレッドを持つことができ、これを仮想CPU（vCPU）と呼びます。現世代のインテル製プロセッサーでは、各プロセッサーコアに2つのハイパースレッド（2つのvCPU）が搭載されています。

仮想マシンは通常、仮想CPU（vCPU）の上に構成され、サーバー上の利用可能なvCPUのすべて、またはvCPUのサブセットを使用するように設定することができます。 もちろん、あるマシン上の仮想マシンに、そのマシンが利用可能なvCPUよりも多くのvCPUを与えることで、仮想マシンをオーバープロビジョニングすることも可能です。

例えば、100個のvCPU（ハイパースレッド）が利用できるマシンがあるとします。10個のvCPUを持つVMを10個作成しても、システムのオーバープロビジョニングにはなりません。 しかし、10個のvCPUを持つVMを20個作成すると、システムで利用可能なvCPUの数を超えてしまうため、2倍のオーバープロビジョニングとなります。 20台のVMが同時に割り当てられたvCPUをすべて消費した場合、システム全体として深刻なパフォーマンス問題が発生します。この状態は、Linuxの「sar -q」コマンドなどを使ってプロセッサの実行キューを見ることで、システムレベルで確認することができます。

Oracle Cloudは、他のクラウドベンダーとは異なり、仮想マシンのコンピュートシェイプを過剰にプロビジョニングしないことに注意してください。また、オラクルはハイパースレッドではなくプロセッサコアの使用量に対して課金します。Oracle Cloudでは1 OCPUが1つのプロセッサコアに相当しますが、他のクラウドプロバイダーの中には、vCPU（ハイパースレッド）または約1/2コアに基づいて課金するところもあります。

ベアメタルマシンや仮想マシンの上では、Oracle Database Resource Manager (DBRM) を有効にして CPU_COUNT パラメーターを設定することで、Oracle Databaseの各インスタンスがいくつかの vCPU を使用するように構成されます。DBRM が構成されていない場合は、CPU_COUNT 設定は単にシステム上の合計 vCPU を反映します。DBRM を有効にすると、CPU_COUNT 設定がデータベースで利用可能な vCPU 数を制御できるようになります。これは、CDB（Container Database）とPDB（Pluggable Database）の両方のレベルで適用されます。

先に述べたように、システムレベルでのオーバープロビジョニングが可能ですが、データベースレベルでもオーバープロビジョニングが可能なのです。 例えば、ある仮想マシンが10個のvCPUで構成されていて、10個のデータベースをそれぞれ2個のvCPUで作成したとします（CPU_COUNT=2）。この場合、仮想マシンは2倍のオーバープロビジョニングとなります。 10個のデータベースが同時に割り当てられたvCPUをすべて消費した場合、システム（ベアメタルまたはVM）全体として深刻なパフォーマンス問題が発生します。

つまり、オーバープロビジョニングとは、同じリソースを複数のユーザーに何度も「売る」ことなのです。誰もが同時にそのリソースを必要としないことを期待して、リソースを約束することです。 オーバープロビジョニングの危険性は、すべてのユーザー（すべてのデータベース）が同時にアクティブになることです。利用可能なvCPUをオーバーランさせると、プロセッサのランキューに仕事が入り、システムが不安定になったり、反応しなくなったりします。

CPU割り当ての考え方

CPUリソースを管理する最も一般的な方法は、オーバープロビジョニングを行わず、利用可能なものに応じて単純にCPUを割り当てることです。 これは非常に簡単な方法ですが、システムリソースが十分に活用されていないことになります。すべてのデータベースは、割り当てられたCPU（vCPU）の最大値よりも低い値で動作する時間があるため、この方法では利用率が低くなり、組織のコストが高くなってしまいます。

1 つのデータベースを含む仮想マシンに CPU を割り当てる場合も、1 つの仮想マシンに存在する個々のデータベースに CPU を割り当てる場合も、結果は同じです。各データベースには余剰の CPU ヘッドルームが与えられており、その閾値以下の CPU 使用率は変動します。その結果、次の図に示すように、使用されていないCPU容量が増え、コストが高くなります。

CPUオーバープロビジョニング

先に述べたように、未使用のCPUリソースを確保するための一般的なアプローチの1つは、単純にシステムをオーバープロビジョニングすることです。各データベースに、より多くの CPU リソースを割り当てることができ、割り当てられた合計量がシステム上の CPU 量を上回ります。 これをシステム（仮想マシン）レベルで行っても、データベース間でオーバープロビジョニングしても、結果は同じです。 オーバープロビジョニングは、「Noisy Neighbor」問題の原因となり、システムが不安定になったり、反応しなくなったりします。

シェアと制限

オラクルでは、コンテナデータベース内の各Pluggable Databaseに「シェア」を設定する機能があります。 コンテナデータベースの各インスタンスには、DBRMを有効にしてCPU_COUNTを設定することで、使用するvCPUの量が与えられます。そして、そのコンテナ・データベース内のプラグインデータベースには、コンテナ・データベースが利用できるvCPUの「シェア」が与えられる。各Pluggable Databaseは、指定されたシェアのCPUリソースを受け取り、システムがオーバーサブスクライブされることはありません。

また、各Pluggable Databaseには、使用できるCPUリソースの上限を設定することができ、データベースのパフォーマンスの大幅な変動を防ぐことができます。Pluggable Databaseに制限がない場合、各データベースはシステム上の未使用のCPUをすべて使用することができるため、ユーザーにはパフォーマンスの大きな変動と映る可能性があります。シェアはシェアの値で表されますが、利用制限は以下の例のようにパーセンテージで表されます。

Pluggable Database	Shares	Share %	Utilization Limit
PDB1	1	10%	20%
PDB2	2	20%	40%
PDB3	2	20%	40%
PDB4	5	50%	90%
Total:	10	100%

 

シェアの値は、コンテナデータベース内の他のPluggable Databaseとの相対値です。シェアの割合は、シェアの値をコンテナデータベース内の全シェアの合計で単純に割ることで計算できます。 Utilization Limitsは、パーセンテージで表されます。Utilization Limitsの合計が100%より大きいことに注意してください。しかし、Container Databaseが制限に達した場合は、Sharesの値が優先されます。Pluggable Databaseは、規定のCPUシェアを受け取り、追加のCPUが利用可能であれば、そのシェアを超えて上限に達することができます。コンテナデータベースにプラグインデータベースが頻繁に追加・削除される環境では、シェアとリミットの管理が難しくなります。 シェアとリミットの値は、プラグイン式データベースが追加または削除されるたびにリファクタリングする必要があります。シェア＆リミットのアプローチではなく、現在はCPUの最小/最大範囲機能の使用を推奨しています。

Oracle Database 19c (19.4)のダイナミック CPU スケーリングについて

ダイナミック CPU スケーリング が重要である理由を説明しましたが、この機能の仕組みを見てみましょう。 管理者は、CPU の min/max レンジを使用して、各 Pluggable Database で利用可能な vCPU の下限と上限を設定できます。 各Pluggable Databaseは、保証された最低量のvCPUを受け取りますが、最大レベルまで自動的にスケールアップすることもできます。 この機能は、各Pluggable Database内の以下の2つのシンプルなパラメータによって制御されます。

•     CPU_MIN_COUNT
•     CPU_COUNT

CPU_MIN_COUNT は、Pluggable Database Instance が受け取る vCPU の最小数です。 すべてのPluggable DatabaseインスタンスのCPU_MIN_COUNTの合計が、Container DatabaseインスタンスのCPU_COUNTを超えないようにしてください。DBRMが有効で、かつCPU_MIN_COUNTが設定されている場合、CPU_COUNTパラメータは、Pluggable Database Instanceが使用できるvCPUの最大数を定義します。 

仮想マシンによるデータベースへのハードな割り当てや、単一のコンテナデータベース内での個々のデータベースの割り当てを行わないことで、すべてのデータベースが余剰容量を共有することができます。 また、すべてのデータベースは、CPUのヘッドルームとして1つの割り当てを共有しており、すべてのデータベースは最低保証で同じ容量を共有しています。下の例では、全体の使用容量は前の図の約1/2ですが、すべてのデータベースが必要な容量を使用することができます。

CPU_MIN_COUNTとCPU_COUNTの比率を標準化することをお勧めします。たとえば、CPU_COUNTをCPU_MIN_COUNTの3倍の値に設定します。これは、Oracle DatabaseのvCPU使用率が、MINからMAXまでの3倍の範囲内に収まることを意味します。広い範囲を使用すると、パフォーマンスのばらつきが大きくなり、ユーザーの満足度が低下する可能性があります。一方、狭い範囲を使用すると、（未使用の）計算能力が余ってしまい、コストが高くなる可能性があります。CPUの最小/最大の範囲は、特定のコンテナデータベースに存在するデータベースのワークロードによって異なります。また、Oracle Real Application Clusters環境では、データベースノードの大きさを等しくし、各インスタンスのCPUの最小/最大範囲を等しく設定した対称クラスター構成を推奨します。非対称クラスター（異なるサイズのデータベースサーバーまたは仮想マシンを使用）は、非対称性の程度が低い（サーバーまたは仮想マシンのサイズのばらつきが小さい）場合は許容されます。

CPU_MIN_COUNT と CPU_COUNT は，それぞれの Pluggable Database のインスタンスレベルで適用されることに注意してください。Pluggable DatabaseがReal Application Cluster (RAC)構成の一部である場合、Pluggable Databaseの合計のCPU min/max範囲は、Oracle Real Application Cluster (RAC)インスタンスの数で乗算されます。たとえば、CPU_MIN_COUNT=2のPluggable Databaseが2ノードのRACクラスタに属している場合、合計で最低4つのvCPUにアクセスできます。 コンテナデータベースレベルでは、CPU_COUNTのみを使用し（CPU_MIN_COUNTは使用しない）、これは各RACインスタンスにも適用されます。Oracle Database 19c では、コンテナデータベースレベルでの CPU の最小/最大範囲 (PDB/CDB 以外のデータベースでも同じ) は利用できません。RAC クラスターの各インスタンスは、同じようなサイズのコンピュートノードを使用し、Pluggable Database レベルと Container Database レベルの両方でこれらのパラメーターに同じ値を設定した対称的な構成を使用することが理想的です。

DBRMは、各Pluggable Database内のCPUリソースの需要と、コンテナデータベース・レベルでのCPUリソースの全体的な利用可能性を常に監視しています。DBRMは、コンテナデータベースで利用可能な場合、より多くのCPUリソースを使用するために、各プラグイン・データベースを自動的かつ即座にスケールアップさせます。DBRMは、需要が落ち着くとCPUリソースを自動的かつ即座にスケールダウンさせます。コンテナ内に存在する他のPluggable Databaseは、そのCPU割り当てを消費し始める可能性があるため、CPU_MIN_COUNT以上の容量は保証されず、それらの他のPluggable Databaseによる使用のために取り出される可能性があります。

まとめ

Oracle Database 19cの新機能であるダイナミック CPU スケーリングを使うと、ユーザーの要求に応じてPluggable DatabasesのCPUリソースを自動的に増減させることができます。この機能は、従来の「シェア＆リミット」方式よりも管理が容易で、特にコンテナデータベースにプラグイン式データベースを頻繁に追加・削除する場合に有効です。CPUの最小値と最大値の範囲は、自動的、動的、かつ即時に機能するため、オンプレミス環境やクラウド環境において、計算リソースをより効果的に使用することができ、全体的なコストを削減することができます。

See also…

CPU_MIN_COUNT – 

https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/CPU_MIN_COUNT.html

Oracle MAA Best Practices for Database Consolidation –

https://www.oracle.com/technetwork/database/availability/maa-consolidation-5648225.pdf