基本情報のキャパシティプランニングを負荷予測と見積例で理解する

キャパシティプランニングは、現在の負荷を測り、将来の処理量を予測して、必要なサーバの性能や保存容量を決め、導入後も評価する活動です。基本情報の学習では、作業の順番と、どの数値から何を見積もるのかを結び付けると理解しやすくなります。

たとえば「1台で毎秒180件処理できるから、毎秒270件なら2台」と計算できても、1台停止したときまで同じサービス水準を保てるとは限りません。この記事では、応答時間とスループットを整理し、自作の台数・容量計算で、前提条件によって答えが変わる理由を確認します。

基本情報のキャパシティプランニングの進め方

目的は将来の負荷でも要件を満たすこと

キャパシティは、システムが持つ容量・処理能力を指します。キャパシティプランニングでは、どのような処理が、どれだけ発生し、いつまでに終わる必要があるかを整理し、それに見合う資源を計画します。単に大きなサーバを選ぶ作業ではなく、サービスの要求と設備の能力を対応させる作業と考えましょう。

IPAの基本情報技術者試験シラバスVer.9.2は、「システムの評価指標」の中でキャパシティプランニングを扱っています。処理の種類・量・時間を検討し、性能要件からサーバやストレージの性能諸元を見積もり、継続して性能を把握・評価する、という学習範囲です。単語の意味だけでなく、見積もりと評価のつながりまで押さえたい分野です。

学習範囲の確認には、IPAの基本情報技術者試験シラバスVer.9.2の「システムの評価指標」（冊子17ページ）を参照できます。ここで紹介する数値例は、考え方を理解するために作成したもので、IPAの問題や実際の運用実績ではありません。

たとえば申込システムなら、目標は「CPUを増設する」ではなく、「受付開始時に毎秒何件の申込が来ても、決めた時間内に応答する」です。CPU増設は、その目標を満たすための候補の一つです。先に機器を選ぶと、本当に不足しているのがメモリやデータベースの処理能力だった場合に、必要な対策を外してしまいます。

また、処理能力と保存容量は別の条件です。画面が速く表示されても、添付ファイルの保存先が満杯になれば処理できません。反対に、空き容量が十分でも、短時間に読み書きが集中すれば遅くなることがあります。「速さ」「単位時間に処理できる量」「蓄積できる量」を分けて考えるのが出発点です。

現状測定から継続評価までをつなげる

検討は、現状を測る、将来の負荷を予測する、要件と比較して構成を見積もる、導入後に評価する、という流れで進めます。どの段階でも、前の段階で集めた情報が次の判断の材料になります。順番を丸暗記するより、「その判断には何の情報が必要か」と考えると整理しやすいですね。

段階	確かめること	次の判断に渡すもの
現状測定	処理件数、応答時間、資源の使用状況	現在の負荷と能力の対応
負荷予測	利用者増、新機能、ピークの発生条件	将来の処理量とデータ量
見積もり・構成検討	性能要件、必要資源、拡張方法	台数・容量・導入時期の案
検証・継続評価	想定負荷での動作と運用後の変化	予測と実測の差、見直しの材料

現状測定では、負荷の小さい時間帯だけを選ばないことが大切です。月末処理があるなら月末、朝にログインが集中するなら始業時刻など、そのシステムで厳しくなる時間帯を含めます。新規システムで実測値がなければ、試作品や類似条件の試験などを使い、何を仮定したのかを分かる形にします。

負荷予測では、過去の増加傾向だけでなく、新たな業務やイベントを確認します。現状の利用者が増えなくても、1件ごとの計算が重い機能を追加すれば必要能力は変わります。予測の根拠が変われば見積もりも変わるため、利用者数だけを毎回同じ倍率で延ばす方法では説明できない場合があります。

IBMの公式解説でも、現在の能力の評価、需要予測、制約の特定、対策、監視と最適化が一連の活動として整理されています。計画した構成を導入して終わりにせず、実際の需要とのずれを確認して次の計画につなげる点を、IBMのキャパシティプランニング解説で確認できます。

応答時間とスループットを区別する

応答時間は1件の要求に応じるまでの時間、スループットは単位時間に処理した量です。前者は「1回の検索で何秒待つか」、後者は「1秒間に何件の検索を処理するか」と置き換えられます。同じシステムの性能を見ていますが、答えている疑問が異なります。

指標	例として使う単位	判断する内容
応答時間	秒、ミリ秒	要求してから応答するまでの待ち
スループット	件/秒、件/分	一定時間内に完了する処理量
CPU・メモリ使用率	%	対象資源がどれくらい使われているか
保存データ量・空き容量	GB、TB	今後の蓄積を受け入れられるか

たとえば、毎秒300件を受け付けても、完了しているのが毎秒200件なら、同じ状態が続く間は処理待ちが増えます。「受け付けた件数」と「完了した件数」を同じ意味で扱わないようにしましょう。この例では、測定区間の途中で待ち行列が増えた可能性があるため、完了件数だけを見て余裕があると判断できません。

反対に、毎秒100件を処理できたとしても、1件の応答に求める時間を超えていれば要件は未達です。件数の目標と時間の目標は両方確認します。夜間バッチなら、画面の応答よりも「締切までに全件を処理し終えるか」が重要になるため、処理の開始から終了までの時間も判断材料になります。

CPU使用率は原因を調べる材料になりますが、それだけで利用者の体験を表すわけではありません。CPUに余裕があっても、ディスクの読み込みや外部サービスの応答待ちで遅くなる場合があります。AWSの性能エンジニアリングの監視資料も、応答の遅延、要求処理量、エラーと、各資源の利用状況を合わせて見る考え方を示しています。

平均値を使うときは、どの区間・対象の平均かも確認しましょう。「一日の平均応答時間」と「受付開始直後の応答時間」は同じ条件ではありません。遅い要求が一部に集中していないかまで確かめると、処理能力の見積もりとサービス水準の確認を結び付けられます。待ちが増える仕組みを数式でも確かめたい場合は、待ち行列モデルと利用率の計算が補助になります。

平均ではなくピークの負荷を予測する

将来の負荷を見積もるときは、最初に単位をそろえます。1日あたりの利用者数、1人あたりの操作回数、ピーク1秒あたりの要求数は、そのままでは比較できません。利用者がいつ利用し、1回の操作が何件のサーバ処理を発生させるかを確認してから、必要な処理量へ変換します。

ここでは、自作の例として、受付開始時のピークが毎秒150件のシステムを考えます。次回は同じ利用の仕方をする利用者が1.5倍となり、さらに同じ時間帯の集中を1.2倍と見込む、という独立した二つの条件を置きます。予測するピーク負荷は150×1.5×1.2＝270件/秒です。

1.5倍は利用規模の変化、1.2倍は集中の変化という別の要因です。すでに集中増を含めて「ピークが1.8倍になる」と予測しているなら、そこにもう一度1.2を掛けてはいけません。安全側のつもりで同じ要因を二重に加えると、見積もりの根拠を説明できなくなります。

また、利用者が1.5倍になっても処理が必ず1.5倍になるとは限りません。画面を開くたびに検索する人が増える、画像添付が追加される、といった変化があれば、1人あたりの処理も変わります。先ほどの270件/秒は「要求1件の仕事量は変わらない」という条件の下で使う数値です。

ピークの長さも分けて考えます。毎秒270件が数秒だけ続く場合と、1時間続く場合では、処理待ち、メモリ、ログの増加などの確認条件が変わります。短い集中を平均化して見落とさず、どの程度の時間その負荷が続くのかを、台数計算の前提に含めましょう。

スケールアップとアウトを選び分ける

スケールアップは1台の性能や資源を増やす方法、スケールアウトは複数台へ処理を分散する方法です。たとえば、1台のメモリを増やすのが前者、同じ役割のサーバを追加するのが後者です。この区別は、IBMのスケールアップとスケールアウトの比較でも確認できます。

方法	変更の例	検討する条件
スケールアップ	CPU・メモリを強化する	1台の資源が不足しているか、強化できる上限は何か
スケールアウト	処理用サーバの台数を増やす	要求を分散できるか、共通の処理先が詰まらないか
チューニング	検索方法や処理内容を改善する	同じ仕事をより少ない資源で処理できるか

どちらを選ぶかは、負荷の量だけでは決まりません。処理を別々のサーバへ分けられるなら台数を増やす案を検討できますが、1件の巨大な処理を並列化できない場合は、台数を増やしてもその1件が速くなるとは限りません。また、複数のサーバが同じデータベースを使い、そこで待たされているなら、アプリケーションの増設だけでは改善しない可能性があります。

1台を高性能に置き換える場合にも、CPUの性能差がそのままシステム全体の性能差になるとは限りません。CPU以外の待ち時間が含まれるためです。装置単体の性能を計算する考え方はCPU性能とクロック周波数・MIPS・CPIの計算で整理し、構成全体の見積もりとは段階を分けて学ぶと混同を防げます。

チューニングも、必要能力を満たす手段の一つです。将来の負荷に備えてクエリを改善することもあるので、「チューニングは現在だけ、計画は将来だけ」と完全に切り離す必要はありません。問われているのが資源需要の計画なのか、具体的な処理効率の改善なのかを、作業の目的で判断してください。

基本情報のキャパシティプランニングの見積例

サイジングの前に問題条件を整理する

サイジングは、性能要件や負荷の見込みから、必要な資源の規模を見積もることです。台数を求める前に「何を満たす最小台数か」を言葉にしましょう。通常時だけ処理できればよいのか、1台が止まっても同じ要件を満たすのかで、同じピーク負荷でも答えが変わります。

以下の例では、アプリケーションサーバ1台の基準処理能力を毎秒180件とします。この180件/秒は、例題上の比較基準であり、CPU使用率100%を表す数字ではありません。計画では基準の75%までを使い、そこで目標の応答時間も満たすことが試験で確認できた、という条件を置きます。

条件	この例で与える値・仮定
将来のピーク負荷	270件/秒
1台の基準処理能力	180件/秒
計画上の処理量上限	基準処理能力の75%
分散の条件	同等性能のサーバへ均等に分散できる
性能の条件	台数に比例して合計処理能力が増え、共通処理先の制約はない
時間の条件	計画上限以内なら目標応答時間を満たすことを確認済み

75%はこの計算のために与えた割合です。どのシステムにも適用できる推奨使用率ではありません。実際の計画では、応答時間の目標、負荷の変動、追加に要する時間などから、必要な余裕を決めます。問題文に上限が示されていればその値を使い、示されていない条件を勝手に追加しないことが大切です。

ここでの「均等に分散できる」「能力が比例する」は、単純な割り算を使えるようにするための仮定です。実機の能力を証明するものではありません。条件が与えられた例題として計算し、実際の構成案では負荷試験で確かめる、という二段階で扱います。

ピーク処理量から必要台数を求める

最初に、1台へ割り当ててよい計画上の処理量を求めます。この例では180×0.75＝135件/秒です。次に、将来のピーク270件/秒を135件/秒で割ると、必要台数は2台となります。2台に均等に分散できれば、1台あたり135件/秒となり、設定した上限以下に収まります。

必要稼働台数＝将来のピーク処理量÷1台あたりの計画上限と置き、端数が出たら整数へ切り上げます。たとえばピークが280件/秒へ変われば、280÷135≒2.07です。2台では合計270件/秒までなので不足し、必要稼働台数は3台になります。四捨五入すると不足を見逃すため注意しましょう。

式に入れる数値の単位は、どちらも件/秒にそろっています。1台の性能が件/分で与えられた場合には、60で割って件/秒へ換算するか、負荷側を60倍して件/分に直します。計算が合っているように見えても、分子と分母の時間の単位が違うと、台数の意味が変わってしまいます。

また、「25%の余裕」という言葉には読み違いが生じやすいため、何を分母にした割合かを確認します。この例では基準能力の25%を使わずに残すので、使用できるのが75%です。「予測需要へ25%を上乗せする」という別条件なら計算式は異なります。余裕という語だけを見て、いつも同じ倍率を掛けないようにしてください。

この台数計算で分かるのは、与えられたモデルの処理量条件を満たす台数です。毎秒180件という数値しか与えられず、応答時間との対応が分からない場合には、台数だけから「必ず0.5秒以内」といった結論は出せません。ここで2台と判断できるのは、先ほどの性能・時間・分散の前提を置いているためです。

増加するデータから必要容量を求める

次に、処理件数ではなく保存容量を考えます。自作の別の例として、現在の保存データが150GB、今後の純増が1日2GB、計画期間が90日であるとします。純増とは、新規保存量からその日に削除する量を差し引いた増加です。この例では期間中ずっと同じ純増が続くものとします。

90日後に保存するデータ量は、150＋2×90＝330GBです。ここで「使用率を80%以下にする」という条件が付く場合、必要な使用可能容量をCとすると、330÷C≦0.8となります。したがってC≧330÷0.8＝412.5GBであり、少なくとも412.5GBの使用可能容量を確保する必要があります。

330GBに20%を足した396GBでは、330÷396≒83.3%となり、使用率80%以下を満たしません。空き20%は装置の使用可能容量全体に対する割合です。「データ量の20%を加える」こととは分母が違う、と捉えると間違いを防げます。

計算段階	式	求まる値
計画期間中の純増	2GB/日×90日	180GB
90日後の保存データ量	150GB＋180GB	330GB
使用率80%以下に必要な容量	330GB÷0.8	412.5GB以上
仮に500GBを確保した場合	330GB÷500GB	使用率66%

最後の500GBは計算を確かめるための仮の使用可能容量で、特定製品の容量を意味しません。公称容量と、OSや保護方式を含めて実際に使える容量は区別します。試験問題でGBの換算や利用可能割合が指定されたらその条件を優先し、指定のない換算方式を途中で混ぜないようにしましょう。

この例の330GBには、対象に含めた保存データだけを計上しています。ログ、バックアップ、複製、検索用データなどを同じ装置に置くなら、それらも含む将来量を求めてから使用率の条件を当てはめます。二重に見積もらないために、何を含めた値なのかを先に決めておくことが重要です。

容量が足りることと、必要な速さで読み書きできることも別です。412.5GB以上を確保できたとしても、受付が集中する時間帯に書き込みを処理できるかは、この式だけでは分かりません。台数と同様に、保存量の条件を計算で確かめたあと、処理時間や入出力性能の条件を確認します。

停止時と負荷試験の条件も確認する

処理用サーバの例に戻り、1台が停止しても毎秒270件を処理し、各稼働サーバの計画上限135件/秒を超えない条件を追加します。稼働しているサーバが2台必要なので、構成する台数は3台です。3台のうち1台が止まっても、残り2台で270件/秒を処理できます。

通常時の必要台数が2台だからといって、常に予備1台を足す決まりではありません。今回は「1台停止しても同じ負荷と上限を満たす」という追加条件があるため、3台になります。停止時はサービスを制限してよい場合や、複数台の同時停止も想定する場合には、必要な構成を別に検討します。

さらに、3台にしても、要求の振り分け装置やデータベースが1か所で停止すれば、処理できなくなる可能性があります。AWSの信頼性設計の原則では、複数の小さな資源へ分散する際に共通の障害点を避ける考え方が示されています。台数の余裕と、システム全体の停止への備えを同じものとして扱わないようにしましょう。

見積もった構成では、想定した業務の組合せとピークの持続時間を再現して、目標を満たすか試します。軽い検索ばかりの試験で毎秒270件を処理できても、実際には重い更新処理が多ければ結果をそのまま使えません。負荷の件数だけでなく、1件の仕事の内容も一致させる必要があります。

AWSの負荷試験のガイドも、本番を意識した条件で、スループットや応答時間を評価し、ボトルネックや非線形な性能変化を確認する手順を挙げています。ここで置いた「台数に比例する」という仮定が現実でも成立するかは、こうした試験で確かめる対象です。

キャパシティプランニングを条件で復習する

基本情報のキャパシティプランニングは、「何台増やすか」を考える前に、「どの負荷で、どのサービス水準を満たすか」を決めると整理できます。現状測定で現在の姿をつかみ、将来の業務を負荷へ変換し、計算で構成案を作り、試験と運用後の測定で確かめる、という流れを説明できるようにしましょう。

• 現状把握の問題では、処理量と資源使用状況を先に確認する
• 予測の問題では、ピークの量・長さと処理内容の変化を読む
• 台数の問題では、1台の計画上限で割って端数を切り上げる
• 容量の問題では、将来量を求めてから許容使用率で割る
• 停止条件がある問題では、必要稼働台数と設置台数を分ける

最後に、次の三つを自分の言葉で確認してみてください。「毎秒270件、1台の計画上限135件なら通常時は何台か」「1台停止後も同じ条件なら何台を用意するか」「330GBを使用率80%以下で保存するには何GB必要か」です。答えは順に2台、3台、412.5GB以上となり、それぞれ条件の違う問いに答えています。

導入後は、予測した処理件数と実際の件数、応答時間、資源の余裕を比較します。利用が予測より速く増えたなら対策時期を早め、増えなかったなら過剰な確保を見直す、といった判断につなげます。サービス水準をどのように合意し管理するかは、サービスマネジメントとSLA・SLMの解説で関連付けて確認できます。

手順と条件を説明できたら、基本情報の科目A・科目Bの演習に取り組むことで、問題文から必要な情報を拾う練習へ進めます。計算結果だけでなく、なぜその式を使ったのかまで確認しながら復習してみてください。