How to speed up container startup

概要

サーバーレスコンピューティング (FaaS) は、顧客が自身のコードとビジネスロジックのみに集中できる新しいクラウドコンピューティングパラダイムです。基盤となる仮想化、リソース管理、弾力的スケーリングは、すべてクラウドシステムサービスプロバイダーがメンテナンスを担います。サーバーレスコンピューティングはコンテナエコシステムをサポートし、さまざまなビジネスシナリオを解放します。しかし、コンテナイメージの複雑さと大きさ、FaaS の高い動的性および予測不可能なワークロードにより、業界をリードする多くの製品や技術を FaaS プラットフォームに適切に適用できません。そのため、効率的なコンテナ配信技術は FaaS プラットフォーム上で課題に直面しています。

本論文では、FaaSNet を設計・提案します。FaaSNet は高いスケーラビリティを持つ軽量システムミドルウェアで、イメージアクセラレーションフォーマットを活用したコンテナ配信を実現します。対象シナリオは、FaaS における突発的トラフィック下での大規模コンテナイメージ起動（関数のコールドスタート）です。FaaSNet のコアコンポーネントには、分散型自己平衡二分木トポロジーである Function Tree (FT) が含まれ、ツリートポロジー内のすべてのノードは等価です。

FaaSNet を Function Compute 製品に統合した実験の結果、高同時実行リクエスト下で、FaaSNet は Function Compute (FC) と比較して 13.4 倍のコンテナ起動速度を実現できることが示されました。さらに、突発的リクエストによるエンドツーエンドレイテンシの不安定化に対して、FaaSNet は FC と比較して 75.2% 短い時間でエンドツーエンドレイテンシを通常レベルに回復できます。

論文の導入

1. 背景と課題

FC は 2020 年 9 月にカスタムコンテナイメージのサポートを開始しました（https://developer.aliyun.com/article/772788 ）。同年 12 月、AWS Lambda も Lambda コンテナイメージサポートを相次いでリリースし、FaaS がコンテナエコシステムを取り入れる趨勢が明確になりました。また、Function Compute は 2021 年 2 月にイメージアクセラレーション機能をリリースしました（https://developer.aliyun.com/article/781992 ）。これらの 2 つの機能により、ユーザーはコンテナベースのビジネスロジックを Function Compute プラットフォームへシームレスに移行でき、GB レベルのイメージを秒レベルで起動できます。

Function Compute バックエンドで大規模リクエストにより関数のコールドスタートが多数発生する場合、イメージアクセラレーション機能のサポートがあっても、コンテナレジストリの帯域幅に大きな負荷がかかります。複数マシンが同時に同じコンテナレジストリからイメージデータをプルすると、コンテナイメージサービスの帯域幅がボトルネックまたは流量制限の対象となり、イメージデータのプルおよびダウンロード時間が増加します（イメージアクセラレーションフォーマットの場合でも）。より直接的なアプローチとして Function Compute バックエンドのレジストリ帯域幅を増強できますが、この方法では根本的な問題を解決できず、追加のオーバーヘッドも発生します。

1）ワークロード分析

まず、FC の 2 つの主要リージョン（北京と上海）からオンラインデータを分析しました。

図 (a) は関数のコールドスタート時の FC システムによるイメージプル遅延を分析したもので、北京では約 80%、上海では約 90% のイメージプル遅延が 10 秒を超えていることが分かります。

図 (b) はコールドスタート全体に対するイメージプルの割合を示しています。北京リージョンの 80% の関数、上海リージョンの 90% の関数で、コールドスタート全体の 60% 以上の遅延をイメージプルが占めることも確認できます。

ワークロード分析から、関数のコールドスタート時間の大部分がコンテナイメージデータの取得に費やされていることが分かります。したがって、この遅延を最適化することで、関数のコールドスタートパフォーマンスを大幅に改善できます。

オンライン運用保守の履歴記録によると、ある大手ユーザーの代表例では、4,000 の関数イメージを瞬時にプルしました。これらのイメージのサイズは圧縮前で 1.8 GB、圧縮後で 3 〜 4 GB です。高トラフィックリクエストが到着しコンテナのプルが開始された瞬間、コンテナサービスから流量制御アラームが発報し、一部のリクエスト遅延が長期化しました。深刻な場合は、コンテナ起動失敗のプロンプトを受信することもあります。このような問題シナリオは早急に解決する必要があります。

2）既存技術との比較

学術界および産業界には、イメージ配信速度を高速化できるいくつかの関連技術があります。たとえば：

DADI

DADI は効率的なイメージアクセラレーションフォーマットを提供し、オンデマンド読み取りを実現します（FaaSNet もコンテナアクセラレーションフォーマットを活用しています）。イメージ配信技術の面では、DADI はイメージレイヤーの粒度でノードをネットワーク化するツリートポロジー構造を採用しています。各レイヤーが 1 つのツリートポロジー構造に対応し、各 VM は複数の論理ツリーに存在します。DADI の P2P 配信は、より大きなパフォーマンス仕様（CPU、帯域幅）を持つ数台のルートノードに依存して、データのオリジン取得とトポロジー内のピアのマネージャーとしての役割を担います。DADI のツリー構造は比較的静的です。コンテナのプロビジョニング速度は一般的に長時間持続しないため、デフォルトでは DADI のルートノードは 20 分後にトポロジーロジックを解消し、継続的に維持しません。

Dragonfly

Dragonfly も P2P ベースのイメージおよびファイル配信ネットワークで、Supernode（マスターノード）と dfget（ピアノード）のコンポーネントパッケージで構成されます。DADI と同様に、Dragonfly も数台の大規模仕様の Supernode に依存してクラスタ全体を支えます。Dragonfly も中央の Supernode ノードを通じて完全にリンクされたトポロジーを管理・維持します（複数の dfget ノードが同じファイルの異なる断片を提供して、ターゲットノードへのピアツーピア伝送を実現します）。Supernode のパフォーマンスは、クラスタ全体のスループット性能における潜在的なボトルネックとなる可能性があります。

Kraken

Kraken の origin ノードと tracker ノードは中央ノードとしてネットワーク全体を管理し、エージェントは各ピアノードに存在します。Kraken の tracker ノードは組織クラスタ内のピアの接続のみを管理し、Kraken はピアノード間で自律的に通信およびデータ伝送を行うことを許可します。ただし、Kraken もイメージレイヤーベースのコンテナイメージ配信ネットワークであり、ネットワーキングロジックはより複雑な全結合モードになる可能性があります。

上記 3 つの業界をリードする技術を説明することで、いくつかの共通点が見えてきます。

まず、3 つともイメージレイヤーを配信単位として使用しており、ネットワーキングロジックが細粒度すぎるため、各ピアノードで同時に複数のアクティブなデータ接続が発生します。

次に、3 つとも中央ノードに依存してネットワーキングロジックの管理とクラスタ内のピアノード間の調整を行っています。DADI と Dragonfly の中央ノードはデータのオリジン取得も担当します。この設計では、本番利用において非常に高いトラフィックを処理するために大規模仕様マシン数台の配備が必要であり、期待されるパフォーマンス指標を達成するためにパラメータチューニングも必要です。

FC ECS アーキテクチャの前提条件の下で設計を検討します。FC ECS アーキテクチャ内の各マシンは、2 CPU コア、4 GB メモリ、1 Gbps の内部ネットワーク帯域幅という仕様で、これらのマシンのライフサイクルは信頼性が低く、いつでも回収される可能性があります。

これにより、3 つのより深刻な問題が生じます。

内部ネットワーク帯域幅の不足により、全結合での帯域幅輻輳が発生しやすくなり、データ伝送パフォーマンスが低下します。全結合トポロジー構造は関数認識を持たず、FC 環境下でシステムセキュリティの問題を引き起こしやすくなります。各関数ロジックを実行するマシンは FC システムコンポーネントから信頼されていないため、テナント A がテナント B のデータを傍受するセキュリティリスクが残ります。

CPU と帯域幅の仕様が限られています。従量課金型 Function Compute の課金特性により、クラスタ内のマシンライフサイクルは信頼性が低く、マシンプールから数台のマシンを中央ノードとして確保してクラスタ全体を管理できません。これらのマシンのオーバーヘッドは大きな負担となります。さらに、信頼性も保証できず、マシンは障害につながる可能性があります。FC が必要とするのは、オンデマンド課金特性を継承し、瞬時にネットワークを構築できる技術です。

複数関数の問題。上記 3 つには関数認識メカニズムがありません。たとえば、DADI P2P では、単一ノードが多数のイメージを保持してホットスポットとなり、パフォーマンスが低下する問題が発生する可能性があります。より深刻な問題は、複数関数のプルが本質的に予測不可能であることです。複数関数が同時にフル帯域幅までプルすると、同時にリモートからダウンロードされる他のサービス（コードパッケージやサードパーティ依存関係のダウンロードなど）にも影響がおよび、システム全体の可用性問題が発生します。

これらの課題を踏まえ、次のセクションで FaaSNet の設計案を詳しく説明します。

2. 設計案 - FaaSNet

前述の業界における 3 つの成熟した P2P ソリューションによると、関数レベルでの認識が実現されておらず、クラスタ内のトポロジーロジックは主に全結合ネットワークモードで、マシン性能に一定の要件を課しています。これらの前提設定は FC ECS のシステム実装には適しません。そこで、関数レベルの関数認識に対応した論理ツリートポロジー構造である Function Tree（以下 FT）を提案します。

1）FaaSNet アーキテクチャ

図のグレーの部分が FaaSNet のシステム修正部分で、他の白いモジュールは FC の既存システムアーキテクチャを踏襲しています。注目すべきは、FaaSNet のすべての Function Tree は FC スケジューラ上で管理されている点です。各 VM には VM エージェントがあり、gRPC 通信でスケジューラと連携して上流・下流ノードからのメッセージを受信します。さらに、VM エージェントは上流・下流ノードとの間でイメージデータの取得と配信も担当します。

2）分散型関数/イメージレベル自己平衡ツリートポロジー

上記 3 つの課題に対応するため、まずトポロジーを関数/イメージレベルに昇格させ、各 VM 上のネットワーク接続数を効果的に削減しました。さらに、AVL 木に基づくツリートポロジーを設計しました。次に、Function Tree の設計について詳しく説明します。

Function Tree

分散型自己平衡二分木トポロジー

FT の設計は AVL 木アルゴリズムに着想を得ています。現在 FT にはノード重みの概念がなく、すべてのノード（ルートノードを含む）が等価です。任意のノードがツリーに追加または削除されると、ツリー全体が完璧な平衡構造を維持し、任意のノードの左右部分木の絶対高さの差が 1 を超えないことを保証します。ノードの追加または削除時、FT はツリー自体の形状（左/右回転）を調整して平衡構造を実現します。下図の右回転の例に示すように、ノード 6 が回収される際、ノード 1 を親ノードとする左右部分木の高さが不均衡になり、右回転操作により平衡状態を復元する必要があります。状態 2 は回転後の最終状態を表し、ノード 2 がツリーの新しいルートノードとなります。注：すべてのノードは FC 内の ECS マシンを表します。

FT では、すべてのノードが等価で、主な責務は次のとおりです。1. 上流ノードからデータをプルする。2. 2 つの下流子ノードにデータを配信する。（FT では特定のルートノードを指定しない点に注意してください。ルートノードと他のノードの唯一の違いは、上流がソースノードであることであり、ルートノードはいかなるメタデータ管理も担当しません。次のセクションで、メタ情報の管理方法について説明します。）

複数ピアノード上での複数 FT の重複

同一ユーザーの異なる関数が同一ピアノード上に存在するため、必然的に 1 つのピアノードが複数の FT に位置する状況が生じます。上図に示すように、インスタンス内には func 0 〜 2 に属する 3 つの FT が存在します。ただし、FT は独立して管理されるため、伝送が重複しても、FT は各ノードが対応する正しい上流ノードを見つけ出せるようになっています。

さらに、マシンが保持できる関数の最大数を制限することで関数認識を実現し、複数関数のプルダウンデータ制御不能問題をさらに解決します。

設計の正確性に関する考察

FC に統合することで、FT のすべてのノードが等価であるため、いかなる中央ノードにも依存する必要がないことが分かります。

トポロジーロジックの管理者はクラスタ内に存在せず、FC のシステムコンポーネント（スケジューラ）が管理し、コンテナ作成リクエストと一緒に gRPC 経由で各ピアノードに送信されます。

FT は FaaS ワークロードの高い動的特性に完全に適応し、クラスタ内のあらゆるサイズのノードが参加・離脱時に自動的に形態を更新します。

関数という粗い粒度でのネットワーキングと、二分木データ構造を使用して FT を実装することで、各ピアノードのネットワーク接続数を大幅に削減できます。

関数を隔離単位としてネットワーキングすることで、関数認識を自然に実装し、システムのセキュリティと安定性を向上できます。

3. 性能評価

実験では、Alibaba Cloud の DAS アプリケーションシナリオのイメージを選定し、Python をベースイメージとしました。コンテナイメージの圧縮前サイズは 700 MB 以上で、29 のイメージレイヤーで構成されます。ここではストレステストのセクションを選んで解釈し、完全なテスト結果は元の論文を参照してください。テストシステムとして、Alibaba の DADI、Dragonfly 技術、および Uber のオープンソース Kraken フレームワークとの比較を行いました。

1）ストレステスト

ストレステストのセクションで記録される遅延は、ユーザーが認識するエンドツーエンドのコールドスタート遅延の平均値です。まず、イメージアクセラレーション機能が従来の FC と比較してエンドツーエンドレイテンシを大幅に改善できることが分かります。しかし、同時実行数が増加すると、より多くのマシンが同時に中央コンテナレジストリからデータをプルするため、ネットワーク帯域幅の競合が生じ、エンドツーエンドレイテンシが増加します（オレンジと紫のバー）。一方、FaaSNet では分散型設計により、同時実行の圧力レベルに関係なく、1 つのルートノードのみがオリジンからデータをプルして下流に配信するため、極めて高いシステムスケーラビリティを持ち、平均レイテンシは同時実行圧力の増加により上昇しません。

ストレステストのセクションの最後に、異なるイメージの関数（複数関数）を同一 VM 上に配置した場合のパフォーマンスを検証しました。ここでは、イメージアクセラレーションを有効化し DADI P2P をインストールした FC (DADI+P2P) と FaaSNet を比較しました。

上図の縦軸は正規化されたエンドツーエンド遅延レベルを表します。異なるイメージの関数が増加するにつれて、DADI P2P ではレイヤー数が多く、FC 内の各 ECS の仕様が小さいため、各 VM の帯域幅に過大な負荷がかかり、パフォーマンスが劣化します。エンドツーエンド遅延は 200% 以上にまで増加しました。一方、FaaSNet はイメージレベルで接続を確立するため、接続数は DADI P2P のレイヤーツリーより遥かに少なく、依然として良好なパフォーマンスを維持できます。

まとめ

高いスケーラビリティと高速なイメージ配信速度により、FaaS サービスプロバイダーはカスタムコンテナイメージのシナリオをより効果的に解放できます。FaaSNet は軽量で分散型の自己平衡 Function Tree を利用することで、中央ノードによるパフォーマンスボトルネックを回避し、追加のシステムオーバーヘッドを導入せず、既存の FC システムコンポーネントとアーキテクチャを完全に活用しています。FaaSNet はワークロードの動的特性に基づいてリアルタイムネットワーキングを実現し、関数認識を実現します。事前のワークロード分析や前処理は不要です。

FaaSNet の対象シナリオは FaaS に限定されません。Kubernetes や Alibaba SAE など、多くのクラウドネイティブシナリオで、突発的トラフィックへの対応において力を発揮し、コールドスタート過多によるユーザー体験への影響という課題を解消し、コンテナのコールドスタート問題を根本的に解決できます。

FaaSNet は、国内クラウドベンダーとして初めて、サーバーレスシナリオでの突発的トラフィックに対応するコンテナ起動高速化技術に関する論文を国際トップカンファレンスで発表しました。本研究がコンテナベース FaaS プラットフォームに新たな可能性をもたらし、コンテナエコシステムへの扉を完全に開き、機械学習やビッグデータ解析など、より多くのアプリケーションシナリオを解放できることを期待します。