負荷試験
Google SRE Book 17章「Testing for Reliability」を取得して読み、 理解した内容を自分の言葉で書いたもの。本文の引用はしていない。
かけ方の手順は 分散システムにある。 段階的に上げる、キャッシュを温めてからにする、通常負荷に戻したときの挙動を見る、 といった具体はそちら。
ここはなぜやるのか、何を答える試験なのか、そして結果をどこへ渡すのか。
なぜ要るのか
理由は1つ。
多くのコンポーネントは、ある閾値を超えると優雅に劣化せず、壊滅的に壊れる。
分散システムで 優雅な劣化を設計するのは、放っておけばそうならないから。 そして設計したつもりの劣化が本当に働くかは、実際に壊すまで分からない。
だから負荷試験は「速さの確認」ではなく、壊れ方の確認が主目的になる。
何を答える試験か
問いの形にすると具体的になる。
データベースはどこまで埋まると、書き込みが失敗し始めるか
アプリケーションサーバーは秒間何クエリで過負荷になり、リクエストが失敗し始めるか
「どこまでなら大丈夫か」ではなく「どこで壊れるか」を聞いているのが要点。 上限を探しに行く試験なので、壊さずに終わったら情報が得られていない。
答えは数字1つではなく、限界点と、そこでの壊れ方の組になる。
カナリアは試験ではない
ここは区別しておく価値がある。
カナリアテストは、実のところ試験ではない。構造化された利用者による受け入れ。
一部のサーバーだけ更新して、期間を置いて様子を見る(バイナリを「寝かせる」)。 やっていることは、予測しにくい本番のトラフィックに新しいコードを晒すことであって、 あらかじめ決めた条件を検証しているわけではない。
だから完全ではなく、新しく入った欠陥を常に捕まえるとは限らない。
負荷試験がカナリアの代わりにならないし、逆も成り立たない。 カナリアの運用はデプロイ戦略にある。
本番で確かめる
既知の良いリクエストを、本番に監視プローブとして流す。
一見すると無駄に見える。同じリクエストは事前に試験済みだから。 それでも意味があるのは、試しているのが「組み合わせ」だから。
フロントエンドとバックエンドは独立したリリースサイクルを持つので、 いま本番で組み合わさっている特定の版どうしは、一度も一緒に検証されていないことがある。
密閉した試験環境では原理的に捕まえられない種類の不整合が、ここに出る。
既知のデータに対して試験することと、未知の利用者データを監視することは、 別のことをしている。
試験の限界
オフラインの試験と、本番の監視のあいだには埋まらない差がある。
試験 決めた筋書きを、決めた条件で確かめる
監視 バグを見つけられるが、報告経路が反応できる速さでしか反応できない
現実の規模、現実のタイミング、同時に起きる複数の障害の下での挙動は、 出すまで部分的に分からないままになる。
だからデプロイ戦略のように 出し方の側で影響範囲を絞る必要が出てくる。 「十分に試験したから安全に出せる」は成り立たない。
結果をどこへ渡すか
限界点の数字は、2つの場所で使われる。
測りっぱなしにしない。 キャパシティ計画にあるとおり、 数字が意図に翻訳されないと、資源の都合が変わるたびに人が計画を作り直すことになる。
QPS ではなく実際に消費する資源で測るのは 分散システムと同じ理由。 クエリごとに必要な資源が違うので、比率が予測不能に動く。