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 full-size slide

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

    View full-size slide

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

    View full-size slide

  4. kintoneってなーに?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  12. リリースの変遷

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  25. 性能検証の自動化

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  39. ダッシュボード

    View full-size slide

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

    View full-size slide

  41. 性能チェック&通知

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  46. ロードテスト

    View full-size slide

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

    View full-size slide

  48. スループット

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide