Growth / Usage Trendから将来障害を予測する

ゴール

現在の需要を確認
↓
時系列で利用増加を確認
↓
一時的な変動と継続的な傾向を分離
↓
現在のキャパシティと余裕を確認
↓
需要増加を将来へ延長
↓
どのリソースが
いつ頃飽和する可能性があるか評価
↓
将来の信頼性リスクとして残す

という判断ができるようにします。ここではAuto Scalingの設定、サービスクォータの引き上げ、リソース増強方法までは決めません。

前提

現在のパフォーマンスボトルネックの特定、Auto Scalingや自己修復の仕組み、Service Quotas、コスト予測などは既習として扱います。ここではそれらを再講義せず、現在正常なワークロードの利用増加から将来の信頼性リスクを予測することへ進みます。

1. 将来障害は「現在の障害」だけから探さない

現在CPUピーク65%、エラー率0%、p95レイテンシーが目標内でも、ピーク使用率が48% → 53% → 59% → 65%と増え続けているなら、現在は正常でも将来の飽和リスクは増加しています。

重要なのは現在値だけでなく、現在値がどちらへ、どの速度で動いているかです。

2. 単一時点ではなく時系列で見る

CPU使用率70%という1点だけでは、安定しているのか、急増しているのか、低下しているのかを判断できません。

現在 70%
ではなく
45% → 52% → 58% → 64% → 70%

のように時系列で確認します。同じ現在値でも、上昇中か横ばいかで将来リスクは異なります。

3. トラフィック増加を把握する

トラフィック増加では、平均リクエスト数だけでなく、同時接続数、トランザクション数、スループット、キュー投入量、ピーク時の需要などを時系列で確認します。

月平均 2,000 req/s は一定
しかしピークは
1月 6,000
2月 7,000
3月 8,500 req/s

平均が安定していることと、ピーク需要が安定していることは同じではありません。

4. データ増加も将来の障害要因になる

保存データ
1月 4.0 TiB
2月 4.6 TiB
3月 5.2 TiB
4月 5.8 TiB

実用上の容量 10 TiB

現在は空きがあっても、毎月約0.6 TiBの増加が継続すれば将来の容量不足を予測できます。保存データ量、テーブルサイズ、ログ量、オブジェクト数、バックアップ量、キュー滞留量などを対象にします。

5. 使用パターンと長期的な増加を分ける

時系列には長期的な増加傾向だけでなく、繰り返す使用パターンも含まれます。

月〜金 昼12時にピーク
土日 低負荷

毎月末 バッチ集中
毎週月曜日 アクセス増加
年末 季節ピーク

平均値だけでなく、繰り返し発生するピークを確認します。

6. 「一時的な急増」と「継続的な傾向」を分ける

通常 40%
障害発生日 95%
その後 40% / 41% / 39%

のような異常値1点を将来へ延長してはいけません。一方、50% → 57% → 64% → 71%のような継続的な増加は将来予測の材料になります。

7. キャパシティは「現在使用している量」ではない

現在需要 7,000 req/s
要求を満たせる最大 10,000 req/s
余裕 3,000 req/s

キャパシティとは、そのリソースや処理経路が要求を満たしながら処理できる範囲です。「まだ動いている」だけでなく、あとどの程度の需要増加を吸収できるかを見ます。

8. 余裕を確認する

余裕
=
キャパシティ
-
ピーク需要

例えば10,000 req/sの実用上の処理能力に対し現在ピーク8,000 req/sなら余裕は2,000 req/sです。毎月1,000 req/s増加しているなら、この余裕は急速に縮小します。

9. 飽和は100%だけを意味しない

飽和はCPU 100%だけではありません。接続可能数、ストレージ空き容量、キュー処理能力、ネットワーク帯域、IOPS、スループット、API処理能力など、要求を満たせる処理余裕がなくなる状態を見ます。

10. 飽和の前に劣化が始まることがある

最大処理可能量に達する前から、キュー増加 → レイテンシー増加 → タイムアウト増加 → エラーという劣化が始まることがあります。

物理的な最大値だけでなく、SLA / SLOを維持できる実用上のキャパシティを基準にします。

11. 傾向は「方向」と「増加速度」で見る

ピークトラフィック
1月 4,000
2月 4,200
3月 4,400
4月 4,600
→ 毎月約200 req/s増加

一方、4,000 → 8,000 → 3,800 → 7,900 → 4,100のような変動なら、単純な直線増加ではなく特定条件で発生するピークを調べます。

12. 予測は「予言」ではない

予測の目的は正確な障害日時を断定することではありません。

現在の傾向が続いた場合
どの時期に
どのキャパシティが
危険領域へ入るか

を見積もり、対策を始める必要がある時間軸を判断します。

13. 飽和までの時間を考える

飽和までの時間
≈
現在の余裕
÷
期間あたりの増加量

現在6 TiB、実用上の上限10 TiB、増加0.5 TiB / 月なら、余裕4 TiB ÷ 0.5 ≈ 約8か月です。増加率の変化、季節性、新サービス開始、データ削除などがある場合は単純な直線予測だけでは不十分です。

14. 既知の事業イベントも予測へ加える

2か月後 全国キャンペーン開始
予想トラフィック 現在ピークの2倍

のように将来イベントが確定している場合、過去の利用傾向だけを延長せず、過去の傾向＋既知の将来イベントを合わせて評価します。

15. 複数のキャパシティを別々に見る

どれか1つに余裕があるからといってワークロード全体に余裕があるとは限りません。利用増加によって最初に要求を満たせなくなる部分を特定します。

16. 現在値より「余裕が減る速度」を見る

リソースA
現在75%
過去6か月 74〜76%

リソースB
30% → 38% → 46% → 55%

現在値だけならAが高く見えますが、将来リスクではBの方が急速に余裕を失っている可能性があります。現在使用率と増加速度の両方を見ます。

17. 平均だけでなくピーク傾向を見る

月間平均 40% で変化なし

週次ピーク
65% → 72% → 78% → 85%

平均負荷が一定でもピークが増えていれば将来の飽和リスクがあります。平均、最大値、パーセンタイル、ピーク時間帯を用途に応じて確認します。

18. 傾向だけでなく「ピーク時間の長さ」も見る

90%以上の使用率
第1週 5分
第2週 15分
第3週 35分
第4週 70分

最大値が同じでも、高負荷状態が継続する時間が増加していることは重要な傾向です。

19. トラフィック増加とデータ増加を別々に考える

トラフィック 毎月5%増加
データ 毎月20%増加

ならデータ側が先にキャパシティへ近づく可能性があります。利用増加を1つの数字へまとめず、それぞれのキャパシティ消費を追います。

20. 将来障害は「いつ」「何が」不足するかで残す

何が、どの傾向で、どのキャパシティへ、いつ頃近づくかを残します。

21. 新しい実績で「最初に飽和する対象」を更新する

当初
ストレージ 飽和予測6か月後
注文API 飽和予測9か月後

最新実績
注文API余裕 2,400 req/s
増加 1,200 req/s / 月
→ 約2か月

最新実績から各対象の余裕と増加速度を再計算し、飽和までの時間と最も早く不足する対象を再評価します。単に予測値を書き換えるだけでなく、どのキャパシティリスクを先に扱う必要があるかを更新します。

22. サービスクォータ管理とは分ける

将来の制約接近が見つかっても、AWS Service Quotasの確認方法、クォータ引き上げ、固定クォータ回避、フェイルオーバー時のクォータ余裕までは扱いません。ここでは利用増加と傾向から将来キャパシティ不足が発生する場所を見つけることに限定します。

23. スケーリング設計とは分ける

3か月後のキャパシティ不足が予測されても、この時点でAuto Scalingを即決しません。スケーリング、アーキテクチャ変更、データレプリケーション、クォータ対応などの改善策選択は後続へ残します。

24. 判断フロー

現在は正常？
↓
時系列データを確認
↓
利用量は増加している？
↓
トラフィック増加 / データ増加 / その他の消費を確認
↓
現在のキャパシティと余裕を確認
↓
傾向 / 使用パターンを確認
↓
一時的な急増と長期傾向を分離
↓
増加速度を確認
↓
既知の事業イベントを加味
↓
飽和までの時間を見積もる
↓
将来の信頼性リスクとして記録
↓
新しい実績が得られたら
最初に飽和する対象を再評価
↓
後続の改善判断へ渡す

25. 混同ポイント

26. シナリオ：平均は安定しているがピークが増えている

月間平均CPU 40% で半年間ほぼ一定

週次ピークCPU
65% → 72% → 78% → 85%

85%以上になる時間
5分 → 20分 → 45分 → 90分

現在SLOを満たしていても、平均値だけで判断せず、ピークの高さと継続時間の傾向から将来の飽和リスクを評価します。

27. シナリオ：データ増加が先にキャパシティへ近づく

トラフィック 毎月3%増加
保存データ 毎月15%増加

保存データ 現在7.5 TiB
実用上の上限10 TiB

処理能力に十分な余裕があっても、データ増加の方が早く上限へ近づくなら、データ増加を主要な将来リスクとして追跡します。

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

単一障害点の除去、マルチAZ構成追加、Elastic Load Balancing導入、Auto Scalingのスケーリングポリシー設定、自己修復、データレプリケーション改善、DR戦略変更、AWS Service Quotasの引き上げ、信頼性改善戦略の最終選択、コスト予測は扱いません。

ここで完成させるのは、利用増加と使用傾向から、現在は発生していない将来のキャパシティ不足・飽和リスクを予測することです。

まとめ

現在の使用量
+
トラフィック増加
+
データ増加
+
使用パターン
+
現在のキャパシティ
+
傾向
↓
余裕
↓
飽和までの時間
↓
予測

重要なのは現在使用率が高いリソースではなく、余裕がどの速度で減っているかです。一時的な急増と継続的な増加を区別し、確定した将来イベントも加味します。

各キャパシティの余裕
+
最新の増加速度
↓
飽和時期を再計算
↓
最初に不足する対象を再評価

最終的には、どのキャパシティが、どの利用増加によって、いつ頃要求を満たせなくなる可能性があるかを将来の信頼性リスクとして残します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 3.4
• AWS Well-Architected フレームワーク — 信頼性の柱
• AWS Well-Architected — 設計原則「容量の推測をやめる」
• AWS Well-Architected — ワークロードリソースをモニタリングする
• AWS Well-Architected — サービスクォータと制約を管理する