k6を使ったKubernetes環境での負荷テスト

ツール導入前の課題

• 急激なリクエスト量増加への対応: 運用しているサービスでは、短時間の間にリクエスト量が倍以上増加することがあり、そのような状況に対処できるか事前に確認する必要があった
• 最適なリソース設定の不明確さ: リクエスト数増加を見越した最適なPod数やリソース量の設定値が明確でなかった
• 複数プロトコルへの対応: REST APIサーバーに加えて、gRPCサーバーも運用しているため、状況によっては両方のプロトコルに対する負荷テストが必要だった
• 継続的なテスト実施体制の未整備: 負荷テスト環境が整っておらず、システムの健全性を継続的に確認する仕組みがなかった

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

• トラフィック急増に対する耐性の確認: 急激なリクエスト量増加を負荷テストのシナリオに組み込み、システムの挙動を把握する
• 適切なリソース設定の決定: 負荷テスト結果を基に、最適なPod数やリソース量を設定する
• 継続的なテスト実行環境の構築: Kubernetes環境で効率的に負荷テストを実行し、定期的にシステムの健全性を確認できる体制を整える
• 開発チーム全体での負荷テスト実施: インフラ担当だけでなく、開発者も扱いやすいツールを選定し、チーム全体で負荷テストに取り組める環境を作る

• JMeter: 老舗のGUIベースの負荷テストツール
• k6: JavaScriptベースの負荷テストツール（採用）

開発チームとの親和性

• JavaScriptでのシナリオ記述: インフラ担当だけでなくアプリ開発者でも扱いやすい言語であること
• バージョン管理: テストスクリプトをGitで管理し、レビューやCI/CDに組み込みやすいこと
• テストの再現性: コードベースであり、環境に依存しない再現性の高いテストが実現できること

技術的優位性

• 軽量性とスケーラビリティ: メモリ消費が少なく、大規模な負荷テストでもリソース効率よく実行できること
• プロトコル対応: HTTP/REST、gRPC、WebSocketなど、複数のプロトコルに対応していること
• クラウドネイティブ: Kubernetes環境での実行に最適化されていること

今回の要件への適合性

1. Kubernetes統合: Kubernetes Jobとしての実行が標準サポートされており、GKE環境に適している
2. 開発効率: JavaScriptでの設定により、チーム内での保守性が高い
3. プロトコル対応: gRPCプロトコルにネイティブ対応しており、将来的な拡張に対応可能
4. 柔軟な負荷パターン: ramping-arrival-rateなど段階的な負荷増加が設定可能で、実際のトラフィック変動を想定したテストシナリオを組める

技術的な決定要因

• Go製による軽量性: JMeterなどの他の負荷試験ツールと比べてメモリ消費が少なくスケールしやすい
• 開発者ファーストの思想: 従来のGUIベースの負荷テストツールとは異なり、開発者が慣れ親しんだプログラミング言語を使用して直感的にテストを作成できる
• モダンなDevOpsワークフローへの適応: CI/CDパイプラインとの統合、Infrastructure as Code（IaC）との親和性が高い

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

• システムの耐性確認: 100 RPS程度の負荷に対応可能であることを確認でき、現在の設定で目標とする負荷に耐えられることが分かった
• オートスケーリングの検証: HPAによるオートスケーリングが適切に動作し、負荷増加に対応してPod数が調整されることを確認
• リソース設定の最適化: 最大負荷時においてもCPUリソースを使い切ることなくリクエストを捌けていることが確認でき、適切なリソース設定の指標を得られた

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

• 効率的な負荷テスト環境の構築: k6 + Kubernetes Jobの組み合わせにより、簡単に負荷テストを実行できる環境を構築
• 現実的なテストシナリオの実現: 段階的負荷増加パターン（ramping-arrival-rate）により、実際のトラフィック変動を想定したテストを実現
• システムの健全性確認: レスポンス時間が全体を通して安定しており、システムの健全性を定量的に確認
• 継続的なテスト実施体制: Makefileによるコマンド化により、誰でも簡単に負荷テストを実行できる体制を整備

• Kubernetes Job定義ファイルの作成と設定の調整: k6をKubernetes Job方式で実行するための設定ファイルの構成を検討する必要があった
• ConfigMapを使ったスクリプトファイルの配置方法: テストスクリプトやサンプルデータをどのようにKubernetes環境に配置するか、ConfigMapを使った方法を調査・実装する必要があった

ただし、k6の公式ドキュメントは非常に充実しており、Kubernetes環境での実行方法やスクリプトの書き方、各種設定項目について詳細な説明と豊富なサンプルコードが提供されています。そのため、ドキュメントを参照しながら実装を進めることで、上記の課題も段階的に解決することができました。特に、Kubernetes統合やramping-arrival-rateの設定例など、実践的なユースケースがドキュメント化されているため、初めて導入する場合でも安心して取り組めます。

• クラウドネイティブ環境での負荷テストに最適: Kubernetes環境で運用している場合、k6は非常に適している
• 開発チーム全体での活用: JavaScriptでシナリオを記述できるため、インフラ担当だけでなく開発者も扱いやすい
• コードベースでの管理: テストスクリプトをGitで管理でき、レビューやCI/CDへの組み込みが容易
• 段階的な導入: まずは簡単なHTTPリクエストのテストから始め、徐々に複雑なシナリオに発展させるのがおすすめ
• 公式ドキュメントの充実: 公式ドキュメントが充実しているため、学習リソースには困らない

• 異なる負荷パターンでのテスト実施: スパイクテスト、ストレステスト、ソークテストなど、多様なシナリオでのテスト実施
• 定期的な負荷テストの自動化: CI/CDパイプラインに組み込み、定期的に自動で負荷テストを実施する体制を構築
• gRPCサーバーへの負荷テスト: 現在はREST APIに対してのみテストを実施しているが、今後はgRPCサーバーへの負荷テストも実施予定
• 負荷テスト環境の継続的改善: システムの成長に合わせて、負荷テスト環境も継続的に改善していく