記事

GitHub、eBPFでデプロイの循環依存を検出——cGroup単位でDNSを書き換える新しい安全装置

GitHubはeBPFを使ってデプロイスクリプトの循環依存を検出・防止する仕組みを公開しました。BPF_PROG_TYPE_CGROUP_SOCK_ADDRでDNSクエリをローカルプロキシに転送し、プロセス単位でgithub.com依存を可視化します。

GitHubを守るためにGitHubを使えない問題

GitHubは2026年4月16日、公式ブログでデプロイ時の循環依存を検出する新しい仕組みを公開しました。GitHubは自社のソースコードや配布物をgithub.com自身にホストしているため、プラットフォームが障害でダウンすると、復旧に必要なコードを取りに行けないという構造的なリスクを抱えています。

この「GitHubを直そうとしてGitHubに依存する」という依存関係は、インシデントの復旧時間を不必要に延ばしてしまいます。Lawrence GripperとAleksey Levensteinのエンジニアリングチームは、デプロイスクリプトからgithub.comへの問題のある依存を自動で検知・可視化するために、Linuxカーネルの拡張機構であるeBPFを採用しました。

GitHubのインフラ基盤を象徴する抽象画像

画像引用元: GitHub Blog

3種類の循環依存を洗い出す

GitHubは問題のある依存を3つに分類しています。1つ目は「直接依存」で、デプロイスクリプトがgithub.comのリリースからオープンソースツールを取得するようなケースです。MySQLの設定スクリプトでツールをcurlしてくるような例が挙げられており、GitHub障害時にはスクリプト自身が動かなくなります。

2つ目は「隠れた依存」で、すでにホストに入っているツールが実行中に内部的なチェックで更新版を確認しに行くパターンです。当事者ですら自覚していない通信が含まれるため、障害時に突然タイムアウトで止まるという厄介な挙動を起こします。

3つ目は「間接依存」で、デプロイスクリプトが社内サービスを呼び、そのサービスが裏でgithub.comにアクセスするようなケースです。失敗はスクリプト側に返ってくるため、表層だけを見ても原因の切り分けが難しくなります。

cGroupとeBPFでプロセス単位のネットワーク制御

github.comへの通信を丸ごと遮断すればステートフルなプロダクション通信まで巻き込んでしまうため、チームは「デプロイスクリプトだけ」を対象にする仕組みを必要としました。解決策として採られたのが、Linux cGroupとeBPFを組み合わせたプロセス単位のネットワークフィルタリングです。

使われているeBPFプログラム種別は2つです。BPF_PROG_TYPE_CGROUP_SKBはcGroupからのネットワーク送出にフックして、パケットレベルの選別を行います。もう一方のBPF_PROG_TYPE_CGROUP_SOCK_ADDRはソケット生成のsyscallに介入し、DNS（ポート53）を狙うconnect4コールをlocalhost:53に書き換えて、ユーザースペースのDNSプロキシにトラフィックを集約します。プロキシ側ではブロックリストと照合し、problematic なドメインへの問い合わせだけを弾く設計になっています。

実装は`cilium/ebpf`で組み立てる

実装には、Goだけでメモリ安全にeBPFを書けるcilium/ebpfライブラリが使われています。デプロイスクリプトを専用のcGroupに配置し、そこへeBPFプログラムをアタッチしてDNSクエリをローカルプロキシへ転送、さらにeBPFマップを介してカーネルとユーザースペースで情報をやり取りする、という流れです。

ブロックしたリクエストは、DNSのトランザクションIDやパケットヘッダから取れるプロセスIDを手がかりに/proc/{PID}/cmdlineと突き合わせることで、「どのコマンドがどのドメインを叩こうとしたのか」まで特定できます。cGroupの標準機能として、プロセス単位のCPU・メモリ制限も同時にかけられるため、暴走したスクリプトがホストのリソースを食い潰すのを防ぐ副次的な効果もあります。

6カ月の段階導入を経て本番稼働

チームはこの仕組みを約6カ月かけて段階展開し、現在は本番で稼働しています。問題のある依存を誰かが新しく持ち込んでも、ツーリングがそれを検知して該当チームに通知する運用が回り始めており、インシデント発生時の平均復旧時間の短縮につながっていると報告されています。

eBPFに踏み込みたい開発者向けには、cilium/ebpfのexamplesリポジトリやdocs.ebpf.ioが入り口として案内されています。自分でプログラムを書くほどではない場合も、bpftraceやptcpdumpといったeBPF活用ツールで同等のオブザーバビリティを得られると紹介されており、プラットフォームチーム以外にも応用しやすい構成になっています。