デプロイ時の循環依存は、障害対応の最中に初めて発覚すると復旧を遅らせます。結論から言うと、GitHubが公開したengineering write-upの要点は、デプロイスクリプトだけをcGroupに入れ、eBPFでDNSや外向き通信を監視・制御することで、危険な依存関係を本番反映前に検出できるというものです。GitHub Blogは2026年4月16日、GitHubがeBPFを使ってdeployment toolingの安全性を高め、循環依存を検出・防止している事例を紹介しました。(The GitHub Blog)
この話は、単なる「eBPFすごい」という技術紹介ではありません。Infrastructure engineersやSRE teamsにとって重要なのは、デプロイの成功条件を「コードが正しいか」だけでなく、障害時にも必要な外部・内部依存なしで実行できるかまで広げてチェックする点です。特に、GitHub Actions、社内デプロイ基盤、ホストベースのdeployment tooling、Kubernetes周辺の運用を持つチームでは、同じ考え方をリリース前検証や安全装置に応用できます。
GitHub deployment tooling / eBPFで注目すべきポイント
GitHubの事例で扱われている問題は、「GitHubをデプロイするためにGitHubへアクセスする必要がある」という循環依存です。GitHubは自社のソースコードをgithub.com上でホストしているため、github.comが停止した場合、自社サービスの修正デプロイにも影響が出る可能性があります。これに対してGitHubは、修正用コードのミラーやロールバック用のビルド済みアセットを維持していると説明しています。(The GitHub Blog)
しかし、問題はそれだけではありません。デプロイスクリプトが内部サービスを呼ぶ、ツールが自動更新チェックを行う、バイナリをGitHub Releasesから取得する、といった動きが入ると、見えにくい循環依存が生まれます。GitHubは新しいホストベースのデプロイシステムを設計する中で、eBPFを使えばこうした呼び出しを選択的に監視・ブロックできると判断しました。(The GitHub Blog)
ここで重要なのは、GitHubが「本番ホスト全体の通信を止めた」のではない点です。ステートフルなホストはローリングデプロイや再起動中でも顧客トラフィックを処理するため、単純にgithub.comへのアクセスを全面遮断すると、検証どころか本番影響を出しかねません。GitHubは、デプロイスクリプトだけを対象にした条件付きのネットワーク制御を目指しました。(The GitHub Blog)
循環依存とは何か：SREが本番前に潰すべき3パターン
デプロイ安全性の文脈での循環依存とは、障害を直すためのデプロイが、障害中に使えないサービスへ依存してしまう状態です。通常時は問題なく動くため、レビューやCIでは見落とされやすいのが厄介です。
GitHubの記事では、MySQL障害を例に、デプロイスクリプトが問題解決のために走る場面を想定しています。その際にGitHubは、循環依存を「直接依存」「隠れた依存」「推移的依存」のように整理しています。(The GitHub Blog)
| 依存の種類 | 何が起きるか | 実務での典型例 | リスク |
|---|---|---|---|
| 直接依存 | デプロイスクリプト自身が障害中のサービスへアクセスする | GitHub Releasesから最新バイナリを取得する、社内Artifact Registryへ取りに行く | 取得失敗でデプロイが停止する |
| 隠れた依存 | スクリプトが呼ぶツール内部で外部通信が発生する | CLIツールの自動更新確認、ライセンス確認、プラグイン取得 | レビューでは見つかりにくく、タイムアウトで復旧が遅れる |
| 推移的依存 | 呼び出した内部サービスがさらに別サービスへ依存する | migration serviceが外部リリースを取得する、社内APIがGitHub APIへアクセスする | 障害の原因とデプロイ失敗の関係が追いにくい |
この分類は、GitHub以外の組織にもそのまま使えます。たとえば、社内のCI/CD基盤がGitHub Enterprise、GitLab、Artifactory、S3、Vault、npm registry、container registryのいずれかに依存している場合、そのサービスが使えない状況でも「復旧用デプロイ」は成立する必要があります。
なぜ静的レビューだけでは不十分なのか
循環依存チェックは、まずコードレビューや依存関係リストで始めるべきです。ただし、それだけでは限界があります。
理由は大きく3つあります。
第一に、デプロイスクリプトはシェル、Go、Python、Ruby、社内CLI、systemd unitなど複数の層をまたぎます。スクリプト本体にはcurl github.comがなくても、呼び出したバイナリがDNS解決や更新確認を行うことがあります。
第二に、依存先は時間とともに変わります。今日問題のないCLIが、明日のバージョンで新しい外部エンドポイントへアクセスする可能性があります。GitHubの記事でも、既存のバイナリツールが新しい依存を取った場合にも検出できるようにしている点が示されています。(The GitHub Blog)
第三に、障害対応時に必要なのは「設計上依存していないはず」ではなく、「実行時に本当に依存していない」という確認です。Infrastructure engineersやSRE teamsが欲しいのは、理想的な依存関係図ではなく、デプロイ中に実際に発生した通信の証跡です。
eBPFベースのチェックが効く理由
eBPFは、Linuxカーネル内のイベントにプログラムをフックし、ネットワークやプロセスの挙動を低レイヤーで観測・制御できます。GitHubの事例では、特定のcGroupに入れたデプロイスクリプトの外向き通信を対象に、BPF_PROG_TYPE_CGROUP_SKBを使ってネットワークegressを扱っています。(The GitHub Blog)
ポイントは、対象を「ホスト全体」ではなく「デプロイスクリプトのプロセス群」に絞れることです。これにより、本番ワークロードの通常通信を壊さずに、デプロイ処理だけを検査対象にできます。
GitHubのアプローチを簡略化するとこうなる
GitHubのengineering write-upを実務向けに読み替えると、構成は次のようになります。
| レイヤー | 役割 | 何を検出できるか |
|---|---|---|
| cGroup | デプロイスクリプトと子プロセスを隔離する | 「どの処理をチェック対象にするか」を限定する |
eBPF CGROUP_SKB | 外向き通信を監視・制御する | ブロック対象ドメインへの通信、想定外のegress |
eBPF CGROUP_SOCK_ADDR | ソケット作成や接続先を書き換える | DNS問い合わせをローカルのDNSプロキシへ転送する |
| DNSプロキシ | ドメイン単位で許可・拒否を判定する | IPアドレスではなくドメイン名ベースで依存先を扱う |
| eBPF Maps | カーネル側とユーザー空間で情報を共有する | DNS transaction IDとPIDの対応付けなど |
| ログ・監査出力 | 所有チームに原因を返す | どのコマンドがどのドメインへアクセスしたか |
GitHubは、CGROUP_SKBだけではIPアドレス単位の制御になり、GitHub規模ではブロック対象IPリストの維持が難しいと説明しています。そこでDNS問い合わせをユーザー空間のDNSプロキシへ転送し、問い合わせドメインをブロックリストと照合する方式を組み合わせています。(The GitHub Blog)
この判断は実務的です。クラウド環境やSaaSのIPレンジは変化しやすく、CDNも絡みます。SREが本当に管理したいのは多くの場合、IPではなく「github.comへ依存していないか」「社内のcontrol planeへ依存していないか」「復旧対象そのものへ依存していないか」です。
危険なデプロイがlandする前にどう止めるか
eBPF-based checksをdeployment toolingへ組み込む目的は、単に通信をブロックすることではありません。重要なのは、リスクのある変更を本番リリース前に発見し、所有チームへ修正可能な形で返すことです。
たとえば、次のような流れにすると、GitHubの考え方を自社のCI/CDやリリースプロセスに落とし込めます。
| フェーズ | 実施内容 | 判定の例 |
|---|---|---|
| 開発・レビュー | デプロイスクリプトの依存先を明示する | github.com、社内API、registry、Vaultなどを一覧化 |
| CI | テスト環境でデプロイスクリプトをeBPF監視下で実行する | 禁止ドメインへのDNS問い合わせがあればfail |
| Staging | 本番相当のcGroup・DNSプロキシ構成でdry-runする | 直接依存・隠れた依存・推移的依存をログ化 |
| 本番前ゲート | 監査ログをdeployment approvalに紐づける | 未承認の外部通信があれば承認不可 |
| 本番デプロイ | ブロックまたは警告モードで実行する | 重大依存はblock、移行期間はwarn |
| 事後改善 | 検出結果をサービス所有チームへ返す | 依存をvendoring、ミラー、事前配置へ変更 |
特に有効なのは、最初からブロックモードにしないことです。既存システムでは、思わぬ依存が大量に出る可能性があります。まずは監査モードで通信ログを取り、復旧に影響する依存から優先順位を付けて潰す方が現実的です。
実装時に設計すべきポリシー
eBPFによるデプロイ安全性チェックは強力ですが、「何を禁止するか」が曖昧だと運用に乗りません。技術実装より先に、SREとPlatform Engineeringでポリシーを決める必要があります。
ブロック対象は「障害時に使えない可能性があるもの」から始める
禁止リストを広げすぎると、通常のデプロイが止まりすぎます。最初は、障害時の復旧を妨げる依存に絞るのが現実的です。
| 対象 | ブロック候補になる理由 | 代替策 |
|---|---|---|
| 自社サービス本体 | 復旧対象そのものに依存すると修正できない | ミラー、ローカルアセット、break-glass経路 |
| 外部Gitホスティング | 障害時やネットワーク分断時に取得できない | 事前ビルド、内部ミラー、vendor化 |
| Package registry | npm、PyPI、Go module proxyなどの取得失敗で停止する | lockfileだけでなくアーティファクトも固定 |
| Container registry | ノード上にイメージがないと起動できない | 事前pull、内部registry、復旧用イメージの固定 |
| 社内control plane | control plane障害時にデプロイが詰まる | データプレーン側で完結する復旧手順 |
逆に、すべての外部通信を悪とみなす必要はありません。監視通知、メトリクス送信、監査ログ転送などは、ブロックではなく許可・遅延送信・ベストエフォート化を選ぶ方がよい場合もあります。
「検出したら誰が直すか」まで決める
GitHubの事例で実用的なのは、ブロックされたDNS requestを特定のコマンドやプロセスへ紐づけ、所有チームが修正しやすい形で示している点です。GitHubはDNS transaction IDとPIDをeBPF Mapで対応付け、/proc/{PID}/cmdlineからコマンドラインを取得できると説明しています。(The GitHub Blog)
SREチームが欲しいログは、単なる「blocked=true」ではありません。次の情報があると修正が進みます。
deployment_id=deploy-20260417-001
service=mysql
stage=preprod
blocked_domain=github.com
pid=266767
command="curl github.com"
owner=database-platform
policy=circular-dependency-blocklist
action=blockedこの粒度で出せれば、レビューコメントやPull Requestのチェック結果にも載せられます。
「どのファイルを直すべきか」「どのチームに連絡すべきか」が明確になり、SREだけが調査を抱え込む状態を避けられます。
導入で失敗しやすいポイント
eBPFを使ったdeployment safetyは魅力的ですが、導入時には落とし穴があります。特にシニアインフラ層が検討する場合、次の点を先に潰しておくべきです。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| いきなり本番ブロックする | 既存デプロイが止まり、開発チームの反発を招く | まず監査モードで依存先を可視化する |
| IPリストだけで管理する | CDNやクラウドの変更に追従できない | DNSベースのポリシーを併用する |
| ログにコマンド情報がない | どの処理が依存を作ったか分からない | PID、cmdline、deployment IDを紐づける |
| 例外申請がない | 緊急対応時に安全装置を迂回する運用になる | 期限付きallowlistと承認ログを用意する |
| 所有者情報がない | SREが全修正を背負う | service catalogやCODEOWNERSと連携する |
| CIだけで満足する | 本番ホスト固有の依存を見逃す | stagingやcanaryでも同じチェックを行う |
特に避けたいのは、「eBPFでブロックできるから安全」と考えることです。ブロックは最後の防波堤です。理想は、ブロックに到達する前に、CIやstagingで危険な依存を発見して修正することです。
GitHub以外のチームで使える実践ステップ
自社で同じ考え方を取り入れるなら、最初からGitHub規模の仕組みを作る必要はありません。小さく始めるなら、次の順序が現実的です。
まず復旧に必要なデプロイ経路を1つ選ぶ
最初の対象は、全サービスではなく「障害時に絶対に動いてほしいデプロイ」です。
たとえば、次のようなものです。
- データベース設定変更用スクリプト
- feature flagや緊急停止設定の反映
- ロールバック用のホストベースデプロイ
- Kubernetesクラスタ障害時のnode-level修復手順
- 認証基盤やCI/CD基盤そのものの復旧手順
この1つに絞って、実行時のDNS問い合わせと外向き通信を記録します。
次に依存先を分類する
記録した通信を、単純なドメイン一覧で終わらせず、復旧リスクで分類します。
| 分類 | 判断基準 | 例 |
|---|---|---|
| 必須依存 | デプロイ成功に必要で、代替がない | internal artifact store |
| 置き換え可能 | 事前配置やミラーで回避できる | GitHub Releases、package registry |
| 不要依存 | 自動更新確認など、復旧時には不要 | CLI update check |
| 監査対象 | 許可するがログを残す | logging endpoint、metrics endpoint |
| 禁止依存 | 障害時に復旧を妨げる | 復旧対象サービス本体 |
この分類を行うと、eBPFによる検出結果が単なるネットワークログではなく、リリース判断に使える安全性シグナルになります。
最後にdeployment gateへ組み込む
検出結果は、GitHub Actionsや社内CI、deployment approval、change managementのどこかに接続します。
実務では、次のような判定が分かりやすいです。
PASS: 許可済みドメインのみ
WARN: 未分類ドメインあり。ただし本番反映は可能
FAIL: 禁止ドメイン、復旧対象サービス、外部registryへの依存あり最初はWARNを多めにして、依存の棚卸しを進めます。ポリシーが固まったら、復旧手順に関わるデプロイからFAILへ移行します。
Senior infra audiencesに刺さる理由
このGitHubのengineering write-upがInfrastructure engineersやSRE teamsに響く理由は、技術の新しさだけではありません。デプロイ安全性を、抽象的なベストプラクティスではなく、実行時の依存関係を低レイヤーで観測し、危険な変更を早期に止める仕組みとして示しているからです。
特にグローバルな大規模サービスでは、次の課題が共通しています。
- サービス数が多く、依存関係図がすぐ古くなる
- デプロイツールが社内外のSaaSやregistryに依存しがち
- インシデント中はcontrol planeやGitホスティングへアクセスできるとは限らない
- チームごとにスクリプトやツールチェーンが異なる
- 復旧時間を短くするには、障害時に初めて依存を発見していては遅い
eBPFは、この問題に対して「実際に何が起きたか」をプロセス単位で見る手段を提供します。さらにcGroupと組み合わせることで、顧客トラフィックを処理しているホスト全体ではなく、デプロイ処理だけを狙って検証できます。これは、production safetyとdeveloper velocityを両立させるうえで大きな意味があります。
すぐ始めるためのチェックリスト
自社のdeployment toolingにこの考え方を取り入れるなら、次のチェックから始めると効果的です。
- 復旧時に必要なデプロイスクリプトを3つ以内に絞る
- それぞれのスクリプトがアクセスするドメインと内部APIを記録する
- GitHub、package registry、container registry、社内control planeへの依存を分ける
- 自動更新確認や最新バイナリ取得を無効化できるか確認する
- 復旧用アーティファクトを事前配置またはミラー化する
- CIやstagingで、禁止ドメインへの通信を警告として出す
- ログにはdeployment ID、service、PID、command、domainを含める
- 期限付きallowlistと承認フローを用意する
- 最後に、復旧手順書へ「依存なしで実行できること」を明記する
最初のゴールは、完璧なeBPF基盤を作ることではありません。障害時に必要なデプロイが、障害中に使えないものへ依存していないと確認できる状態を作ることです。
まとめ：eBPFはデプロイ前の「実行時依存チェック」に使える
GitHubの事例が示しているのは、eBPFを使えば、デプロイスクリプトの外向き通信をプロセス単位で監視し、DNSベースで循環依存を検出し、危険な依存を本番反映前にチームへ返せるということです。GitHubはこの仕組みにより、デプロイスクリプトから循環依存を起こしうるドメインを条件付きでブロックし、どのコマンドが問題を起こしたかを所有チームへ示し、デプロイ中にアクセスされたドメインの監査リストも得られると説明しています。(The GitHub Blog)
SRE teamsが次に取るべき行動は、eBPFの実装から始めることではありません。まずは、障害時に必要なデプロイ経路を1つ選び、実行時の依存先を可視化してください。そのうえで、GitHub deployment tooling / eBPFの考え方を参考に、監査モード、警告モード、ブロックモードの順に安全装置を育てていくのが現実的です。
危険なデプロイは、landしてから止めるより、landする前に見つける方が安く済みます。eBPF-based checksは、そのための強力な選択肢です。
コメント