Author: AWS Team


十二月

十一月

十月

九月

八月

七月

六月

五月

四月

二月

一月

2016


如何在1个小时之内轻松构建一个Serverless 实时数据分析平台    30 Dec

AWS Limit Monitoring ——书到用时方恨少,资源提限需趁早!    29 Dec

Amazon Polly – 支持47种语音与24种语言的文本到语音转换服务  19 Dec

开发者预览版——EC2实例(F1)携手可编程硬件    19 Dec

Amazon Lex – 构建对话语音与文本界面    15 Dec

如何在AWS上安装使用分布式TensorFlow    13 Dec

New feature launched to AWS China (BJS) region, operated by SINNET – Amazon RDS for SQL Server – Support for Native Backup/Restore to Amazon S3    5 Dec

由光环新网运营的AWS中国北京(BJS)区域现推出新RDS功能–支持SQL Server 本机备份/还原到Amazon S3   27 Nov

Amazon S3 和 Amazon Glacier 降价    27 Nov

构建健壮的混合云网络——BJS DX+VPN篇    23 Nov

构建健壮的混合云网络——BJS DX篇    23 Nov

构建健壮的混合云网络——BJS VPN篇    23 Nov

GPU为 Amazon Graphics WorkSpaces 提供助力    21 Nov

Amazon QuickSight全面上线——更快更易用的大数据商务分析服务    21 Nov

Amazon EC2 产品价格调降通知(C4,M4, 和T2实例)    21 Nov

利用 CloudWatch 搭建无人值守的监控预警平台    16 Nov

一键搞定云端网络环境,让您轻松迁移至AWS!    9 Nov

程序员的深度学习入门指南    07 Nov

如何在 AWS上构建基于 OpenSwan 的软件 VPN 解决方案    01 Nov

AWS的在线云计算专家,你用了吗?    31 Oct

CloudFront常见错误配置及解决方法    25 Oct

使用DMT工具迁移北京区域的数据库    18 Oct

VPC中NAT的那点事     17 Oct

CloudWatch Events监控您应用的安全    8 Oct

Oracle数据库迁移到AWS云的方案    28 Sep

使用AWS的数据库迁移DMS服务    28 Sep

手把手教你使用Amazon EMR进行交互式数据查询    27 Sep

使用Oracle Data Pump将数据库迁移到AWS的RDS Oracle数据库    26 Sep

手把手教你快速部署流量压测工具 – Bees with Machine Guns    26 Sep

优秀的领导者如何更进一步迈向伟大?    24 Sep

现代IT高管已然化身首席变革管理官    24 Sep

利用云方案进行实验时的四要与四不要    24 Sep

来自成功云企业的十项诀窍    24 Sep

助你决胜云时代的人才其实近在眼前    13 Sep

手把手教你如何用Lambda + Alexa调用echo设备    01 Sep

AWS Kinesis的Javascript交互方法    25 Aug

基于AWS 平台跳板机配置    08 Aug

如何使用AWS 命令行分段上传大文件    02 Aug

我喜欢我的Amazon WorkSpaces    02 Aug

算法改变世界 - 从Prisma 的走红说开去    02 Aug

为员工进行云培训时的11条箴言    07 Jul

畅谈CIO该如何合并业务和技术    07 Jul

协同合作伙伴 合力加速上云战略    07 Jul

在云端试验时的“有所为和有所不为”    07 Jul

专线直连AWS建立混合IT环境实务指南    01 Jul

手把手教你调校AWS PB级数据仓库    20 Jun

Token Vending Machine:移动应用客户端安全访问AWS服务的解决方案    20 Jun

分布式神经网络框架 CaffeOnSpark在AWS上的部署过程    16 Jun

打造DIY版Echo:树莓派+ Alexa 语音服务    01 Jun

使用Docker封装IPSec安全网关    30 May

将VMware 中的Ubuntu 12.04 映像导入成Amazon EC2 AMI    30 May

如何使用AWS Auto-reboot和Auto-recovery进一步提升单机高可用    16 May

AWS CTO对过去十年的经验总结 – 十条军规    12 Apr

AWS上的游戏服务:Lumberyard + Amazon GameLift + Twitch    12 Apr

为AWS北京区管理控制台集成ADFS访问    12 Apr

AWS的十年创新之路    12 Apr

空荡的数据中心,120种妙用!    12 Apr

媒体洞察 | 让企业自由发展的云时代    12 Apr

亚马逊 风力发电厂在福勒岭启动了!    12 Apr

新功能- Collectd的Amazon CloudWatch插件

原文:https://aws.amazon.com/blogs/aws/new-cloudwatch-plugin-for-collectd/

作者:Jeff Barr


我在2011年已介绍过Cloud Watch的特性,“您可以在Cloud Watch中查看图表、设置告警、并根据这些指标启动自动化操作,所使用的这些AWS资源指标会被存储于Cloud Watch中 。”您目前已有能力在Amazon Cloud Watch中存储一段时间范围内的业务、应用及系统的指标数据(参阅“Amazon Cloud Watch定制新指标”了解更多信息)。

今天我们将简化系统统计信息的采集过程,使用一个新的 CloudWatch plug for colletd将采集数据发送至CloudWatch中 。并通过collectd 多种类型信息的统计采集能力与cloudwatch存储、展示、警报和告警的功能的整合,您可以更好地获取EC2实例、本地硬件以及运行于其上应用程序的运行状态及其性能信息。该插件已经作为一个开源项目发布,我们期待您的反馈。

Collectd守护进程采用C语言编写,具有高性能和可移植性。它支持上百个插件 ,允许您收集有关ApacheNginx Web服务器性能统计数据、memory usage uptime等信息。

安装与配置

为了演示这些功能,我在EC2实例上安装并配置了Collectd服务及新Cloudwatch插件。

首先我创建了一条IAM策略,它具备将指标数据写入CloudWatch的权限:

然后我创建了一个IAM角色,允许EC2(运行collectd程序的实例)使用上述所建的策略:

如果我计划使用Collectd 插件从本地服务器或运行中的EC2实例收集统计信息,那请跳过这些步骤,采用创建一个具有适当权限的IAM用户作为替代方法。在我完成上述工作后,会将该用户的证书放在本地服务器或EC2实例中。

在策略和角色配置完毕后,选择该角色来启动一个EC2实例

登录并安装Collectd :

$ sudo yum -y install collectd

然后获取插件和安装脚本,设置脚本为可执行,并运行该脚本:

$ chmod a+x setup.py

$ sudo ./setup.py

回答一些交互问题确认安装过程无误,在完成配置之后就可启动Collectd :

Installing dependencies ... OK

Installing python dependencies ... OK

Copying plugin tar file ... OK

Extracting plugin ... OK

Moving to collectd plugins directory ... OK

Copying CloudWatch plugin include file ... OK

Choose AWS region for published metrics:

1. Automatic [us-east-1]

2. Custom

Enter choice [1]: 1

Choose hostname for published metrics:

1. EC2 instance id [i-057d2ed2260c3e251]

2. Custom

Enter choice [1]: 1

Choose authentication method:

1. IAM Role [Collectd_PutMetricData]

2. IAM User

Enter choice [1]: 1

Choose how to install CloudWatch plugin in collectd:

1. Do not modify existing collectd configuration

2. Add plugin to the existing configuration

Enter choice [2]: 2

Plugin configuration written successfully.

Stopping collectd process ... NOT OK

Starting collectd process ... OK

$

在Collectd运行并且插件安装配置完成后,下一步是确定感兴趣的统计信息,并配置插件将它们发布至CloudWatch中(每个指标的采集成本也是一个需考虑因素)。

文件/opt/collectd-plugins/cloudwatch/config/blocked_metrics包含已收集但尚未发布到CloudWatch的指标列表:


$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics

# This file is automatically generated - do not modify this file.

# Use this file to find metrics to be added to the whitelist file instead.

cpu-0-cpu-user

cpu-0-cpu-nice

cpu-0-cpu-system

cpu-0-cpu-idle

cpu-0-cpu-wait

cpu-0-cpu-interrupt

cpu-0-cpu-softirq

cpu-0-cpu-steal

interface-lo-if_octets-

interface-lo-if_packets-

interface-lo-if_errors-

interface-eth0-if_octets-

interface-eth0-if_packets-

interface-eth0-if_errors-

memory--memory-used

load--load-

memory--memory-buffered

memory--memory-cached

如您对内存消耗关注,可添加了一行到

/opt/collectd-plugins/cloudwatch/config/whitelist.conf

memory--memory-.*

Collectd配置文件(/etc/collectd.conf)中包含Collectd附加设置及插件设置。不需要做任何修改。

重新启动Collectd,以便所做的调整生效:

$ sudo service collectd restart

为了模拟内存消耗,可执行了一些消耗内存的程序,然后打开CloudWatch Console来查找并显示自定义指标:

该截图包括了对CloudWatch控制台即将推出增强功能的预览;如果看起来不一致也不必担心(请关注获取更多信息)。
如果监控一个生产实例,您还可以安装更多Collectd插件。以下是Amazon Linux AMI可用插件列表:

$ sudo yum list | grep collectd
collectd.x86_64                        5.4.1-1.11.amzn1               @amzn-main

collectd-amqp.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-apache.x86_64                 5.4.1-1.11.amzn1               amzn-main

collectd-bind.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-curl.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-curl_xml.x86_64               5.4.1-1.11.amzn1               amzn-main

collectd-dbi.x86_64                    5.4.1-1.11.amzn1               amzn-main

collectd-dns.x86_64                    5.4.1-1.11.amzn1               amzn-main

collectd-email.x86_64                  5.4.1-1.11.amzn1               amzn-main

collectd-generic-jmx.x86_64            5.4.1-1.11.amzn1               amzn-main

collectd-gmond.x86_64                  5.4.1-1.11.amzn1               amzn-main

collectd-ipmi.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-iptables.x86_64               5.4.1-1.11.amzn1               amzn-main

collectd-ipvs.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-java.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-lvm.x86_64                    5.4.1-1.11.amzn1               amzn-main

collectd-memcachec.x86_64              5.4.1-1.11.amzn1               amzn-main

collectd-mysql.x86_64                  5.4.1-1.11.amzn1               amzn-main

collectd-netlink.x86_64                5.4.1-1.11.amzn1               amzn-main

collectd-nginx.x86_64                  5.4.1-1.11.amzn1               amzn-main

collectd-notify_email.x86_64           5.4.1-1.11.amzn1               amzn-main

collectd-postgresql.x86_64             5.4.1-1.11.amzn1               amzn-main

collectd-rrdcached.x86_64              5.4.1-1.11.amzn1               amzn-main

collectd-rrdtool.x86_64                5.4.1-1.11.amzn1               amzn-main

collectd-snmp.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-varnish.x86_64                5.4.1-1.11.amzn1               amzn-main

collectd-web.x86_64                    5.4.1-1.11.amzn1               amzn-main

需了解事项

如果您使用的是5.5或更新版本的Collectd ,则会在默认情况下发布四个指标:

  • df-root-percent_bytes-used – disk utilization
  • memory–percent-used – memory utilization
  • swap–percent-used – swap utilization
  • cpu–percent-active – cpu utilization

如果您不希望发布它们,您可以从whitelist.conf文件中删除这些指标。

在Amazon Linux AMI,Ubuntu,RHEL和CentOS的软件仓库中,目前提供了较旧版本的Collectd; 如果从源代码或自定义repo进行构建安装,请注意默认行为的变化。

更多

除了本次所展示的内容外, 您可以安装更多的插件,然后配置whitelist.conf来向CloudWatch发布更多的指标。同时您可以创建CloudWatch警报 ,自定义仪表盘等。

要开始使用,请访问AWS Lab on GitHub,并下载collectd plugin for CloudWatch

译者介绍

 

倪晓峻,AWS专业服务顾问,负责基于AWS云计算项目的咨询和设计,具有超过十五年以上企业客户服务经验,致力于AWS服务在国内和全球的项目实施。在企业级解决方案,混合云架构,运营集成等领域有着广泛的设计与实践经验。在加入AWS之前曾任职VMware;HPE专业服务顾问,从事云计算/虚拟化架构设计及运维咨询工作,两次获得省部级科技进步奖励,参与OGC ITIL V3中文版的审定工作 。

 

 

使用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实战经验。

使用 Amazon EC2 Run Command 在不使用 SSH 访问的情况下大规模地管理实例

以下博文的投稿者为 Ananth Vaidyanathan (EC2 Systems Manager 高级产品经理) 和 Rich Urmston (Pegasystems 公司云架构高级总监),介绍了如何使用 EC2 Run Command 在不使用 SSH 的情况下管理大量 EC2 实例。

-Jeff


企业通常具有若干托管环境和成千上万的 Amazon EC2 实例。安全地管理系统非常重要,同时也要避免棘手的安全外壳 (SSH)。Run CommandAmazon EC2 Systems Manager 的一部分,可以让您以可控制和可审查的方式对实例 (或使用标签的实例组) 运行远程命令。这有效地提升了每天都要依赖 Run Command 服务的 Pega 云操作的效率。

您可以通过标准 IAM 角色和策略控制 Run Command 访问,定义文档以获取输入参数,控制用于返回命令输出的 S3 存储桶。您还可以与其他 AWS 账户共享文档或将文档公开。总而言之,Run Command 提供了一组很有用的远程管理功能。

优于 SSH

Run Command 优于 SSH 且 Pegasystems 已将其作为主要远程管理工具的原因如下:

Run Command 所需时间较短 – 安全地连接到一个实例需要几个步骤,例如要连接的跳转盒或要列入白名单的 IP 地址等。使用 Run Command,云操作工程师可以直接从笔记本电脑调用命令,而不必找到密钥甚至实例 ID。相反,系统安全性依赖于 AWS 身份验证、IAM 角色和策略。

Run Command 操作完全经过审查 – 使用 SSH,无法真正控制他们的操作,也没有审查跟踪。使用 Run Command,每个调用的操作都会在 CloudTrail 中进行审查,包括调用用户的信息、运行命令的实例、参数和操作状态。您拥有完全控制权,能够限制工程师可以在系统上执行的功能。

Run Command 无需管理 SSH 密钥 – Run Command 利用标准 AWS 凭证、API 密钥和 IAM 策略。通过与企业身份验证系统的集成,工程师可以根据其企业凭证和身份与系统进行交互。

Run Command 可以同时管理多个系统 – 使用 SSH 完成某些简单任务会很麻烦,如查看 Linux 服务的状态或在托管实例队列中检索日志文件。Run Command 允许您通过 ID 或标签指定实例列表,并在指定队列中并行调用命令。除非是最小的 Pega 群集,否则这会在进行故障排查或管理时提供巨大的优势。

Run Command 使自动化复杂任务更容易 – 实现操作任务标准化需要详细的程序文档或描述准确命令的脚本。在整个队列中管理或部署这些脚本会很麻烦。Run Command 文档提供了一种封装复杂功能并处理文档管理和访问控制的简单方式。当与 AWS Lambda 结合使用时,文档提供了强大的自动化平台来处理任何复杂任务。

示例 – 重新启动 Docker 容器

下面是一个用于重新启动 Docker 容器的简单文档示例。它包含一个参数,即要重新启动的 Docker 容器的名称。它使用 AWS-RunShellScript 方法调用命令。该服务自动收集输出并将输出返回调用方。有关最新文档架构的示例,请参阅创建 Systems Manager 文档

{
  "schemaVersion":"1.2",
  "description":"Restart the specified docker container.",
  "parameters":{
    "param":{
      "type":"String",
      "description":"(Required) name of the container to restart.",
      "maxChars":1024
    }
  },
  "runtimeConfig":{
    "aws:runShellScript":{
      "properties":[
        {
          "id":"0.aws:runShellScript",
          "runCommand":[
            "docker restart {{param}}"
          ]
        }
      ]
    }
  }
}

在 Pegasystems 上实际应用 Run Command

Pegasystems 配置系统位于AWS CloudFormation上,后者用于部署和更新 Pega 云资源。在此之上是 Pega Provisioning Engine,这是一个无服务器的基于 Lambda 的服务,它管理着 CloudFormation 模板和 Ansible 操作手册库。配置管理数据库 (CMDB) 跟踪每个部署和更新的所有配置详细信息和历史记录,并使用分层目录命名约定布置其数据。下图显示了不同系统的集成方式:

对于云系统管理,Pega 操作使用名为 cuttysh 的命令行版本和基于 Pega 7 平台的图形版本,名为 Pega Operations Portal。这两种工具都允许您浏览部署环境的 CMDB,查看配置设置,并通过 Run Command 与部署的 EC2 实例进行交互。

CLI 演示

下面是一个 CLI 演示,用于查看客户部署并使用 Run Command 与实例交互。启动 cuttysh 工具可以显示 CMDB 的根目录和配置客户的列表:

% cuttysh
d CUSTA
d CUSTB
d CUSTC
d CUSTD

您可以使用标准 Linux shell 命令 (例如 cdlscatgrep) 与 CMDB 进行交互。带有 s 前缀的项目表示可查看其属性的服务。带有 d 前缀的项目表示 CMDB 层次结构中可导航的子目录。在此示例中,将目录更改为 CMDB 层次结构的客户 CUSTB 部分,然后再将其更改为名为 env1 的配置 Pega 环境,位于 Dev 网络下。此工具显示了为该环境配置的项目。这些条目映射到配置的 CloudFormation 模板。

> cd CUSTB
/ROOT/CUSTB/us-east-1 > cd DEV/env1

ls –l 命令显示配置资源的版本。这些版本号映射到源代码控制 – CloudFormation、Ansible 和构成 Pega 云版本的其他组件的托管项目。

/ROOT/CUSTB/us-east-1/DEV/env1 > ls -l
s 1.2.5 RDSDatabase 
s 1.2.5 PegaAppTier 
s 7.2.1 Pega7 

现在,使用 Run Command 与部署的环境进行交互。要执行此操作,可使用 attach 命令并指定要进行交互的服务。在以下示例中,可挂载到 Pega Web Tier。使用 CMDB 和实例标签中的信息,CLI 可以找到相应的 EC2 实例,并显示有关它们的一些基本信息。此部署有三个实例。

/ROOT/CUSTB/us-east-1/DEV/env1 > attach PegaWebTier
 # ID         State  Public Ip    Private Ip  Launch Time
 0 i-0cf0e84 running 52.63.216.42 10.96.15.70 2017-01-16 
 1 i-0043c1d running 53.47.191.22 10.96.15.43 2017-01-16 
 2 i-09b879e running 55.93.118.27 10.96.15.19 2017-01-16 

在这里,您可以使用 run 命令调用 Run Command 文档。在以下示例中,您可以对实例 0 (列表中的第一个实例) 运行 docker-ps 文档。EC2 执行命令并将输出返回到 CLI,CLI 将显示输出。

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 docker-ps
. . 
CONTAINER ID IMAGE             CREATED      STATUS        NAMES
2f187cc38c1  pega-7.2         10 weeks ago  Up 8 weeks    pega-web

使用相同的命令和已定义的其他文档,您可以重新启动 Docker 容器,甚至将文件的内容撤回到本地系统。当您获得文件时,Run Command 还会在 S3 存储桶中留下一个副本,以备您希望将链接传递给同事。

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 docker-restart pega-web
..
pega-web

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 get-file /var/log/cfn-init-cmd.log
. . . . . 
get-file

Data has been copied locally to: /tmp/get-file/i-0563c9e/data
Data is also available in S3 at: s3://my-bucket/CUSTB/cuttysh/get-file/data

现在,利用 Run Command 可一次完成多个操作。在以下示例中,您挂载到具有三个正在运行的实例的部署,并希望查看每个实例的正常运行时间。将 par (并行) 选项与 run配合使用,CLI 将指示 Run Command 对所有实例并行执行正常运行时间文档。

/ROOT/CUSTB/us-east-1/DEV/env1 > run par uptime
 …
Output for: i-006bdc991385c33
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.42, 0.32, 0.30

Output for: i-09390dbff062618
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.08, 0.19, 0.22

Output for: i-08367d0114c94f1
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.36, 0.40, 0.40

Commands are complete.
/ROOT/PEGACLOUD/CUSTB/us-east-1/PROD/prod1 > 

总结

Run Command 通过提供更快的系统访问和跨一组实例运行操作,可以提高工作效率。Pega 云操作将 Run Command 与其他操作工具集成,为管理系统提供了一种简单安全的方法。这大大提高了操作效率,并更好地控制了每个主体在托管部署可以执行的操作。Pega 持续改进过程会定期评估操作者需要访问权限的原因,并将这些操作转换为新的 Run Command 文档以添加到库中。事实上,它们的长期目标是停止在启用 SSH 时部署云系统。如果您有任何问题或建议,请给我们留言!

-Ananth 和 Rich

AWS Marketplace 中的 Box 平台 – Lambda 蓝图和示例代码

Box 是一个基于云的文件共享内容管理系统,具有一个最近已在 AWS Marketplace 中提供的 API (Box 平台 – 云内容管理 API)。凭借一系列协作相关功能的推出,以及对安全性的重视,Box 已经在许多企业中得到了广泛应用 (请参见其成功案例页面中的列表)。

Box API 允许开发人员将内容体验构建到 Web 和移动应用程序中。今天我想向您介绍一些 [lambda] 蓝图和模板,这些蓝图和模板将可以帮助您在构建 AWS 应用程序时使用此 API 来简化用户身份验证和将元数据添加到新上传的内容中。这些模板基于 Box 节点 Lambda 示例而创建,可作为您开发工作的一个强大起点。我们来看一看这些蓝图,顺便查看一些我们在 Box 的好友所撰写的博客文章。

适用于 Lambda 的 Box 蓝图

蓝图显示了您如何通过 [apigateway] 调用 Box API 和将 Box webhook 连接到 Lambda 函数。要找到它们,请直接打开 Lambda 控制台,搜索 box

第一个蓝图使用存储在 BOX_CONFIG 环境变量中的安全凭证。您可以从 Lambda 控制台内设置此变量:

此蓝图中的代码会检索并记录通过凭证确定的用户的 Box User 对象。第二个蓝图会实施一个 Box webhook,置于 API Gateway 终端节点后面。它会接受请求,验证它们,然后将它们记录到Amazon CloudWatch中:

查看方便的博客文章

Box 的开发人员关系团队撰写了一些博客文章,向您展示如何将 Box 与多项 AWS 服务结合使用:结合使用 Amazon Cognito 和 Box 平台来管理用户身份验证 – 这篇文章向您展示了如何使用Amazon Cognito来为您的应用程序用户的登录页面提供支持。Cognito 将会处理身份验证和用户池管理,博客文章中所列出的代码会在用户首次登录时在 Box 中创建一个应用程序用户。该代码在 GitHub 上作为 box-node-cognito-lambdas-sample 提供。

利用 Amazon Rekognition 将基于深度学习的图像识别功能添加到您的 Box 应用程序中 – 这篇文章向您展示如何构建由Amazon Rekognition提供支持的图像标记应用程序。对于用户拍摄并上传的照片,应用程序会使用存储在Amazon Dynamodb中的元数据自动标记这些照片。文件上传时,代码会通过一个 webhook 激活。您可以在 GitHub 上的 box-node-rekognition-webhook 中找到代码。感谢我们在 Box 的好友抽出时间来创建了这些非常有用的开发人员资源。

-Jeff

全新推出 – 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

Amazon S3新版管理控制台的正确打开方式

Amazon Simple Storage Service(简称S3)是AWS在2006年发布的第一款云服务产品,S3作为对象存储具有海量存储、接口灵活、11个9持久性、价格便宜等特点,特别适合存放静态文件如图片、视频、日志以及备份文件等等,同时S3是AWS大数据解决方案中重要组成部分,以EMRFS的形式与EMR(AWS托管的Hadoop平台)结合提供计算与存储分离的灵活架构。

熟悉S3控制台的小伙伴一定发现,自从5月份开始,控制台的界面焕然一新,甚至有点无处下手,但熟悉起来后又有些爱不释手,下面我们将介绍下新版控制台带来了哪些新的功能,以及如何给你的工作带来极大效率提升。

新版控制台的操作说明,图文并茂,详见:

http://docs.amazonaws.cn/AmazonS3/latest/user-guide/what-is-s3.html

一、创建存储桶

创建存储桶的时候除了配置桶名、存储桶区域之外,还可以配置版本控制、日志、标签以及访问权限,现在用户可以在新版控制台使用“从现有存储桶复制设置”的功能,选择相同配置的存储桶即可,避免重复设置。

二、上传对象

在控制台下除了正常的通过点击上传按钮选择上传文件完成上传外,新版控制台支持在存储桶界面下,直接将待上传的对象拖放到页面上。通过新版控制台上传单个文件支持最大78GB。

对存储桶中对象的上传、删除、重命名等操作,页面底部可以看到该操作的进度及其他操作的历史记录。

三、ACL

我们可以通过配置存储桶及对象的ACL来实现存储桶和对象的访问控制,老版控制台的部分名称容易让人引起歧义,以存储桶ACL为例,如下图所示,其中查看权限是指查看该存储桶权限的权限,即查看该存储桶ACL的权限,而不是指查看存储桶的权限,编辑权限同样是指编辑权限的权限,不是编辑存储桶的权限。

在新版控制台中很好的避免了这点误区,分对象访问和权限访问,这里以存储桶的ACL举例,见下图:

其中一个新功能是我们可以在管理用户处添加其他帐号的规范ID(https://docs.aws.amazon.com/zh_cn/general/latest/gr/acct-identifiers.html )或帐号的Email向该帐号中的IAM user/role授权访问,以实现跨帐号访问,需要注意的是对方帐号的IAM user/role拥有对该存储桶的操作权限取决于此处我们设置的ACL以及对方帐号中IAM user/role本身policy设定的权限。

四、标签Tag

S3标签是随S3新版控制台一起发布的一个服务特性。标签可以帮助你对存储桶以及对象进行分类或标记,类似我们给EC2等资源添加标签一样,每个S3标签也是一个键值对,每个对象最多可添加10个标签键值对,键值对大小写敏感。通过使用标签,我们可以创建基于标签的IAM policy以实现细粒度的权限控制,比如标签为PHI的值为true时,仅供只读。同时,在使用S3数据生命周期管理、分析、指标等功能的时候,可以创建基于标签的过滤器,实现细粒度的资源管理。

S3 标签作为新服务特性,相应的API也同步发布,比如PUT Object tagging, GET Object tagging, DELETE Object tagging以及其他支持标签的API如PUT Object, GET Object, POST Object, PUT Object-Copy,详细可参考:

http://docs.aws.amazon.com/zh_cn/AmazonS3/latest/dev/object-tagging.html 需要注意的是,标签遵循最终一致性模型。

五、生命周期管理

数据通常从创建后会经历频繁访问、低频访问、极少访问的数据热度周期,相对于热数据,冷数据适合以成本更低的方式存储,比如热数据存放在S3 standard,冷数据存放在S3-IA,归档数据存放在Glacier等,以达到成本最优的目标。我们可以使用S3数据生命周期管理通过配置相应的规则来实现数据的生命周期管理,随着S3标签的发布,现在我们可以创建基于前缀和/或基于标签的规则,以实现更细粒度的资源管理。详细操作步骤见:

http://docs.amazonaws.cn/AmazonS3/latest/user-guide/create-lifecycle.html

六、存储类分析

存储类分析是新发布的功能,通过该工具,我们可以更加直观的了解到存储桶中的数据活跃情况,帮助我们决策何时将不常访问的数据从S3 Standard转换为S3-IA,即为配置数据生命周期管理提供数据支持。

同时,可以创建筛选条件,选择对整个桶中对象或者具有某些前缀或标签的对象进行分析,即对对象进行分类分析,需要注意的是,分析是从启用该功能后一段时间后才能看到结果(通常是24~48小时),并不是可以立刻可以看到分析结果。

通过存储类分析,我们可以可视化的了解到存储桶数据在过去30天的检索量,占比,以及多个时间范围段内数据存储与检索的情况,该数据每天更新,并且可以以csv的格式导出到S3存储桶以供下载,可使用Quicksight等BI工具进行展现。

csv中字段说明见:

http://docs.amazonaws.cn/en_us/AmazonS3/latest/dev/analytics-storage-class.html#analytics-storage-class-export-to-file

配置存储类分析详细操作步骤见:

http://docs.amazonaws.cn/AmazonS3/latest/user-guide/configure-analytics-storage-class.html

七、存储指标

CloudWatch可以监控S3存储桶的使用情况,过去只有两个指标:存储桶大小和对象数量,随着新版控制台的发布,又有两类指标发布,即请求指标和数据传输指标。

请求指标(收费功能)中包含GetRequest, PutRequest, ListRequest, AllRequest, PostRequest, DeleteRequest, HeadRequest, 4xxErrors, 5xxErrors。数据传输指标(收费功能)包含TotalRequestLatency,FirstByteLatency,BytesDownloaded,BytesUploaded。这些指标均为1分钟报告1次,我们可以通过这些指标快速了解和定位S3使用过程中的一些问题,比如当前S3存储桶是否遇到性能瓶颈,是否需要提case提升限制等等。同样可以通过配置基于前缀/标签的过滤器实现细粒度的管理。

S3请求速率及性能注意事项参见:

http://docs.amazonaws.cn/AmazonS3/latest/dev/request-rate-perf-considerations.html

指标详细解释可以见:

http://docs.amazonaws.cn/en_us/AmazonS3/latest/dev/cloudwatch-monitoring.html#s3-request-cloudwatch-metrics

配置请求指标操作步骤见:

http://docs.amazonaws.cn/AmazonS3/latest/user-guide/configure-metrics.html

八、存储清单

S3存储清单是S3 提供的一项存储管理工具,S3存储清单可以每天或每周输出指定S3存储桶或存储桶中指定前缀的对象及其相关元数据信息的列表,并以CSV文件的格式存储在指定的S3存储桶中。存储清单遵循最终一致性模型,即列表中可能没有最近添加或删除的对象信息,如果需要确认某一个对象的状态,我们可以使用HEAD Object REST API(或命令行,SDK)来获取该对象的元数据。

对于存储桶中有海量文件的用户而言,存储清单可以方便的帮助用户了解当前存储桶中的文件列表而不是像过去那样需要频繁调用GET Bucket API(每次返回最多1000个对象),从而加速一些业务工作流及大数据作业等等。

配置存储清单时,我们可以指定清单筛选条件、生成频率、存储位置、清单中包含的字段等等,一个存储桶可以配置多个清单。

配置存储清单操作步骤见:

http://docs.amazonaws.cn/AmazonS3/latest/user-guide/configure-inventory.html

看完上面S3新版控制台的介绍,是不是对这个新工具又有了一些新的认识,不妨将这些新功能用起来,优化成本,提升工作效率,在AWS上面诞生更多的创新应用。

作者介绍

王世帅,AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内教育、医疗行业的应用和推广。在加入AWS之前曾在国航担任系统工程师,负责存储方案的架构设计,在企业私有云方面有丰富经验。

利用Amazon ElastiCache寻找附近的X

基于地理信息的应用已经越来越深入到日常生活中,人们经常会在应用中寻找附近的朋友,车,餐厅或其它资源。而与此同时,随着物理网技术及设备的普及,应用需要更加实时和精确的处理来自各种数据源(包括用户手机,各种传感器设备及其他系统)的大量数据,以完成相关的搜索和计算距离等操作。

架构

对于开发者来说,Redis因为其性能上的优势往往会被采用作为位置数据的缓存,只是在3.2版本之前需要代码中把位置数据进行Geohash后才能有效的排序和分析。不过3.2版本后,Redis已经能够原生支持基于位置信息的存储,计算及搜索了。Amazon ElastiCache是AWS提供的托管型的数据缓存服务,借助该服务,用户能够在云中轻松部署、运行和扩展分布式内存数据存储或缓存。 Amazon ElastiCache 的Redis引擎是一项与 Redis 兼容的内存服务,兼具 Redis 的易用性和强大功能,同时还可为要求最苛刻的应用程序提供适用的可用性、可靠性和性能,提供单节点和多达 15 个分片的群集,从而可将内存数据扩展到高达 3.55TiB。这里,我们可以基于Elasticache并结合AWS其他服务构建出以下的示例架构:

1)终端设备获取GPS位置信息,定时或基于事件将数据上传到云端。在AWS上可以选择使用IoT或Kinesis等托管型服务作为数据收集的接收端,也可以使用部署在EC2/Lambda上的自定义服务。

2)所有位置信息写入可以自动扩展的DynamoDB,基本Schema包含设备Id/Timestamp/Geo location, 方便历史查询或轨迹查询。

3)打开DynamoDB流,用KCL或Lambda监听DynamoDB的数据改变,并将当前变化的位置数据更新到Elasticache中建立基于Geospatial的索引缓存。

4)手机应用搜索附近资源时,部署在EC2/Lambda的查询服务利用Elasticache geospatial直接获取结果。

实现

如前文所述,步骤1和2可选择的方案很多,比如采用AWS IoT服务甚至可以无需任何代码仅通过配置即可完成云端的功能讲数据实时写入相应的DynamoDB表中。因此,本文将着重介绍如何实现前文架构中的3和4步:

a) 打开DynamoDB 流,获取流的ARN用于读取,如下图:

读取DynamoDB流数据有三种方式:利用Kinesis adapter,利用低级别API以及利用Lambda函数来进行读取。从易用性的角度来说,当然是Lambda函数最简单,不需要考虑shard,吞吐和checkpoint等问题而专注于业务逻辑。但是Lambda函数并不是在所有的AWS区域都支持,因此本文采用第一种方式利用Kinesis adapter完成读取。具体参考文档:http://docs.amazonaws.cn/amazondynamodb/latest/developerguide/Streams.KCLAdapter.html

b) 在读取流的同时,我们需要将最新的地理位置信息利用GEOADD更新到Elasticache中。前文提到Redis在3.2版本后,Geospatial Indexing已经被原生支持,而它实际上是Sorted List数据结构的一种扩展,即排序 key扩展成了经纬度,如下图所示的数据结构,并且可以方便的使用基于地理信息的API,例如GEOADD——添加地理位置 。

通过Elasticache可以快速构建出一个Redis环境,包括支持shard的集群模式,如下图所示。

构建完成后,通过Elasticache提供的终端节点就可以访问cache了。

需要注意的是如果选择的Redis是集群模式,那么就得同步升级支持Redis集群模式的客户端SDK用以开发。因为Redis的集群提供的是分片功能,它会把不同的slots分布在不同的节点上,需要由客户端通过CRC16(Key)取模从而计算出数据在哪个节点上。目前可以支持redis集群模式的客户端有很多,比如本文用到的java的jedis以及nodejs的ioredis。

综合a,b两步的示例代码的StreamCacheProcessor.java如下(其余代码参考http://docs.amazonaws.cn/amazondynamodb/latest/developerguide/Streams.KCLAdapter.Walkthrough.CompleteProgram.html ):


import java.nio.charset.Charset;
import java.util.HashMap;
import java.util.HashSet;
import java.util.List;
import java.util.Map;
import java.util.Set;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import redis.clients.jedis.GeoCoordinate
import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.JedisCluster;

import com.amazonaws.services.dynamodbv2.streamsadapter.model.RecordAdapter;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.IRecordProcessor;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.IRecordProcessorCheckpointer;
import com.amazonaws.services.kinesis.clientlibrary.lib.worker.ShutdownReason;
import com.amazonaws.services.kinesis.model.Record;

public class StreamsCacheProcessor implements IRecordProcessor {

        private static Log LOG = LogFactory.getLog(StreamsCacheProcessor.class);

  private Integer checkpointCounter;

  private String clusterHost;
  private int port;
  private JedisCluster jedis;

public StreamsCacheProcessor(String clusterHost,int port) {
      this.clusterHost=clusterHost;
      this.port=port;
}

@Override
public void initialize(String shardId) {
      Set jedisClusterNode=new HashSet();
      jedisClusterNode.add(new HostAndPort(clusterHost,port));
      jedis=new JedisCluster(jedisClusterNode);
 checkp ointCounter = 0;
}
@Override
public void processRecords(List records, IRecordProcessorCheckpointer checkpointer) {
 for (Record record : records) {
  String data = new String(record.getData().array(), Charset.forName("UTF-8"));
  LOG.debug("Received the data as:"+data);
  if(record instanceof RecordAdapter)
     com.amazonaws.services.dynamodbv2.model.Record streamRecord = ((RecordAdapter) record).getInternalObject();
    //新增GPS数据更新到Elasticache中
    if(streamRecord.getEventName().equals("INSERT")){
    Map coordinateMap = new HashMap();
    double longitude = Double.parseDouble(streamRecord.getDynamodb().getNewImage().get("longitude").getN());
    double latitude = Double.parseDouble(streamRecord.getDynamodb().getNewImage().get("latitude").getN());
    String deviceId = streamRecord.getDynamodb().getNewImage().get("deviceId").getS();
    coordinateMap.put(deviceId, new GeoCoordinate(longitude, latitude));

    jedis.geoadd("bikes", coordinateMap);
    LOG.info("Updated "+deviceId+" GPS information as:"+longitude+","+latitude);
    }
  }
checkpointCounter += 1;
if(checkpointCounter % 10 == 0){ //checkpoint大小需根据实际需求调整
  try {
    checkpointer.checkpoint();
   }
  catch (Exception e) {
    e.printStackTrace();
   }
  }
 }
 
}

@Override
public void shutdown(IRecordProcessorCheckpointer checkpointer, ShutdownReason reason) 
{
  if(reason == ShutdownReason.TERMINATE) {
    try {
      checkpointer.checkpoint();
    }
    catch (Exception e) {
     e.printStackTrace();
    }
   }
  }
}

c)在完成地理信息的实时更新后, 可以基于Elasticache的数据利用GEORADIUS搜索周边的资源。使用nodejs示例代码如下:


var express = require('express');
var app = express();
var Redis = require('ioredis');

var cluster = new Redis.Cluster([{
    port:6379,
    host:'lab-cluster.4bh9j8.clustercfg.cnn1.cache.amazonaws.com.cn'
}]);

app.get('/bikes', function(req,res){
if(req.query['longitude'] && req.query['latitude']){
console.log ('longitude = %s,latitude = %s',req.query['longitude'],req.query['latitude']);
cluster.send_command('GEORADIUS',
[ 'bikes',req.query['longitude'],req.query['latitude'],2000,
'm',
'WITHDIST',
'WITHCOORD',
'COUNT',
10], (error, reply) =>{

if (error) {
res.status(500).send("无法获取附近车辆信息");
return;
}

var stations = reply.map( (r) =>{
return {
name: r[0],
distance: `${r[1]} m`,
coordinates: {
latitude:  Number(r[2][1]),
longitude: Number(r[2][0])
} }
});

res.status(200).json(stations);
});
}
});

var server = app.listen(8080,function(){
var host = server.address().address
var port = server.address().port
console.log("应用实例,访问地址为 http://%s:%s", host, port)
});

基于以上代码,服务端就可以返回最近的10个资源以及每个资源离当前位置的距离。例如:
请求
http://hostname or elb address/bikes?longitude=116&latitude=39.4
返回


[
 {
  "name": "48093ba0-f8f1-49f0-b312-285800341b08",
  "distance": "1117.8519 m",
   "coordinates": {
    "latitude": 39.40640623614937,
    "longitude": 116.01002186536789
 }
},
{
  "name": "950fb5df-c0ff-4a95-90ea-2f5f574c5796",
  "distance":"1305.5083 m",
  "coordinates": {
   "latitude": 39.40184880750488,
   "longitude": 116.01500004529953
  }
 },
……
]

d)通过封装http请求构建手机应用。

总结

Redis Geospatial功能可以让开发者更高效的搜索和计算位置信息的记录。同时,Amazon ElastiCache提供的托管Redis服务大大简化了对于Redis集群的维护工作,包括搭建,备份和迁移等工作。最后,自动扩展的Amazon DynamoDB则负责位置信息数据的持久化和检索,而它的流功能也使得数据能够快速实时的流转起来。

 

作者介绍

赵霏,AWS解决方案架构师。负责基于AWS的云计算方案架构咨询和设计,同时致力于AWS云服务在国内的应用和推广。他拥有超过13年IT行业从业经验,长期专注于企业IT云转型、物联网、移动互联网、Devops等领域,在大规模后台架构、分布式计算和自动化运维等方面有着广泛的设计和实践经验。

使用 Amazon Redshift 中的查询监控规则管理查询工作负载

本文主要介绍了如何利用Amazon Redshift的WLM(工作负载管理)功能,监控数据仓库的查询性能,从而优化队列优先级并保障关键任务的执行。本文还列出了三个常见场景,给出了简单的配置过程。

众所周知,数据仓库的工作负载由于周期性、潜在高开销的数据探索查询以及SQL开发人员不同的技能水平等会出现比较大的性能变化。

为了在面临高度变化的工作负载下仍然能使Redshift集群获得较高的性能,Amazon Redshift工作负载管理(WLM)使您能够灵活地管理任务优先级和资源使用情况。通过配置WLM,短时间,快速运行的查询不会停留在需要较长时间运行的查询之后的队列中。 但尽管如此,某些查询有时可能会陷入不相称的资源分配,并影响系统中的其他查询。 这种查询通常被称为流氓查询或失控查询。

虽然WLM提供了一种限制内存使用并将超时查询移动到其他队列的方法,但多重精细控制依然很需要。您现在可以使用query monitoring rules查询监视规则为查询创建资源使用规则,监视查询的资源使用情况,然后在查询违反规则时执行操作。

工作负载管理并发和查询监控规则

在Amazon Redshift环境中,单个集群最多可以同时连接500个连接。 吞吐量(Throughput)通常表示为每小时的查询量以最大化性能,但像MySQL这样的行数据库使用并发连接数进行衡量。 在Amazon Redshift中,工作负载管理(WLM)可以最大限度地提高吞吐量,而不太考虑并发性。 WLM有两个主要部分:队列和并发。 队列允许您在用户组或查询组级别分配内存。 并发或内存是如何进一步细分和分配内存到一个查询。

例如,假设您有一个并发度为10的队列(100%内存分配)。这意味着每个查询最多可以获得10%的内存。 如果大部分查询需要20%的内存,那么这些查询将交换到磁盘,导致较低的吞吐量。 但是,如果将并发度降低到5,则每个查询分配20%的内存,并且最终结果是更高的吞吐量和更快的SQL客户端响应时间。 当从行数据库切换到基于列的数据库的时候,常见的错误认知是认为更高的并发性将产生更好的性能。

现在你了解了并发性,这里有更多关于查询监控规则的细节。 您可以基于资源使用情况定义规则,如果查询违反了该规则,则会执行相应的操作。 可以使用十二种不同的资源使用指标,例如查询使用CPU,查询执行时间,扫描行数,返回行数,嵌套循环连接等。

每个规则包括最多三个条件,或谓词,和一个动作。谓词由一个指标,比较条件(=、<、>),和一个值组成。如果所有的谓词满足任何规则,该规则的行动被触发。可能的规则操作包括日志记录、跳过任务和中止任务。

这样就可以在导致严重问题前捕获流氓或失控查询。该规则触发一个动作来释放队列,从而提高吞吐量和响应速度。

例如,对于专用于短时运行查询的队列,您可能会创建一个规则来中止超过60秒的查询。 要跟踪设计不当的查询,您可能会有另一个规则记录包含嵌套循环的查询。 在Amazon Redshift控制台中有预定义的规则模板让您使用。

使用场景

使用查询监控规则来执行查询级别的操作,从简单地记录查询到中止查询,以下所有采取的操作都记录在STL_WLM_RULE_ACTION表中:

  • 日志记录(log):记录信息并继续监视查询。
  • 跳出(hog):终止查询,并重新启动下一个匹配队列。 如果没有其他匹配队列,查询将被取消。
  • 中止(abort):中止违反规则的查询。

以下三个示例场景显示如何使用查询监视规则。

场景1:如何管理您临时查询队列中的未优化查询?

连接两个大表的失控查询可能返回十亿行或更多行。 您可以通过创建规则来中止返回超过十亿行的任何查询来保护您的临时队列。 在逻辑上如下所示:

IF return_row_count > 1B rows then ABORT.

在以下截图中,任何返回BI_USER组中超过十亿行的查询都将中止。

场景2:如何管理和控制未调优的CPU密集型查询?

偶尔引起CPU飙升的查询不一定有问题。 然而,持续的高CPU使用率可能会导致其他并发运行查询的延迟时间增加。 例如,在较长时间内使用高百分比CPU的未调优查询可能是由于不正确的嵌套连接引起的。

您可以通过创建规则来中止超过10分钟使用80%或更多CPU的任何查询来提高群集吞吐量和响应能力。 在逻辑上如下所示:

IF cpu_usage > 80% AND query_exec_time > 10m then ABORT

以下屏幕截图显示,任何使用超过80%CPU超过10分钟的查询都将中止。

您可以通过使用80%CPU记录查询超过5分钟进一步扩展此规则,并终止使用了80%CPU超过10分钟的查询。 在逻辑上如下所示:

IF cpu_usage > 80% AND query_exec_time > 5m then LOG and  IF cpu_usage > 80% AND query_exec_time > 10m then ABORT

以下屏幕截图显示,系统将记录使用了80%CPU并运行5分钟以上的查询,并且中止使用了80%CPU并运行超过10分钟的查询。

场景3:如何监视和记录没有任何进展的查询?

例如,在混合工作负载环境中,ETL作业可能会将S3中的大量数据从大量的数据传输到Amazon Redshift中。 在数据摄取过程中,您可能会发现一个COPY命令被卡在队列中而没有进行任何进展。 这样的查询可能会增加数据吞吐延迟并影响业务SLA。

您可以通过创建跟踪和记录查询的规则来查找此类查询。 创建一个规则来查找具有低CPU利用率和过长执行时间的查询,例如,使用1%CPU记录查询超过10分钟的规则。 在逻辑上如下所示:

IF cpu_usage < 1% AND query_exec_time > 10m then LOG

以下屏幕截图显示,系统将记录使用1%CPU并运行10分钟以上的查询。

总结

Amazon Redshift是一个功能强大,全托管的数据仓库,可以在云计算框架中显著提升性能并降低成本。 但是,查询集群资源(流氓查询)可能会影响您的体验。

在这篇文章中,我们讨论了如何使用查询监视规则帮助过滤和中止不符合要求的任务。 这反过来也可以帮助您在支持混合工作负载时顺利地进行业务操作,以最大限度地提高集群性能和吞吐量。

如果您有任何问题或建议,请在下面留言。


关于作者

Gaurav Saxena是Amazon Redshift查询处理团队的软件工程师。 他负责Amazon Redshift工作负载管理和性能改进的几个方面。 在业余时间,他喜欢在他的PlayStation上玩游戏。

Suresh Akena是AWS专业服务的高级大数据/ IT转型架构师。 他与企业客户合作,为大型数据战略提供领导,包括迁移到AWS平台,大数据和分析项目,并帮助他们在使用AWS时优化和改进数据驱动应用的上市时间。 在业余时间,他喜欢和他8岁和3岁的女儿一起玩,看电影。

译者:

屈铭,AWS中国专业服务团队大数据咨询顾问

曾供职于亚马逊电商和澳大利亚智能交通研究机构,拥有多年电商平台和智慧供应链的数据分析经验。现任职于AWS中国专业服务团队,主要为客户提供云上大数据平台设计,数据仓库解决方案和优化,数据建模等咨询服务。

如何在Amazon EC2 Container Service上实现服务高可用的自动伸缩

1. 简介

Amazon EC2 Container Service (ECS)是Amazon提供的一项Docker容器管理服务,可以让您轻松构建、运行、管理您的Docker容器服务。ECS Service是ECS的重要组件,它可以在集群中运行指定数量的任务,当某个任务不可用时,它会重新启动新的任务,维持住任务的指定数量。这个特性从一定程度上保证了服务的可用性,但当面对突发流量,ECS本身并不能动态地进行任务数量的扩展,当流量较少时,ECS也无法动态地进行任务数量的缩减。为解决此问题,可以使用Auto Scaling和Amazon CloudWatch等实现服务的自动伸缩,保证服务高可用。本文将介绍一个运用Auto Scaling在ECS中实现服务高可用的方案,并通过对方案构建过程的剖析,让您对高可用、自动伸缩的服务架构有更进一步的了解。

2. 方案构建

2.1 整体结构图

本方案使用AWS CloudFormation模板声明整个资源堆栈所需资源和相关配置,并实现自动化构建。关于AWS CloudFormation相关知识,请通过以下链接了解:CloudFormation入门

从上面这个结构图可以看出以下主要组成部分:

  1. 初始由两个跨AZ的Container Instance组成的ESC Cluster。
  2. 初始ESC Service中有两个task。
  3. Service Auto Scaling与CloudWatch结合,当Service维度的 CPUUtilization与Threshold满足设定的触发条件时,触发CloudWatch Alarm,CloudWatch Alarm根据设定的Scaling Policy进行Task数量伸缩。
  4. Auto Scaling Group与CloudWatch结合,当Cluster维度的CPUReservation与Threshold满足设定的触发条件时,触发CloudWatch Alarm,CloudWatch Alarm根据设定的Scaling Policy进行实例数量的伸缩。

2.2 准备工作

(1)准备好CloudFormation模板脚本

请从这里(点我)下载用于构建整个资源堆栈的模板脚本文件。

或者通过点击下面按钮来运行堆栈:

(2)准备好Lambda Function

本方案在Auto Scaling Group中的实例关闭时,会调用一个实现自动切换Draining状态的Lambda Function。那么在构建整个堆栈之前,需要先准备好这个Lambda Function。这里我们使用Python编写了这个脚本auto_drain.py来实现此功能。您可以了载包含了这个脚本的压缩包(点我)

下载完成后,请将它上传到您账户上同个Region的S3 Bucket中。记住这个S3 Bucket Name,在构建堆栈时,将它传给Lambda Function S3 Bucket 这个参数。

2.3 构建过程

(1)构建堆栈

打开您的CloudFormation控制面板,使用模板脚本创建堆栈,创建成功后,打开堆栈“输出”栏,可以看到ALBDNS输出值如下所示:

将这个URL复制到浏览器访问,看到It Works字样,表示堆栈构建成功。

(2)测试service auto scaling

我们在模板中定义了基于ECS Service维度的CPU使用率(CPU Utilization)指标进行自动伸缩service的task个数。初始状态下,我们设置Service的Desired Count(参见模板中的ServiceDesiredCount参数)为2,查看ECS Service Management Console,选中左边栏“集群”,再选中as-demo-cluster,点击“ECS Service实例”。可以看到现在有两个容器实例,每个容器实例运行一个任务,总共有两个任务。

接下来我们利用Apache ab压测工具进行测试,向我们的ALB发送30000条请求,并发为每秒1000。相应的ab命令如下:

$ ab -n 300000 -c 1000 http://as-in-publi-xxxxxxxxxxxxxx/

等待ab请求运行完成后,查看此时ECS Service中实例的状态,如下图所示,可以发现在某台实例上新增加了一个task,总的task数量变成了3个,也就是成功触发了Service Scale out。

等待几分钟,再次查看ECS Service中实例的状态,可以看到task总数量又变成了2个,即当Service CPUUtilization小于我们设的的Threshold一定时间(默认设置的是5分钟)后,自动触发了Service Scale in。

(3)测试cluster auto scaling

同样使用Apache ab进行压测,不过为了达到效果,需要加大请求数量和并发数量。

使用以下ab命令(当然您可以根据自己实际情况进行调整)

$ ab -n 1000000 -c 2000 http://as-in-publi-xxxxxxxxxxxxxx/

如果遇到 socket:Too many open files异常。可以使用以下命令修改linux系统最大打开文件数

$ ulimit -n 2048

等待压测结束后,查看ECS中实例的状态(因为实例的启动与容器的启动不同,耗费时间比较长,可能需要等待几分钟才能看到效果),如下图所示,Cluster自动增加了一台实例。

等待一段时间后,再次查看ECS Service中实例的状态,如下图所示,Cluster自动减少了一台实例。

(4)测试自动切换实例Draining状态

我们使用Lambda Function实现在Scale in时自动切换实例到Draining状态(具体讲解见后面章节)。

当前集群中总的实例数量为2,我们通过修改Auto Scaling Group的desired count(在EC2管理窗中界面选中我们模板创建的Auto Scaling Group,修改desired count),将它设为1,这样Auto Scaling会自动关闭一台实例,看看运行的任务数量有什么变化。

可以看到被停掉的实例状态自动切换成了DRAINING,任务也被移到了另一台实例上。

3. 基于两个维度的自动伸缩

CloudWatch监听ECS中的四个指标,分别是CPUUtilization、MemoryUtilization、CPUReservation和MemoryReservation。这四个指标可以分为两大类,前两者是指资源使用率,后两者是指资源占有率。本方案通过集群和服务这两个维度,分别对占用率和使用率进行监控,定制不同的伸缩策略,从而实现自动伸缩。

3.1 什么是资源使用率和资源占有率

资源使用率(CPUUtilization和MemoryUtilization)是指ECS集群(或服务)中所有运行着的任务实际使用资源的总和除以EC2 Container Service集群(或服务)总的资源得到的数值,表现的是集群或服务中资源的使用情况

资源占有率(CPUReservation和MemoryReservation)是指ECS集群(或服务)中所有运行着的任务申请占有的资源的总和除以EC2 Container Service 集群(或服务)总的资源得到的数值,表现的是集群或服务中资源的剩余情况

3.2 基于服务中CPU使用率实现服务自动伸缩

为了简单起见,本方案只监控CPU的使用率和占有率。

当服务面对越来越大的流量时,服务中CPU使用率快速上升,这时可以根据这个CPU使用率来动态地增加任务数量,以达到分担负载的作用。而不是根据CPU占有率来进行扩展,因为无论流量如何变大,CPU占用率是与服务中任务数量相关的,任务数量不同,CPU占用率也不会改变。

在本方案中,具体的构建过如下:

(1)首先,我们声明了对服务中task desired count作为Auto Scaling调整的对象ScalableTarget,ResourceId指向我们创建的ECS Service代码如下:

ServiceScalingTarget:

    Type: AWS::ApplicationAutoScaling::ScalableTarget

    DependsOn: DemoService

    Properties:

      MaxCapacity: !Ref ServiceMaxSize

      MinCapacity: !Ref ServiceMinSize

      ResourceId: !Join [”, [service/, !Ref ‘ECSCluster’, /, !GetAtt [DemoService, Name]]]

      RoleARN: !GetAtt [ServiceAutoscalingRole, Arn]

      ScalableDimension: ecs:service:DesiredCount

      ServiceNamespace: ecs

(2)我们声明了两个Scaling Policy,分别针对Scale Out和Scale In两种情况,当Scale Out时修改ServiceScalingTarget中的Service Desired Count,增加1个task;当Scale In时修改ServiceScalingTarget中的Service Desired Count,减少1个task。主要代码如下:

ServiceScaleOutPolicy:

    Type: AWS::ApplicationAutoScaling::ScalingPolicy

    Properties:

      PolicyType: StepScaling

      PolicyName: StepOutPolicy

      ScalingTargetId: !Ref ‘ServiceScalingTarget’

      StepScalingPolicyConfiguration:

        AdjustmentType: ChangeInCapacity

        MetricAggregationType: Average

        StepAdjustments:

        – MetricIntervalLowerBound: “0”

          ScalingAdjustment: “1”

 

  ServiceScaleInPolicy:

    Type: AWS::ApplicationAutoScaling::ScalingPolicy

    Properties:

      PolicyType: StepScaling

      PolicyName: StepInPolicy

      ScalingTargetId: !Ref ‘ServiceScalingTarget’

      StepScalingPolicyConfiguration:

        AdjustmentType: ChangeInCapacity

        MetricAggregationType: Average

(3)最后,我们声明两个CloudWatch Alarm,分别在Service的CPUUtilization满足Threshold关系时,触发Scale Out和Scale In的Alarm。

ServiceCPUUtilizationScaleOutAlarm:

    Type: AWS::CloudWatch::Alarm

    Properties:

      EvaluationPeriods: !Ref ServiceCPUUtilizationScaleOutMinutes

      Statistic: Average

      Threshold: !Ref ServiceCPUUtilizationScaleOutThreshold

      AlarmDescription: Alarm if Service CPUUtilization greater then threshold.

      Period: ’60’

      AlarmActions: [!Ref ‘ServiceScaleOutPolicy’]

      Namespace: AWS/ECS

      Dimensions:

      – Name: ClusterName

        Value: !Ref ECSCluster

      – Name: ServiceName

        Value: !GetAtt [DemoService, Name]

      ComparisonOperator: GreaterThanThreshold

      MetricName: CPUUtilization

 

  ServiceCPUUtilizationScaleInAlarm:

    Type: AWS::CloudWatch::Alarm

    Properties:

      EvaluationPeriods: !Ref ServiceCPUUtilizationScaleInMinutes

      Statistic: Average

      Threshold: !Ref ServiceCPUUtilizationScaleInThreshold

      AlarmDescription: Alarm if Service CPUUtilization less then threshold.

      Period: ’60’

      AlarmActions: [!Ref ‘ServiceScaleInPolicy’]

      Namespace: AWS/ECS

      Dimensions:

      – Name: ClusterName

        Value: !Ref ECSCluster

      – Name: ServiceName

        Value: !GetAtt [DemoService, Name]

      ComparisonOperator: LessThanThreshold

      MetricName: CPUUtilization

3.3 基于集群中CPU占有率实现集群自动伸缩

当服务中任务的数量随着流量增大也不断增加时,集群中CPU的占有率也会上升,当CPU占有率不断上升,表示可用的资源已不多了,此时需要扩展新的实例,增加整个集群总的资源。

在本方案中,具体的构建过如下:

(1)首先声明两个Scaling Policy,当集群Scale Out时修改集群中的实例数量,增加1个实例;当Scale In时修改集群中的实例数量,减少1个task。主要代码如下:

ClusterScaleOutPolicy:

    Type: “AWS::AutoScaling::ScalingPolicy”

    Properties:

      AdjustmentType: “ChangeInCapacity”

      AutoScalingGroupName:

        Ref: “ECSAutoScalingGroup”

      PolicyType: “StepScaling”

      MetricAggregationType: “Average”

      StepAdjustments:

        –

          MetricIntervalLowerBound: “0”

          ScalingAdjustment: “1”

 

  ClusterScaleInPolicy:

    Type: “AWS::AutoScaling::ScalingPolicy”

    Properties:

      AdjustmentType: “ChangeInCapacity”

      AutoScalingGroupName:

        Ref: “ECSAutoScalingGroup”

      PolicyType: “StepScaling”

      MetricAggregationType: “Average”

      StepAdjustments:

        –

          MetricIntervalUpperBound: “0”

          ScalingAdjustment: “-1”

(2)我们声明两个CloudWatch Alarm,分别监听的指标是集群的CPUReservation,当CPUReservation满足Threshold设定的关系时,触发Scale Out和Scale In的Alarm。主要代码如下:

ClusterCPUReservationScaleOutAlarm:

    Type: AWS::CloudWatch::Alarm

    Properties:

      EvaluationPeriods: !Ref ClusterCPUReservationScaleOutMinutes

      Statistic: Average

      Threshold: !Ref ClusterCPUReservationScaleOutThreshold

      AlarmDescription: Alarm if Service CPUUtilization greater then threshold.

      Period: ’60’

      AlarmActions: [!Ref ‘ClusterScaleOutPolicy’]

      Namespace: AWS/ECS

      Dimensions:

      – Name: ClusterName

        Value: !Ref ECSCluster

      ComparisonOperator: GreaterThanThreshold

      MetricName: CPUReservation

 

  ClusterCPUReservationScaleInAlarm:

    Type: AWS::CloudWatch::Alarm

    Properties:

      EvaluationPeriods: !Ref ClusterCPUReservationScaleInMinutes

      Statistic: Average

      Threshold: !Ref ClusterCPUReservationScaleInThreshold

      AlarmDescription: Alarm if Service CPUUtilization less then threshold.

      Period: ’60’

      AlarmActions: [!Ref ‘ClusterScaleInPolicy’]

      Namespace: AWS/ECS

      Dimensions:

      – Name: ClusterName

        Value: !Ref ECSCluster

      ComparisonOperator: LessThanThreshold

      MetricName: CPUReservation

4. Cluster scale in时切换实例到Draining保证服务容量

我们的ECS集群并不是一创建好就一成不变的,特别是当集群空闲的时候,触发了EC2的Auto Scaling Group的缩减实例之后. 有些时候我们需要关闭其中某个实例,无论是由于系统升级、安装软件、还是为了节省运行成本。那么在关闭实例时,实例上正在运行的task怎么办呢?把它们全杀掉?那可不行,那样就等于减小了整个ECS服务的容量和负载能力,对性能有很大影响。另外就是当直接关闭EC2机器的时候杀死其中的task, 可能造成运行在上面的task处理的请求异常终止,而影响到我们所提供服务的SLA, 这种情况下,将实例切换到Draining状态就是一种解决方案。

当您要关闭集群中某个实例时,运行在这个实例上的task会被停止,然后ECS会在集群中另一个(或多个)实例上运行这些被停掉的task,从而保证整个ECS Service 的task数量保持不变,保证了整个服务容量和负载能力不受影响。同时,当实例被设置成为Draining状态之后,ECS将会自动平滑关闭EC2宿主机中的task资源,利用定义task模版时候所定义的放置规则,将其移动到其他拥有剩余资源的集群中的宿主机上. 关于实例Draining的更多信息,请参见文档.

在本方案中,我们使用AWS SNS 和Lambda实现了实例在集群的Auto Scaling Group Scale in时关联Auto Scaling的LifecycleHook,实现被关闭前调用Lambda Function自动切换Draining状态,将task转移到集群中其它实例上。

我们定义了一个Lambda Function运行Python脚本auto_drain.py,这个脚本主要完成两个工作:

(1)判断传到Lambda Function中的event是否包含autoscaling:EC2_INSTANCE_TERMINATING,是的话就将这个实例状态切换成Draining,这样ECS就会自动停止此实例上所有运行中的task,并在集群中别的实例启动同样数量的task。

切换实例到Draining状态的代码:

containerStatus = containerInstances[‘status’]

            if containerStatus == ‘DRAINING’:

                tmpMsgAppend = {“containerInstanceId”: containerInstanceId}

            else:

                # Make ECS API call to set the container status to DRAINING

                ecsResponse = ecsClient.update_container_instances_state(cluster=clusterName,

containerInstances=[containerInstanceId],status=’DRAINING’)

(2)判断实例上还有没有task正在运行中。如果仍然有运行中的task,则过发送一条SNS通知重新触如这个Lambda Function。如果实例上所有task都已经被停止,则解开LifecyleHook,使这个实例被停掉。

根据task运行情况做不同处理的代码:

# If tasks are still running…

            if tasksRunning == 1:

                response = snsClient.list_subscriptions()

                for key in response[‘Subscriptions’]:

                    if TopicArn == key[‘TopicArn’] and key[‘Protocol’] == ‘lambda’:

                        snsClient.publish(

                            TopicArn= key[‘TopicArn’],

                            Message=json.dumps(message),

                            Subject=’Publishing SNS message to invoke lambda again..’

                        )

            # If tasks are NOT running…

            elif tasksRunning == 0:

                completeHook = 1

                try:

                    response = asgClient.complete_lifecycle_action(

                        LifecycleHookName=lifecycleHookName,

                        AutoScalingGroupName=asgGroupName,

                        LifecycleActionResult=’CONTINUE’,

                        InstanceId=Ec2InstanceId)

                    logger.info(“Response received from complete_lifecycle_action %s”,response)

                    logger.info(“Completedlifecycle hook action”)

                except Exception, e:

整个Python脚本代码,可以解压您在准备工作中下载的auto_drain.zip,查看auto_drain.py脚本文件。

5. 总结

本文主要介绍了如何在ECS 中使用 Auto Scaling、Amazon CloudWatch和其他常用AWS服务实现高可用,可伸缩的服务架构,并结合Lambda Function和AWS SNS 做到当集群中由于Auto Scaling缩减关闭某个实例时,自动切换实例状态到Draining,将task转移到其他实例上,保证服务容量以及回收实例资源时候的task的平滑过渡。通过本套方案,可以让ECS服务在可用性和伸缩性上得到保证,从而为您解决实际业务场景中相类的问题提供一定的帮助和思路。您也可以在本方案基础上,结合实际业务需求,定制自己的Scaling Policy、监控指标和监控维度,实现更符合您需求的解决方案。

作者介绍

李磊,AWS解决方案架构师,负责基于AWS的云计算方案的架构设计,同时致力于AWS云服务在国内和全球的应用和推广。在大规模并发后台架构,电商系统,社交网络平台、互联网领域应用,DevOps以及Serverless无服务器架构等领域有着广泛的设计与实践经验。在加入AWS之前超过十年的开发和架构设计经验, 带领团队攻克各种技术挑战,总是希望站在技术的最前沿。