13 ポイント 投稿者 xguru 2023-10-26 | まだコメントはありません。 | WhatsAppで共有
  • Metaが社内で利用しているFaaSプラットフォーム
  • 数十のデータセンターリージョンに分散した10万台以上のサーバーで、毎日数兆件の関数呼び出しを処理
  • AWS Lambda、Azure Functionsより効率的だと主張し、XFaaS: Hyperscale and Low Cost Serverless Functions論文で公開

興味深い統計と示唆

  • 論文の核心は、ソフトウェアでハードウェア利用を最適化することでサーバーレスの性能を改善できるという点
  • MetaはServerless Functionsのスタートアップオーバーヘッドの無駄を認識し、すべてのワーカーが起動オーバーヘッドなしにすべての機能を即時実行できるUniversal Workerをエミュレートすることを目標としている
    • この規模ではハードウェアコストが莫大であり、ごく小さな比率でも重要
  • XFaaSはユーザー対面ではない機能にのみ使われる。サーバーレス関数は、ユーザー対面機能に一貫して使うには可変レイテンシが大きすぎる
  • XFaaSのクライアントは非常に急激な形で関数呼び出しを実行する。ピーク需要はオフピーク需要の4.3倍に達する
    • 一例として、15分以内に2,000万件の関数呼び出しがXFaaSに投入されることもある
    • Metaは急増する関数にもパターンがあることを発見し、これを活用してワークロード内の急増する関数をより予測可能にした

XFaaSはどれほど効率的か?

  • 業界平均を大きく上回る66%の日次平均CPU使用率を達成
  • 時間(関数の遅延を通じて)と空間(負荷の低いデータセンターへ送ることで)を使って負荷を効率的に分散

    Metaは多くの機能を、負荷とコストを予測できる利用の少ない時間帯に予約する方向へ継続的に移行している

  • 社内クラウドであるため、Metaは同一プロセスで複数ユーザーの複数機能を実行するなど、さまざまな独自最適化を行える
  • ほとんどの関数は1秒以内に実行されるが、すべてがそうではない

XFaaSで解決した問題

  • 問題: 長いコールドスタート時間
    • コンテナを早く終了しすぎると、次の呼び出しのためにコンテナ全体を再初期化しなければならない
    • コンテナを遅く終了しすぎると、アイドル状態のまま残って貴重な計算資源を無駄にする
    • 解決策: XFaaSはJITコンパイルのような手法を使い、すべてのワーカーがすべての関数を即時実行できるよう近似(approximate)する
  • 問題: 深刻な負荷分散
    • オーバープロビジョニングによって追加のハードウェアコストが発生し、逆に不足するとシステムが遅くなる
    • 解決策: XFaaSはdelay-tolerantな関数実行を利用の少ない時間帯まで遅らせ、世界中のデータセンターリージョンへ関数呼び出しを分散する
  • 問題: ダウンストリームサービスへの過負荷
    • 例: ユーザー対面ではない関数の呼び出し急増によって、ユーザー対面のオンラインサービスが停止したことがある
    • 解決策: XFaaSはTCP輻輳制御に似たメカニズムを用いて関数実行を調整する

一般的なFaaSとの比較(AWS Lambda、Google Cloud Functions、Azure Functions)

  • パブリッククラウドFaaSは関数実行を単一のデータセンターリージョンに制限する一方、XFaaSは関数呼び出しを世界中に分散でき、ロードバランシングを改善できる
  • FaaSプラットフォームはハードウェア利用率を見落としたままレイテンシ削減を優先しがちだが、XFaaSはハードウェア利用率と関数呼び出しのスループットに重点を置く
  • パブリッククラウドにも役立ちうるXFaaSの技術
    • 呼び出し側が関数実行の開始時刻を指定できるようにする
    • 関数オーナーが完了期限に関するサービスレベル目標(SLO)を設定できるようにする(SLOが緩ければ、より良い実行時間のために遅延可能)
    • 関数オーナーが関数に重要度レベルを指定できるようにする
  • パブリッククラウドはXFaaSのように複数ユーザーの機能を同一プロセスで実行することはできないが、大規模クラウド顧客は仮想プライベートクラウドでXFaaSのアプローチを採用できる可能性がある
  • 少数のMetaチームがXFaaS容量のかなりの部分を消費している。パブリッククラウドを使う同様の大規模顧客もXFaaS戦略の恩恵を受けられるだろう

Background: 前提と要件

  • 前提
    • 核心的なインサイトは、XFaaSの機能の大半が自動化ワークフローによってトリガーされ、遅延しても問題ないということ
    • これによりXFaaSは、時間(機能を遅らせること)と空間(負荷の低いデータセンターへ送ること)にまたがって負荷を分散できる
    • XFaaSはPHP、Python、Erlang、Haskellのランタイムと、すべての言語向けの汎用コンテナベースランタイムをサポート
    • 関数には、関数名、引数、ランタイム、重要度、実行開始時刻、実行完了期限、リソース割り当て量、同時実行制限、再試行ポリシーなど、開発者が設定できるさまざまな属性があり、実行完了期限は秒単位から24時間まで設定可能
    • XFaaSは地域ごとにハードウェア容量が異なるため、ロードバランシングではこれを考慮する必要がある
  • ワークロード種別
    • Metaは3種類のワークロードをXFaaSでサポートしている
      • キュートリガー関数
      • イベントトリガー関数(データウェアハウスおよびデータストリームシステムのデータ変更イベント)
      • タイマートリガー関数(事前設定したタイミングで自動実行)
    • XFaaSは、非ユーザー対面機能である非同期レコメンデーションシステム、ロギング、生産性ボット、通知などに使われる

全体アーキテクチャ

(この部分は長すぎて、論文の内容をほぼそのまま移したものなので省略します。)

まだコメントはありません。

まだコメントはありません。