
- Oracle Cloud
- Oracle Database
Oracle Cloud VMware SolutionでのVMware HCX環境構築手順(後編)
前回の記事でOCVS)でHCXを利用するための前提となる手順の前半をお伝えしました。本記事では後続の手順であるサービスメッシュ作成・L2延伸手順を記載し、仮想マシンを移行できる状態、つまりHCX環境の構築完了までを説明します。
|
「Oracle CloudWorld 2024」にて発表された新サービス「Oracle Exadata Database Service on Exascale Infrastructure(以下、ExaDB-XS)」について、前回の記事ではExaDB-XSの特徴とメリットについて紹介しました。
クラウドデータベースの選定において、コストとパフォーマンスは重要なポイントです。
本記事では、ExaDB-XSと標準的なPaaSサービスであるOracle Base Database Service(以下、BaseDB)をコストで比較するのに加え、簡易的なパフォーマンス比較もします。
ExaDB-XSの優位性がどのような点にあるのかを明らかにしていきます。
Index
今回、簡易比較検証を実施したBaseDBとExaDB-XSはそれぞれ以下の構成となります。
BaseDB | ExaDB-XS | |
---|---|---|
CPU数 | 8 OCPU(4×2node) | 合計ECPU:48 ECPU 有効ECPU:32 ECPU |
メモリー容量(GB) | 128(64×2node) | 132(66×2node) |
VM数 | 2(RAC構成) | 2(RAC構成) |
DBストレージ | 1024 GB(+DATA領域) | 1024 GB |
ExaDB-XSには合計ECPUと有効ECPU、予約済ECPUが存在します。それぞれ単価が異なります。
合計ECPUは、ユーザー側であらかじめ利用を予約しているECPU数のことです。
ExaDB-XSは共有インフラストラクチャであるため、物理的な基盤を他のユーザーと共有しています。そのため、ユーザー側で必要な時に必要なCPU数を利用するために、ECPU数を予約することが可能です。ExaDB-XSのクラスタ全体のメモリ容量(GB)は、この合計ECPU数に紐づいて算出されます。
なお、合計ECPUのスケーリング時には仮想マシンが再起動されますのでご留意ください。
有効ECPUは、実際に仮想マシン上でアクティブなECPU数のことです。
ExaDB-XSを利用しない時は、0にスケーリングして課金を削減することが可能です(有効ECPU数が0の場合は仮想マシン自体が停止しています)。
予約済ECPUは、合計ECPUと有効ECPUの差分のECPU数のことです(合計ECPUと有効ECPUから自動で算出)。
仮想マシン上でアクティブではないため、有効ECPUよりも単価が低く設定されています。
以下の場合には、予約済ECPUの確保の検討を推奨します。
①大きなメモリ容量が必要な場合
仮想マシンのクラスタ全体のメモリ容量は、合計ECPU数に基づいて算出されます。そのため、大きなメモリ容量が必要な場合は、合計ECPUを有効ECPUよりも多く設定します。
②ECPU数のオンラインスケーリングの要件がある場合
合計ECPU数のスケーリング時には、仮想マシンの再起動が発生します。そのため、オンラインスケーリングをする要件がある場合は予約ECPUを確保することで、システムを停止せずにスケーリングをすることができます。
これらのECPUにより、ExaDB-XSはECPU数とメモリ容量を柔軟に選択できるため、OCPU数とメモリ容量が固定であるBaseDBと比べて高い柔軟性があります。
ExaDB-XSとBaseDBを1か月稼働させた場合のコストをCost Estimator(https://www.oracle.com/jp/cloud/costestimator.html
※オラクル社のサイトに移動します)で試算してみました。
試算結果の比較は以下のとおりです。
BaseDB | ExaDB-XS | |
---|---|---|
1か月あたりの金額(744h) | 1,256,023 円 | 1,409,516 円 |
上記のコスト比較の表から分かるように、1か月稼働し続けた場合のコストは、わずか12%程度の差となりました。ExaDB-XSはExadata基盤で稼働しているので「高額」という印象を持っていた方もいらっしゃるかも知れませんが、BaseDBと比べてわずかなコスト差しかないことが分かります。
検証では、OLTP系とDWH系それぞれの典型的なワークロードを用いて比較しました。
結果は以下のとおりです。
OLTP系のワークロードでは、BaseDBとExaDB-XSでは大きな性能差は見られませんでした。
これにより、OLTP系のワークロードではBaseDBでも十分な処理性能が発揮されることがわかりました。
データウェアハウス(DWH)系のワークロードでは、ExaDB-XSが圧倒的な優位性を示す結果となりました。
これは前記事でも紹介したExadata固有の機能のSmart Scanが影響しています。
SmartScanは、大量データに対する集計、分析、検索の処理をストレージ側で実行する仕組みです。これにより、I/O量を大幅に削減し、SQLの実行時間を短縮することができます。
この技術は特に以下のようなワークロードで優位性を発揮します。
・大量データの集計・分析処理(DWH系)
・検索条件の絞り込みがあるバッチ処理
・OLAP的な多次元分析クエリ
以上の結果より、DWH分野における、データの集計、分析、検索の処理のワークロードや、オンライントランザクション処理とDWHの混合ワークロード(ミックスワークロード)のシステムにおいて、Exadata固有の機能を利用できるExaDB-XSに圧倒的なメリットがあることがわかりました。
今回はExaDB-XSとBaseDBについて、コストと簡易的なパフォーマンスの比較を紹介しました。
ExaDB-XSとBaseDBの比較によりわかったこと:
・コスト面:Exadata基盤を利用しているにも関わらず、わずか12%程度の違いである
・性能面:Exadata固有の機能Smart Scanの効果のより、DWH系の処理においてExaDB-XSが圧倒的に優れている
つまり、ExaDB-XSは既存のPaaSサービスと比べて、柔軟性やコスト面でのメリットが大きく、優れたコストパフォーマンスを持っているといえます。
本記事でExaDB-XSやパフォーマンス比較結果の詳細についてご興味を持たれた際は、当社までお気軽にご相談ください。
今後もOracle Cloudの注目のサービスを紹介します!
![]() |
---|
■本記事の内容について
本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。
■商標に関して
・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
前回の記事でOCVS)でHCXを利用するための前提となる手順の前半をお伝えしました。本記事では後続の手順であるサービスメッシュ作成・L2延伸手順を記載し、仮想マシンを移行できる状態、つまりHCX環境の構築完了までを説明します。
23aiで読取り専用モードの機能が拡張されました。ユーザー/セッション単位で読み書き可能/読取り専用モードの使い分けができるようになり、今まで以上にメンテナンス操作やアプリケーションからの接続の権限管理が柔軟にできるようになっています。
Oracle Database 23aiの新機能であるロックフリー予約により、トランザクション同士がブロックすることなく、効率的なデータ更新を実現できます。本記事では、ロックフリー予約の使い方をご紹介します。