はじめに
システム開発の要件定義では、「どのような機能を実現するか」という機能要件だけでなく、「どの程度の品質で動作するか」という非機能要件を整理する必要があります。
その中でも、インフラエンジニアが特に重要視する項目の1つが「性能・拡張性」です。
お客様からは、
「レスポンスが遅くならないようにしてほしい」
「将来的な利用者増加にも対応したい」
といった要望を受けることがあります。
しかし、これらは非常に曖昧な表現です。
「遅い」「速い」という感覚は人によって異なりますし、「将来的に増える」という要望も、どの程度増えるのかが分からなければ設計できません。
そのため、インフラ要件定義では、性能や拡張性を数値や条件として明確化する必要があります。
IPA（情報処理推進機構）が公開している「非機能要求グレード」では、この性能・拡張性について体系的に整理されています。
非機能要求グレードがそもそも何か？については以下の記事にまとめています。
インフラ要件定義で役立つ「非機能要求グレード」とは？実務で感じたメリットと注意点
今回は、性能・拡張性の考え方や、実際の要件定義で意識しているポイントについて解説します。
性能・拡張性とは何か
性能・拡張性とは、システムが必要な処理能力を満たし、将来的な利用増加にも対応できることを定義する非機能要件です。
性能については主に、
- レスポンス
- スループット
という2つの観点で考えます。
レスポンスとは、利用者が操作を行ってから結果が返ってくるまでの時間です。
例えば、
- ログイン画面の表示
- 商品検索
- データ登録
などが該当します。
一方のスループットは、単位時間あたりにどれだけ処理できるかを表します。
例えば、
- 1時間あたりの帳票作成件数
- 1秒間あたりのトランザクション数
などです。
また拡張性とは、利用者数やデータ量が増加した場合でもシステムを継続利用できる能力を指します。
システムは通常、数年間から十年以上利用されます。
そのため、現在の利用状況だけでなく、将来的な成長も見据えて設計する必要があります。
業務処理量の整理が性能設計の出発点
性能・拡張性を検討する際、最初に整理しなければならないのが「業務処理量」です。
IPAの非機能要求グレードでも、性能目標値を決める前提条件として位置付けられています。
実務でも、まず以下のような情報を収集します。
- 利用ユーザ数
- 同時アクセス数
- データ件数
- オンライン処理件数
- バッチ処理件数
- 業務機能数
例えば、
「利用者数は500人です」
という情報だけでは不十分です。
500人全員が同時利用するのか、それとも最大で50人程度なのかによって必要なシステム性能は大きく変わります。
また、データ量も重要です。
利用開始時は数万件でも、5年後には数千万件になるシステムも珍しくありません。
実際の案件では、
「まだ業務量が決まっていない」
というケースもあります。
その場合でも、
- 仮定値を置く
- 想定増加率を決める
- 決定時期を明確にする
などの整理を行います。
ここが曖昧なまま進むと、後工程で性能問題が発生しやすくなります。
性能目標値は数値で合意することが重要
性能要件でよくある失敗が、目標値を曖昧にしてしまうことです。
例えば、
- 快適に使えること
- ストレスなく利用できること
- 遅くならないこと
といった表現では設計もテストもできません。
そのため、要件定義では数値による合意が必要になります。
例えば、
- ログイン処理は3秒以内
- 検索処理は2秒以内
- 登録処理は5秒以内
といった形です。
また、オンライン処理とバッチ処理では考え方も異なります。
オンライン処理では利用者の体感速度が重要になります。
一方でバッチ処理は、
- 夜間処理が翌朝までに完了すること
- 月次集計が営業開始前に終了すること
など、処理完了時間で評価するケースが一般的です。
実務では、
「95％以上の処理が3秒以内」
のような達成率で定義することもあります。
一部の例外処理まで含めて厳密な目標を設定すると、システムコストが大幅に上昇するためです。
ピーク時の性能を考慮する
性能設計では、通常時だけを基準にしてはいけません。
実際のシステムではピーク時間帯が存在します。
例えば、
- 月末処理
- 給与計算日
- ボーナス支給日
- ECサイトのセール期間
などです。
通常時の10倍以上のアクセスが発生することもあります。
実務では、
- 最大同時接続数
- 最大リクエスト数
- ピーク継続時間
などを確認します。
また、ピークが予測可能かどうかも重要です。
毎月発生するピークであれば事前に対策できますが、突発的なアクセス増加の場合は別の設計が必要になります。
近年のクラウド環境ではオートスケール機能が利用できますが、それでも上限値や増設速度には限界があります。
ピーク特性を把握せずに設計すると、本番稼働後に性能問題が発生する可能性があります。
拡張性は「将来の成長」を見据えて考える
システムは稼働開始がゴールではありません。
むしろ運用開始後に利用者数やデータ量が増加していきます。
そのため、将来的な拡張性を考慮しておく必要があります。
代表的な拡張方法には、
- スケールアップ
- スケールアウト
があります。
スケールアップは、
- CPU増設
- メモリ増設
- ストレージ増設
など、既存サーバの性能を向上させる方法です。
比較的容易ですが、物理的な上限があります。
一方のスケールアウトは、
- Webサーバ追加
- APサーバ追加
- DBレプリカ追加
など、サーバ台数を増やして対応する方法です。
クラウド環境ではこちらが主流となっています。
要件定義では、
- 将来何倍まで増える可能性があるか
- どの程度の増設を想定するか
を整理しておくことが重要です。
性能品質保証と性能テストの重要性
どれだけ立派な性能要件を定義しても、確認できなければ意味がありません。
そこで重要になるのが性能品質保証です。
特に近年は、
- 画像
- 動画
- WebAPI
- クラウドサービス連携
などが増えており、CPUやメモリだけではなくネットワーク性能も重要になっています。
そのため、
- ネットワーク帯域
- リソース共有状況
- 仮想基盤の利用率
なども確認対象になります。
また、実務で最も重要なのが性能テストです。
代表的なものとして、
- 負荷テスト
- ストレステスト
- 長時間運転テスト
があります。
実際に想定負荷を与え、
- レスポンス目標を満たすか
- リソース不足が発生しないか
を確認します。
性能は理論値だけでは判断できません。
そのため、本番前の検証は非常に重要な工程となります。
まとめ
性能・拡張性は、インフラ要件定義の中でもシステム規模やコストに大きく影響する重要な非機能要件です。
特に重要なのは、
- 業務処理量を整理すること
- 性能目標を数値化すること
- ピーク時を考慮すること
- 将来の拡張性を見据えること
- 性能テストで検証すること
の5点です。
実務では「速くしてほしい」「将来増えるかもしれない」といった曖昧な要望からスタートすることも少なくありません。
しかし、そのまま設計を進めると、性能不足による障害や過剰スペックによるコスト増加につながります。
IPAの非機能要求グレードは、そのような曖昧な要求を整理し、関係者間で共通認識を持つための非常に有効なフレームワークです。
インフラ要件定義を担当する方は、性能・拡張性の観点をしっかり押さえたうえで、業務要件に見合ったシステム基盤を設計していきましょう。
コメント