0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

【AWS】Windows Server EC2 T系、M系インスタンスの損益分岐点

Posted at

今回はEC2で一般用途向けとして提供されている2タイプ(T系とM系)のうち
運用コストの側面からどちらが最適であるのかを考察してみました。

背景:Windows Server EC2インスタンスをT系で数十台運用中、AWS営業からM系インスタンスへの変更を勧められた

各インスタンスタイプの特徴:
https://aws.amazon.com/jp/ec2/instance-types/

T系インスタンスの特徴

  • M系と比べ低価格

  • CPUクレジットという概念

CPUクレジットとは

  • T系インスタンスでは、他のインスタンスタイプとは違い、ベースラインと呼ばれるあらかじめ決められたCPU使用率が定義されています。
    その上で、ベースラインを超えたCPU使用率が使用できる状況をバースト機能と呼びます。
    そのバースト機能を使用している時に消費されるのが、CPUクレジットです。

CPUクレジットの消費タイプは以下二種類

  • Standardモード
    • CPUクレジット残高が0になると、CPU使用率はベースライン使用率以下までのみ使用可能。
  • Unlimitedモード
    • CPUクレジット残高が0になると追加課金が行われ、ベースライン以上の性能を維持することが可能。
       ※CPU高負荷持続時間によってはM系インスタンスの利用料金を上回る可能性あり

各インスタンスタイプのベースライン使用率

M系インスタンスの特徴

  • T系と比較して高価
  • どのサイトを見ても「バランスが良い」と書かれている

AWSの営業からも、T系インスタンスを用いた運用の中でCPUクレジットを使用するケースが多々あるようで
あればM系インスタンスへの移行を検討するように言われました。

ですが、改めて損益分岐点について調査してみたところ、CPUクレジットが一時的に消費されたり
ある基準までのCPU使用率であれば、M系インスタンスへ移行するよりT系での運用を続けたほうがコストメリットがある
という考えに至ったのでその経緯を紹介します。

Linux系EC2の損益分岐点について

Linux系EC2におけるT系、M系の損益分岐点となるCPU使用率についてはリファレンス上で公開されています。
image.png

上記によるとt3.xlargeを運用する際、CPU使用率が52.5%以上で推移し続けることがなければ継続課金が
行われている場合でもコストメリットがあると言えます。

Windows系EC2の損益分岐点について

当初Windows系EC2についてもLinux系と同じようにCPU使用率:52.5%がt3.xlargeの損益分岐点になると考えていました。

当初は。。。

(現にWindows系のリファレンスにはLinux系と同じ表が用意されています)
image.png

ですが後にWindows系EC2ではLinux系と比較して損益分岐点が異なることが判明しました。

以下が本題のWindows系EC2インスタンスにおける本当の損益分岐点を調査した結果になります。

前提条件

t3.xlarge (t3a.xlarge)
オンデマンドの時間単価 0.2912 USD/h
vCPU(コア数) 4
ベースライン CPU 使用率 40%

ひと月のインスタンスの稼働にかかるコスト

0.2912[USD/h] * 730[時間] = 212.576[USD]

獲得できる CPU クレジットの計算式

ベースラインCPU使用率[%] × vCPU 数[個] × 60[分]
0.4 × 4[vCPU] × 60[分] = 96[個]
96[個] × 730[時間] = 70,080[個]/月

消費するクレジット数の計算式(CPU使用率を60%ととして計算)

1時間平均のCPU使用率[%] × vCPU 数[個] × 60[分]
0.6 × 4[vCPU] × 60[分] = 144[個]
144[個] × 730[時間] = 105,120[個]

消費するクレジットと獲得するクレジットの差を計算すると

105,120[個] - 70,080[個] = 35,040[個]
→月間35,040[個]が課金対象として消費されているクレジットになります。

課金対象として消費されたクレジットに掛かるコストはvCPU 時間あたり 0.096 USD です。
(Windows および SQL Web を使用する Windows の場合、vCPU 時間あたり 0.096 USD)
つまり、1つの vCPU を1時間、100%で稼働させると 0.096 USD 掛かります。
「1つの vCPU を1時間、100%で稼働させる」ということは、
60個の CPU クレジットを消費することに相当します。

これらの条件から、過剰に消費された CPU クレジットに掛かるコストは
35,040[個] × 0.096/60[USD] = 56.064[USD]

月間総コスト

212.576[USD] + 56.064[USD] = 268.64[USD]

参考:
https://blog.serverworks.co.jp/t3-burstcost

M系インスタンス(m5.xlarge)との比較

オンデマンドの時間単価 0.432 USD/h
vCPU(コア数) 4

ひと月のインスタンスの稼働にかかるコスト

0.432[USD/h] * 730[時間] = 315.36[USD]

本当の損益分岐点

本来t3.xlargeをM系と比較した場合、損益分岐点となるCPU使用率は52.5%の
はずが、CPU使用率60%でもT系の方がコストメリットがあります。
→なぜ?

調査したところ、Linux用とWindows用でオンデマンドの時間単価が異なり、
WindowsのT系⇔M系の価格差に大きな開きがあることが判明しました。(52.5%はLinuxの損益分岐点)

■Linux
t3.xlarge 0.2176 USD
m5.xlarge 0.248 USD
価格差割合:
(0.248[USD] - 0.2176[USD]) / 0.248[USD] * 100 = 12.258%

■Windows
t3.xlarge 0.2912 USD
m5.xlarge 0.432 USD
価格差割合:
(0.432[USD] - 0.2912[USD]) / 0.432[USD] * 100 = 32.592%

ではWindowsの損益分岐点は? = CPU使用率:77%

60% 212.576[USD] + 56.064[USD] = 268.64[USD]
70% 212.576[USD] + 84.096[USD] = 296.67[USD]
77% 212.576[USD] + 103.718[USD] = 316.29[USD]★
80% 212.576[USD] + 112.128[USD] = 324.70[USD]
90% 212.576[USD] + 140.160[USD] = 352.74[USD]
100% 212.576[USD] + 168.192[USD] = 380.78[USD]

以上のことからよほどCPU使用率が高負荷で推移し続けるといったことがない限り
T系インスタンスの方がコストメリットがあるといえるのではないでしょうか。

消費クレジットとCPU使用率の監視は必須ですが。

そして改めてWindows系のリファレンスを見てみると、以下の記載が。。。
image.png
(AWSも中々攻めた売り出し方をするなぁと感じた次第でした。)

まとめ

日本語で書かれているブログ記事では、T系よりもM系を推奨する記事が多いですが、
運用コストを突き詰め、運用方法さえ固めればT系の方がコストメリットがあるケースは結構ありそう
というのが分かっていただけたかと思います。

参考
https://aws.amazon.com/jp/blogs/startup/burstable-performance-instances/

T系M系の損益分岐点
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html
https://blog.serverworks.co.jp/t3-burstcost

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?