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

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

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

Transcript

1. サイボウズ株式会社 西日本開発部 鈴木 亜耶 @szkayeah kintoneのリリースを加速する！ 性能検証自動化 2018/10/27 ヒカラボ関西 キントーン
2. はなすひと 鈴木 亜耶 @szkayeah • Webアプリケーションエンジニア • 2017年1月に中途入社(Uターン) • 好き：CI・自動化・モニタリング • 大好き：紅茶 すず き あ や
3. おしながき • kintoneってなーに？ • リリースの変遷 • 性能検証の自動化 • 内容 • 仕組み • まとめ
4. kintoneってなーに？
5. kintoneとは サイボウズの クラウド型の グループウェア
7. ドラッグ＆ドロップでフォーム作成
8. 作ったフォームでデータ登録
9. データに付随するコミュニケーションはコメント欄で
10. (弊社では見たよでも使われているいいね機能)
11. 登録データは一覧で見たり
12. グラフ化したりできる
13. リリースの変遷
14. kintoneのリリース • 少しずつ間隔が短くなっている(緊急リリース除く) • 2015年：5回 • 2016年：8回 • 2017年：10回 • 2018年：12回＋α • 現在は基本1か月に1回リリース
15. kintoneのリリース • 間隔が短くなった要因 • もっと早く出したいという思い • やってみたら意外とできた • UI変更が伴う/伴わないでリリース月を分けていた(対外的な理由) • いつの間にかどの月でもUI変更リリースをするように • スクラム導入 • 職能横断でプロセス最適化
16. kintoneのリリース • もっと、もっと早くリリースだ！ • 今年9月から週1リリースの試み • プロセス改善である程度できた • 週1リリースできる対応が限定されている • UI変更：× • 性能に影響がありそうなもの：×
17. 週1でリリースできるものを増やしたい • UI変更 • いきなり使い勝手が変わると顧客が困る • 顧客ごとのカスタマイズに影響がでる可能性がある • 実装したものの品質が担保できないわけではない →実現するには社外との調整が必要
18. 週1でリリースできるものを増やしたい • 性能に影響がありそうなもの • 性能検証が必要 • しかし現状のままだと週1で実施がつらい
19. kintoneのリリース 1月 2月 3月 4月 5月 開発期間 試験期間 開発期間 試験期間 開発期間 試験期間 リリース リリース リリース
20. kintoneのリリース 1月 2月 開発期間 試験期間 改修 改修 改修 改修 性能検証 脆弱性検証 回帰試験 移行試験 改修
21. kintoneのリリース 1月 2月 開発期間 試験期間 改修 改修 改修 改修 性能検証 脆弱性検証 回帰試験 移行試験 改修 機能試験は 各改修毎に実施
22. kintoneのリリース 1月 2月 開発期間 試験期間 性能検証 脆弱性検証 回帰試験 移行試験 N月版アーカイブが 固まってから実施
23. kintoneのリリース 1月 2月 開発期間 試験期間 性能検証 脆弱性検証 回帰試験 移行試験 一番時間がかかる (数日)
24. kintoneのリリース 1月 2月 開発期間 試験期間 性能検証 脆弱性検証 回帰試験 移行試験 【補足】 期間は長いが 開発期間にスプリントごとに 小分けで実施している
25. 週1でリリースできるものを増やしたい • 性能に影響がありそうなもの • 性能検証が必要 • しかし現状のままだと週1で実施がつらい →実現するには内部的な課題をクリアすれば良い →やり方を変えよう！
26. 性能検証の自動化
27. 従来の性能検証 • ScaleBench • http://developer.cybozu.co.jp/archives/tech/2010/05/scalebench-c8c6.html • 内製の負荷テストツール • VU(バーチャルユーザ)という指標で性能を数値化 • シナリオでユーザの操作を定義 • 徐々に操作ユーザ数を増やして負荷を上げる • 安定して操作できるユーザ数がVU(大きいほど良い)
28. こんな感じのグラフが出てくる
29. 従来の性能検証 • 時間が掛かる(特に準備) • 手動実施しているため • 指標の解釈が難しい • 「前月版は1200VUで今月版は1100VUなので9%劣化です」 • どの操作が遅くなったのか分かりづらい • 様々なシナリオが混ざっている状態での指標
30. 従来の性能検証 • 時間が掛かる(特に準備) • 手動実施しているため • 指標の解釈が難しい • 「前月版は1200VUで今月版は1100VUなので9%劣化です」 • どの操作が遅くなったのか分かりづらい • 様々なシナリオが混ざっている状態での指標 →単に自動化するだけでは満足できなさそう…
31. 従来の性能検証 • 時間が掛かる(特に準備) • 手動実施しているため • 指標の解釈が難しい • 「前月版は1200VUで今月版は1100VUなので9%劣化です」 • どの操作が遅くなったのか分かりづらい • 様々なシナリオが混ざっている状態での指標 →「性能検証で何が出てくると嬉しいか」から考えた
32. 性能検証のアウトプット • APIごとに性能を見たい • 性能劣化に繋がった改修を見つけるのが容易 • 指標はどれにしよう？
33. 性能 • 色々な観点がある • 処理が早い • 同時にたくさん処理できる • リソースを食わない
34. 性能 • 色々な観点がある • 処理が早い → レスポンスタイム • 同時にたくさん処理できる → スループット • リソースを食わない → リソース使用量
35. 性能検証のアウトプット • APIごとに性能を見たい • 性能劣化に繋がった改修を見つけるのが容易 • 指標はレスポンスタイムにしよう
36. 性能検証のアウトプット • APIごとに性能を見たい • 性能劣化に繋がった改修を見つけるのが容易 • 指標はレスポンスタイムにしよう →これだけだと同時に処理した時の性能が担保できない →本番環境では同時に複数人が使う
37. 性能検証のアウトプット • APIごとに性能を見たい • 性能劣化に繋がった改修を見つけるのが容易 • 指標はレスポンスタイムにしよう • 本番の使われ方に近いリクエスト種・量で性能を見たい • DBロックを広く取ってしまう等の劣化を検知 • 指標はスループットにしよう
38. 性能検証の自動化 • 2つの自動テストを作ることにした • パフォーマンステスト • APIごとにレスポンスタイムを計測する • ロードテスト • 本番に近いリクエスト種・量でスループットを計測する • リソース使用量も記録する
39. パフォーマンステスト
40. ダッシュボード
41. 同じAPIでもパラメータ違いで分けている
42. 性能チェック＆通知
43. パフォーマンステスト 計測 開始 計測 終了 計測結果 JUnit 記録 劣化通知 性能 チェック 引用：https://www.elastic.co/ API呼出
44. パフォーマンステスト • 計測：Junit • ApacheCommonsのStopWatchを使用 • 計測結果の保存：Elasticsearch • 計測結果の可視化：Kibana • 性能チェック結果：kintone
45. パフォーマンステスト • 計測：Junit • ApacheCommonsのStopWatchを使用 • 計測結果の保存：Elasticsearch • 計測結果の可視化：Kibana • 性能チェック結果：kintone →以前は結果の保存・可視化もkintoneで行っていたが Kibanaの可視化が強力だったので移行
46. パーセンタイルとか簡単に取れるし…
47. ロードテスト
48. ダッシュボードは同じくKibana
49. スループット
50. 複数リクエストを同時実行するのでエラー数も見ている
51. APIごとのレスポンスタイムのサマリー
52. リソース使用量は別ダッシュボード
53. ロードテスト 計測結果 Locust 記録 引用：https://www.elastic.co/ API呼出 API呼出 API呼出 リソース モニタ Prometheus Grafana
54. ロードテスト • 計測：Locust • 計測結果の保存：Elasticsearch • 計測結果の可視化：Kibana • リソースモニタ：Prometheus • リソース使用量の可視化：Grafana
55. ロードテスト • 計測：Locust • 計測結果の保存：Elasticsearch • 計測結果の可視化：Kibana • リソースモニタ：Prometheus • リソース使用量の可視化：Grafana →リソース周りは元々開発環境にあったものを転用 →ひとつのダッシュボードにまとめるメリットがなかった
56. 2つの性能検証とこれから
57. 2つの性能検証 • 絶賛調整中 • まだ開発プロセスに組み込まれていない • 1日4回実行はしている • パフォーマンステスト：4.5時間/回 • ロードテスト：2時間/回
58. 過去の性能劣化を再現して検知できるか検証中 劣化を再現した アーカイブ
59. APIによっては集計が安定しないものも(ぐぬぬ) 何もしてない
60. 2つの性能検証 • 絶賛調整中 • まだ開発プロセスに組み込まれていない • 1日4回実行はしている • パフォーマンステスト：4.5時間/回 • ロードテスト：2時間/回 • ある程度過去の性能劣化は検知できている • 一部ケースの安定化が課題
61. 性能検証の安定化 • 安定化が課題 • パフォーマンステストの安定化の取り組みについては、 以前発表しているのでそちらをご覧ください。 https://speakerdeck.com/szkayeah/20180305-kintones-automatic-test
62. まとめ
63. まとめ • kintoneのリリース間隔はどんどん短くなっている • 更に短くするために性能検証に目を付けた • 自動化で何を成し遂げたいかを決めた • ただ自動化することを目的にしない • パフォーマンステストとロードテストを作り、お互い似 通いつつも使いやすいツールを選定している
64. ありがとうございました