前回の負荷テスト実施時に指標とした数値、計算方法をご紹介します。
いろいろな計算方法があると思いますので、一例としてご認識ください。

数値のサンプル

項目 例の値 単位 備考
A 登録ユーザ数 1,000,000 DBレコード数の目安に
B DAU 登録ユーザ数 100,000 -
C 一人当たりの平均プレイ時間 0.5 時間 - シナリオ分析より求める
D 平均アクセス間隔 0.86 D = 86400 / B
E 平均滞在時間 1,800 E = C * 3600
F 同時アクセス数 (約) 2,083 F = E / D
G ピーク時のアクセス倍率 2.5 -
H ピーク時の同時アクセス数 (約) 5,208 H = F * G
I 平均アクセス回数 80 - シナリオ分析より求める
J 平均通信間隔 22.5 J = E / I
K 同時リクエスト数 (約) 230 K = H / J
L トランザクション発生率 75.0 % - シナリオ分析より求める

※計算式の修正について
2017年09月29日 に計算式の誤りを修正しました。
具体的に 「B.平均アクセス間隔の割る / 割られる数」が逆で、DAU を増やすほど同時アクセスが少なくなる状態でした。
誤りについてご迷惑をおかけしましたことをお詫びいたします。

また、項目に「ピーク時のアクセス倍率」を追加しました。

解説

A.登録ユーザ数、B.DAU

想定の登録ユーザ数、アクセス数をざっくりと見積もります。
サービス開始から 2 - 3か月ほど経過した時点での想定数値 を設定するのがポイントです。

C.一人当たりの平均プレイ時間、E.平均滞在時間

これは「 あるユーザがアクセスしてから離脱するまで 」の平均値を指します。
モデルケースを作成し、ユーザが 1回 に「連続してサービスを利用する時間」の平均値を割り出して設定してください。

E.平均滞在時間は単位を変換しただけのものです。

数値モデルが、ソーシャルゲームがベースのため「プレイ時間」と表現しています。

D.平均アクセス間隔

新しいユーザが「どのくらいの頻度でサービスにアクセスするか」という数値です。

DAU は言葉通り「1日にアクセスするユーザ数」ですから、これを1日の秒換算 86400秒( 24 * 60 * 60 )で割り、「 平均してユーザがサービスにアクセスする間隔 」を求めます。

F.同時アクセス数、H.ピーク時の同時アクセス数

平均滞在時間と平均アクセス間隔の重複から、「 ある時間、同時にサービスにアクセスしているユーザの数 」を求めます。

負荷テストでは同時接続がもっとも問題な指標です。
それは「 瞬間あたり、どれだけサーバリソースの奪い合いが発生するか 」に直結するためです。

ピークタイムのアクセス数に耐えられるようにするため、「日付の切り替わり」や「イベント開始、終了直前」など、アクセスが集中しがちなタイミングで どれだけのユーザが集まるかを慎重に検討 します。

今回は平常時とピークタイムの差は 2.5倍 としましたが、サービスの種類に左右されますため、見極めが大切です。

I.平均アクセス回数、J. 平均通信間隔

1ユーザ が平均滞在時間中に「 どの程度サーバにアクセスするか 」の数値です。

実際にサービスを利用してモデルケースを作成し、数値を平均化したものを指標にすると良いでしょう。

モデルケースは、「上級ユーザ」や「週末だけ利用するユーザ」など複数の利用形態を想定すると、より信頼度が高まります。

また、この数値は 提供するサービスによって大きく値が変化 します。

例えばこのような具合です。

  • ブラウザベース
    画面遷移ごとに 1 リクエストが発生

  • ネイティブアプリ用のAPI
    状態が変わる場合に 1 リクエストが発生するため、アクセスの間隔が広い

K.同時リクエスト数

ピーク時の同時アクセス数に平均通信間隔をかけたものを「 同時リクエスト数 」とみなします。
この数値が高ければ高いほど、アクセスが集中するという意味です。

負荷テストではこの 同時リクエスト数をクリアできることを目標 にシナリオを組み立ててテストを実施していきます。

L.トランザクション発生率

「データベースの更新を伴う通信」がどのくらいの割合で発生するかの指標で、データベースの負荷分散に関わる数値です。
用意したモデルケースを分析して、数値を求めましょう。

例えばネットショップなら「データベースの更新」よりも「データベースからのデータの参照」が圧倒的に多くなることが予想されます。
これは、平均アクセス間隔の欄で示したように、提供するサービスによって傾向が異なります。

最後に

どの数値も見積もりが甘く、精度が低ければ 信頼の薄いテスト となってしまいます。
また、 負荷の高い通信 のみでシナリオの組み立ててしまうと良い数値が出ずに苦しむことになってしまいます。

各数値、シナリオの決定は慎重に、実態に即した内容で検討してください。


[24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

安井 真伸,横川 和哉,ひろせ まさあき,伊藤 直也,田中 慎司,勝見 祐己
出版社:技術評論社  発売日:2008-08-07

Amazonで詳細を見る