いつ満杯になるかを計算する — 有機的な増加と段差、そして発注期限

一言でいうと

容量計画の答えは「今何%か」ではなく、「いつまでに何を発注しなければならないか」です。その日付は3つの数字で決まります。平常時に増えていく速さ(オーガニックな増加)、超えてはならない線(しきい値)、発注から設置までにかかる時間(リードタイム)です。1回限りの大きな増加(階段状の増加)をトレンドに混ぜると、予測がまるごと狂います。

なぜ必要なのか

ディスクが95%になってから増設を依頼しても、すでに手遅れです。サーバーとストレージは、発注・配送・ラック作業・作業ウィンドウの確保まで数週間かかり、クラウドでも予約容量や予算の承認には時間がかかります。そのため容量担当者は、「今は大丈夫か」ではなく「発注ボタンを遅くともいつまでに押さなければならないか」に答える必要があります。

Google SRE本のまえがきは、容量計画に必要なものとして、正確なオーガニック需要の予測と、新機能のリリースや顧客の移行のようなインオーガニック需要を別に反映すること、そして調達リードタイムを超える期間を見通すことを挙げています。このモジュールは、その3つをディスク使用量の表1つで身につけます。

どう動くのか

トレンドラインは、1日1回測った使用量を、x = 初日からの日数、y = 使用量(GB)として、最小二乗の直線を引いたものです。傾きは次の式です。

기울기 = Σ (x − x̄)(y − ȳ) / Σ (x − x̄)²        단위: GB/일

ExcelのSLOPEや、Pythonの数行で計算できます。直線は粗いものですが、週末は増えにくく平日は増えやすいといった揺れは、数か月分を集めれば傾きにほとんど影響しません。

階段状の増加を取り除きます。表にしてみると、ある1日に数百GBが一度に増えた箇所があります。古いサーバーのデータを移行した日、新しい顧客を受け入れた日、ログの保存期間を延ばした日です。これは二度と起こらないことです。全期間に直線を引くと、その階段状の増加が傾きに混ざって「毎日これだけ増える」と解釈され、予測は実際よりはるかに悲観的になります。そのため、最も大きい1日の増加を見つけ、その日以降だけで傾きを引き直します。今後予定されている階段状の増加(来月の移行計画)がある場合は、トレンドに混ぜず、別に加算します。

残り日数は、しきい値が80%の場合、올림((용량 × 0.8 − 지금 사용량) ÷ 기울기)です(プレースホルダーは切り上げ、容量、現在の使用量、傾きです)。100%までも同じ式で求めておけば、「しきい値を超えたあとどれだけ持ちこたえるか」を言えます。切り上げるのは、「何日後」を保守的に見積もるためです。

発注締切日は、임계 도달일 − 리드 타임(プレースホルダーはしきい値到達日とリードタイムです)が、遅くとも発注しなければならない日です。この日付がすでに過ぎているか、あと数日しか残っていない場合は、レポートの1行目に書く必要があります。

しきい値が100%ではない理由は次のとおりです。ファイルシステムは満杯になるよりずっと前から遅くなり(断片化、予約ブロック)、データベースは整理作業に空き容量を必要とし、予測はいつでも外れる可能性があります。しきい値と100%のあいだの間隔は、予測の誤差や急な増加を吸収するバッファです。そのため計画はしきい値に合わせ、100%までの残り日数は「予測が外れたときにどれだけ持ちこたえるか」を示すために使います。

数字	どこから来るか	間違えると
オーガニックな傾き	階段状の増加より後のトレンドライン	階段状の増加を混ぜると過剰発注、成長を無視すると欠品
しきい値	運用基準(余裕・性能低下の地点)	高すぎると対応する時間がない
リードタイム	購入・配送・作業ウィンドウ	短く見積もると発注が遅れる

現場での姿

最も多い失敗は、モニタリング画面の「予測」をそのまま信じることです。多くのツールは、直近数日や数時間の傾きで線を引きます。昨日バックアップファイルが一度に積み上がれば「3日後に満杯」と表示され、翌日に整理されれば「400日後」と表示されます。どの期間で引いたのかを確認していない予測は、数字ではなくノイズです。

2つ目は、階段状の増加を知らないことです。移行直後のレポートが「増加率が3倍になった」と言えば、誰かがその数字で1年分の予算を組みます。逆に、来月予定されている移行を見落とすと、トレンドは正常なのにある日突然足りなくなります。そのため容量レポートは、トレンド(オーガニック)と予定されていること(インオーガニック)を別々に書きます。

直線が外れる場合も知っておきます。ユーザーが増えるにつれて増加の速さそのものが上がるサービスでは、直線はいつも警告が遅れます。その場合は、直近の区間の傾きと全体の傾きを並べて書いて加速を見せ、リードタイムに余裕をさらに持たせます。逆に、保存期間ポリシーがあるログボリュームのように、古いものが消えて平衡に近づくデータでは、直線は過度に悲観的になります。予測モデルを精巧にするより、どの仮定で引いた線なのかをレポートに1行で明記することが先です。

3つ目は、同じ計算を毎月手作業で行うことです。表が変わっても同じ答えを出す小さなスクリプトにしておけば、来月はコマンド1行で済み、ほかのボリュームにもそのまま使えます。

次のラボですること

120日分のディスク使用量の表と、運用基準(容量・しきい値・リードタイム)を受け取ります。現在の状態を書き、全期間の傾きを求めたあと、階段状の増加があった日を見つけて、それ以降のオーガニックな傾きを引き直します。しきい値と100%までの残り日数、発注締切日を計算し、最後に、この計算をどんな表にも実行できるスクリプトにします。採点ツールは、そのスクリプトを採点のたびに新しく作った表にも実行します。