[論文レビュー] Affinity-aware Serverless Function Scheduling

Giuseppe De Palma, Saverio Giallorenzo+3 more|arXiv (Cornell University)|Jul 19, 2024

Cloud Computing and Resource Management被引用数 2

ひとこと要約

本稿では、サーバーヲス・ファンクション・イン・ア・サービス（FaaS）環境におけるアフィニティに配慮したスケジューリングを可能にする、Apache OpenWhisk向けの宣言的でプラットフォームに依存しない言語拡張であるaAPPを提案する。開発者が、他の関数の実行時存在に基づいて関数を同じ場所に配置するか分離するかを指定できるポリシーを表現できるようにすることで、レイテンシに敏感なおよびセキュリティが重要なシナリオでのパフォーマンスを向上させるとともに、アフィニティを必要としないワークロードでは最小限のオーバーヘッドを発生させる。

ABSTRACT

Functions-as-a-Service (FaaS) is a Serverless Cloud paradigm where a platform manages the scheduling (e.g., resource allocation, runtime environments) of stateless functions. Recent work proposed using domain-specific languages to express per-function policies, e.g., policies that enforce the allocation on nodes that enjoy lower latencies to databases and services used by the function. Here, we focus on affinity-aware scenarios, i.e., where, for performance and functional requirements, the allocation of a function depends on the presence/absence of other functions on nodes. We present aAPP, an extension of a declarative, platform-agnostic language that captures affinity-aware scheduling at the FaaS level. We implement an aAPP-based prototype on Apache OpenWhisk. Besides proving that a FaaS platform can capture affinity awareness using aAPP and improve performance in affinity-aware scenarios, we use our prototype to show that aAPP imposes no noticeable overhead in scenarios without affinity constraints.

研究の動機と目的

• FaaSプラットフォームにおける関数（反）アフィニティ制約のネイティブなサポートの欠如に対処すること。
• 開発者が実行時における関数の共存または分離に基づいてスケジューリングポリシーを表現できるようにすること。
• 既存のFaaSランタイムにシームレスに統合できる宣言的でプラットフォームに依存しない言語拡張を設計すること。
• aAPPのパフォーマンスへの影響を、アフィニティ対応および非アフィニティの両シナリオで評価すること。
• aAPPが複雑なスケジューリングポリシーを可能にしつつ、実行時オーバーヘッドを最小限に抑えることの妥当性を実証すること。

提案手法

• 既存のAPP言語に、関数アフィニティおよびアンチアフィニティ制約を表現するための新しい構文を拡張する。
• aAPPポリシーに基づいて、関数がワーカーに割り当て可能かどうかをチェックする線形時間のスケジューリングアルゴリズムを設計する。
• Apache OpenWhisk上にaAPPベースのプロトタイプを実装し、ポリシー評価をスケジューリングパイプラインに統合する。
• 各関数ごとに宣言的構文でポリシーを定義し、ターゲットワーカー上で他の関数の必須または除外存在を指定する。
• マルチコントローラー環境におけるスケジューリングレースを回避するために、集中型スケジューラーを採用する。
• 7つのベンチマークを用いてプロトタイプを検証し、パフォーランスオーバーヘッドを測定するために、vanilla OpenWhiskと比較する。

実験結果

リサーチクエスチョン

• RQ1 aAPPは、データベース接続を共有する関数を同じ場所に配置するなど、FaaSレベルでのアフィニティ対応スケジューリングポリシーを効果的に表現できるか？
• RQ2 Apache OpenWhiskへのaAPPの統合により、非アフィニティシナリオで測定可能なパフォーマンスオーバーヘッドが生じるか？
• RQ3 aAPPベースのスケジューリングは、計算集約的関数とのリソース競合を回避するなど、アフィニティ対応ユースケースでパフォーマンスをどのように向上させるか？
• RQ4 aAPPは実行時に効率的に評価可能であり、スケーラビリティと低レイテンシを確保できるか？
• RQ5 実世界のFaaSワークロードにおける（反）アフィニティ制約は、関数スケジューリングにどのような影響を及ぼすか？

主な発見

• aAPPベースのプロトタイプは、FaaSスケジューリングにおいて（反）アフィニティ制約を正常に強制し、アフィニティ対応シナリオでのパフォーマンスを向上させ、関数間レイテンシとリソース競合を低減した。
• 非アフィニティワークロードでは、aAPPによるオーバーヘッドは最小限であり、7つのベンチマークすべてで測定可能な閾値未満のパフォーマンス劣化が確認された。
• スケジューリングアルゴリズムは、ワーカー数およびスクリプト長に対して線形時間で動作し、スケーラビリティを確保した。
• プロトタイプは、FaaSレベルでのアフィニティスケジューリングが、VM/コンテナ再利用を損なわず、インfraストラクチャ抽象化の漏洩を引き起こさずに実現可能で効率的であることを示した。
• 評価により、aAPPはパフォーマンスを損なわず、表現力があり安全かつ効率的なスケジューリングポリシーを可能にすることが確認された。
• 本研究は、aAPPを他のFaaSプラットフォームに統合する可能性を示しており、初期段階でFunLessに対しても対応が拡張されている。