一千萬個為什麽

搜索

如何在多租戶環境中縮小規模?



AWS中的雲環境允許用戶親自管理多租戶,經典示例是容器編排器,如ECS或Kubernetes。

當你有兩個服務時,需要另一個cpu的內存,然後把它們放在一個集群中。然後擴大規模相對較小。每當您需要更多容量時,請添加更多容量。 cpu 由於EC2容量是指cpu和內存中的單位。

Scaling up based on a single metric can very easily achieved using CloudWatch Alarms.

縮小比例時,為了降低成本,需要考慮內存和CPU的限制,並且不要讓兩者中的任何一個降到要求的數量以下。

由於不幸的是,CloudWatch警報不允許使用布爾邏輯或考慮多個指標。

為自動縮放組實現縮小容量的好方法

轉載註明原文: 如何在多租戶環境中縮小規模?

一共有 2 個回答:

自動縮放是機器學習的一個很好的例子

這是一個難以做好的難題。

你真正想要的是像你的EC2基礎設施的Nest Thermostat。

有(前述)資源需求/限制的多個維度。

  • CPU
  • 存儲器
  • 磁盤空間
  • 磁盤IO
  • 網絡IO
  • 並發/延遲/隊列深度

有多種需求指標(除上述之外)。

  • 並發唯一訪問/會話
  • 每次訪問
  • 頁面
  • 互動率/互動功能使用率

隨著時間的推移,需求變化有多種常見模式。

  • 每日用戶需求周期
  • 每周用戶需求周期
  • 每月...
  • 年度...
  • 特殊活動/天
  • DDoS加載
  • 媒體/營銷曝光流量高峰

有多個財務決策因素。

  • 收入是否與流量成比例?怎麽樣? (您需要保守多少?)
  • 是否存在控制成本(交易成本,限額)?
  • 縮放的成本模型是什麽? (管道中的東西一起縮放,負載均衡集群中的東西獨立縮放)

不久之後,如果您嘗試手動優化手動選擇的功能,您會遇到一個技術債務怪獸,可能比您網站中的任何其他邏輯更復雜。如果您在謹慎的方面犯錯(大幅度),亞馬遜會賺更多的錢,所以他們的工具可能永遠不會接近您想要的。

Instead, choose an architecture/technology stack that can grow/scale so you don't have to get it exactly right the first time. Then pick a few factors which you think are obvious. Then try to come up with a way to sort multiple representative possibilities in order of preference. Then collect some real world data covering all those points. If you're lucky, a simple obvious hand-coded solution will jump out at you from looking at the data. If not, code up something that will give you an approximate model f(x1,x2,x3,x4) --> y * app nodes, using an appropriate algorithm.

我敢打賭,你並不認為這將會是如此有趣!

為了能夠對ECS信心增長,有幾個策略:

  • 創建一個跟蹤兩個指標中較大者的第三個自定義指標。例如,如果CPU分配為60%,內存分配為70%,則應將該度量設置為70%。
  • 選擇兩個資源(CPU或內存)中的一個,並且始終為每個容器分配比例高於其他資源的百分比。通過這種方式,您將始終在優先資源不足之前達到您的首選資源,並且您不必擔心擴大或縮小。雖然這是最簡單的解決方案,但顯而易見的缺點是無法優化可能是CPU或內存密集型服務,並且最終可能會浪費資源。
  • 在不使用CloudWatch指標的情況下進行自動調整。諸如 https://github.com/ameir/ECSpander 之類的工具可用於提供幫助。

Kubernetes不使用CloudWatch指標進行擴展,它通過內部機制設置ASG所需的實例數來管理擴展,因此不受您描述的問題的影響。