Google Borgと

コンテナベース分散システムデザインパターン

Kamiyacho.k8s #7 LT@ktateish

概要

Google Borgの論文[1]とコンテナベース分散システムデザインパ

ターンの論文[2]を読んだので概要を大雑把に紹介

Google Borg?

● K8s のご先祖であり、Googleで使われている大規模コンテナ

・クラスタ・管理システム[1]● コンピューティング・リソース・マネージャ＆タスク・スケジューラ

と言うほうが正確○ マシンの状態、リソース管理

○ タスクをスケジュール、死活監視

● スケーラブル

● 高可用性

Google Borgの重要な特徴

● タスクに2種類の優先度を割り当てる。(実際はもっと細かく、例外も )

○ Prod: 高レスポンス要求。

○ Non-Prod: レスポンス要求がゆるい。

● 2種類とも同一マシン上で実行される

● Prodは要求リソースを確約(オーバーコミットしない)○ Prodタスクをサブミットする開発者は余計に確保しがち。

○ もったいない → リソース再利用のしくみ

● Non-Prodタスクはその再利用リソースを、つかえるリソースだ

と思ってスケジュールされる(オーバーコミット)

リソースのオーバーコミットによりおこること

● Prodタスクが余分にリソース確保したくなる理由○ バースト的なリクエストに対処したい。

● 実際にそれがおこり、Prod用リソース不足なら Non-Prod タス

クが殺され、別マシンに再スケジュールされる

● つまり、Borg ではいつタスクが殺されるかわからない

○ リソースの話はあくまで一例。Prod(例えばAdサービス用MySQL)であっても週1,2回程度は起こるらしい[3]

● 開発者はプロセスがいつ殺されてもおかしくない、という前提

でアプリを書かなかればならない

Borgは重要な分散コンピューティング基盤である

● Borg自体は分散コンピューティング(※)的な要素が少ない○ Paxosストアくらい？ (k8sではetcdが担当)○ 色々示唆に富む洞察があるので、ぜひ論文[1]を読もう

● ただし、そこに乗るタスクを書くDev, 運用するOpsには分散コ

ンピューティングを強制する

● 結果、Borg上のあらゆるアプリが故障に強くなる。○ 故障に強いアプリでないと、Borg上ではまともに動かない

○ 我々(一般人)の環境はタスクが死ぬ頻度が少ないので、そこに労力を

つぎ込むインセンティブがあまり多くない

※ ここでは「構成要素の一部が故障しても総体としては動作しつづける」くらいの意味です。

知っておきたいBorgの技術的な特徴

● Alloc○ リソースのセットに名前をつけたもの

○ タスクをallocに依存させることで複数の異なるタスクを結びつけること

ができる

○ 結果、複数の異なるタスクが一つの物理マシン上に co-schedule され

る

○ K8sでは Pod という概念として受け継がれている

Borgについては以上

コンテナベース・分散システム・デザインパターン

● K8s創始者によって HotCloud ‘16 で発表された論文[2]● K8sブログでも紹介されたので見た人多いかも

● 今の分散システム開発の状況は，プログラミングにおけるオブ

ジェクト指向の流行からデザインパターンの登場という状況に

似てるぜ，実際コンテナを使ったデザインパターンと呼べるも

のが登場しているぜ，という主張

● 実例が示されてないものもあるけど、たぶんGoogle内にはあ

るのかも・・・？(以下、「実例？」と書いてある)

デザインパターンの分類

おおきく3つの分類がある

● シングルコンテナ・マネジメント・パターン○ コンテナ管理用のお約束

● シングルノード・マルチコンテナ・パターン○ Alloc/Podによるローカルリソース（lo NIC, localディスク) の共有

● マルチノード・アプリケーション・パターン○ 分散アルゴリズムの利用を簡単にする

シングルコンテナ・マネジメント

● コンテナ管理のお約束

● アプリケーション情報API○ 最近の言語ならHTTPサーバ書くの楽なんだから、 “/health” で死活ほ

か、アプリの情報を取れるようにしてね、という話

● ライフサイクル管理API○ Borg/k8s等のタスクを殺すときの作法： SIGKILL する前に SIGTERM

を送り，アプリ側で定義した秒数だけ待つ。

○ これに対応するようにアプリ書こうぜ、という話

■ SIGTERMうけたら重要データを保存する、とか

○ ほかにも readiness probe など

シングルノード・マルチコンテナ

● ローカルリソースの共有によって楽しよう

● サイドカー(ローカルディスクを共有)○ ディスクに書き込むやつとそこから読み取るやつを同居させる

○ 例:■ ログを吐くアプリ＋ログをクラスタストレージに保存するアプリ

■ 静的コンテンツ提供Webサーバ＋リポジトリからコンテンツ取得

○ リソースを融通しやすい(ユーザ対向以外は暇な時に動けば良い)○ 複数チームに分けて開発しやすい

○ 独立してアップデートしやすい

○ アプリコンテナを再利用しやすい

シングルノード・マルチコンテナ(cont.)

● アンバサダー(loインターフェースを共有)○ 他ホストの提供サービスをlocalhostにあるように見せる

○ 例: 127.0.0.1のmemcachedにアクセスしてると思っていたら実は

twemproxyで、memcacheクラスタに投げてくれていた

○ Memcache利用側のアプリは、開発時にlocalhostにmemcacheイン

スタンスをたてておけば、そのままプロダクション環境と同じ設定でい

ける。実例： twemproxy● アダプター(これもlo共有)

○ アンバサダーの逆。共通的なAPIを監視アプリなどに提供

○ 実例？

マルチノード・アプリケーション

● 分散アプリの開発を楽にしよう

● リーダー選出

○ 熟練者でないと、正しく書くのが難しい。言語制約があることも

(Java,Go,...?)○ リーダー選出をやってくれるアプリを一緒にスケジュール

○ 難しいアプリを何度も書かなくて良くなる

○ リーダー選出アプリはHTTPなAPIを提供してくれれば自分のアプリの

言語はなんでも良くなる

○ 実例？

マルチノード・アプリケーション(cont.)

● ワークキュー○ 分散システムでよくある

○ 現状、実装のあるフレームワークの言語にあわせないとダメ

○ ローカルディスクからデータを読みだして、処理結果をローカルディス

クに書き出す、というアプリだけ書けば、あとはフレームワークが全部

やってくれるよ

○ 実例？

マルチノード・アプリケーション(cont.)

● スキャッター/ギャザー○ これも分散システムでよくある

○ ワークロードを分割してマージするようなもの（eg.Web検索）

○ 実際の処理をするリーフノードコンテナと結果をマージするマージコン

テナだけ実装すれば、あとはフレームワークが面倒を見てくれるよ

○ 実例？

所感

● 「我々(一般人)の環境はタスクが死ぬ頻度が少ない」(再掲)○ AWSだと若干死にやすいけど、そこまで頻繁にタスク死なないよね、と

いうのが一般認識かと。オンプレはまず死なない。

○ k8s の世界が来てしまったので、こんなことは言ってられない。あなた

のアプリのプロセスは週1,2回は殺されます

○ コンピューティング・リソース・マネージャの覇権をk8sが握るかどうか

はわからないが、この流れは必定

○ 備えよう

所感

● 備える？どうやって？○ 分散システム的なアーキテクチャに適応しよう。

■ 移行は痛みが伴うだろうけど、きっと楽になる

○ コンテナベース・分散システム・デザインパターン

■ ひとつの道標として

参考文献

[1] Large-scale cluster management at Google with Borg

[2] Design Patterns for Container-based Distributed Systems

[3] Site Reliability Engineering O'Reilly Media p.73 - 75