RightsizingによるPerformance改善

前提

以下は既習として扱います。

• CPU・メモリ・ストレージ・ネットワークを別々の制約として確認する
• インスタンスファミリーやインスタンスサイズの選択
• EBS性能の選択
• パフォーマンスベースライン
• ボトルネックの特定
• AWS Compute Optimizerの基本的な役割

CPU不足ならどのインスタンスファミリーを選ぶか、ネットワーク不足ならどのインスタンスタイプを選ぶか、IOPS不足ならどのEBS構成を選ぶかという基本選択は再講義しません。

ここでは、既存構成を変更することが本当に性能改善へ直結するかを判断します。

1. Rightsizingは既存構成と必要能力の差を修正する

性能改善におけるRightsizingは、現在の能力をワークロード要件を満たす能力へ調整することです。

現在の能力
↓
ワークロード要件を満たす能力

変更方向は、拡大・縮小・リソース配分の変更のどれもあり得ます。大きいほどよい、小さいほどよい、ではなく、必要な性能を満たす能力へ合わせることが重要です。

2. 最初に「Rightsizingで解決する問題か」を判断する

性能目標を満たしていなくても、原因がリソース能力不足とは限りません。

API p95       900 ms
EC2 CPU       35%
メモリ         42%
ストレージ     余裕あり
ネットワーク   余裕あり
外部決済サービス 700 ms

この状態ではEC2を大きくしても外部サービスの700 msは直接短縮できません。

性能目標未達
↓
ボトルネック確認
↓
現在のリソース能力不足か

という順序で確認します。

3. 使用率は単独ではRightsizingの結論にならない

CPU平均が30%でも、それだけでは縮小できるとは判断できません。Rightsizingで比較するのは、現在の使用率・現在の能力・満たすべき負荷・性能目標です。

逆にCPUが高くても、要求された処理量、応答時間、処理期限をすべて満たしているなら、「CPU 90%だから必ず拡大」とも判断できません。

使用率は、ワークロード要件との関係で評価する値です。

4. 「現在の負荷」と「評価すべき負荷」を分ける

現在のトラフィック量だけでRightsizing候補を決めるわけではありません。

現在の負荷
2,000 req/s

設計上満たす必要がある負荷
4,000 req/s

なら、要求負荷を満たせる能力が必要です。ただし「将来負荷だから必ず大きくする」と暗記するのではありません。

Rightsizingで使用する負荷条件を、何を満たす必要があるかというワークロード要件から決めます。

5. 変更量は「不足している能力差分」から考える

今の構成では不足しているからといって、とにかく大幅に拡大するわけではありません。

例えばCPUが制約で、現在4 vCPU相当の能力に対して要求負荷時のCPU使用率が96%だったとします。同じ処理についてCPU 70%以下を変更候補の目安にし、CPU能力にほぼ比例して負荷を分散できると仮定すると、

必要CPU能力
≈ 4 × 96 / 70
≈ 5.5 vCPU相当

となります。この場合、6 vCPU相当以上の能力を持つ候補から評価を始められます。

この計算だけで最終構成を決めるのではなく、現在能力と必要能力との差分を定量化して候補を絞ることが目的です。

6. CPU・メモリ・ストレージ・ネットワークは「変更対象の特定」に使う

どの能力が不足しているかを判定する方法自体は既習です。ここでは、その結果をRightsizing対象の決定へ利用します。

CPU不足
→ CPU側の能力変更を検討

メモリ不足
→ メモリ側の能力変更を検討

ストレージ不足
→ ストレージ側の能力変更を検討

ネットワーク不足
→ ネットワーク側の能力変更を検討

他の能力に十分な余裕があるなら、すべてを同じ割合で増やす必要はありません。ただし変更候補は、変更対象以外の必須要件も引き続き満たす必要があります。

7. メモリ能力もワークロード要件から必要量を決める

メモリのRightsizingでも、平均メモリ使用率だけから構成を決めません。

基本使用量      8 GiB
1ジョブあたり   6 GiB
同時実行要件    8ジョブ

8 GiB + 6 GiB × 8
= 56 GiB

この例では、今の平均使用率よりも、要求された同時実行数を満たすために1台あたり何GiB必要かから必要能力を算出します。

8. ComputeとStorageのRightsizingを分ける

既存EC2アプリケーションで、CPU 30%、メモリ45%、ネットワークには余裕があり、問題発生時間にVolumeIOPSExceededCheck = 1、EC2側EBS能力には余裕があるとします。

この場合の変更対象はEC2全体ではなく、EBS側のIOPS能力です。

アプリケーション全体を大きくするのではなく、実際に不足している能力をRightsizingします。

9. ネットワーク遅延とネットワーク能力不足を混同しない

ネットワーク関連の性能問題でも、すべてがインスタンスのネットワーク能力不足とは限りません。

インスタンスのネットワーク使用量
性能上限の35%

CPU / メモリ
余裕あり

遠隔APIまでのRTT
180 ms

アプリケーション処理
20 ms

現在のインスタンスのネットワーク能力に余裕があり、遅延の大部分が遠隔通信によるものなら、インスタンスのRightsizingでは直接短縮できない遅延です。

10. ワークロード要件が変われば必要能力も再計算する

既存構成が適切だったとしても、同時実行数、1処理あたりの必要メモリ、要求スループット、性能目標などが変更された場合は必要能力も変わります。

以前適切だったサイズを維持することでも、「要件が増えたから必ず1段階大きくする」ことでもありません。

変更されたワークロード要件から必要能力を再計算し、現在能力との差分を確認することが重要です。

11. AWS Compute Optimizerは「変更候補」の入力として使う

AWS Compute Optimizerは既存リソースの使用状況を分析し、Rightsizing候補を提示できます。ただし、推奨候補をそのまま採用するわけではありません。

要求負荷、処理期限、最低メモリ、必要なネットワーク能力、必要なストレージ性能など、システム固有のワークロード要件を満たすか確認します。

AWS Compute Optimizerは候補を絞るための情報として使い、最終判断はワークロード要件との比較で行います。

12. Rightsizingの適用を止める条件

リソース能力に余裕があり、性能目標未達の原因が外部サービス待ち、リージョン間通信、データベースロック、ホットキー、直列処理、アプリケーションコードなどにある場合は、Rightsizing以外を優先します。

より大きなインスタンスへ変更しても、支配的な待ち時間を短縮できない可能性があります。

重要なのは、Rightsizing可能かどうかではなく、Rightsizingが現在のボトルネックへ効くかどうかです。

13. 高い使用率だけで拡大を決めない

要求された最大負荷で、CPU 88%、メモリ55%、p95 240 ms、性能目標300 ms以下、キュー滞留なし、スロットリングなしだったとします。

CPU使用率は高めですが、要求負荷と性能目標は満たしています。この状態だけから「CPU 88%だからもっと大きい構成」と決めることはできません。

Rightsizingの目的は特定の使用率へ揃えることではなく、ワークロード要件を満たす能力へ合わせることです。

14. 判断フロー

性能目標未達
↓
ボトルネック特定済み
↓
リソース能力不足か

├─ No
│   ↓
│ Rightsizingを主改善策にしない
│
└─ Yes
    ↓
  不足している能力を確認
    ↓
  ワークロード要件から必要能力を算出
    ↓
  現在能力との差分を確認
    ↓
  必要能力を満たす候補へ変更

Rightsizing後の実測比較は次の教材で扱います。

15. このページで扱わないこと

ここでは、マネージドサービスへの置換や新しい技術への移行は扱いません。また、改善候補を実際に負荷試験し、変更前 / 変更後を比較して最終採用する手順も後続へ残します。

ここでは、Rightsizingを適用するか判断し、必要な能力変更を決めるところまでを扱います。

まとめ

Rightsizingによる性能改善では、高使用率だから拡大、低使用率だから縮小、とは判断しません。

満たすべきワークロード要件

実測使用率

現在の能力

特定済みボトルネック

を確認し、リソース能力不足が性能目標未達の原因である場合に、現在の能力から必要な能力までの差分をRightsizingします。

逆に、その能力を変更しても支配的な遅延が変わらないなら、Rightsizingを主要な改善策にしないことも重要な判断です。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド
• AWS Compute Optimizer User Guide — EC2 instance metrics
• AWS Compute Optimizer User Guide — Viewing EC2 instance recommendations
• AWS Compute Optimizer User Guide — Rightsizing recommendation preferences