+86 13541016684Mon. - Fri. 10:00-22:00

AWS AutoScaling的一个ScaleDown策略问题以及解决方法

AWS AutoScaling的一个ScaleDown策略问题以及解决方法

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 流程步骤

简要的流程图如下所示:

wKiom1VAmlyhLtnYAAJLkj1REKk461

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时间,单位:秒
notificationEmails=user1@example.com;user2@example.com;user3@example.com #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的脚本

这些脚本的调用关系见下图所示:

wKioL1VAm8WzKU8CAAIw-nyprPM110