順次追記していく
クラウドにおける負荷試験の目的
- 各種ユースケースを想定し、それぞれにおけるシステムの応答速度を推測する
大量のデータ登録
データ容量の増加
ユーザ数の増加
バッチ処理とのバッティング
システムが異常系を返す
再起動直後でキャッシュが効かない場合
など
- 高負荷時におけるシステムの性能改善を行う
応答速度の低下
ロックの競合
エラー発生
データ不整合
- 目的の性能を提供するために必要なハードウェアをあらかじめ選定する
クラウドはあまり気にしなくて良い
- システムがスケール性をもつことを確認する
- システムのスケール特性を把握する
どこを上げれば性能が上がるのか
上げるためのダウンタイムはどれくらいか
どこまで上がるのか(限界がある場合は今の構成でどれくらいのユーザ数増加まで耐えられるのかを把握する)
性能指標
大きく分けて 2 つ
- スループット
単位時間あたりに捌ける処理数
-
レイテンシ
1 の処理をさばくのにかかる時間
- ユーザ目線のレイテンシ
リクエストを投げてからレスポンスを受け取りブラウザで描画するまでの時間
- システム目線のレイテンシ
→web システムで制御可能なのはこっち。
一般的に言うレイテンシはこっち
Web のシステムがリクエストを受け取ってからレスポンスを返すまでの時間
システムは複数のサブシステムから成る(Web,API,DB など)
- システム全体のスループット…全サブシステムのうち、もっともスループットが低い箇所に依存する
- システム全体のレイテンシ…待ち時間も含めた全サブシステムのレイテンシの合計値
スループットの改善
スループットがもっとも低い箇所(ボトルネック)を特定
→ 改善する
→ 別の場所がボトルネックになる
→ 改善する
の繰り返し
レイテンシの改善
待ち時間を含んでいるのがミソ
一見処理時間が長いサブシステムが原因に見えても、その先のサブシステムのスループットが低く、待ち時間が発生してるということもある。
ボトルネック関係なく、短くした分全体の性能の改善につながる
負荷試験計画
-
スケジュール
- 余裕を持ったスケジュールを。改善の時間も込みで考える
-
目的
- 各種ユースケースを想定した応答速度の推測
- サービス利用開始時にユーザが大量登録
- データ量の増加
- 急激なアクセス増加
- バッチ処理とのバッティング
- システムが異常系を起こす
- 再起動後にキャッシュが揮発している
- 高負荷時の性能改善
- ハードウェアの選定
- スケール性があることの確認
- スケール特性の把握 など
-
前提条件
- 試験範囲
- ユーザ数、データ量
- 外部システムのレイテンシ、制約
- 目標値の継続時間(一瞬満たせばいいのか何時間維持、など)
- 負荷のかけかた(ネットワーク経路など)
-
目標値
- 利用するツール
- 試験環境
- シナリオ
目標値の決め方
スループットが上がる → レイテンシーが上がる、の流れ
- 正常…スループットが上がってもレイテンシが上がらない
- 全体的に遅い…スループットが低くてもレイテンシが遅い
- 性能不足…スループットが上がるとレイテンシが急激に上がる
スループットの目標値
一定時間にどの程度アクセスがあるか
- 1 日の利用者数(A)
- 1 人あたりの 1 日の平均アクセス数(B)
- 1 日の平均アクセス数に対する最大ピーク時の倍率(C)
を求める
(A _ B) / 86,400 秒= 1 日の平均 rps
1 日の平均 rps _ C = 最大ピーク時の倍率 = 最大 rps
最大 rps に安全係数(2 とか 3)をかけて数字をスループットの目標値とする。
この目標値が達成できれば想定されるアクセスを捌ける、と考える。
例
スループット=20000DAU
1 人あたりの平均アクセス数=50
1 日平均アクセス数に対する最大ピーク時の倍率=5 倍
安全係数=2
rps= 30,000 _ 50 / 86,400 _ 5 * 2 = 173.6rps
高負荷シナリオの決定
- アクセス頻度の高いページ
- リソース消費量が高い ことが分かってるページ
- DB を参照/更新するページ
- 外部と通信するページ