はじめに!

こんにちは!
2019年新卒で入社した、「たくみ」です。

過去にOracle Cloud infrastructure(以下OCI)のブロック・ボリュームについて
何度か執筆させて頂きましたが、今回もブロック・ボリュームについてです(笑)

今回はブロック・ボリュームのパフォーマンスについてです。

ブロック・ボリュームのパフォーマンスが決まる要素や、
実際に各パターンでのスループット(書き込み速度)の違いの検証結果をご紹介します!

たくみさんのブロック・ボリュームに関する過去記事も是非ごらんくださいね。
他にも多数執筆していますがいずれも人気記事です。
OCI ブロック・ボリュームのサイズを変更してみよう!
OCI ブロック・ボリュームをインスタンスにアタッチしてみよう!
OCI ブロック・ボリュームをクローニングしてみよう!

ブロック・ボリュームのパフォーマンスについて

※ブロック・ボリュームについてやその作成手順は「こちら」の記事もご参照ください!

まずはブロック・ボリュームのパフォーマンスについてご説明します。
ブロック・ボリュームのパフォーマンスを決める要素として主に下記2つがあります!

  • パフォーマンス・レベル
  • ブロック・ボリュームのサイズ

パフォーマンス・レベルを高性能なものに設定するほど、
ブロック・ボリュームのサイズを大きくするほど、ブロック・ボリュームのパフォーマンスは向上します。
※ブロック・ボリュームのサイズについては、一定以上になるとパフォーマンスは向上しなくなります。

パフォーマンス・レベル

ブロック・ボリュームのパフォーマンス・レベルは大きく分けて4段階存在します。
また、その中の「超高パフォーマンス」はボリューム・パフォーマンス・ユニット(以下VPU)を指定でき、さらにパフォーマンス・レベルを調整することができます。
(他のパフォーマンス・レベルのVPUは固定です。)

VPUは10の倍数の整数で、0から120まで指定することができます。
考え方としては、ストレージ価格に加えて、毎月1 GBあたり 「XX VPU」を購入するといったものになります。
※価格については後述いたします。

このVPU毎にパフォーマンス関連の数値が定義されており、VPU数が大きくするほど、ブロック・ボリュームのパフォーマンスが向上します!

このパフォーマンス・レベルはブロック・ボリュームの作成時に指定できます。
また一部例外を除き、インスタンスにアタッチした状態でも、オンラインで上下させることが可能です!
※ブロック・ボリュームのサイズは縮小できませんので、ご注意ください。

それでは、各パフォーマンス・レベルについてご紹介します!

超高パフォーマンス(VPU:30~120)

I/O要件が最も高く、大規模なデータベースなどに推奨されます。
上述の通り、VPUを30から120まで(10段階)指定できます。
その理論上の最大スループットは
2,680 MB/秒(VPU:120 ボリュームサイズ:1500 GB以上 ブロック・サイズ:1 MB の時)となっています!

また、各VPU毎にGB当たりのIOPS(1秒間に処理(読み取り/書き込み)できる回数)が設定されています。
120 VPUの場合のGBあたりのIOPSは225 IOPS/GBとなり、
理論上の最大IOPSは300,000 IOPS(ボリュームサイズ:1,333 GB の時)となっています!

ただし、最適なパフォーマンスを実現するには、ボリューム・アタッチメントをマルチパス対応にする必要があります。

また、他のパフォーマンス・レベルから超高パフォーマンス・レベルに変更する場合、1度ブロック・ボリュームをインスタンスからデタッチし、再アタッチする必要がありますので、ご注意くだい。

超高パフォーマンスについてのトラブルシューティングがこちらにまとめられています!
併せてご参考ください!

・参考マニュアル
超高パフォーマンス・ボリューム・アタッチメントのトラブルシューティング

より高いパフォーマンス(VPU:20)

高いワークロードのシステムであるが、
超高パフォーマンス程の性能は求められないシステムに推奨されます。
理論上の最大スループットは
680 MB/秒(ボリュームサイズ:1200 GB以上 の時)となっています!

GBあたりのIOPSは75 IOPS/GBとなり、
理論上の最大IOPSは50,000 IOPS(ボリュームサイズ:667 GB の時)となっています!

バランス(VPU:10)

デフォルトのパフォーマンス・レベルで、パフォーマンスとコスト削減のバランスを取ることが可能です。
また、ブート・ボリュームで指定できる最小パフォーマンス・レベルとなります。
理論上の最大スループットは
480 MB/秒(ボリュームサイズ:1024 GB(1 TB) 以上 ブロック・サイズ:1 MB の時)となっています!

GBあたりのIOPSは60 IOPS/GBとなり、
理論上の最大IOPSは25,000 IOPS(ボリュームサイズ:417 GB の時)となっています!

より低いコスト(VPU:0)

ストリーミング、ログ処理、データ・ウェアハウスなど、大規模な順次I/Oがあるスループット集中型のワークロードに推奨されます。
また、ブート・ボリュームには指定することができません。
理論上の最大スループットは
480 MB/秒(ボリュームサイズ:1,536 GB(1.5TB)以上  ブロック・サイズ:1 MB の時)となっています!

GBあたりのIOPSは2 IOPS/GBとなり、
理論上の最大IOPSは3,000 IOPS(ボリュームサイズ:1,500 GB の時)となっています!

下記OCIマニュアルに各パフォーマンス・レベル(VPU)の詳細へのリンクや、最大パフォーマンスが表にまとめられています。
併せてご確認ください!

・参考マニュアル
ブロック・ボリューム・パフォーマンス

また、OCIにログイン可能な場合、ブロック・ボリュームの作成画面から、
指定した条件における最大スループット/IOPSを確認することができます!
実際に作成する必要はないので、是非様々な条件で試してみてください!

赤枠のところで確認!
※確認のみの場合は最後に「取消」をクリックしてください。
※作成画面については先述した「こちら」の記事もご参照ください!

ブロック・ボリュームの価格計算

ここからはブロック・ボリュームの価格について記載します!

パフォーマンスが主にパフォーマンス・レベル(VPU)ブロック・ボリュームのサイズに影響されますが、価格も同様となります。

その月額価格の計算式は下記です。

(ストレージ単価*サイズ)+(VPU単価*VPU数*サイズ)

2024年11月時点でのストレージ単価は\3.9525、VPU単価は¥0.2635ですので、仮にVPU数を10(バランス)サイズを100GBとした場合の月額は下記のようになります。

(3.9525*100)+(0.2635*10*100)=\658.75

なお、各単価が改訂されることもございますので、最新の単価は下記マニュアルから確認してください。

OCI価格リスト(ストレージ)

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

ブロック・ボリュームのパフォーマンスはパフォーマンス・レベル、ブロック・ボリュームのサイズ以外にも様々な要因で変動します。
その主な要因として以下のようなものがあげられます。実際の構築/運用の際にはご留意ください。

  • 使用されるファイル・システム
  • ブロック・ボリュームをアタッチするインスタンスのシェイプの種類
  • ネットワーク帯域幅(仮想マシン コンピュート・インスタンスの場合)
    仮想マシン コンピュート・インスタンスの場合、
    インスタンスとブロック・ボリューム間はネットワークでつながっています。
    そのため、ネットワーク帯域幅の影響を受けます。
  • サード・パーティのセキュリティ・ツール
    特にWindows環境にてデフォルトで有効となっている、
    「Windows Defender Advanced Threat Protection」
    ディスクのI/Oパフォーマンスを大きく低下させます
  • 転送中の暗号化
    転送中の暗号化を有効にしている場合、パフォーマンスは低下します。

その他のパフォーマンス関連の機能

その他、パフォーマンス関連の機能については下記のようなものがあります。
ここでは簡単なご紹介となりますが、検証できましたら記事にしてみたいと思います!

パフォーマンス・ベースの自動チューニング

ボリュームへの負荷状況に応じて、
ユーザーが指定したデフォルトVPU/GB(最低値)最大VPU/GB(最大値)の間で、パフォーマンス・レベル(VPU)を自動調整してくれる機能になります!

常に高いパフォーマンス・レベルを維持する必要がない場合、この機能を利用することでコスト削減につなげることができます!

デタッチ済ボリューム自動チューニング


ブロック・ボリュームをインスタンスからデタッチした際にパフォーマンス・レベルを自動的に「より低いコスト」に調整してくれる機能になります!
また、再アタッチすることで元のパフォーマンス・レベルに戻してくれます。
※自動チューニングが有効の場合はデフォルト値(最低値)に戻ります。

この機能を使うことで、使用していないブロック・ボリュームのパフォーマンス・レベルを下げ忘れて、無駄なコストがかかるのを防げます。

検証

それでは、パフォーマンス・レベルとサイズによって本当にブロック・ボリュームのパフォーマンスが向上するのか検証いたしましたので、ご紹介します。

ブロック・ボリュームをアタッチしたインスタンス情報は下記の通りです。

インスタンス・タイプ 仮想マシン
OS Oracle Linux 8
シェイプ
OCPU数 1
ネットワーク帯域幅(Gbps) 1

検証方法は各パターンでのブロック・ボリュームに「dd」コマンドで5 GBのファイルを作成し、
その時のスループット(MB/秒)を比較します。

それぞれのパターンは下記の通りです。

  • パターン1 (基準)
    パフォーマンス・レベル :より低いコスト
    ブロック・ボリュームのサイズ:50 GB
  • パターン2 (パフォーマンス・レベルのみ変更)
    パフォーマンス・レベル :バランス
    ブロック・ボリュームのサイズ:50 GB
  • パターン3 (サイズのみ変更)
    パフォーマンス・レベル :より低いコスト
    ブロック・ボリュームのサイズ:100 GB
  • パターン4 (パフォーマンス・レベルとサイズを変更)
    パフォーマンス・レベル :バランス
    ブロック・ボリュームのサイズ:100 GB

それでは早速結果を見てみましょう!

パターン1 (基準)

[root@test-instance ~]# dd if=/dev/zero of=/mount/low_50G bs=1G count=5 
5+0 records in 
5+0 records out 
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 348.028 s, 15.4 MB/s 

パターン2 (パフォーマンス・レベルのみ変更)

[root@test-instance ~]# dd if=/dev/zero of=/mount/balance_50G bs=1G count=5 
5+0 records in 
5+0 records out 
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 174.138 s, 30.8 MB/s 

パターン3 (サイズのみ変更)

[root@test-instance ~]# dd if=/dev/zero of=/mount/low_100G bs=1G count=5 
5+0 records in
5+0 records out
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 174.123 s, 30.8 MB/s

パターン4 (パフォーマンス・レベルとサイズを変更)

[root@test-instance ~]# dd if=/dev/zero of=/mount/balance_100G bs=1G count=5
5+0 records in
5+0 records out
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 86.154 s, 62.3 MB/s

表にまとめますと下記の通りです!

パターン 検証時のスループット 理論上のスループット
(ブロック・ボリューム
作成画面より確認)
パターン1 (基準)
パフォーマンス・レベル :より低いコスト
ブロック・ボリュームのサイズ:50 GB
15.4 MB/秒 12 MB/秒
パターン2 (パフォーマンス・レベルのみ変更)
パフォーマンス・レベル :バランス
ブロック・ボリュームのサイズ:50 GB
30.8 MB/秒 24 MB/秒
パターン3 (サイズのみ変更)
パフォーマンス・レベル :より低いコスト
ブロック・ボリュームのサイズ:100 GB
30.8 MB/秒 24 MB/秒
パターン4 (パフォーマンス・レベルとサイズを変更)
パフォーマンス・レベル :バランス
ブロック・ボリュームのサイズ:100 GB
62.3 MB/秒 48 MB/秒

いかがでしょうか。
パフォーマンス・レベル及びサイズを大きくすることで、ブロック・ボリュームのスループットが早くなっているいることが確認できました!
それどころか理論上のスループットよりも早いですね( ゚Д゚)

もちろん、何も負荷がかかっていない検証環境に、5 GBのファイルを作成しただけですので、実際の環境では必ずしも同じ結果になるとは限らないことはご注意ください!

まとめ

いかがだったでしょうか。
今回はブロック・ボリュームのパフォーマンスについてご紹介いたしました。

ストレージのパフォーマンスが良くないと感じたときに、すぐにパフォーマンス・レベル(VPU)をオンラインで上げることができますので、運用される際はご検討ください。

本記事が実際の業務の参考となりましたら幸いです。
最後までご精読頂きまして、ありがとうございました!

OracleDBに関してお困りのことがあれば是非お問い合わせください。

投稿者プロフィール

技術チーム
技術チーム
DBひとりでできるもんを盛り上げるべく、技術チームが立ち上がり早6年。ひとりでできるもんと言いつつ、技術者が読んでプッとなるような、極めてピンポイントでマニアックな技術ネタを執筆しています!