k6 （と Playwright）で負荷試験を刷新する

導入前の状況

負荷試験の仕組みはすでに構築されていました。

以下のような流れで、アベレージロードテストを毎日定時に自動実行していました。

1. 変更の加わったコードを試験用サーバー環境にデプロイ
2. 負荷をかける側の環境をAWS CDKで自動構築
3. Locust のシナリオを動かしてサーバーのAPIのエンドポイントに対して負荷がけ
4. 主要なAPIのレイテンシが悪化していないかを確認

社内で主に使われる Python でコーディングができるという理由で Locust を利用していました。

SREチームがテストシナリオコードのメンテナでした。

ツール導入前の課題

課題①：インフラ運用コストへの対処

当時、インフラのコード管理を Terraform メインで行う中、負荷試験実行環境だけAWS CDK管理で認知負荷になっていました。（現在、別で AWS CDK を利用しているサービスもありますが...）

CDK バージョン更新も後回しとなり、その実施に大きなコスト発生が見込まれていました。 また、事業状況の変化に伴い負荷試験環境を変更・構築することが少なくなり、負荷試験のインフラをコード管理することのメリットは小さくなっていました。

課題②：シナリオ運用コストへの対処

負荷試験構築のときの想定よりここに割けるチームのリソースに乏しく、シナリオの運用まで手が回らず、テストシナリオがプロダクトの進化に同期的に追従できていませんでした。

どのような状態を目指していたか

健全な負荷試験の運用（主にシナリオ・インフラのメンテナンス）にかかるコスト最適化が目的でした。

• Locust (当時利用中)
• Apache JMeter
• Gatling
• vegeta
• Artillery

実行環境の移行可能性 (vs 課題①：インフラ運用コストへの対処)

CDK によるインフラ管理、CDK そのもののメンテナンスを脱却するのに併せて、負荷試験環境構築・運用になるべく手がかからなくなることが要件でした。

想定としては、既存の CI 環境への組み込みか、マネージドなクラウドサービスの利用を考えていました。

HAR との互換性 (vs 課題②：シナリオ運用コストへの対処)

Playwright の実行で生成される HAR 形式のファイルを用いて、シナリオ実装を機械化して運用コストを下げることが刷新の狙いのひとつでした。そのため、HAR からツールで用いるシナリオ定義を生成できる周辺ライブラリが存在することを必須要件としていました。

負荷シナリオ定義の自由度

単一の HTTP リクエスト量産ではなく、一連のユーザー体験を再現したときの負荷をモニタリングしたく、ある程度は独自にシナリオ定義できる必要がありました。

その他、SREを加味した観点

シナリオ定義で用いる言語と社内利用言語の親和性

SREチーム以外の開発者にも積極的に負荷試験へ関与してもらえるよう、利用言語の差による無用な学習コストを発生させないことも考えていました。従来の Locust の選定でも考慮していた点でした。

将来的な拡張性

事業拡大に伴うプロダクトの変化により、大規模かつマネージドなクラウド環境からの負荷実行が必要になったり、HTTP以外のプロトコルへの移行が発生したり、という将来的な拡張性もある程度は考慮しました。 必須の要件とはしなかったのもの、対応できそうであればベターというスタンスでした。

インフラのコスト・保守性が改善する見込みがある (vs 課題①)

k6 は低スペックのマシンでも一定負荷をかける試験が実行可能で、既存の CI パイプラインに負荷試験実行環境を構築できる見込みがたちました。当時利用していた Locust も CI 実行は不可能ではなかったはずですが、マシンスペック水準に加えて k6 の方が CI 環境のライブラリ・ドキュメントも充実している印象を受けました。

シナリオ自動生成の実現可能性が高い (vs 課題②)

Playwright のシナリオから HAR を経由して機械的にシナリオ生成できることを検証できました。 Locust にも同様の変換ライブラリはあったものの、メンテナンスは外部コミュニティ（例えば個人の公開リポジトリ）に依存しており、Grafana Labs が主導してリポジトリを公開・運用している k6 のエコシステムとは差があると捉えました。

その他の要件

• シナリオ定義の自由度 & 社内利用言語との親和性：JavaScript とほとんど同じ書き方ができる
• 拡張性：GraphQL/gRPC などの対応、k8s の利用、Grafana Cloud k6 の存在、etc...

改善したかった課題はどれくらい解決されたか

AWS CDK によるインフラ管理 → 運用コスト減

CI 環境で実行されるようになり、CDK のコード管理はなくなりました。 管理対象は CI 設定用の yaml に代替され、インフラの運用は定期的に他のサービスで行われる CI 環境バージョンアップ等の一連のメンテナンスに吸収されました。

負荷試験シナリオコードの運用 → ある程度まで自動化

Playwright の運用状況に依存しているため、シナリオ生成・更新・追加を完全に自動化できたとはまだ言えません。 ただ、今後 Playwright との連携を高めていき、従来できていなかった運用ができるようになっていくと見込んでいます。

どのような成果が得られたか

上記の課題解決の度合いが主な成果ではありますが、副次的に得られた点を付記しておきます。

Datadog との連携

かつては負荷をかけられる側のインフラのメトリクスのみ監視していました。 今回の k6 導入により、エージェントから Datadog に負荷をかける攻撃側のメトリクスも送信できるようになりました。シナリオ実行時の監視対象が増えてトラブルシューティングに役立っています。

Open Source 版のみの利用であり、k6 そのものの導入で苦労した点は特にありませんでした。 自社の特殊なユースケースで発生した点で一般に役立つか怪しいですが、念のため記載しておきます。

Playwright からの負荷試験シナリオ自動生成の接続

あるリクエストに対して返却されたレスポンスのデータを用いて、次のリクエストのデータを構成するのはよくある流れです。このレスポンスデータがリクエスト毎に変化し再利用できない値だと、Playwright で生成される HAR ファイルのデータは、そのままでは k6 でシナリオ再現できないものになってしまいます。

ログインのセッション保持など一部は k6 のライブラリで対応できますが、プロダクトでは同様の処理を行うもののライブラリのみで対応できない箇所が複数ありました。公式の har-to-k6 も調査時には未対応でした。

そのような箇所に対応するため、Jinja のテンプレートエンジンを挟んで k6 シナリオ（JavaScript）コードに変換するようにしました。

このレビューは、Playwright の E2E テストシナリオがある程度実装され、それを負荷試験にも活用する前提のもと、ツールを比較しています。特定のエンドポイントに対して瞬間的な負荷をかけたいなど、一般的に考えられるシンプルな負荷試験のケースにおける比較ではないことにご留意ください。

その前提を踏まえ、記述してきた良い点を利とする状況下では k6 を検討に含める価値はあると思います。