タッパーウェア: Facebook の Kubernetes キラー?

Tupperware を使用した、あらゆる規模のクラスターの効率的かつ信頼性の高い管理

今日は Systems@Scale カンファレンス 当社は、ほぼすべてのサービスを実行している数百万台のサーバー間でコンテナを調整するクラスター管理システムである Tupperware を導入しました。 当社は 2011 年に初めて Tupperware を導入し、それ以来当社のインフラストラクチャは 1 データセンター 全体まで 15 の地理的に分散されたデータセンター。 その間、タッパーウェアは立ち止まらず、私たちとともに発展してきました。 Tupperware が、ステートフル サービスの便利なサポート、すべてのデータ センターに対する単一のコントロール パネル、サービス間の容量をリアルタイムで分散する機能など、一流のクラスター管理をどのように提供するかを説明します。 また、インフラストラクチャの進化に応じて学んだ教訓も共有します。

タッパーウェアはさまざまなタスクを実行します。 アプリケーション開発者は、これを使用してアプリケーションを配信および管理します。 アプリケーション コードと依存関係をイメージにパッケージ化し、それをコンテナーとしてサーバーに配信します。 コンテナーは、同じサーバー上のアプリケーション間の分離を提供するため、開発者はアプリケーション ロジックを処理し、サーバーの検索や更新の管理について心配する必要がなくなります。 タッパーウェアはサーバーのパフォーマンスも監視しており、障害を発見した場合には、問題のあるサーバーからコンテナを転送します。

キャパシティ プランニング エンジニアは、Tupperware を使用して、予算と制約に基づいてサーバーのキャパシティをチームに割り当てます。 また、サーバーの使用率を向上させるためにも使用されます。 データセンターのオペレーターは、データセンター全体にコンテナを適切に分散し、メンテナンス中にコンテナを停止または移動するために Tupperware を利用しています。 このおかげで、サーバー、ネットワーク、機器の保守に必要な人間の介入は最小限に抑えられます。

タッパーウェアのアーキテクチャ

Tupperware PRN アーキテクチャは、データセンターのリージョンの 1 つです。 この地域は、近くにある複数のデータ センター ビルディング (PRN2 および PRNXNUMX) で構成されます。 XNUMX つのリージョン内のすべてのサーバーを管理する XNUMX つのコントロール パネルを作成する予定です。

アプリケーション開発者は、Tupperware ジョブの形式でサービスを提供します。 ジョブは複数のコンテナで構成されており、通常、それらはすべて同じアプリケーション コードを実行します。

Tupperware は、コンテナーのプロビジョニングとライフサイクルの管理を担当します。 これはいくつかのコンポーネントで構成されています。

• Tupperware フロントエンドは、Tupperware と対話できるユーザー インターフェイス、CLI、およびその他の自動化ツール用の API を提供します。 これらは内部構造全体をタッパーウェアのジョブ所有者から隠します。
• Tupperware Scheduler は、コンテナーとジョブのライフサイクルを管理するコントロール パネルです。 これはリージョン レベルとグローバル レベルで展開され、リージョン スケジューラは XNUMX つのリージョン内のサーバーを管理し、グローバル スケジューラは異なるリージョンのサーバーを管理します。 スケジューラはシャードに分割されており、各シャードは一連のジョブを管理します。
• Tupperware の Scheduler Proxy は内部シャーディングを隠し、Tupperware ユーザーに便利な単一画面を提供します。
• Tupperware アロケータは、コンテナをサーバーに割り当てます。 スケジューラーは、コンテナーの停止、開始、更新、およびフェイルオーバーを処理します。 現在、XNUMX つのアロケーターはシャードに分割せずにリージョン全体を管理できます。 (用語の違いに注意してください。たとえば、タッパーウェアのスケジューラは、タッパーウェアのコントロール パネルに対応します。 Kubernetes、Tupperware アロケータは、Kubernetes ではスケジューラと呼ばれます。)
• リソース ブローカーは、サーバーおよびサービス イベントの信頼できる情報源を保存します。 データ センターごとに XNUMX つのリソース ブローカーを実行し、そのデータ センター内のサーバーに関するすべての情報を保存します。 リソース ブローカーとキャパシティ管理システム、またはリソース プロビジョニング システムは、どのスケジューラ配信がどのサーバーを制御するかを動的に決定します。 ヘルス チェック サービスはサーバーを監視し、サーバーの健全性に関するデータをリソース ブローカーに保存します。 サーバーに問題があるかメンテナンスが必要な場合、リソース ブローカーはアロケーターとスケジューラーにコンテナを停止するか、コンテナを他のサーバーに移動するように指示します。
• Tupperware Agent は、各サーバー上で実行され、コンテナーのプロビジョニングと削除を処理するデーモンです。 アプリケーションはコンテナ内で実行されるため、分離性と再現性が高まります。 の上 昨年の Systems @Scale カンファレンス イメージ、btrfs、cgroupv2、systemd を使用して個々の Tupperware コンテナーを作成する方法についてはすでに説明しました。

タッパーウェアの特徴

Tupperware は、Kubernetes や Kubernetes などの他のクラスター管理システムと多くの点で似ています。 メゾス、ただし、違いもあります。

• ステートフル サービスの組み込みサポート。
• 異なるデータセンターにあるサーバー用の単一のコントロール パネルで、意図に基づいたコンテナの配信、クラスターの廃止、メンテナンスを自動化します。
• ズーム用の操作パネルを明確に分割。
• エラスティック コンピューティングを使用すると、サービス間でリアルタイムに電力を分散できます。

私たちは、巨大なグローバル共有サーバー群全体でさまざまなステートレスおよびステートフル アプリケーションをサポートするために、これらの優れた機能を開発しました。

ステートフル サービスの組み込みサポート。

Tupperware は、Facebook、Instagram、Messenger、WhatsApp の永続的な製品データを保存するさまざまな重要なステートフル サービスを運用しています。 これらは、キーと値のペアの大規模なストアである可能性があります (例: ZippyDB) および監視データ リポジトリ (たとえば、 ODSゴリラ и スキューバ）。 ステートフル サービスを維持することは簡単ではありません。システムは、ネットワーク停止や停電などの大規模な中断にコンテナの供給が耐えられることを保証する必要があるからです。 また、フォールト ドメイン間でコンテナを分散するなどの従来の手法はステートレス サービスにはうまく機能しますが、ステートフル サービスには追加のサポートが必要です。

たとえば、サーバー障害により 50 つのデータベース レプリカが使用できなくなった場合、10 のプールから 50 台のサーバーのコアを更新する自動メンテナンスを有効にする必要がありますか? 状況によります。 これら 2 台のサーバーのいずれかに同じデータベースの別のレプリカがある場合は、一度に XNUMX つのレプリカを失わずに待つことをお勧めします。 システムのメンテナンスとパフォーマンスに関する決定を動的に行うには、内部データのレプリケーションと各ステートフル サービスの配置ロジックに関する情報が必要です。

TaskControl インターフェイスを使用すると、ステートフル サービスがデータの可用性に影響を与える決定に影響を与えることができます。 このインターフェイスを使用して、スケジューラはコンテナ操作 (再起動、更新、移行、メンテナンス) について外部アプリケーションに通知します。 ステートフル サービスは、各操作を安全に実行できる時期を Tupperware に通知するコントローラーを実装しており、これらの操作は一時的に交換または遅延できます。 上記の例では、データベース コントローラーは Tupperware に 49 台のサーバーのうち 50 台を更新するように指示できますが、現時点では特定のサーバー (X) をそのままにしておくことができます。 その結果、カーネルの更新期間が過ぎてもデータベースが問題のあるレプリカを復元できない場合でも、Tupperware は X サーバーを更新します。

Tupperware の多くのステートフル サービスは、TaskControl を直接使用するのではなく、Facebook 上でステートフル サービスを作成するための共通プラットフォームである ShardManager を通じて使用します。 Tupperware を使用すると、開発者はコンテナをデータセンター間でどのように分散するかについての意図を正確に指定できます。 ShardManager を使用すると、開発者はデータ シャードをコンテナ間で分散する方法についての意図を指定できます。 ShardManager はアプリケーションのデータ配置とレプリケーションを認識し、TaskControl インターフェイスを介して Tupperware と通信して、アプリケーションが直接関与することなくコンテナ操作をスケジュールします。 この統合によりステートフル サービスの管理が大幅に簡素化されますが、TaskControl ではさらに多くのことが可能になります。 たとえば、当社の広範な Web 層はステートレスであり、TaskControl を使用してコンテナーの更新速度を動的に調整します。 最終的に Web 層は複数のソフトウェア リリースを迅速に完了できます。 可用性を損なうことなく、XNUMX 日あたり

データセンター内のサーバーの管理

Tupperware が 2011 年に初めて立ち上げられたとき、各サーバー クラスターは個別のスケジューラーによって管理されていました。 当時、Facebook クラスターは XNUMX つのネットワーク スイッチに接続されたサーバー ラックのグループであり、データ センターには複数のクラスターが収容されていました。 スケジューラーは XNUMX つのクラスター内のサーバーのみを管理できるため、ジョブを複数のクラスターに分散することはできません。 インフラストラクチャが拡大し、クラスターの償却が増加しました。 Tupperware は廃止されたクラスターから変更を加えずにジョブを他のクラスターに移動することができなかったため、多大な労力と、アプリケーション開発者とデータ センター オペレーター間の慎重な調整が必要でした。 このプロセスにより、廃止手順のためにサーバーが数か月間アイドル状態になったときにリソースが無駄になりました。

クラスターの廃止問題を解決し、他の種類のメンテナンス タスクを調整するために、リソース ブローカーを作成しました。 リソース ブローカーは、サーバーに関連付けられたすべての物理情報を追跡し、どのスケジューラーが各サーバーを制御するかを動的に決定します。 サーバーをスケジューラーに動的にリンクすると、スケジューラーはさまざまなデータセンターのサーバーを管理できるようになります。 Tupperware ジョブは単一クラスターに限定されなくなったため、Tupperware ユーザーはフォールト ドメイン間でコンテナーを分散する方法を指定できます。 たとえば、開発者は、特定のアベイラビリティ ゾーンを指定せずに、自分の意図 (たとえば、「PRN リージョン内の 2 つの障害ドメインでジョブを実行する」) を宣言できます。 Tupperware 自体は、クラスターまたはサービスが廃止された場合でも、この目的を実装するのに適したサーバーを見つけます。

グローバル システム全体をサポートする拡張性

これまで、当社のインフラストラクチャは、個々のチームごとに数百の専用サーバー プールに分割されてきました。 断片化と標準の欠如により、運用コストが高くつき、アイドル状態のサーバーを再度使用することがさらに困難になりました。 昨年のカンファレンスでは システム @Scale 私たちが提示した サービスとしてのインフラストラクチャ (IaaS)これにより、インフラストラクチャが単一の大きなサーバー パークに統合されるはずです。 ただし、シングル サーバー パークには独自の困難があります。 特定の要件を満たす必要があります。

• スケーラビリティ。 各地域にデータセンターを追加するにつれて、当社のインフラストラクチャは拡大しました。 サーバーは小型化され、エネルギー効率が向上しているため、各地域にはさらに多くのサーバーが存在します。 その結果、リージョンごとに XNUMX つのスケジューラーでは、各リージョンの数十万台のサーバーで実行できるコンテナーの数を処理できません。
• 信頼性。 たとえスケジューラをそれほどスケールアップできたとしても、スケジューラの範囲が広いということは、エラーのリスクが高く、コンテナのリージョン全体が管理不能になる可能性があることを意味します。
• フォールトトレランス。 大規模なインフラストラクチャ障害が発生した場合 (たとえば、スケジューラを実行しているサーバーがネットワーク障害や停電により障害を起こした場合)、悪影響はリージョン内の一部のサーバーにのみ影響します。
• 使いやすさ。 XNUMX つのリージョンに対して複数の独立したスケジューラを実行する必要があるように思えるかもしれません。 ただし、利便性の観点から見ると、リージョンの共有プールへの単一のエントリ ポイントにより、キャパシティとジョブの管理が容易になります。

大規模な共有プールの維持の問題を解決するために、スケジューラーをシャードに分割しました。 各スケジューラ シャードはリージョン内の独自のジョブ セットを管理するため、スケジューラに関連するリスクが軽減されます。 共有プールが大きくなるにつれて、さらに多くのスケジューラ シャードを追加できます。 Tupperware ユーザーにとって、シャードとスケジューラ プロキシは XNUMX つのコントロール パネルのように見えます。 タスクを調整する多数のシャードを操作する必要はありません。 スケジューラ シャードは、ネットワーク トポロジに従ってサーバーの共有プールを静的に分割せずにコントロール パネルをパーティション分割していた以前に使用していたクラスタ スケジューラとは根本的に異なります。

エラスティック コンピューティングによる使用効率の向上

インフラストラクチャが大規模になればなるほど、サーバーを効率的に使用してインフラストラクチャのコストを最適化し、負荷を軽減することがより重要になります。 サーバーの使用効率を高めるには XNUMX つの方法があります。

• エラスティック コンピューティング - 静かな時間帯にはオンライン サービスを縮小し、解放されたサーバーを機械学習や MapReduce ジョブなどのオフライン ワークロードに使用します。
• 過負荷 - オンライン サービスとバッチ ワークロードを同じサーバーに配置し、バッチ ワークロードが低い優先順位で実行されるようにします。

データセンターのボトルネックは、 電力使用量。 したがって、より多くの処理能力を提供する、小型でエネルギー効率の高いサーバーが好まれます。 残念ながら、CPU とメモリが少ない小規模サーバーでは、過負荷はあまり効果的ではありません。 もちろん、プロセッサ リソースとメモリをほとんど消費しない、エネルギー効率の高い XNUMX 台のサーバーに小規模なサービスのコンテナを複数配置することもできますが、この状況では大規模なサービスのパフォーマンスが低下します。 したがって、大規模なサービスの開発者には、サーバー全体を使用するようにサービスを最適化することをお勧めします。


基本的にはエラスティックコンピューティングを利用して利用効率を向上させます。 ニュース フィード、メッセージング機能、フロントエンド Web 層などの主要なサービスの多くは、時間帯によって異なります。 当社では、静かな時間帯にはオンライン サービスを意図的に縮小し、機械学習や MapReduce ジョブなどのオフライン ワークロードには解放されたサーバーを使用します。

大規模なサービスはエラスティック キャパシティの主要な提供者であり、主要な消費者でもあり、サーバー全体を使用するように最適化されているため、サーバー全体をエラスティック キャパシティの単位としてプロビジョニングすることが最善であることが経験からわかっています。 サーバーが待機時間中にオンライン サービスから解放されると、リソース ブローカーはサーバーをスケジューラにリースして、そのサーバー上でオフライン ワークロードを実行します。 オンライン サービスでピーク負荷が発生した場合、リソース ブローカーは借用したサーバーをすぐにリコールし、スケジューラと連携してオンライン サービスに返します。

学んだ教訓と将来の計画

過去 8 年間にわたり、当社は Facebook の急速な成長に対応するためにタッパーウェアを開発してきました。 私たちは学んだことを共有し、他の人が急速に成長するインフラストラクチャを管理するのに役立つことを願っています。

• コントロール パネルと、コントロール パネルが管理するサーバーとの間に柔軟な接続を設定します。 この柔軟性により、コントロール パネルでさまざまなデータ センターのサーバーを管理できるようになり、クラスターの廃止とメンテナンスの自動化に役立ち、エラスティック コンピューティングを使用した動的な容量割り当てが可能になります。
• リージョン内に単一のコントロール パネルがあると、タスクの処理がより便利になり、大規模な共有サーバー フリートの管理が容易になります。 規模や耐障害性の理由で内部構造が分離されている場合でも、コントロール パネルは単一のエントリ ポイントを維持することに注意してください。
• プラグイン モデルを使用すると、コントロール パネルは今後のコンテナー操作を外部アプリケーションに通知できます。 さらに、ステートフル サービスはプラグイン インターフェイスを使用してコンテナ管理をカスタマイズできます。 このプラグイン モデルを使用すると、コントロール パネルがシンプルになり、さまざまなステートフル サービスを効率的に提供できます。
• 私たちは、バッチ ジョブ、機械学習、その他の緊急でないサービスのためにドナー サービスからサーバー全体を取り除くエラスティック コンピューティングが、エネルギー効率の高い小型サーバーの効率を向上させる最適な方法であると信じています。

実装はまだ始まったばかりです 単一のグローバル共有サーバー群。 現在、サーバーの約 20% が共有プール内にあります。 100% を達成するには、共有ストレージ プールの維持、メンテナンスの自動化、クロステナント要件の管理、サーバー使用率の向上、機械学習ワークロードのサポートの向上など、多くの問題に対処する必要があります。 私たちはこれらの課題に取り組み、成功を共​​有するのが待ちきれません。

出所： habr.com