GitHubの可用性に関するアップデート
(github.blog)- 最近2回の障害 を受け、GitHubは可用性を最優先に据え、急増した開発ワークロードと agentic development workflows に合わせてインフラとアーキテクチャを見直している
- 1つの pull request でも Gitリポジトリ、Actions、検索、通知、権限、webhooks、APIs、バックグラウンドジョブ、キャッシュ、データベースまで広く結びついており、小さな非効率が積み重なると キューの滞留 や 依存関係の波及 につながりうる
- 短期的には、webhooks の バックエンド移行、ユーザーセッションキャッシュの再設計、認証・認可フローの調整、Azureベースのコンピュート拡張によって、ボトルネックとデータベース負荷の削減に注力している
- 長期的には、中核サービスの分離、単一障害点の縮小、Ruby monolith の一部を Go へ移行、public cloud への移行と multi cloud 経路 の確保を通じて、回復力と柔軟性を高めている
- 4月23日の merge queue のリグレッションと 4月27日の Elasticsearch 過負荷のいずれも データ損失はなく、GitHub は status page に availability 指標を追加し、小規模な障害まで公開範囲を広げて透明性も強化している
可用性対応の背景
- GitHubは 最近2回の障害 を受け、可用性と信頼性の改善状況を整理した
- 2025年10月から 容量を10倍に拡大する計画 を実行しており、2026年2月には現在規模の30倍を前提に設計する必要が明確になった
- ソフトウェア開発の進め方の変化が主な背景であり、2025年下半期以降 agentic development workflows が急速に加速している
- リポジトリ作成、pull request の活動、API利用量、自動化、大規模リポジトリのワークロードがいずれも急速に増加している
拡張の過程で明らかになった構造的負荷
- 1つの pull request が Gitリポジトリ、mergeability checks、branch protection、GitHub Actions、search、notifications、permissions、webhooks、APIs、background jobs、caches、databases まで同時に触れる可能性がある
- 大規模環境では小さな非効率も蓄積し、キューの滞留、キャッシュミスによるデータベース負荷への転嫁、インデックス遅延、リトライトラフィックの増幅、遅い依存先による複数製品への影響につながりうる
- 優先順位は 可用性を最優先、次に容量、その次に新機能という形で整理されている
- 不要な処理の削減、キャッシュ改善、中核サービスの分離、単一障害点の除去、性能に敏感な経路の専用システムへの移行を並行して進めている
- あるサブシステムに負荷がかかっても全体が崩れないよう、隠れた結合の縮小、blast radius の制限、graceful degradation の確保が重要課題となっている
現在進行中の改善作業
- 短期的には、想定より早く顕在化したボトルネックの解消に集中している
- webhooks を MySQL の外にある別のバックエンドへ移行 し、ユーザーセッションキャッシュを再設計し、認証・認可フローも見直して、データベース負荷を大幅に減らした
- Azure 移行を活用して より多くのコンピュート資源 も確保した
- その後は git や GitHub Actions のような 中核サービスの分離 と単一障害点の縮小に注力している
- 依存関係とトラフィック階層を細かく分析して何を分離すべきかを把握し、各種攻撃が通常トラフィックへ与える影響を最小化する方向で、リスク順に対応している
- 性能や規模に敏感なコードの一部を Ruby monolith から Go へ移行 する作業も加速している
- 既存の小規模な自社データセンターから public cloud へ移行する作業を進める中で、さらに長期的には multi cloud 経路 も同時に推進し始めている
- この長期施策は、今後必要となる回復力、低遅延、柔軟性を確保するために必要である
大規模リポジトリと merge queue への対応
- リポジトリ数の増加以上に難しい拡張課題として 大規模 monorepo の増加 を挙げている
- この3か月間で git システムと pull request 体験の両面において、この傾向に対応する投資を大きく増やした
- より高い効率と拡張性のための 新API設計 に関する作業も進行中で、別のブログ記事で公開予定である
- 1日に数千件の pull request が発生するリポジトリで重要であることから、merge queue の処理最適化 にも投資している
最近の障害 1: 4月23日の merge queue 問題
- 4月23日には pull request の merge queue 動作におけるリグレッション が発生した
- squash merge 方式を使う merge queue で、merge group に pull request が2件以上含まれると 誤った merge commit が生成された
- 影響を受けた場合、その後のマージによって、先にマージされた pull request と既存コミットの変更が意図せず巻き戻される状態につながった
- 影響期間中に 658件のリポジトリと2,092件の pull request が影響を受けた
- 初期の数値は保守的に見積もっていたため、当初共有した数値はこれよりやや高かった
- merge queue の外でマージされた pull request には影響がなく、merge または rebase 方式を使う merge queue グループも影響を受けなかった
- データ損失はなかった。すべてのコミットは Git に保存されたまま残っていた
- ただし、影響を受けたリポジトリのデフォルトブランチの状態は誤っており、すべてのリポジトリを安全に自動復旧することはできなかった
- incident root cause analysis: 追加の詳細を確認できる
- 今回の障害により複数の プロセス上の不備 が明らかになり、同種の問題が再発しないようこれらのプロセスを変更している
最近の障害 2: 4月27日の検索関連問題
- 4月27日には、複数の検索ベース体験を担う Elasticsearch サブシステム で障害が発生した
- 影響範囲には、pull requests、issues、projects における一部の検索ベースUIが含まれた
- 根本原因分析はまだ完了しておらず、まもなく公開される予定である
- 現時点で把握されているところでは、クラスターが 過負荷状態 となり、その結果検索結果を返せなくなった
- 過負荷の原因としては botnet attack の可能性 も残されているが、根本原因分析はまだ終わっていない
- データ損失はなく、Git 操作と APIs は影響を受けなかった
- ただし、検索に依存するUIの一部では結果をまったく表示できず、大きな混乱を招いた
- このシステムは単一障害点をなくすための完全な分離がまだ終わっていない領域であり、それ以前は他領域のリスク優先度の方が高かった
- 同じ方法による依存関係分析と blast radius 縮小の作業を適用し、この種の障害の発生可能性と影響を減らしている
障害時の透明性強化
- 障害発生時に、顧客がより高い 透明性 を求めていることが明確になった
- 最近 GitHub status page を更新し、availability 指標 を含めるようにした
- 大規模な障害だけでなく小規模な障害も status に掲載することにし、問題がユーザー側なのか GitHub 側なのかを推測させないようにするのが目的である
- 障害分類の方法も継続的に改善しており、規模と範囲をより理解しやすくしようとしている
- 障害時に顧客がシグナルを共有し問題を報告する方法についても、より良くする作業を進めている
今後の約束
- GitHubは 可用性の改善、回復力の拡大、将来のソフトウェア開発規模に合わせた拡張、そしてより透明なコミュニケーションを約束している
- 4月23日の障害における影響リポジトリ数は、2026年4月28日時点の情報に更新されている
2件のコメント
エラーがあまりにも多いので、取り急ぎいったん告知を出したということですね。
でも、あまりにも遅すぎるのではという気もしますが…。
すでにエラーが多すぎて、みんな離脱すると話しているところなのに つらい
Hacker Newsの意見
GitHubは今年に入ってからだけでも数十回の障害を起こしており、昨年よりも可用性と信頼性が目に見えて悪化している。
ここまで来るとダッシュボードやヒートマップが回るほど深刻で、HNやRedditのような場所でGitHubの不安定さがミーム化するレベルに達していると思う。
それなのに優先順位が"availability, capacity, new features"だと言うのは、現実認識があまりに甘い。
今の優先順位は1、2、3の全部がavailabilityであるべきで、少なくとも6か月は他の話をせず、それだけを直すべきだ
6か月前にはAzure移行が最優先だから機能開発を遅らせると言っていたのに、今度はまた可用性が最優先だというのは話の筋が通っていない。
当時はAIとCopilot需要のせいでバージニアのデータセンター容量制約が"existential"だと言っていたのに、いまだに同じ問題でふらついているのを見るとさらにあきれる。
機能開発は遅れていると言いながらも、毎週のように新機能やUI変更は出続けており、少し前にもissueの単一ビューを変えた。
Microsoftほどの資源を持つ会社がこうして同じところでずっとつまずいているのは信じがたいし、人気のある開発者向けサービスを買って全部同じプラットフォームへ移す戦略も不安に見える
大きなエンジニアリング組織では優先順位は排他的ではなく、中核的な優先事項に直接貢献できないチームは別の機能作業を続けることもある
https://news.ycombinator.com/item?id=47912521
専用ハードウェアのほうがクラウドより予測可能性が高く、"Azureへ行くな、ラックを数台追加しよう"のような判断はGitHub経営陣のレベルでは決められない話だったのかもしれない
GitHubは5分ごとに再設計するサイトではなく、管理職が自分たちの存在意義を示すために、新機能のための新機能を押し込んでいるように見えることがある。
その結果、壊せば壊すほどユーザーを引きつけるうえで逆効果になっている。
検索も大きく劣化したし、Google検索やYouTubeのように、なぜどこもまともだった検索を壊し続けるのか分からない。
しかもMicrosoftにはほぼ放置されたようなAzure DevOpsもありGitHubもあるが、どちらも特にチケットシステムが嫌いだ。
Jiraはプロジェクトごとに設定がバラバラでうんざりしていたのに、今では「むしろJiraが恋しい」とまで言いたくなる
あの記事は真顔で読むのが難しいという印象だ。
数字だけ大きく置いたラベルなしのグラフ、実際の体感と合わない優先順位、そしてこの12か月のひどいアップタイムをきちんと認めない態度がどうにも気に障る
左下の軸ラベルはないが、2023→2024→2025→2026と成長速度が非常に速いという要点は伝わる。
2026年の初めから終わりごろには、それ以前の3年を合計したより大きな成長を語っているようにも読めるし、軸の数値が分からなくても大まかな傾向は見える。
線形グラフだという前提は必要だが、文脈上その程度の仮定は無理がないように見える。
計画を大きく上回る成長を経験する会社なら容量問題が起きるのは避けられず、もはや単にハードウェアを足すだけではなくバックエンドの効率化が必要に見える。
書かれている目標もおおむねそこを狙っている
https://x.com/kdaigle/status/2040164759836778878
今の成長が指数関数的だということを信じられないのか、それとも年10倍成長くらい大したことではないと見ているのか分からない
https://damrnelson.github.io/github-historical-uptime/
「multi cloudパスを開始した」という文を見ると、MicrosoftがAzureだけでは望む水準の信頼性を出せないと事実上認めたようにも聞こえる
維持率の防衛には役立つかもしれない
もともとは人の介入がほとんどない運用を目指していたのに、今では誰かがラックやVMにシリアルを付けて直接触るようなやり方が日常的な手順になっている、という話だった。
今はリンクを見つけられないが
月〜木の午前9〜11時Pacificに最も活発な読者が多く、週末は競争は少ないが参加度も低い
GitHub CTOがCodepath.orgの理事にも入っていて、そこに「最初のAI-native世代のエンジニア、CTO、創業者を作る」といった説明があるなら、どこに問題があるのかだいたい察しがつく
体感としてGitHubの安定性はかなり悪く、最近はWebで表示されるデータ自体も信用しづらい。
昨日から私と同僚数人が、複数のリポジトリでPR一覧が不完全に表示されるのを確認している。
たとえば https://github.com/gap-system/gap/pulls ではタブには"Pull requests 78"と出るのに、一覧ビューでは"35 open"しか見えない。
78が正しい数字であることは
gh pr listでも確認できるのに、https://www.githubstatus.com はいまだに"all systems operational"と表示しているCLIでは一覧が出るのに、検索を通るWeb経路では全部消えている。
サポートチームもこの問題は認めていたが、その後は静かで、ステータスページにも27日のおそらく関連がありそうな問題以外は何もない。
一部のリポジトリでは途中で解決したようだが、いまだに複数のorgやrepoで再現し続けている。
https://github.com/orgs/community/discussions/193388
抜けているPRはブランチページを掘ってようやく見つけた
完全なバグというより、インフラ負荷を下げるために製品として非常に悪い選択をしたのかもしれない
ここ数年の新しいrepo/issues/commitsデータを公開したのは、それでも興味深かった。
みんなが外から推測していた通り、エージェントがGitHubに突発的で大きな追加負荷を与えていることを裏づけている。
すでに巨大なユーザーベースを抱えながらもスタートアップのように指数成長しているわけで、標的になりやすいのも当然だし、組織が素早く動くのも簡単ではなさそうだ。
逆に、人材・インフラ・資金はスタートアップよりはるかに多いという点もある
ラベルのないグラフが1つと現在のピーク数値があるだけだ
あのグラフは何をやっているのかさっぱり分からず、ほとんどアーティストの印象画のように見える。
コミットのグラフを見ると、なぜ大きな段差が生じた後に緩やかに下がるのか、なぜその段差が一定の地点で起きないのか、なぜより大きいジャンプのほうが時にはより小さい傾きを持つのか説明がつかない。
他のグラフはまたまったく別の形で動いていて、さらに奇妙だ
実データやデータの意味を示すのではなく、ただ「何かが上がっている」と伝えるためのものだ
federated forgesこそ結局は未来だと思う。
リポジトリはそれぞれ主権的なインフラにホスティングし、グローバルIDとfederated metadataのissue・PRなどを重ねる構造が合っているように見える。
こうしたグローバルインデックスは立ち上げやすいので、可用性が大きな心配事ではなくなるようにできるし、私たちもその方向で作業している
結局サードパーティホスティングを使うなら、また1〜3社の大手事業者が現れる可能性が高い。
そして可用性問題を避けるためにセルフホストしても、依存先がGitHubのような大規模サービスにかかっていれば、そちらの障害はやはり避けられない。
だから現実的な解決策は、今と同じく使うものを全部プロキシするかミラーリングすることだ
GitHub、Codeberg、セルフホストに同じrepoを置き、メインブランチの整合性だけ管理すればいい。
その後はどこからでも更新できるし、READMEにリンクさえきちんと置けばいい
decentなAPIやwebhookさえ提供する別のforgeをつなげて同じ利便性を得られるなら、全部セルフホストにしたい。
エージェント側でもインターフェースを開く必要はあるだろうが、プラグイン構造ならGitHub依存を切り離し、残りはMCPやskillsで処理できる気がする
私は大きなrunnerならセルフホストでも構わないので、最近Codebergへ移行し、小さなcronジョブはCodebergが提供するrunnerを使っている。
そこにはこういう用途向けのlazy runnerまである
今やっていることは、これのように見える。
トークン補助金は十分な学習データを吸い上げ、agentic junkiesビジネスも今やフライホイールを回せるだけの規模になったので打ち切り、損失誘導商品を整理するということらしい。
https://news.ycombinator.com/item?id=47923357