Upgrade to Pro — share decks privately, control downloads, hide ads and more …

kintoneのリリースを加速する!性能検証自動化 / 20181027 Performanc...

szkayeah
October 27, 2018

kintoneのリリースを加速する!性能検証自動化 / 20181027 Performance Test

2018/10/27 ヒカラボ関西
有名サービス開発エンジニア登壇のLT大会~プロダクト開発における自動テスト環境について~

kintoneのリリース期間を短縮するために、どこに手を入れるか検討し、性能検証の自動化に至ったお話です。

szkayeah

October 27, 2018
Tweet

More Decks by szkayeah

Other Decks in Programming

Transcript

  1. kintoneのリリース 1月 2月 3月 4月 5月 開発期間 試験期間 開発期間 試験期間

    開発期間 試験期間 リリース リリース リリース
  2. kintoneのリリース 1月 2月 開発期間 試験期間 改修 改修 改修 改修 性能検証

    脆弱性検証 回帰試験 移行試験 改修 機能試験は 各改修毎に実施
  3. kintoneのリリース 1月 2月 開発期間 試験期間 性能検証 脆弱性検証 回帰試験 移行試験 【補足】

    期間は長いが 開発期間にスプリントごとに 小分けで実施している
  4. 従来の性能検証 • ScaleBench • http://developer.cybozu.co.jp/archives/tech/2010/05/scalebench-c8c6.html • 内製の負荷テストツール • VU(バーチャルユーザ)という指標で性能を数値化 •

    シナリオでユーザの操作を定義 • 徐々に操作ユーザ数を増やして負荷を上げる • 安定して操作できるユーザ数がVU(大きいほど良い)
  5. 従来の性能検証 • 時間が掛かる(特に準備) • 手動実施しているため • 指標の解釈が難しい • 「前月版は1200VUで今月版は1100VUなので9%劣化です」 •

    どの操作が遅くなったのか分かりづらい • 様々なシナリオが混ざっている状態での指標 →単に自動化するだけでは満足できなさそう…
  6. 従来の性能検証 • 時間が掛かる(特に準備) • 手動実施しているため • 指標の解釈が難しい • 「前月版は1200VUで今月版は1100VUなので9%劣化です」 •

    どの操作が遅くなったのか分かりづらい • 様々なシナリオが混ざっている状態での指標 →「性能検証で何が出てくると嬉しいか」から考えた
  7. パフォーマンステスト • 計測:Junit • ApacheCommonsのStopWatchを使用 • 計測結果の保存:Elasticsearch • 計測結果の可視化:Kibana •

    性能チェック結果:kintone →以前は結果の保存・可視化もkintoneで行っていたが Kibanaの可視化が強力だったので移行
  8. ロードテスト • 計測:Locust • 計測結果の保存:Elasticsearch • 計測結果の可視化:Kibana • リソースモニタ:Prometheus •

    リソース使用量の可視化:Grafana →リソース周りは元々開発環境にあったものを転用 →ひとつのダッシュボードにまとめるメリットがなかった
  9. 2つの性能検証 • 絶賛調整中 • まだ開発プロセスに組み込まれていない • 1日4回実行はしている • パフォーマンステスト:4.5時間/回 •

    ロードテスト:2時間/回 • ある程度過去の性能劣化は検知できている • 一部ケースの安定化が課題