K8s負荷試験作業記録
概要
負荷試験を実施したので記録する
環境
AWS(EKS)、Datadog、Gatling
事前準備
- 負荷試験ツール選定
- 目標値設定
- シナリオ作成
- スケジュール設定
- 環境構築、試験用踏み台準備
- モック準備(必要な場合)
- 関連部署に連絡(必要な場合)
負荷試験実施
- 負荷をかける
- APM,ログを確認する
- 問題のある箇所の特定
- 修正
上記ステップを繰り返す。
確認事項
メトリクス
- K8s
ClusterのCPU、メモリ使用率
NodeのCPU、メモリ使用率、DiskUsage
Deployment単位のCPU、メモリ使用率 ReplicaSet数
など - 各アプリケーション(Datadogでいうservice単位)
レイテンシ、リクエスト数、エラー数 - CoreDNS
リクエスト数、エラーレート、レスポンスタイム - アプリケーションログ
エラーログ、トレース - その他インフラリソース
NatGateway、CloudFrontなど
考慮点
スケールアップかスケールアウトか
アプリケーション特性やモニタリングの容易性が変わる
スケールアップするよりもスケールアウトしたほうが性能が出る場合
細かなスケールアウト、スケールインを繰り返すとモニタリングがしづらい
PodとNodeのスケールアウト速度の差
Podは立ち上がるのが早いが、Nodeは遅い
しきい値を上げすぎるとNodeのスケールアウトが間に合わないケースがある
スケール特定
線形スケールするか？
アプリケーション特性
- スパイクアクセスが多いか？
スパイクアクセスが多い場合はスケールアウトが間に合わない可能性があるので、基本スペックを上げたり、しきい値を低くするなどの対策が必要 - 時間帯によってリクエスト数は増えるか？
時間帯が決まっているならスケジュールで事前にスケールアウトしておく - 高可用性が求められるか？
改善点
作業人員不足
コンテナ数が多く確認項目も多かったため人員不足を感じた。人員を増やすか、ダッシュボードを有効活用する。
下記のような役割が必要。
- 負荷試験実施要員
- 試験記録要員
- アプリケーションナレッジ要員
参考
https://gist.github.com/voluntas/00da5ea7a1a14d82adf2e718c7d8a145
負荷試験ツールはGatlingを使ったが、k6のドキュメントも概念を知るには良かった。 https://k6.io/docs/misc/glossary
