サービスメッシュの死角が引き金に #
8月17日深夜(日本時間22時28分)から翌朝6時15分まで、約7時間47分にわたりGitHubで大規模障害が発生した。ピーク時にはウェブ機能で約20%、リポジトリのダウンロードで約50%がエラーになったという。
原因はGitHub.com本体ではなく、サービス間通信を仲介する「Istio」のサイドカーだった。米中部データセンターで同時接続数が上限に達したが、オートスケーラーは本体サービスの負荷しか監視しておらず、サイドカーの限界を検知できなかった。容量不足は通信振り分け役のHAProxy 4台にも波及し、内部認証経路に遅延とエラーが発生。Issues・Pull Requests・Actions・Copilotなど、認証に依存するほぼ全機能が連鎖的に止まった。
1. トラフィック急増
月間コミット数が4カ月で14億→29億件に倍増。
2. サイドカーが上限到達
Istioの同時処理数が限界に達する。
3. 自動拡張が検知できず
監視対象が本体側のみでサイドカーが盲点に。
4. HAProxy逼迫・認証遅延
内部認証経路にエラーと遅延が波及。
5. 主要機能が連鎖停止
Issues・Actions・Copilot等が軒並み停止。
「善意の再試行」が自己DDoSに化けた #
復旧を遅らせたのはクライアント側の再試行だった。VS Code上のCopilotが認証失敗時に大量リクエストを再送する挙動を持っており、認証トークン処理へのアクセスは平常時の毎秒7,000〜9,000件から一気に7万〜10万件へ急増した。これは攻撃者が意図的に仕掛ける再送増幅型DoSと構造がほぼ同じで、正規クライアントの善意の再試行が結果的に自己DDoSとして牙を剥いた形だ。
セキュリティの視点で見逃せないのは、GitHubが世界中のCI/CDパイプラインとソフトウェアサプライチェーンの単一障害点になっている点。今回は攻撃ではなく成長痛が原因だったが、同じ経路は攻撃者にとっても魅力的な標的になり得る。GitHubは再試行回数の上限設定、監視粒度の細分化、Azure移行加速などの対策を進めるという。
COMMENTS 0
まだコメントはありません。最初のコメントを投稿しよう。