情報管理技術士 学習ノート
← 一覧へ
SW工学・管理
#성능요구사항#응답시간#TPS#가용성#비기능#132회
最終更新 · 2026-07-07

情報システムの性能要件における主要性能指標

1. 概要

A. 定義

情報システムが満たすべき性能目標を定量的かつ測定可能に定義した非機能要件(NFR)である。応答時間・スループットなどの数値目標で表現され、設計・構築・検収・SLA契約の客観的な基準となる。

性能要件は「何をするか(機能)」ではなく、「どれだけ速く、安定して行うか(品質)」を規定する。機能要件が満たされても性能が不十分であれば、システムは失敗と見なされる — 例えば照会はできても30秒かかるのであれば、ユーザーはそのシステムを使わない。したがって性能は、機能に劣らず重要な要件として扱わなければならない。

B. 登場背景および必要性

性能要件が「速く、安定的に」のような曖昧な表現のまま残されると、開発者・発注者・検収者がそれぞれ異なる期待を持つことになり、竣工段階で紛争が生じる。「3秒以内」か「10秒以内」かによって、必要なサーバ台数とアーキテクチャがまったく異なるからである。定量化された性能指標は、(1) キャパシティ算定とアーキテクチャ設計の根拠となり、(2) 負荷試験の合格基準を提供し、(3) SLA・業務履行の可否を客観的に判定できるようにする。これが、性能要件を最初から数値で確定させなければならない理由である。

2. 主要性能指標

flowchart LR
  R[応答時間<br/>ユーザー体感] --- T[スループット TPS<br/>システム能力]
  T --- C[同時ユーザー<br/>負荷規模]
  C --- U[リソース使用率<br/>余力・ボトルネック]
  U --- A[可用性<br/>信頼性]

性能指標は互いに連動して動く。同時ユーザーが増えればスループットの要求が大きくなり、スループットが限界に達するとリソース使用率が飽和して応答時間が急増する。したがって指標は個別ではなく、まとめて定義しなければならない。

  • 応答時間(Response Time): ユーザーがリクエストを送ってから結果を受け取るまでにかかる時間であり、ユーザーの体感性能を直接反映する。単純平均だけを使うと少数の遅いリクエストが隠れてしまうため、「95パーセンタイルで3秒以内」のようにパーセンタイル(percentile)基準で定義するのが実務的である。
  • スループット(Throughput/TPS): 単位時間あたりの処理件数(秒間トランザクション数)であり、システムが処理できる仕事量(能力) を表す。応答時間が個々のリクエストの観点であるのに対し、スループットは全体処理の観点である。
  • 同時ユーザー数(Concurrency): 同じ時点に接続・処理中のユーザー規模であり、負荷の大きさを定義する。「接続者」と「実際にリクエストを発生させるアクティブユーザー」を区別することで、過大・過小な算定を避けられる。
  • リソース使用率(Utilization): CPU・メモリ・ディスクI/O・ネットワークの使用割合であり、余力とボトルネックを示す。通常はCPU 70~80%を閾値とし、ピーク時にも余裕を残す。
  • 可用性(Availability): 稼働率(例: 99.9% → 年間約8.8時間のダウンを許容)で表現される信頼性の指標であり、MTBF/MTTR によって裏付けられる。
  • 拡張性(Scalability): 負荷が増えたときにリソースを追加して性能を維持する能力であり、スケールアップ/アウトの可否を規定する。
指標 観点 定義例
応答時間 ユーザー体感 95%ile 3秒以内
スループット(TPS) システム能力 500 TPS
同時ユーザー 負荷規模 アクティブ1万人
リソース使用率 余力・ボトルネック ピーク時CPU 80%以下
可用性 信頼性 99.9%、MTTR 30分
拡張性 成長への対応 オートスケール対応

3. 作成時の考慮事項

性能目標は測定条件とともに定義されて初めて意味を持つ。「500 TPS」という数字も、それが平常時なのかピーク時なのか、データが10万件のときなのか1億件のときなのかによって、達成の難易度がまったく異なるからである。したがって以下を併せて明記する。

  • 測定条件の明記: ピーク/平常時の区分、データ蓄積量、同時実行レベルを前提として確定させる。
  • 定量性・検証可能性: 数値・単位・目標値と測定方法を併せて規定し、「どのように確認するか」まで合意する。
  • ピーク負荷基準: 年末調整や履修登録のように瞬間的なアクセス集中があるシステムは、最大負荷の時点を基準に算定してこそ実際の障害を防げる。
  • SLAとの連携: 契約したサービスレベル(例: 可用性99.9%、応答時間目標)と要件の数値を一致させ、責任の境界を明確にする。

4. 検証方法

定義した目標は必ず試験で検証する。性能(負荷)テストは目標負荷における指標の充足可否を、ストレステストは限界点(臨界負荷)を、耐久(soak)テストは長時間運用時のメモリリークなどの劣化を確認する。BMT(ベンチマークテスト) は候補となる製品・アーキテクチャを同一条件で比較して目標達成の可能性を事前に検証し、運用段階ではAPM で実際の指標を常時モニタリングしてSLA違反を早期に捕捉する。

方法 時期 確認対象
性能・負荷テスト 構築・検収 目標負荷での指標充足
ストレステスト 構築 限界点・障害時の挙動
BMT 導入前 製品・アーキテクチャの比較
APMモニタリング 運用 常時の指標・SLA

5. 考慮事項および示唆

  • 設計との直結: 性能要件はキャパシティ算定・アーキテクチャ(キャッシュ・負荷分散・DBインデックス)を決定するため、要件定義の初期に確定させるべきであり、後半で変更すると再設計のコストが大きい。
  • ボトルネック分析とチューニング: 目標未達の場合、やみくもにサーバを増やすよりも、プロファイリングでボトルネック(遅いクエリ・ロック競合)をまず見つけ、スケールアップ/アウトとコード・クエリのチューニングを組み合わせる。
  • トレードオフ: 性能・コスト・複雑さは相反する。過度な性能目標はコストの無駄であるため、実際の業務量に基づいた適正水準を定める。
  • 展望・連携: クラウドのオートスケールとオブザーバビリティ(Observability) によって性能管理が自動化・常時化しつつあり、MSA環境ではサービスごとの指標と分散トレーシングが性能管理の鍵となる。

一言まとめ: 性能要件とは、応答時間・スループット(TPS)・同時ユーザー・リソース使用率・可用性などを、ピーク負荷・測定条件とともに定量的かつ検証可能に定義した非機能要件であり、キャパシティ算定・アーキテクチャの根拠となり、性能テスト・BMT・APMによって検証・管理する。