Tag: Auto Scaling


使用“运行命令”管理一组实例

Emily Freebairn,亚马逊AWS软件开发工程师

翻译 Ye Zhou | 原文链接

通常,工程师希望在一组实例中执行操作任务。 但是,这些任务中的许多任务需要以受控的速度进行,并在出现问题时获得反馈。 此外,管理员还通常希望确保工程师只能执行指定的操作。

运行命令”是Amazon EC2系统管理器(SSM)的一部分,旨在让您远程和安全地管理实例。 “运行命令”提供了一种简单的方法来自动执行常见的管理任务,如运行shell脚本、安装软件或修补程序等等。 “运行命令”允许您在多个实例上执行命令,并提供对结果的可见性。通过与AWS身份和访问管理(IAM)的集成,您可以精确控制用户可以在实例上执行的操作权限。 “运行命令”执行的所有操作均由AWS CloudTrail记录,允许您审核对系统的更改。

在本文中,演示了如何执行命令来收集实例的诊断信息。 由于系统容量是按需添加,系统的容量会随时变化。为了减少实例出现意外的可能性,命令可以以受控的速度运行。 如果出现失败,您将收到通知以进行事后分析。 要确保您不会意外运行其他命令,请使用具有锁定权限的自定义操作来执行指定任务。

演练

在本节中,我将向您展示如何使用Auto Scaling设置实例,创建自定义SSM文档,然后在Auto Scaling组中的所有实例上运行命令。 同时展示了如何设置Amazon CloudWatch事件,以便在遇到问题时收到通知。

步骤1:使用Auto Scaling组启动实例

要使用“运行命令”,实例需要以下内容:

SSM代理与“运行命令”服务通信以接收命令并发送输出,并使用IAM角色授予调用服务的权限。

对于这篇文章,使用Auto Scaling组来创建一组正确配置的实例。 有关分步说明,请参阅Auto Scaling入门

这里是一个使用了五个实例的Auto Scaling组的示例。

步骤2:创建自定义文档

“运行命令”使用文档来指定要在实例上执行的操作。文档是由JSON定义的AWS资源,它们包括您指定的步骤和参数。

AWS提供了一组执行常见任务的文档,例如运行shell脚本,配置CloudWatch,安装应用程序等。 此外,您可以为自己的文档编写特定任务。 因为IAM策略允许您控制用户被授权使用哪些文档,因此可以通过将一个指定用户限制到某个文档子集来锁定该用户可以执行的操作。

这里是一个文档的例子,它找出最消耗内存的进程。

{
    "schemaVersion": "2.0",
    "description": "Instance Diagnostics",
    "parameters": { },
    "mainSteps": [
        {
            "action": "aws:runShellScript",
            "name": "collectInformation",
            "inputs": {
                "runCommand": [ "ps aux --sort '%mem' | head -5" ]
            }
        }
    ]
}

要创建自定义文档,请使用创建文档SSM API。

aws ssm create-document --name InstanceDiagnostics --content file://~/workspace/document.json --document-type Command
{
    "DocumentDescription": {
        "Status": "Creating", 
        "Hash": "92182f1392807f23556ecc3f9e1d950a575dce8e2a4b96d284b1b2fb93369db2", 
        "Name": "InstanceDiagnostics", 
        "Parameters": [], 
        "DocumentType": "Command", 
        "PlatformTypes": [
            "Linux"
        ], 
        "DocumentVersion": "1", 
        "HashType": "Sha256", 
        "CreatedDate": 1492636792.396, 
        "Owner": "040557870006", 
        "SchemaVersion": "2.0", 
        "DefaultVersion": "1", 
        "LatestVersion": "1", 
        "Description": "Instance diagnostics example."
    }
}

步骤3:设置CloudWatch事件

去年,我们在“运行命令”中添加了对命令状态更改的通知的支持。 设置CloudWatch事件通知时,您可以决定在每个实例或每个命令的基础上触发事件,并指定通知的状态。使用此功能,您可以选择在命令完成时收到通知,以进行必要的后续操作。

设置CloudWatch事件通知,以通过Amazon SNS通知并在命令完成时收到电子邮件。 首先创建一个在触发时发送电子邮件的SNS主题。

接下来,创建CloudWatch事件规则以在命令完成执行时触发SNS主题。

步骤4:测试一个实例上的命令

在将命令发送到整个实例组之前,请确保它按预期工作。

首先,检查测试实例是否正确设置并通过使用DescribeInstanceInformation API连接到该服务。 这将返回有关代理的状态、代理运行的平台以及其他实例信息。

aws ssm describe-instance-information --filters "Key=InstanceIds,Values=i-01222ecf7db201ca2"
{
    "InstanceInformationList": [
        {
            "IsLatestVersion": false, 
            "ComputerName": "ip-172-31-24-177.us-west-1.compute.internal", 
            "PingStatus": "Online", 
            "InstanceId": "i-01222ecf7db201ca2", 
            "IPAddress": "172.31.24.177", 
            "ResourceType": "EC2Instance", 
            "AgentVersion": "2.0.755.0", 
            "PlatformVersion": "2017.03", 
            "PlatformName": "Amazon Linux AMI", 
            "PlatformType": "Linux", 
            "LastPingDateTime": 1492637593.888
        }
    ]
}

接下来,使用先前创建的文档向上述实例发送命令

aws ssm send-command --document-name "InstanceDiagnostics" --instance-ids "i-01222ecf7db201ca2" 
{
    "Command": {
        "Comment": "", 
        "Status": "Pending", 
        "MaxErrors": "0", 
        "Parameters": {}, 
        "ExpiresAfter": 1492645288.475, 
        "ServiceRole": "", 
        "DocumentName": "InstanceDiagnostics", 
        "TargetCount": 1, 
        "OutputS3BucketName": "", 
        "NotificationConfig": {
            "NotificationArn": "", 
            "NotificationEvents": [], 
            "NotificationType": ""
        }, 
        "CompletedCount": 0, 
        "Targets": [], 
        "StatusDetails": "Pending", 
        "ErrorCount": 0, 
        "OutputS3KeyPrefix": "", 
        "RequestedDateTime": 1492638088.475, 
        "CommandId": "11cf0866-fdec-43a4-987b-b7a5f8ad60e9", 
        "InstanceIds": [
            "i-01222ecf7db201ca2"
        ], 
        "MaxConcurrency": "50"
    }
}

最后,检查以确保命令成功完成。

aws ssm list-commands --command-id 11cf0866-fdec-43a4-987b-b7a5f8ad60e9
{
    "Commands": [
        {
            "Comment": "", 
            "Status": "Success", 
            "MaxErrors": "0", 
            "Parameters": {}, 
            "ExpiresAfter": 1492645288.475, 
            "ServiceRole": "", 
            "DocumentName": "InstanceDiagnostics", 
            "TargetCount": 1, 
            "OutputS3BucketName": "", 
            "NotificationConfig": {
                "NotificationArn": "", 
                "NotificationEvents": [], 
                "NotificationType": ""
            }, 
            "CompletedCount": 1, 
            "Targets": [], 
            "StatusDetails": "Success", 
            "ErrorCount": 0, 
            "OutputS3KeyPrefix": "", 
            "RequestedDateTime": 1492638088.475, 
            "CommandId": "11cf0866-fdec-43a4-987b-b7a5f8ad60e9", 
            "InstanceIds": [
                "i-01222ecf7db201ca2"
            ], 
            "MaxConcurrency": "50"
        }
    ]
}

步骤4:用速度控制“命令运行”

现在,您可以将命令发送到您的一组实例。

“运行命令”公开了两个新概念,用于帮助您控制发送命令的速率。 您可以通过使用max-concurrency参数来控制多少个实例同时执行该命令。 您可以指定绝对的实例数,如10,或百分比,如50%。 系统将逐步创建更多的调用(命令和实例ID配对),直到达到最大并发限制,此时它将在创建下一个调用之前等待每个当前调用完成。

第二个参数max-errors允许您指定在“运行命令”停止向其他实例发送命令之前允许的错误数。 像最大并发一样,最大错误可以指定为绝对数或百分比。

向所创建的Auto Scaling组中的所有实例发送命令,举个例子,我们指定max-concurrency为40%、max-errors为100%。 您可以使用自动生成的Auto Scaling组标签,无需任何其他工作。 通过将max-concurrency设置为40%,您可以确保命令不会同时发送到所有实例。 将max-errors设置为100%将确保所有实例都运行命令,即使某些命令调用不成功。

因为您已设置CloudWatch事件通知,所以在命令完成时将会收到通知。 “运行命令”API的输出限制为1200个字符,因此指定一个S3的位置以确保捕获完整的输出。

aws ssm send-command --document-name "InstanceDiagnostics" --target "Key=tag:aws:autoscaling:groupName,Values=RunCommandASG" --max-concurrency 40% --max-errors 100% --output-s3-bucket-name "run-command-blog" --output-s3-key-prefix "diagnostics"
{
    "Command": {
        "Comment": "", 
        "Status": "Pending", 
        "MaxErrors": "100%", 
        "Parameters": {}, 
        "ExpiresAfter": 1492647224.49, 
        "ServiceRole": "", 
        "DocumentName": "InstanceDiagnostics", 
        "TargetCount": 0, 
        "OutputS3BucketName": "run-command-blog", 
        "NotificationConfig": {
            "NotificationArn": "", 
            "NotificationEvents": [], 
            "NotificationType": ""
        }, 
        "CompletedCount": 0, 
        "Targets": [
            {
                "Values": [
                    "RunCommandASG"
                ], 
                "Key": "tag:aws:autoscaling:groupName"
            }
        ], 
        "StatusDetails": "Pending", 
        "ErrorCount": 0, 
        "OutputS3KeyPrefix": "diagnostics", 
        "RequestedDateTime": 1492640024.49, 
        "CommandId": "666b0ea2-0004-4352-bddc-ac212e0e4090", 
        "InstanceIds": [], 
        "MaxConcurrency": "40%"
    }
}

步骤5:验证命令结果

当命令完成后,您将收到一封电子邮件中的SNS通知。

{
    "version": "0",
    "id": "8bb24048-9af4-4f88-a70d-47feba9da26c",
    "detail-type": "EC2 Command Status-change Notification",
    "source": "aws.ssm",
    "account": "040557870006",
    "time": "2017-04-19T22:38:19Z",
    "region": "us-west-1",
    "resources": [
        
    ],
    "detail": {
        "command-id": "666b0ea2-0004-4352-bddc-ac212e0e4090",
        "document-name": "InstanceDiagnostics",
        "requested-date-time": "2017-04-19T22:38:16.105Z",
        "expire-after": "2017-04-20T00:38:16.105Z",
        "output-s3bucket-name": "run-command-blog",
        "output-s3key-prefix": "diagnostics",
        "parameters": "",
        "status": "Success"
    }
}

使用ListCommands API来检查总体的命令状态。 这里会返回一些信息,例如命令的状态、有多少个实例被定位(TargetCount)以及完成了多少个调用(CompletedCount)。

aws ssm list-commands --command-id 666b0ea2-0004-4352-bddc-ac212e0e4090 
{
    "Commands": [
        {
            "Comment": "", 
            "Status": "Success", 
            "MaxErrors": "100%", 
            "Parameters": {}, 
            "ExpiresAfter": 1492647224.49, 
            "ServiceRole": "", 
            "DocumentName": "InstanceDiagnostics", 
            "TargetCount": 5, 
            "OutputS3BucketName": "run-command-blog", 
            "NotificationConfig": {
                "NotificationArn": "", 
                "NotificationEvents": [], 
                "NotificationType": ""
            }, 
            "CompletedCount": 5, 
            "Targets": [
                {
                    "Values": [
                        "RunCommandASG"
                    ], 
                    "Key": "tag:aws:autoscaling:groupName"
                }
            ], 
            "StatusDetails": "Success", 
            "ErrorCount": 0, 
            "OutputS3KeyPrefix": "diagnostics", 
            "RequestedDateTime": 1492640024.49, 
            "CommandId": "666b0ea2-0004-4352-bddc-ac212e0e4090", 
            "InstanceIds": [], 
            "MaxConcurrency": "40%"
        }
    ]
}

现在,您需要从指定实例收集的诊断信息。 使用GetCommandInvocation API。 这里会返回命令的输出,包括有关命令执行的更多详细信息,如开始执行时间以及执行了多久。

aws ssm get-command-invocation --command-id 666b0ea2-0004-4352-bddc-ac212e0e4090 --instance-id i-01222ecf7db201ca2
{
    "Comment": "", 
    "ExecutionElapsedTime": "PT0.004S", 
    "ExecutionEndDateTime": "2017-04-19T22:13:47.122Z", 
    "StandardErrorContent": "", 
    "InstanceId": "i-01222ecf7db201ca2", 
    "StandardErrorUrl": "https://s3-us-west-1.amazonaws.com/run-command-blog/diagnostics/666b0ea2-0004-4352-bddc-ac212e0e4090/i-01222ecf7db201ca2/awsrunShellScript/0.diagnose/stderr", 
    "DocumentName": "InstanceDiagnostics", 
    "StandardOutputContent": "eth0      Link encap:Ethernet  HWaddr 02:9B:C5:26:4B:00  \n          inet addr:172.31.24.177  Bcast:172.31.31.255  Mask:255.255.240.0\n          inet6 addr: fe80::9b:c5ff:fe26:4b00/64 Scope:Link\n          UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1\n          RX packets:9905 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:3260 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:1000 \n          RX bytes:11135049 (10.6 MiB)  TX bytes:514905 (502.8 KiB)\n\nlo        Link encap:Local Loopback  \n          inet addr:127.0.0.1  Mask:255.0.0.0\n          inet6 addr: ::1/128 Scope:Host\n          UP LOOPBACK RUNNING  MTU:65536  Metric:1\n          RX packets:2 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:1 \n          RX bytes:140 (140.0 b)  TX bytes:140 (140.0 b)\n\n", 
    "Status": "Success", 
    "StatusDetails": "Success", 
    "PluginName": "diagnose", 
    "ResponseCode": 0, 
    "ExecutionStartDateTime": "2017-04-19T22:13:47.122Z", 
    "CommandId": "666b0ea2-0004-4352-bddc-ac212e0e4090", 
    "StandardOutputUrl": "https://s3-us-west-1.amazonaws.com/run-command-blog/diagnostics/666b0ea2-0004-4352-bddc-ac212e0e4090/i-01222ecf7db201ca2/awsrunShellScript/0.diagnose/stdout"

最后,因为你设置了一个S3存储桶,所有的命令调用的输出结束将保存在你指定的 S3的位置。

结论

在本文中,展示了如何使用“运行命令”以及其他AWS服务来对一组实例执行管理操作。“运行命令”提供了一种简单且可扩展的方式来管理您的实例。 您可以控制发送命令的速率,使用细粒度的权限,并使用通知来简化工作流程。

关于作者

Emily Freebairn是亚马逊EC2系统管理团队的软件开发工程师。 她已经在亚马逊工作了四年,从事Amazon EC2和系统管理器的“运行命令”和其他功能。 在工作之余,她喜欢帆船和跳舞。

使用AWS CodeDeploy和Auto Scaling组实现蓝绿部署

原文: https://aws.amazon.com/blogs/devops/performing-bluegreen-deployments-with-aws-codedeploy-and-auto-scaling-groups/

作者:Jeff Levine,Amazon Web Services解决方案架构师


AWS提供的服务能够帮助大家利用云的力量来满足开发和部署的需求。AWS CodeDeploy可自动将代码部署到Amazon EC2或本地实例,并支持蓝绿部署方式。在这篇博文中,将讨论蓝绿部署的好处,并展示如何实现。

蓝绿部署的好处

蓝绿部署涉及两个生产环境:

  • 蓝色环境指代正在使用的生产环境。
  • 绿色环境则将发布一个新版本。

以下是蓝绿部署的一些优点:

  • 可在绿色环境下进行测试,而不会中断蓝色环境。
  • 切换到绿色环境不需要停机,只需要重定向用户流量。
  • 问题发生时,可很方便地从绿色环境回滚到蓝色环境,只要将流量重定向回蓝色环境即可,而无需重新构建。
  • 需要变更时,利用不可变基础设施原则初始化新的实例,避免实例配置产生不一致性。

AWS CodeDeploy提供了两种蓝绿部署的方式:

  • 第一种,AWS CodeDeploy为Auto Scaling组创建了副本,启用新的Amazon EC2实例,将应用程序部署到这些新实例,然后重定向用户流量重定到新部署的代码。
  • 第二种,可使用实例标签或Auto Scaling组来选择用于绿色环境的实例。AWS CodeDeploy会将代码部署到标记的实例上。

那么,如何设置你的第一个蓝色环境?最佳做法,当然是采用AWS CodeDeploy的in-place部署方式。当然也可以从已有的空白Auto Scaling组开始。

蓝绿部署的示例

我们来看一下如何使用Auto Scaling组来实现蓝绿部署。

概述

下图中,示例环境包括一组Amazon EC2实例,可作为AWS CodeDeploy的工作站。服务发布管理员或开发人员可以使用此工作站部署新版本的代码。蓝色环境包含一个Auto Scaling组,其中另有两个实例用作Web服务器。 Web服务器,最初将包含应用程序的第一个版本和AWS CodeDeploy客户端。负载均衡器以轮转的方式,将流量引导到两个Web服务器。

服务发布管理员使用工作站实例,将新版本的应用程序推送到AWS CodeDeploy,并启动蓝绿部署。 AWS CodeDeploy会创建Auto Scaling组的副本,启动两个新的Web服务器实例,并安装新版本的应用程序,然后将负载均衡器重定向到新实例。 原实例仍然是原Auto Scaling组的一部分。 如果需要,均可重新关联到负载均衡器中。

构建该示例的先决条件

以下是需要的准备工作。

  • 具有使用Amazon EC2,Amazon S3,Amazon VPC,AWS CodeDeploy和AWS CloudFormation权限的IAM用户。
  • 选定构建示例环境的AWS区域和可用区域。
  • Amazon EC2密钥对。
  • 熟悉上述服务和AWS管理控制台,如何连接到Amazon EC2实例。

其他注意事项

本示例中,您将会为使用到的基础AWS服务付费,本例中提供的资源仅为培训目的。 在实施与本博文中描述的类似技术时,请务必考虑相关的安全需求。

步骤1:创建初始环境

1. 下载包含示例模板的存档,并将其保存在相应的目录。https://github.com/awslabs/codedeploy-blue-green/

2. 登录到AWS管理控制台并打开AWS CloudFormation控制台,网址为 https://console.aws.amazon.com/cloudformation/

3. 如果这是一个新的AWS CloudFormation帐户,请单击创建新堆栈 。 否则,单击创建堆栈 。

4. 在将模板上传到Amazon S3选项中 ,单击Choose File,从您下载的存档中选择YAML文件,然后单击下一步 。

5. 在指定详细信息的堆栈名称中,输入bluegreen 

6. 在AZName中 ,选择一个可用区域。 (在这篇博文中,使用us-east-1a)

7. 在BlueGreenKeyPairName中 ,选择要使用的密钥对。

8. 在NamePrefix中 ,使用bluegreen的默认值,除非已经运行了以bluegreen开头的名称的应用bluegreen 。NamePrefix用于为创建的资源分配名称标签。 单击下一步 。

9. 在选项页面上,单击下一步 。

10. 选择确认框以允许创建IAM资源,然后单击创建 。CloudFormation将需要大约10分钟来创建示例环境。除了创建图中所示的基础设施之外,CloudFormation模板还设置了一个AWS CodeDeploy应用程序和蓝绿部署组。

步骤2:查看初始环境

1. 看看CloudFormation的堆栈输出。应该会看到以下类似内容。 WorkstationIP是工作站实例的IP地址。 AutoScalingGroup和LoadBalancer是由CloudFormation为Auto Scaling组和弹性负载均衡器创建的DNS名称。

2. 将LoadBalancer值复制到浏览器中并浏览到该链接,将会显示以下应用程序。这是一个PHP应用程序,用来查询Amazon EC2实例的元数据。 如果刷新页面,则会根据轮转的负载均衡算法,看到IP地址和实例ID的变化。

3. 回到EC2控制台,查看实例。将看到与此示例相关联的三个运行中的实例:工作站和Auto Scaling组创建的两个Web服务器实例。这些Web服务器实例构成蓝色环境。

步骤3:部署新版本的代码

1. 通过WorkStationIP中显示的地址,连接到工作站实例 。这个实例正在运行Ubuntu操作系统,用户名是ubuntu 。登录后,将看到两个目录:scripts目录包含Bourne shell脚本;newversion目录包含对PHP应用程序的更新。

2. 以下是newversion/content/index.php中新版本的PHP代码。 与最初安装代码的唯一区别是应用程序版本号。

3. 现在看下面的scripts/pushnewversion.sh的shell脚本。使用aws deploy push命令,将代码打包,上传到Amazon S3。

4. 运行pushnewversion.sh脚本,将看到一条消息,告诉您如何使用AWS命令行解释器来部署代码,不过这里我们将使用AWS CodeDeploy控制台来部署。

5. 打开AWS CodeDeploy控制台 https://console.aws.amazon.com/codedeploy/

6. 点击bluegreen-app的链接。 如果选择了NamePrefix的默认名称,请改为单击该名称,展开Revisions,将看到刚从工作站实例推送的修订版本,单击Deploy revision 。

7. 在Create Deployment页面上,选择bluegreen-app应用程序和bluegreen-dg部署组。保留所有其他默认值,然后单击Deploy。AWS CodeDeploy将配置Auto Scaling组和实例,部署代码,设置运行状况检查以及将流量重定向到新实例。这个过程需要几分钟。部署完成后,如下图所示。由于部署组中的设置,AWS CodeDeploy会跳过终止原始实例这一步。

步骤4:查看更新的环境

1. 在浏览器上打开负载均衡器的DNS地址。应该看到新版本的应用程序,如下图所示。应用程序版本从1变为2,如预期。

2. 回到EC2控制台并查看实例。将看到已被Auto Scaling组标记的四个实例。 IP地址为10.200.11.11和10.200.11.192的实例是我们在蓝色环境中看到的。部署过程创建了现在属于绿色环境的IP地址为10.200.11.13和10.200.22的实例。

3. 转到Auto Scaling组控制台 。将看到现在有两个Auto Scaling组,每个组有两个实例。 名称以CodeDeploy开头的Auto Scaling组是在部署过程中创建的。

4. 使用AWS CodeDeploy已经成功完成了蓝绿部署。

步骤5:清理

1. 重新登录到到AWS CodeDeploy工作站实例。

2. 运行scripts/cleanup.sh脚本。 将会删除部署包并关闭Auto Scaling组。

3. 转到CloudFormation控制台,选择之前创建的堆栈,然后将其删除。

结论

AWS CodeDeploy帮助开发人员将代码部署自动化到Amazon EC2和本地实例。其蓝绿部署选项帮助服务发布管理员,创建新的生产环境,并在问题出现时非常便捷地回滚到之前的环境。 有关AWS CodeDeploy的更多信息,请参阅AWS CodeDeploy文档 。现在,您只需点击几次即可开始使用。

在蓝绿的世界中享受生活!

译者介绍

黄帅,AWS中国专业服务的咨询顾问,主要为企业客户提供云架构设计、迁移技术指导和DevOps落地实践。加入AWS之前,有多年企业产品SaaS转型的研发和运维经历,以及丰富的DevOps实战经验。

全新推出 – Auto Scaling for Amazon DynamoDB

Amazon DynamoDB 拥有十万多的客户,客户身处各种行业,使用案例也各不相同。这些客户依赖于 DynamoDB 在任何规模下都能提供的一致性能和覆盖全球 16 个地理区域的服务网络。最近我们注意到一个趋势,客户正在使用 DynamoDB 来为他们的无服务器应用程序提供支持。这是一个很好的搭配:使用 DynamoDB,您无需考虑配置服务器、执行操作系统和数据库软件修补或跨可用区配置复制以确保高可用性之类的事情 – 您只需创建一些表,然后开始添加数据,其他的交给 DynamoDB 处理。

DynamoDB 提供预置容量模式,可以让您设定您的应用程序所需的读取和写入容量。尽管这让您无需考虑服务器,在 AWS管理控制台中进行简单的 API 调用或按钮单击就可以对表的配置进行更改,但客户已经在询问我们,有没有方法让管理 DynamoDB 容量变得更加轻松。

现在,我们推出了 Auto Scaling for DynamoDB,可帮助您实现表和全局二级索引容量管理的自动化。您只要指定所需的目标使用率,并提供读取和写入容量的上限和下限。之后,DynamoDB 将利用 Amazon Cloudwatch 警报来监控吞吐量占用情况,并根据需要上调或下调预置容量。Auto Scaling 对于所有新表和索引默认启用,您还可以对现有表和索引配置此功能。即使您不在左右,DynamoDB Auto Scaling 也将监控您的表和索引,并根据应用程序流量的变化自动调整吞吐量。这使您可以更加轻松地管理 DynamoDB 数据,帮助您最大程度地提高应用程序的可用性,并帮助您降低 DynamoDB 成本。我们来看看它是如何工作的……

使用 Auto Scaling

现在当您创建新表时,DynamoDB 控制台会提出一组适宜的默认参数。您可以原样接受它们,也可以取消选中“Use default settings”,然后输入您自己的参数:

以下是您输入自己的参数的方式:

目标使用率以占用容量与预置容量的比值来表示。以上参数将允许提供足够的空间,使占用容量能够在读取或写入请求突增时倍增 (请参阅容量单位计算,了解更多有关 DynamoDB 读取和写入操作与预置容量之间关系的信息)。预置容量的变化是在后台发生的。

Auto Scaling 的实际操作

为了了解这项重要的新功能的实际操作,我按照入门指南中的指示进行了操作。我启动了一个全新的 EC2 实例,安装了 (sudo pip install boto3) 并配置了 (aws configure) 适用于 Python 的 AWS 开发工具包。然后我使用 Python 和 DynamoDB 一节中的代码创建了一个表,为其填充了一些数据,并手动为该表分别配置了 5 个读取和写入容量单位。我稍作休息,以便 CloudWatch 指标形成简洁的直线,这样我就可以展示 Auto Scaling 的效果了。这是我开始应用负载之前指标的样子:

步骤3中,我修改了代码,以便继续在 1920 年至 2007 年之间随机选择年份执行查询,运行一份代码,并在一两分钟后查看了读取指标:

占用的容量高于预置的容量,导致出现了大量的受限制读取。现在就是 Auto Scaling 发挥作用的时间了!我返回控制台,单击了我的表中的 Capacity 选项卡。然后我单击 Read capacity,接受默认值,并单击 Save

DynamoDB 创建了一个新的 IAM 角色 (DynamoDBAutoscaleRole) 和一对 CloudWatch 警报来管理读取容量的 Auto Scaling:

DynamoDB Auto Scaling 将会管理警报的阈值,在扩展过程中上下移动这些阈值。第一个警报被触发,表状态更改为 Updating,同时预置了额外的读取容量:

几分钟内,读取指标中就会显示这一更改:

我启动了我修改后的查询脚本的其他几个副本,并观察额外容量的预置情况,如红线所示:

我删除了所有的脚本,然后去做其他的事情,同时等待缩减警报触发。以下是我返回时所看到的:

第二天,我检查了我的 Scaling activities,看到警报在一夜间已经触发了多次:

这在指标中也有显示:

到现在为止,对于这种情况,您需要根据预期使用情况合理设置您的读取容量,还要准备着为超额容量 (蓝线和红线之间的空间) 付款。否则,您可能将它设置得太低,忘了进行监控,而在流量攀升时容量耗尽。使用 Auto Scaling,您就可以做到两全其美:当需求增加,表明需要更多容量时自动响应,当容量不再需要时,再一次自动响应。

须知事项

DynamoDB Auto Scaling 可用于处理以大致可预测、通常为周期性的方式变化的请求速率。如果您需要处理不可预测的读取活动突增,则应将 Auto Scaling 与 DAX 结合使用 (请参阅 Amazon DynamoDB Accelerator (DAX) – 读取操作密集型工作负载的内存缓存以了解更多信息)。另外,AWS SDK 会检测受限制的读取和写入请求,并在适当的延迟之后重新尝试这些请求。

我之前提到了 DynamoDBAutoscaleRole。该角色为 Auto Scaling 提供它要扩展和收缩表和索引所需的权限。要了解更多有关这一角色及其使用权限的信息,请参阅Using the AWS Management Console With DynamoDB Auto Scaling

Auto Scaling 拥有完整的 CLI 和 API 支持,包括启用和禁用 Auto Scaling 策略的能力。如果您的流量存在一些可预测的时限性峰值,则您可以通过编程的方式禁用 Auto Scaling 策略,在设定的时间段内预置更高的吞吐量,并在之后重新启用 Auto Scaling。

DynamoDB 中的限制页面中所述,您可以按您所需的频率,根据您的需求增加预置容量 (受限于可以申请增加的每帐户限制)。对于每个表或全局二级索引,您每天最多可将容量减少九次。您将按照正常的 DynamoDB 定价为您预置的容量付费。您还可以通过购买 DynamoDB 预留容量进一步节省费用。

现已推出 此功能现已在所有区域推出,您可以立即开始使用。

-Jeff

新增 – EC2 Auto Scaling 的目标跟踪策略

最近我介绍过 DynamoDB Auto Scaling,并演示了它如何使用多个 CloudWatch 警报来实现 DynamoDB 表的自动容量管理。此功能在后台使用了一种更为通用的 Application Auto Scaling 模型,我们计划以后逐渐在多项不同 AWS 服务中投入使用该模型。

这一新的 Auto Scaling 模型包括一项重要的新功能,我们称之为目标跟踪。在创建使用目标跟踪的 Auto Scaling 策略时,需要为特定 CloudWatch 指标选择一个目标值。然后,Auto Scaling 旋转相应的旋钮 (打个比方) 推动指标趋向于目标,同时调整相关的 CloudWatch 警报。比起使用初始步进扩展策略类型来手动设置范围和阈值而言,采用对应用程序有意义的任何指标驱动的单元来指定期望的目标,通常来说要更简单,也更为直接。不过,您可以结合使用目标跟踪和步进扩展来实现高级扩展策略。例如,您可以使用目标跟踪实现扩展操作,使用步进扩展实现缩减操作。

现在面向 EC2

现在我们为 EC2 Auto Scaling 增加了目标跟踪支持。您现在可以创建应用程序负载均衡器请求计数、CPU 负载、网络流量或自定义指标 (Request Count per Target 是新指标,也是在今天发布) 驱动的扩展策略:

这些指标都具有同一个重要的特性:添加额外的 EC2 实例会推动指标下降 (但不会改变总体负载),反之亦然。

要创建使用目标跟踪的 Auto Scaling 组,只需输入策略名称、选择一个指标,然后设置所需的目标值:

您可以选择禁用策略的缩减功能。如果禁用,您可以手动缩减,也可以使用独立的策略。您可以使用 AWS Management ConsoleAWS Command Line Interface (CLI),或 AWS SDKs 来创建目标跟踪策略。如果要使用目标跟踪,请注意以下事项:

  • 只要每个目标引用不同的指标,您可以在单个 Auto Scaling 组中跟踪多个目标。扩展始终选择能推动实现最高容量的策略。
  • 如果指标数据不足,则不会扩展。
  • Auto Scaling 会补偿指标快速、瞬时的波动,尽力将相应的容量波动减到最小。
  • 您可以通过 Auto Scaling APIAWS Command Line Interface (CLI)为自定义指标设置目标跟踪。
  • 大多数情况下,您应该选择根据基于 1 分钟频率 (也称为详细监控) 发布的指标进行扩展。根据基于 5 分钟的指标进行扩展,将导致响应时间变慢。

现已推出

这项新功能现已推出,您可以立即开始使用,无需额外费用。要了解更多信息,请阅读《Auto Scaling 用户指南》中的目标跟踪扩展

-Jeff