Amazon Web Services負荷試験入門 ――クラウドの性能の引き出し方がわかるを読んだ備忘録です。

 クラウド時代の負荷試験の目的あくまで一般的な話、細かいところはプロジェクトによって異なる
各種ユースケースにおける応答性能を推測する
高負荷時のシステムの性能改善を行う
目的の性能を提供するためのハードウェアを選定する
システムがスケール性を持つことを確認する
システムのスケール特性を把握する
スケール特性とは「どこを増強すれば性能が向上するか」

以下を把握するとよい
いくつかのレベル(100rps・500rps・1000rps)を処理するために最適なインフラ構成
目標値を超えて最大どの程度のスループットを処理できるか

Ken

 良い負荷試験が実施されていることを示す指標試験対象のシステムに負荷が集中している状態
ボトルネックを特定できている状態
べき論としては本番環境に近いデータを取得するために、負荷試験環境は本番環境と全く同じものを構築する。

ただ対象以外に引きづられて本来負荷をかけたいシステムに負荷をかけられないのでは良い試験ではない。今まさに負荷をかけたい場所がどこかを見極め、試験対象システムに負荷を集中させるには一部本番環境と異なる構成をとってもいいと考える必要がある。

Ken

 攻撃ツールを使う際の注意点攻撃ツールで観測されるレイテンシは負荷試験対象システムのレイテンシとは異なる
攻撃ツールのクライアントの同時起動数とシステムで処理される同時処理数は異なる
攻撃ツールのクライアントは前のリクエストが完了しないと次のリクエストを発行しない
攻撃ツールで見えている数字はSSLのデコードやネットワークの遅延を含んでいるので、システムが実際に処理した時間は別途確認できるようにしておく

Ken

 スケジュールの決定負荷試験は「システムの改善」の時間が大きくブレる可能性があるため、余裕を持ったスケジュールで臨む必要がある。

フレームワークの再選定になった場合等は手戻りが大きいため、システムの完成を待たずに並行して負荷試験を行うことも検討する。
当然システムの構成変更権限を持たない人が試験を行う場合は、権限を持つ人が行う場合に比べて数倍の期間を要する。

Ken

 目的の設定「クラウド時代の負荷試験の目的」で記載した内容に加えて、具体的にどのようなユースケースに対する試験を行うのかここで洗い出す。
サービス利用開始直後にユーザーが大量に登録をする
順調に稼働後データが大量に溜まった

etc...

Ken

前提条件の整理

試験対象とするシステムの範囲
データ量
- サービス利用者数・想定ユーザー行動・利用期間などから概算で決める
外部システムのレイテンシ、利用するシステムの制約
継続的な性能維持期間
- 「X時間以上継続して性能を維持すること」などのような期間を決める
負荷のかけ方について
- どこのネットワークから負荷をかけるのか
- HTTPSを使うかどうか
その他前提条件
- 本番環境との差異
- 実施スケジュールの制約等

Ken

 目標値の決定大抵の場合は「スループット」「レイテンシ」の2つの指標について適切な値を検討する。

 スループットの目標値「1日の利用者数」「1人あたりの1日の平均アクセス数」「1日のアクセス数に対する最大ピーク時の倍率」が分かればどの程度のアクセスがあるか概算できる。
1日の利用者数 × 1人辺りの1日の平均アクセス数 = 1日の総アクセス数
1日の総アクセス数 ÷ 1日の秒数 = 1日の平均rps
1日の平均rps × 1日の平均アクセス数に対する最大ピーク時の倍率 = 最大rps
この最大rpsに安全計数として2 ~ 3倍を乗じた数字をスループットの目標値にする。

Ken

利用する負荷試験ツールの選定

手軽さ・複雑なシナリオ作成・高負荷それぞれの得意不得意があるので、それぞれに合ったツールを選定する。

Ken

 負荷試験シナリオの決定

 負荷試験シナリオに含まれているべきページ
アクセス頻度の高いページ
例: TOPページ

サーバーリソースの消費量が高いことが想定されるページ
CPU例: 暗号化や認証操作を行うページ、画像・動画のコンバートを担うページ、ファイルの圧縮操作や展開操作などを行うページ
ネットワーク帯域例: 応答コンテンツサイズが大きいページ、画像・動画のアップロード操作やダウンロード操作を行うページ
ディスクIO例: ログ出力内容が多いページ、動的なファイル内の検索などを行うページ

DBの参照をするページ
複数のユーザーが同じリソースを参照し、同じ応答を返すページ
マスタ系の参照ページ
全員が必ず最新のユーザー投稿を参照するページ

リソース全体の横断検索をした上で結果を応答するページ
ポイントランキングのリアルタイム表示
自分と属性が近いユーザーの検索・表示

アクセスするユーザーごとに異なるソースを参照し、個別の応答を返すページ
ユーザー別のマイページ
ユーザー属性に依存した結果を表示するページ
ユーザーの所有するタイムライン


DBの更新をするページ
複数のユーザーが同じリソースを更新するページ
ユーザーごとに異なるリソースを更新するページ

外部システムと通信するページ(SNSやSQSも含む)

Ken

 負荷試験の準備負荷試験対象環境構築
負荷試験ツールの準備
関連システムの部門間調整
クラウド事業者の各種制限緩和申請

 負荷試験対象環境構築実際とは異なり以下の形で準備する
最終的にELBを利用する場合でも、配下のアプリケーションサーバーへの直接リクエストを許可
ELBの前に別のルーティングを利用する場合でも、ELBを直接叩くエンドポイントを利用可能とする
アクセスログに実行時間を追加するようにする
(できれば)HTTPでのアクセスを許可
外部のシステムとの結合ポイントのon/offができるようにスタブなどを用意
また以下の負荷試験専用エンドポイントを追加しておく

そして以下のエンドポイントからリソースを取得するシナリオも作成しておく
静的なコンテンツを返答するだけのURL
Webフレームワークを利用したHello Worldページを返答するURL

Ken

 負荷試験の実施1度に全体的な負荷試験を実施してしまうと、負荷試験が妥当なのかの切り分けが難しくなるため段階を追って実施していく。

 負荷試験を効率的に進めるための9つのステップツールや環境の検証
Webフレームワークの検証
参照系の性能の検証
更新系の性能の検証
外部サービス連携の性能の検証
シナリオ試験
スケールアップ/アウト試験準備
スケールアップ/アウト試験(1~6の回帰試験)
限界性能試験(1~6の回帰試験)

 ツールや環境の検証試験対象のWebサーバーに負荷試験ツールをインストールしてローカルホストで負荷をかける。(もしくは同一セグメントからPrivateIPで接続)対象は静的ファイルの取得。攻撃ツール側にボトルネックを作り、かけられる負荷の上限及び計測可能なスループットの上限を計測する。
十便なスループット(数千rps以上)が観測されていれば次の進める。されなければ設定の見直しを行う。

 Webフレームワークの検証Webフレームワークの機能を利用して生成されるHello Worldに対する試験。

ここでボトルネックが見つかった場合は、Webフレームワーク利用部分のチューニングを行える。最悪の場合はフレームワークの選定し直しとなる可能性がある。

Webフレームワークの最速値を計測する。
Webサーバーのリソースを十分に使えているか
前のステップと比較して明らかなレイテンシ・スループットの悪化が認められないか

 参照系の性能の検証キャッシュシステムの利用やDBの参照部分にフォーカスした試験を行う
Webサーバーのリソースを十分に使えているか
DBサーバーのリソースを十分に使えているか
前のステップと比較して明らかなレイテンシ・スループットの悪化が認められないか

 更新系の性能の検証DBの更新処理にフォーカスした試験を行う
Webサーバーのリソースを十分に使えているか
DBサーバーのリソースを十分に使えているか
前のステップと比較して明らかなレイテンシ・スループットの悪化が認められないか
DBに登録されたデータやログは正常か

 外部サービス連携の性能の検証外部API・KMS・S3・DynamoDBなど

外部システム利用時のオーバーヘッドを見積もり、不要なオーバーヘッドがなく、効率的な呼び出しがされていることを確認する
Webサーバーのリソースを十分に使えているか
DBサーバーのリソースを十分に使えているか
前のステップと比較して明らかなレイテンシ・スループットの悪化が認められないか
外部システムのリソース使用状況は切迫していないか
外部システムのレイテンシに問題はないか

 シナリオ試験ここまではPrivateIPによる接続

 スケールアップ/アウト試験準備ここからはロードバランサー経由の攻撃に変更。

Webサーバーはまだ1台とする。
グローバルセグメントからの攻撃が適切に行われることを確認する
独立した攻撃サーバーからかけられる攻撃の限界値を計測する

 スケールアップ/アウト試験ここからが本番

ステップ7まででボトルネックになっていたリソースに関してスケールアップ/スケールアウトを行い再試験を繰り返す。
システム性能がスケールアップやスケールアウトに追従して完全することを確認する
今まで負荷がかかっていなかった各サブシステムに適切な負荷をかけてそれぞれのチューニングを行う

 限界性能試験多くの場合は攻撃サーバー1台で十分な負荷をシステムにかけることができる。

目標スループットが高く、攻撃サーバー1台では適切な負荷をかけられないこともある。

その場合には攻撃サーバーをスケールアウトして、複数の攻撃サーバーから同時に負荷をかけることでより強い負荷をシステムに与え、その結果を観測する試験を行う。
単体の攻撃サーバーからでは負荷をかけきれない、より大規模なシステムにおける負荷試験を実施
将来のリソース増強のためのマイルストーンを見積もる