Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

kintoneってなーに？

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

ドラッグ＆ドロップでフォーム作成

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

グラフ化したりできる

Slide 13

Slide 13 text

リリースの変遷

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

性能検証の自動化

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

パフォーマンステスト

Slide 40

Slide 40 text

ダッシュボード

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

性能チェック＆通知

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

ロードテスト

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

スループット

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

まとめ

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

ありがとうございました