{"id":439195,"date":"2017-02-14T11:47:34","date_gmt":"2017-02-14T11:47:34","guid":{"rendered":"https:\/\/exotel.com\/id\/?post_type=blog&p=439195"},"modified":"2023-08-25T13:06:34","modified_gmt":"2023-08-25T13:06:34","slug":"autoscaling-aws-exotel","status":"publish","type":"blog","link":"https:\/\/exotel.com\/id\/en\/blog\/autoscaling-aws-exotel\/","title":{"rendered":"Auto Scaling on AWS"},"content":{"rendered":"\n

Exotel is growing faster than it ever has. We now have reached a phase where we handle more than 4 million phone calls per day and this number only keeps growing!  A few months ago we decided to work on our technical debt by overhauling some of our DevOps practices. In this post, we talk about the problems we faced while re-architecting bits of our infrastructure and the approach we took to address them. Our hope is that people can use some of our learnings and re-use some of the code we wrote<\/a><\/span>, to minimize the time and effort required to set up an auto-scaling infrastructure on Amazon AWS.<\/span><\/p>\n

\"\"<\/h3>\n

Getting Started<\/h3>\n

Here’s how things worked earlier – we’d bake service-based AMIs, then manually update the codebase and make other changes while adding new machines behind the ELBs. This greatly affected the rate at which we could add instances or push\/revert code\/environment changes. Besides, there was always a scope for human errors because the whole process was manual. We would usually add instances when we anticipated higher volumes or just observed a high load average across the instances.<\/p>\n

We started off at the sidelines – setting up a build pipeline and storing artifacts on S3. This eliminated human errors while updating\/reverting code.<\/p>\n

With builds formalized, we needed to formalize deployments. It’s tricky because there are several ways of doing it and there’s no one-size-fits-all solution. We experimented with a bunch of different stuff. Pre-baked or vanilla AMIs? wget+unarchive or rsync? More machines or larger machines? Eventually, what worked best for us was to go with semi-baked AMIs that contained the packages that took too long to install. Everything else would be taken care of by Ansible.<\/p>\n

Build pipeline and deployment<\/h3>\n

We used Jenkins to set up a build pipeline. The Ansible scripts and the actual code of the services have different pipelines.<\/p>\n

Each service has a Jenkins job which builds the project and uploads the build artifacts to S3.<\/p>\n

#!\/bin\/bash\r\n\r\ncd $WORKSPACE\r\naws s3 cp s3:\/\/build\/$ARTIFACT\/prod\/latest.txt RELEASE\r\nif [ \"$?\" -eq 0 ]; then\r\n    VERSION=$(( `grep VERSION RELEASE | cut -d'=' -f2` + 1 ))\r\nelse\r\n    VERSION=1\r\nfi\r\necho \"MODULE=$ARTIFACT\r\nVERSION=$VERSION\r\nBUILD=$BUILD_NUMBER\r\nGIT_COMMIT=$GIT_COMMIT\r\nTIMESTAMP=$BUILD_TIMESTAMP\" > RELEASE\r\nrm -rf $ARTIFACT.tar\r\ntar cf $ARTIFACT.tar obelix commonix RELEASE --exclude=\"*\/.git\"\r\naws s3 cp $ARTIFACT.tar s3:\/\/build\/$ARTIFACT\/prod\/$ARTIFACT-${VERSION}.tar --storage-class REDUCED_REDUNDANCY --sse AES256\r\naws s3 cp $WORKSPACE\/RELEASE s3:\/\/build\/$ARTIFACT\/prod\/latest.txt --storage-class REDUCED_REDUNDANCY --sse AES256<\/pre>\n
This Jenkins job takes the git branch to be used as a parameter. This allows us to deploy patches by forking a patch branch based out of “release” branch, applying our patch and then deploying the patch branch to production.<\/p>\n
\"Jenkins\"<\/p>\n
This newly created build is considered to be the “latest” build. <\/span><\/p>\n
When an ASG cluster scales out, the instance is configured with the “latest-stable” build version of the service.<\/p>\n
There is another Jenkins job for each service to promote any of it’s builds to “latest-stable”.<\/p>\n
#!\/bin\/bash\r\n\r\nset -e\r\nif [ \"latest\" == \"$RELEASE_VERSION\" ]; then\r\n\taws s3 cp s3:\/\/build\/$ARTIFACT\/prod\/latest.txt RELEASE\r\n    GIT_COMMIT_ID=`grep GIT_COMMIT RELEASE | cut -d'=' -f2`\r\n    cd $WORKSPACE\r\n    git config user.email \"XXX@yyy.GIT_COMMIT\"\r\n  \tgit config user.name \"Demo user\"\r\n    git tag -d $GIT_TAG_NAME || echo \"Tag doesn't exist. Creating one\"\r\n    git push origin :refs\/tags\/$GIT_TAG_NAME || echo \"Tag doesn't exist. Creating one\"\r\n    git tag -a $GIT_TAG_NAME -m \"$GIT_TAG_NAME\" $GIT_COMMIT_ID\r\n    git push --tags\r\n    aws s3 cp s3:\/\/build\/$ARTIFACT\/prod\/latest.txt s3:\/\/build\/$ARTIFACT\/prod\/latest-stable.txt --storage-class REDUCED_REDUNDANCY --sse AES256\r\nelif [[ $RELEASE_VERSION =~ ^[0-9]+$ ]]; then\r\n\taws s3 cp s3:\/\/build\/$ARTIFACT\/prod\/$ARTIFACT-$RELEASE_VERSION.tar $ARTIFACT-$RELEASE_VERSION.tar\r\n    if [ \"$?\" -ne 0 ]; then\r\n        echo \"ERROR: s3:\/\/build\/$ARTIFACT\/prod\/$ARTIFACT-$RELEASE_VERSION.tar does not exist.\"\r\n        exit 1\r\n    else\r\n        rm -rf $ARTIFACT-$RELEASE_VERSION\r\n        mkdir $ARTIFACT-$RELEASE_VERSION\r\n        cd $ARTIFACT-$RELEASE_VERSION\r\n        tar xf ..\/$ARTIFACT-$RELEASE_VERSION.tar\r\n        GIT_COMMIT_ID=`grep GIT_COMMIT RELEASE | cut -d'=' -f2`\r\n    \tcd $WORKSPACE\r\n    \tgit config user.email \"xxx@yyy.com\"\r\n  \t\tgit config user.name \"Demo user\"\r\n    \tgit tag -d $GIT_TAG_NAME || echo \"Tag doesn't exist. Creating one\"\r\n    \tgit push origin :refs\/tags\/$GIT_TAG_NAME || echo \"Tag doesn't exist. Creating one\"\r\n    \tgit tag -a $GIT_TAG_NAME -m \"$GIT_TAG_NAME\" $GIT_COMMIT_ID\r\n    \tgit push --tags\r\n        aws s3 cp $ARTIFACT-$RELEASE_VERSION\/RELEASE s3:\/\/build\/$ARTIFACT\/prod\/latest-stable.txt\r\n    fi\r\nelse\r\n\techo \"Invalid release number. Please specify valid one\"\r\n    exit 1\r\nfi<\/pre>\n
Either the latest build or a specific build version of that service can be made the stable version. When making a particular build as “latest-stable”, we also tag the most recent commit ID of the branch in our git repository so that we can track the version of code running in production.<\/p>\n
\"Jenkins-1\"<\/p>\n
Deploying code to a specific instance or an entire ASG cluster can be done by choosing the relevant options from a Jenkins job –<\/p>\n
\"Jenkins<\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
This build internally uses <\/span>EC2 external inventory script<\/span><\/a> to get the IPs of the instances of the ASG to which the deployment has to be done. <\/span>Here<\/span><\/a> is the script triggered by the above Jenkins job.<\/span><\/p>\n
Auto Scaling<\/h3>\n
Breaking from our earlier bad practice of using the AWS management console to configure the infrastructure, we decided to use <\/span>Terraform<\/span><\/a> to make sure that the infrastructure set up is codified and versioned. As <\/span>explained<\/span><\/a> by Netflix about the lessons they learned from their auto-scaling implementation, we scale up early and scale down slowly. At steady state, every web server cluster has exactly one On-Demand m4.large instance and one or more m4.large Spot instances.<\/span><\/p>\n
We use Spot instances very heavily. Spot instances are around 80% cheaper than on-demand instances of the same configuration. We set bid prices for Spot instances to be higher than the price of the On-Demand instance of the same configuration. In effect, the Spot instances would almost never be terminated as it is unlikely for the price of the Spot instances to be greater than the price of the corresponding On-Demand instance. AWS provides a way wherein a warning is triggered two minutes before the spot instance would be terminated when the current Spot price rises above our bid price (<\/span>Spot Instance Termination Notice<\/span><\/a>). We have set up a <\/span>cron job<\/span><\/a> which polls this endpoint every 5 seconds. If it learns that the instance is scheduled for termination, we increase the desired count of the corresponding On-demand cluster by one. Thus, even in the case when spot instances are terminated abruptly, there will not be a disruption of the service.<\/span><\/p>\n
Setting up the scaling policies was trickier than we expected. We tried out various combinations of scaling policies before settling down on the one that worked best for us. This is what we finally ended up with –<\/span><\/p>\n
\"obelix-appengine-scaling-policies\"<\/p>\n
 <\/p>\n
\"obelix-appengine-scaling-policies-ondemand\"<\/p>\n
Most of our web server clusters are currently on Apache. We found that 50% CPU utilization over 5 minutes to be a safe threshold above which the cluster had to be scaled up. To be able to handle sudden spikes in traffic another scaling policy is set up to scale out when CPU utilization of spot cluster is more than 85% over two consecutive 1 minute periods. The scale out policy for the On-demand cluster has a higher CPU utilization threshold than that of the Spot cluster. This is because we assume that On-demand instances will be needed only if Spot instances are not being spawned for some reason. <\/span><\/p>\n
We noticed that AWS’ default scale down policies don’t work well. Though an option to specify the “Seconds to warm up after each step” is provided, a scale-in activity is triggered every minute. This results in cluster scaling in too aggressively, thereby not having enough capacity at times. Instead “Simple Scaling policy” works as expected for scaling down wherein “Seconds before allowing another scaling activity” can be specified. We remove 10% of the instances of the cluster when the CPU utilization of the cluster is less than 30% for 10 consecutive periods of 60 seconds.<\/span><\/p>\n
The ASG is associated with a target group. The target group is in turn associated with an Application Load Balancer (ALB). The instances are in a private subnet and they only accept requests on port 80 from the corresponding ALB. The ALB is associated with a public subnet and accepts requests on both ports 80 and 443 from everywhere. SSL termination is done only at the ALB.<\/span><\/p>\n
When an instance is spawned from an auto-scaling group, the user data is set to download a setup script from S3.<\/span><\/p>\n
#!\/bin\/bash\r\n\r\nSERVICE=obelix-appengine\r\nS3BUCKET=\"s3:\/\/build\/deploy-scripts\/prod\"\r\n\r\nif [ -z $ANS_VERSION ]; then\r\n    ANS_VERSION=latest-stable\r\nfi\r\nif [ -z $VERSION ]; then\r\n    VERSION=latest-stable\r\nfi\r\n\r\naws s3 cp ${S3BUCKET}\/${SERVICE}.sh obelix-appengine.sh\r\nchmod +x obelix-appengine.sh\r\n.\/obelix-appengine.sh $ANS_VERSION $VERSION<\/pre>\n
This script<\/span><\/a>, in turn, downloads the “latest-stable” version of the ansible scripts and the service code or binary from S3. The script then executes the ansible playbook of the service to configure the newly launched instance. The last step of the ansible playbook on successful execution is to copy a health check file into the right location. Thus after the instance has been fully set up, the instance is brought into service after the target group’s health check passes.<\/span><\/p>\n
Logging and Monitoring<\/h3>\n
We still had two things to figure out – logging and monitoring. When instances are spawned and terminated dynamically depending on traffic, we needed to figure out a way to ship logs out of the machines and dump them in a centralized location. We tried out Filebeat and Heka for shipping but eventually settled on good old rsyslog, which ships logs to a Kafka cluster. The log messages are later consumed from Kafka and indexed in ElasticSearch.<\/p>\n
As far as monitoring is concerned, the major problem was the maintenance of dynamic inventory in Nagios. Since we were okay with a short delay in adding new hosts to monitoring, we decided to poll for ASG changes every few minutes and <\/span>update the hosts <\/span><\/a>in the monitoring config.<\/span><\/p>\n
We created a dashboard on <\/span>Grafana<\/span><\/a> for each web server cluster with metrics from AWS Cloudwatch to visualize the status of the cluster –<\/span><\/p>\n
\"Grafana<\/p>\n
While the above-described setup worked pretty smoothly for a few months now, one day the default YUM repository mirrors used by the AWS instances went down. This caused deployment failures and the cluster couldn’t be scaled up as expected. To prevent such an incident we the future, we now host the YUM repositories ourselves on an S3 bucket and use them instead.<\/span><\/p>\n
That pretty much sums up our little adventure with auto scaling at Exotel. Our key takeaways:<\/span><\/p>\n