回到首页

输入关键词，多个关键词用空格分隔。

← 云计算课程 · 系列目录

云计算 第 11 课 Horizontal Scaling and Advanced Resource Scaling

约 25 分钟
本页目录

经过上一节课的『锻炼』，这一次我们要迎来更大的挑战。前面很多时候都是通过 Web 界面来进行云资源的管理，这里我们需要学会如何用代码来申请和控制各种资源。

学习目标

这一次课时间紧任务重，需要掌握的知识和技能有：

  1. 根据需求利用代码通过云 API 来申请所需资源
  2. 能够在故障、花费和性能等限制条件下完成 web 服务的部署
  3. 对比 AWS 和 Azure 在 API 使用上的不同
  4. 能够识别和说明处理资源故障的必要性
  5. 能够解释在所有资源间保证负载均衡的必要性
  6. 在 Azure 的 VM Scale Set 上配置和部署一个负载均衡器 Load Balancer
  7. 在 AWS 的 Auto Scaling Group 上配置和部署一个 Elastic Load Balancer
  8. 完成能够处理资源失败的解决方案
  9. 在申请云资源的时候考虑花费这一限制因素
  10. 分析最大化性能和可靠性与成本之间的权衡

有一些需要注意的地方

  • 记得打标签（EC2, ELB, ASG）
  • 不要在代码里包含 AWS 的密钥
  • AWS 中只能使用 m3.medium 或 m3.large
  • Azure 中只能使用 Standard_A1(DC) 和 Standard_D1(LG)

基础知识

上一课里，我们使用云来进行了大数据处理和分析，只需要几行代码，就可以启动一个 EMR 集群来进行并行处理运算。但是，类似 EMR 这种服务通常很贵，并且内部具体的运行状况我们很多时候无从得知。另外，虽然 EMR 支持很多不同的应用，但是实际上还是有诸多限制，比方说主要是应用在批处理和分析上。这一次我们会部署一个 web 服务，用来响应各种 web 请求（类似于第 7 课 AWS 动手玩（原文暂缺））

在第 9 课 Sequential Programming中，我们故意选择了一个 t1.micro 实例，只有很有限的硬件资源。在这种条件的制约下，就很容易出现运行缓慢，甚至内存不够的问题，于是需要我们去尽可能优化代码。

但是代码优化总有一个极限，很多时候我们必须指定合适的硬件资源才能更有效率地完成各项任务。在云计算中，调整分配给不同工作/任务/服务的资源的过程称为 scaling。

Scaling 具体来说，可以分成两类

Scaling 的分类

Vertical Scaling

这是最简单的方法，也就是提高系统中资源的容量。例如，改变核心的数量，内存的大小或者处理器的计算速度。我们在之前的课程中也进行过测试。

Horizontal Scaling

Horizontal scaling 就复杂很多，因为需要把任务进行切分，然后分配到不同的资源上。一个比较简单的机制就是不断增加相同的资源（实例），这次我们主要以这种方式来完成 horizontal scaling

在没有云之前，要对资源进行 scaling 是一个很复杂的任务，云的其中一个突出好处就是可以动态添加资源，也就是这节课着重要强调的内容。

这里我们要做的就是写代码来和云上的资源进行交互，简单来说，就是把各种 API 连起来用正确的顺序进行调用，但是需要注意代码的可靠性和容错性。因为实际上是发送过去一个请求，然后得到一个返回结果，所以需要做好各种可能的预防措施，比如失败的话，可能需要重新申请。

剧情梗概

设定很有意思，居然强行扯上了奥威尔的世界观，简单来说，这个世界观比这门课有意思多啦！《1984》+《动物农场》，你值得拥有。大概是这样的：

Azure Horizontal Scaling

  • Scaling out: 从一个 Standard_A1 虚拟机扩展到很多个 Standard_A1 虚拟机
  • Scaling in: 减少虚拟机的数量

这里我们会用到两种不同的实例：

  • Load Generator: 产生请求
  • Data Center: 处理和响应请求

目标也很简单，不断开启实例，直到最终满足能够处理每秒 3000 次的请求(3000 RPS)

第一步

因为 Azure 的限制，所以需要把镜像先拷贝到自己的账户中：

  • Data Center, Standard_A1, https://cmucc.blob.core.windows.net/public/Microsoft.Compute/Images/vhds/cc15619p21dcv5-osDisk.e27faca3-f177-40ea-a740-9a1838326ae6.vhd
  • Load Generator, Standard_D1, https://cmucc.blob.core.windows.net/public/Microsoft.Compute/Images/vhds/cc15619p21lgv10-osDisk.f6be8828-8cab-45ae-a611-904aeeef3c9e.vhd

命令如下：

# 复制
azure storage blob copy start https://cmucc.blob.core.windows.net/public/Microsoft.Compute/Images/vhds/cc15619p21dcv5-osDisk.e27faca3-f177-40ea-a740-9a1838326ae6.vhd --dest-account-name YOURNAME --dest-account-key YOURKEY --dest-container YOURCONTAINER

# 查看
azure storage blob copy show --account-name YOURNAME --account-key YOURKEY --container system --blob Microsoft.Compute/Images/vhds/cc15619p21dcv5-osDisk.e27faca3-f177-40ea-a740-9a1838326ae6.vhd

大概要等一阵子，可以先来看看具体的测试规则：

  1. Data Center 必须用 Standard_A1，Load Generator 必须用 Standard_D1
  2. 所有的虚拟机都必须通过代码启动，所有的 data center（除了第一个）都必须要在测试开始之后创建
  3. 代码需要完成处理当前每秒的请求并决定是否需要启动另一台虚拟机
  4. 不要 hardcode 虚拟机的数量
  5. 代码不应该连续开启多个 data center 虚拟机
  6. 每开启一个虚拟机，需要等待 100 秒才可以开启下一个虚拟机
  7. 测试一旦开始，除了关机没有其他办法可以停止，所以确定准备好了再开始
  8. 除了复制镜像的部分，程序必须是全自动并且可以容忍错误的。也就是说，从开启虚拟机到提交密码和 andrewid 再到开始测试再到添加需要的虚拟机最后测试完成退出都必须是自动的。
  9. 代码中不需要关闭 load generator，之后还会用到。不过 data center 可以删除（不一定需要在代码中完成）

再来是给出的一些提示：

  1. 可以利用之前给出的 Azure API 代码来从镜像创建虚拟机
  2. 使用 DNS 而不是 IP 地址
  3. 如果不大清楚程序在做什么，可以用浏览器体验一下整个过程
  4. 如果不熟悉如何通过代码提交请求，看看浏览器是怎么做的
  5. 使用 GET 和 POST 来完成请求
  6. Horizontal Scaling Test 在达到指定的 RPS 后会结束，可以通过检查 log 来判断测试的状况
  7. 测试文件是 ini 格式的，可能需要用 ConfigParser(Python) 或 ini4j(Java) 来进行解析

经过漫长的等待，复制完成，我们可以开始这次的任务了。首先是把之前的 Azure Demo 的代码导入到 Eclipse 里面。（代码在第 5 课 Azure API（原文暂缺）中，感谢 @jiexing 提供的具体步骤）

  1. eclipse->help->install new software->http://download.eclipse.org/technology/m2e/releases/
  2. eclipse->file->import->existing maven projects
  3. 在运行设置中，设置命令行参数：RESOURCEGROUP STORAGEACCOUNT VHDNAME SUBSCRIPTIONID TENANTID APPLICATIONID APPLICATIONKEY（和之前启动的一样）

第二步

修改样例代码，让它能够启动一个 Load Generator 和一个 Data Center 的虚拟机。然后要去 load generator 那里注册一下 andrewid 和提交密码。地址是

http://[your-load-generator-instance-dns-name]/password?passwd=[your submission password]&andrewid=[your andrew id]

这里我遇到了个问题，就是创建了虚拟机之后却没办法访问页面，好的暂时没办法继续了。

原因找到了，因为少了一段设置 DNS 的代码（后来更新的，在这里）

第三步

就是按部就班来完成任务了，不停测试是少不了的，说一些需要注意的地方：

  • 注意每一步操作之后均需要等待一段时间，这样一来更准确，二来不用反复重试
  • 整体的逻辑最好先想好，不然写着写着容易乱
  • 把访问网络的部分封装好，自动处理连接失败的问题，这样就可以避免很多麻烦
  • 解析 RPS 数值可以使用 ini 解析器，也可以直接处理纯文本，我觉得纯文本比较好处理，就没用 ini 来解析了
  • 访问 log 需要利用之前开始测试时返回的 log id，需要解析出来之后进行使用。
  • 确保这一步没错才开始下一步，这样比较保险。

这里我判断重试的逻辑有一点问题，注意 try catch 语句可能引起的特殊流程

Azure Autoscaling

在前面的任务中，我们做的是 horizontal scaling，利用代码来增加 data center 虚拟机的数量。这种方法的局限性在于：

整个 scale 的过程需要程序执行，如果程序因为某些原因关闭了，那么就不会再发送 API 请求了。而且，这种情况下负载是不均衡了，每次增加 data center，需要通知 load generator，这之后才能对其发送请求。

诸如 AWS 和 Azure 的云服务提供商都可以自动进行资源扩展和负载均衡。我们所要做的就是进行一些配置，一旦配置成功，就会自动进行资源调度了。接下来我们会在 Azure 上体验一下

Virtual Machine Scale Sets

Azure 的 Virtual Machine Scale Sets 其实就是一个集群，集群中的每个虚拟机都是一样的。我们可以利用基于 json 的部署脚本，通过 Azure 资源管理器或者命令行工具来进行配置。使用之前我们需要对 json 脚本进行一些配置。

  • Virtual Machine Configuration
    • 包括虚拟机的镜像文件，虚拟机类型和其他一些虚拟机相关问题。
  • Virtual Network
    • 在 scaling set 中的每一台机器都必须被配置为在特定的虚拟网络中
  • Load Balancer Configuration
    • 负载均衡器通常用 round-robin 方式来发送请求，虽然这种调度方式并不算完美，但是面对来自大量用户的简单请求，已经足够了。
  • Scaling Policies
    • Scaling policies 决定何时从 scaling set 增加和减少虚拟机

因为是动态资源管理，所以负载均衡器需要对其背后的机器有一些了解。所以通常会定期检查各个主机是否正常运行，如果不正常，就会停止对其发送请求。

因此，我们的负载均衡器必须配置好 IP 地址，负载均衡规则（决定需要进行转发的琉璃那个），以及探测器（检查实例是否正常运行）

Configuring an Azure VM Scaling Set

这里，我们可以自动进行 scaling，而不需要像第一个任务那样手动申请。Load Generator 会不断增加发送的请求，从一台 data center 虚拟机开始，Azure 会自动增加虚拟机的数量，以便处理更多的请求。

我们还会用之前的 data center 和 load generator 虚拟机镜像。接着我们会用 JSON 格式的模板来创建 auto scaling set。下载 Azuredeploy.json 和 Azuredeploy.parameters.json。下面是运行部署命令会创建的资源列表：

azuredeploy.json

  • Virtual Network: All the NICs and IP addresses associated with the virtual machines and load balancers will be deployed in this virtual network.
  • IP Address: This will be assigned to the NIC on the load balancer.
    • Note: Azure VM set does not assign IP addresses to the backend machines.
    • domainNameLabel: This is a DNS prefix for the load balancer DNS name. The load balancer DNS name will thus have the format ${prefix}.eastus.cloudapp.azure.com. The provided JSON template currently uses the vmScalingSetName (explained below) as the DNS prefix.
  • Load Balancer: As the frontend of the VM set, the load balancer will receive HTTP requests and forward them to the backend machines using round robin strategy.
    • frontendIPConfigurations: Provide the resource name of the IP Address created above.
    • backendAddressPools: Configure the backend machines. Azure allows users to put machines in a pool and use this set as a backend for a load balancer. In this JSON template, we will use the VM set as the backend pool of data center VMs.
    • loadBalancingRules: You can configure the traffic type you want to forward from the frontend to the backend machines. In this template, we will forward TCP traffic from port 80 to port 80, which is typically used for HTTP requests.
    • probes: This is the health checker for the load balancer. The load balancer will send a request to a user specified path in a fixed interval. If no reply is received from a backend machine within a specified threshold, the load balancer will mark the machine as unhealthy and stop forwarding traffic to it.
  • Virtual Machine Scale Set: You need to specify the image URL for this Azure VM set. The new machines will be created from this image if necessary.
    • sku: You can configure the virtual machine type (Standard_A1 in this case) for the data center VMs and the initial number of machines (1 in this case).
    • virtualMachineProfile: Provide a VM image URL in this section, the machines at the backend will be created from this image.
    • extensionProfile: Here we will configure a LinuxDiagnostic extension for the VM set. This will help us collect the CPU utilization of a VM, which we will use as the basis for triggering any scaling actions.
  • Auto Scale Setting: In Azure, the autoscale setting policy is used to configure an autoscaling event trigger and action. For example, you can configure the autoScalingSetting section in the JSON file to make the VM set scale up when the CPU Utilization Percentage is above a threshold.
    • profiles.rules: You need to configure the scaling policy in this section.

大概了解之后，具体配置的时候需要修改 azuredeploy.json 和 azuredeploy.parameters.json 中的一些参数的内容。在 azuredeploy.json 中只需要修改下面的部分：

azuredeploy.json

The profiles under Microsoft.Insights/autoscaleSettings: You need to consider the capacity and rules.

在 azuredeploy.parameters.json 中，配置下面的参数：

azuredeploy.parameters.json

  • vmScalingSetName: Name for your Virtual Machine Scaling Set and Load Balancer DNS prefix. Give a global unique name for this. (This name should match ^[a-z][a-z0-9-]{1,61}[a-z0-9]$).
  • storageAccName: Storage Account name where your data center VM image is in.
  • resourceGroupNameForStorageAcc: Resource Group name where your data center VM image is in.
  • instanceCount: Leave it at 1 for this project.
  • vmSize: Keep it Standard_A1 for this project.
  • location: Keep it East US for this project.
  • sourceImageVhdUri: The data center VM image URL in your strorage account.
  • frontEndLBPort: Keep it 80. The http request to frontEndLBPort will be forwarded to the backEndLBPort on the data center VMs.
  • backEndLBPort: Keep it 80.

配置好了对应参数，就可以用下面的命令来创建了，注意需要提供一个新的 RESOURCE_GROUP_NAME（除了虚拟机磁盘，都会在这个资源组创建）以及你的 AZURE_SUBSCRIPTION_ID。

azure group create  -f ./azuredeploy.json -e  ./azuredeploy.parameters.json -n <RESOURCE_GROUP_NAME> -l "East US" --subscription <AZURE_SUBSCRIPTION_ID>

之后注意去 web 界面检查下是不是真的开启成功了。

Running the Autoscaling Test

部署成功之后就可以进行测试了。具体的任务步骤如下：

  1. 根据之前给出的配置文件，用命令行工具进行部署
  2. 确保部署成功，并且 load generator 正常运行。可以通过访问 http://${vmScalingSetName}.eastus.cloudapp.azure.com/lookup/random 来进行测试（注意修改为自己的地址）
  3. 向 Load Generator 提交负载均衡起的地址以进行测试 http://[your-load-generator-instance-dns-name]/junior?dns=[your-loadbalancer-dns-name]（如果是新开的机器，需要提交密码和 andrewid）
  4. 可以不断刷新网页来查看 log

测试规则和提示：

  • 开始测试时只能启动一个 data center 虚拟机来进行测试
  • 设定的 autoscaling policy 应该在负载加大的时候自动增加机器
  • 目标是 30 分钟达到 900 rps
  • Load Generator 只使用 Standard_D1，Data Center 只使用 Standard_A1

AWS Horizontal Scaling

AWS 的这个部分需要完成的和 Azure 类似，需要注意以下几点：

  1. 使用 m3.medium 用 ami-8ac4e9e0 来作为 load generator
  2. 使用 m3.medium 用 ami-349fbb5e 来作为 data center
  3. 用下面的 URL 来提交密码和 andrew id：http://[your-load-generator-instance-dns-name]/password?passwd=[your submission password]&andrewId=[your andrewId]
  4. 用下面的 URL 来提交 data center 的 dns 来开始测试：http://[your-load-generator-instance-dns-name]/test/horizontal?dns=[your-instance-dns-name]
  5. 打标签需要在代码中完成，要确保 security group 设置所有的端口都打开
  6. 可以通过下面的 URL 来查看 log：http://[your-load-generator-instance-dns-name]/log?name=test.[test-number].log
  7. 为了通过测试，需要保证 RPS 达到 4000，测试开始之后可以通过发送请求来添加实例：http://[your-load-generator-instance-dns-name]/test/horizontal/add?dns=[your-instance-dns-name]
  8. 所有 data center 的规格应该是一样的

就是按部就班来完成任务了，不停测试是少不了的，说一些需要注意的地方：

  • 注意每一步操作之后均需要等待一段时间，这样一来更准确，二来不用反复重试
  • 整体的逻辑最好先想好，不然写着写着容易乱
  • 把访问网络的部分封装好，自动处理连接失败的问题，这样就可以避免很多麻烦
  • 解析 RPS 数值可以使用 ini 解析器，也可以直接处理纯文本，我觉得纯文本比较好处理，就没用 ini 来解析了
  • 访问 log 需要利用之前开始测试时返回的 log id，需要解析出来之后进行使用。
  • 确保这一步没错才开始下一步，这样比较保险。

完成之后，就可以发现现在这种方法的局限：

我们有一个 Load Generator，若干个 data center 会试着从中获取数据。每次添加实例，都需要通知 load generator，然后需要进行一些计算使得各个 data center 获得相同的流量。但是如果不想要这么多 data center，或者忽然有一个实例挂掉了呢？怎么去监控这个事情呢？怎么保证每个 data center 的负载均衡呢？

所以 AWS 提供一个叫做 Elastic Load Balancing 的服务，可以自动把流量均分给连接的实例，也能处理好实例挂掉的情况。接下来我们会做一些这个方面的尝试。

AWS Autoscaling

服务质量（QoS）和花费是部署云服务时非常重要的两个方面。如果不能提供高质量的服务，肯定会损失用户。性能，可用性，可靠性和安全性都是服务质量中很重要的因素。

Elastic Load Balancer 像是一个网络路由器，会用 round-robin 的方式转发进入的请求给不同的 EC2 实例。

ELB 指向的机器可以通过 web 界面手动添加，也可以写代码或者通过 Auto Scaling Group(ASG)，这里 AWS 会有一个实例池。ELB 同时也会检查实例是否正常运行，如果不是的话会停止发送请求。目前，ELB 每小时花费 $0.025 加 $0.008 每 GB 数据传输费。下图大概描述了 ELB 的功能。Video 中也对 ELB 有详细的介绍。

界面创建 ELB：点击左边的页面，选择 Load Balancer，设定名字以及转发规则，然后配置 Health Check，设定间隔和超时的规则，然后选择安全组，最后选择需要 ELB 的 EC2 实例，就可以启动了。然后访问 ELB 的地址，就可以看到会把请求发送到不同的实例上，用完记得删除 ELB 和 EC2 实例。

可以用下面的方式来跟 ELB 进行交互

  1. The AWS Command Line Interface (AWS CLI)
  2. The AWS SDK for Java
  3. boto for Python

AWS Auto Scaling 服务会根据使用需求自动添加或移除分配给一个应用的资源，使用的是 horizontal scaling 的机制，也就是加机器，而非加硬件。AWS Auto Scaling 会根据需求来增加或减少同样的资源。我们可以通过命令行工具或者 API 来进行控制。这个 视频 是一个简要的介绍。

视频内容大致为：

我们可以利用 Auto Scaling 来处理流量突然增大的状况。传统的方式不够灵活，闲时浪费计算能力，忙时可能计算能力又不够。整体的机制是：

Amazon CloudWatch 是用来监控不同的资源指标的，当达到某个占用量时，可以执行某些操作，如下

Amazon Simple Notification Service 是一个快速且灵活的消息发送服务，当特定事件发生的时候会推送消息，然后订阅者可以接受并做对应的操作，比方说，下图就描述了在发生 ScaleOut/ScaleIn 时发送邮件通知的大概流程

Amazon's Auto Scaling 在 EC2 实例上提供下列部署模式：

  • 一直维护固定数量的 EC2 实例，定期检查状况，替换掉不健康的实例
  • 调用 Auto Scaling 来调整实例数量
  • 根据开发者指定的调度计划来进行调整（比方说可以设定周五晚上增加机器，周一早上减少机器）
  • 根据开发者设定的条件来动态调整（比如 CPU 的利用率）

这里我们会用 Auto Scaling 根据不同的流量状况来调整机器数量。流量增大，每台机器的负载加大，那么就增加服务器数量，反之亦然。我们可以编写代码让 Auto Scaling 根据 CPU 负载（或者其他指标）来申请机器。

Auto Scaling Architecture in Amazon EC2

使用 Auto Scaling 需要满足以下条件：

  • 一个 Auto Scaling 组在创建的时候需要定义最小/最大和预期实例数量
  • 需要定义一个启动配置模板，包括 AMI id，实例类型，key pair 和安全组等等信息
  • 需要创建 Auto Scaling policy，其中定义了当特定事件（如 CloudWatch 的警报）触发时需要执行的操作。

这个视频简要介绍了如何使用 Auto Scaling。

要创建一个 Auto Scaling Group，我们需要

  1. 一个激活的 Elastic Load Balancer
  2. 启动实例的配置
  3. ASG 定义和 Scaling policies

所以我们先创建好 ELB，然后来到 Auto Scaling 的页面，选择一个镜像，然后创建启动配置，这里勾上 CloudWatch 监控选项，接着一路继续，可以选择和 ELB 一样的安全组，接着就可以创建了。

下一步需要起个名字，从 1 台机器开始，然后给定之前创建的 ELB，然后可以自定义最大和最小的机器数量，这里可以自定各种 CloudWatch 的警报然后设定对应要做的事情。这里也可以设定一个冷却时间（即一次 scaling 之后多久才能继续 scaling）

如何删除呢？如果在 EC2 页面删除，那么 ASG 会认为是实例失败，然后重新创建。所以需要改 ASG 的规则，设置最大和最小都是 0，就会自动进行关闭了。然后才可以删除对应的 ASG，一定要注意这个顺序。

Amazon CloudWatch

我们在项目中会使用 CloudWatch 来制定高效的 auto scaling policy。Amazon CloudWatch 让开发者可以监控 AWS 资源的状态。通过 API，开发者就可以知道最新的信息，并且据此来进行自动调整。CloudWatch 允许你设置警报，并且可以设置警报触发时需要完成的一系列动作。

CloudWatch 可以监控的 AWS 资源有：

  • EC2 instances
  • EBS volumes
  • EMR job flows etc
  • ELB Loads

对于 EC2 实例, CloudWatch 能帮助我们监控 CPU，内存和磁盘占用率（在网页上的监控那一栏可以看到）。更多信息可以参考 Amazon CloudWatch 文档。这里是一个介绍视频

视频主要讲解 CloudWatch 设定 Alarm 的一些逻辑，某条命令：

aws cloudwatch put-metric-data --metric-name PageViewCount --namespace "MyService" -- value 2 --timestamp 2014-02-14T12:00:00:00.000Z

Advanced Auto Scaling in AWS

这里我们需要用 AWS API 来创建或者启动最终测试所需的所有资源。最终测试中，load generator 会给你的 ELB 发送动态负载，然后 autoscale policy 会自动调整实例的数量，最终以实例的小时数和每秒的请求来进行统计。

因为时间限制，我们会用 48 分钟的测试代替实际的 1 天，也就是说，现实世界中的 1 个小时相当于测试中的 2 分钟。

系统每天会有早晚两次访问高峰（超过 1800 rps，访问 /lookup/random 页面），但是不巧的是，系统每天有 200 个实例小时的限制

关于实例小时 Instance Hour 一个 m3.medium 实例跑一个小时相当于 2 个实例小时，一个 m3.large 实例跑一个小时相当于 4 个实例小时。（注意这里会把分钟换算成小时数目）

预算控制

每超出限制的 1 个实例小时，就会对应在工资中扣一部分，所以要根据流量来进行调整。可以在 ELB 的 Healthy Hosts 图中看到具体的实例小时使用。

应该使用 ELB 来在实例间平分流量。借助 Auto Scaling 和 CloudWatch 能够对系统进行调整以适应流量变化。后面会给出一个例子，不过只要能完成任务，也可以自己设定具体的规则。

错误容忍

我们的 data center 实例可能会时不时崩溃，除非被标记为不健康，load balancer 还是会一直发送请求，你需要设置 ELB 来检测崩溃的实例以避免这种情况，当实例失败时，可能需要做对应的处理

总体流程

需要用 Java, Python 或者命令行工具来完成下列步骤，并且在完成之后上传源代码。这个流程可以在网页上模拟运行来了解具体的步骤。

一开始你可以不设置 CloudWatch 和 Auto Scaling Group，而是先用固定数量的实例来了解流量的模式。一旦清楚了流量的波动，就可以进行下面的测试了（对应步骤的图片有编号放在最后）

  1. 创建两个允许所有流量进出的且所有端口打开的安全组，其中一个会被关联到 ELB 和 ASG 上（之后需要通过代码删除）
  2. 创建一个 m3.medium 大小的 Load Generator（用之前的 ami，并且使用另外的安全组）。这个安全组可以事先创建，之后手动删除。
  3. 创建一个 ELB:
    • 重定向来自 load balance 的 HTTP:80 请求到 data center 的 HTTP:80
    • 设置 /heartbeat?lg=[your-load-generator-instance-dns-name] 页面作为健康状况检查的页面
    • 不提供正确的健康检查页面会使测试无效
  4. 为那些将要成为 Auto Scaling Group 的实例创建一个 Launch Configuration，参数为:
    • AMI ID
    • 实例类型: m3.medium 或 m3.large
    • 详细监控: enabled
  5. 分析了流量模式，设定一个好的调整规则。这里提供了一个参考的参数设置，但是用这个很难通过测试：
    • Group Size Start With: 1 instance
    • Subnet: Recommeded to choose the same availability zone(s) corresponding to your ELB
    • Load Balancing: Receive traffic from Elastic Load Balancer and choose your ELB
    • ELB Name: Choose your ELB name, make sure it’s alphanumeric
    • Health Check Type: ELB
    • Detailed Monitoring: enabled
  6. 创建 Auto Scale Policies: 这里提供了一个参考的参数设置，但是用这个很难通过测试：
    • Minimum Instance Size: 1
    • Maximum Instance Size: 2
    • Create a ScaleOut policy that automatically adds 1 instance to the auto scaling group.
    • Create a ScaleIn policy that automatically removes 1 instance from the auto scaling group.
  7. 创建 CloudWatch 警报，会在下列情境时触发合适的政策，这里提供了一个参考的参数设置，但是用这个很难通过测试：
    • Scale out when the group's CPU load exceeds 80% on average over a 5 minute interval.
    • Scale in when the group's CPU load is below 20% on average over a 5 minute interval.
  8. 把 CloudWatch 警报和 Auto Scaling Group 的 ScaleOut/ScaleIn 规则关联起来
  9. 设置好合适的标签，实在不行可以用命令行工具来进行设置。
  10. 开始测试前需要在 http://[your-load-generator-instance-dns-name]/password?passwd=[your-submission-password] 提交密码和 andrewid
  11. 最好让负载均衡器热个身，可以访问 http://[your-load-generator-instance-dns-name]/warmup?dns=[your-elb-dns]。Load Generator 会在 15 分钟内发送大量请求，可以在 ELB 达到你满意的状况下多做几次。热身时候花费的实例小时不算在总评里。
  12. ELB 热身完毕之后，访问 http://[your-load-generator-instance-dns-name]/junior 并输入你的 ELB DNS 来开始测试
    • 代码需要访问 http://[your-load-generator-instance-dns-name]/junior?dns=[your-elb-dns]
    • 可以在下面的网址查看具体的测试情况 http://[your-load-generator-instance-dns-name]/log?name=test.[testId].log
  13. 也可以通过 web 界面来监控 ELB，对应的图片是 HTTP 2XX 的请求（成功请求），如果你发现自己有很多失败的请求，那么可能是因为 ELB 没有配置好，不能根据情况进行资源调整
  14. 测试的最后会告知你的平均 RPS 和所有的实例小时
  15. 代码需要关闭除了 Load Generator 之外的其他所有资源。

5. An example of Auto Scaling Group configuration

6. An example of Auto Scaling Group configuration

10. Enter Submission Password Page on Load Generator

11. Warmup Page on Load Generator

12. Junior System Architect Test Page on Load Generator

12. A sample Junior System Architect test log

13. Sum of 2XX Https of ELB in CloudWatch

A sample test result

性能目标和得分

如果你的 rps = 1350 用了 150 实例小时, 那么得分是 18.75 + 25 = 43.75

如果你的 rps = 1800 用了 250 实例小时, 那么得分是 25 + 22.5 = 47.5

代码最后需要手动提交

任务目标

  1. 用 Java, Python 或者命令行工具来使用 AWS API
  2. 程序要启动一个 load generator 和多个 data center，注意 ami 和 类型要保证正确
  3. 程序需要创建安全组，启动 ELB 和初始化 ASG（包括启动配置，Auto Scale Policies 和 CloudWatch 警报）。需要等待所有资源创建完毕才能继续
  4. 程序需要在开始测试前给 ELB 热身，并且需要记录返回的 testId
  5. 程序需要等待测试完成，终止除 Load Generator 外的所有资源（安全组，ELB，ASG 和对应的其他资源）
  6. 在 http://[your-load-generator-instance-dns-name]/upload 提交源代码 [testId].zip 和 references 包含两部分的代码。这里 references 是必须要的。不要上传其他东西，只有上传代码才会对测试评分
  7. 如果还有预算剩余，可以测试不同的配置
  8. 不要忘记关闭 Load Generator

Hints

  • 一次完整测试要 48 分钟，注意时间
  • 可能需要手动运行几次测试
  • 热身是必须的
  • Scaling out 同样有些技巧，找到减轻添加新实例可能带来的影响的方法
  • Scale out 和 scale in 的规则很重要
  • 选择的地区可能会影响到测试结果
  • 不要同时开启多个 Load Generators，这样会给计算实例小时带来麻烦
  • 如果 rps 几乎是 0，看看 ELB 有没有连接到至少一台健康的实例，注意容错性
  • 如果实例小时是 0 (ih=0)，检查下 ELB 的健康检查页面有没有正确设置
  • 最好禁止 ELB 的跨区域负载均衡，把所有的 data center 放到一个地区
  • 会以最新的提交来评分，而不是最高的那次

一些资源

一些问题以及对策

  • Load Generator 有时候会发送消息让 Data Center 自杀
    • 解决方法是尽快让 ELB 发现挂了的 dc，快速反应重启
  • ELB warmup 也很重要
    • 要注意 warmup 的时间
  • 可能机器提升的数量赶不上实际的峰值
    • 长期保持多几台机器，并且让机器减少的速度变慢
    • 调整 policy 检测的数量
    • 让 ASG 的 cooldown 减小，快速反应
    • 5 台 基本是够用的
    • 可以一开始直接 boost 到最大，然后慢慢滑落，遇到峰值，直接再 boost 到最大
    • policy 中的数值都需要是 60 的倍数
  • 要想办法减少开机导致的性能损失

相关文章