リソース上限を倍率だけで考えない – CPU、メモリ、同時接続数、障害時の余白で見る

CPU やメモリのリソース設計では、上限値や倍率だけを見ると判断を誤ります。CPU を 2 倍にした、メモリを 4 倍にした、Pod の replica を 3 つにした、ロードバランサー配下のサーバー台数を増やした。これらは重要な情報ですが、それだけではシステムが安全になったとは言えません。実際に効いてくるのは、どの負荷が、どの時間幅で、どの資源を消費し、障害時にどれだけの余白が残るかです。

リソースを考えるときは、単純な容量ではなく、処理量、同時性、待ち行列、回復時間、片系運用時の余力に分解する必要があります。平均 CPU 使用率が低くても、ピーク時にキューが伸びれば利用者体験は悪化します。メモリに余裕があるように見えても、GC、キャッシュ、バッファ、ページキャッシュ、再起動時の初期化で別の制約に当たることがあります。

CPU 使用率だけでは処理余力は分からない

CPU 使用率は分かりやすい指標ですが、単独では処理余力を表しません。CPU 使用率が 50% だから、単純にあと 2 倍のリクエストを処理できるとは限りません。アプリケーションが I/O 待ちで止まっているのか、ロック競合で詰まっているのか、スレッド数やコネクションプールで頭打ちになっているのかによって、CPU の見え方は変わります。

また、CPU 使用率の平均値はピークを隠します。1 時間平均で 40% に見えても、数分だけ 100% に張り付いていれば、その時間帯のレスポンスは悪化します。逆に、短時間の CPU スパイクだけを見て恒久的な増強を決めると、バッチやデプロイ直後の一時的な変動に過剰反応することになります。

見るもの	分かること	見落としやすいこと
平均 CPU 使用率	長い時間幅での大まかな負荷傾向。	短時間の飽和、待ち行列、単一スレッドの詰まり。
p95 / p99 レイテンシ	一部の利用者が遅くなっていないか。	原因が CPU、I/O、外部依存のどれか。
キュー長	処理待ちが積み上がっているか。	キューに入る前に失敗したリクエスト。
スレッド数・ワーカー数	同時処理の上限に近いか。	外部接続や DB 側の制約。
エラー率	処理が失敗として表面化しているか。	遅延しているが失敗していない状態。

リソース設計で見るべきなのは、CPU の数字そのものではなく、処理が遅れ始める境界です。CPU、スレッド、キュー、外部接続、データベース、ストレージ I/O のどこが先に詰まるのかを見なければ、増強の方向を間違えます。

メモリは空き容量だけで判断しない

メモリも、空き容量だけでは安全性を判断できません。Linux ではページキャッシュが使われるため、単純な free の値だけを見ると誤解しやすくなります。アプリケーション側でも、ヒープ、ネイティブメモリ、キャッシュ、バッファ、ワーカーごとの使用量があり、どこが増えているのかを分けて見る必要があります。

メモリ不足は、CPU 飽和よりも急に深刻化することがあります。余裕があるように見えていたのに、特定の処理、再起動、バッチ、キャッシュ再構築、アクセス集中をきっかけに OOM やスワップ発生へ進むことがあります。Kubernetes では request と limit の設計によって、スケジューリング、QoS、OOM kill の挙動も変わります。

項目	設計で見ること
通常時の使用量	平常時にどの程度のメモリを使うか。
ピーク時の増加	アクセス集中、バッチ、キャッシュ再生成でどれだけ増えるか。
起動時の使用量	再起動やローリングアップデート時に一時的に増えないか。
障害時の片寄り	片系停止や Pod 退避で残った側に負荷が集まったとき耐えられるか。
強制終了の境界	OOM kill、プロセス再起動、スワップ発生の条件を把握しているか。

同時接続数とキューは見えにくい上限になる

CPU やメモリに余裕があっても、同時接続数、ワーカー数、DB コネクションプール、ファイルディスクリプタ、NAT テーブル、セッションテーブル、メッセージキューで上限に達することがあります。この種の制約は、リソース監視の見た目では分かりにくく、障害時には急に表面化します。

たとえば Web アプリケーションで、アプリケーションサーバーの CPU が空いていても、DB コネクションプールが枯渇すればリクエストは待たされます。ロードバランサーでサーバー台数を増やしても、背後のデータベースや外部 API の同時接続上限が変わらなければ、ボトルネックは移動するだけです。

設計上重要なのは、単体のサーバーがどれだけ強いかではなく、依存先を含めた処理経路のどこで待ちが発生するかです。キューは一時的な吸収には有効ですが、処理能力を超えた流入が続くと遅延を蓄積し、復旧時間を長くします。

冗長化は容量を単純に増やすことではない

サーバーを 2 台にしたから処理能力が 2 倍になる、と考えるのも危険です。冗長化は、通常時の分散処理だけでなく、障害時に残った構成でどこまで耐えるかを含めて設計する必要があります。2 台構成で通常時に各 50% 使っているなら、片系停止時には残り 1 台がほぼ 100% を受け持つことになります。実際にはフェイルオーバー、コネクション再確立、キャッシュミス、再試行が重なり、単純な 100% より厳しくなることがあります。

N+1 構成、Active-Active、Active-Standby、Kubernetes の replica、クラウドのオートスケールは、それぞれ余力の持ち方が違います。台数や倍率ではなく、1 台落ちたとき、1 ゾーン落ちたとき、依存サービスが遅くなったときに、どの負荷を捨て、どの機能を残すのかを決めなければなりません。

構成	見かけの安心材料	確認すべき境界
2 台冗長	片方が落ちてもサービスが残る。	残り 1 台でピーク負荷を処理できるか。
オートスケール	負荷に応じて台数が増える。	起動までの時間、スケール条件、依存先の上限。
Kubernetes replica	Pod が複数ある。	ノード障害時の再配置、request、limit、PDB、HPA の条件。
キューイング	一時的な流入を吸収できる。	処理能力を超えた流入が続いたときの遅延と破棄条件。
キャッシュ	バックエンド負荷を下げられる。	キャッシュミス、再生成、失効時の集中。

リソース設計は損失額ではなく影響範囲で見る

リソース不足の影響は、単にサーバーが高負荷になることではありません。レスポンス遅延、タイムアウト、再試行、キュー滞留、ログ大量出力、監視アラートの連鎖、他サービスへの波及として現れます。特に再試行は、障害時に負荷を増幅する要因になります。遅いから再試行する、再試行が増えるからさらに遅くなる、という形で悪化します。

そのため、リソース設計では、どの資源が足りなくなったら、どの機能が、どの利用者に、どれだけ影響するのかを見ます。重要な処理と後回しにできる処理を分け、必要であればレート制限、バックプレッシャー、キューの上限、優先度制御、サーキットブレーカーを設計します。

設計時に決めるべきこと

リソース設計は、CPU とメモリの見積もり表を作るだけでは終わりません。正常時、ピーク時、障害時、復旧時の状態を分け、それぞれで何を守るのかを決める必要があります。

観点	決めること
通常時	平均負荷、日次ピーク、定期処理を含めた標準状態。
ピーク時	アクセス集中やバッチ集中時に許容する遅延と上限。
障害時	片系停止、ノード退避、依存先遅延時に残す機能。
復旧時	再起動、キャッシュ再生成、再試行集中をどう抑えるか。
破棄条件	キュー、接続、リクエストをどこで制限し、何を返すか。
観測方法	CPU、メモリ、キュー、接続数、レイテンシ、エラー率をどう関連付けるか。

このように分解すると、増強の判断も変わります。CPU を増やすべきなのか、ワーカー数を増やすべきなのか、DB 接続数を見直すべきなのか、キューの上限を下げるべきなのか、処理を非同期化すべきなのか。リソース上限を倍率で見ているだけでは、この判断にたどり着けません。

負荷試験で確認すべき境界

リソース設計を記事や設計書で終わらせないためには、どの境界を試験で確認するのかを決める必要があります。CPU やメモリを見積もっても、実際には接続数、キュー、依存先、再試行、キャッシュミスが先に効くことがあります。したがって、負荷試験は最大性能を誇示するためではなく、どこから壊れ方が変わるのかを確認するために行います。

試験観点	確認する境界	見る指標
通常ピーク	日常的な最大負荷で余白が残るか。	レイテンシ、エラー率、CPU、メモリ、DB 接続数。
バースト	短時間の流入増加を吸収できるか。	キュー長、タイムアウト、オートスケール開始までの時間。
片系停止	1 台または 1 ゾーンを失っても主要機能が残るか。	残存ノードの負荷、再配置時間、利用者影響。
依存先遅延	外部 API や DB が遅いときに連鎖しないか。	リトライ回数、スレッド枯渇、サーキットブレーカー動作。
復旧直後	キャッシュ再生成や再試行集中で再悪化しないか。	キャッシュヒット率、バックログ処理時間、二次アラート。

この確認があると、増強判断は単なるスペック選定ではなくなります。どの条件で処理を通し、どの条件で待たせ、どの条件で捨てるのかを決められるため、キャパシティ設計と障害時の制御がつながります。

まとめ

リソース上限は、CPU 何コア、メモリ何 GB、サーバー何台という数字だけでは判断できません。見るべきなのは、処理量、同時性、待ち行列、依存先、障害時の余力、復旧時の挙動です。平均値だけで余裕があるように見えても、ピーク、片系運用、再試行、キャッシュミス、キュー滞留で簡単に境界を超えることがあります。

リソース設計では、倍率ではなく影響範囲を見るべきです。どの資源が先に詰まるのか。どの時間幅で問題になるのか。どの利用者や機能へ影響するのか。どこで制限し、どこで捨てるのか。どの指標で異常を検知し、どの条件で増強や設計変更を判断するのか。ここまで決めて初めて、CPU やメモリの数値が設計情報になります。

参考書籍

参考資料

• Kubernetes: Resource Management for Pods and Containers
• Google SRE Book: Addressing Cascading Failures
• Google SRE Book: Handling Overload

関連する記事