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

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

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. サイボウズ株式会社 西日本開発部
    鈴木 亜耶 @szkayeah
    kintoneのリリースを加速する!
    性能検証自動化
    2018/10/27 ヒカラボ関西
    キントーン

    View Slide

  2. はなすひと
    鈴木 亜耶 @szkayeah
    • Webアプリケーションエンジニア
    • 2017年1月に中途入社(Uターン)
    • 好き:CI・自動化・モニタリング
    • 大好き:紅茶
    すず き あ や

    View Slide

  3. おしながき
    • kintoneってなーに?
    • リリースの変遷
    • 性能検証の自動化
    • 内容
    • 仕組み
    • まとめ

    View Slide

  4. kintoneってなーに?

    View Slide

  5. kintoneとは
    サイボウズの
    クラウド型の
    グループウェア

    View Slide

  6. View Slide

  7. ドラッグ&ドロップでフォーム作成

    View Slide

  8. 作ったフォームでデータ登録

    View Slide

  9. データに付随するコミュニケーションはコメント欄で

    View Slide

  10. (弊社では見たよでも使われているいいね機能)

    View Slide

  11. 登録データは一覧で見たり

    View Slide

  12. グラフ化したりできる

    View Slide

  13. リリースの変遷

    View Slide

  14. kintoneのリリース
    • 少しずつ間隔が短くなっている(緊急リリース除く)
    • 2015年:5回
    • 2016年:8回
    • 2017年:10回
    • 2018年:12回+α
    • 現在は基本1か月に1回リリース

    View Slide

  15. kintoneのリリース
    • 間隔が短くなった要因
    • もっと早く出したいという思い
    • やってみたら意外とできた
    • UI変更が伴う/伴わないでリリース月を分けていた(対外的な理由)
    • いつの間にかどの月でもUI変更リリースをするように
    • スクラム導入
    • 職能横断でプロセス最適化

    View Slide

  16. kintoneのリリース
    • もっと、もっと早くリリースだ!
    • 今年9月から週1リリースの試み
    • プロセス改善である程度できた
    • 週1リリースできる対応が限定されている
    • UI変更:×
    • 性能に影響がありそうなもの:×

    View Slide

  17. 週1でリリースできるものを増やしたい
    • UI変更
    • いきなり使い勝手が変わると顧客が困る
    • 顧客ごとのカスタマイズに影響がでる可能性がある
    • 実装したものの品質が担保できないわけではない
    →実現するには社外との調整が必要

    View Slide

  18. 週1でリリースできるものを増やしたい
    • 性能に影響がありそうなもの
    • 性能検証が必要
    • しかし現状のままだと週1で実施がつらい

    View Slide

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

    View Slide

  20. kintoneのリリース
    1月 2月
    開発期間 試験期間
    改修
    改修
    改修
    改修
    性能検証
    脆弱性検証
    回帰試験
    移行試験
    改修

    View Slide

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

    View Slide

  22. kintoneのリリース
    1月 2月
    開発期間 試験期間
    性能検証
    脆弱性検証
    回帰試験
    移行試験
    N月版アーカイブが
    固まってから実施

    View Slide

  23. kintoneのリリース
    1月 2月
    開発期間 試験期間
    性能検証
    脆弱性検証
    回帰試験
    移行試験
    一番時間がかかる
    (数日)

    View Slide

  24. kintoneのリリース
    1月 2月
    開発期間 試験期間
    性能検証
    脆弱性検証
    回帰試験
    移行試験
    【補足】
    期間は長いが
    開発期間にスプリントごとに
    小分けで実施している

    View Slide

  25. 週1でリリースできるものを増やしたい
    • 性能に影響がありそうなもの
    • 性能検証が必要
    • しかし現状のままだと週1で実施がつらい
    →実現するには内部的な課題をクリアすれば良い
    →やり方を変えよう!

    View Slide

  26. 性能検証の自動化

    View Slide

  27. 従来の性能検証
    • ScaleBench
    • http://developer.cybozu.co.jp/archives/tech/2010/05/scalebench-c8c6.html
    • 内製の負荷テストツール
    • VU(バーチャルユーザ)という指標で性能を数値化
    • シナリオでユーザの操作を定義
    • 徐々に操作ユーザ数を増やして負荷を上げる
    • 安定して操作できるユーザ数がVU(大きいほど良い)

    View Slide

  28. こんな感じのグラフが出てくる

    View Slide

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

    View Slide

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

    View Slide

  31. 従来の性能検証
    • 時間が掛かる(特に準備)
    • 手動実施しているため
    • 指標の解釈が難しい
    • 「前月版は1200VUで今月版は1100VUなので9%劣化です」
    • どの操作が遅くなったのか分かりづらい
    • 様々なシナリオが混ざっている状態での指標
    →「性能検証で何が出てくると嬉しいか」から考えた

    View Slide

  32. 性能検証のアウトプット
    • APIごとに性能を見たい
    • 性能劣化に繋がった改修を見つけるのが容易
    • 指標はどれにしよう?

    View Slide

  33. 性能
    • 色々な観点がある
    • 処理が早い
    • 同時にたくさん処理できる
    • リソースを食わない

    View Slide

  34. 性能
    • 色々な観点がある
    • 処理が早い → レスポンスタイム
    • 同時にたくさん処理できる → スループット
    • リソースを食わない → リソース使用量

    View Slide

  35. 性能検証のアウトプット
    • APIごとに性能を見たい
    • 性能劣化に繋がった改修を見つけるのが容易
    • 指標はレスポンスタイムにしよう

    View Slide

  36. 性能検証のアウトプット
    • APIごとに性能を見たい
    • 性能劣化に繋がった改修を見つけるのが容易
    • 指標はレスポンスタイムにしよう
    →これだけだと同時に処理した時の性能が担保できない
    →本番環境では同時に複数人が使う

    View Slide

  37. 性能検証のアウトプット
    • APIごとに性能を見たい
    • 性能劣化に繋がった改修を見つけるのが容易
    • 指標はレスポンスタイムにしよう
    • 本番の使われ方に近いリクエスト種・量で性能を見たい
    • DBロックを広く取ってしまう等の劣化を検知
    • 指標はスループットにしよう

    View Slide

  38. 性能検証の自動化
    • 2つの自動テストを作ることにした
    • パフォーマンステスト
    • APIごとにレスポンスタイムを計測する
    • ロードテスト
    • 本番に近いリクエスト種・量でスループットを計測する
    • リソース使用量も記録する

    View Slide

  39. パフォーマンステスト

    View Slide

  40. ダッシュボード

    View Slide

  41. 同じAPIでもパラメータ違いで分けている

    View Slide

  42. 性能チェック&通知

    View Slide

  43. パフォーマンステスト
    計測
    開始
    計測
    終了
    計測結果
    JUnit
    記録
    劣化通知
    性能
    チェック
    引用:https://www.elastic.co/
    API呼出

    View Slide

  44. パフォーマンステスト
    • 計測:Junit
    • ApacheCommonsのStopWatchを使用
    • 計測結果の保存:Elasticsearch
    • 計測結果の可視化:Kibana
    • 性能チェック結果:kintone

    View Slide

  45. パフォーマンステスト
    • 計測:Junit
    • ApacheCommonsのStopWatchを使用
    • 計測結果の保存:Elasticsearch
    • 計測結果の可視化:Kibana
    • 性能チェック結果:kintone
    →以前は結果の保存・可視化もkintoneで行っていたが
    Kibanaの可視化が強力だったので移行

    View Slide

  46. パーセンタイルとか簡単に取れるし…

    View Slide

  47. ロードテスト

    View Slide

  48. ダッシュボードは同じくKibana

    View Slide

  49. スループット

    View Slide

  50. 複数リクエストを同時実行するのでエラー数も見ている

    View Slide

  51. APIごとのレスポンスタイムのサマリー

    View Slide

  52. リソース使用量は別ダッシュボード

    View Slide

  53. ロードテスト
    計測結果
    Locust
    記録
    引用:https://www.elastic.co/
    API呼出
    API呼出
    API呼出
    リソース
    モニタ
    Prometheus
    Grafana

    View Slide

  54. ロードテスト
    • 計測:Locust
    • 計測結果の保存:Elasticsearch
    • 計測結果の可視化:Kibana
    • リソースモニタ:Prometheus
    • リソース使用量の可視化:Grafana

    View Slide

  55. ロードテスト
    • 計測:Locust
    • 計測結果の保存:Elasticsearch
    • 計測結果の可視化:Kibana
    • リソースモニタ:Prometheus
    • リソース使用量の可視化:Grafana
    →リソース周りは元々開発環境にあったものを転用
    →ひとつのダッシュボードにまとめるメリットがなかった

    View Slide

  56. 2つの性能検証とこれから

    View Slide

  57. 2つの性能検証
    • 絶賛調整中
    • まだ開発プロセスに組み込まれていない
    • 1日4回実行はしている
    • パフォーマンステスト:4.5時間/回
    • ロードテスト:2時間/回

    View Slide

  58. 過去の性能劣化を再現して検知できるか検証中
    劣化を再現した
    アーカイブ

    View Slide

  59. APIによっては集計が安定しないものも(ぐぬぬ)
    何もしてない

    View Slide

  60. 2つの性能検証
    • 絶賛調整中
    • まだ開発プロセスに組み込まれていない
    • 1日4回実行はしている
    • パフォーマンステスト:4.5時間/回
    • ロードテスト:2時間/回
    • ある程度過去の性能劣化は検知できている
    • 一部ケースの安定化が課題

    View Slide

  61. 性能検証の安定化
    • 安定化が課題
    • パフォーマンステストの安定化の取り組みについては、
    以前発表しているのでそちらをご覧ください。
    https://speakerdeck.com/szkayeah/20180305-kintones-automatic-test

    View Slide

  62. まとめ

    View Slide

  63. まとめ
    • kintoneのリリース間隔はどんどん短くなっている
    • 更に短くするために性能検証に目を付けた
    • 自動化で何を成し遂げたいかを決めた
    • ただ自動化することを目的にしない
    • パフォーマンステストとロードテストを作り、お互い似
    通いつつも使いやすいツールを選定している

    View Slide

  64. ありがとうございました

    View Slide