【勉強会メモ】【ヒカ☆ラボ】有名サービス開発エンジニア登壇のLT大会
- 日時:2018/10/27(土) 13:00 〜 17:00
- 場所:サイボウズ 大阪オフィス
サイボウズ、ロックオン、ウェブリオのエンジニアが登壇するヒカラボ主催のイベント。今回のテーマは「自動テスト」です。大阪では数少ない自社サービスを扱う会社の地道な取り組み事例を知ることができる貴重な機会でした。
kintoneのリリースを加速する!性能検証自動化
サイボウズ 鈴木 亜耶さん
kintoneのリリース
- 2015年:5回
- 2016年:8回
- 2017年:10回
- 2018年:12回+α
- 基本1ヶ月に1回リリース
間隔が短くなった要因
- もっと早く出したいという思い
- やってみたら意外とできた
- UI変更が伴い・伴わないでリリース付きを分けていた
- いつの間にかどの月でもUI変更リリースをするように
- スクラム導入
- 職能横断でプロセス最適化
もっと早くリリースしたい
- 9月から週1リリースの試み
- プロセス改善である程度できた
- 週1リリースできる対応が限定されている
- UI変更:☓
- 性能に影響がありそうなもの:☓
UI変更
- いきなり使い勝手が変わると顧客が困る
- 顧客ごとのカスタマイズに影響がでる可能性がある
- 実装したものの品質が担保できないわけではない
実現するには社外との調整が必要
性能に影響がありそうなもの
- 性能検証が必要
- 現状のままだと週1実施はつらい
開発サイクル1ヶ月
- 特定の機能の検証はその都度検証
- 全体の検証は1ヶ月の開発期間の最後に検証⇒数日かかる
現状のままだと週1実施はつらい→やり方を変えよう
性能検証の自動化
ScaleBench
内製の負荷テストツール
VU(バーチャルユーザー)が高いほうが性能が良いという喧騒
- ある操作のシナリオを安定して操作できるユーザー数の最大
従来の性能検証
- 時間がかかる(特に準備)
- 指標の解釈が難しい
- 前月版は1200VUで今月版は1100VUなので9%劣化
- どの操作が遅くなったのかわかりづらい
- 様々なシナリオが混ざっている
単に自動化するだけなら満足できない
- APIごとに性能をみたい
- 性能劣化に繋がった改修を見つけるのが容易になる
性能のいろいろな観点
- 処理が早い→レスポンスタイム
- 同時にたくさん処理できる→スループット
- リソースを食わない→リソース使用量
⇒指標はレスポンスタイムにする
- これだけだと同時に処理したときの性能が担保できない
- 本番環境では同時に複数人が使う
- 本番の使われ方に近いリクエスト種・量で性能を見たい
⇒スループットも見る
2つの自動テスト
- パフォーマンステスト
- ロードテスト
パフォーマンステスト
- kibanaのダッシュボード
- どのビルドでどれくらいのレスポンスかがわかる
- 性能チェック&通知
- Jenkinsからチャットに投稿
- 計測:Junit
- ApachCommonsのStopWatch
- 計測結果:Elasticsearch
- 可視化:Kibana
- kintoneを使っていたがkibanaの可視化が強力だったので移行
- データ分析に特化しているので良いものは活用する
- チェック結果:kintone
ロードテスト
リソース使用量は別ダッシュボード
- Locust→Python製のシナリオテストツール
参考
- 計測:Locust
- リソースモニタ:Prometheus
- リソース使用量の可視化:Grafana
- リソース周りはもともと開発環境にあったものを転用
2つの性能検証のこれから
- まだ開発プロセスには組み込まれていない
- 1日4回実行
- パフォーマンステスト:4.5時間
- ロードテスト2時間
- 過去の性能劣化ケースを再現させて検知できるか検証中
- 一部ケースの安定化が課題
- APIによっては安定しない(悪化しているのかわからない)ものもある
安定化の課題
- パフォーマンステストの安定化の取り組みについて
以前の資料
www.slideshare.net
オープンソースEC-CUBEを支えるテストのしくみ
ロックオン 遠藤 良さん
EC-CUBEの開発スタイル
システム要件いろいろ
- PHPバージョン
- サポートDBいろいろ
EC-CUBEを支えるテストのしくみ
- TravisCIを利用
- ユニットテスト
- DBとPHPのバージョンを分けてテスト
- E2Eテスト
- MySQL,PostgreSQLわけてテスト
- AppVeyar
- 静的解析
※AppVeyar
自動テスト
- 複数環境でテストができる安心感
- 修正内容に問題がないか自動ですぐにフィードバックできる
- テストNGだった場合に取り込めない理由が明確にわかる
非機能要件の自動テスト
- より多くの環境でのテスト…Codeception
- パフォーマンス計測…ApacheBench
- セキュリティ解析…Vady
時間コスト高
- 毎日1回のみ実施
テストをより細かく
- PostgreSQL 9.2,9.6
- MySQL 5.5,5.6
- Chrome,firefox
- Root,Sub(インストールディレクトリ)
パフォーマンス計測(Apache Bench)
セキュリティ検査(Vaddy)
- E2Eテストを流用してクロール
- 毎日セキュリティ検査をしているという安心感
3年間の積み重ね
- 2015年
- ver.2
- 自動テストなし
- リリース前に長期テスト→1ヶ月ぐらい
- 2016年〜2017年
- ver.3
- Unitテストラインカバレッジ80%
- E2Eテスト
- 静的解析
- セキュリティて検査
- 2018年
- ver.4
- E2Eテスト
- パフォーマンス計測
いろいろなTRY
チームでふりかえり
- 自動テストも継続して改善
- よりスピード感を持って価値を生むことにフォーカスするために
DockerとJenkinsを使った開発速度と品質の向上
ウェブリオ平野 昌士 さん
DOckerを使った開発実践例
Dockerがなかったあの頃
- 環境構築で2日
- 手順書に書かれていない設定
- Windowsの手順しかない
- 手順書通りやっても動かない
Docker導入後
- Dockerコンテナを起動するだけ
- 開発者の環境が統一
- 環境構築の手順書作成の手間を省略
- イメージの再配布だけ
- 開発者がインフラの設定不要
Dockerの導入
- 開発環境、Jenkins,Redashなど
- docker-composeを使ってイメージのpullから起動まで
- Dockerイメージは社内のDockerレジストリ
Dockerfileの記述
- 構築手順が明確
- しかしビルドには時間がかかる
PrivateなDockerリポジトリ
- 社内におけるDockerレジストリ
- Docker HubのようにDockerイメージの配信
- Dockerfileからビルドしたイメージをpush
- イメージを作るDockerfileはGithubで管理
Docker辛かったところ
- Docker for Mac重い問題
- volumeでマウントしているホストファイルへのアクセスが原因
- DockerがosdxfsでFile Systemを監視しているのが原因
- ファイルの変更が多いとCPU負荷ががんが上がる
- 重くなったらDocker for Macを再起動
- Reset to factory defaultsを実行
- cachedオプションをつける
Dockerイメージ・コンテナが増えすぎる問題
- 全コンテナ停止、全コンテナ削除、イメージ削除コマンドを使う
ホストのマシン再起動後コンテナが起動されない
- 起動し忘れ
- 1つずつ主導でコンテナを起動するのが手間
- restart: "always"
を設定
ここまでのまとめ
- 機械でできることは機械に任せる
- 手間を省いて開発速度を向上
- 手順見える化
Jenkinsを使った開発実践例
Jenkins
Jenkinsおじさんがいなかったあの頃
- テスト実行が手動
- 目視でレビュー
- デプロイも手動
CI導入後
- ビルド、テストデプロイが自動
- ユニットテストやE2E自動
- 静的解析も自動
- ヒューマンエラー減った
JenkinsはDocker上で動く
- アプリケーションごとに技術が違うためそれぞれのSlave用コンテナがある
Weblioの開発フロー
- developからブランチを切って開発しdevelopにマージ
- 開発完了→staging→QAやビジネスサイドのテスト→master
PR Builderを使った検証
- PRごとに不正なコードがメインブランチに入らないようにする
マージ後の検証
CIで工夫したこと
- 失敗したときのfallback
- 成功しないとマージされない
- Slackに通知してすぐきづけるように
- Dockerを起動するだけで元のJenkins環境再現
CIを楽しむ5過剰
- 自分が直接関わるところに力をいれる
- 自分が楽になることを考える
- 自分が使いたいものを導入する
- 自分がいなくても大丈夫な状態をつくる属人性を排除する
- 全部自動化しようと考えない