# Borg [[Google]] が社内で開発・運用する大規模クラスタ管理システム。数万台規模のマシンとコンテナ化されたジョブを管理し、ジョブのスケジューリング・プリエンプション・リソース割り当てを統括する。Kubernetes の設計に多大な影響を与えた（Borg が Kubernetes の前身）。 [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]] では、Google TPU フリートのスケジューリング層として Borg が機能し、ML Productivity Goodput の Scheduling Goodput（SG）成分の算出基盤となっている。SG はジョブが「同時実行中（simultaneously running）」にある時間の割合として定義され、部分的割り当て・プリエンプション・ダウンタイムを分母の capacity から明示的に分離する設計を取る。 [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]]では、Borg が [[TPUv4]] スーパーコンピュータのクラスタスケジューラとして、ユーザージョブの3Dトポロジ要求を受けてキューブ候補集合を選定し、Pod Manager へ xconnect リクエストを発行する役割を担う。Borg Prime(複数レプリカが構成する論理的な単一インスタンス)は、healthd・Pod Manager・Repair Automation System から集約される障害通知に基づき、影響を受けた TPU マシンを利用不可とマークして実行中ジョブを退避・再スケジューリングし、優先度スケジューリングとプリエンプションで断片化解消(defragmentation)を行う。 [[@2016__OReilly__SRE Book - Chapter 2 The Production Environment at Google, from the Viewpoint of an SRE]] では、Borg の全体像が SRE の視点から用語として導入される。ジョブは 1 つ以上の同一タスクからなり、Borg はジョブ開始時に各タスクへ Borg Naming Service(BNS)経由の名前(`/bns/<cluster>/<user>/<job name>/<task number>`)を割り当て、IP アドレスとポート番号への解決を仲介する。ビンパッキングの際は CPU・メモリなどの要求リソースに加えてラックのような障害ドメインを考慮し、単一の top-of-rack スイッチが単一障害点になるような配置(同一ジョブの全タスクを同一ラックに置くこと)を避ける。タスクが要求以上のリソースを使用した場合は強制終了・再起動され、再起動を繰り返す(crashloop する)方が二度と再起動されないよりも望ましいという設計判断がとられている。 [[@2016__OReilly__SRE Book - Chapter 8 Release Engineering]] では、自動リリースシステム [[Rapid]] のワークフローが本番サーバー上の Borg ジョブとしてタスクにディスパッチされる基盤として Borg が登場する。この設計により Rapid は本番インフラを再利用して数千件のリリース要求を同時に処理できる。単純なデプロイでは Rapid が Borg ジョブを新しい Midas Package Manager(MPM)パッケージへ直接更新し、より複雑なロールアウトは Sisyphus フレームワークに委譲される。