Adrian Cantrill’s SAA-C02 study course, 60 minutes: HA & Scaling section: [ADVANCED DEMO]: Stage 5 part 2: Enable elasticity via a ASG & ALB and fix wordpress (hardcoded WPHOME)
[ADVANCED DEMO] Architecture Evolution STAGE 5: Part 2
Continuing on from part one, we picked up with working on enabling an autoscaling group, which would allow for the automatic provisioning and termination of the EC2 instances.
To get started on this, we navigated to the EC2 console, scrolled to the Auto Scaling section, and clicked on Auto Scaling groups. After this we clicked on create and auto scaling group. We named the auto scaling group, picked the website launch template we had updated previously, which we set to use as the latest version.
Continuing on, we clicked next to move to the next set of configuration options. The next section was the networking section, and it was here that we provisioned exactly which subnets would be used to provision our instances into. For this, we clicked on the VPC dropdown to verify that the specific subnet we wanted was selected, and then we picked the three public subnets in the subnets menu.
After this we looked at integrating the auto scaling group with the load balancer, It was explained that load balancers actually work for EC2 with static instance registration. This means that instances are registered with a target group within a load balancer configuration. What auto scaling groups do when you integrate them is it links this with a target group, so any instances provisioned by the auto scaling group are added to the target group and anything which the auto scaling group terminates is removed from the target group.
We would be attaching the auto scaling group to an existing load balancer. Our options were to pick an application load balancer or a network load balancer because then we would get to pick the target group. We clicked in the target group dropdown and selected the specific target group we wanted to use, selected the health checks we wanted to use, and we opted for ELB health checks, because they are much more feature rich than the normal EC2 status checks. Continuing on, we clicked on next.
From here, we looked at selecting one desired capacity, one minimum capacity, and one maximum capacity. Here we reviewed that it is the job of an auto scaling group to keep the minimum number of running instances the same as the desired capacity. This is the value that changes up or down and the minimum and maximum capacity provide limits to this. For the time being, we left desired, minimum and maximum all at one.
The next option was for automatic scaling policies, which we decided to ignore for the time being, choosing to leave it as a static auto scaling group. We clicked on next, ignored the option to add notifications for any scaling events, and looked at making sure that any instances provisioned by this auto scaling group were recognizable. For this we added a tag, the key being set as Name, and the value was a name that related to the website. We left the tag new instances checkbox selected, which meant that any instances launched by this auto scaling group would be tagged with this name.
Moving on, we clicked on next, scrolled to the bottom of that screen, and clicked on create auto scaling group. After this we clicked on instance, right-clicked on our existing instance, and terminated it, opting to rid ourselves the of the instance created directly with the launch template. After this we scrolled down to the auto scaling group’s console, clicked on the auto scaling group, clicked on activity, and refreshed. What we were looking forwas the following:
Because we had created this auto scaling group with a desired capacity of one, and because it had zero running instances, it would begin the creation of an instance in order to bring the running number of instances to be equal to the desired number of instances which is one. So at this point it would automatically provision an EC2 instance. Navigating to the EC2 console and hitting refresh, we looked to verify that there was a new EC2 instance, labelled with the specific name we had designated for use by the auto scaling group.
It was discussed that what we had created was for a simple static auto scaling group, and we wanted to ‘add some intelligence’. For this we navigated to the auto scaling group’s console, and we looked at adding some scaling policies. For this we clicked on auto scaling group, selected automatic scaling, create dynamic scaling policy, and we created two policies.
The first was to add instances when the average CPU utilization is above 40%, and we wanted to remove instances when the average CPU utilization is below 40%. For this, we would opt to use simple scaling policies. We reviewed that target tracking scaling adjusts automatically and aims to try to keep a certain value at a certain level. We applied a specific name to the first policy, and defined a Cloudwatch alarm. For this, we clicked on created Cloudwatch alarm, clicked on select metric, then EC2, and then by auto scaling group. We were looking for CPU utilization next to our auto scaling group. We clicked on that and then clicked on select metric.
We were looking to create an alarm that would go into an alarm state whenever the average CPU utilization was above 40%. For this, we set the threshold type to be static, and set the rest of the parameters so that the alarm was in line with our intended usage. We opted out of configuring a notification in the next screen, and gave the alarm a specific name. From here we created the alarm.
After this we moved back to the previous tab where the create scaling policy menu was still open, clicked on the refresh icon, and then clicked on the Cloudwatch alarm dropdown and selected the alarm we just created. We modified the alarm action to add one capcity unit whenever the cpu went above 40%, making sure the action was set to add. Then we clicked on create. After this we created another scaling policy with Cloudwatch alarm, this one for low cpu. The action added at the end was to remove and instance when the cpu usage dropped below 40%.
After this, we clicked on group details to adjust the auto scaling group settings so that the maximum capacity was more than one, because if it remained at one, the desired capacity could never increase. For this, we clicked on edit, and changed the max capacity to equal three.
It was considered that now we had created a fully scalable architecture, which we wanted to test by simulating some load. For the simulation we moved back to the EC2 console and connected using Session Manager. To this instance. After getting the instance up and running, we ran stress in bash to stress the CPU of the EC2 instance. For our purposes, stress used two cores and ran for 3,000 seconds. The desired effect is that the auto scaling group would detect the increase in CPU, the automatic scaling rule would be triggered, and a new instance would be created. Desired capacity would be increased to two, so a new instance would be generated. The instance would be provisioned with the launch template, it would be added to the target group at the load balancer, and then it couldcope with more load in our application.
We also looked at the self-healing capacity of the load balancer by terminating an instance. The load balancer detected this and automatically created a new instance.
It was then considered that at this point we had created a fully scalable elastic self-healing architecture, removed all of the prior limitations, split the application and database into separate pieces of compute, moved the data into an RDS instance, moved the WordPress content onto a shared EFS file system, added a load balancer and auto scaling group to allow automatic scaling actions, and the load balancer abstracts the sessions so they no longer connect directly to the EC2 instances. Also, at this point, the architecture can scale in and out based on the cpu load.
CloudMastermind 