GitHubのオートスケーリングとコンポーネント置換の誤謬

Lorin Hochstein インシデント、レジリエンス、ソフトウェア、システム 2026年8月19日 3分 昨日のGitHubの障害に関する投稿には、私が何も言及しなかった詳細がありました：飽和したIstioサイドカーを持つサービスのオートスケーリングポリシーです。当初、これはIstioサイドカーポッドが同時実行数の上限に達し、ホストサービスは監視するもののサイドカーの上限は監視しないという誤設定されたポリシーのために正しくオートスケールできなかったことが原因でした。 このブログの読者はおそらくオートスケーリングが何であるか、そしてそれがどのように機能するかをよく知っていると思いますが、念のため簡単な要約を以下に示します。 サービスが必要とするコンピューティングおよびメモリリソースの量は、そのサービスに課される負荷によって異なります。ここでの負荷の関連ソースは、トラフィックとしても知られるサービスに対する外部リクエストです。トラフィックの量は時間とともに変化します。例えば、GitHubのような企業では、平日の日中の方が夜間や週末よりもトラフィックが多いと推測されます。 負荷は動的に変化し、サービスが必要とするコンピューティングおよびメモリリソースは負荷の関数であるため、2つの一般的な戦略があります。1つの戦略は、ピーク負荷のためにサービスをプロビジョニングすることです。もう1つの戦略は、現在の負荷に基づいてサービスに割り当てられるリソースを動的に調整することです。これはオートスケーリングと呼ばれます。 サービスでオートスケーリングを使用したい場合は、オートスケーリングポリシーを定義する必要があります。特に、負荷を表すメトリックを選択し、そのメトリックがどのように変化するかに基づいてリソースをどのように追加または削除するかを指定する必要があります。CPU使用率は、オートスケーリングに使用される一般的なメトリックです。しかし、CPUが低い場合でも、サービスが飽和する可能性があることに注意してください。例えば、スレッドプールでリクエストごとにスレッドを使用しており、下流リクエストのレイテンシが増加し、スレッドプールのすべてがブロックされてしまうシナリオを想像してみてください。この場合、サービスは飽和しており、新しいポッドを起動することから利益を得られますが、CPUは実際には低いです。なぜなら、スレッドはI/Oを待ってブロックされているからです（これは2021年にSlackで起こりました）。 ここで、そのようなケースを処理するためにオートスケーリングポリシーに追加のルールを追加できます（Slackが行ったように、スレッド数に基づいて急速にスケールアップしました）。または、サービスがCPUバウンドでない場合は、CPUではなく、受信リクエストボリュームに基づいてスケールすることもできます。 GitHubのレポートに基づくと、影響を受けたサービスのオートスケーリングポリシーは、サービス自体の負荷のみを考慮し、Istioサイドカーの負荷は考慮しない負荷メトリックを使用していたようです。 一般的に、各サービスは負荷の下で異なる動作をします。これは、すべてのオートスケーリングポリシーが実質的にカスタムメイドであることを意味します。これは、サービスを所有するチームがビジネスロジックだけでなく、カスタムパラメータを持つ運用制御システムにも責任を負うことを意味し、これはロードテストを通じてのみチェックできます。（すべてのサービスでロードテストを実施していますか？）サービスオーナーは、ほぼ間違いなくオートスケーリングの専門家ではありません。したがって、誤設定されたオートスケーリングポリシーがここで貢献した要因であることは驚くことではありません。 しかし、オートスケーリングのリスクを認識してもらうために、このポリシーの特定の欠陥について議論する価値はあると思いますが、このインシデントに関わる他の要因を無視して、それに固執しすぎるのも簡単だと思います。これは、David Woodsがコンポーネント置換の誤謬と呼ぶものです。つまり、信頼性を向上させる方法は、欠陥のあるコンポーネントを特定して修正することに労力を集中させるという考え方です。確かに、インシデントによって明らかになった欠陥を特定して修正すべきですが、同時に次のことも認識する必要があります。 あなたのシステムは、現時点でも、これらのすべての欠陥が存在するにもかかわらず、潜在的なコンポーネントの欠陥に満ちています。 これらの欠陥すべてが存在するにもかかわらず、あなたのシステムは常に障害を起こしているわけではありません。 これは、コンポーネントの欠陥だけではシステムをダウンさせることはできない、あるいはシステムはすでにダウンしているはずだということです。 個々のコンポーネントを見るだけでなく、相互作用をファーストクラスとして扱ってください。 GitHubの障害では、次のような要因間の相互作用についての議論が見られます：トラフィックパターンの変化（スクレイパーを含む）、オートスケーリングポリシー、Istioサイドカーの飽和、リトライロジック、HAProxyノードの飽和、認証トラフィック。 また、迅速に公開された公開レポートであるため、私たちにはわからない多くの詳細があります。良い情報は内部レポートにのみ見つけることができます。 私はこの投稿で、サービスオーナーとオートスケーリングポリシーの関係について推測しましたが、ここでの歴史についてもっと知りたいです（例えば、このポリシーはIstioサイドカーの使用より前に存在していましたか？）。また、問題のあるトラフィックについてももっと知りたいです（どのような種類の要求でしたか？突然の増加でしたか、それとも徐々に増加しましたか？トラフィックが増加した理由を知っていますか？）。 公開されているインシデントレポートではこれらの質問に答えることはできませんが、あなたの組織内の内部レポートでは可能です。質問をすることはあなた次第です。 共有： Xで共有 (新規ウィンドウで開く) X Facebookで共有 (新規ウィンドウで開く) Facebook いいね 読み込み中... Lorin Hochsteinによって公開 Lorin Hochsteinのすべての投稿を表示 公開日：2026年8月19日