🍝
負荷試験を秘伝のタレにしない仕組みを考えてみる
はじめに
- この記事は、トラストバンク Advent Calendar 2021の17日目です。
- 今回特定のツールや言語が登場しますが、それぞれを批判する意図は無いので悪しからず🙇
背景
- これまで経験した各環境において、負荷試験を業務として引き継いできたことが何度かありました
- 様々なツールを使ったものがありましたが、その多くが秘伝のタレと化しており先人の作ったシナリオを少しいじる程度の変更しかできない状態でした
- しかしながら、その言語でアプリケーションを書くよりはハードルは低いと思うものの、その言語を普段使っていない人からすると、その時点でアレルギー反応を示す事実もあるように思います
- 以前、Pythonで書けば可読性が良くなると信じてLocustで展開したものの、Pythonという時点でシナリオを読む気が失せる人が多かった経験😢
- そこで、今回この年末に向けて実施した負荷試験のシナリオを属人化させずに、みんなでシナリオを評価し会えるようにするにはどうすればいいか考えてみる🔥
課題
まず現状私が負荷試験実施までに直面すると考える課題と解決策はこんな感じです。
言語の不一致
- 前述の通り、言語が違う時点で読むことに抵抗を抱く人もいます
- かと言ってマイナーはメンテナンスされないリスク
解決策
- 言語を一致させる or YAML, JSON等のDSLで書くのが良さそう
実施までの障害
- 経験上Readmeやドキュメントに実行手順があっても口伝されていることが多いです
- リファクタリングしようと動かそうとしても、シナリオがコード管理されていなかったり、されていてもサーバ上のコードが正となっていたりしていることもままあります
- 負荷試験の環境もテンポラリなものも多く、共通アカウントを使いまわしたりと再現性の低いサーバ上でやっていることも多いです
解決策
- シナリオのコード管理を徹底する
- IaC、デプロイフロー整備を進めて、再現性のある環境で実行できるようにする
現在のふるさとチョイス開発環境で考えてみる
- サーバサイドで使われている言語は主にPHP
- 負荷試験ツールとしてGatlingが秘伝のタレ化している
- PHP製の有名なツールは軽く調べた限り、メジャーなものはなさそうなのでDSLで書けると良さそう
- シナリオはファイルサーバに置かれているが、負荷試験サーバに置かれているものが正となっている
- まずはシナリオをGithubに上げてコード管理を始める(済)
- 負荷試験環境は負荷試験をやるときにGatlingが実行できるサーバを複数台用意している
- AWSで必要なときにすぐ環境を準備できるようにしたい
- 負荷増加もシナリオの実行数を手動で増やしているので、オーケストレーションする仕組みを入れたい
検討しているツール
Taurus
- yamlで書いて、JMeterやGatling等各種ロードテストシナリオにコンバートして実行できる
- 既存のシナリオを活かしつつ、段階的に移行できるかも？
- AWSソリューションであるDistributed Load Testing on AWSでも利用されており、サーバレスな実装も比較的簡単にできそう
- テンプレートではJMeterを前提とした作りにはなっているので、Gatlingを利用したり、複雑なシナリオを組む場合にはカスタマイズが必要そう
Artillery
- yamlでシナリオを書く、Node.js製のツール
- モダンでSREやDevOpsのためのと謳っている
Artillery is modern load testing & smoke testing for SRE and DevOps
- 公式にAWSでのサーバレスな実行機能を持っており、よりシンプルに実行できそう
- アカウントの発行が必要で、負荷試験の規模や頻度によっては無料枠で使えない
最後に
- ホントはもう少し手を動かした記事を書きたかったですが、現在絶賛お試し中で締め切りの都合上、技術選定までの思考を書いてみました
- 半分自分の頭の整理を兼ねたような内容ではありますが、意見、感想があればお待ちしております！🙇
Discussion