UI実装者が書いたシナリオだからこそ、 意味を持つk6負荷試験

Transcript

1. UI実装者が書いたシナリオだからこそ、 意味を持つk6負荷試験 梅木和弥 フロントエンドカンファレンス関西2026
2. はじめに 負荷試験とは。
3. Webアプリケーションエンジニア 梅木 和弥 @umekikazuya プロジェクトで負荷検証を2本担当 k6 を使った負荷テストの連載記事を執筆
4. アジェンダ 今日お話しすること 01 02 03 04 05 従来のやり方と、なぜフロントエンドエンジニアなのか 負荷試験は、これまで誰の仕事だったのか 負荷は、誰がどう作っているのか 負荷の起点と、そのかたちを決めているもの 負荷は、どうやって再現するのか k6 と、妥当なシナリオを書くための知識 意味のある負荷検証とは 何をもって合格とするのか まとめ
5. 01 従来のやり方と、 なぜフロントエンド エンジニアなのか 01 従来のやり方と、なぜフロントエンドエンジニア なのか 02 負荷は、誰がどう作っているのか 03 負荷は、どうやって再現するのか 04 意味のある負荷検証とは 05 まとめ
6. 01 従来のやり方 負荷試験は専任チームや外部ベンダーの仕事?? アプリケーション エンジニア 画面とAPIを実装する 分業の利点 依頼 専任チーム ・ 外部ベンダー シナリオを書く 実行する アプリケーションエンジニアは、検証工程に関わらずに済む。 専門知識も環境の準備も任せられる レポートを返す
7. 01 従来のやり方 ただ。この分担には懸念もある。 シナリオを書く人が、実装を一番知っている人と は限らない 設計 実装 テスト 結果が、実装の改善に戻ってきにくい 負荷試験 リリース リリース直前の、一度 きりの行事になりがち
8. 01 新しい流れ 担い手が変わりつつある これまで 実装 外部に依頼 シナリオ作成・実行 開発サイクル これから 実際の効果 実装 負荷検証 負債が溜まってない段階での改修は修正コストが軽い 非機能要件のコード化が可能 「依頼して待つ」がなくなる 手元や CI で回す レポート
9. 02 負荷は、 誰がどう 作っているのか 01 従来のやり方と、なぜフロントエンドエンジニア なのか 02 負荷は、誰がどう作っているのか 03 負荷は、どうやって再現するのか 04 意味のある負荷検証とは 05 まとめ
10. 02 負荷の起点 最初に負荷を生むのは、クライアントのアプリケーション ユーザーの操作 初期表示、ホバー、ブラ ウザバック、ボタン押下 負荷はここで生まれる クライアント 操作に応じてリクエスト を投げる画面のコード つまり。負荷を最初に生み出すのは?? サーバー 受け取って、データを整 形して返す ストレージ データベースなど
11. 02 UI実装者だけがユーザーの次の一手を知ってる UIの設計判断から、負荷の形を推測することは可能 流入元 ② ① 初期表示のあと ダッシュボード ① 一覧をスクロール ③ ボタンを押す アカウント設定 「このダッシュボードなら、まず この操作をするはず」 ② 流入元から 「このリファラから来たなら、ア カウント設定に飛ぶはず」 デザインチームと議論し、それをコードにしたのはフロントエンドエンジニア ③ スクロールのあと 「ここまでスクロールしたら、ほ ぼ確実にここを押すはず」
12. 02 よくある負荷改善 負荷改善の目は、サーバー側に向きがち ユーザーの操作 クライアント サーバー ストレージ ここは見られていない データ取得の N+1（DBク エリ） I/O の見直し インフラリソース もちろん、これで改善することもある ただ、クライアントは改善の対象として見られていないことが多い
13. 02 それでも出てくる声 「数字は問題ないのに、 なんかもっさりしてない？」 「これ、本当に負荷検証を通ったの？」
14. 02 原因 UIの設計判断で生まれる負荷が、見られていない API仕様書 / IaC 非機能要件 UIの設計判断 負荷シナリオ シナリオに入っていない 負荷検証のシナリオは、API仕様書と非機能要件を照らし合わせて作るものではない
 「実ユーザーの操作を保証出来るか」をシナリオ作成時の起点にすべき
15. 03 負荷は、 どうやって 再現するのか 01 従来のやり方と、なぜフロントエンドエンジニア なのか 02 負荷は、誰がどう作っているのか 03 負荷は、どうやって再現するのか 04 意味のある負荷検証とは 05 まとめ
16. 03 必要な知識 負荷を再現するために必要な要素 エンドユーザーへの理解 ユーザーが次にどこへ進 み、何を繰り返すか + UIの実装判断 その操作で、何本、どの 順で、いつ飛ぶか + シナリオを書く知識 k6 の書き方、負荷試験 の型、ユーザー操作記録 からの変更 = 実ユーザーを想定した
 実際の負荷 どちらも、UIを実装した人が毎日扱っている知識
17. 03 負荷検証ツールに求める要件 再現に求める、4つの要件 01 エンドユーザーの行動が表現で きる 02 03 04 学習コストが低い 画面実装者の設計判断がシナリ オに乗る 日々の開発に組み込みやすい （軽量で、環境に依存しない）
18. 03 k6 という選択肢 k6 は、4つの要件を満たす 要件 k6 では 設計判断がシナリオに乗る 画面の操作単位で group を切り、リクエストの並びをそのまま書け る ユーザー操作を想定できる sleep で操作の間を、シナリオの組み方で操作の比率を表せる 技術的に楽 JavaScript でシナリオを書ける 日々の開発に組み込める 単体のバイナリで動き、手元でも CI でも回せる
19. 03 シナリオの書き方 シナリオは、このくらいの量で書ける import http from 'k6/http' import { group, sleep } from 'k6' export default function () { group('一覧を見る', () => { http.get(`${BASE}/api/products?page=1`) }) sleep(2) // 一覧を眺める時間 group('詳細を開く', () => { http.get(`${BASE}/api/products/${id}`) }) } group 画面の操作のまとまり sleep ユーザーが考えている時間
20. 03 負荷試験の型 負荷試験には、型がある Smoke Test Load Test Stress Test Spike Test Soak Test Breakpoint Test 最小の負荷で、シナリオが正しく動くか 急激な負荷変動の挙動確認 縦軸：同時に操作するユーザー数 横軸：時間 平常時のアクセス数。パフォーマンス目 標を達成できるか。 長時間稼働で劣化やリークがないか 平常を超えたとき、どう劣化するか 破綻点の特定
21. 03 一から書かなくていい 記録した操作を、シナリオに変換できる STEP 1 STEP 2 DevTools の Network タブで右クリック → Save all as HAR npx har-to-k6 recorded.har -o script.js HAR を保存する k6 のシナリオに変換する 記録した操作が、そのままシナリオの叩き台になる
22. 03 必要な知識 負荷を再現するために必要な要素 エンドユーザーへの理解 ユーザーが次にどこへ進 み、何を繰り返すか + UIの実装判断 その操作で、何本、どの 順で、いつ飛ぶか + シナリオを書く知識 k6 の書き方、負荷試験 の型、ユーザー操作記録 からの変更 = つまり、UI実装者だからこそ書けますよね。 実ユーザーを想定した
 実際の負荷
23. 03 日々の開発へ 日々の開発に組み込める 実装を変える 負荷をかける 「ちょっと負荷をかけてみたい」が、 その場でできる レビューで話す 結果を確かめる
24. 04 意味のある 負荷検証とは 01 従来のやり方と、なぜフロントエンドエンジニア なのか 02 負荷は、誰がどう作っているのか 03 負荷は、どうやって再現するのか 04 意味のある負荷検証とは 05 まとめ
25. 04 実体験 はじめて一人称で負荷検証をやった STEP 1 プロジェクト 始動 STEP 2 STEP 3 STEP 4 仕様書レビュー通っ た!! 非機能要件は満たせ た!! 事業側へ提出!! 非機能要件定義 負荷検証を実施 レポートを提出
26. 04 検証レポートへの反応 「何を計測して、 何が得られたのか分からない」 事業側に、検証レポートを出したときに言われた言葉
27. 04 振り返ると 意味を考えずに始めた負荷検証は、泥と化す よくある順番 負荷検証をやる シナリオを作る まず先に 意味のあるシナリオを考える AIに書いてもらう シナリオを作る 泥と化す AIに手伝ってもらう
28. 04 やる意味 そもそも、負荷検証をやる意味は何か ユーザー体験 混雑時でも、ユーザーが操作 を完了できるか ユーザー体験 劣化したときの壊れ方（一部 か全部か、メンテナンス表示 をどう出すか） ユーザー体験 「遅い」というフィードバッ クの原因特定と早期発見 事業・運用 セールや告知での機会損失を 防ぐ 事業・運用 インフラ費用の根拠をつくる 事業・運用 障害対策の訓練（復旧までの 時間） 事業・運用 非機能要件が妥当かを問い直 す 事業・運用 関連リソースへの影響を確か める 「負荷検証をやるから、シナリオを考えよう」では、何の意味も持たない
29. 04 2つの意味 意味は、2つに分かれる 知る（把握する） 保証する 負荷を上げ続け、どこで、どう壊れるかを知る。 壊れたとき、復旧にどんな業務が発生するかを知る 決めた線（点線）の内側にあることを約束する。 このトラフィックなら、この速度とエラー率で安定稼働できる 先ほどの8つの意味は、すべてこの2つに分けられる
30. 04 知るべきだったこと 知るべきだったのは、混雑時のユーザーの操作 問い 1 問い 2 一覧を開き、検索し、詳細を見て、戻る。 混雑していても、この流れを終えられるか 一部だけが遅くなるのか、全部が止まるのか。 そのとき、画面に何を出すのか 最後まで、操作を完了できるか できないなら、どこから、どう壊れるか 操作を完了できないのに「非機能要件は満たしている」は、 意味を持たない
31. 04 結論 意味のある負荷検証にコミットできるのは、 非機能要件をエンドユーザーの視点で 肯定・否定できる、UI実装者
32. まとめ 01 従来のやり方と、なぜフロントエンドエンジニア なのか 02 負荷は、誰がどう作っているのか 03 負荷は、どうやって再現するのか 04 意味のある負荷検証とは 05 まとめ
33. おわりに UI実装者だからこそ 意味を持つ負荷試験!!!! 負荷はどう作られるの？ フロントエンドエンジニアは負荷の再現スキルを保有してるの？ 意味のある検証と意味のない検証？
34. おまけ 01 従来のやり方と、なぜフロントエンドエンジニア なのか 02 負荷は、誰がどう作っているのか 03 負荷は、どうやって再現するのか 04 意味のある負荷検証とは 05 まとめ
35. おわりに 負荷検証を2本やって、得られたこと 手を挙げる人が少ない分、 評価が大きい 同じ8時間でも、機能をひとつ作 るのと、負荷検証の枠組みを作 るのでは、評価のされ方が大き く違った 非機能要件の解像度が上が る ユーザー数、アクティブな時間 帯、本当に使われるのか。この プロジェクトが解決したいこと を考えるようになった レビューの説得力が上がる 負荷の観点から、実装の判断を 根拠をもって話せるようになっ た
36. おわりに CI組み込みについて Github Actions でレポート生成 Artifactを活用 長くても5分以内に収めるのが鉄則 閾値は育てるもの 最初から完璧な閾値を設定する必要。
37. 資料 今日の資料 連載記事 【ハンズオン】k6で始める負荷テスト（全5回） https://www.mochiya.ad.jp/blog/system-dev/detail/load-test-01 教材リポジトリ umekikazuya/k6-sandbox https://github.com/umekikazuya/k6-sandbox
38. ご清聴ありがとうございました。 梅木和弥