まだ余裕があるのに増強する？｜需要予測・閾値・容量管理

今日の使用量が上限より小さければ、増強は後でよいのでしょうか。需要が増え、準備に時間がかかるなら、足りなくなる前に動く必要があります。通常時の余裕だけでなく、故障時と調達期間を含めて計算します。

事例：6台のサーバで、毎月増えるアクセスを受ける

ピークの需要は現在1200リクエスト/sで、毎月200ずつ増える見込みです。6台のサーバがあり、1台の能力は対象の負荷で400リクエスト/sと測定されています。追加サーバの準備には2か月かかります。

このサービスでは、負荷試験で求めた応答時間を保つため、1台の計画上限を能力の75%とします。さらに1台故障しても対応する条件です。75%はこの事例の設計値で、すべてのシステムの共通基準ではありません。

6台×400で、2400まで受けられる？

計画上の1台分は400×0.75=300リクエスト/s。1台故障時は5台なので、使える能力は5×300=1500リクエスト/sです。6×400=2400という通常時の最大値を、そのまま運用の保証値にはできません。

不足するのは2か月後です。準備に2か月かかるため、今から増強を始めます。実際の発注・確認には余裕が必要です。予測のずれや準備の遅れを見込んで、期限より前に使える状態を計画します。

3か月後には、何台必要？

1800リクエスト/sを1台300で受けるには、稼働する台数が1800÷300=6台必要です。1台故障の分を足して合計7台とします。端数が出る需要なら、稼働台数を切り上げてから予備条件を足します。

1. 需要

   利用者数だけでなく、ピークの要求回数、処理の種類、データ量を見積もります。

2. 能力

   同じ種類の負荷で、応答時間や失敗率を満たせる量を測ります。機器の公称値だけで決めません。

3. 準備期間

   調達、設定、試験、運用引継ぎまでの期間です。注文から納品までだけで終わらせません。

7台なら6×300=1800で、3か月後の予測には一致しますが、成長のずれに対する余裕はありません。最低台数の計算と、安全な運用計画を区別し、予測の上振れやその後の成長も評価します。

ストレージは、警告が出てから買えばよい？

保存容量の上限は1000GB、現在600GB、毎月50GBずつ増えるとします。警告を80%の800GBで出すなら、到達は(800-600)÷50=4か月後です。上限へ到達する8か月後とは違います。

警告の時点までに増設を終えたいなら、準備2か月を引き、遅くとも2か月後までに開始します。削除や保持期間の見直しも選択肢ですが、必要な記録を消してよいかを業務・監査の条件から確認します。

使用量が増え続けるか、季節的に山があるか、保持期間で頭打ちになるかを確認します。一つの時点の数値ではなく、傾向と変化の理由を合わせて見ます。

平均129.5msなら、応答目標200msを満たす？

100件の応答時間が、80msで90件、250msで5件、900msで5件とします。平均は(80×90+250×5+900×5)÷100=129.5msです。ただし、遅い問い合わせの状況は平均だけでは分かりません。

小さい順に並べ、nearest-rank方式で95番目を見るなら、p95は250msです。p95を200ms以内にする目標は満たしません。99番目のp99は900msです。百分位の方式や集計範囲をそろえて比較します。

需要の増加で、応答の遅い側が先に悪化することがあります。処理量、失敗率、待ち時間、CPU・メモリ・I/Oの飽和を合わせて監視します。利用率の数字だけから、利用者の体験を決めつけません。

サーバを増やしたのに、速くならないのはなぜ？

共有DBのI/Oが詰まっていれば、Webサーバを増やしてもDBへの要求が増えるだけの場合があります。負荷試験や区間ごとの観測で、能力を制限している資源を特定します。

一時的には受付制限、優先度の低い処理の延期、キューの上限などで過負荷を抑えます。しかし、必要な業務量を恒常的に満たす計画の代わりにはなりません。対処の効果と利用者への影響を確認します。

増強後は同じ条件で再測定し、予測と実績の差を更新します。容量管理は一度の購入ではなく、測定、予測、判断、実施、確認を続ける運用です。

演習1：故障時の能力

条件：6台、1台400/s、計画上限75%、1台故障を考慮します。

問い：運用計画に使う能力を答えてください。

解答例：1500リクエスト/sです。

根拠：(6-1)×400×0.75です。

誤答の理由：6×400では、余裕と故障条件の両方が抜けています。

演習2：開始する時期

条件：需要1200/s、毎月200/s増加、能力1500/s、準備2か月です。

問い：いつ増強を始めますか。

解答例：計算上は今から開始し、2か月後より前に使える状態を目指します。

根拠：2か月後に1600/sで能力を超えます。

誤答の理由：能力を超えてから発注すると、準備中に不足する期間が生じます。

演習3：必要台数

条件：需要1800/s、1台の計画能力300/s、1台故障に備えます。

問い：最低の合計台数を答えてください。

解答例：7台です。

根拠：稼働6台と故障分1台です。予測上振れへの余裕は別に評価します。

誤答の理由：6台だけでは、1台故障時に1500/sへ落ちます。

演習4：保存容量の閾値

条件：600GBから毎月50GB増え、警告800GB。準備は2か月です。

問い：警告到達と開始期限を答えてください。

解答例：警告は4か月後。警告前に完了するには、遅くとも2か月後までに始めます。

根拠：(800-600)÷50=4か月から準備2か月を引きます。

誤答の理由：1000GBの上限で計算すると、警告値に対して動く計画になりません。

演習5：平均とp95

条件：80msが90件、250msが5件、900msが5件。p95の目標は200msです。

問い：nearest-rankで目標を満たすか答えてください。

解答例：p95は250msで、目標を満たしません。平均は129.5msです。

根拠：95番目は91〜95番目に並ぶ250msの範囲です。

誤答の理由：平均だけで合格とすると、一部の遅い問い合わせを見落とします。

演習6：増強する資源

条件：WebのCPUには余裕があり、共有DBのI/O待ちが長くなっています。

問い：Webの台数だけ増やせばよいですか。

解答例：DBのI/Oや問い合わせの負荷を調べ、その制約へ対処します。

根拠：処理を止めている資源と増やす資源が対応していません。

誤答の理由：台数を増やせば必ず全体が速くなるという判断は、共有資源を見落とします。

出典と仕様を確認する

IPA：APシラバス Ver.7.2

Google SRE：サービスの能力計画

Google SRE：分散システムの監視

Google SRE：過負荷への対処

関連テーマを続けて学ぶ

性能・利用率・待ち時間

仮想化と物理資源