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