如何自動縮放EMR任務實例

Question

我將EMR與任務實例組一起用作競價型實例。 我想始終保持最小數量的任務實例。 就是說，每當EMR由於出價高於我們設置的價格而終止任務實例時，我的應用程序都應以較低的出價啟動另一個任務實例。

我的研究

1. 使用Cloudwatch通知何時違反閾值，並自動縮放任務實例。 但是根據研究，EMR中沒有自動縮放的概念。
2. 使用Cloudwatch，並在閾值中斷時通知SQS，並且只有一項服務始終在使用和擴展任務實例。

問題

1. EMR中是否存在任何自動縮放功能？ 如果可以的話，那么我的工作將減少為僅設置閾值，並執行相應的擴展任務實例操作。
2. 如果您有其他方法可以解決此問題，請提出建議。

Answer 1

現貨價格如何運作

當以現貨價格啟動Amazon EC2實例時（包括從Amazon EMR啟動時），如果當前現貨價格低於提供的買入價 ，則實例將啟動。 如果現貨價格上漲到高於買入價，則實例終止。 實例僅按當前現貨價收費 。

因此，不需要以“稍高的出價”啟動新的現貨實例的邏輯。 該實例將始終按照當前的現貨價格收費 ，因此只需出價與您願意為該現貨實例支付的價格一樣高即可。 您將支付的價格低於現貨價格（最高！），或者您的實例將被終止，因為價格已經超出了您願意支付的價格（在這種情況下，您不想為該實例支付“稍高的價格”） ）。

如果您希望一直“保持最少的任務實例數量”，則要么支付正常的EMR費用（這意味着實例不會被終止），要么為現貨實例出價特別高的價格，例如2倍正常價格 。 是的，您有時可能會為實例支付更高的價格，但是平均而言，您的價格會很低。

如果您想偷偷摸摸，可以出價EC2實例的正常價格，然后，如果實例終止，則啟動更多任務節點而不使用現貨定價。 這樣，您的實例將不會被終止，您所支付的費用也不會超過正常的EC2價格。 但是， 當現貨價格下降時 ， 您將不得不終止並替換這些實例 ，否則您將付出太多。 這就是為什么最好在您的現貨實例上提供高出價的原因。

底線：使用現貨定價，但要價高。 大多數時候您會得到一個不錯的價格。

Answer 2

AWS EMR沒有可用的自動縮放選項。 但是您可以使用AWS SQS進行變通並集成Autoscaling。 這是您可以集成的粗略圖片。

1. 使用競價型實例啟動EMR集群。
2. 設置一個SQS隊列並創建3個觸發器，一個用於CPU閾值，第二個用於EC2競價型實例終止通知，第三個用於更改競價型實例報價。
3. 因此，如果CPU使用率增加，SQS將觸發一個事件以啟動新實例到集群，如果有現貨實例終止通知，則SQS將觸發以啟動另一個實例以平衡負載並發送事件以更改出價以啟動另一個現貨。實例。 （這只是一個粗略的草圖，但我想您會理解邏輯的。

這是AWS SQS自動縮放的指南。

https://docs.aws.amazon.com/autoscaling/latest/userguide/as-using-sqs-queue.html

Answer 3

正如已經正確指出的那樣，EMR API提供了所有必要的要素，以1）收集監視數據，以及2）以編程方式向上和向下擴展群集。

基本上，有兩個主要選項可為EMR群集實現自動擴展：

1. Autoscaling Loop（自動縮放循環）：在服務器上運行並持續監視群集當前負載的進程。 可以定期收集性能指標（內存，CPU，I / O等）並將其存儲在數據庫中。 將根據性能指標評估自動擴展規則，並根據需要擴展或縮減集群的任務節點。
2. 基於事件的自動縮放：使用CloudWatch指標（例如EMR或EC2的指標），您可以以編程方式定義在某些條件下觸發的觸發器（例如，如果所有節點的平均CPU利用率超過80％，則添加節點）。

兩種選擇都有其優點和缺點。 選項2的主要優點是它是一種無需服務器的方法（不需要運行您自己的服務器）。 另一方面，選項1確實需要服務器，但因此具有更多的控件來自定義擴展規則的邏輯。 而且，它允許保留可伸縮決策歷史記錄的可搜索記錄。

您可以看一下Atmissian開發的EMR自動縮放框架Themis 。 Themis實現了上面的選項1中討論的自動縮放循環。 當前的功能包括主動和被動自動縮放，對點/按需任務節點的支持，它帶有Web UI，並且該工具易於配置。

Answer 4

我有一個類似的問題，我想分享一個可能的選擇。 我編寫了一個Java工具來在處理過程中動態調整EMR集群的大小。 它可能會幫助您。 在以下位置查看：

http://www.lopakalogic.com/articles/hadoop-articles/dynamically-resize-emr/

源代碼在Github上可用