• 沒有找到結果。

Add a target tracking scaling policy

在文檔中 Application Auto Scaling (頁 65-119)

• Step 4: Clean up (p. 65)

Prerequisites

This tutorial assumes that you have already done the following:

• You created an AWS account.

• You installed and configured the AWS CLI. For more information, see Set up the AWS CLI (p. 4).

• Your account has all of the necessary permissions for registering and deregistering resources as a scalable target with Application Auto Scaling. It also has all of the necessary permissions for creating scaling policies and scheduled actions.

• You have a scalable resource in a non-production environment available to use for this tutorial. If you don't already have one, create one before beginning the tutorial.

Before you begin, note the following:

While completing this tutorial, there are two steps in which you set or update your MinCapacity and MaxCapacity values to 0 to reset the current capacity to 0. Depending on the resource that you've chosen to use, you might be unable to reset the current capacity to 0 during these steps. To help you address the issue, a message in the output will indicate that minimum capacity cannot be less than the value specified and will provide the minimum capacity value that the resource can accept.

To monitor your scaling activities with Application Auto Scaling, you can use the describe-scaling-activities command. Each scaling event that is triggered by a scaling policy or a scheduled action generates a scaling activity.

Step 1: Register your scalable target

Step 1: Register your scalable target

Start by registering your resource as a scalable target with Application Auto Scaling. A scalable target is a resource that Application Auto Scaling can scale out or scale in.

To register your scalable target with Application Auto Scaling

• Use the following register-scalable-target command to register a new scalable target. Set the MinCapacity and MaxCapacity values to 0 to reset the current capacity to 0.

Linux, macOS, or Unix

aws application-autoscaling register-scalable-target \ --service-namespace service namespace \

--scalable-dimension scalable dimension of the scalable target \

--resource-id resource identifier to associate with this scalable target \ --min-capacity 0 --max-capacity 0

Windows

aws application-autoscaling register-scalable-target --service-namespace service namespace --scalable-dimension scalable dimension of the scalable target --resource-id resource --resource-identifier to associate with this scalable target --min-capacity 0 --max-capacity 0

This command does not return any output if it is successful.

Step 2: Set up scheduled actions according to your requirements

You can use the put-scheduled-action command to create scheduled actions that are configured to meet your business needs. In this tutorial, we focus on a configuration that stops consuming resources outside of working hours by reducing capacity to 0.

To create a scheduled action that scales out in the morning

1. To scale out the scalable target, use the following put-scheduled-action command. Include the --schedule parameter with a recurring --schedule, in UTC, using a cron expression.

On the specified schedule (every day at 9:00 AM UTC), Application Auto Scaling updates the MinCapacity and MaxCapacity values to the desired range of 1-5 capacity units.

Linux, macOS, or Unix

aws application-autoscaling put-scheduled-action \ --service-namespace namespace \

--scalable-dimension dimension \ --resource-id identifier \

--scheduled-action-name my-first-scheduled-action \ --schedule "cron(0 9 * * ? *)" \

--scalable-target-action MinCapacity=1,MaxCapacity=5

Windows

Step 2: Set up scheduled actions according to your requirements

aws application-autoscaling put-scheduled-action service-namespace namespace --scalable-dimension dimension --resource-id identifier --scheduled-action-name my-first-scheduled-action --schedule "cron(0 9 * * ? *)" --scalable-target-action MinCapacity=1,MaxCapacity=5

This command does not return any output if it is successful.

2. To confirm that your scheduled action exists, use the following describe-scheduled-actions command.

Linux, macOS, or Unix

aws application-autoscaling describe-scheduled-actions \ --service-namespace namespace \

--query 'ScheduledActions[?ResourceId==`identifier`]'

Windows

aws application-autoscaling describe-scheduled-actions service-namespace namespace --query "ScheduledActions[?ResourceId==`identifier`]"

The following is example output.

[ {

"ScheduledActionName": "my-first-scheduled-action", "ScheduledActionARN": "arn",

"Schedule": "cron(0 9 * * ? *)", "ScalableTargetAction": {

"MinCapacity": 1, "MaxCapacity": 5 },

...

} ]

To create a scheduled action that scales in at night

1. Repeat the preceding procedure to create another scheduled action that Application Auto Scaling uses to scale in at the end of the day.

On the specified schedule (every day at 8:00 PM UTC), Application Auto Scaling updates the target's MinCapacity and MaxCapacity to 0, as instructed by the following put-scheduled-action command.

Linux, macOS, or Unix

aws application-autoscaling put-scheduled-action \ --service-namespace namespace \

--scalable-dimension dimension \ --resource-id identifier \

--scheduled-action-name my-second-scheduled-action \ --schedule "cron(0 20 * * ? *)" \

--scalable-target-action MinCapacity=0,MaxCapacity=0

Windows

Step 3: Add a target tracking scaling policy

aws application-autoscaling put-scheduled-action service-namespace namespace --scalable-dimension dimension --resource-id identifier --scheduled-action-name my-second-scheduled-action --schedule "cron(0 20 * * ? *)" --scalable-target-action MinCapacity=0,MaxCapacity=0

2. To confirm that your scheduled action exists, use the following describe-scheduled-actions command.

Linux, macOS, or Unix

aws application-autoscaling describe-scheduled-actions \ --service-namespace namespace \

--query 'ScheduledActions[?ResourceId==`identifier`]'

Windows

aws application-autoscaling describe-scheduled-actions service-namespace namespace --query "ScheduledActions[?ResourceId==`identifier`]"

The following is example output.

[ {

"ScheduledActionName": "my-first-scheduled-action", "ScheduledActionARN": "arn",

"Schedule": "cron(0 9 * * ? *)", "ScalableTargetAction": {

"MinCapacity": 1, "MaxCapacity": 5 },

...

}, {

"ScheduledActionName": "my-second-scheduled-action", "ScheduledActionARN": "arn",

"Schedule": "cron(0 20 * * ? *)", "ScalableTargetAction": {

"MinCapacity": 0, "MaxCapacity": 0 },

...

} ]

Step 3: Add a target tracking scaling policy

Now that you have the basic schedule in place, add a target tracking scaling policy to scale based on current resource utilization.

With target tracking, Application Auto Scaling compares the target value in the policy to the current value of the specified metric. When they are unequal for a period of time, Application Auto Scaling adds or removes capacity to maintain steady performance. As the load on your application and the metric value increases, Application Auto Scaling adds capacity as fast as it can without going above MaxCapacity. When Application Auto Scaling removes capacity because the load is minimal, it does so without going below MinCapacity. By adjusting the capacity based on usage, you only pay for

Step 3: Add a target tracking scaling policy

what your application needs. For more information, see Supporting application availability during high utilization periods (p. 36).

If the metric has insufficient data because your application does not have any load, Application Auto Scaling does not add or remove capacity. The intention of this behavior is to prioritize availability in situations where not enough information is available.

You can add multiple scaling policies, but make sure you do not add conflicting step scaling policies, which might cause undesirable behavior. For example, if the step scaling policy initiates a scale-in activity before the target tracking policy is ready to scale in, the scale-in activity will not be blocked. After the scale-in activity completes, the target tracking policy could instruct Application Auto Scaling to scale out again.

To create a target tracking scaling policy

1. Use the following put-scaling-policy command to create the policy.

The metrics that are most frequently used for target tracking are predefined, and you can use them without supplying the full metric specification from CloudWatch. For more information about the available predefined metrics, see Target tracking scaling policies for Application Auto Scaling (p. 33).

Before you run this command, make sure that your predefined metric expects the target value. For example, to scale out when CPU reaches 50% utilization, specify a target value of 50.0. Or, to scale out Lambda provisioned concurrency when usage reaches 70% utilization, specify a target value of 0.7. For information about target values for a particular resource, refer to the documentation that is provided by the service about how to configure target tracking. For more information, see AWS services that you can use with Application Auto Scaling (p. 15).

Linux, macOS, or Unix

aws application-autoscaling put-scaling-policy \ --service-namespace namespace \

--scalable-dimension dimension \ --resource-id identifier \

--policy-name my-scaling-policy --policy-type TargetTrackingScaling \ --target-tracking-scaling-policy-configuration '{ "TargetValue": 50.0,

"PredefinedMetricSpecification": { "PredefinedMetricType": "predefinedmetric" }}'

Windows

aws application-autoscaling put-scaling-policy service-namespace namespace --scalable-dimension dimension --resource-id identifier --policy-name my-scaling-policy --policy-type TargetTrackingScaling --target-tracking-scaling-policy-configuration "{ \"TargetValue\": 50.0, \"PredefinedMetricSpecification\": { \"PredefinedMetricType

\": \"predefinedmetric\" }}"

If successful, this command returns the ARNs and names of the two CloudWatch alarms that were created on your behalf.

2. To confirm that your scheduled action exists, use the following describe-scaling-policies command.

Linux, macOS, or Unix

aws application-autoscaling describe-scaling-policies --service-namespace namespace \ --query 'ScalingPolicies[?ResourceId==`identifier`]'

Windows

Step 4: Clean up

aws application-autoscaling describe-scaling-policies service-namespace namespace --query "ScalingPolicies[?ResourceId==`identifier`]"

The following is example output.

[ {

"PolicyARN": "arn",

"TargetTrackingScalingPolicyConfiguration": { "PredefinedMetricSpecification": {

"PredefinedMetricType": "predefinedmetric"

},

"TargetValue": 50.0 },

"PolicyName": "my-scaling-policy", "PolicyType": "TargetTrackingScaling", "Alarms": [],

...

} ]

Step 4: Clean up

To prevent your account from accruing charges for resources created while actively scaling, you can clean up the associated scaling configuration as follows.

Deleting the scaling configuration does not delete your scalable resource. It also does not return it to its original capacity. You can use the console of the service where you created the scalable resource to delete it or adjust its capacity.

To delete the scheduled actions

The following delete-scheduled-action command deletes a specified scheduled action. You can skip this step if you want to keep the scheduled actions that you created.

Linux, macOS, or Unix

aws application-autoscaling delete-scheduled-action \ --service-namespace namespace \

--scalable-dimension dimension \ --resource-id identifier \

--scheduled-action-name my-second-scheduled-action

Windows

aws application-autoscaling delete-scheduled-action service-namespace namespace --scalable-dimension dimension --resource-id identifier --scheduled-action-name my-second-scheduled-action

To delete the scaling policy

The following delete-scaling-policy command deletes a specified target tracking scaling policy. You can skip this step if you want to keep the scaling policy that you created.

Linux, macOS, or Unix

Step 4: Clean up

aws application-autoscaling delete-scaling-policy \ --service-namespace namespace \

--scalable-dimension dimension \ --resource-id identifier \ --policy-name my-scaling-policy

Windows

aws application-autoscaling delete-scaling-policy --service-namespace namespace --scalable-dimension --scalable-dimension --resource-id identifier --policy-name my-scaling-policy

To deregister the scalable target

Use the following deregister-scalable-target command to deregister the scalable target. If you have any scaling policies that you created or any scheduled actions that have not yet been deleted, they are deleted by this command. You can skip this step if you want to keep the scalable target registered for future use.

Linux, macOS, or Unix

aws application-autoscaling deregister-scalable-target \ --service-namespace namespace \

--scalable-dimension dimension \ --resource-id identifier

Windows

aws application-autoscaling deregister-scalable-target service-namespace namespace --scalable-dimension dimension --resource-id identifier

Scaling activities

Suspending and resuming scaling for Application Auto Scaling

This topic explains how to suspend and then resume one or more of the scaling activities for the scalable targets in your application. The suspend-resume feature is used to temporarily pause scaling activities triggered by your scaling policies and scheduled actions. This can be useful, for example, when you don't want automatic scaling to potentially interfere while you are making a change or investigating a configuration issue. Your scaling policies and scheduled actions can be retained, and when you are ready, scaling activities can be resumed.

In the example CLI commands that follow, you pass the JSON-formatted parameters in a config.json file.

You can also pass these parameters on the command line by using quotation marks to enclose the JSON data structure. For more information, see Using quotation marks with strings in the AWS CLI in the AWS Command Line Interface User Guide.

Contents

• Scaling activities (p. 67)

• Suspend and resume scaling activities using the AWS CLI (p. 68)

Scaling activities

Application Auto Scaling supports putting the following scaling activities in a suspended state:

• All scale-in activities that are triggered by a scaling policy.

• All scale-out activities that are triggered by a scaling policy.

• All scaling activities that involve scheduled actions.

The following descriptions explain what happens when individual scaling activities are suspended. Each one can be suspended and resumed independently. Depending on the reason for suspending a scaling activity, you might need to suspend multiple scaling activities together.

DynamicScalingInSuspended

• Application Auto Scaling does not remove capacity when a target tracking scaling policy or a step scaling policy is triggered. This allows you to temporarily disable scale-in activities associated with scaling policies without deleting the scaling policies or their associated CloudWatch alarms. When you resume scale in, Application Auto Scaling evaluates policies with alarm thresholds that are currently in breach.

DynamicScalingOutSuspended

• Application Auto Scaling does not add capacity when a target tracking scaling policy or a step scaling policy is triggered. This allows you to temporarily disable scale-out activities associated with scaling policies without deleting the scaling policies or their associated CloudWatch alarms. When you resume scale out, Application Auto Scaling evaluates policies with alarm thresholds that are currently in breach.

ScheduledScalingSuspended

Suspend and resume scaling activities using the AWS CLI

• Application Auto Scaling does not initiate the scaling actions that are scheduled to run during the suspension period. When you resume scheduled scaling, Application Auto Scaling only evaluates scheduled actions whose execution time has not yet passed.

Suspend and resume scaling activities using the AWS CLI

You can suspend and resume individual scaling activities or all scaling activities for your Application Auto Scaling scalable target.

NoteFor brevity, these examples illustrate how to suspend and resume scaling for a DynamoDB table.

To specify a different scalable target, specify its namespace in --service-namespace, its scalable dimension in --scalable-dimension, and its resource ID in --resource-id. For a list of valid values for each option, see register-scalable-target.

To suspend a scaling activity

Open a command-line window and use the register-scalable-target command with the --suspended-state option as follows.

Linux, macOS, or Unix

aws application-autoscaling register-scalable-target --service-namespace dynamodb \ --scalable-dimension dynamodb:table:ReadCapacityUnits --resource-id table/my-table \ --suspended-state file://config.json

Windows

aws application-autoscaling register-scalable-target service-namespace dynamodb scalable-dimension dynamodb:table:ReadCapacityUnits resource-id table/my-table --suspended-state file://config.json

To only suspend scale-in activities that are triggered by a scaling policy, specify the following in config.json.

{ "DynamicScalingInSuspended":true }

To only suspend scale-out activities that are triggered by a scaling policy, specify the following in config.json.

{ "DynamicScalingOutSuspended":true }

To only suspend scaling activities that involve scheduled actions, specify the following in config.json.

{ "ScheduledScalingSuspended":true }

To suspend all scaling activities

View suspended scaling activities

Use the register-scalable-target command with the --suspended-state option as follows.

Linux, macOS, or Unix

aws application-autoscaling register-scalable-target --service-namespace dynamodb \ --scalable-dimension dynamodb:table:ReadCapacityUnits --resource-id table/my-table \ --suspended-state file://config.json

Windows

aws application-autoscaling register-scalable-target service-namespace dynamodb scalable-dimension dynamodb:table:ReadCapacityUnits resource-id table/my-table --suspended-state file://config.json

This example assumes that the file config.json contains the following JSON-formatted parameters.

{ "DynamicScalingInSuspended":true, "DynamicScalingOutSuspended":true, "ScheduledScalingSuspended":true }

View suspended scaling activities

Use the describe-scalable-targets command to determine which scaling activities are in a suspended state for a scalable target.

Linux, macOS, or Unix

aws application-autoscaling describe-scalable-targets --service-namespace dynamodb \ --scalable-dimension dynamodb:table:ReadCapacityUnits --resource-id table/my-table

Windows

aws application-autoscaling describe-scalable-targets service-namespace dynamodb --scalable-dimension dynamodb:table:ReadCapacityUnits --resource-id table/my-table

The following is example output.

{

"ScalableTargets": [ {

"ServiceNamespace": "dynamodb",

"ScalableDimension": "dynamodb:table:ReadCapacityUnits", "ResourceId": "table/my-table",

"MinCapacity": 1, "MaxCapacity": 20, "SuspendedState": {

"DynamicScalingOutSuspended": true, "DynamicScalingInSuspended": true, "ScheduledScalingSuspended": true },

"CreationTime": 1558125758.957,

"RoleARN": "arn:aws:iam::123456789012:role/aws-service-role/dynamodb.application-autoscaling.amazonaws.com/

AWSServiceRoleForApplicationAutoScaling_DynamoDBTable"

}

Resume scaling activities

] }

Resume scaling activities

When you are ready to resume the scaling activity, you can resume it using the register-scalable-target command.

The following example command resumes all scaling activities for the specified scalable target.

Linux, macOS, or Unix

aws application-autoscaling register-scalable-target --service-namespace dynamodb \ --scalable-dimension dynamodb:table:ReadCapacityUnits --resource-id table/my-table \ --suspended-state file://config.json

Windows

aws application-autoscaling register-scalable-target service-namespace dynamodb scalable-dimension dynamodb:table:ReadCapacityUnits resource-id table/my-table --suspended-state file://config.json

This example assumes that the file config.json contains the following JSON-formatted parameters.

{

"DynamicScalingInSuspended":false, "DynamicScalingOutSuspended":false, "ScheduledScalingSuspended":false }

Application Auto Scaling monitoring

Monitoring is an important part of maintaining the reliability, availability, and performance of Application Auto Scaling and your other AWS solutions. You should collect monitoring data from all parts of your AWS solution so that you can more easily debug a multi-point failure if one occurs. AWS provides monitoring tools to watch Application Auto Scaling, report when something is wrong, and take automatic actions when appropriate.

You can use the following features to help you manage your AWS resources:

Amazon CloudWatch Alarms

To detect unhealthy application behavior, CloudWatch helps you by automatically monitoring certain metrics for your AWS resources. You can configure a CloudWatch alarm and set up an Amazon SNS notification that sends an email when a metric’s value is not what you expect or when certain anomalies are detected. For example, you can be notified when network activity is suddenly higher or lower than a metric's expected value. For more information, see Monitoring with CloudWatch alarms (p. 72) and the Amazon CloudWatch User Guide.

Amazon CloudWatch Dashboards

Amazon CloudWatch monitors your AWS resources and the applications that you run on AWS in real time. CloudWatch dashboards are customizable home pages in the CloudWatch console. You can use these pages to monitor your resources in a single view, even including resources that are spread across different Regions. You can use CloudWatch dashboards to create customized views of the metrics and alarms for your AWS resources. For more information, see Building dashboards with CloudWatch (p. 73).

Amazon EventBridge

EventBridge delivers a near real time stream of system events that describe changes in AWS resources. EventBridge enables automated event-driven computing. You can write rules that watch for certain events and trigger automated actions in other AWS when these events happen. For more information, see Getting notified of events preventing scaling through EventBridge (p. 75).

AWS CloudTrail

AWS CloudTrail captures API calls and related events made by or on behalf of your AWS account.

Then it delivers the log files to an Amazon S3 bucket that you specify. You can identify which users and accounts called AWS, the source IP address from which the calls were made, and when the calls occurred. For more information, see the AWS CloudTrail User Guide. For information about the Application Auto Scaling API calls that are logged by CloudTrail, see Logging Application Auto Scaling API calls with CloudTrail.

Amazon CloudWatch Logs

Amazon CloudWatch Logs enable you to monitor, store, and access your log files from Amazon EC2 instances, CloudTrail, and other sources. CloudWatch Logs can monitor information in the log files and notify you when certain thresholds are met. You can also archive your log data in highly durable

Amazon CloudWatch Logs enable you to monitor, store, and access your log files from Amazon EC2 instances, CloudTrail, and other sources. CloudWatch Logs can monitor information in the log files and notify you when certain thresholds are met. You can also archive your log data in highly durable

在文檔中 Application Auto Scaling (頁 65-119)

相關文件