はじめに
こんにちは。inductorです。
今日のエントリーはタイトルの通りです。
BorgはGoogleが持つアプリケーション実行基盤で、Google CloudにおいてはGKEのマスターノードやGoogle App Engineなどが実際に動くインフラとしても使われています。
また、話題のKubernetesの元になったGoogle Insideなプロジェクトとしても有名かとおもいます。
ツイッターで誰かが「Borgの論文を誰か日本語で解説してほしい」と言っていたのを見かけたのを見かけたので、論文を読んで実際に中身を紐解いてみたいなと思いました。
元論文はこちらです
何を書くのか
自分は実はBorgの論文をきちんと読み込んだことはないため、時間を掛けて何回かに分けてやってみようと思っています。
実は、Borgの解説自体は他の方々もやっているようで、僕が改めてやる意味はあるんだろうか、なんて思ったりもしたのですが、まあ実際のところいろいろな視点での解説があったほうがわかりやすいかもなと思ったのと、そもそも僕は論文なるものをちゃんと読んだことがほとんどないので、これを機にやってみようかな、なんて思ったのでした。
めっちゃ時間かかりそうなので、とりあえずAbstractだけ訳したものと、それに対する僕の見解を置いておきます。
---以下、本文---
Abstract
GoogleのBorgシステムはクラスターマネージャーで、何万ものジョブを、何千ものアプリケーションから、何万ものマシンを持つ多数のクラスタにまたがって実行します。
Borgでは、アドミッション制御、効率的なタスクパッキング、オーバーコミット、そしてプロセスレベルのパフォーマンス分離を用いたマシンの共有を組み合わせることによって高利用率を達成しています。また、障害回復時間を最小限に抑えるランタイム機能と、相関障害の可能性を減らすスケジューリング・ポリシーを備えた高可用性アプリケーションをサポートします。
Borgは、宣言型のジョブ指定言語、ネームサービスの統合、リアルタイムのジョブ監視、さらにシステムの動作を分析しシミュレートするツールを提供することで、ユーザーの"生活"を簡素化します。
ここでは、Borgのシステムアーキテクチャと機能の概要、重要な設計上の決定、そのポリシー決定のいくつかの定量的分析、および10年間の運用経験から学んだ教訓の定性的検討を示します。
解説
GoogleのBorgシステムはクラスターマネージャーで、何万ものジョブを、何千ものアプリケーションから、何万ものマシンを持つ多数のクラスタにまたがって実行します。
複数のマシンを組み合わせて、それを「1つの大きな基盤」として提供するという手法は、いわゆる分散システムやHCI(Hyper-Converged Infrastructure)にも代表されるような概念です。
決まった場所に決まった方法でデプロイするような制約を定めてしまえば、アプリケーション開発者がインフラの難しい部分を意識すること無く開発に集中できるようになるという意味ではとても合理的な概念であると考えています。
Borgでは、アドミッション制御、効率的なタスクパッキング、オーバーコミット、そしてプロセスレベルのパフォーマンス分離を用いたマシンの共有を組み合わせることによって高利用率を達成しています。
- アドミッション制御
- 主にネットワーク機器などの文脈で使われることが多い用語ですが、かんたんに言うと「そのリクエストを許可するか」を決定するための制御です。アプリケーションを実行する際に、セキュリティ的にその挙動を許可するかや、リソース的に実行可能なのかなどを判断するために使われます。
- タスクパッキング
- 論文をまだ読んでないので間違ってるかもしれませんが、コンテナを使ったインターフェースの統一やパッキングのことを言っているのかな?と思いました。
- オーバーコミット
- インフラのVirtualizationなどでよく使われる制御で、あるアプリケーションを特定のマシンに割り当てる際に、実際そのマシンが持つよりも大きなリソースを割り当てるようなもののことを言います。アイドル時の無駄なリソース消費を少なくすることが出来るなどの効果があります。
- プロセスレベルのパフォーマンス分離を用いたマシンの共有
- 表現自体がわりと曖昧ですが、コンテナを使うことで同一マシン上で複数のアプリケーションをプロセスとして分離することが可能なので、そういう話だと思います。
また、障害回復時間を最小限に抑えるランタイム機能と、相関障害の可能性を減らすスケジューリング・ポリシーを備えた高可用性アプリケーションをサポートします。
- 障害回復時間を最小限に抑えるランタイム機能
- これも論文ちゃんと読んでないのでまだ想像ですが、「正常」と「異常」を明確に定義しておくことで、正常な状態を保つように自律制御することを指しているのかなと思いました。これによって人の手を介すこと無くアプリケーションの復旧が行なえます。
- 相関障害の可能性を減らすスケジューリング・ポリシー
なにもわからない。論文を読むしかなさそう。- ノイジーネイバー問題や負荷の高いタスクや継続して動かすための優先度の高いタスクをどうやっていいかんじに上手いこと管理するかみたいな話かな(多分)
Borgは、宣言型のジョブ指定言語、ネームサービスの統合、リアルタイムのジョブ監視、さらにシステムの動作を分析しシミュレートするツールを提供することで、ユーザーの"生活"を簡素化します。
- 宣言型のジョブ指定言語
- 従来のインフラ管理ではAPIを用いた命令的な構成管理が一般的でした。BorgではKubernetesでも用いられているような「あるべき姿を宣言する」ことによって、自律制御を可能にしている、みたいな話だと思います。
- ネームサービスの統合
なにもわからない。論文を読むしかなさそう。- 内部DNSを使ってサービスディスカバリする話っぽい
- リアルタイムのジョブ監視
- 状態監視は自律制御では言うまでもなく重要です。
- システムの動作を分析しシミュレートするツール
- ほう!!!!なんのことだろう?
- ユーザーの"生活"を簡素化します
- これはアプリケーション開発者にとっての日々の開発ライフの話だと思いました(多分)
続きはまたやっていきます。今日は素振り!
つづきはこちら