負荷試験Night#1 負荷試験2023年トレンド

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Copyright Drecom Co., Ltd. All Rights Reserved. 自己紹介 •Tsunenori Ohara / おーはら • Twitter(X): @ohrdev • GitHub: @ohr486 •Work • 株式会社ドリコム SREソリューション部部長 • 負荷試験のコンサル/負荷試験SaaS開発/SRE活動/etc • 1案件/月程の頻度で社内外システムの負荷試験を実施 • 3-5アプリ/年程の頻度で負荷試験のレビュー • Elixir/Erlang/HCL/Ruby/etc •OSS/Community • tokyo.ex/JapanElixirAssociation/Erlang&ElixirFest • プログラミング言語/クラウド/テスト/ガジェット •Hobby • 仏像制作/写経/寺社仏閣/FF14/UltimaOnline/自転車

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Copyright Drecom Co., Ltd. All Rights Reserved. このセッションのゴール • セッション終了時の状態 • 「負荷試験をしてね」と言われた時、ゴールまでの流れが想像できる • 話すこと • 負荷試験の基本部分（流れ） • 負荷試験をする際のツールや方法の選択肢 • よく使われているツールやサービス • 話さないこと • 個別の試験ツールの詳細 • 具体的なチューニングの方法や手法

Slide 7

Slide 7 text

Copyright Drecom Co., Ltd. All Rights Reserved. 事前アンケート内容（サンプル数15x） Q1. 今までに負荷試験を実施されたことはある？ Q2. Q1で「はい」: 負荷試験の頻度はどれくらい？ Q3. Q1で「はい」: 負荷試験ツールは何？ Q4. Q3で「その他」: 負荷試験ツールは何？ Q5. 負荷試験をする際の一番の困りごとは？ Q6. Q5で「その他」: 負荷試験をする際の一番の困りごとは？そこそこサンプル数が多く、有用な内容だったので、生のアンケートデータは個人情報をマスクした形で後ほど公開

Slide 8

Slide 8 text

Copyright Drecom Co., Ltd. All Rights Reserved. なぜ負荷試験をするのか • ユースケース毎の応答性能の推測 • 高負荷時の性能改善 • 必要なハードウェア選定 • クラウド利用で重要性は薄れつつある • システムのスケール性の確認 • サーバーを倍にすればスループットは倍になるか？ • システムのボトルネックは？ • システムのスケール特性の把握 • 将来的にスケールできるアーキテクチャ？ Cloudでサービスを運用する時代これまでの負荷試験簡単にサーバーの調達/変更が可能に

Slide 9

Slide 9 text

Copyright Drecom Co., Ltd. All Rights Reserved. 負荷試験のカタ • 性能指標 • スループット • レイテンシ • データの読み方 • ツール • 攻撃ツール • モニタリングツール • プロファイリングツール • サイクル • プランニング • ツール選定 • 試験環境 • PDCA • チェックポイント • 1台のWebサーバーに対する試験 • ロードバランサーに複数の Webサーバーがある時の試験

Slide 10

Slide 10 text

Copyright Drecom Co., Ltd. All Rights Reserved. 負荷試験の性能指標 • スループット(rps) • 単位時間に処理を行う量（ex. 秒間のHTTPリクエスト数, request per sec • レイテンシ(ミリ秒) • 処理時間、観測者によって変わる（ユーザー/システムから見た場合 • 負荷試験の文脈ではシステムから見た処理時間（ネットワーク時間を除く • データの読み方 • レイテンシは平均ではなくパーセンタイル値で判断する • よくある間違い • ⇨ システムの性能を平均値で判断、平均値は悪い値が丸まるので良い結果に見える • ※ Nパーセンタイル = 結果が悪いデータの(100-N)%を除外した中の最悪値 • ⇨ 我々がよく利用するパーセンタイル値 =99%tile, 95%tile, 90%tileあたり

Slide 11

Slide 11 text

Copyright Drecom Co., Ltd. All Rights Reserved. 負荷試験のツール • 攻撃ツール • 負荷をかける側のツール • JMeter,Locust,Gatling,Tsung,k6,... • モニタリングツール • 負荷をかけられる側のシステムのリソースのモニタリング • クラウドのモニタリングサービス(ex. AWS->CloudWatch, XXX-Insight • プロファイリングツール • ミドルウェアやアプリ内部の挙動の解析 • NewRelic, DataDog,... • DB,JVM,...

Slide 12

Slide 12 text

Copyright Drecom Co., Ltd. All Rights Reserved. 負荷試験のサイクル • プランニング • 目的の確認 … (ex. ユースケース毎の応答性能推測 , スケール特性の確認, … • 前提条件の確認 … (ex.試験時のデータ量/運用3年の状態,リリース直前,... • ユースケース洗い出し … (ex. シナリオ/DB参照/更新/外部通信有無/頻度,... • ツール選定の軸 • 複雑なユースケース/シナリオに対応できるか • 高い負荷をかけれるか • 試験環境 • 外部システムとの通信の有無 • 本番環境と同じ構成か(開発環境だと意味がないケースも ) • PDCA • P: 試験計画策定 • D: 試験準備/試験実施 • C: 試験結果分析 • A: レポーティング/改善(チューニング) このサイクルをなるべく高速に多く回したい様々な自動化/効率化のサービス/取り組み ⇨ 負荷試験/クラウドサービスの利用

Slide 13

Slide 13 text

Copyright Drecom Co., Ltd. All Rights Reserved. 負荷試験のチェックポイント 1台のWebサーバーに対する試験のチェックポイント 1. ツールの検証 a. 正しく攻撃できているか b. 静的ファイルの取得であれば十分高速か 2. WebFrameworkの検証 a. 単純なhello-worldを返す処理は十分高速か 3. 環境の検証 a. 参照系の処理は高速に応答できるか b. 更新系の処理は高速に応答できるか c. 外部サービスと連携する場合は正常に処理できるか 4. シナリオの検証 a. ユースケース毎のシナリオが通るかロードバランサーに複数のWebサーバーがある時のチェックポイント 1. スケール性の検証 a. トラフィックに応じてスケールアップするか b. トラフィックに応じてスケールインするか 2. ツール検証 a. 攻撃サーバーをスケールアウトした時、どこまでの限界性能がでるか

Slide 14

Slide 14 text

Copyright Drecom Co., Ltd. All Rights Reserved. 我々のよくある失敗事例 •例)ソーシャルゲーム案件 • リリース後、即緊急/長期メンテナンス • ロードが進まない • ゲーム中の通信エラーが頻発 •原因 • トラフィックの見積もりミス • データ量の見積もりミス • 試験結果の評価のミス • 簡単にスケールできないアーキテクチャ • リリース直前の負荷試験 • 間違った負荷試験方法 • etc 正しい負荷試験を実施していれば、助かったサービスは数多くあった正しい型で試験をしていれば、助かったかもしれない項目

Slide 15

Slide 15 text

Copyright Drecom Co., Ltd. All Rights Reserved. 近年の負荷試験の傾向 • 通信方式の多様化 • HTTP/1.1, HTTP/2, … • REST, WebSocket, GraphQL, gRPC, … • データ形式の多様化 • JSON, XML, MessagePack, ProtocolBuffer, … • ツールの多様化 • クラウド系サービスもちらほら • 試験/運用環境はクラウド前提 • スケールできることが前提 • スケール特性の確認が主目的利用技術(設計)の多様化必要なツールも選択肢が増えたとりあえずJMeterだけ使っていればよかった時代は終了試験の目的が、性能把握からスケール性の確認にシフトクラウド型のサービスにより自動化や効率化がしやすく高頻度/高速でサイクルをどれだけ回せるかが重要に

Slide 16

Slide 16 text

Copyright Drecom Co., Ltd. All Rights Reserved. 近年の負荷試験の傾向 • 変わったこと • 目的 • 性能の推測 ⇨ スケール性の確認 • ツールのバリエーション • JMeterだけでなく、多くの選択肢がとれるように • クラウド型のサービス • 求められる(試験のサイクルの)スピード • より高速に、より頻繁に、よりカジュアルに • クラウド/インフラのセッティングが変わったタイミングでも試験が求められる事も • スケール特性が変わってしまうため • 変わらないこと • 基本的な試験のやりかた（カタ）

Slide 17

Slide 17 text

Copyright Drecom Co., Ltd. All Rights Reserved. クラウド型負荷試験サービス近年、様々なサービスが出てきている海外系（有名どころ、小規模なサービスは多数） • https://grafana.com/products/cloud/k6/ • https://www.blazemeter.com/ • (https://www.postman.com/) • https://www.flood.io/ • https://loader.io/ • その他、多数国産系 • 成功しているところは（多分）まだなさそう • https://www.lp.mxload.mx/ （It’s me!）ステマ

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Copyright Drecom Co., Ltd. All Rights Reserved. 答え合わせ: Q3. 負荷試験の利用ツール • 61/103: JMeter • 30/103: k6 • 24/103: Locust • 16/103: Gatling • 13/103: Apache Bench • 5/103: Vegeta • 3/103: wrk • 1/103: Artillery • 1/103: Tsung • 7/103: その他

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Copyright Drecom Co., Ltd. All Rights Reserved. 答え合わせ: Q6. 試験時の困りごと(その他) • 7: 環境関連（データが準備できない、環境がない、準備が大変） • 7: シナリオ関連（悩む、作るのが大変、アプリに追従できない） • 4: 定期実行・自動化（定期的に実行したい、自動化したい） • 4: 試験結果（結果の判断ができない、レポート作るの大変） • 2: ツール関連（適切なツールがわからない、選定できない） • 2: 工数関連（工期が獲得できない、予算がない） • 1: SPAの場合のやりかたがわからない

Slide 30

Slide 30 text

Copyright Drecom Co., Ltd. All Rights Reserved. まとめ • 負荷試験のツールやサービスは多様化しても、基本は変わらない、負荷試験の「カタ」が大事 • クラウドで運用するサービスの負荷試験では「性能の推測」だけでなく「スケール性の確認」も重要 • より高速に、より頻繁に、よりカジュアルに負荷試験を実行できる事が求められてきている • 「期間が足りない」「できるエンジニアがいない」の課題をかかえている人が多い • クラウド型負荷試験サービスの利用

Slide 31

Slide 31 text

Copyright Drecom Co., Ltd. All Rights Reserved. お願い • イベントの改善の為、アンケートにご協力ください https://docs.google.com/forms/d/e/1FAIpQLSfW2lmqLurHi_yzc2vl Es1twUhaq9reMEtHA4-0L3lPCoiSGw/viewform ※ イベント終了後、Twitter(X)にてお知らせします