[論文レビュー] Mitigating Cold Starts in Serverless Platforms: A Pool-Based Approach

Ping-Min Lin, Alex Glikson|arXiv (Cornell University)|Mar 28, 2019

Cloud Computing and Resource Management参考文献 3被引用数 50

ひとこと要約

本論文は Knative Serving においてウォーム関数インスタンスのプールを実装し、コールドスタート待機を低減させ、単一ポッドプールでP99を最大で85%削減することを実現している。

ABSTRACT

Rapid adoption of the serverless (or Function-as-a-Service, FaaS) paradigm, pioneered by Amazon with AWS Lambda and followed by numerous commercial offerings and open source projects, introduces new challenges in designing the cloud infrastructure, balancing between performance and cost. While instant per-request elasticity that FaaS platforms typically offer application developers makes it possible to achieve high performance of bursty workloads without over-provisioning, such elasticity often involves extra latency associated with on-demand provisioning of individual runtime containers that serve the functions. This phenomenon is often called cold starts, as opposed to the situation when a function is served by a pre-provisioned "warm" container, ready to serve requests with close to zero overhead. Providers are constantly working on techniques aimed at reducing cold starts. A common approach to reduce cold starts is to maintain a pool of warm containers, in anticipation of future requests. In this report, we address the cold start problem in serverless architectures, specifically under the Knative Serving FaaS platform. We describe our implementation leveraging a pool of function instances, and evaluate the latency compared to the original implementation, resulting in a 85% reduction of P99 response time for a single instance pool.

研究の動機と目的

• サーバーレス（FaaS）プラットフォームにおけるコールドスタート遅延の低減を動機づける。
• Knative Serving 内でコールドスタートを緩和するためのプールベースのウォームポッド戦略を提案する。
• プールを Knative リソースとして実装し、オートスケーリングとポッド移動を統合する。
• 単純およびヘビーな初期化を用いた、プールなしのベースライン Knative と比較して待機時間の改善を評価する。

提案手法

• ウォームポッドを管理するため、リビジョン構造を模した Knative Custom Resource Definition (CRD)としてプールを実装する。
• 新しいポッドを起動する前に、ポッドをリリース先リビジョンへ移動するよう Knative のオートスケーリングを変更する。
• ラベル付けの変更とメトリクス収集の有効化によってポッドを対象の replicaSets へ移行し、欠員が生じた場合のみ新規ポッドを起動する。
• GCP 上で 2 つのアプリ（Go HTTP サーバと TensorFlow 画像分類器）を用いて、コールドスタートとウォームスタートを比較し、性能を測定する。
• パレート分布の到着間隔トレースを用いた大規模シミュレーションを実施し、さまざまなプールサイズでのパーセンタイル遅延改善を評価する。

実験結果

リサーチクエスチョン

• RQ1 ウォームポッドのプールは、サーバーレス関数のコールドスタート遅延（P95、P99、P99.5）をどれだけ削減するか？
• RQ2 単一ポッドのプールが、アプリケーション初期化オーバーヘッドが異なるさまざまなワークロードに与える影響は？
• RQ3 プール支援付きオートスケーリングは Knative Serving の待機時間と移行時間にどう影響するか？
• RQ4 プールを追加する際のリソースと実装のオーバーヘッド（LOC、移行時間）は？

主な発見

Application	Cold Start (sec)	Warm Start (sec)
HTTP Server	12.123 (1.638)	5.076 (1.055)
Image Classifier	39.25 (1.475)	7.458 (0.641)

• 1 ポッドのプールは HTTP サーバのコールドスタートを 12.123s から 5.076s に削減する（σ 1.638, 1.055 分別）。
• 1 ポッドのプールは 画像分類器のコールドスタートを 39.25s から 7.458s に削減する (σ 1.475, 0.641 分別)。
• プールは単一インスタンスプールに対して P99 コールドスタート遅延を最大約 85% 削減することを実現する（結論のとおり）。
• シミュレーションでは、プール内に 1 ポッドを置くことで短い・長いアプリケーションのいずれも P95 が完全に排除され、P99 は少なくとも 50% 減少。
• ポールドポッドをターゲットリビジョンへ移行するには約 2 秒；プールリソース定義 ~200 LOC；移行コード ~350 LOC。