チューニング結果を各チームの VM に反映し、評価スクリプトをそれぞれの VM 内で実行することで採点ができます。
評価スクリプトでは、以下のプロセスで評価を行います。
- Step1. データベースを初期状態に戻す (顧客データをセット)
- Step2. 簡易 DB マイグレーションの実行
- Step3. API 動作テスト (e2e テスト)の実施
- Step4. 負荷試験の実施
- Step5. スコアの計算
- Step6. スコアの表示 & 運営への送信
Step3 ではAPI 仕様書をベースに、主要な要件を満たしているかをチェックします。問題があった場合はそこで採点が停止します。
Step6 で画面に表示されたスコアが、その時点のチームの持ち点になります。
*スコア上位グループについては、成果物に対して追加で審議される場合があります。
評価スクリプトを実行する度にデータベースの状態は戻ってしまいますが、あらかじめ登録された SQL を実行させ、テーブル等への変更を採点前に反映させることができます。
webapp/ディレクトリのmysql/migration/に置かれた{数字}_*.sql ファイルは、採点前に実行されます。
0_name.sql, 1_name.sql...という名称のファイルを置いておくことで、番号が若い順に実行されていきます。
負荷試験はシナリオテストの形で行われます。つまり、アプリケーションの想定される利用シナリオについて複数のユーザが同じ操作を行い、そのシナリオを完了するまでにそれぞれどれだけの時間がかかるかを持ってスコアとします。
負荷試験では、特性の異なる複数のエリアについてそれぞれ下記のシナリオを実施します（より詳しい定義は 業務背景によるレギュレーションも参考にしてください）：
- ディスパッチャーとしてシステムにログイン
- 自身の担当地域の依頼の中でまだ対応されていないものを古い順に表示
- 最も古いものを選択し、その依頼の位置情報から、現場に最も近い位置にいるかつ、対応可能な状態のレッカー車を検索する
- 検索されたレッカー車を依頼に割り当てるリクエストを送る
※ 2. についてはリストにユーザのプロフィール画像を表示する処理が追加で行われます。画像の取得は、依頼のリストが表示されてから３秒間待機し、その時間内に表示された画像数を使用します
このシナリオが複数のディスパッチャーによって同時に実行される状況を想定します。
- シナリオの途中でのチェック（上記のシナリオの各ステップが完了しているか）に失敗した場合、そのシナリオは中断され新たにシナリオを開始します。
Step4 では、負荷試験ツール「k6」を用いて下記のような流れで負荷試験を行います。
- エリア２からエリア７までの６つの特性の異なるエリアについて時間をわけて（シナリオが重なる部分あり）シナリオを実施します。
- 同時に一つのエリアに対して複数のシナリオが実施されるものもあります。
Step5 では、さらに以下のようにスコアの計算を行います
- Step4.の結果から、各エリアでシナリオのどの部分までを実施できたか、を用いて計算を行います。
- エリアの規模によって異なる重みを含め、それぞれのシナリオでどれだけ処理を実施できたか、でスコアリングを行います。
- それぞれのシナリオについて、下記に定めた補正係数を成功応答回数にかけた点数を基本点とする。
補正係数:
| チェックポイント | エリア2 | エリア3 | エリア4 | エリア5 | エリア6 | エリア7 |
|---|---|---|---|---|---|---|
| ログイン | 10 | 10 | 10 | 10 | 10 | 10 |
| 保留中の依頼一覧取得 | 10 | 10 | 50 | 50 | 50 | 80 |
| プロフィール画像の取得（1つの画像につき） | 1 | 1 | 1 | 1 | 1 | 1 |
| 注文詳細取得 | 10 | 10 | 20 | 20 | 20 | 30 |
| 最寄りのレッカー車検索 | 50 | 100 | 150 | 200 | 300 | 400 |
| 配車リクエスト | 200 | 300 | 400 | 500 | 600 | 700 |
| ログアウト | 30 | 30 | 30 | 30 | 30 | 30 |
※ 「ログイン」「ログアウト」「プロフィール画像取得」についてはそれぞれで最大 1000 点の加算が上限となります。
※ 採点についてより詳しい情報は /benchmarker 配下を参考にしてください。