SAP-C02-091 · セクション 10 / タスク 2.5

Rightsizing Strategy

CPU / Memory / ネットワーク / Storage / 使用率 / 適正サイズ化

適正サイズ化（Rightsizing）では、

CPU使用率が低い
↓
小さいインスタンスへ変更

のように、1つの指標だけで判断しません。

実際にインスタンスサイズを決めているのは、

CPU
メモリ
ネットワーク
ストレージ

のうち、

最も厳しい性能要件

である場合があります。

例えば、

CPU
25%

メモリ
55%

ネットワーク
85%

なら、CPUには大きな余裕があっても、ネットワーク性能を維持するために現在の規模が必要かもしれません。

適正サイズ化では、

各リソースの必要量
↓
サイズ変更後に利用できる能力
↓
すべての制約を満たせるか

を確認します。

ゴール

次のような判断ができるようにします。

CPUに余裕
+
メモリが上限付近
        ↓
CPUだけを見て縮小しない

CPU / メモリに余裕
+
ネットワークが上限付近
        ↓
ネットワーク性能が
サイズを決める可能性

必要なストレージ性能が高い
        ↓
その性能を利用できる
EC2構成を下限条件にする

つまり、

どのリソースが
最小構成を決めているか

を見つけます。

1. 適正サイズ化では「制約となるリソース」を探す

例えば現在のEC2インスタンスが、

CPU
20%

メモリ
25%

ネットワーク
90%

EBS
30%

だったとします。この場合、

平均すると
余裕が大きい

からといって縮小できるとは限りません。

実際のサイズを決めているのは、

ネットワーク性能

かもしれません。

適正サイズ化では、

最も余っているリソース

ではなく、

最も厳しい制約

を確認します。

2. パフォーマンス目標を満たす能力を残す

例えばCPU使用率が、

85%

でも、

必要なスループットを達成
+
レイテンシーも目標以内
+
必要な余裕も確保

できているなら、それだけでサイズ不足とは判断しません。

反対に、

CPU
40%

でも、

ネットワーク上限到達
+
レイテンシー悪化

なら、現在の構成は性能目標を満たしていない可能性があります。

したがって、

利用率
+
実際の性能目標

を組み合わせます。

3. CPU・メモリ・ネットワーク・ストレージを別々に評価する

1つのEC2インスタンスでも、

CPU能力
メモリ容量
ネットワーク性能
ストレージ性能

は別々の制約になります。

例えば、

CPU
余裕あり

メモリ
余裕あり

ネットワーク
不足

なら、

CPUを増やすこと

自体が目的ではありません。必要なのは、

ネットワーク要件を満たす構成

です。

4. CPUが制約になる場合

例えば、

CPU
95〜100%

メモリ
45%

ネットワーク
30%

ストレージ
40%

レイテンシー
目標超過

なら、CPU能力が性能を制限している可能性があります。

この場合は、

必要なCPU能力

を満たせる構成を評価します。

重要なのは、

CPU不足
↓
制約と無関係な
リソースだけを増やす

としないことです。

5. メモリが制約になる場合

例えば、

CPU
25%

メモリ
92%

ネットワーク
20%

なら、CPUだけを見ると縮小できそうに見えます。

しかし同じ比率のまま小さいサイズへ変更すると、

CPU
十分

メモリ
不足

になる可能性があります。

この場合、

必要なメモリ容量を維持しつつ
過剰なCPUを減らせる構成

を評価します。

つまり、

総サイズ

だけでなく、

CPU : メモリ

の比率も適正サイズ化の対象です。

6. メモリの観測値がなければ判断を保留する

CPU使用率だけが低くても、

メモリ使用率
不明

なら、

小さいインスタンスへ変更可能

とは確定できません。

サイズ変更を制限する可能性のある情報が不足しているためです。

適正サイズ化では、

必要なリソースの観測値がない
        ↓
縮小判断を確定しない

とします。

7. ネットワーク帯域がサイズを決める場合

EC2インスタンスには、インスタンスタイプごとにネットワーク性能があります。

例えば、

CPU
30%

メモリ
35%

ネットワークスループット
上限付近

なら、CPUやメモリだけを根拠に小さい構成へ変更すると、

利用可能なネットワーク性能
↓
さらに低下

する可能性があります。

この場合は、

必要なネットワーク帯域

を満たすことがサイズ変更の条件になります。

8. PPSがサイズを決める場合

ネットワークでは、

転送バイト数

だけでなく、

PPS
（Packets Per Second）

も制約になります。

例えば、

大量の小さいパケット

を処理するワークロードでは、総転送量がそれほど大きくなくても、

パケット処理性能

が上限に近づくことがあります。

そのため、

NetworkIn
NetworkOut

だけでなく、

NetworkPacketsIn
NetworkPacketsOut

も判断材料になります。

9. ストレージは容量と性能を分ける

ストレージでは、

保存容量

と、

IOPS
スループット

を別の制約として扱います。

例えば、

2 TiBのEBSボリューム

使用データ
400 GiB

でも、

高いIOPS
+
高いスループット

が必要なら、

容量使用率が低い
=
I/O性能も余っている

とは判断できません。

10. 既習のストレージ性能要件をサイズ変更の下限制約として使う

ストレージ性能そのものの選び方は既習です。

ここでは、

必要IOPS
+
必要スループット

を、

EC2をどこまで小さくできるか

の制約として利用します。

例えば、小さいEC2候補がCPU・メモリ要件を満たしていても、

必要なストレージ性能を
利用できない

なら、その候補は除外します。

11. 容量の余裕と性能の余裕は別に扱う

例えば、

保存容量
80%未使用

でも、

必要IOPS
高い

必要スループット
高い

場合があります。

反対に、

保存容量
多い

からといって、高いI/O性能が必要とは限りません。

したがって、

容量の適正化

と、

性能の適正化

を別々に考えます。

12. 1つの制約だけで最小サイズが決まることがある

例えば候補Aと候補Bがあるとします。

候補A

CPU
十分

メモリ
十分

ネットワーク
不足

候補B

CPU
十分

メモリ
十分

ネットワーク
十分

この場合、候補Aの方が小さくても選べません。

適正サイズ化では、

すべての必要条件を
満たす最小構成

を探します。

13. 全リソースを同じ割合で減らせるとは限らない

現在、

CPU
過剰

メモリ
適正

ネットワーク
適正

だとします。

同じインスタンスファミリーで1段階小さくすると、

CPU
適正

メモリ
不足

ネットワーク
不足

になる可能性があります。

この場合は、

サイズだけを小さくする

のではなく、

CPU
メモリ
ネットワーク

の比率がワークロードへ合う構成を評価します。

14. 同じファミリー内だけで考えない

現在の構成が、

CPU
20%

メモリ
85%

なら、同じ比率でCPUとメモリが減るサイズ変更は適さない可能性があります。

必要なのは、

余っているCPUを減らす
+
必要なメモリを維持する

ことです。

逆に、

CPU
95%

メモリ
30%

なら、CPU側へ比重を置いた構成が候補になります。

ここでのポイントは、

現在のサイズ

ではなく、

必要なリソース比率

です。

15. 水平スケーリングと1台あたりの適正サイズ化を分ける

Auto Scalingを使用していても、

1台あたりのインスタンスが
過剰に大きい

ことはあります。

例えば、

ピーク時
12台

各インスタンス
CPU 25%
メモリ 30%
ネットワーク 25%

なら、

台数を自動調整できている

ことと、

1台のサイズが適切

であることは別です。

1台あたりの能力

と、

必要台数

を分けて考えます。

16. 小さくすると別のリソースが次のボトルネックになる

例えば変更前が、

CPU
20%

メモリ
40%

ネットワーク
45%

だったとします。

サイズを小さくすると、

CPU
35%

メモリ
70%

ネットワーク
95%

になるかもしれません。

この場合、

CPUにはまだ余裕がある

としても、ネットワークが新しい制約になります。

適正サイズ化では、

現在のボトルネック

だけではなく、

変更後に
どのリソースが最初に限界へ達するか

も考えます。

17. 複数制約が同時に存在する場合

例えば、

CPU
70%

メモリ
82%

ネットワーク
85%

なら、どれか1つだけを基準にサイズを決めるのではなく、

CPU要件
かつ
メモリ要件
かつ
ネットワーク要件

をすべて満たす必要があります。

つまり適正サイズ化は、

最小CPU

最小メモリ

最小ネットワーク

を個別に確認し、

そのすべてを満たせる構成

を選ぶ問題です。

18. EBS容量を小さくしたい場合は新しいボリュームへ移行する

Amazon EBSでは、既存ボリュームのサイズをそのまま小さくすることはできません。

例えば、

現在
2 TiB

必要容量
500 GiB

だからといって、

既存2 TiB
↓
500 GiBへ直接縮小

することはできません。

容量を小さくしたい場合は、

必要な容量と性能を持つ
新しい小容量ボリュームを作成
↓
データを移行
↓
切り替え

という方法を評価します。

この場合も、

容量だけ

ではなく、

IOPS
+
スループット

の要件を維持します。

19. 代表的な判断表

観測状態	サイズを決める主な条件
CPU高、他に余裕	CPU能力
CPU低、メモリ高	メモリ容量
CPU・メモリ低、ネットワーク高	ネットワーク帯域
転送量に余裕、小パケット処理が多い	PPS
容量利用率低、IOPS高	IOPS
容量利用率低、スループット高	スループット
複数リソースが上限付近	すべての制約を満たす構成
1台あたり低利用、Auto Scalingあり	1台のサイズと台数を別々に評価

20. SAP-C02での判断フロー

現在の構成
        ↓

CPU / メモリ /
ネットワーク / ストレージ
の必要量を確認
        ↓

どのリソースが
最も厳しい制約？

 ├─ CPU
 │    ↓
 │  必要なCPU能力
 │
 ├─ メモリ
 │    ↓
 │  必要なメモリ容量
 │
 ├─ ネットワーク
 │    ↓
 │  必要な帯域幅 / PPS
 │
 └─ ストレージ
      ↓
    必要な容量
    IOPS
    スループット

        ↓

候補構成は
すべての条件を満たす？

        ├─ いいえ
        │    ↓
        │  候補から除外
        │
        └─ はい
             ↓
       より小さい候補を評価

        ↓

小さくしたとき
別のリソースが
新たな制約にならない？

        ├─ なる
        │    ↓
        │  その制約を満たす
        │  構成まで戻す
        │
        └─ ならない
             ↓
           適正サイズ候補

まとめ

適正サイズ化では、

最も余っているリソース

ではなく、

サイズを決めている
最も厳しいリソース要件

を探します。

CPUに余裕があっても、

メモリ
ネットワーク
PPS
ストレージ性能

のいずれかが上限に近ければ、単純な縮小はできません。

ストレージでは、

容量
IOPS
スループット

を分離します。

最終的には、

CPU条件
かつ
メモリ条件
かつ
ネットワーク条件
かつ
ストレージ条件

をすべて満たす範囲で、

過剰な能力を減らせる
最小の構成

を選択します。

主要AWS公式資料

AWS Certified Solutions Architect - Professional 試験ガイド
Amazon EC2 — インスタンスタイプ
Amazon EC2 — CloudWatchメトリクス
Amazon EBS — CloudWatchメトリクス
Amazon EBS — ボリュームの変更

理解確認

このページの内容を7問で確認します。

理解確認7問へ →