Sravya Yakkati's Blog

Lab 4: Performance Efficiency

Sravya Yakkati's photo
Sravya Yakkati
·

11 min read

© 2023 Amazon Web Services, Inc. or its affiliates. All rights reserved. This work may not be reproduced or redistributed, in whole or in part, without prior written permission from Amazon Web Services, Inc. Commercial copying, lending, or selling is prohibited. All trademarks are the property of their owners.

Note: Do not include any personal, identifying, or confidential information into the lab environment. Information entered may be visible to others.

Corrections, feedback, or other questions? Contact us at AWS Training and Certification.

Objectives

After completing this lab, you will be able to:

  • Create target tracking scaling policies for an Amazon EC2 Auto Scaling group.

  • Create an Amazon CloudWatch dashboard.

  • Perform a stress test to validate the scaling policy.

Prerequisites

This lab requires:

  • Use of a personal computer or laptop with Wi-Fi. The lab is not accessible using an iPad or tablet device, but you can use these devices to access the student guide.

  • Access to the administrator account on your local the computer.

  • Access to an internet browser, such as Chrome or Firefox.

Duration

This lab requires 40 minutes to complete.

Scenario

This lab guides you through activities to learn how to measure the performance and the behavior of an Amazon EC2 Auto Scaling group. Remember, if you cannot measure it, you cannot manage it. If you cannot manage it, you cannot improve it.

You visualize and set thresholds to check the performance of resources using Amazon CloudWatch dashboards. You use alerts to modify the architecture in case a defined threshold is breached, either to increase or decrease the number of instances accordingly.

Finally, aligned with the performance efficiency pillar, you use design principle to experiment more often, to perform an automated test that validates the scaling of the resources.

Start lab

  1. To launch the lab, at the top of the page, choose Start lab.

You must wait for the provisioned AWS services to be ready before you can continue.

  1. To open the lab, choose Open Console.

You are automatically signed in to the AWS Management Console in a new web browser tab.

Do not change the Region unless instructed.

COMMON SIGN-IN ERRORS

Error: You must first sign out

If you see the message, You must first log out before logging into a different AWS account:

  • Choose the click here link.

  • Close your Amazon Web Services Sign In web browser tab and return to your initial lab page.

  • Choose Open Console again.

Error: Choosing Start Lab has no effect

In some cases, certain pop-up or script blocker web browser extensions might prevent the Start Lab button from working as intended. If you experience an issue starting the lab:

  • Add the lab domain name to your pop-up or script blocker’s allow list or turn it off.

  • Refresh the page and try again.

Task 1: Create Target Tracking Scaling Policies

In this task, you create policies to automate the creation of instances to increase (scale out) the architecture and support the increase in the demand. You can also reduce (scale in) the number of instances when there is a reduction in the users and transactions into the application.

Create the Target Tracking Policy.

Target tracking, and simple scaling, policies can be found in the AWS Documentation.

  1. At the top of the AWS Management Console, in the search bar, search for and choose

    .

  2. In the navigation pane at the left of the page, under Auto Scaling, choose Auto Scaling Groups.

  3. In the Name column, choose the waAutoscaleGroup link.

The browser displays the waAutoscaleGroup details page.

  1. Select the Automatic scaling tab.

  2. Choose Create dynamic scaling policy.

The browser displays the Create dynamic scaling policy page.

  1. For Policy type, select Target tracking scaling .

  2. For Scaling policy name, confirm the name is

    .

  3. For Metric type, confirm the metric is Average CPU utilization .

  4. For Target value, input

    .

  5. For Instances need, input

    .

  6. Choose Create.

The browser displays the waAutoscaleGroup details page.

A banner message like the following is displayed at the top of the page: Dynamic scaling policy created or edited successfully..

You just automated the scaling out and scaling in for your architecture.

An advantage over simple scaling policy is that target tracking creates both the scale-in and scale-out policies for you at the same time. Additionally, Amazon CloudWatch alarms are automatically created for the scaling policies. You explore these in CloudWatch next.

This is an example of an implementation of advanced technology, applying the design principle of Democratize advanced technologies.

Congratulations! In this task, you created both scale-in and scale-out policies that are target tracking for the CPU utilization. Amazon CloudWatch can use this scaling for alarms.

Task 2: View Alarms and Create an Amazon CloudWatch Dashboard

In this task, you create a dashboard to visualize the performance of your resources and detect the alarms that can activate an automated action like scaling.

  1. At the top of the AWS Management Console, in the search bar, search for and choose

    .

  2. In the navigation pane at the left of the page, under Alarms, choose All alarms.

The browser displays the Alarms page.

On the Alarms page, two TargetTracking CloudWatch alarms exist. These alarms were automatically created when you set up target tracking polices for auto scaling in the previous task. One is the scale-in alarm, and the other is the scale-out alarm. The alarm metrics are set to collect data points over 15 minute intervals. Notice that after 15 minutes, the low CPU utilization (<50%) is in alarm, while the high CPU utilization (>70%) is not in alarm. That is because, in this lab, the auto scaling instances are idling and not receiving a real network traffic load.

  1. In the navigation pane at the left of the page, choose Dashboards.

  2. Choose Create dashboard.

The Create new dashboard message box is displayed.

  1. For Dashboard name, input .

The Add widget message box is displayed.

Next, add the following three widgets to this dashboard:

  • Number of heathy instances per load balancer

  • Average CPU % average utilization

  • Alarm status

First, add the number of healthy instances widget:

  1. Choose the Number card.

The Add metric graph message box is displayed.

  1. Next to Untitled graph, choose the Edit icon .

The Rename graph message box appears.

  1. Input .

  2. Choose Apply.

The graph is now named.

  1. In the Metrics section, choose the ApplicationELB card.

  2. In the Metrics section, choose the Per AppELB, per TG Metrics card.

  3. In the row that has a value of HealthyHostCount, under the Metric Name column, select the checkbox next to the load balancer.

  4. Select the Graphed metrics tab.

  5. In the table header, set Statistics to Maximum and Period to

    .

  6. Choose Create widget.

The Healthy Hosts widget is added to the dashboard.

Next, add the CPU % average utilization widget.

  1. Near the top right corner of the Amazon CloudWatch console, choose the plus icon .

The Add widget message box appears.

  1. Choose the Gauge card.

The Add metric graph message box is displayed.

  1. Next to Untitled graph, choose the Edit icon .

The Rename graph message box appears.

  1. Input .

  2. Choose Apply.

The graph is now named.

  1. In the Metrics section, choose the EC2 card.

  2. In the Metrics section, choose the By Auto Scaling Group card.

  3. In the row that has a value of CPUUtilization under the Metric Name column, select the checkbox next to the Amazon EC2 Auto Scaling group.

  4. Select the Options tab.

  5. Under Gauge range:

    • For Min, input .

    • For Max, input .

  6. Select the Graphed metrics tab.

  7. In the table header, set the Statistic to Average and Period to

    .

  8. Choose Create widget.

The CPU % Utilization widget is added to the dashboard.

Lastly, add the alarm status widget:

  1. Near the top right corner of the Amazon CloudWatch console, choose the plus icon .

The Add widget message box appears.

  1. Choose the Alarm status card.

  2. Select the checkboxes next to both TargetTracking alarms.

  3. Choose Create widget.

The Add to dashboard message box is displayed.

  1. In the Select a dashboard field, ensure that the value is .

  2. For Customize widget title, input .

  3. Choose Add to dashboard.

The Alarm widget is added to the dashboard.

  1. Near the top right corner of the Amazon CloudWatch console, choose Save.

Feel free to move and resize the widgets as you like, and remember to save your changes.

Now, considering that monitoring is an area of performance efficiency and for taking a data-driven approach for our architecture, you created a dashboard to be aware of any deviance from expected performance and take automated actions. Also, consider to make trade-offs in the architecture to improve performance, such as scaling up, scaling out, using compression or caching, or relaxing consistency requirements.

Congratulations! In this task, you created a custom Amazon CloudWatch dashboard with metrics from your environment and alarms.

Task 3: Validate the Alarms and Policies Created

At the end of this task, you validate the automated actions you configured. You can consider experimenting more often with new functionalities, services, and technologies.

Note: According to your business growth plans, this stress test can represent a simulation of the expected heavy traffic.

Use the AWS Systems Manager Run Command feature to stress your application servers.

  1. At the top of the AWS Management Console, in the search bar, search for and choose

    .

  2. In the left navigation pane, under the Node Management section, choose Run Command.

The browser displays the Run Command page.

  1. In the Commands section, choose Run a Command.

The browser displays the Run a Command page.

  1. In the Command document search box, input

    , and then press Enter.

  2. In the list of returned search results, select AWS-RunShellScript.

  3. On the Run a command page, under the Command parameters section, paste the following command.

Command:

#!/bin/bash
sudo stress --cpu 8 --vm-bytes $(awk '/MemAvailable/{printf "%d\n", $2 * 0.9;}' < /proc/meminfo)k --vm-keep -m 1 --timeout 300s
  1. On the Run a command page, under the Targets section:

  • For Target selection, select Choose instances manually.

  • For Instances, select the checkboxes next to the two instances which have the value

    in the Name column.

  1. On the Run a command page, under the Output options section, clear the checkbox next to Enable an S3 bucket.

  2. Scroll down, and then choose Run.

These commands run for 5 minutes. As soon as they start, immediately proceed to the next steps to observe the effect these commands have on your environment.

  1. At the top of the AWS Management Console, in the search bar, search for and choose

    .

  2. In the left navigation pane, choose Dashboards.

  3. In the Dashboards list, choose the WA-ASG link.

  4. Periodically, refresh the web page to receive updated information.

In the WA-ASG dashboards:

  • The average CPU % utilization increases above the target tracking threshold for scaling out.

  • The TargetTracking scale out alarm activates.

  • The number of healthy hosts increases to 4.

After the script finishes running, the instance count in the Amazon EC2 Auto Scaling group, and the CPU % utilization both return to normal levels.

Although instance count eventually scales-in and returns to normal, because of the auto-generated alarms, you probably will not witness the scale-in events during the allocated lab time. Recall that these alarms monitor underlying CPU utilization metrics, that are set to 15 minute intervals. Delaying your scale-in events can be a good practice to prevent thrashing in your environment, that is the rapid spin-up/spin-down of instance count in response to scaling thresholds.

Congratulations! In this task, you verified the target tracking scaling policy and Amazon CloudWatch Dashboard are working. You utilized command documents from the Systems Manager Run Command to increase the CPU utilization on two of the instances in the Amazon EC2 Auto Scaling group. This caused the number of available instances to scale out.

Lab Complete

Congratulations! You completed the lab.

You worked on the efficient use of computing resources to meet requirements and how to maintain efficiency as demand changes and technologies evolve. Continue to review your choices on a regular basis and ensure that you are taking advantage of the continually evolving AWS Cloud.

When architecting workloads, there are finite options that you can choose from. However, over time, new technologies and approaches become available that can improve the performance of your workload. Fortunately, in the cloud, it is much easier to experiment with new features and services.

In this lab, you learned how to:

  • Create target tracking scaling policies for an Amazon EC2 Auto Scaling group.

  • Create a customized Amazon CloudWatch dashboard.

  • Perform a stress test to validate the scaling policy.

End lab

Follow these steps to close the console and end your lab.

  1. Return to the AWS Management Console.

  2. At the upper-right corner of the page, choose AWSLabsUser, and then choose Sign out.

  3. Choose End lab and then confirm that you want to end your lab.

For more information about AWS Training and Certification, see aws.amazon.com/training.

Your feedback is welcome and appreciated.
If you would like to share any feedback, suggestions, or corrections, please provide the details in our AWS Training and Certification Contact Form.