本記事はOracle Cloud Infrastructure Advent Calendar 2022と、JPOUG Advent Calendar 2022の三日目の記事となります。
Oracle Cloud Infrastructure Advent Calendar 二日目の記事はshukawamさんの記事「OCI Search Service with OpenSearch を使うための最低限の環境を IaC 化した」、JPOUG Advent Calender 二日目の記事はcharade_oo4oさんの記事「Oracle on Hyper-V 2022」でした。
はじめに
2022年8月の終わりに、OCI Block Storageの自動チューニングによる動的パフォーマンス・スケーリングが発表された。
他のパブリッククラウドの場合だと、基本的に高性能なブロックボリュームディスクのプロビジョニングは先に実施しておかねばならず、また、IOPSを消費するとその分課金される仕組みであることが多い。
OCIの性能が動的にスケーリングされるブロックボリュームがどのように動作するのか、確認してみた。
動的パフォーマンス・スケーリングとは？
動的パフォーマンス・スケーリングは2つのタイプからなる。
- パフォーマンス・ベースの自動チューニング
- 該当のボリュームでモニターされたパフォーマンスに基づき、指定したレベルの中でボリュームのパフォーマンスが調整される
- デタッチ済ボリューム自動チューニング
- 該当のボリュームとインスタンスがアタッチされているかデタッチされているかに基づいて、ボリュームのパフォーマンス・レベルが調整される
VPUについて
VPUとはボリューム・パフォーマンス・ユニットのことであり、OCIのブロックボリュームのパフォーマンスを表す。
VPUを追加しボリュームに追加のリソースを割り当てることにより、IOPS/GBおよびGB当たりのスループットを増やすことができる。（減らすことも可能）
超高パフォーマンスの制限
コンピュート・シェイプによってネットワーク帯域に制限があるのは周知の話だが、高性能なブロック・ボリュームのマウントの際にはもう一つ制限がある。
その制限はマルチパス対応の有無となり、マルチパスが対応しているシェイプでないと、超高パフォーマンスとして設定されている30VPU以上のボリュームをマウントしても、20VPUまでしか性能がでない、というものになる。
マルチパス対応の制限の説明は超高パフォーマンス・ボリュームのためのアタッチメントの構成に記載がある。
通常のVMシェイプの場合、16OCPU以上が搭載されているシェイプでないと、マルチパス非対応となる。
また、ボリュームのアタッチ方法によってサポートされるOSが変わってくる、等の制限がある。
1. パフォーマンス・ベースの自動チューニング
パフォーマンス・ベースでの自動チューニングでは、ボリュームで実際にモニターされたパフォーマンスに基づき、指定したレベルの中でボリュームのパフォーマンスが調整される。
パフォーマンスを上げるための調整は数十秒単位で繰り返され、パフォーマンスを下げるための調整は、最初の調整が有効になるのが1時間以内で、その後の調整は数分で実施される。
2. デタッチ済ボリューム自動チューニング
本機能ではボリュームがデタッチされるとパフォーマンス・レベルが「より低いコスト」(0VPU/GB)に調整される。ボリュームがデタッチされた14日後に「より低いコスト」へのパフォーマンス調整が開始される。
また、ボリュームが再アタッチされると、デフォルトのVPU/GB設定で指定されたパフォーマンス・レベルに戻る。こちらは再アタッチ直後に調整される。
パフォーマンスベースの自動チューニングを試してみた
1.の「パフォーマンス・ベースの自動チューニング」について、OCIの環境で確認を行った。
検証の流れは以下。
- デフォルトのブロックボリュームと、動的パフォーマンス・ボリュームを作成し、仮想マシンにアタッチする
- それぞれのボリュームに1GBのファイルをddで作成し、負荷をかける
- それぞれのボリュームのスループットと、動的パフォーマンス・ボリュームのスケール状況を確認する
検証環境
検証環境は以下。
- 仮想マシン：VM.Standard.E2.1.Micro(前述の通りマルチパス非対応シェイプのため、～20VPUの確認となる)
- デフォルトのブロックボリューム： 50GB 10VPU
- 動的パフォーマンス・ボリューム： 50GB 10～120VPU
デフォルトのボリュームの作成
ブロックボリューム作成時に「デフォルト」を選択する。
動的パフォーマンス・ボリューム作成
ブロックボリューム作成時に「カスタム」を選択し、パフォーマンス・ベースの自動チューニングを「オン」に設定するとデフォルト・最大のVPU/GBを選択できるようになる。
通常時のVPU/GB、最大VPU/GBをそれぞれ選択することが可能となる。
なお、デタッチ済ボリューム自動チューニング機能もこの画面の下のトグルを「オン」にすることで設定することが可能となる。
作成したボリュームの確認
作成したデフォルトのボリュームと、動的パフォーマンス・ボリュームはそれぞれ以下。
各ボリュームへの負荷がけの実施
ddコマンドにてそれぞれのボリュームに1GBのファイル作成を行った。
結果、以下のように動的パフォーマンスボリュームの方が若干性能が向上している。
- デフォルトのボリューム
$ sudo dd if=/dev/zero of=/mnt/bv1/dummy bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 38.5024 s, 27.2 MB/s
- 動的パフォーマンス・ボリューム
$ sudo dd if=/dev/zero of=/mnt/bv2/dummy bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 36.5389 s, 28.7 MB/s
各ボリュームの負荷がけ後の状況確認
負荷がけ後、動的パフォーマンス・ボリュームは「より高いパフォーマンス(VPU/GB):20」に変化した。
また、この状態で再度動的パフォーマンス・ボリュームに負荷がけを行うと、1回目に比べてさらに性能が向上していた。
$ sudo dd if=/dev/zero of=/mnt/bv2/dummy bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 29.7642 s, 35.2 MB/s
まとめると、動的パフォーマンス・ボリュームはスループットが向上していることが確認できる。
| ボリューム | 回数 | 所要時間(秒) | スループット(MB/s) |
|---|---|---|---|
| バランス | 1 | 38.5024 | 27.2 |
| バランス | 2 | 37.382 | 28.1 |
| バランス | 3 | 38.2707 | 27.4 |
| 動的パフォーマンス | 1 | 36.5389 | 28.7 |
| 動的パフォーマンス | 2 | 29.7642 | 35.2 |
| 動的パフォーマンス | 3 | 30.3904 | 34.5 |
負荷がけとスケーリングの関係
負荷がけのタイミングから少なくとも１分以内にはパフォーマンスがチューニングされていることが確認できていたため、改めてどの程度の負荷で、どのくらいのタイミングでチューニングが行われるのかを確認する。
負荷のサイズを少しずつ増加させて確認したところ、300MBの負荷(約10秒間の負荷がけ)でチューニングが発生した。
また、チューニングされるタイミングは、負荷がけ開始のタイミングから約30秒後となっていた。
ちなみにチューニングが発生するタイミングはOCI監査でcom.oraclecloud.BlockVolumes.UpdateVolume.endのTypeを検索すると確認できる。
"stateChange": {
"current": {
"VPU": 20
},
"previous": {
"VPU": 10
}
}
また、ガイド通り約1時間でチューニングが戻ることも確認できた。
"stateChange": {
"current": {
"VPU": 10
},
"previous": {
"VPU": 20
}
}
まとめ
Oracle CloudのBlock Volumeの性能動的スケーリングを確認した。
性能チューニングは約30秒程度で実行され、特にユーザ側は気にすることなくチューニングの恩恵を受けることができた。
この機能を利用することで、必要なタイミングで必要なだけ性能を確保することができ、細かいチューニングや比較的高価な高性能ボリュームの予約をすることなく必要な性能を確保することができる。
超高パフォーマンス（VPU>30）を利用する場合にはいくつか制限があるが、利用できる環境の場合にはAutonomousな恩恵を享受できるため、高性能が必要な可能性がある場合には設定しておいて損はないと考えている。