Recommendation_of_Gatling.pdf

Transcript

1. Gatling Recommendation of gatling
2. 今日やること
3. Gatlingいいぞ！ あるプロジェクトの負荷試験でGatlingというツールを使ってみた。 https://gatling.io/ 良いツールなので社内に普及させたい！
4. 自己紹介
5. あんただれ？ • 名前　　　　：川嶋 一寿 • チーム　　　：sst（sstってなんのこと？） • 生息地　　　：静岡県静岡市 • 趣味　　　　：酒、ジョギング • 好きな言語　：Scala • その他　　　：専門学校講師、Scalapediaの記事執筆 • Twitter　　　：@cupperservice
6. Gatlingってなに？
7. Gatlingとは GatlingはHTTPサーバのための負荷テストツールの一種 負荷テストツールは他にも多くのツールが存在する • JMeter • Locust • ab • etc... awesome-http-benchmark 主要なツールについてまとめられている
8. JMeter https://jmeter.apache.org/
9. Locust https://locust.io/
10. シナリオは スクリプトで！
11. シナリオをスクリプトで書けるもの 名前 スクリプトの種類 ライセンス Gatling Scala Apache 2.0 Locust Python MIT Artillery JavaScript MPL2 k6 JavaScript AGPL3 wrk Lua Apache 2.0
12. なぜGatling？
13. Locustは嫌だ！
14. Locustの問題 去年からシステムの限界性能の測定のためにLocustを使用していたが、測定に非常に 時間がかかる問題があった。 測定時間10分のデータを取るために１時間ほどの作業が必要だった。
15. Problem 1 手動でユーザー数を変更しrps, response time, cpu利用率等を観測しながら同時に 実行するユーザー数の限界値を決めるため、測定に多くの時間を必要とした。 以下の手順で限界性能を測定していた。 1. 以前の計測結果からユーザー数を決定して測定 (測定時間: 1分程度) 2. CPUに余裕があり、レイテンシーが悪化していなければユーザー数を増やして再度 測定 3. CPUに余裕がなかったり、レイテンシーが悪化した場合は、ユーザー数を減らして 再度測定 4. 一番性能が良いユーザー数で再度測定 (測定時間: 10分程度)
16. Problem 2 テストの経過時間を軸にしたデータ(rpsやresponse time)がレポートに出力されないた め、ある時点で問題があってもレポートを取得した時点で問題がなければレポートから 判断できない。 画面には表示されているため、必要であればスクリーンショットを採ってエビデンスにす る。（スクリーンショット職人になりたいなら問題ない）
17. Problem 3 テストの実施時間を指定できない。 実施時間を確認し手動でテストを停止する必要がある。 そのため、テストを流しておいて他の作業をすることが難しい。（テストを止めるのを忘れ る可能性がある） 長時間ランニングテストの場合は、夜間流しておいて朝に手動で停止した。
18. Problem 4 Pythonのインデント構文が肌に合わない @task(1) def scenario1(self): response = self.login("login_id00", "password00") token = response["token"] print(token) self.logout(token) こういうの書けない Dottyはインデント構文サポートするんだよね。。。
19. 他のツールを探す
20. Locust以外のツールを探す！ 次の条件に当てはまるツールを探した。 • シナリオをスクリプトで書くことができること • 十分な負荷をかけることができること • 詳細なレポートが出力されること
21. Locust以外のツールを探す前に。。。 Scalaでシナリオを書くツールを作ろうと思っていた。。。 すでにあった。。。
22. Gatlingは使えそう！ • 次の条件はクリアしている ◦ シナリオをスクリプトで書くことができること ◦ 十分な負荷をかけることができること ◦ 詳細なレポートが出力されること • お客様の他のプロジェクトでも使っているそうなので、使うこと に問題はなさそう 面倒な調整不要！
23. 検証結果
24. ちまちました作業が不要！ 以下のシナリオを用意することで、作業時間を短縮 ・5日かかっていた作業を2日に短縮（予定） • 測定するユーザー数の最小値と最大値を決める • ユーザー数を最小値から最大値まで徐々に増やしながら測定 ユーザー数の範囲が100〜4,000 10秒ごとに100ユーザーずつ増やして測定 このシステムの限界値は ユーザー数 4,000 RPS 10,000 rps
25. Gatlingの特徴
26. 商用利用 • OSS版とEnterprise版がある • OSS版のライセンスはApache 2.0 • OSS版で利用できない機能 ◦ 分散モード ◦ モニタリング項目(TCP connection, DNS resolutions, ...) ◦ ライブレポート ◦ 実行履歴の管理 ◦ LDAP認証 ◦ 他
27. マルチスレッド • JavaVM上でマルチスレッドで動作する locustはシングルスレッド • Akka / Nettyを使った非同期処理
28. シナリオ シナリオはScalaで記述する package cupper.scenario import io.gatling.core.Predef._ import io.gatling.http.Predef._ import scala.concurrent.duration._ class FirstTest extends Simulation { val protocol = http .baseUrl(http://localhost:3000) .headers(Map( HttpHeaderNames.ContentType -> HttpHeaderValues.ApplicationJson, HttpHeaderNames.UserAgent -> "gatling" )) val user1 = scenario("first test") .exec(http("get movies") .get("/movies") .check(status.is(200)) ) setUp(user1.inject(rampUsers(1000) during(30 seconds)).protocols(protocol)) }
29. レポート とても素敵なグラフィカルなレポートが作成される。 OSS版でも同じ！
30. 多くの測定パターン • ユーザー数の指定 • 実施回数指定 • 期間内のユーザー数の分布（一定、ランダム） • 実施時間の指定 • 経過時間とともにユーザー数を増やす
31. Closed/Open Workload Models • Closed Workload Model 一定数のユーザーが連続的にリクエストを発行するケース。 同じユーザーからのリクエストは、前のリクエストが完了した後に発行される。 社内システムなど同時ユーザー数を制限するシステムに対するテストで有効 • Open Workload Model システムが現在処理しているリクエスト数に関係なくユーザーがリクエストを発行す るケース。 同時ユーザー数を宣言できないシステムに対するテストで有効 多くの一般向けのWebサイトのテストで有効
32. Jenkinsとの連携 Jenkinsと連携してGatlingを起動することができる
33. 分散構成 複数のマシンを使用してGatlingを実行できる。 [Enterprise版] クラウド環境(AWS, GCP, Azureなど)にインスタンスをデプロイし てテスト終了後にインスタンスを閉じる機能が提供されている。 [OSS版] 自分でスクリプトを組む必要がある。
34. Scala...難しそう
35. 怖がらなくても大丈夫！ • とっても簡単（Easy） • モナドとか圏論とかわからなくても大丈夫 公式ページにも下のように書かれている Gatling simulation scripts are written in Scala, but don’t panic! You can use all the basic functions of Gatling without knowing much about Scala. In most situations the DSL will cover most of your needs and you’ll be able to build your scenarios.
36. Sample
37. Sample code package cupper.scenario import io.gatling.core.Predef._ import io.gatling.http.Predef._ import scala.concurrent.duration._ class FirstTest extends Simulation { val protocol = http .baseUrl(http://localhost:3000) .headers(Map( HttpHeaderNames.ContentType -> HttpHeaderValues.ApplicationJson, HttpHeaderNames.UserAgent -> "gatling" )) val user1 = scenario("first test") .exec(http("get movies") .get("/movies") .check(status.is(200)) ) setUp(user1.inject(rampUsers(1000) during(30 seconds)).protocols(protocol)) } ベースURL 共通のリクエストヘッダー テストシナリオ リクエストURL レスポンスの確認 シナリオのシミュレーション 30秒間で1,000ユーザーがシナリ オを実行する Simulationをextends
38. Execution result
39. Concepts
40. Main concepts Name Description Virtual User シナリオを実行するユーザーを表す 独自のデータ(パラメータやCookieなど)を持つ Scenario ユーザーの行動を表す一連の操作を記述する Simulation どのように負荷をかけるのかを記述する Session ユーザーごとのデータ Feeders 外部(ファイルなど)からSessionにデータを注入する Checks レスポンスをチェックしたり、チェック結果を Sessionに格納する Assertions テストの成否条件を記述する
41. Demo
42. シナリオ テスト対象は以下のシナリオ オープンモデルで限界値を測定する 1. ECサイトにログイン 2. 商品を検索 3. 商品の内容を確認 4. ショッピングカートに登録 5. 購入 or 取り消し 6. ログアウト Github: https://github.com/cupperservice/gatling-sample
43. 必要なソフトのインストール Gatlingを実行するには以下が必要 • Java 64 bit Open JDK 8 ro Open JDK 11 • sbt 0.13.6以上 今回はSDKMANを使ってインストールする
44. 注意点
45. OS Turning GatlingはFDを多く消費するため、OSのチューニングが必要 チューニング内容は参照URLを参照
46. Session is immutable Sessionはimmutable exec(session => { session.set(“key1”, “value1”) session.set(“key2”, “value2”) }) exec(session => { session .set(“key1”, “value1”) .set(“key2”, “value2”) }) exec(session => { session.setAll( (“key1” -> “value1”), (“key2” -> “value2”)) }) NGなコード key1の値は無効 OKなコード
47. コネクション注意！ shareConnectionsを有効にしたほうが良いかも。。。 Gatlingは仮想ユーザーごとにコネクションプールを持つ。 これが原因かはわからないが、shareConnectionsを有効にしな いと十分な負荷がかからなかった。
48. 今後の課題
49. テストの中断 Assertionsでテストの成否は判定することができる。 しかし、テストを中断することはできない。 　↓↓↓ システムの限界を超えた負荷をかけ続けることになる。無駄 　↓↓↓ テストに失敗（例えば、500系のステータスコードが帰った場合な ど）した場合、その後のテストを中断する仕組みを入れたい。
50. 分散構成の自動化 OSS版で分散構成を組むにはスクリプトを組む必要がある。 ↓↓↓ 非常に面倒くさい！ ↓↓↓ Enterprise版のように自動で必要なEC2インスタンスを立ち上げ て、Gatlingを実行するようにしたい。
51. 最後に
52. これを機にScala使ってみない？ 2020年度内にScala 3がリリースされる予定 　ロードマップ 興味のある方がいれば勉強会を開きます！ こちらもよろしく！ scalapedia
53. Thank you for listening