性能測定の準備をまとめてみました

はじめに

最近始まったプロジェクトの中で、開発しているSaaSのアプリケーションの性能測定を行うことになりました。
自分の頭の中を整理するためにも性能測定でやることをまとめました。
これから「準備」「計測」「報告」の3stepに分けて、記事を配信していこうと考えています。
第一回目は「性能測定の準備」についてです。

※間違いや不明点などありましたらご指摘いただけると幸いです。

事前知識と背景

なぜ性能測定は必要なのか？

ソフトウェアを開発するときには、それが何をするのか＝機能、それがどのように動作するのか＝非機能を決めることが求められます。そして、ソフトウェアの品質を高めるためには、機能、非機能の観点で要件通りに動作するのかをテストする必要があります。
機能テストは注意深く行われますが、非機能テストが行われないケースはしばしば見受けられます。
以下は、ISOによって定められた製品品質モデルと呼ばれるもので、検証すべき品質特性の分類です。

品質特性	概要
機能適合性	明示された状況下で使用するとき、明示的ニーズ及び暗黙のニーズを満足させる機能を、製品又はシステムが提供する度合い。
性能適合性	明記された状態（条件）で使用する資源の量に関係する性能の度合い。
互換性	同じハードウェア環境又はソフトウェア環境を共有する間、製品、システム又は構成要素が他の製品、システム又は構成要素の情報を交換することができる度合い、及び／又はその要求された機能を実行することができる度合い。
使用性	明示された利用状況において、有効性、効率性及び満足性をもって明示された目標を達成するために、明示された利用者が製品又はシステムを利用することができる度合い。
信頼性	明示された時間帯で、明示された条件下に、システム、製品又は構成要素が明示された機能を実行する度合い。
セキュリティ	人間又は他の製品若しくはシステムが、認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように、製品又はシステムが情報及びデータを保護する度合い。
保守性	意図した保守者によって、製品又はシステムが修正することができる有効性及び効率性の度合い。
移植性	一つのハードウェア、ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に、システム、製品又は構成要素を移すことができる有効性及び効率性の度合い。

(ISO/IEC 25010:2011)

様々にありますが、この記事では「性能適合性」の品質を検証するための、性能テストについて述べていきます。

システムの性能とは何か？

性能について調べてみると、下記のように表現されていました。

性能とは、「システムが処理結果を返す力」です。
https://gihyo.jp/dev/serial/01/tech_station/0008

（他にも書かれていましたが、なんとなくこちらがしっくりきたので、、、）

性能＝「処理結果を返す力」の要因が大きく以下の3つです。

レスポンスタイム ＝　処理の応答時間
スループット　＝　時間あたりの処理能力
リソース使用量 ＝　処理を行うための必要な資源

最終的にこれらの測定を行い、性能的に問題ないかを見ていくことがゴールになります。
それぞれの測定対象、測定方法は以下を用います。

性能の指標	測定対象	測定方法
レスポンスタイム	api、画面のレスポンス速度	Jmeter、devtool
スループット	複数スレッドの時間あたりのapiの処理件数	Jmeter
リソース使用量	CPU、ディスク、メモリ、ネットワーク	AWSのモニタリング

※スループットについて
https://codezine.jp/article/detail/9614

背景

今回、性能測定を行うに至った理由は、開発しているアプリケーションの機能要件を大きく変更することになったからです。この機能要件の変更により、大量データの作成、取得を行う必要があるため、非機能要件を満たすかを検証する必要がありました。
この性能検証の結果で非機能要件を満たせなければ、ユーザーにとっては嬉しいであろう機能要件も変更せざるを得なくなります。そのため、今回の結果がプロジェクトの生死を分かつとっていっても過言ではありません。

性能測定の準備

大きな流れ

筆者は最初、性能測定をするとなったので、
「よし、早速apiのレスポンス速度を測ってみよう」
などと思っていましたが、そう簡単なことではありませんでした。
性能測定の序盤ではこんなやり取りもありました。

先輩
「そもそも、測定対象何かわかっている？」
「そもそも、機能要件を満たすための大量データがある状態で、測定を行う必要あるけど、その大量データってどんなデータがどのくらい必要かわかっている？」
「そもそも、まだ機能自体完成していないから、データなんてないよ。データ作成する必要あるけど、データの作成の仕方わかっている？」
筆者
「どれも、どうやるのか全然わからないです。」

整理すると、
性能測定をするためには、機能要件を満たした場合、
どんなデータが必要かを調べて、そのデータを作成して、そのデータによって影響のある対象を測定する必要があります。
それぞれの工程とそのアウトプット物は以下になります。

工程	アウトプット物
データ要件定義	データ要件定義書
データ作成	データ作成用のスクリプト、データ作成手順書
測定対象のスコープ決め	測定対象一覧シート

やることが少しクリアになったところでこれからそれぞれの工程を詳しくみていきます。

データ要件定義

まず、どんなデータが必要かを考えていきます。
ここでのアウトプットは、データ要件定義書です。
今回性能測定するソフトウェアは、Saasプロダクトのため、企業単位でどんなデータが必要かを決めていきます。
データ要件定義の中では、やることは大きく以下の2つです。

・データ定義する項目を決める(ex.ユーザー数)
・データ量がどのくらいを決める(ex.ユーザー数:1万人)

データ定義する項目を決める

データ定義が必要な項目は、今回利用するデータと依存関係のあるデータ項目です。
例えば、企業の地域あたりのユーザー数が利用するデータの場合、そのデータと依存関係のあるユーザー数と地域数という項目のデータ量を定義する必要があります。

データ量がどのくらいを決める

データを定義する項目が決まると、項目ごとのデータ量を決める必要があります。
データ量を決める上で大事なのが想定される最大のデータ量を考えることです。
何年後までを想定した仕様にするか、その時の最大規模の企業での項目ごとのデータ量はどの程度か(企業数も含めて)によりデータ量が変わります。
これは、事業戦略として何年後にどのくらいの規模の企業にプロダクトを納品するか、といったビジネスサイドの話が大きく関わってきます。

データの作成

必要なデータが分かったら、次にそのデータを作成していきます。
ここでのアウトプットは、データ作成手順書、データ作成用のスクリプトになります。今回変更する機能は、まだできていないため利用するデータを作成する必要があります。
データの作成の中でやることは、大きく以下の2つです。

・実際に測定を行うときに必要なデータを作成するプロセスを手順化する。
・データを作成する方法を明らかにし、必要であればスクリプトを作成する。

データ作成手順書

下記のようなデータ作成手順書を作成し、データ要件定義で決めたデータを作成する上で何が必要かを考えます。

no	工程
1	測定環境の構築
2	ユーザーデータの作成
3	地域データの作成
4	地域あたりのユーザーの集計

データ作成方法

データを作成する工程については、大きく下記の方法で実現していきます。

・アプリケーション側からデータを設定する
・スクリプトを作成する

今後の測定も考えた上で一番早い方法を選択し、必要があればスクリプトを新たに作成して、データを作成します。

測定対象のスコープ決め

必要なデータが準備できたら、測定対象のスコープを決めていきます。
ここでのアウトプットは、測定対象の一覧になります。
測定対象は大きく下記の2つがあるので、分けて測定対象のスコープを決めます。

・アプリケーション側で呼ばれる画面、api
・非同期で実行されるバッチ処理

画面、api

画面、apiに関しては、今回大量作成されるデータに関する値が返ってくるものを測定対象とします。
スコープの特定はdevtoolを用いて行います。

バッチ処理

今回のアプリケーションでは、重めの処理を非同期でアプリケーションサーバーとは別のサーバーで実行しています。
api同様に、今回大量作成するデータに対して、CRUD操作を行うものに絞って、測定対象のスコープを決めます。
スコープの特定はソースコードから行います。

まとめ

今回は、性能測定するまでの準備をまとめてみました。
非機能要件を満たしていなかったら、機能要件も見直す必要もあるので、新たに機能を追加する上で性能検証はすごい重要なことだと感じました。
自分でアウトプットしようとすると、怪しい点がいくつも出てきたので、よかったです。
次は具体的に性能測定方法などを書こうと思います。

まだまだ理解が不足していることもあると思うので、ご意見、FBあればお願いします！