「正常」を数字で書かなければ、それはただの事故だ
一言でいうと
壊す前に「正常」が数字で書かれている必要があります。その数字がなければ、実験は事故と区別できません。
なぜ必要なのか
運用の振り返りで最もよく出る言葉が、「あのときは少し遅かったです」です。少し遅かったというのが、どれだけ遅かったのか、普段はどのくらいだったのかを、誰も言えません。その状態で障害を1つ注入すると、何が起きるでしょうか。画面が赤くなり、人が集まってきて、誰かがロールバックを押し、そして誰も、何を学んだかを言えません。それは実験ではなく、ただの事故です。
カオスエンジニアリングが違うのは、壊すことにあるのではありません。壊す前に、何を測るのか、何が起きると信じているのか、いつ止めるのかを、先に文章に書いておくことにあります。カオスエンジニアリングの原則が、最初の項目に「システムの正常な動作を、測定可能な出力として定義せよ」を置いている理由が、これです。内部状態(CPU使用率、ヒープサイズ)ではなく、外から見える出力、つまりリクエストが成功する割合と、応答が返ってくる時間で定義するよう、明記しています。内部指標は、障害ではないのに揺れ、本物の障害なのに問題なさそうに見えることがあるからです。
どう動くのか
定常状態は、普通2つの軸で書きます。可用性とレイテンシです。この2つは別の軸なので、一緒に書く必要があります。リクエストの99.9%が成功しても、p95の応答が3秒なら、ユーザーは故障だと感じ、逆に、応答は20ミリ秒なのに20回に1回失敗するなら、それも故障です。1つの軸だけを見ると、実験結果の半分を見逃します。
レイテンシは、平均ではなくパーセンタイルで書きます。平均は、遅いテールを薄めてしまいます。リクエスト100件のうち5件が2秒で、残りが20ミリ秒なら、平均は120ミリ秒で問題なさそうに見えますが、p95は2秒なので、問題がそのまま表に出ます。ユーザーは平均を経験しません。自分のリクエスト1つを経験します。
정상 상태 기술의 예 (이 코스의 실습에서 실제로 쓰는 형식)
availability_ratio_min : 0.98 20초 동안 정적 경로 200회 중 196회 이상 성공
p95_ms_max : 70 CPU 를 쓰는 경로의 95분위 응답이 70밀리초 이하
そして、中止条件を一緒に書きます。「成功率が半分を下回ったら、すぐに元に戻す」のような文です。実験の最中は、判断が曇ります。もう少し見れば原因が見えそうで、元に戻すと、また設定し直すのが面倒です。その瞬間に備えて、落ち着いているときに書いておいた文が必要です。
最後に、爆発半径(blast radius)を決めます。レプリカ1つだけ、1つのネームスペースの中だけ、トラフィックの1%だけ。実験は、仮説を確認できるだけの大きさで足り、それより大きいと、得るものなしにリスクだけが大きくなります。
測定ウィンドウの長さとサンプル数も、あらかじめ決めておきます。ウィンドウが短すぎると、復旧が速い障害をまるごと見逃し、サンプルが少なすぎると、1件の失敗が成功率を5%ずつ揺らして、何を見ても有意に見えます。このコースのラボは、20秒のウィンドウで毎秒10回の可用性リクエストを送って、200件を集めます。1件の失敗が0.5%に当たるので、0.98という境界が「4件までは大丈夫」という意味になり、解釈がはっきりします。境界の数字よりも、その数字が何件に当たるかを知っていることが、実験を読む感覚を作ります。
現場での姿
Kubernetesでは、「正常」が何層にも分かれているので、さらに注意が必要です。PodがRunningであることとReadyであることは別の事実で、Readyであることと、Serviceのエンドポイントに載ってトラフィックを受けることも、また別の事実です。コンテナの準備状態はreadinessProbeが決め、その結果はPodのコンディションとして現れます。緑のランプが3つ点いていても、ユーザーのリクエストは失敗することがあります。
そのため、実戦ではクラスターの状態を「定常状態」としません。外から実際にリクエストを送ってみた結果を定常状態とし、クラスターの状態は、それを説明する補助的な証拠として使います。この順序を逆にすると、ダッシュボードはすべて緑なのに、カスタマーセンターだけが忙しくなる、見慣れた光景ができあがります。
ベースラインを測るときに、よくやってしまうミスがもう1つあります。まだ安定していない状態を、ベースラインにすることです。デプロイした直後は、キャッシュが空で、イメージが取得されたばかりなので、応答が普段より遅いです。その数字をベースラインにすると、あとで行うすべての比較が緩くなります。ロールアウトが終わり、プローブが安定してから測ること、そして、ベースラインを測っている間は、何も触らないことの2つを守る必要があります。このラボの記録ツールが、ベースラインの測定ウィンドウの中で新しいPodが生まれたら、記録を拒否する理由も同じです。
もう1つ付け加えると、定常状態は、チームが合意した文である必要があります。1人で決めた基準は、事件が起きたときに必ず揺らぎます。「p95 70ミリ秒」という数字がどこから出たのか、なぜ60でも100でもないのかを、説明できなければならず、その説明は、たいてい「普段測ってみたら33ミリ秒で、2倍まではユーザーが感じない」のような、実測と判断の組み合わせです。数字だけあって根拠のない基準は、次の四半期に、何の理由もなく変わります。
次のクイズで確認すること
定常状態をなぜ外から見える出力で定義するのか、レイテンシをなぜ平均ではなくパーセンタイルで書くのか、中止条件と爆発半径が実験でそれぞれどのような役割を果たすのかを確認します。