システムの性能設計・サイジングの進め方

Contents

性能設計・サイジングの重要性

システムの非機能要件の一つである「性能」。

開発上流工程でしっかり考慮して性能設計しておかないと、カットオーバー後にシステムのスローダウンといった性能問題の憂き目に合う。

性能設計の流れは以下の通り。

ここでは「性能要件の定義」について整理してみたい。

システムの利用者部門へのヒアリングにより性能要件を決定していく。性能要件で定めるべき項目はメジャーなもので以下のものがある。

レスポンスタイム（Responce time）とは、システムに処理を要求して応答を受け取るまでに要した時間のこと。単に「応答時間」ともいう。

単位はms（ミリ秒）やs（秒）で表すことが多い。

人によって違うとは思うけどレスポンスタイムが3,000msec（3秒）を超えてくるとシステム利用者のストレスになるというのが定説。このことから多くのWebシステムは性能要件を1秒～3秒に定義してシステムの設計をすることが多い。

スループット（Throughput）とは、単位時間あたりの処理量のこと。

「単位時間あたりの」という表現をしたけど一般的には秒（Second）あたりの処理量を示すことが圧倒的に多く、この時の単位はtps（Transactions Per Second）で表す。

システムの性能を「質」「量」の2軸で評価しようとすると、

といえる。

「レスポンスタイムの要件を遵守しつつ、1秒あたりに何件処理を捌く必要があるか」という質・量の両面からスループットの要件を定義していくのがふつう。

このときにキーワードとなるのが「ピーク」という考え方で、そのシステムが「何月何日、何時何分何秒にピークを迎えるのか」を予測してスループット要件を定義することが重要となる。

身近なシステムのピーク例で言うと、AmazonであればAmazonプライムデーのスケジュールから負荷のピークを予測できるし、Twitterであれば「天空の城ラピュタ」の再放送日時から負荷のピークを予測できる（バルス負荷）

CPUやメモリなどのシステムリソース全体量に対する使用率のこと。

常時10%以下だと「リソースを有効活用できていない」「オーバースペック（＝過剰投資）だ」と経営者に怒られてしまうし、常時90%以上だと「いつスローダウンしてもおかしくない」「性能リスクが高い、怖い」と利用者にビクビクされてしまう。

なのでリソース使用率の要件は「ピーク時にちょうど8割～9割の利用率になるようにすること」と定義されることが多い

バッチ処理時間とは、一定量のデータを一括処理するのに要する時間のこと。

単位は秒（s）であったり分（m）であったり時間（h）であったりまちまち。

たとえば「前日に発生した業務データを夜間に一括処理して翌日の業務に使用する」という業務要件が合ったとき、バッチ処理時間が10時間も20時間もかかっていたら業務にならないのでバッチ処理時間は性能要件としてちゃんと定めてあげる必要がある。

バッチ処理時間はバッチ処理が途中でエラーを起こしても再実行できるだけの余裕を持たせるために、「時間制約÷2」で定義するという考え方が多い