Performance問題から改善戦略を選択する

ゴール

KPI未達
↓
ボトルネックを確認
↓
制約の種類を分類
↓
スケーリング
適正サイズ化
エッジ
マネージドサービス
から対応する改善軸を選択
↓
必要なら複数の改善軸を組み合わせる
↓
測定結果で妥当性を確認

各技術の仕組みを再講義せず、どの性能問題に、どの改善軸を適用するかを完成させます。

前提

• ビジネス要件をSLA / KPIへ変換する
• 正常時との比較からボトルネックを特定する
• コンピューティングアーキテクチャを改善する
• グローバル利用者向けの遅延区間を改善する
• CPU、メモリ、ストレージ、ネットワークを適正サイズ化する
• マネージドサービスや新しい技術への置換を評価する
• 改善候補をベンチマークや負荷テストで検証する

ここでは、それらを入力として使用します。

1. 改善戦略ではなくKPIから始める

最初にどのサービスを使うかを決めるのではなく、どのKPIが、どの条件で未達なのかを確認します。

要求 10,000 req/s
実測 7,000 req/s

要求 p95 150 ms以下
実測 p95 320 ms

同じ「性能問題」でも、未達している指標によって改善対象は異なる可能性があります。

2. KPI未達だけでは改善策を決めない

例えばp95レイテンシー500 msという値だけを見ても、CPU処理、処理台数、遠隔リージョンとの通信、データ基盤の需要追従、外部依存先など複数の原因が考えられます。

KPI未達
↓
測定
↓
ボトルネック特定
↓
改善戦略

KPIから原因を推測して改善策へ飛ばず、測定されたボトルネックを介して選びます。

3. スケーリングを選ぶのは「総処理能力」が不足するとき

スケーリングは、ワークロード全体として必要な処理能力を確保できないときの改善軸です。

1台ごとの処理は正常
複数台へ分散可能
ピーク時に要求件数が増加
↓
固定台数では全体の処理能力不足

この場合は、単一リソースのサイズではなく、需要に対して必要な総キャパシティを用意できるかを見ます。

4. 適正サイズ化を選ぶのは「既存リソースの能力差」が問題のとき

適正サイズ化は、現在のリソース能力と必要なリソース能力の差を修正する改善軸です。

要求負荷は一定
1ワーカーのCPUが継続的に飽和
処理能力とCPU能力の関係は確認済み
↓
必要CPU能力 - 現在CPU能力

逆にCPU、メモリ、ストレージ、ネットワークに余裕があるなら、単に大きなリソースへ変更しても根本改善にならない可能性があります。

5. スケーリングと適正サイズ化を混同しない

各ワーカーには余裕があるが台数不足でキューが増えるなら総容量側を見ます。必要な並列数は足りるが各ワーカーのCPU能力が不足するなら個々の能力側を見ます。

6. エッジを選ぶのは「利用者との距離や配信経路」が制約のとき

グローバル利用者がいるだけでエッジと決めるのではなく、遅延区間を確認します。

利用者 → アプリケーション
ネットワーク往復 180 ms
アプリケーション処理 20 ms

この場合は通信距離やネットワーク経路が主要な制約なので、コンテンツを利用者へ近づける、AWSネットワークへ早く取り込む、処理地点を近づけるなどを検討できます。

一方、通信20 ms・アプリケーション処理400 msなら、エッジだけを追加しても主要な遅延は残ります。

7. マネージドサービスを選ぶのは「技術や運用モデル自体」が制約のとき

需要増加
↓
担当者が手動変更
↓
データ再配置
↓
40分後に利用可能

現在の技術が持つキャパシティ管理方式そのものが性能維持を妨げる場合、同じ技術をさらに大きくするより、異なるスケーリングモデルを持つマネージドサービスや新技術への置換が候補になります。

重要なのはマネージドであることではなく、現在のボトルネックを生んでいる技術特性を変えられることです。

8. 改善軸は「症状」ではなく「制約」に対応させる

総処理能力不足
→ スケーリング

個々の能力不足
→ 適正サイズ化

距離 / 配信経路
→ エッジ

技術・管理モデル
→ マネージドサービス / 新技術

同じレイテンシー悪化でも原因が違えば改善軸は異なります。同じ症状 = 同じ改善戦略ではありません。

9. 1つの改善策ですべてを解決しようとしない

独立した複数のボトルネックが存在する場合があります。

ピーク時のオリジン総処理能力不足
+
遠隔利用者のネットワーク遅延

オリジンの処理能力 → スケーリング
距離 / 配信経路       → エッジ

1種類の改善だけに無理にまとめず、ボトルネックごとに対応する改善軸を選びます。

10. 複数戦略を使う場合も「全部追加」ではない

スケーリング、適正サイズ化、エッジ、マネージドサービスをすべて適用するわけではありません。それぞれについて、この変更はどのボトルネックを解消するのかを説明できる必要があります。

CPUに余裕がありネットワーク距離が主要遅延なら、インスタンスサイズ拡大には主要ボトルネックとの対応関係がありません。

11. KPIを満たすことを改善戦略の出口にする

目的はCPUを下げることでも、新しいAWSサービスを使うことでもなく、要求された性能を満たすことです。

p95 500 ms
↓
350 msまで改善

KPI 300 ms以下
→ まだ不十分

改善戦略の適用、メトリクス改善、KPI達成までをつなげます。

12. 「最も新しい技術」を選ぶページではない

新しいインスタンスファミリーやマネージドサービスが存在しても、新しいこと自体は最適性を保証しません。最大スペックや最大スループットを選ぶことも目的ではありません。

現在のボトルネック
+
未達KPI
+
改善後の検証結果

を選択基準にします。

13. 検証済みの証拠を選択へ戻す

改善候補を測定して、KPI達成かつ許容できない回帰なしなら、性能面での推薦根拠になります。

一方、改善はしたがKPI未達なら、戦略自体が不足しているか、別のボトルネックが残っている可能性があります。

改善はした
しかしKPI未達
↓
同じ改善を自動的に続けない
↓
残っているボトルネックへ戻る
↓
必要なら次の改善戦略を選択

14. 改善戦略対応表

症状から技術へ直結させるのではなく、測定された制約 → 改善メカニズムとして使用します。

15. 判断フロー

性能KPI未達
↓
ボトルネックは特定済みか
├─ いいえ → 測定・調査へ戻る
└─ はい
    ↓
制約は何か
├─ 総処理能力 / 需要追従 → スケーリング
├─ 個々のリソース能力差 → 適正サイズ化
├─ 距離 / 配信経路 → エッジ
└─ 技術 / 管理モデル → マネージドサービス / 新技術
↓
複数のボトルネックがある？
├─ はい → 対応する戦略を組み合わせる
└─ いいえ → 単一改善候補
↓
既存の検証結果を確認
↓
KPI達成？
├─ いいえ → 残存ボトルネックを再確認
└─ はい → 性能改善戦略として推薦

16. 混同ポイント

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

ここでは、ボトルネックを最初から調査する詳細手順、Amazon EC2 Auto Scalingの設定方法、EC2 FleetやPlacement Groupの詳細、Amazon CloudFront・AWS Global Accelerator・AWS Wavelengthの再説明、CPUやメモリの必要量計算、マネージドサービスの個別機能比較、ベンチマークや負荷テストの実施方法、可用性・冗長化・障害ドメイン、コスト最適化、セキュリティ改善は扱いません。

ここで完成させるのは、既に特定された性能ボトルネックとKPIを使い、適切な改善戦略へ接続することです。

まとめ

KPI未達
↓
ボトルネック
↓
制約の種類
↓
対応する改善軸
↓
検証結果
↓
KPI達成

総処理能力 / 需要追従 → スケーリング
個々のリソース能力差 → 適正サイズ化
距離 / 配信経路 → エッジ
技術 / 管理モデル → マネージドサービス / 新技術

独立した複数のボトルネックがある場合は、それぞれに対応する改善軸を組み合わせます。最終的な判断基準は、測定されたボトルネックを解消し、要求されたKPIを満たせるかです。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 3.3
• AWS Well-Architected フレームワーク — パフォーマンス効率
• PERF01 — ワークロードに適したクラウドリソースとアーキテクチャの選択
• PERF01-BP07 データ駆動型のアプローチでアーキテクチャを選択する