負荷の急増に対応できる B シリーズ仮想マシンのサイズ
適用対象: ✔️ Linux VM ✔️ Windows VM ✔️ フレキシブル スケール セット ✔️ 均一スケール セット
B シリーズ VM は、さまざまなハードウェアの種類とプロセッサにデプロイできるため、競争力のある帯域幅割り当てが提供されます。 B シリーズは、第 3 世代 Intel® Xeon® Platinum 8370C (Ice Lake) プロセッサ、Intel® Xeon® Platinum 8272CL (Cascade Lake) プロセッサ、Intel® Xeon® 8171M 2.1GHz (Skylake) プロセッサ、Intel® Xeon® E5-2673 v4 2.3 GHz (Broadwell) プロセッサ、または Intel® Xeon® E5-2673 v3 2.4 GHz (Haswell) プロセッサ上で実行されます。 Web サーバー、概念実証、小規模なデータベース、開発ビルド環境など、CPU が常時最大限のパフォーマンスを発揮する必要のないワークロードでは、B シリーズ VM が最適です。 このようなワークロードでは通常、負荷の急増に対応できることがパフォーマンスの要件となります。 このサイズがデプロイされる物理ハードウェアを判断するには、仮想マシン内から仮想ハードウェアをクエリします。 B シリーズでは、購入する VM サイズに一定のベースライン パフォーマンスが約束されており、使用量がベースラインを下回る場合にはクレジットが蓄積されていきます。 VM にクレジットが蓄積されていると、アプリケーションで必要な CPU パフォーマンスが高まった場合にベースライン以上のパフォーマンス (上限: vCPU のパフォーマンスの 100%) を実現できます。
B シリーズには、次の VM サイズが用意されています。
Azure コンピューティング ユニット (ACU):状況に応じて異なります*
Premium Storage:サポートされています
Premium Storage キャッシュ: サポートされていません
ライブ マイグレーション: サポートされています
メモリ保持更新: サポートされています
VM 世代サポート: 第 1 世代と第 2 世代
高速ネットワーク:サポートされています \*\*
エフェメラル OS ディスク:サポートされています
入れ子になった仮想化: サポートされていません
\* B シリーズの VM はバースト可能であるため、ACU の数はワークロードとコアの使用状況によって異なります。
**高速ネットワークは、Standard_B12ms、Standard_B16ms、Standard_B20ms でのみサポートされます。
サイズ | vCPU | メモリ:GiB | 一時ストレージ (SSD) GiB | VM のベース CPU パフォーマンス | VM の最大 CPU パフォーマンス | 初期のクレジット | 1 時間に蓄積されるクレジット | 蓄積できるクレジットの最大値 | 最大データ ディスク数 | キャッシュが無効な場合の最大ディスク スループット: IOPS/MBps | バースト キャッシュが無効なディスクの最大スループット: IOPS/MBps1 | 最大 NIC 数 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Standard_B1ls2 | 1 | 0.5 | 4 | 5% | 100% | 30 | 3 | 72 | 2 | 160/10 | 4000/100 | 2 |
Standard_B1s | 1 | 1 | 4 | 10% | 100% | 30 | 6 | 144 | 2 | 320/10 | 4000/100 | 2 |
Standard_B1ms | 1 | 2 | 4 | 20% | 100% | 30 | 12 | 288 | 2 | 640/10 | 4000/100 | 2 |
Standard_B2s | 2 | 4 | 8 | 40% | 200% | 60 | 24 | 576 | 4 | 1280/15 | 4000/100 | 3 |
Standard_B2ms | 2 | 8 | 16 | 60% | 200% | 60 | 36 | 864 | 4 | 1920/22.5 | 4000/100 | 3 |
Standard_B4ms | 4 | 16 | 32 | 90% | 400% | 120 | 54 | 1,296 | 8 | 2880/35 | 8000/200 | 4 |
Standard_B8ms | 8 | 32 | 64 | 135% | 800% | 240 | 81 | 1944 | 16 | 4320/50 | 8000/200 | 4 |
Standard_B12ms | 12 | 48 | 96 | 202% | 1200% | 360 | 121 | 2909 | 16 | 4320/50 | 16000/400 | 6 |
Standard_B16ms | 16 | 64 | 128 | 270% | 1600% | 480 | 162 | 3888 | 32 | 4320/50 | 16000/400 | 8 |
Standard_B20ms | 20 | 80 | 160 | 337% | 2000% | 600 | 203 | 4860 | 32 | 4320/50 | 16000/400 | 8 |
1 B シリーズの VM では、ディスクのパフォーマンスをバーストでき、一度に最大 30 分間バーストを最大にしておくことができます。
2 B1ls は Linux でのみサポートされています。
ワークロードの例
出社/退社アプリケーションについて考えてみましょう。 このアプリケーションは、営業時間中 CPU バーストを必要としますが、営業時間外はそれほど多くの処理能力を必要としません。 この例のワークロードでは、64 GiB の RAM を搭載した 16vCPU 仮想マシンが効率的に機能する必要があります。
次の表は、1 時間あたりのトラフィック データを示しており、グラフは、そのトラフィックを視覚的に表現したものです。
B16 の特徴:
最大 CPU パフォーマンス: 16vCPU * 100% = 1600%
ベースライン: 270%
シナリオ | Time | CPU 使用率 (%) | 蓄積されるクレジット1 | 使用可能なクレジット |
---|---|---|---|---|
B16ms のデプロイ | デプロイ | デプロイ | 480 (初期クレジット数) | 480 |
トラフィックなし | 0:00 | 0 | 162 | 642 |
トラフィックなし | 1:00 | 0 | 162 | 804 |
トラフィックなし | 2:00 | 0 | 162 | 966 |
トラフィックなし | 3:00 | 0 | 162 | 1128 |
トラフィックなし | 4:00 | 0 | 162 | 1290 |
トラフィックなし | 5:00 | 0 | 162 | 1452 |
低トラフィック | 6:00 | 270 | 0 | 1452 |
従業員が出社 (アプリは 80% の vCPU を必要とする) | 7:00 | 1280 | -606 | 846 |
従業員が次々に出社 (アプリは 80% の vCPU を必要とする) | 8:00 | 1280 | -606 | 240 |
低トラフィック | 9:00 | 270 | 0 | 240 |
低トラフィック | 10:00 | 100 | 102 | 342 |
低トラフィック | 11:00 | 50 | 132 | 474 |
低トラフィック | 12:00 | 100 | 102 | 576 |
低トラフィック | 13:00 | 100 | 102 | 678 |
低トラフィック | 14:00 | 50 | 132 | 810 |
低トラフィック | 15:00 | 100 | 102 | 912 |
低トラフィック | 16:00 | 100 | 102 | 1014 |
従業員が退社 (アプリは 100% の vCPU を必要とする) | 17:00 | 1600 | -798 | 216 |
低トラフィック | 18:00 | 270 | 0 | 216 |
低トラフィック | 19:00 | 270 | 0 | 216 |
低トラフィック | 20:00 | 50 | 132 | 348 |
低トラフィック | 21:00 | 50 | 132 | 480 |
トラフィックなし | 22:00 | 0 | 162 | 642 |
トラフィックなし | 23:00 | 0 | 162 | 804 |
1 1 時間に累積されるクレジット/使用されるクレジットは ((Base CPU perf of VM - CPU Usage) / 100) * 60 minutes
に等しい。
16 台の vCPU と 64 GiB のメモリを搭載した D16s_v3 の場合、時間レートは 1 時間あたり 0.936 ドル (1 か月あたり 673.92 ドル) で、16 台の vCPU と 64 GiB のメモリを搭載した B16ms の場合、レートは 1 時間あたり 0.794 ドル (1 か月あたり 547.86 ドル) です。 結果として、15% の節約になります。
Q & A
Q:クレジットが不足した場合はどうなりますか?
A: クレジットを使い切ると、VM がベースライン パフォーマンスに戻ります。
Q: VM のベースライン パフォーマンスが 135% というのは、どういうことでしょうか?
A: 135% というのは、その VM サイズを構成する 8 つの vCPU により共有される数字です。 たとえば、アプリケーションで 8 個あるコアのうち 4 個を使用してバッチ処理を実行しており、その 4 つの vCPU の使用率がそれぞれ 30% であれば、VM の CPU パフォーマンスの合計は 120% になります。 つまり、ベースライン パフォーマンスとの差分となる 15% が、VM によりクレジット時間として蓄積されていくことになります。 逆に、(VM の CPU パフォーマンスの最大値は 800% であるわけですから) クレジットの残高があれば、同じ VM で 8 つの vCPU すべてについて 100% のパフォーマンスを使用することもできます。
Q:クレジットの残高や消費量を確認するにはどうすればよいでしょうか?
A: Credit メトリックでは、VM で蓄積されたクレジットの数を確認できます。ConsumedCredit メトリックでは、蓄積した CPU クレジットをどれだけ消費したかを確認できます。 この 2 つのメトリックは、ポータルの [メトリック] ウィンドウのほか、プログラムを使って Azure Monitor API 経由で確認できるようにする予定です。
Azure でメトリック データにアクセスする方法の詳細については、「Microsoft Azure のメトリックの概要」を参照してください。
Q:クレジットはどのように蓄積され、消費されますか?
A: VM によるクレジットの蓄積と消費のスピードは、VM がベース パフォーマンス レベルで実行されている場合にクレジットの蓄積量と消費量がいずれもゼロになるように設定されています。 VM の実行中にベース パフォーマンス レベルを下回っていればクレジットが増加し、ベース パフォーマンス レベルよりも多く CPU を使用していればクレジットが減少します。
例: 小規模な勤怠データベース アプリケーション用に B1ms サイズの VM をデプロイしました。 このサイズでは、アプリケーションでベースラインとして vCPU の最大 20% を使用できます。この場合、1 分あたりに利用または蓄積できるクレジットは 0.2 となります。
このアプリケーションは、従業員の勤務日の始めと終わり、具体的には AM 7:00 ~ 9:00 と PM 4:00 ~ 6:00 の間にそれぞれ負荷が大きくなります。 それ以外の 20 時間はこのアプリケーションをほとんど使用しないため、vCPU の使用量はわずか 10% にまで下がります。 このピーク外の時間には、クレジットを 1 分あたり 0.2 獲得しますが、0.1 しか消費しないため、1 時間に 0.1 x 60 = 6 クレジットが VM で蓄積されます。 つまり、ピーク外の 20 時間に合計 120 クレジットが蓄積されることになります。
これに対して、ピーク時間にはアプリケーションの vCPU 使用率が平均 60% になります。ピーク時間であっても 1 分あたり 0.2 のクレジットを利用できるのは変わりませんが、今度は 1 分間にクレジットを 0.6 を消費しているため、1 分あたり正味 0.4 クレジット、1 時間あたりでは 0.4 x 60 = 24 クレジットを消費することになります。 ピーク時間は 1 日 4 時間であることから、ピーク時間のクレジット使用量は 4 x 24 = 96 となります。
ピーク外の時間に獲得したクレジット 120 からピーク時に消費したクレジット 96 を差し引くと、1 日あたり 24 クレジットが残ります。この分は、別の事情でアクティビティが急増した場合に使用することができます。
Q:累積されるクレジットと使用されるクレジットを計算するにはどうすればよいですか?
A: 次の数式を使用することができます。
(VM の基本 CPU パフォーマンス - CPU 使用率) / 100 = 1 分あたりに蓄積または使用されるクレジット
たとえば、上記のインスタンスの場合、ベースラインは 20%です。CPU 使用率が 10% であれば、1 分あたりに蓄積されるクレジットは、(20%-10%)/100 = 0.1 になります。
Q: B シリーズでは、Premium Storage データ ディスクをサポートしていますか?
A: はい。B シリーズのどのサイズでも、Premium Storage データ ディスクをサポートしています。
Q: 再デプロイまたは停止/起動後、クレジットの残りが 0 に設定されるのはなぜですか?
A : VM が再デプロイされて VM が別のノードに移動すると、累計されたクレジットは失われます。 VM を起動/停止したが、同じノードにとどまっていれば、VM は 累積されたクレジットを保持します。 ノードで VM を新たに起動するたびに初期クレジットが取得されます (Standard_B8ms では 240)。
Q:サポートされていない OS イメージを B1ls にデプロイするとどうなりますか?
A: B1ls は Linux イメージのみをサポートしているため、他の OS イメージをデプロイすると最善のカスタマー エクスペリエンスが得られない可能性があります。
その他のサイズと情報
料金計算ツール: 料金計算ツール
ディスクの種類の詳細情報: ディスクの種類
次のステップ
Azure コンピューティング ユニット (ACU) を確認することで、Azure SKU 全体の処理性能を比較できます。