[論文レビュー] Understanding Open Source Serverless Platforms: Design Considerations and Performance

Junfeng Li, Sameer G. Kulkarni+2 more|arXiv (Cornell University)|Nov 18, 2019

Peer-to-Peer Network Technologies参考文献 7被引用数 19

ひとこと要約

この論文は、Knative、Kubeless、Nuclio、OpenFaaSの4つのKubernetesベースのオープンソースサーバessプラットフォームを評価し、パフォーマンスおよびオートスケーリングに顕著な影響を与えるアーキテクチャ設計の選択を特定している。RPSおよび同時接続数ベースのオートスケーリングのみでは不十分であり、OpenFaaSおよびKnativeに見られるトラフィック分散の欠陥により、低負荷時において深刻なスループット低下が発生する。特にKnativeでは、不適切なスケーリング動作により1500 RPSではなく200 RPSにまで低下する。

ABSTRACT

Serverless computing is increasingly popular because of the promise of lower cost and the convenience it provides to users who do not need to focus on server management. This has resulted in the availability of a number of proprietary and open-source serverless solutions. We seek to understand how the performance of serverless computing depends on a number of design issues using several popular open-source serverless platforms. We identify the idiosyncrasies affecting performance (throughput and latency) for different open-source serverless platforms. Further, we observe that just having either resource-based (CPU and memory) or workload-based (request per second (RPS) or concurrent requests) auto-scaling is inadequate to address the needs of the serverless platforms.

研究の動機と目的

• オープンソースサーバーヲーストプラットフォームにおけるアーキテクチャ設計の意思決定がパフォーマンスおよびオートスケーリング行動に与える影響を理解すること。
• 複数のプラットフォームにわたるリクエストルーティング、関数ポッドのスケーリング、リソース利用効率におけるパフォーマンスボトルネックを同定すること。
• 実際のワークロードにおけるRPSおよび同時接続数ベースのオートスケーリングメカニズムの限界を評価すること。
• ゲートウェイ、ウォッチドッグ、キューープロキシなどのプラットフォーム固有コンponentが遅延およびスループットに与える影響を調査すること。
• Kubernetesベースのサーバーレスプラットフォームの設計および構成を改善するための実行可能なインサイトを提供すること。

提案手法

• 制御されたワークロードを用いてKubernetesクラスタ上で4つのオープンソースサーバーレスプラットフォーム—Knative、Kubeless、Nuclio、OpenFaaS—を評価した。
• 定常状態およびバーストワークロード下でのパフォーマンスを測定し、スループット（RPS）、遅延、オートスケーリング動作に注目した。
• CPU利用率を用いたKubernetesのHorizontal Pod Autoscaler（HPA）を設定し、複数プラットフォームにおけるリソースベースのオートスケーリングを評価した。
• APIゲートウェイおよびイングレスコントローラーがリクエスト配分に果たす役割を分析し、OpenFaaSおよびKnativeにおける誤ルーティング問題を同定した。
• ワークアラウンド（例：OpenFaaSにおける接続リセット）を無効化することでアブレーションスタディを実施し、パフォーマンス劣化要因を隔離した。
• 関数ポッドにおけるCPUおよびメモリ使用量を測定し、スケーリング効率およびリソースオーバーヘッドを評価した。

実験結果

リサーチクエスチョン

• RQ1 ゲートウェイ、コントローラー、関数ランタイムコンponentにおけるアーキテクチャ的差異が、サーバーレスプラットフォームのベースラインパフォーマンスおよび遅延に与える影響は何か？
• RQ2 RPSベースおよび同時接続数ベースのオートスケーリングメカニズムが独立してワークロード要件を満たせない程度はどの程度で、その結果として生じるパフォーマンスへの影響は何か？
• RQ3 OpenFaaSはHPA設定がなされているにもかかわらず、低同時接続ワークロード下で効果的にスケーリングできないのはなぜか？長期間接続のルーティングが果たす役割は何か？
• RQ4 関数ランタイムの選択（例：Kubelessにおけるリクエストごとのフォーク）がCPU利用率、リクエストドロップ率、オートスケーリングの応答性に与える影響は何か？
• RQ5 キューープロキシやウォッチドッグなどのプラットフォーム固有コンponentがCPUオーバーヘッドおよびオートスケーリング速度に与える影響は何か？

主な発見

• Knativeは低負荷時（9件の同時リクエスト）にオートスケーリングに失敗し、1つの関数ポッドしか維持せず、スループットが1500 RPSから200 RPSに低下する。
• OpenFaaSは、誤ったトラフィック分散のためオートスケーリング下でもスループットの向上が著しく不十分である—長期間接続がすべてのトラフィックを最初の関数ポッドにルーティングし、他のポッドは無効状態のままとなる。
• Kubernetes HPAによるリソースベースのオートスケーリングはプラットフォーム依存の挙動を示す：Nuclioは最も速く（インスタンスを2倍にするまでに40秒）、一方Kubelessはリクエストドロップと高遅延のためスケーリングが著しく劣る。
• オートスケーリングが有効になっても、メモリ使用量は顕著に増加するが、CPU利用率は安定したままであるため、一部のプラットフォームではリソース利用効率が著しく低いことが示唆される。
• APIゲートウェイと関数ポッドの間の相互作用が主要なパフォーマンスボトルネックとなっており、誤ルーティングによりスケールされたインスタンスが未利用状態となる。
• RPSまたは同時接続数ベースのオートスケーリングに依存するだけでは不十分であり、過剰または不足なリソース割り当てを回避するには、ハイブリッドまたはワークロード認識型のスケーリングポリシーが必要である。