はじめに
"Flexible profile"とは
Flex profileとは、Virtual Server for VPCで利用可能な、CPUプロファイルのタイプの1つです。ユーザーはvCPU(1~64 vCPUs), Memory,Bandwidthの組み合わせを選択可能で、実際に割り当てられるハードウェアやCPU世代は、プロバイダー側のリソース状況に応じて決定されます。第2世代および第4世代のIntel Xeon Scalableプロセッサー(Cascade Lake/ Sapphire Rapids)とAMDの第3世代EPYCプロセッサーのうち、指定された地域で利用可能な世代のプロセッサーに配置されます。
少し言い方を変えると、Flex profileでは、CPU世代の指定ではなく性能レベルで指定してオーダーします。これによってクラウドプロバイダー側は最新世代のCPUを導入しつつ、古い世代も活用できます。そのため、ユーザーとしてはvCPUあたりのコストを抑えてVSIを利用することができます。
(ご参考：General purpose - Flex)
"Burstable option"とは
(2025年12月現在ベータ版です) 12/12時点でBurstable機能はGAしたようです。
https://cloud.ibm.com/docs/vpc?topic=vpc-release-notes&locale=en#vpc-dec1225
Burstable optionはFlex profileの一部で利用可能なオプションの機能です。この機能を有効化したVSIは、普段のワークロードはオーダー時に設定したベースラインレベル(10％、25％、50％から選択)で動作し、必要なときに設定されたベースラインの最大2倍までのパフォーマンスにバーストすることができます。たとえば、25％のベースラインを持つインスタンスは、ホスト側でアイドルCPU時間が利用可能な場合、割り当てられたvCPUの50％までパフォーマンスを引き上げることができます。
(ご参考：Burstable virtual servers)
今回の検証では、Flex profile + Burstable optionでVSIをオーダーしてみて、どんなCPUに配置されるのかや、Burstable optionの挙動について確認してみました。
手順
1. VSIのオーダー
- Location: jp-tok, tok02
- Image: CentOS Stream9
- Profile: 2vCPU, 4GiB RAM
"c×f-2×4" - Convert to burstable instance: 有効化
- vCPUあたりのベースラインパフォーマンス：50%
今回の検証ではBurstable optionを試すので、"Burstable instance"にもチェックを入れてProfile検索しました
Convert to burstable instanceの項目を有効化します。
vCPUあたりのベースラインパフォーマンスを50%に設定しました。
2. flex profileのCPU世代を確認してみる
SSHでVSIに接続します。
ssh root@xx.xx.xx.xx
接続ができたら、以下のCPUの情報を調べるコマンドを打ってみます。
lscpu
以下のように返ってきました。
Flex profileでオーダーしたところ、オーダーしたVSIのCPU世代がCascade Lakeということはわかりました。OS側が認識する仮想HWまでしか読み取れず、それより下のレイヤーの情報はわかりませんでした。
3. CPU負荷をかけてBurstさせてみる
今回設定したベースライン性能の50%から、CPU負荷がかかると最大2倍になるということです。
また、ポータル画面を見た限りですが、バーストのタイミングはユーザーが任意に操作できるわけでは無いようです。ですので今回はコマンドでCPU負荷をかけてみて、バースト機能が発動したかどうかをCloud Monitoringや追加検証で確認してみます。
CPU負荷なし
まず、CPUに負荷がかかっていない状態で、Cloud MonitoringでCPU Usageを確認します。VSIのOverview画面右側からMonitoringを開きます。
VSI for VPCの"Average CPU usage across all CPUs"(以下"平均CPU使用率")の情報を見てみます。
1:20 pmに作成されたばかりなので、この時点では平均CPU使用率は11.77%しかありません。
CPU負荷をかける
［02:22 pm 時点]
ここからyesコマンドを3回打って負荷をかけてみます。
yes > /dev/null &
yesコマンドを止めたい時はjobsコマンドで実行中のジョブを確認しkillコマンドを使います。
Cloud Monitoringで確認
上記の作業中（CPU負荷なし〜CPUの負荷をかけた時間）のを、Cloud Monitoringで確認します。
2:30 pmにCPU使用率が186.91%となっています。
yesコマンドを3回打って負荷をかけたあたりと推測できます。
Cloud Monitoringで確認できる平均CPU使用率は、OSから見たCPU使用率ではなく、Hypervisorから取得した情報のようです。つまり、HypervisorがVSIに設定したbaselineを100%とした基準に対する利用率が表示されているということです。
ibm_is_instance_average_cpu_usage_percentage
which is the average percentage usage across all CPUs for the VSI is an indicator of resource utilization. This metric produced by the IBM Cloud VPC service and available in IBM Cloud monitoring is collected at the Hypervisor level and should be identified as a Golden signal for saturation.
(例)
2vCPUのVSI, baseline50%を利用しているとき、
Hypervisorがbaselineで制御しているので、使っているのは1vCPU分
→ Cloud Monitoringで表示される平均CPU使用率は100%
バーストしてパフォーマンスが2倍になった時、
Hypervisorのbaseline制御が開放されたので、使っているのは2vCPU分
→ Cloud Monitoringで表示される平均CPU使用率は200%
追加検証
本当にバースト機能が発動したのか確かめるため、burstable optionが有効でないprofileで同じサイズのVSI( "Compute | cx2-2x4")を注文し、同じようにコマンドで負荷をかけてみます。
まずはstress-ngを1分、その後yesを4回打って15分ほど放置してみました。
この時の平均CPU使用率をCloud Monitoringでも確認します。
平均CPU使用率が最大でも100%までしか上がっていませんでした。
burstable optionが有効でないProfileでは、同じコマンドで負荷をかけても100%までしか利用していないことがわかりました。
わかったこと
- burstable optionをつけていない通常のVSIでは、負荷をかけても平均CPU使用率が100%だったのに対し、burstable optionが有効なVSIでは、負荷をかけることで平均CPU使用率200%まで上がったことから、ホストのアイドルCPUを利用したバースト機能が発動したと考えられます。
- 負荷をかける前と後でlscpuでCPU情報を確認したところ、CPU数やクロック数などが変わっている訳ではありませんでした。2vCPUでオーダーしたのが4vCPUになる、などと性能が上がっている訳ではなく、選択したprofileのCPU数でVSIが作成され、その何%まで使えるかが、baselineで制御されているという仕組みになっていると考えられます。