AWS AutoScaling的一個ScaleDown政策問題以及解決方法

1. AWS AutoScaling簡介

AutoScaling是AWS的一個重要服務，用來彈性的自動建立（ScaleUp）或者删除（ScaleDown）EC2虛拟機，并且Scale的政策完全是使用者自定義的、或者是基于虛拟機健康狀态檢查結果、或者是按照計劃來實施Scale政策。

例如，考慮如下的業務場景，系統部署在EC2虛拟機上，所有任務分發均是通過AWS SQS來完成的，即請求按照特定格式發送到SQS指定隊列中，而EC2虛拟機上運作的系統從這個隊列讀取消息來運作任務。

借助于AutoScaling，我們可以簡單的設定下面的伸縮政策：

1）確定至少有2台EC2虛拟機正常提供服務；

2）ScaleUp：當SQS隊列中的消息個數超過20個的時候，就自動建立一台或者多台虛拟機，ScaleUp政策執行之後CoolDown一段時間再次檢查ScaleUp政策。當然建立該虛拟機的鏡像需要提前預制好，確定虛拟機建立之後OS運作的時候，我們的業務系統能夠自動運作起來。

3）ScaleDown：當SQS隊列中的消息個數小于20個的時候，自動删除一台虛拟機。

說明：上面的例子隻是簡單的示範了AutoScaling的使用方式，可以借助于CloudWatch來實作更強大更精細的AutoScaling配置。

更多介紹詳見AWS AutoScaling官方文檔：http://aws.amazon.com/autoscaling/

2. AWS AutoScaling的ScaleDown政策存在的問題

對于一般的同步請求業務系統而言，AutoScaling的功能是比較強大的，借助于它，我們可以友善的實作業務的彈性自動伸縮。

但是，在使用過程中，發現AWS的AutoScaling（下文簡稱AmazonAS）存在一個問題，就是對于長時間運作的業務而言，比如一個視訊轉碼請求需要幾個小時才能處理完的，任務運作的時間幾乎和視訊時長一樣長。在這種情況下，AmazonAS的ScaleDown政策就會出現一個問題：如果在一個虛拟機正在運作任務的時候，AmazonAS根據CloudWatch資料觸發了ScaleDown政策，那麼很有可能會删除掉該虛拟機，進而引起業務資料丢失或混亂。由此可見，AmzonAS并不适合于我們的業務特性，是以有必要仿照AmazonAS來實作一套定制化的AutoScaling來滿足我們的業務需求。

3. 解決方法

3.1 ScaleUp政策

基本類似AmazonAS的ScaleUp政策來實作，或者說是它的簡化版本。 通過監控SQS中指定隊列的消息個數來自動建立一定數量的虛拟機，來運作隊列中的任務消息，建立虛拟機的同時發送郵件到指定郵箱。

3.2 ScaleDown政策

由上文介紹的AmazonAS存在的問題或不足，我們就不能簡單的根據SQS中消息個數來删除虛拟機了。我們的政策是讓虛拟機内部自動根據任務運作情況來自我删除。

實作方式如下： 在虛拟機内部預制好檢查任務運作狀态（我們是通過檢測日志來實作的）的腳本，如果發現系統空轉一段時間之後就執行關機指令，進而觸發AWS EC2虛拟機的Shutdown Behavior進行自我删除。備注：這就要求建立虛拟機的時候設定Shutdown Behavior為Terminate，即删除。

3.3 流程步驟

簡要的流程圖如下所示：

1） 首先，AutoScaling啟動一個線程，進入循環；

2）在目前循環周期内，根據SQS中消息個數進行ScaleUp政策檢查，如果滿足政策條件，則調用EC2建立虛拟機的API建立一台或者多台虛拟機，并将Shutdown Behavior設定為Terminate，虛拟機參數會在AutoScaling中進行預先配置。如果建立了虛拟機則會根據預制的郵件清單發送郵件通知，并且CooleDown一段時間。

3）在目前循環周期内，ScaleUp完成之後就進行ScaleDown政策檢查，真正運作ScaleDown政策的機制是在EC2虛拟機裡面通過cron任務來執行的，在AutoScaling中僅僅是判斷哪些虛拟機在目前循環周期内被删除了，如果檢測到有虛拟機被删除掉，則發郵件通知。

4）ScaleUp和ScaleDown在目前周期全部執行完畢之後，等待一段時間，然後重新進入下一次循環周期。

3.4 代碼實作

使用Java開發了該系統，并且運作在tomcat容器中，所有代碼和腳本全部公開在github上，位址為：https://github.com/yuanhuan2005/autoscaling.git。

3.4.1 代碼結構

代碼位于autoscaling/src/main/java/com/tcl/autoscaling下面：

awsec2    #EC2建立新的虛拟機接口 awsses #SES接口，用于發郵件 awssqs #SQS接口，用于操作SQS中的消息 common #公共方法 listener #監聽器 mail #發郵件接口 transcode #執行業務Scale的核心代碼

3.4.2 配置檔案

配置檔案位于autoscaling/src/main/resources/autoscaling.propertites中：

awsAccessKeyId=YOUR_ACCESS_KEY #AWS的access key id         awsSecretAccessKey=YOUR_SECRET_KEY #access key對應的secret key           queueMessageCheckDuration=600 #隊列中的消息檢查周期，機關：秒           transcodeMonitorQueueURL=https://sqs.us-east-1.amazonaws.com/xxxxxxxxxxxxx/transcoderQueue #隊列位址           transcodeMonitorQueueTotalNumberThreshold=1 #隊列消息個數的閥值           transcodeInstanceLanchNumber=1 #啟動的虛拟機個數           transcodeImageIdToLanchInstances=ami-88888888888 #啟動虛拟機使用的鏡像id           transcodeRegion=us-west-2 #虛拟機在哪個region建立           transcodeAvailabilityZones=us-west-2a,us-west-2b,us-west-2c #虛拟機在上面的region中哪個可用分區中建立           transcodeMaxInstancesNum=20 #建立虛拟機的最大個數           transcodeInstanceType=m1.xlarge #虛拟機規格           transcodeKeyPair=transcoder_for_asg #虛拟機keypair，用于ssh登入           transcodeSecurityGroupId=sg-f321c896 #虛拟機所在的安全組           transcodeInstanceName=test #虛拟機名稱，便于管理           transcodeCoolDownTimeInSeconds=1200 #cooldown時間，機關：秒           [email protected];[email protected];[email protected] #email清單，多個email用分号分割

3.4.3 shell腳本

在EC2虛拟機中需要安裝如下的腳本，預設安裝路徑是/home/ec2-user/bin/，如有變化可對應修改。

腳本解釋如下：

check_dispatcher_status.sh #檢查運作狀态。如果空轉，則将idle_number的數字加1，當idle_number達到配置的上限時執行關機指令進行自我删除；如果沒有空轉即正在運作任務，則将idle_number清零，等待進入下次檢查周期。 idle_number #記錄空轉次數的檔案 dispatcher #注冊為系統服務，以便可以用service指令進行管理，檔案路徑：/etc/init.d/dispatcher restart_tomcat.sh #重新開機tomcat的腳本 start_tomcat.sh #啟動tomcat的腳本 status_tomcat.sh #檢查tomcat運作狀态的腳本 stop_tomcat.sh #停止tomcat的腳本