SGの容量・能力管理｜平均とピーク、負荷試験の読み方を図解

現行SGシラバスVer.4.1には、サービスマネジメントの用語として需要管理、容量・能力（キャパシティ）管理、監視、CPU・メモリ・ディスク・ネットワークの使用率や閾値が挙がっています。容量という言葉から記憶装置の空きだけを連想せず、業務の利用量に対して必要な性能を保てるかを考えましょう。

例えば月末の申請、研修開始時のログイン、集計処理などでは、同じ一日でも必要な能力が変わります。いつ、どんな操作が、どれくらい集中するかが需要の側です。利用者が困らない水準を決め、その条件で処理できるかを確かめるのが学習の入口になります。

Microsoftの容量計画の公式ガイドも、ピーク時の需要、資源の状態、スループットや待ち時間などを踏まえた計画を説明しています。以下はその製品設定の手順ではなく、当サイト独自の架空ケースです。公式問題の再現、実サービスの性能測定、必要なサーバ台数の見積りではありません。

データの更新が重なる場面の学習はSGのトランザクションと排他制御で、性能の待ちと更新の競合を、残り1席の架空例から分けて確認できます。

一秒あたりの要求数は、サービスへどれだけ仕事が来たかを見る数字です。一秒あたりに完了した処理数はスループットの一例で、来た数と常に同じとは限りません。待ち行列が増えたり、失敗や時間切れが発生したりするなら、完了した数だけを見ても利用者の状況は分かりません。

応答時間は、一つの要求にどれだけ時間がかかったかを見ます。全件の平均だけでなく、遅い側の要求を含めて判断する条件が必要なこともあります。例えば95パーセンタイルは、対象とした測定値の分布の95%の位置にある値を表し、平均値と同じ指標ではありません。集計対象や算出方法もそろえます。

CPU使用率やメモリ使用率は資源の状態を知る手掛かりです。「CPUが低いから必ず速い」「CPUが高いから必ず増強が正解」とは言えません。処理の待ち、外部への通信、データベースなど、別の場所に制約がある可能性も残ります。使用率は、利用者への応答と結び付けて読みます。

架空の社内研修サービスで、9時から10時までに受け付けた要求は36,000件でした。そのうち9時から9時5分までが18,000件、残る55分が18,000件とします。これは説明のための受信記録で、全件を正常に処理できたことを意味しません。人数や接続数の記録でもありません。

1時間全体の平均は36,000÷3,600＝10件／秒です。最初の5分の平均は18,000÷300＝60件／秒、残る55分の平均は18,000÷3,300で約5.45件／秒です。同じ単位でも集計区間が違うため、1時間平均だけでは開始直後の集中が見えません。

ここで分かるのは区間ごとの平均までです。60件／秒が一瞬の最大値だったとは言えず、5分の中にさらに短い集中があった可能性があります。また利用者一人が複数の要求を発生させる場合があるので、60件／秒を60人の同時利用と読み替えることもできません。

研修担当者から「開始直後に画面が遅かった」という連絡があれば、まずその時間帯と対象操作を確認します。9時から9時5分の要求に対し、正常完了、失敗、処理待ちがどう変化したか、同じ時間帯の応答時間や資源の記録と照合します。別の時間のCPU平均を並べて、原因がなかったと結論付けないようにします。

仮に遅延とデータベースの待ちが同時に増えていても、同時に起きたことだけで因果関係の証明にはなりません。「対象の検索処理の待ちが影響しているのではないか」と仮説を置き、担当者が構成や処理の記録を調べ、安全に比較できる条件を決めます。利用部門が推測だけで本番設定を変える場面ではありません。

対応案は資源の追加だけではありません。業務上許されるなら開始時刻の分散、処理方法の改善なども候補になります。ただし、必要な締切や操作を犠牲にしてよいとは限りません。効果、費用、運用上の制約を比べ、実施後も利用者への水準が満たされたか確認します。

Microsoftの性能試験の公式ガイドは、測定可能な目標と判定条件、実際の使い方を反映した試験環境・データ、変更前後の比較を重視しています。「100人で動いた」という記録でも、全員がログインしただけなのか、検索や登録を続けたのかで意味が変わります。

研修の例なら、検証環境で開始直後の操作の構成と集中を再現し、応答時間・正常完了・失敗・資源の推移を記録する計画を考えます。データ量、キャッシュの状態、外部連携の代替方法、試験時間や中止条件も明記します。本番と違う条件で得た結果を、本番の性能保証にはしません。

通常・想定ピークの負荷を確認する試験、限界や破綻時の挙動を見る試験、長時間の劣化を見る試験では目的が違います。短時間の成功だけで長時間も問題ないとは言えません。この記事に沿って実サービスへ大量のアクセスを送ることはせず、試験は権限のある担当者が影響範囲と安全策を確認して計画します。

文章問題では、数値の大きさを比べる前に、何を測った数字かを短く書き出すと整理できます。「平均10件／秒」の横に「9〜10時の受信要求」と添えるだけで、完了件数や同時利用者数との取り違えを防げます。観測値、原因の仮説、実施する対応を別の欄にするのも有効です。

閾値も全サービス共通の数字を暗記するだけでは使えません。どの資源・時間幅・継続条件で通知するか、その通知を受けて誰が何を確認するかまで対応付けます。自動増強の仕組みがあっても、反応するまでの時間や増強できる上限、別の制約が残るため、性能が負荷に比例して伸びるとは限りません。

利用者と何を約束し、どう実績を評価するかはSGのSLA・サービスレベル管理で扱います。本記事の容量・能力管理は、その水準を支える需要と処理能力の側です。機器の一斉送信や再送の集中を和らげる通信上の工夫はIoTの通信トラフィックへ。ここでは通信方式別の説明を繰り返さず、測定と判断の条件に焦点を当てました。

対象の構成や関係を整理する学習はCI・CMDB・構成管理、範囲の確認はSGシラバス案内で進められます。登録不要の無料6問では問題と解説の操作を試せますが、容量管理全体の理解を測る診断ではありません。SGの教材・料金で対象と購入条件を確認してください。