Kubernetesの未来はFacebookの先例に従うだろう

[編集者注]現在、Kubernetes は最大で約 5,000 個のノードを管理しています。これは、Borg や Tupperware のスケーラビリティからは程遠いだけでなく、認識せずに異なるエリアのノードをスケジュールすることもできません。この記事では、Tupperware と Delos の背後にあるアイデアと取り組みの一部を紹介します。これらの取り組みにより、Facebook はデータ センターや地域に関係なく、いつでもどこでもグローバル リソースを使用できるようになりました。

Kubernetes コンテナ管理システムの将来がどうなるのか疑問に思っているなら、Facebook が 2011 年以来 (Docker コンテナ、さらには Kubernetes 以前) 使用し、進化させてきたクローズド ソースの自社開発 Tupperware コンテナ制御システムが、良いインスピレーションの源になるかもしれません。

Kubernetes は 5 年前に Google によってオープンソース化されました。 Google 社内の Borg および Omega クラスタとコンテナ制御システムが Kubernetes に多大なインスピレーションを与えなかったわけではありません。実際、Google は Borg のコードを単に取得してクリーンアップし、GitHub にダンプするのではなく、Go プログラミング言語 (これも Google が作成したもの) を使用して Kubernetes をゼロから作成し、その周りにコミュニティを構築して大成功を収めました。現時点では、アプリケーション構築のための次世代コンテナ オーケストレーション プラットフォームとして Kubernetes を選択したからといって、解雇される人はいないはずです。

しかし、それは、Facebook のような他のハイパースケーラーが大きな問題に遭遇し、Kubernetes が対処や解決に苦労していない方法でそれを解決したことがないということを意味するものではありません。たとえ Google が Borg と Omega で社内的に同様の問題に直面していたとしてもです。残念ながら、Facebook は、先週末に開催された Facebook の Systems Scale イベントで説明された Tupperware コンテナ クラスターとコントローラー、または現在の Tupperware コントロール プレーンの基盤となる新しい Delos ストレージ サービスのオープン ソース バージョンを作成する予定はありません。

Tupperware システムは Facebook のアプリケーションとデータ サービスを実行するために非常に正確に構築されたため、企業内で実行されているさまざまなサービスを統合してサポートするためのコントローラーの一般バージョンを作成することは困難でした。 Google の Borg と Omega についても同様で、Borg と Omega のコア部分を書き直して汎用のクラスタおよびコンテナ コントローラにするのにかなりの労力がかかりました。正直に言うと、Kubernetes プラットフォームは 5 年間で大きな進歩を遂げてきたにもかかわらず、まだ完成していません。

簡単に言うと、Facebook のエンジニアリング マネージャーで、Tupperware の取り組みを監督し、以前は IBM の T.J. でクラウド自動化の研究を率いていた Chunqiang Tang 氏です。 Watson Research CenterのCEOはThe Next Platformに対し、FacebookはGoogleが将来行うかもしれないように、Tupperwareから学んだことをKubernetesに応用する計画はないと語った。 (Borg/Omega ベアメタルではなく、Google Cloud Platform 上の Kubernetes 上で実行されている Google サービスはすでに多数あります。)

Facebook は、Tupperware で使用されている低遅延でプラグ可能な API データ ストアである Delos を現在公開する予定はないが、Delos プロジェクトで Facebook と協力したミシガン大学のコンピューター サイエンスおよびエンジニアリングの教授である Jason Flinn 氏は、このプロジェクトは 1 年前に開始されたばかりで、実稼働で使用されてからまだ 4 か月ほどしか経っていないため、長期的には可能性があるとしても、公開するには時期尚早であると示唆した。

重要なのは、Systems Scale カンファレンスで Tupperware と Delos について明らかにされた情報が、オープンソースとクローズドソースの両方における他のクラスターおよびコンテナー管理とストレージ サブシステムの作業に情報を提供し、刺激を与えるために使用できるということです。結局のところ、2005 年の Google の MapReduce 論文が、Yahoo による Hadoop の作成に直接つながったのです。

私たちは、両方のコードセットの技術的な詳細と同じくらい、大規模なインフラストラクチャの実行に関して Facebook が提供する洞察にも興味を持っています。コードは 1 人の人にしか適用されないかもしれませんが、これらの洞察は多くの人に適用されます。

規模の点では、Tang 氏は Kubernetes を Borg/Omega と比較することはできないし、ましてや Tupperware と比較することはできないと明らかにしました。 Kubernetes は、最初にリリースされたとき、数百台のサーバーで実行するのに苦労しましたが、1 年後には 1,000 ノードを突破しました。 Tang 氏によると、Kubernetes は現在約 5,000 個のノードを管理しています。これは、Borg や Tupperware のスケーラビリティとは程遠いものです。 Google と Facebook のデータセンターの物理クラスターは約 10 万台のマシンにまたがり、複数のデータセンターが 1 つのリージョンを形成しています。 Google では、これらの物理クラスターは Borg によってセルに分割されており、過去にはこれらのセルの平均ノード数は 10,000 でしたが、数千ノードにスケールダウンされたものもあれば、50,000 ノードまでスケールアップされたものもありました。

タッパーウェアが最初に考案されたとき、Facebook はラック、クラスター、データセンターの観点から、ほとんどのデータセンターと同様にタッパーウェアを編成し、これらの構造は、上回ることが困難な物理的構成になることがよくありました。また、2010 年代初頭には、Docker コンテナは存在すらしていなかった (そして、何年も実稼働していなかった) ため、Facebook は当初、サンドボックス化されたアプリケーションを実行するために chroot を使用し、すべてのアプリケーションを単一の物理 Linux サーバー上で同時に実行できるようにしました。これは、Google が長年行っていたのと同じです。また、名前空間が成熟するにつれて、Facebook もワークロード間の分離を実現するためにこれを採用しました。

周知のとおり、Google によって作成され、Linux コミュニティに寄贈された Cgroups と Namespaces は、Docker と Linux コンテナの基盤であり、Facebook が Linux コンテナを導入して社内で一方向に拡張したのに対し、Docker は Linux コンテナを採用して、少し異なる方法で進化させました (単純化しすぎであることは承知しています)。私たちの見解では、コンテナ化に関しては Facebook は Google より数年遅れており、最終的には同じ問題に直面し、少し異なる方法で解決しました。問題は、クラスター レベルで管理しても効率を向上できないことです。最終的には、データセンターとリージョンをまたぐ必要があります。

現在、Tupperware は、ラック、クラスター、データ センターという観点で考えるのではなく、数十万台の物理サーバーが存在する地域、または場合によっては世界中の複数の地域にある複数のデータ センターにわたって抽象化レイヤーを提供しています。 Tupperware は、クラスターを管理するための運用ツールから、Facebook でアプリケーションを展開するプログラマーが「このアプリケーションを Prineville 地域の異なるデータ センターで実行するように展開するか、Prineville と Lula のデータ センターに展開すると、Tupperware が可用性に基づいて計算します」と簡単に指示できる意図的なツールへと進化しました。これはサーバーレス コンピューティングではありません (私たちにとっては馬鹿げた用語です)。これはシステム管理されていないコンピューティングであり、正直に言えば、すべてのデータ センターの究極の目標です (システム管理者は、会社に雇用されている唯一のサイト信頼性エンジニアになる予定がない限り、これを行いません)。

クラスター管理は Facebook にとって大きな障害でしたが、同社は Resource Broker と呼ばれるツールでこれに対処しました。このツールにより、Facebook は作業をあるクラスターから別のクラスターに移動し、クラスターをスケジューラに緩く結合することでクラスターを維持できるようになりました。 Resource Broker は、すべての Facebook サーバーの容量と可用性も監視します。

Tupperware スケジューラと物理クラスタ間のリンクが切断されると、物事はより簡単になり始めます。現在、各リージョン内またはリージョン間でスケジューラの作業はシャード化されており、各シャードは Tupperware で実行されているジョブのサブセットを管理していますが、重要なのは、これらすべてのシャードが集約され、管理されているすべてのサーバー、コンテナー、ワークロードの単一のビューが表示されることです。興味深いことに、Tang 氏は、管理下にあるサーバーにコンテナーを割り当てる Tupperware スケジューラーのアロケーターは、シャーディングなしで Facebook リージョン全体を処理できるほど強力であると述べています (これは、Facebook が他の理由で Tupperware をシャーディングしないという意味ではありません)。各サーバーには、BTRFS ファイルシステムでカスタム形式を使用して作成され、systemd によって管理されるコンテナーを開いたり削除したりする Tupperware デーモンがあります。

興味深いことに、Facebook はシングルソケット サーバー、特に Facebook でインフラストラクチャ ソフトウェアを実行するために広く導入されている Yosemite マイクロサーバーの分野では最前線に立っています。その結果、Facebook の各データセンターには、標準的な 2 ソケット マシンの数は増えないまでも、物理サーバーの数が増え、Tupperware にかかる負荷が増加する一方で、ムーアの法則により各ノードがサポートできるコア数が増加し、したがってコンテナーの数も増えることになります。そのため、タッパーウェアの作業を分割する必要はありますが、タッパーウェアとのインターフェースは透明に保つことが望ましいです。

しかし、ここには別の使命があります。最終的に、Facebook は単一の画面からその全資産を管理できるようにしたいと考えています。そのためには、より多くの Tupperware ワーカー シャードと、Facebook ネットワーク上のワークロードに関連付けられた同様のストレージ シャードが必要になります。今のところ、Facebook のインストール済みサーバーの 20% のみがこの巨大な共有リソース プールに含まれていますが、Facebook は最終的に、データ センターや地域に関係なく、いつでもどこでもグローバル リソースを使用できるようにしたいと考えています。

これはもう 1 つの興味深い観察です。Borg がワークロードについて考える方法は、オンライン作業とバッチ作業があり、スケジューラの主な仕事は、オンライン作業 (検索エンジンの要求を満たすなど) にさらに容量が必要になるまで、アイドル状態の容量をバッチ作業 (MapReduce データ分析作業など) で埋めることです。したがって、2 種類の作業はシステム上で交互に実行され、必要に応じて使用量が増減され、使用率が向上します。

Facebook は異なるアプローチを採用し、生のサーバー レベルで考えます。まず、マイクロサーバーでは、サーバー ノードあたりの生のコンピューティングが小さいため、2 ソケット マシンよりも分割できる部分が少なくなります (これは、AMD Rome Epyc プロセッサのコア数が多いと変わります)。 Facebook では、プログラマーはサーバーの能力をすべて活用するような方法でコーディングするように教えられています。各リージョンの夜間、ニュース フィード、メッセンジャー、Web フロントエンド、およびアプリケーションの他のレイヤーがあまり使用されていないときに、そのリージョンのサーバー ノードは、MapReduce 分析や統計的機械学習などのさまざまなバッチ処理ジョブを実行します (結局のところ、ディープラーニングにすべての GPU が必要なわけではありません)。そのため、各物理サーバーに異なるコンテナをプロビジョニングするためのオンライン作業またはバッチ作業の量を心配する代わりに、Facebook は Resource Broker を使用してバッチ作業またはオンライン作業を各サーバーに分散し、完全に実行され、最も価値のある消費が得られるようにします。これは Google と Facebook の興味深い違いであり、コンテナは実際にはワークロード分離ツールというよりもデプロイメント メカニズムに近いものです。

規模以外にも、Facebook が Kubernetes を誇れる領域として主張しているのは、Facebook アプリのフロントエンドを構成する Web サーバーや PHP サーバーなどのステートレス アプリケーションではなく、Facebook Web サイト、Instagram、Messenger、WhatsApp の背後にあるデータベースやデータ ストア (ZippyDB、ODS Gorilla、Skuba など) などのステートフル アプリケーションの管理です。

Tupperware コントローラーに追加された TaskControl というサービスは、ストレージへのステートフル リンクの維持に関するアプリケーションの依存関係を調べ、そのニーズに基づいて、それらのアプリケーションを実行するコンテナーをどのようにデプロイするかを決定し、ステートフル リンクを中断してアプリケーションを破損またはクラッシュさせることなく、必要に応じてコンテナーを更新および移動します。 TaskControl は、Facebook ネットワーク内でのデータの配置と複製を決定する ShardManager と呼ばれるデータ サービスと連携して動作します。これらはすべて自動的に行われるため、プログラマーが心配する必要はありません。

比例制御 比例ストレージ

ご想像のとおり、Tupperware やその他の Facebook サービスにおけるコントロール プレーンのデータ管理は大変な作業です。そのため、Facebook は、Facebook スタックのコントロール プレーンに展開され、最終的にはファイルおよびオブジェクト ストレージのアーキテクチャになる可能性がある、新しい複製ストレージ システムである Delos について検討しています。

Delos が作成される前は、Facebook ソフトウェアのさまざまなコントロール プレーンで使用されるデータは、MySQL、ZooKeeper、その他のキー値ストアやデータベースを使用するなど、さまざまな方法で保存されていました。ほとんどの企業と同様に、それぞれの固有のアプリケーションには、独自の API、パフォーマンス、フォールト トレランス、および展開方法を備えた、固有のデータ ストアまたはデータベースが必要であるように思われます。通常、コントロール プレーンのこれらのストレージ システムは、最初から設計し、コントロール プレーンに新しい機能セットが追加されるたびに書き直す必要があります。本当に困ったものです。

その結果、Facebook は Delos を使用したモノリシック ストレージ システムの設計を放棄したと Flinn 氏は The Next Platform に語った。

Flinn 氏は、Delos の背後にあるアイデアは、再構成可能で仮想的な分散共有ブロックの新しい抽象化を中心にストレージ システムを構築し、コントロール プレーンの独自の目標の多くを満たすことができることだと説明しました。したがって、信頼性の高いストレージの基準は、可用性が高く、一貫性が強くなければならないということです。また、セカンダリ インデックスを使用したリレーショナル クエリや、クエリ プランニング、複雑な述語などを備えた、かなり豊富な API も必要になります。また、さまざまなハードウェアで実行する必要があります。最新のマシンには確かに最大のストレージが搭載されていますが、メタデータを提供するサービスと同じ場所に配置されている可能性のある古いマシンでも実行する必要があります。私の意見では、ここでの最大の要件、そして Delos が提供するユニークな点の 1 つは、依存関係がなく、スタックの一番下になるように設計されていることです。これにより、新しいデータセンターの開設や作業の再開などが簡素化されます。

Delos の背後にある重要な考え方は、いわゆるマテリアライズド データ状態がストレージの順序付けと耐久性の側面から切り離され、さまざまなレベルのフォールト トレランスやレプリケーションを備えたより複雑なログを、比較的単純なログから構築できるというものです。次の図のように:

VirtualLog は、リレーショナル、キー値、ファイル システム、およびその他の API が外部に公開される方法である、より高いレベルの具体化で状態を維持しながら、モードを切り替えて、ある SimpleLog 形式を別の SimpleLog 形式として動作させることができます。これの利点は、上位の API レイヤーを壊すことなく、ストレージ システムの基盤レイヤーを完全に変更できることです。これは、ストレージ システムが複数の同時機能を持つことができ、必要に応じて異なるレイヤーを個別に更新できるという 2 つのことを意味します。

Delos の最初の使用例は、Tupperware リソース エージェントの下に配置され、Facebook が Hadoop スタック用のオープン ソース ZooKeeper プロジェクトから作成したカスタム ZKLog システムを置き換える、DelosTable と呼ばれるリレーショナル システムを作成することでした。当初、Facebook は ZKLog 上で DelosTable を実行していましたが、4 か月後には ZKLog レイヤーをネイティブの SimpleLog 形式に置き換えることができました。この形式は、Facebook が Tupperware の生産ソフトウェア環境で以前から公開している LogDevice システムに基づいています。以下は、さまざまなログ形式で Tupperware リソース エージェントを実行した場合のパフォーマンスの概要です。

Flinn 氏は Delos の記事で、レイテンシ SLA に基づいて、分散ログ アプライアンス ソート層と集約ローカル ログ ソート層を動的に切り替えると説明しました。レイテンシ SLA が満たされると、集約実装 (使用するリソースが少なく、クリティカル パスの依存関係がない) が選択され、レイテンシ SLA に違反すると、分散実装に切り替えられます。

明らかに、LogDevice 形式や NativeLog 形式を使用すると、ZKLog を使用する場合と比較して、レイテンシが短縮され、全体的なパフォーマンスが向上するという点で大きなメリットがあり、これは Tupperware コントロール プレーンにメリットをもたらします。次のアイデアが出てきたら、それを Delos に統合して、パフォーマンスやスケーラビリティをさらに向上させることは比較的簡単になります。

翻訳者: lzc 氏、ソフトウェア エンジニア、DevOpsDays Shenzhen コア オーガナイザー & ボランティア。現在は Huawei に勤務し、クラウド ストレージに従事し、Kubernetes、マイクロサービス、サーバーレスに重点を置き、クラウド ネイティブ方式でクラウド ファイル システム サービスを構築しています。