GitHubが約8時間ダウンした原因が判明、急増する利用量に重要なインフラが自動拡張できず障害が連鎖

親愛なる読者の皆さまへ。ご存じの通り価格高騰などの悪影響でサーバー運営がとても苦しい状態です。回線や台数を整理し見直せる部分は全て見直しましたが、やはりまだ危険水域です。このままだと1ページを10分割ぐらいして無理矢理PVを増やさざるを得なくなってしまいます。そこで、GIGAZINEの物理的なサーバーたちを、たった1円でも良いので親愛なる読者の皆さまに支援してもらえればとっても助かります！今すぐ寄付は上のボタンから！ ・ これまでGIGAZINEを支援してくれたメンバーのリスト

2026年8月17日から18日にかけてGitHubで世界規模の障害が発生し、GitHub.comやGitHub Actions、GitHub Copilotなど多数のサービスが利用しづらくなりました。GitHubは8月20日に調査結果を公表し、過去最高水準のトラフィックに対してアメリカ中部のデータセンターにある重要なインフラが処理能力を拡張できず、障害が連鎖したと説明しています。 The August 17 outage, and the work ahead - The GitHub Blog https://github.blog/news-insights/company-news/the-august-17-outage-and-the-work-ahead/ 障害は日本時間の8月17日22時28分ごろから8月18日6時15分まで7時間47分にわたって続きました。ピーク時にはウェブ機能やAPIで約20％、アーカイブやリポジトリの生コンテンツのダウンロードでは約50％のエラーが発生。IssuesやPull Requests、Actions、Copilotに加えて認証機能にも影響が広がりました。 GitHubが世界中でダウン - GIGAZINE

GitHubの調査によると障害のきっかけはトラフィックが過去最高水準に達したことでした。アメリカ中部のデータセンターでは、サービス間の通信を仲介する「Istio」のサイドカーと呼ばれる補助コンポーネントが同時処理数の上限に到達。しかし、自動的に処理能力を増やす仕組みが本体側サービスの状態だけを監視しており、サイドカーの処理上限を考慮できていなかったため必要な拡張が行われませんでした。 容量不足はさらに別の設備へ波及しました。最終的に通信を振り分ける4台の「HAProxy」が通信処理の上限に達し、GitHub内部の認証経路で遅延やエラーが発生。認証機能は多数のGitHubサービスから利用されるため、GitHub.comやActionsなど広い範囲へ障害が連鎖する結果になったというわけです。

さらに復旧を難しくしたのが、通信に失敗した場合に自動で通信をやり直す「リトライ」でした。障害発生中に大量のリトライが行われたことで内部のロードバランサーへの負荷が増加したほか、Visual Studio Code(VS Code)にはGitHub Copilotの認証に失敗すると大量のリトライを発生させる潜在的な不具合が存在していました。Copilotの認証トークンを処理するサービスへのアクセスは通常の毎秒7000～9000件から毎秒7万～10万件まで膨れ上がり、Copilotの復旧が他のサービスより遅れる原因になったとのこと。 GitHubは8月17日の障害について、コードや設定の変更が直接の原因だったわけではなく「根本的には容量不足だった」と説明しています。GitHubでは利用量そのものが急増しており、月間コミット数は2026年4月の14億件から29億件へ約4カ月で倍増しました。 下図はGitHubの利用状況の推移を示したグラフです。2023年以降、1カ月当たりのマージされたPull Request、新規リポジトリ、コミットはいずれも急増しており、2026年8月にはマージされたPull Requestが約1億3000万件、コミットが約29億件、新規リポジトリが約2400万件に達しています。

急増する利用量に対応するためGitHubは以前からインフラの増強を進めていました。これまでに300万以上のCPUコアと120PBの高速ストレージを追加し、ネットワーク容量も大幅に増強。既存のデータセンターでは利用可能な電力の範囲内でハードウェアを増設するとともに、Microsoft Azureへの移行も加速させています。 2026年5月時点でGitHub全体の処理量に占めるAzureの割合は12％でしたが、すでに約58％まで増加しているとのこと。Git操作についても約半分をAzureが処理しています。インフラ拡張はGitHub Actionsのジョブ実行数の増加も支えており、2026年初頭には数千万件規模だったActions実行数は8月には1億1540万件まで増加しました。

GitHubは巨大なリポジトリを扱う際の性能向上も進めています。巨大なリポジトリでは多数の開発者やシステムが同時にデータを読み出すため、利用者が増えても読み取り処理を効率よく増やせる仕組みが必要になります。GitHubはAzureのインフラと追加した処理能力を利用して大規模リポジトリへの対応を進めており、高い並列度で「git fetch」を実行した場合の処理能力を示すグラフも公開しました。 GitHubは次の段階として「読み取り側の数に応じて処理能力を直線的に増やせるアーキテクチャを導入し、まず最大規模のリポジトリから段階的に展開する予定」と述べ、下図のグラフを公開しています。グラフでは左側の例で1秒当たり約1000回付近に処理量がとどまっている一方、右側では処理量が段階的に増加して1秒当たり約1800回まで伸びています。

GitHubは処理容量を増やす以外にも、サービス同士の通信でリトライできる量に上限を設けることで大量の再試行によってさらに負荷が増える「リトライストーム」を防ぐ仕組みを導入するほか、自動拡張設定やロードバランサーの容量監視、VS Codeのリトライ動作なども見直す予定。重要なシステム同士の依存関係を減らし、一部の障害がGitHub全体へ広がりにくくする取り組みも進めるとしています。また、システム変更の速度や複雑さに従来の運用方法が追いついていなかったとしてテストや安全な展開、監視、アラートの強化も進めるとのことです。 GitHub最高技術責任者(CTO)のウラジーミル・フェドロフ氏は、急速な利用量の増加はシステムにかかっている負荷を説明するものではあるものの、障害の言い訳にはならないと説明。GitHubはプラットフォームの拡張と信頼性向上を進め、利用者からの信頼を取り戻していくと述べています。

・関連記事 GitHubの過去1年間のダウンタイムを「草」形式で可視化する「Red Squares」 - GIGAZINE GitHubで立て続けに数十件の大規模障害が発生したことを受けMicrosoftはライバルのAWSに協力を求めることに、AI主導の成長でインフラにとてつもない負荷がかかっているため - GIGAZINE CursorがGitHub対抗のコードホスティングサービス「Origin」を発表 - GIGAZINE 人気ターミナル「Ghostty」がGitHubからの離脱を表明、開発者が「何が不満なのか」を語る - GIGAZINE 「ghcr.io」を「ghrc[.]io」にタイプミスするとGitHubの資格情報が盗まれるとの指摘 - GIGAZINE

You can read the machine translated English article The reaso