企業のデジタルトランスフォーメーション（DX）を進めるためには、それを実践する組織のアジリティが必要です。そのアジリティを獲得するため先進的な企業ではITシステムの大幅な見直しが図られています。例えば、システム開発の手法はウォーターフォールからアジャイルに、採用するインフラ環境も、オンプレミスからクラウドへと変わりつつあります。
このような変化に伴い、システム性能管理のトレンドにも変化が見られます。
（参考）『次世代企業システムを性能面から支え続ける～NSSOLの強みと性能管理の潮流～』
このような変化に対応するために、システム性能管理の専門チーム「Benchmark & Consultation Center（以下、BCC）」が新しい負荷試験の仕組みを開発しました。アジャイルのような短いアプリケーションリリースサイクルに対応するDevOps向け負荷試験プラットフォーム『cloadios（クローディオス）』です。
開発メンバーのBCC飯島 和之さんに、お話をお聞きしました。
時代にマッチした性能管理を行うためには、自動化・CI/CDの仕組みを取り入れたプラットフォームが必須
―― 『cloadios』が開発された背景から聞かせてください。
飯島：目まぐるしく変わる市場に対応するために、システムの開発にもアジリティが求められています。そうしたなかにおいてシステム性能を継続的に担保していくためには、新しい仕組みが必要だと考えました。
―― アジリティのある開発を後押しするために『cloadios』は開発された、ということですね。
飯島：はい。アジャイルでは次々と新しい機能がリリースされていく傾向にあるため、そのリリースサイクルを支える技術としてテストやデプロイメント、デリバリーに自動化を取り入れるCI/CDが一般的に用いられます。一方で、頻繁なリリースによる構成変更に伴い性能ボトルネックも変化していくため、システムの継続的な性能担保が困難になっていきます。従来の負荷試験ツールはCI/CDと相性が良くなかったため、短いアプリケーション開発サイクルに対して負荷試験を継続的に短期間で実行するというプロセスを実現するためには、新しい仕組みが必要でした。
こうした課題感から生まれたのが『cloadios』です。新たにCI/CDの仕組みを取り入れ、自動で継続的な負荷試験を行うことで開発のアジリティを損なわず、かつ性能品質を担保することがコンセプトです。
―― 確かに開発は早くなったけど障害が頻発していれば元も子もないですから、そのコンセプトには共感します。
「Dockerコンテナ＋kubernetes」で試験シナリオのデプロイを自動管理
―― 『cloadios』にはどのような技術やツールを使って自動化を実現していったのでしょうか。
飯島：負荷試験プロセス全体をソースコードとして管理する、いわば『Load testing as Code』というような着想を得て、図にあるようなパブリッククラウドサービスを、負荷試験を進めていく際の各プロセスに当てはめていきました。
導入部分、試験シナリオをデプロイするまでのフローは、「Dockerコンテナ＋kubernetes」を採用。対象機能ごとの試験シナリオをコンテナに分割するようにしました。そしてGoogle Kubernetes Engine（GKE）を使うことで、コンテナ化された試験シナリオを自動でクラウド上にデプロイ。コンテナ技術の持つ可搬性によって、試験シナリオの実行環境から特定のインフラに対する依存を排除でき、オンプレミス/クラウドを問わず、ユーザーは好きな環境でいつでも同じ負荷試験を行うことができます。
―― コンテナ化することがひとつポイントなのですね。
飯島：負荷試験でコンテナを活用するには、コンテナを管理するオーケストレータと呼ばれるツールが重要になってきます。従来、人がサーバ一台ずつにログインして適切なテストシナリオを読み込ませる作業を実行していましたが、オーケストレータを使うことで、シナリオと必要な実行数だけを指示すれば自動で実行管理できるようになりました。ただ開発当初は、コンテナ技術が出始めたばかりでしたのでデファクトスタンダードなオーケストレータがありませんでした。意図した通りに負荷を生成するには、コンテナの起動速度や管理できるコンテナの数が重要です。いろいろなオーケストレータを実際に使うなど試行錯誤を重ね、GKEに行き着きました。
―― パブリッククラウドを活用したのは、どういった理由からなのですか。
飯島：エンタープライズシステムの中でも特に、トラフィックのピークが変化する傾向にあるB2C向けのWebシステムを試験対象として想定して開発しました。アジャイルではスモールスタートという、初めは小さく開発して徐々に大きくしていくシステムが多いと予想しているため、求められる負荷の変動に柔軟に対応する必要があります。そこに柔軟にリソースをスケールできるパブリッククラウドを使うことで、負荷生成環境の構築期間の短縮や、その構築・管理コストを大幅に下げられるようにしました。
たとえば13万ユーザーが1秒間に2万リクエストするとの設定で行ったテストでは、要したクラウドリソースはサーバ800台（4仮想CPU、メモリ26GB）にもなり、オンプレミスではとても準備できる規模ではありませんでした。しかし、パブリッククラウドであれば、試験1回あたりのクラウドの費用は2万円。要した時間は準備も含め2時間ほどで、絶大な効果を得ることができました。
―― 13万ユーザーの負荷試験が2万円、2時間で行えるのはかなり魅力的ですね。
「elastic cloud」「BigQuery」が莫大なログの中からエラーや問題箇所を的確に抽出
―― テスト結果を知るツールも、新たな技術を採用したと聞いています。
飯島：はい、「elastic cloud」と「BigQuery」を用途に応じて使い分けています。elastic cloudはelastic社が開発したログやメトリクスの検索や集計などを行うelastic stackをクラウド上で利用できるサービスです。BigQueryはGKEと同じくGoogle Cloud Platform上クラウドサービスで、ビッグデータの解析などに使われるメジャーなデータ分析サービスです。この2つのサービスをデータ量や目的に応じて使い分けています。これらのサービスでは、テスト結果の大量データを確実に集約するだけでなく、リアルタイムに加工・解析まで行います。その結果、エラーがどこで起きているのか即時判断でき、その原因まで深堀できるようになりました。そのため試験中にエラーが出た場合などの対処時間を短縮し、無駄な時間ロスを避けられます。また試験を続けながらエラー状況を把握し、メンバーで改善点を議論することも可能です。
以前の負荷試験ツールでは、結果がサマリーで示される仕様であったため、問題が生じたことは分かっても、それがどこで、なぜエラーになっているのかまでは追跡できませんでした。エラーの詳細を把握し、問題ないことを判別することができないと次の試験に進むことができないので、ローカルのディスク容量を気にせず大量のデータを保持できるこれらのクラウドサービスを利用することで、その問題を改善しました。
この他にも、そもそも従来のツールだと試験の目的によっては分析に欲しいデータが取得できないこともありました。欲しいデータはアプリケーションや試験の内容によって大きく変わってくるので、ログからどの部分を抽出してくるかという前処理を柔軟に工夫できるようにしたいという欲求もありました。
―― 『cloadios』であれば、カスタマイズが効くと。
飯島：『cloadios』では、分析に必要な情報を負荷試験結果に柔軟に取り込めるよう、「elastic stack」「BigQuery」で独自のログの前処理機能を実装しています。この機能により、たとえば、試験シナリオの問題個所を指摘できますし、負荷試験で生成している個々のリクエスト成否の分析も可能です。そのほか『cloadios』側の問題、試験に使用するログインユーザなどのテストデータ依存の問題など、想定できる様々なシナリオにおいて、テストならびに診断を的確に行えると自負しています。
―― GitHubやSlackも使われているので、プロジェクトメンバー同士のコミュニケーションや情報の共有もタイムリーに行えそうですね。
飯島：問題が生じた場合はSlackで全メンバーに連絡がいくような設定もできますし、試験結果を受けて修正した内容は、すべてGitHub上に記録し、メンバーに共有します。
一歩先。次世代で必要とされる技術やツールを開発することを意識
―― 既にローンチしたと聞いていますが、今後のバージョンアップや展開などについて、最後にお聞かせください。
飯島：今後のcloadiosでは、負荷試験以外にも、可用性やセキュリティなどをテストする機能も実装したいと考えています。今のトレンドであるアジャイルでは、次々と新機能をリリースするだけでも大変ですから、性能以外にも非機能品質全般が見落とされがちではないかと懸念しています。しかし、非機能を重視するあまり、新機能のリリースの足枷となってしまっては本末転倒です。アジリティを下げずに、これらの非機能をテストする新しい仕組みが必要になります。
―― 『cloadios』を使えば、今お話しされたような課題が解決しますね。
飯島：アジリティを維持しながら、非機能を担保することがSIerとしての付加価値になると、私たちは考えています。シス研BCCではそのような未来を見据え、『cloadios』をはじめとした、開発スピードの向上とサービス信頼性の両立を実現するシステム管理の仕組みを、今後も研究開発していきます。
