リソース予測・トラフィック予測とは何か – キャパシティ管理として設計する

IT インフラの運用では、「リソース予測」や「トラフィック予測」という言葉が使われることがあります。言葉だけを見ると、高度な分析基盤で未来を精密に予測するような印象を受けるかもしれません。

しかし実務で重要なのは、未来の値を当てることそのものではありません。重要なのは、現在の利用状況と過去の傾向をもとに、将来どのリソースが、いつ、どの程度不足しそうかを把握し、必要な判断に接続することです。

予測は目的ではありません。予測は、判断するための材料です。

リソース予測とは何か

リソース予測とは、サーバー、ネットワーク機器、ストレージ、仮想基盤、クラウド環境などにおける各種リソースの将来利用量を見積もることです。

• CPU 使用率、メモリ使用率、ディスク使用量
• ストレージ容量、IOPS、ログ出力量
• ネットワーク帯域、セッション数、コネクション数
• VPN 同時接続数、ライセンス使用数
• クラウド利用料金、SaaS 利用量

例えば、ストレージ使用量が毎月一定量ずつ増えている場合、現在の空き容量と増加傾向から、何か月後に実用上限へ到達するかを見積もれます。

ただし、「将来 85% に到達する」という数値だけでは不十分です。その状態が問題なのか、いつ誰が何を判断するのかまで決めて初めて、リソース予測は実務上の意味を持ちます。

トラフィック予測とは何か

トラフィック予測とは、ネットワークやアプリケーションに流れる通信量や通信特性の将来傾向を見積もることです。

• bps、pps、request/sec、connection/sec
• 同時セッション数、NAT セッション数、Firewall セッション数
• VPN 通信量、SaaS 向け通信量、拠点間通信量
• DNS クエリ数、API アクセス数、ログ出力量

ここで重要なのは、単なる通信量だけを見ないことです。同じ 1Gbps の通信でも、大容量ファイル転送なのか、小さな API 通信が大量に発生しているのかで、消費するリソースは変わります。

大容量ファイル転送では帯域が支配的になるかもしれません。一方、小さな API 通信が大量に発生する場合は、帯域使用率が低くても、PPS、CPS、セッション数、CPU、ログ出力量が問題になることがあります。

トラフィックとリソースは分離できない

リソース予測とトラフィック予測は、説明上は分けられます。しかし実務上は完全には分離できません。トラフィックはリソースを消費する要因であり、トラフィックそのものもリソースの一種だからです。

対象	トラフィックが消費するもの
ネットワーク機器	帯域、PPS、queue、制御プレーン処理
Firewall	同時セッション数、CPS、NAT table、CPU、ログ出力
Load Balancer	connection、TLS 処理、バックエンド転送、ヘルスチェック
アプリケーション	request/sec、DB 接続、worker、queue、レスポンスタイム

つまり、本来見るべきなのは「通信量が増えるか」だけではありません。ワークロードの変化が、各コンポーネントのリソースをどのように消費し、どの時点で実用上限に近づくのかです。

コンポーネントごとに主軸能力は違う

リソース予測では、すべてのメトリクスを横並びに扱わないことが重要です。各コンポーネントには、そのコンポーネントが本来提供している主軸能力があります。

コンポーネント	主軸能力の例
ネットワーク機器	トラフィック転送能力、経路制御、収束性
サーバー	計算処理能力、メモリ、プロセス実行能力
ストレージ	容量、I/O 処理能力、レイテンシ
Firewall	セキュリティ機能を適用した通信処理能力
Load Balancer	接続処理、TLS 終端、バックエンド分散

同じ CPU 使用率でも、ネットワーク機器、ストレージ、Firewall、アプリケーションサーバーでは意味が違います。CPU 使用率という数字を見る前に、その装置が何を提供していて、その能力を支える従属リソースは何かを整理する必要があります。

必要なのは限界の定義である

予測を意味のあるものにするには、対象ごとの限界を定義する必要があります。ここでいう限界とは、リソースが 100% に達する地点ではありません。

• サービス品質を維持できなくなる地点
• 安定運用できなくなる地点
• 増強や設計変更を検討すべき地点
• リスクを受容するか対応するかを判断すべき地点

CPU 使用率が 80% でも問題ないシステムはあります。逆に、CPU 使用率が 30% でも、I/O 待ちや単一スレッド処理の詰まりで性能劣化している場合もあります。

したがって、「80% を超えたら危険」と決めるだけでは粗すぎます。理論上限、実用上限、安全率、劣化開始点、破綻点、監視すべきメトリクス、複合判定条件、対応アクションを定義する必要があります。

閾値と計算式は設計上の決めである

閾値や計算式は自然に決まるものではありません。CPU 使用率を 80% で警告にするのか、70% で警告にするのか。ストレージ使用率を 85% で実用上限とするのか、90% まで許容するのか。平均を見るのか、ピークを見るのか、p95 を見るのか。これらはすべて設計上の決めです。

もちろん、過去の障害、性能試験、ベンダー情報、運用経験を根拠にすべきです。しかし最終的には、「このシステムではこの状態を危険とみなす」という判断境界を定義する必要があります。

閾値とは単なる数値ではありません。運用上の判断境界です。

計算式も同じです。現在使用量、実用上限、直近の増加率から到達見込み日数を出す計算は有用ですが、それは「過去の増加傾向が今後も続く」という前提に基づくモデルです。現実そのものではありません。

未来予測は過去傾向の延長にすぎない

実務上の多くのリソース予測は、過去メトリクスの傾向をもとにした見積もりです。ストレージ使用量が直近 30 日間で毎日 100GB 増えており、実用上限までの残容量が 1.5TB なら、15 日後に上限へ到達すると見積もれます。

この計算は有用です。しかし未来の真実ではありません。以下のような変化があれば、予測は簡単に外れます。

• システム更改、大規模リリース、拠点追加
• ユーザー数増加、キャンペーン、業務イベント
• バックアップ方式変更、ログ出力量変更
• 経路変更、障害迂回、設定変更

予測値は絶対視するものではなく、判断材料の一つとして扱う必要があります。予測の前提が変わった時に、再計算し、説明できる状態にしておくことが重要です。

予測より前に必要なのは判定ロジック

リソース予測やトラフィック予測で最初に必要なのは、高度な予測モデルではありません。まず必要なのは判定ロジックです。

• 実用上限を定義する
• 現在使用量を取得する
• 直近の増加率を計算する
• 残容量や残能力を算出する
• 到達見込み日数を出す
• 一定期間内に上限へ到達する場合に警告する

これは高度な機械学習ではありません。しかし、実務上は十分に有効です。特にストレージ容量、ログ容量、ライセンス使用数、クラウド利用料金のようなものは、まずこの程度のモデルから始める方が現実的です。

ネットワークや Firewall では、単一の値ではなく、帯域、PPS、CPS、同時セッション数、CPU、packet loss、latency、queue drop などを組み合わせて危険状態を判定します。

既存ツールで実現できる範囲は多い

リソース予測やトラフィック予測というと、新しいシステム開発が必要に見えることがあります。しかし、実際には Grafana、Prometheus、Zabbix、Datadog、CloudWatch などの既存基盤で実現できる範囲も多くあります。

• メトリクスの可視化
• 使用率や増加率の計算
• 複数メトリクスの組み合わせ
• 閾値判定とアラート通知
• 到達見込みの表示
• ダッシュボード化と定期レポート

最初から独自の予測システムを作る必要はありません。まずは既存の監視データを使い、計算式と判定条件を定義し、それをダッシュボードやアラートへ反映する方が現実的です。

利用者ごとに必要な粒度は異なる

予測結果は、見る人によって必要な粒度が異なります。同じメトリクスを全員に同じ形で見せても、実務上の判断にはつながりにくいです。

利用者	必要な情報
技術者	装置、インターフェイス、メトリクス、時系列、原因分析に使える詳細
管理者	リスク、優先順位、対応状況、保留判断、担当範囲
経営層	投資判断、リスク受容、費用、期限、選択肢、推奨案

「誰でも見られるダッシュボード」を作ることが目的ではありません。技術者には原因分析できる情報を、管理者には対応判断に使える情報を、経営層には投資判断やリスク受容に使える情報を提示する必要があります。

ゴールなき項目洗い出しは設計ではない

この種のテーマで危ういのは、いきなり「まず項目を洗い出しましょう」と始めることです。項目洗い出し自体は必要ですが、それは目的に従属する作業です。

• どのコンポーネントを対象にするのか
• そのコンポーネントの主軸能力は何か
• どのメトリクスで限界接近を判断するのか
• どの状態を危険とみなすのか
• 誰が結果を見て、何を判断するのか
• アラートやレポートはどの行動につながるのか

この骨格がないまま項目を並べても、CPU 使用率、メモリ使用率、ディスク使用量、トラフィック量、セッション数、エラー率の一覧ができるだけです。それは設計資料ではなく、単なる項目表です。

成功条件を定義する

リソース予測やトラフィック予測には、成功条件も必要です。何を予測するのか、何日先を予測するのか、どの程度の誤差を許容するのか、予測結果を誰が見るのか、アラートが出たら誰が何をするのかを決めておく必要があります。

予測は精度だけで評価するものではありません。実務上は、判断に役立ったか、障害を防げたか、増強判断を早められたか、コスト最適化につながったかで評価するべきです。

まとめ

リソース予測・トラフィック予測は、未来のグラフを作ることではありません。現在のメトリクスと過去の傾向を使い、将来のキャパシティ不足や品質劣化を事前に把握し、運用判断、増強判断、投資判断につなげることです。

• コンポーネントの主軸能力を定義する
• 主軸能力を支える従属リソースを整理する
• 実用上限、劣化開始点、閾値、複合判定条件を定義する
• 過去傾向から限界到達時期を見積もる
• 予測結果を判断とアクションにつなげる

予測は目的ではありません。予測は、判断するための材料です。メトリクスを大量に集めることよりも、そのメトリクスがどの能力の限界を示し、誰のどの判断につながるのかを設計することが重要です。