8月19日、信頼性エンジニアリング分野のブロガーとして知られるLorin Hochsteinが「GitHub, autoscaling, and the component substitution fallacy」と題した記事を公開した。GitHubで発生した障害のポストモーテムを題材に、「欠陥コンポーネントを特定して直せば信頼性は上がる」という根強い思い込みの危うさを鋭く指摘した内容だ。

HochsteinはNetflixに在籍した経験を持ち、複雑系における障害分析について長年考察を続けているブロガー・研究者だ。今回の記事は単なる障害解説にとどまらず、多くのエンジニア組織が陥りがちな分析の「落とし穴」を正面から問い直す内容になっている。

GitHubのポストモーテムに書かれていたこと

GitHubの障害ポストモーテムには、次のような記述がある。

Originally this was caused by an Istio sidecar pod reaching its concurrency limits and failing to auto scale correctly because of a misconfigured policy that watched host service but not sidecar limits.
（要約：Istioサイドカーポッドが同時接続数の上限に達したが、ホストサービスの負荷しか監視しない誤設定のポリシーが原因で、オートスケーリングが正しく機能しなかった）

読んだ印象としては「ポリシーの設定ミスが原因、直した、終わり」に見える。しかしHochsteinはこの読み方に強く警鐘を鳴らす。

オートスケーリングポリシーの本質的な難しさ

まず前提として、オートスケーリングの仕組みを整理しておく。サービスへの負荷は時間帯や状況によって変動する。この変動に対応するため、ピーク時のリソースを事前に確保しておく方法と、負荷に応じて動的にリソースを増減する「オートスケーリング」の2つの戦略がある。

オートスケーリングでは、どの指標（メトリクス）を監視してスケールするかを定義した「ポリシー」が必要だ。よく使われるのはCPU使用率だが、CPUが低くても飽和状態になるケースがある。

典型的な例が、スレッドプールを使ったサービスで下流のレスポンスが遅延した場合だ。すべてのスレッドがI/O待ちでブロックされ、CPUはほぼ遊んでいるのにサービスは完全に詰まる。Hochsteinは以前の記事でも2021年のSlack障害を例にこのパターンを解説している。

今回のGitHubのケースでは、Istioのサイドカー（メインのアプリコンテナと並走するプロキシプロセスで、サービスメッシュの通信制御を担う）の負荷をポリシーが考慮していなかった。ホストサービスの指標だけを見ていたため、サイドカーが詰まっていても「問題なし」と判断され、スケールアウトが走らなかった。

Hochsteinはここで重要な指摘をする。サービスごとに負荷への振る舞いは異なるため、オートスケーリングポリシーは事実上すべてカスタム設計になる。サービスオーナーはビジネスロジックの実装だけでなく、独自パラメータを持つ運用制御システムの設計・検証も担うことになる。そしてその検証は、ロードテストなしには事実上不可能だ。

「欠陥コンポーネントを直せば解決」という思い込みの罠

ここからが記事の核心だ。

Hochsteinはレジリエンスエンジニアリングの第一人者として知られる研究者デイビッド・ウッズ（David Woods）の議論を参照しながら、「コンポーネント代替の誤謬（Component Substitution Fallacy）」を説明する。これは、「信頼性を高めるには欠陥コンポーネントを特定して修正すればよい」という考え方に潜む罠を指す。

「設定ミスが原因」と結論づけると、そのミスを修正することで問題が解決したように見える。しかし、この視点が見落とすのは次の点だ。

コンポーネントの欠陥だけではシステムはダウンしない。 もしそうなら、今この瞬間もシステムはダウンしているはずだ。複数の欠陥やストレスが重なり、特定の条件下で初めて障害が顕在化する。

今回のGitHubの障害でも、ポストモーテムが言及している要因はひとつではない。

• スクレイパーを含むトラフィックパターンの変化
• 誤設定されたオートスケーリングポリシー
• Istioサイドカーの飽和
• リトライロジック
• HAProxyノードの飽和
• 認証トラフィックの増加

これらの相互作用こそが障害の本質だ。個々のコンポーネントではなく、その組み合わせと連鎖を分析することが重要になる。

公開ポストモーテムが答えられない問い

Hochsteinはさらに、今回の障害で本来知りたい情報が公開ポストモーテムからは得られないことも指摘する。

• このオートスケーリングポリシーは、Istioサイドカーを導入する前に書かれたものではないか
• 問題のトラフィックはどんな種類のリクエストだったか
• 急増だったのか、緩やかな増加だったのか
• なぜトラフィックが増加したのか

これらは社内の詳細なポストモーテムには書かれているはずの情報だ。公開レポートでは得られなくても、自分の組織の障害分析では必ず問うべき問いだとHochsteinは締めくくっている。

「設定ミスを直した」で終わる分析は、同じ構造の障害が別の場所で起きたときに何も防いでくれない。障害を「コンポーネントの問題」として閉じるのではなく、「システム全体の振る舞い」として問い直す視点がここには詰まっている。

詳細はGitHub, autoscaling, and the component substitution fallacyを参照していただきたい。