TE(テストエンジニアリングチーム) の川向です。今回は性能検証(負荷検証)自動化のお話です。

サイボウズでの性能検証(負荷検証)

性能検証は、製品に対して大量のアクセスを実行し、これによって得られるデータを解析する試験です。負荷検証とも呼ばれます。

サイボウズでは解析結果を元に、バージョンアップによる性能の劣化調査や、パッケージ版向けのサーバーの構成例を作成しています。

検証は以下の流れで行っています。

・環境構築

検証対象の製品を構築します。クラウドの製品の場合、運用環境と同等の機材上に構築しています。パッケージ版の製品では、利用が想定されるスペックのマシンを使用しています。

・テストデータの作成

製品の利用ユーザ数に応じてデータも増えるので、性能検証でもある程度のユーザ数を仮定してデータを用意しています。基本的にはバックアップしている過去の検証データを使います。データ作成時間の削減のためです。データ量は例えばGaroonでは 1.2TB ほどです。

・テストの実施

実際に負荷をかけていきます。これは内製のscalebenchを使用しており、自動化されています。お客様のアクセスログを元に作成したいくつかのシナリオ(例: ログインしてから、スケジュールの一覧画面を開いて、そのうちの一つのスケジュールの詳細画面を開く)を同時に多数実行します。検証中は少しずつ負荷を増やしていきます。

・テスト結果の集計/分析

scalebenchの検証結果やMySQLやマシンのパフォーマンスデータなどをはExcelのマクロで集計しています。

問題点は？

この性能検証にはいくつかの問題点がありました。

実行に時間がかかる

性能検証用の環境構築やバックアップデータの展開に時間がかかるという問題がありました。これらは手動でコマンドを入力する作業も多かったのも一因でした。

また、人的リソースの問題もありました。 QAには性能検証専任のチームがおり、製品チームからの依頼を受けて検証を行っています。チームの人数はそれほど多くないので、依頼が多くなると検証が遅れることがありました。

性能劣化の検知が遅れがち

実行には時間がかかるので、手戻りを防ぐため性能検証は開発の後期に行われることが多く、開発中に性能劣化を起こすバグが入ってしまっても、それに気が付くのが遅れていました。また、開発後期にはすでにいろいろなコミットが含まれているので、どのコミットが性能劣化を引き起こしたかを特定するのにも時間がかかります。

検証結果がエクセル

前述のように、検証結果はエクセルマクロで集計されています。

社内ではセキュリティ上の理由で原則的にマクロの使用が禁止されています。このため、製品チームのメンバーでもマクロが実行できない人もいます。また、このマクロはWindows以外では動作しません。 MacやUbuntuをメイン環境にしている人は開くことができません。

どう解決する?

TEでは、これらの問題を自動化や新しいツールの導入によって解決しました。

te continuous performance test overview — 性能検証の全体図

実行はJenkinsで

毎晩Jenkinsが実行するようになりました。これにより、これまで開発後期に数回しか行っていなかったものが、開発の全期間において毎日1回実施されるようになりました。

結果はWebで

実行結果はInfluxDBに保存し、Grafanaで閲覧するようにしました。社内の開発環境ではPrometheusが導入されており、そちらの情報も参照できるようにしています。これにより、ブラウザから検証結果をすぐに確認できるようになりました。

また、scalebenchの検証結果データもJenkins上に保存しており、以前と同じ方法でのエクセルでのデータ調査も行えるようになっています。

レストアはWalBで

cybozu.comでは14日間のバックアップデータを保持する仕組みがあります。これは内製のWalBというツールで実現されています。今回の自動化でもこれを使用しました。

今回の自動化では、バックアップデータは14日分ではなく、リリース済みのバージョンの製品の検証データをバックアップしています。製品のリリースがあるときにそれを更新してバックアップをし直します。

検証を行うときはバックアップデータをレストアします。そして、運用環境と同じく製品のバージョンアッププログラムでデータを更新してから検証を行っています。

この仕組みにより、これまで環境構築に13日間かかっていたのが、30分になりました。

通知はkintoneで

CIは回り続けるだけでは価値がありません。問題を検知して適切なアラートを発行することが大切です。今回の仕組みでは、性能が前日や以前のバージョンの製品からある程度低下したときに製品チームに通知を行うようにしています。

通知は、kintoneのREST APIを使って社内のkintoneにレコードを登録することで行っています。

成果は?

この仕組みは昨年からGaroonに対して動かしています。

稼働してまもないころ、製品の劣化を検知して製品チームにフィードバックできました。結果として、この問題を起こすコードがすぐに特定されて取り除かれました。

振り返り

今回ご紹介しているツールや技術は、ほとんどがすでに社内にあるものでした。ですが、知識の共有はうまくなされていない状況でした。

弊社のTEはプログラマとQAのジョイントチームとして結成されており、性能検証自動化を担当したのも、性能検証チーム、SRE QA、Garoonのプログラマをそれぞれ兼務しているメンバーが集まって行いました。このおかげで、それぞれの知見(性能検証の実行方法、cybozu.com環境でのデータレストアの仕組み、CIの稼働方法)を組み合わせることができました。

ジョイントチームのメリットが発揮された良い例だと思います。