status
date
slug
tags
category
type
password
icon
Reference
 
名詞解釋
  • Serverless: 開發者無須自行架設伺服器，只需將程式打包成 Function 再上傳到平台上，平台就會準備好環境短暫執行，結束後就將環境 destroy，以流量計費
  • FaaS: Serverless 的具體實現，知名平台像是 AWS Lambda, Azure Functions, Google Cloud Functions, OpenFaaS(Open Source!)
  • SLO(Service Level Objective): 最低滿足延遲需求的請求數量(i.e. P95 ≤ 200ms ⇒ 100 次呼叫中，有 95 次執行時間 ≤ 200ms)
  • Runtime Metrics: 系統運行 Function 時收集的資料(e.g. CPU Utilization, Memory Utilization, …)
  • Explore / Exploit: ML 中學習與決策中常見的平衡策略
    • Exploit: 根據現有知識，選擇”已知最好”的選擇
    • Explore: 嘗試新選項，看是否會有更好的結果
  • OC(Overcommitted): 超量分配資源
    • 實際情況下，平台會讓多個 Function 共用硬體資源，假設兩個 Function 各自宣稱需要 6GB RAM，但實際運行上通常只需要 2GB RAM，平台可能會選擇共用一個 8GB 的機器 ⇒ Collocation
    • 問題: 如果今天某一支 Function 吃滿資源，會影響到其他 Function 的運行，可能會違反 SLO
  • Vertical Scaling: 調整單一執行個體的資源大小(e.g. CPU, RAM, concurrency, …) 比較: Horizontal Scaling ⇒ 直接增加或減少 Container 的數量
  • Offline Profiling: 在 service 上線前，先跑測試來蒐集資料，模擬真實情況
  • Stateful External Deps: 帶有狀態的外部依賴元件
    • Stateful: 會記住之前發生的事情(e.g. database, cache)
    • External Dependencies: 呼叫外部的 service 或 api
  • Collocation: 將多個 Function 安排在同一個機器或 Container 上運行
    • 優點: 節省資源
    • 缺點: 互相干擾
  • Function-agnostic: 不須知道 function 的內部邏輯與用途，餵給模型一樣可以正常運作 e.g. 不管是什麼 Task，直接觀測 CPU utilization 來判斷 Task 的 workload
  • MRU 原則: Most Recently Used，移除最後使用的對象 比較: LRU ⇒ Least Recently Used，移除最少使用的對象
 
Abstract
  • 問題: FaaS 平台的使用者往往會過度申請資源來避免自己的程式受到硬體的效能瓶頸，導致大量的閒置成本 ⇒ 在節省運算資源以及維持 SLO 之間取得平衡
  • 傳統作法: Offline Profiling
    • 缺點: stateful external deps 的實際表現需要上線之後才知道
    • 之前的調度系統:
      • Owl: 只考慮兩個 Function 之間的 Collocation，實際上可能有多個 Function同時
      • Orion: 直接忽略 Collocation
  • 技術貢獻: Realtime Profiling，用實際運行時的 Metrics 丟進 ML Classifier，來決定 Scheduling Strategy
 
Design
  • Figure 4
      • notion image
      (1) Router(Scheduler): 負責每個 reqeust 的 routing strategy
      (2) Function Instance: 分成 non-OC(保守) 以及 OC(縮小資源) 兩種 instance，每個 instance 會被監控資訊，並將資訊上報給 runtime metrics
      (3) Node Metric Monitor & watchdog: 監控資訊，並將資訊送給 relay
      (4) ML Module: relay 負責批次接收 metrics 的資訊，model 是一個 binary classifier，負責線上更新及預測是否需要 Label
  • Metrics
    • Intra-Container Metrics:
      • CPU utilization: 直接採集自 cgroup
      • memory utilization: 直接採集自 cgroup
      • number of inflight requests: 在 function instance 中紀錄 inflight requests 數量
      • 表現方式(3-D Vector): <CPU, Memo, Inflights>
    • Collocation interference metrics
      • Network:
        • 從 /proc/net 取得 net 與 node 的 receive, transmit 狀態
        • 表現方式(4-D Vector): <NetRx, NetTx, NodeNetRx, NodeNetTx>
      • CPU Cache
        • LLC: Last Level Cache(L3)
        • LLCM: LLC-miss ⇒ 未命中 Cache 的機率
        • 使用 perf stat 工具來監測
        • 表現方式(2-D Vector): <LLCM, NodeLLCM>
    • 共九個 runtime metrics，皆是在運行中可以以低成本取得的資料，可以有效反映 intra-container 和 collocation 所引起的性能變化
    • 監控 container 內部的資訊以及整個 node 的資訊，當 delay 提高時，可以輕易看出到底是 function 本身過於忙碌(container-level)，還是整台機器被其他的 function 占滿(node-level)
  • ML Module
    • 基於 Mondrian Forest(MF) 做 online binary classifier
    • MF 優點: 可快速構建 Decision Tree，適合 online training，常用於 Edge Computing
    • 把每個 request context 標記成是否會違反 SLO(是: positive, 否: negative)
    • Online Stratified Sampling: 保證 balance, 避免 classifier 傾斜
  • Conserve exploration-exploitation Approach
    • 預設使用 non-OC instance 保證穩定性，僅在 Safe Tag 為 1 時會嘗試將某些 instance route 到 OC instance(試看看能否節省資源)
    • 先用 power-of-two choices，隨機採取 個 instance(通常 ), 在查詢開銷極低的情況下取得將近 global optimum 的成果
    • 在這 個 instance 中再使用 Greedy(e.g. MRU, highest confidence, …)，挑出最適合的 instance，如果該次 request 成功並且沒有違反 SLO ⇒ 更新 ML，否則透過把 Label 改成 unsafe，並且觸發 vertical scaling
  • Vertical scaling
    • Continuous and In-place Scaling ⇒ 只調整 maximum concurrency，不用重啟 Container
    • 實現: 維護一個長度為 的 window, 紀錄 window 中超過 SLO 的次數
    • 若 violation ratio > ，代表不滿足 P95 ⇒ 將 max concurrency-1
    • 若 violation ratio < ，代表資源仍有壓縮空間 ⇒ 將 max concurrency+1
    • 效果: 盡量滿足 P95，但不會中斷 service，額外節省 8% memory 之外，讓 scheduler 更勇於探索 OC
      •  
 
實驗
  • 環境
    • Cluster Setup
      • 10 個 AWS EC2 node
      • 1 master node as routing modules(c5.9xlarge)
      • 7 worker nodes as host function (c5.9xlarge, 36vCPU/72GB per node)
      • 1 function dependencies e.g. database(c5.2xlarge, 8vCPU/16GB)
      • 1 request sender(c5.2xlarge, 8vCPU/16GB)
    • Trace(輸入負載)
      • Azure Function Trace
      • 隨機選平日(Day 10)與假日(Day 13)，將一天的 Trace 壓縮到一小時(約 600k calls/hour)
      • 將原 Trace scale down，只保留波動
          • notion image
    • Benchmark
      • 模擬真實世界的 business scenario
          • notion image
      • 初始 concurrency limit=4
    • Baseline
      • Base: non-OC, MRU routing
      • OC: naive OC, MRU routing
      • Orion: profiling
      • E&E: Golgi, disable vertical scaling
      • Golgi: E&E, enable vertical scaling
    • Metrics
      • Performance: P95
      • Resource costs
        • Memory footprint(MBxSec) ⇒ reflect billing
        • VM Running Time ⇒ reflect server workload
    • Procedure
      • 在 Base 環境跑 Trace, 紀錄每個 application 的 P95 作為 SLO baseline
      • 對其他的 baseline 用同樣個 Trace 重複 5 次，使用同樣的 SLO
  • 結果
    • Performance
        • notion image
      • E&E 和 Golgi 幾乎接近 Base
      • OC 和 Orion 在某些 application 會飆高
    • Memory footprint
        • notion image
      • 左圖: OC 節省最大(57% Mem)，但有極大的 latency, Golgi 次之，節省 42% Mem
      • 右圖: 比較 OC 與 Non-OC 的區別，顯示 vertical scaling 有效使 Cost 降低
        • notion image
  • 其他實驗(懶得寫)
    • 將 Golgi 的 router 換成 MRU
    • 將 SLO 放寬兩倍
    • 調 batch size
    • 調 group size
 
Future Work
  • 初期決策偏保守，一開始會 route 到 OC
  • 在大規模 cluster 下取得 metrics 可能會造成 overhead
  • MF 與 stratified sampling 需要持續收集 sample 才會趨於 stable
 
結論
  • 潮棒 der :D
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Relate Posts
JPS 學習筆記
Lazy loaded image
看得見謊言的我，愛上了不說謊的你東、週刊連載被腰斬啦
Loading...
Zixu
Zixu
Welcome to my webstie.
Analytics
Post Count:
228