GitHubがeBPFで循環依存を検出しデプロイの安全性を向上

循環依存の課題

GitHub自体がGitHub上でホスト
デプロイ時に自社サービスへ依存
障害時の復旧スクリプトも影響
直接・隠れ・推移的の3種類を分類

eBPFによる解決策

cGroup単位でネットワーク制御
DNS proxyでドメイン単位のブロック
プロセスIDから原因コマンドを特定

導入成果

6か月の展開で本番稼働開始
詳細を読む

GitHubは2026年4月16日、自社のデプロイツールにおける循環依存の検出と防止にeBPFを活用する手法をエンジニアリングブログで公開しました。GitHubは自社のソースコードをgithub.com上にホストしており、サービス障害時にデプロイに必要なコードにアクセスできなくなるという根本的な循環依存の問題を抱えています。

循環依存には3つのパターンがあります。デプロイスクリプトが直接GitHubからツールを取得する「直接依存」、既存ツールが起動時にGitHubへ更新確認を行う「隠れた依存」、そして別の内部サービスを経由してGitHubに到達する「推移的依存」です。従来はチームごとに手動でスクリプトを確認していましたが、多くの依存関係は障害発生時まで発見されませんでした。

解決策として採用されたのがeBPFBPF_PROG_TYPE_CGROUP_SKBプログラムタイプです。Linuxのcroupにデプロイスクリプトのみを配置し、そのプロセスからの外部ネットワークアクセスを選択的に監視・ブロックします。IP アドレスベースのブロックリスト管理が困難なため、BPF_PROG_TYPE_CGROUP_SOCK_ADDRを使ってDNSクエリをユーザ空間のDNS proxyにリダイレクトし、ドメイン単位でのフィルタリングを実現しました。

さらに、ブロックされたDNSリクエストのトランザクションIDとプロセスIDをeBPF Mapで紐付けることで、どのコマンドが問題のあるリクエストを発生させたかを特定できるようにしました。/proc/{PID}/cmdlineを読み取り、完全なコマンドライン情報をログに出力します。

このシステムは6か月間の展開を経て本番環境で稼働を開始しています。チームが誤って問題のある依存を追加した場合や、既存ツールが新たな依存を取った場合に自動で検出・通知されるようになりました。障害時の平均復旧時間の短縮と、GitHubサービス全体の安定性向上に貢献しています。