Spot・Scaling・RightsizingによるCost改善

ゴール

既存ワークロードについて、

現在の構成
+
ワークロードパターン
+
中断許容度
↓
どのコスト要因が残っているか
↓
適正サイジング
Auto Scaling
Spot Instances
↓
必要なら組み合わせる

という流れで、コスト改善策を判断できるようにします。

適正サイジング、Auto Scaling、Spot Instancesの基本的な仕組みや個別の選択方法は前提知識とします。

ここでは、既存環境を複数のコスト軸へ分解し、まだ残っている改善余地を特定することに集中します。

1. 3つの改善軸を分けて考える

コンピューティングコストでは、少なくとも次の3つを分離して確認します。

例えば、20台のEC2インスタンスを常時稼働しているからといって、

20台
↓
台数が多い
↓
Auto Scaling

とすぐ判断してはいけません。

実際には、

各インスタンスが大きすぎる

のか、

ピーク時だけ20台必要で
通常時は5台でよい

のか、

一部の処理だけは
中断を許容できる

のかを分けて確認します。

複数の条件が同時に成立することもあります。

2. 適正サイジングは独立したコスト軸として残す

過剰能力の候補をどのように発見するかは、ここでは扱い直しません。

このページで重要なのは、

必要な台数

と、

1台あたりに必要な能力

を別のコスト軸として扱うことです。

例えば、

需要に合わせて
稼働台数を増減できている

としても、

稼働している1台ごとに
過剰能力が残る

可能性があります。

逆に、各インスタンスが適切なサイズでも、

低需要時に
不要な台数を維持

していれば別の改善余地があります。

したがって、1つの軸を改善しただけで、他のコスト軸まで改善済みとは判断しないことが重要です。

この適正サイジング軸は、後述する複合シナリオの中で他の改善軸とまとめて判断します。

3. Auto Scalingは「必要以上の稼働容量」を減らす

インスタンスサイズが適切でも、ピーク時に必要な台数を常時維持していれば、需要が少ない時間帯に余剰容量が発生します。

例えば、

昼間
必要 10台

深夜
必要 2台

なのに、

24時間
10台固定

で運用している場合です。

この状態では1台あたりのサイズとは別に、

需要増加
↓
必要な容量を増やす

需要減少
↓
不要な容量を減らす

という稼働容量の軸に改善余地があります。

固定容量
10 ───────────────

実際の需要
2 ── 4 ── 10 ── 6 ── 2

        ↓

需要へ追従する容量
2 ── 4 ── 10 ── 6 ── 2

需要へ容量を追従させることで、ピーク用キャパシティを低需要時にも維持するコストを減らせます。

一方、需要が一日を通してほぼ一定なら、この軸だけでは大きな改善余地がない場合があります。

重要なのは、変動するワークロードパターンと、実際に維持している稼働容量の差です。

4. 中断許容度はSpotによる改善余地の上限を決める

Spot Instancesについて、ここで改めて「どの処理ならSpotを使えるか」を判定し直すことはしません。

ここで見るのは、既存ワークロード全体のコストのうち、Spotによって改善できる可能性がある範囲がどの程度残っているかです。

例えば、同じ100単位のコンピューティング使用量を持つ2つのワークロードがあるとします。

ワークロードA
中断許容度のある使用量 80%

ワークロードB
中断許容度のある使用量 20%

インスタンスサイズや稼働容量など、ほかの条件が同じなら、

Spotによる改善余地

A
████████░░ 80%

B
██░░░░░░░░ 20%

となり、Spotによって見直せるコスト範囲はAの方が大きくなります。

ここで重要なのは、

中断許容度がある
↓
必ずそのすべてをSpotへ変更

ではありません。

中断許容度から分かるのは、Spotによるコスト改善を検討できる範囲の上限です。

そのため、

現在の総使用量
×
中断を許容できる割合
↓
Spotによる
コスト改善候補範囲

という視点で評価できます。

中断許容度が低いワークロードでは、適正サイジングやAuto Scalingに大きな改善余地があっても、Spotによる改善余地は限定されます。

反対に、中断許容度の高いワークロードでは、他のコスト軸を改善した後でも、Spotという別の軸に比較的大きな改善余地が残る可能性があります。

つまり中断許容度は、Spot利用の可否を二択で判定するだけではなく、Spotが既存コスト全体のどの程度まで作用し得るかを評価するための制約として扱います。

5. ワークロードパターンから改善軸を分離する

3つの改善軸は、ワークロードの状態によって効果が異なります。

例えば、

各インスタンスは適切
+
必要台数が2〜20台で変動
+
20台固定

なら、稼働容量の軸に改善余地があります。

一方、2つの環境で総使用量が同程度でも、

環境A
中断許容度あり 80%

環境B
中断許容度あり 20%

であれば、Spotによって改善を検討できるコスト範囲は同じではありません。

さらに1台あたりにも過剰能力が残っていれば、それは別の改善軸として扱います。

6. 1つの改善策で別のコスト要因は消えない

3つの改善軸を混同すると、一部のコストだけを下げて他の無駄を残すことがあります。

Spotだけ適用

大きすぎるインスタンス
+
Spot

としても、1台あたりの過剰能力そのものは残ります。

適正サイジングだけ適用

適切なサイズ
+
ピーク台数を24時間固定

では、低需要時間の余剰台数が残ります。

Auto Scalingだけ適用

需要に合わせて台数変更
+
各インスタンスに過剰能力が残る

なら、稼働している1台ごとのコスト要因が残ります。

したがって、

1台の能力
↓
過剰が残っているか

稼働容量
↓
需要へ追従しているか

中断許容度
↓
Spotが作用できる
コスト範囲はどの程度か

を別々に確認します。

7. 3つの改善軸は組み合わせられる

例えば動画変換ワーカーを30台固定で運用しているとします。

調査結果が次の状態だったとします。

現在
30台固定

1ワーカーの能力
現在より小さい構成でも要件を満たす

必要ワーカー数
時間帯によって
5〜30台相当

変換ジョブ
中断されても再試行可能

この環境には3種類の改善余地があります。

1台あたりに過剰能力
↓
適正サイジング

5台でよい時間にも30台稼働
↓
Auto Scaling

中断可能な容量
↓
Spot Instances

したがって、

適切なサイズのワーカー
+
需要に応じた稼働台数
+
中断を許容できる容量へのSpot

を組み合わせて評価できます。

ここで重要なのは、「SpotにしたからAuto Scalingは不要」「Auto Scalingしたから適正サイジングは不要」ではないという点です。

それぞれ異なるコスト要因を修正しています。

8. コスト削減後も要件を維持する

コスト改善では、削減額だけを最大化してはいけません。

コスト削減
+
性能
+
可用性
+
処理期限
+
中断許容度

を同時に確認します。

例えば、低需要時に容量を減らしても性能要件を満たせなければ、そのスケールインは適切ではありません。

同様に、中断許容度から求めた範囲はSpotによる改善余地の上限であり、その割合すべてを無条件にSpotへ変更することを意味しません。

判断は、

安いか

ではなく、

要件を満たしたまま
不要なコスト要因を
取り除けるか

で行います。

SAP-C02での判断

問題文でコストの高いEC2環境が出てきたら、1つのサービス名へすぐ飛びつかず、残っているコスト要因を分解します。

1台あたりに
過剰能力が残る？
        ↓
適正サイジング軸

需要と稼働台数に
差がある？
        ↓
Auto Scaling軸

中断許容度のある使用量は
全体のどの程度？
        ↓
Spot軸

複数に該当する？
        ↓
組み合わせる

特に、

Spot
=
不要な台数を減らす仕組み

でも、

Auto Scaling
=
1台を適切なサイズにする仕組み

でもありません。

どのコスト要因を変える施策なのかを区別し、すでに改善済みの軸と未改善の軸を切り分けることが決定打になります。

まとめ

適正サイジングは、1台あたりに残っている過剰能力という独立したコスト軸です。

Auto Scalingは、需要に対して必要以上に維持している稼働容量の軸を改善します。

Spot Instancesは、中断許容度のある使用量に対して実行コストを改善する候補です。

ワークロードパターンが変動するなら、需要と稼働容量の差を確認します。

中断許容度は、Spotを使用できる処理を再判定するだけではなく、既存コスト全体のうちSpotによる改善を検討できる範囲の上限として評価できます。

3つの改善軸は排他的ではなく、異なるコスト要因が同時に存在する場合は組み合わせて評価します。

最終的な判断基準は、

要件を維持したまま
どの不要なコスト要因が
まだ残っているか

です。