ロードテストのベストプラクティスチェックリスト

# パフォーマンス志向の信頼性エンジニアによるロードテストの流儀 - すべてのロードテストは、「500リクエスト/秒でp95レイテンシが300ms未満」のような書面化された目標から始める。漠然とした「何が壊れるか見る」から始めない。 - ロードテストをk6、Gatling、またはLocustでコードとして書き、サービスと同じリポジトリに保持する。 - 本番ログから現実的なトラフィックをモデル化する。エンドポイントの混合、ペイロードサイズ、リクエスト間の思考時間を含める。 - インターネットに面するサービスをテストするときは、固定到着率のオープンワークロードモデルを使用する。クローズドモデルはキューイング遅延を隠すため。 - 意図的に異なるテストタイプを実行する。スモーク、予想ピーク時の負荷、ピークを超えるストレス、スパイク、そしてメモリリークのための長時間ソークテスト。 - レイテンシをパーセンタイルで報告し、少なくともp50、p95、p99を含める。平均値だけに頼らない。 - パスまたはフェイルのしきい値をテストスクリプトで定義し、CIが自動的にビルドを失敗させられるようにする。 - 本番と同等のインスタンスサイズ、データ量、構成を持つ本番に近い環境でロードテストを実行する。 - 本番のカーディナリティに一致するテストデータをシードする。小さなデータベースはすべてのクエリを速く見せるため。 - 測定前にキャッシュと接続プールをウォームアップし、ウォームアップ期間を結果から除外する。 - 十分なCPUとネットワークヘッドルームを持つマシンから負荷を生成し、ロードジェネレータ自身のメトリクスも監視する。 - テスト結果をサーバー側のメトリクス、トレース、ログと関連付けて、推測ではなく実際のボトルネックを見つける。 - レイテンシと並行してエラーレートとタイムアウトを追跡する。エラーを返す高速な応答は成功ではない。 - 実行ごとに1つの変数を変更し、各結果とともにコミット、構成、環境を記録する。 - メインへのすべてのマージで短いパフォーマンススモークテストを実行し、主要リリース前に完全なスイートを実行する。 - 結果を保存されたベースラインと比較し、合意されたパーセンテージを超える劣化にフラグを立てる。 - 呼び出しごとに課金される、またはレート制限を強制するサードパーティAPIをモックまたはサンドボックス化するが、自分の依存関係は実際にテストする。 - 破綻点を見つけ、システムがどのように失敗するかを文書化する。429または503での優雅な拒否は、崩壊よりも優れている。 - 負荷を段階的に増やし、新しいキャパシティが助けになるまでの時間を測定して、オートスケーリングが時間内に反応することを確認する。 - ロードテストをチームとオンコールエンジニアに通知し、承認なしに共有本番システムに向けない。 - 発見事項を、テストされた限界の60パーセント以下で実行するなどの明確なヘッドルーム目標を持つキャパシティプランに変換する。