GitHub、8月17日の大規模障害を検証 再発防止へCPU300万基追加
The August 17 outage, and the work ahead
GitHubは8月17日に発生した約7時間47分に及ぶ大規模障害の原因を公表した。トラフィックが新記録に達し、中米データセンターの重要インフラがスケールせず、認証障害や複数サービスの停止を引き起こした。4月以降の月間コミット数は14億から29億へ倍増しており、容量不足が根本原因としている。GitHubはCPU300万基以上、高速ストレージ120ペタバイトを追加し、Azureへの移行を加速。現在はプラットフォーム負荷の約58%をAzureが処理する。さらに、リトライ制限やタイムアウトの可変設定など再発防止策を実施する。
「開発者コミュニティはGitHubに依存してソフトウェアを構築・出荷・運用しています。それは私たちを信頼できる場合にのみ可能であり、8月17日にはそれができませんでした。それを修正するのは私たちの責任です。」
HNでの議論
731- afc
> どちらの障害も、その核心はキャパシティ不足でした。需要がキャパシティを超える前に、重要なコンポーネントをスケールさせることができませんでした。
これは間違った考え方です。なぜなら、無限のキャパシティなど存在しないからです。大規模な分散システムは、大部分がアイドル状態である一方で、（一部のサブコンポーネントでは）過負荷状態になるということが同時に起こります。根本原因は「コンポーネントに十分なキャパシティがなかった（オートスケーリングの失敗による）」ではなく、「この複雑なシステムは、需要がキャパシティを超えたときに（グレースフルに劣化するのではなく）崩壊する」ということです。
コンポーネントがキャパシティの限界に達したとき、最も優先度の低い過剰なトラフィックは拒否されるべきです。拒否されたトラフィックは再試行されるべきではありません。実際、クライアントはこれらのエラーを再試行すべきではないだけでなく、これらのエラーはクライアント側のスロットリングを引き起こすべきです。トラフィックの分離を適用すべきです。過負荷の原因が単一のクライアント/顧客システムである場合、他のシステムに影響を与えるべきではありません。
約10年前、私はGoogleでこれらの保護を実装するために適用したいくつかのテクニックについて書きました：https://sre.google/sre-book/handling-overload/ その後、他のほとんどの大規模なインターネットサービスもこれをコピーしたと思います。
- prennert
なぜGitHubは無料プランをエンタープライズ、あるいはできればすべての有料プランから分離しないのでしょうか？
エンタープライズプランが無料および公開リポジトリのトラフィックによって影響を受けるのは受け入れがたいです。私たちのリポジトリは無料プランでもなく、公開でもありません。ここ数週間、AI関連のことが増えたわけでもありません。私たちのトラフィックは安定しています。ほとんどのエンタープライズが突然トラフィックを急増させたとは思いません。たとえそうだとしても、私たちはクォータに対して支払っています。それでも、GitHub Actionsが壊れたり、PRが表示されなかったりすることがありました。
この不安定さがフォージのカンブリア爆発を引き起こすことを願っています。もしそうなれば、GitHubはAI革命の最初の犠牲者になるでしょう。
私は今、真に分散型/ローカルファーストのコードレビューに取り組んでいますが、その大きな動機の一部はGitHubがどれほどひどくなったかということです。CIも構築する時間があるかどうかはわかりませんが、他の人がやってくれることを願っています。そうでなければ、Jenkinsに戻るだけです。
- blakesterz
「4月以来、月間コミット数は14億から29億に増加しました。」
わあ、それは本当に短い期間での信じられないほどの成長ですね。
- madrox
GitHubを称賛します。しかし、どんなに勇敢であっても、この状況から抜け出せないと思います。スケールの問題は悪化し続けるでしょうし、それが彼らにとってより多くの収入につながるとは思えない形で悪化しています。遅かれ早かれ、現在無料のものに対して課金せざるを得なくなるでしょう。
私はこれをしばらく前から言っています：https://news.ycombinator.com/item?id=47534499
- aesthetics1
> 4月以来、月間コミット数は14億から29億に増加しました
常軌を逸しています。
業界全体が「生産性パニック」に陥っているのがわかります。そして、これがさらなる証拠です。どこかでスピード狂が感激の涙を流していることでしょう。
- arn3n
コミットに対して課金してAIを多用するユーザーを追い出すことを提案する人たちは、GitHubがMicrosoftの所有であり、開発者にAIを使わせ続ける大きなインセンティブがあることを忘れています。
Microsoftは、その損失がすべてのユーザーが自社のモデルを使用し、コードを生成するためにOpenAIのサブスクリプションを支払っていることによるものであれば、GitHubを赤字で運営することを好むかもしれません。
- jdm2212
> これらのサービスでのエラーが、復旧中にクライアント側の再試行ループを引き起こし、トラフィックを増加させました。
私が関わった最悪の障害には、常に何らかの形でこれが含まれています :(
- cube00
> これらのサービスでのエラーが、復旧中にクライアント側の再試行ループを引き起こし、トラフィックを増加させました
これは、たとえユーザーが7時間スピナーを見つめることになっても、ユーザーにエラーを一切見せないようにするという広範な傾向の兆候です。
> 単一の内部エンドポイントへの応答遅延が、VS Codeの潜在的な再試行バグを引き起こし、トラフィックを約10倍に増幅し、Copilot Token Serviceの復旧を遅らせました。
詳細な根本原因分析はこれを「バグ」として処理しようとしています。クライアントの再試行に、再試行のバックオフ動作が設計通りに機能していることを保証する単体テストがないと真剣に言うことはできません。この場合、トークンサービスの応答が不安定になった場合に問題を隠そうと積極的に試みています。
- augunrik
どうでしょうか、このブログ投稿と最近のものは、組織的および人的な失敗のように私には思えます。
彼らのシステムは劣化せず、無限の再試行があり、意味のあるクォータもどこにも見当たりません（私はGitHubをあまり使っていませんが）。
これはSaaSを設計・運用してはいけない方法についての教訓になると思います。
- altcognito
異なるサービスに分散させるのは悪い考えではないでしょう....
それでも、彼らが無料の側面でやっていることには少し感謝せずにはいられません。それが利他的でないことはわかっていますし、誰も10億ドルの企業を擁護する必要はないこともわかっていますが...
この規模で、無料で（広告なしで）彼らがやっていることを提供する他のサービスを挙げてください。それは簡単なことではありません。Wikipediaはおそらくより多くの利用がありますが、より単純な取り組みです。（モデレーションの部分を除けば、それは素晴らしいです）OpenStreetMap？より小さく、より単純です。Internet Archive？これもより小さく、より単純です。Linuxディストリビューションのミラー？これも、GitHubが無料でやっていることよりも小さく、より単純です。