こう
- 「負荷試験は、
どう 計画して 結果を どう 読みますか」 - 「来月の
セールで、 使う 人が ふだんの 10 倍に なりそうです。 何を 確かめますか」 - 「負荷試験で 1 秒に 1000 件さばけました。
これで 大丈夫ですか」 (裏から聞く形)
面接官が
- 試す前に、
何を どこまで 耐えれば よいかの 目標を 数字で置けるか - 本番に
近い 環境、 データの 量、 使われ方で 試す 大事さを 分かっているか - 結果を
平均で 読まず、 遅い ほうの 人の 時間と エラーの 割合で読めるか - 限界の
数字だけでなく、 どこが 先に 詰まったかを 突き止めるか
短い答え
- 先に
目標を 数字で 置きます。 1 秒に 何件の 要求を、 遅い ほうの 人でも 何秒以内に、 エラーを 何 % 未満で 返せば よいか、です。 - 本番に
近い 環境と データの 量で、 実際の 使われ方を まねた 筋書きを 作り、 負荷を 少しずつ上げて、 どこで 目標を 外れるかを 探します。 - 結果は
平均ではなく、 遅い ほうの 人の 時間と エラーの 割合で 読み、 その ときに DB、 CPU、 接続の 数の どこが 先に 詰まったかを 突き止めます。
この
少し
目標を先に置く
負荷試験は
ピーク 1 秒に 500 件の要求
遅さ 上から 5% の人でも 1 秒以内 (95 パーセンタイル)
エラー 0.1% 未満ピークの
本番に近づける
試す環境が
- 台数と設定 サーバーの
大きさ、 台数、 DB の 大きさ。 ステージングが 小さいなら、 その差を 頭に 入れて読みます - データの量行の
数が 1000 件と 1000 万件では、 同じ 問い 合わせでも 速さが まるで違います - 使われ方 1 つの API を
叩き続けるのではなく、 一覧を 見る、 詳しく 見る、 買う、の 割合を 実際に 近づけます。 同じ ID ばかり 使うと、 キャッシュが 効きすぎて 速く見えます
外の
少しずつ上げて読む
負荷を
その
短い
話すときは、
よく
- 目標を
決めずに試す 「1 秒に 1000 件さばけた」が 良いのか 悪いのか、 判断できません - 平均の
速さだけで 合格にする 平均が 速くても、 遅い ほうの 人や エラーが 目標を 外れている ことがあります - 小さな
環境と 少ない データで試す本番でだけ出る 遅さを 見落とします。 同じ ID ばかり 使うのも、 キャッシュで 速く 見える原因です - 試す側の
機械が 先に詰まる 負荷を かける 側の CPU や 回線が 限界だと、 相手の 限界は 分かりません
深掘りの問い
- 「本番で
負荷試験を して よいですか」 利用者や 外の サービスに 影響が 出るので、 基本は しない。 する 場合は 時間と 量を 決め、 止める 手を 用意して 行う、と答えます - 「限界が足りなかったら」詰まった
所を 直すか、 台数を 増やすか、 大きく するかを、 費用と 手間で 選ぶ、 と答えます - 「結果を次に生かすには」限界の
数字と 詰まった 所を 残し、 同じ 筋書きを 大きな 変更の たびに 回す、と答えます