Category: 开发运维


使用云伙伴系统,让您的迁移之旅不再孤单

Edmunds.com 全面迁移到 AWS 的相关经验

伙伴系统这个概念已经使用了数十年,应用范围涵盖生活的许多方面,包括学习、工作和探险。无论涉及哪一方面 (比如大学新生与其学长配对、空军飞行员与其僚机驾驶员或者您的周末潜水伙伴),大多数伙伴系统不外乎两个目的。一个是安全性,通常出现在需要双方相互照顾的体育或危险活动中。另一个是新入学的学生或新来的员工与经验更丰富的伙伴配对以便获得培训和指导,以免出现常见的新手错误,从而自信满满地快速进步。

就我个人来讲,如果 2012 年在我开始全面向云迁移时拥有云伙伴,一定能帮我解决不少难题并省去实验的麻烦。当时,我是北美地区最大的汽车购物网站之一 Edmunds.com 的首席信息官。

但与现在不同的是,当时很难从正在成功迁移的其他公司找到大量伙伴系统资源。如果具备大规模全面的参考案例 (除 Netflix 之外)、托管迁移计划或成熟的咨询合作伙伴生态系统,则迁移工作会容易得多。幸运的是,现在有大量专注于云迁移的人员、流程和技术,这意味着,组织再也不用像我们当时迁移 Edmunds.com 那样孤军奋战了;而且,加快云使用率和更大限度节省成本的相关专业技术水准也在不断提升,这使全面迁移战略变得比以往更加可行。

作为一名终身冲浪爱好者,我可以告诉您,如果有伙伴系统的帮助,即使在危险条件下,冲浪也不是什么了不起的事情。单打独斗被认为是终极精神追求。而如今,如果我要去世界上的陌生地方冲浪,则更愿意采用更加实用的方法。在登上冲浪板之前,我会试着找一位曾经去过那里的“伙伴”,从他那里了解所需的所有海浪相关信息。例如,珊瑚礁有多浅?有鲨鱼出没吗?哪种潮汐状况最适合冲浪?听取了这些方面的建议并学习了别人的经验后,我心中的疑虑通常会打消不少,而且冲浪体验也会得到提升。

最近,我加入了一个前任首席信息官 (他们构成 AWS 企业战略团队) 团体。我们的目标是帮助技术高管思考和拟定其云优先策略,为此我们所采取的一种方法是:制定和简化新型迁移加速计划,以利用我们所积累的知识 (经验是没有压缩算法的)。作为前任首席信息官和 AWS 客户,我们曾经负责过自己的云迁移工作,并在此过程中帮助过各种类型和规模的企业完成了转型,我们的经历就像我到一个新地方冲浪时从伙伴那里获得提示和建议一样。

回想一下,我从 Edmunds.com 迁移经历中得到了三点重要启示;正如您将看到的,即使我们在 2016 年初关闭了最后一个 Edmunds.com 数据中心,我们经历的过程也仍然与大部分企业迁移当前所经历的云采用阶段非常接近 —

我们将完全停止运营这个高性能数据中心

实际上,这不是当时的确切想法。作为当时的首席信息官,我的主要目标是交付技术能力,以超前满足业务需求。在进行云迁移前的 7 年里,我们不知疲倦地工作,开发出了一种被认为极其高效的基础设施运营和 DevOps 实践。但是,这种效率需要企业付出代价,尽管它提供了每日自动发布能力和前所未有的可靠性。这种代价就是,公司需要将越来越多的有限资源分配给支持代码 (私有云和 DevOps 工具集),从而导致没有足够的资源用于面向客户的应用程序代码 (新的客户功能和服务)。我们需要一种新的模式来控制支持代码与客户代码的比率,而不用牺牲任何功能。

2011/2012 年出现的新兴云趋势为企业提供了一种备选方案,它强调与单个公司孤军奋战相比,公有云 (尤其是 AWS 的规模) 能提供更好的基础设施和更优质的服务,而且价格更具竞争力。然而事实却不容乐观,围绕它的新闻层出不穷,报道内容无外乎:与成熟的本地安装相比,云更加昂贵且不太稳定。Netflix 早期曾采用 AWS,当时的情况有力地证明了这一论点:较成熟的大型企业可以在云中运行关键操作;但当时,我们无法为 Edmunds.com 业务找出更类似的参考实施。

同行参考在当时对我们来说极其重要,因为没有任何值得称道的伙伴系统迁移资源可以帮助我们利用成熟的云采用模式。

在缺乏这方面知识的情况下,我们分两步构建了我们的业务案例,这最后成为了任何公司进行云迁移的标准做法:

  1. 概念验证项目,即展示在云中运行关键操作的可行性。
  2. 全面云运营的实际财务模型,它能够经受住时间的考验,并至少展示出与当前基础设施的支出状况基本相当 (或成本更低) 的特征。

事后想来,决定采用完整版核心 Edmunds.com 网站来验证云的可行性并不是进行概念验证的最快或最简单的选择。但在将近 6 个月时间内经过几个专门的工程师的反复试验后,我们获得了无可争议的证据,甚至连之前总是跟我们唱反调的人都认为,云是 Edmunds.com 的最佳选择。如今,AWS 和出色的系统集成商开发了伙伴系统方法 (如停放区,这是 AWS 云采用框架的一个组件),让迁移业务案例比我们当初采取的方法进展得更加快速。

我们对结果非常满意,进而转入下一步,开始深入探究云经济。这时,我们尚未发现通过采用云原生架构实现的生产力的巨大飞跃,但我们相信迁移到云不太可能会毁掉公司。

开发财务模型似乎是一项同样让人望而却步的任务。此类模型必须真实,并且必须避免激进的优化假设。我们已经做到了高效和节俭,但老实说,我不知道最后我们的运营费用是会增加还是会减少。因此,经过一个多月的分析,我惊讶地发现,我们开发的保守财务模型证明,在完成向 AWS 迁移的两年计划 (与主要数据中心租约到期时间一致) 后,我们竟然会节省一小笔运营费用。这还不包括资本设备支出每年所节省的数百万美元。这个计划也有点像沙袋,因为它以纯粹的简单地搬运假设为基础,而我们确信在整个迁移过程中运营支出会大幅降低,但我们不知道如何提前证明这一点。

财务模型表现不俗,概念验证结果也极具说服力,因此,我们怀着激动的心情向首席运营官做了汇报,这次汇报受到了热烈欢迎,首席运营官立即批准了我们的 AWS 迁移建议。

我要指出的一个形式上的错误是,我过分强调了自由现金流的节省。我几乎完全忽略了运营支出这个优势,认为它不是通过审批的前提条件;相反,我将侧重点放在了更大的组合现金节省数字上。但结果证明,支持运营支出预测假设对首席运营官而言更加重要。

现在 AWS 云经济小组重点关注的是,增强业务案例宣传信息和预测更深层次的云费用节省的能力。但是,这样一个通过成熟技术帮助客户进行迁移和 TCO 建模的团队当时尚未完全成形。现在,AWS 云经济小组会在云迁移早期提供一些最好的伙伴系统资源,因为该小组拥有数千个迁移的相关数据,此类数据可通过最大限度提高业务案例中的服务器利用率和员工工作效率,帮助预测和量化节省的费用。

我认为我们实际上要在这方面取得成功

它并非不堪一击。但如果项目涉及每一个应用程序和系统,就会面临相当大的风险,而且企业绝不会容忍因后端增强功能而导致的任何延迟或中断。不过,完成应用程序和数据迁移后,您会发现组织最大的风险与停机或性能问题毫不相干,而是与能否完成迁移相关。在迁移过程中停滞不前不仅会影响您的云 TCO 模型,还会让公司长期无法专注于优先事务。

如前所述,在云迁移中尽早“寻找伙伴”真得非常重要。已经创建的大量伙伴系统资源可帮助避免我们在 Edmunds.com 迁移中遇到的诸多难题,而 AWS 迁移加速计划 (MAP) 等计划或 AWS Database Migration Service (DMS) 等工具就是广泛使用且具有针对性的伙伴系统资源的两个示例。所开发的这些资源融合了来自数千个客户迁移的意见和经验,此类计划和工具涵盖了大量成熟的迁移模式,例如,从 Oracle 迁移到 Amazon 的 RDS 托管数据库服务

尽管如此,在独自完成迁移的过程中,我们确实学到了一些有价值的东西。我相信,对于任何想要顺利轻松地到达终点的云驱动型组织来说,这些知识尤为重要 —

  1. 调整您的初始迁移原则并不会对架构造成损坏或导致迁移失败。您的云迁移策略原则必须足够灵活,以适应云灵活性及在云中运行的新经验。实际上,我们在开始 Edmunds.com 迁移时所秉持的原则是,仅利用核心计算 (EC2) 和存储 (S3、EBS)。但是,我们之所以这么做是因为对更高级别的 AWS 服务 (如 Amazon RDSAmazon CloudWatch Amazon DynamoDB) 缺乏了解。我们很快意识到这些新型云原生服务的集成和成本优势,包括在客户代码上花费更多时间的功能。现在,Edmunds.com 使用的 AWS 服务有三十多种。
  2. 为重构决策使用两周法则。我们是在灵活的原则 (可为我们提供重构机会) 下开始我们的两年迁移计划的;但由于数据中心租约的原因,任何因素都不能延迟两年目标,因此,直接迁移通常成为默认方法。然而,在迁移工作全面展开之后,团队却开发出了沿用至今的特定的两周经验法则。如果我们能在两周内重构堆栈内的次优组件或服务,我们就会重构,而不是直接迁移。例如,基于 NFS 的共享存储架构位于重构列表的前面,但它不符合两周法则,因此,我们将其安排在了迁移窗口的末期。另一方面,诸如负载均衡、缓存、OS 分配和 DNS 等许多对象也在迁移过程中使用新的两周法则进行了重构。根据迁移时间表或开发周期,您可能需要使用不同的时间段,但两周或一个开发冲刺是 Edmunds.com 的最优约束条件。此处提到的优质伙伴系统资源是指 AWS Application Discovery Service,系统集成商使用这项服务帮助公司发现和映射应用程序的依赖关系,然后再确定哪些内容适合直接迁移,哪些有机会重构。现在,您可以通过最近发布的 AWS Migration Hub 跟踪迁移状态。我会在以后的文章中介绍两周法则的其他相关信息。但在此期间,请务必阅读“将应用程序迁移到云的 6 大策略”,作者是 Stephen Orban,目前担任 AWS 全球企业战略主管。这篇文章很有启发性,提供了非常实用的构建思路。
  3. 您无需弃用现有团队并重新聘用一组云专家。Edmunds.com 没有专门为云迁移招聘一名员工,更不用说“云专家”了。在这方面我们的经验是:建立清晰的领导机制和等效的云卓越中心 (CCoE),并设定明确的目标和关键结果。我们的云迁移团队负责人 Ajit Zadgaonkar 的最初职责是领导我们的自动化测试团队 (SDET)。在与传统运营团队协作进行自动化配置及持续集成和交付方面,他的团队已经具备一定的经验。同样,Stephen Orban 也就此主题发布了一篇文章,建议您阅读他的这篇文章:“You Already Have the People You Need to Succeed With the Cloud”(您已经拥有成功实现云迁移所需的人才)。在这方面,需要考虑的另一个重要事项是,您要在新来的云/开发运营工程师与现有团队之间做出选择,前者对您的环境一无所知,后者在关键应用程序的依赖关系、流程和业务需求方面拥有多年的实践经验。我的 AWS 同事 Jonathan Allen Capital One 中详细介绍了他经历的这个过程,以培训现有团队并让其为云迁移做好准备。

弄清楚人员和文化等因素与您做出的技术决策同等重要,因为在迁移加速进行并涉及更多应用程序时,他们使内部伙伴系统能够确保组织内的一致性。

我庆幸自己没有把未来搞砸

第三点也是最后一点启示更多的是关于迁移结束之后的事宜 – 从我在组织内的新职位和角度来看。在我们完成向 AWS 的迁移之后不久,我不再担任首席运营官/首席信息官,转而成为 Edmunds 的首位首席数字官。担任这个职务后,我的主要职责是开发下一代广告平台并将新的商业模式推向市场,例如,在线汽车零售和消息传递应用程序。因此,我从云服务提供者变身为消费者。回想起来,我绝对是一名要求苛刻的客户!

将所有应用程序和数据都按计划迁移到 AWS 之后,Edmunds.com 成功地将 IT 开支削减了 30%。通过开始使用云原生架构 (自动扩展、微服务、临时计算) 优化或重新思考堆栈的每一个组件,或者通过直接使用 AWS 服务将组件完全替换掉,团队实现了更大的节省。我的新团队努力完成的许多计划都有技术框架,这与最初迁移到 AWS 的对象不同,而且在有些情况下,它们完全是无服务器的。现在,已经出现了针对无服务器架构的新兴伙伴生态系统,它正在改变云和本地安装之间的对比结果。

这些新型 AWS 服务 (如 AWS LambdaAWS Elastic BeanstalkAmazon Kinesis AWS GLUE) 绝不可能由 Edmunds.com 在内部合理地开发出来,但它们以之前难以想象的速度为客户提供了新功能。展望未来,在数据中心内可以完成的操作与云原生服务之间的差距只会越来越大。例如,主流的机器学习和人工智能与普通 Web 应用程序所要求的技术框架大相径庭。在内部维护这些不同的技能组合和专门的计算容量对大部分组织来说绝非最佳选择。

我会在以后的文章中,持续提供这方面的见解和建议。当然,目的是为了帮助您尽快上手,以便重塑自己的技术和业务。

在此期间,请试用伙伴系统,尽快开始或完成您的迁移。然后,您将可以使用云原生服务,减少用于维护基础设施的支持代码义务并交付更多客户代码。

最大的变化从简单的步骤开始 —

Philip Potloff
@philippotloff
potloff@amazon.com
企业战略家

 

EKK—基于AWS托管服务的日志收集分析系统

译者:刘磊

应用系统日志的收集分析对于运维来说是至关重要的。一个可靠、安全、可扩展的日志收集分析解决方案在分析应用系统异常终止原因时能够让一切都变得轻松起来。

在这篇博文里,我们会探讨除了流行的ELK(Elasticsearch, Logstash, and Kibana)解决方案之外的另一种选择,EKK解决方案(Amazon Elasticsearch Service, Amazon Kinesis, and Kibana)。EKK架构最大的好处是使得你不再需要自己亲自安装、部署、管理以及扩展日志收集分析系统,而将精力集中在分析日志,排除应用系统异常上面。

下面我们会介绍如何使用EKK架构来收集和分析Apache web服务器的日志,先来看看EKK架构的组成部分。

Amazon Elasticsearch Service是一个流行的搜索和分析引擎,主要用来提供实时的应用系统日志和点击类流量的分析服务。本文中我们会利用Amazon ES将Apache的日志存储并索引起来,作为一项托管服务,Amazon ES可以很轻松地在AWS云上进行部署、操作和扩展。此外使用托管服务,还能大大减轻管理上的工作,例如打补丁、异常监测、节点恢复、备份、监控等等。因为Amazon ES自身内部已经和Kibana进行了集成,所以省去了安装和配置等工作。获取Amazon ES的更多信息,请参考Amazon Elasticsearch Service

Amazon Kinesis Agent 是一个易于安装的单机版Java应用程序,它负责收集和发送日志数据。它会持续监控Apache web服务器的日志文件,并且将新的数据不断地发送到传输数据流中。同时它还负责文件回滚、生成检查点、异常发生后的重试,以及以时间序列为准可靠地发送日志文件。获取更多利用Amazon Kinesis Agent的信息,请参考Amazon Kinesis AgentGitHub 相关项目

Amazon Kinesis Firehose提供了往AWS中加载流式数据的捷径。本文中,Firehouse会获取并自动加载日志的流式数据到Amazon ES里,随后在S3中还会再进行一次备份。获取Amazon Kinesis Firehose的更多信息,请参考Amazon Kinesis Firehose

有了AWS CloudFormation的帮助,你只需要使用一个模板就能快速实现EKK架构。模板里准备了Apache web服务器,并使用Amazon Kinesis Agent和Firehose将它的访问日志发送给Amazon ES集群,同时在S3中备份日志数据,最后使用Amazon ES Kibana endpoint来对你的日志进行可视化分析。

AWS CloudFormation template帮你快速完成如下工作:

  • 准备Amazon ES集群。
  • 准备Amazon EC2实例。
  • 安装2.4.23版本的Apache HTTP服务器。
  • 在Apache HTTP服务器之上安装Amazon Kinesis Agent。
  • 准备ELB(弹性负载均衡)。
  • 创建Amazon ES索引和相应的日志对应关系。
  • 创建Amazon Kinesis Firehose发送系统。
  • 创建所有的IAM角色以及相应的权限规则。例如,Firehose需要将日志数据备份到S3中,那么就需要往目标S3桶上传数据的权限。
  • 为Firehose发送系统配置CloudWatch 日志流和日志组,以便在日志发送出现异常时进行排查。

EKK架构示意图:

要搭建本文中的EKK架构,你需要以下先决条件:

  • US West区域的Amazon EC2密钥对。
  • US West区域的S3桶。
  • US west区域的默认VPC。
  • 具有管理员权限的IAM角色,用来确保Amazon ES和Amazon S3通过Firehose获取到EC2上的日志数据

让我们开始吧:

从启动AWS CloudFormation模板开始创建整个系统

1. 在AWS CloudFormation控制台上,选择来 启动模板。请确保你在US West区域。

提示:如果你想下载这个模板并随后上传至AWS CloudFormation,你可以从随后给出的S3桶里面下载模板到你本地的电脑中。

2. 选择下一步

3. 在详细设置页面,提供以下信息:

a)软件栈名称:为你的EKK系统命名

b)实例类型:选择安装Apache HTTP服务器的EC2实例类型

c)密钥:选择US West区域的密钥对

d) SSH位置:可以通过SSH连接到EC2实例的IP地址范围,默认为0.0.0.0/0

e)web服务端口:Web服务器的监听端口,默认为80

4. 选择下一步

5. 在选项页面,为AWS CloudFormation模板提供你想要的可选信息,然后选择下一步。

6. 在回顾页面,检查模板的各项设置,点击确认然后选择创建系统。

整个创建过程大约耗时10-15分钟。

配置Amazon Kinesis Agent

等待AWS CloudFormation创建完整个EKK系统,然后开始配置Amazon Kinesis Agent。

1. 在AWS CloudFormation控制台中,选择资源标签页,找到Firehose发送系统的名称。你在随后的第3步中需要它来配置Agent。

2. 在输出标签页,找到并记录下Web服务器的公有IP地址。你随后需要通过它SSH登录到Web服务器上配置Agent。获得更多关于通过SSH连接EC2实例的信息,请参考通过SSH登录你的Linux实例.

3. 在Web服务器的命令行上,运行以下命令:

sudo vi /etc/aws-kinesis/agent.json

该命令会打开配置文件,agent.json,内容如下:

{ "cloudwatch.emitMetrics": true, "firehose.endpoint": "firehose.us-west-2.amazonaws.com", "awsAccessKeyId": "", "awsSecretAccessKey": "", "flows": [ { "filePattern": "/var/log/httpd/access_log", "deliveryStream": "", "dataProcessingOptions": [ { "optionName": "LOGTOJSON", "logFormat": "COMMONAPACHELOG" } ] } ] }

4. 将在资源标签页获得的Firehose发送系统名称填入deliveryStream栏目中,然后保存并退出。

5. 在命令行上运行以下命令:

sudo service aws-kinesis-agent restart

6. 在AWS CloudFormation 控制台中查看Amazon ES对应的逻辑ID域

7. 在AWS Elasticsearch服务页面中你可以查看到由AWS CloudFormation创建的ES集群

配置Kibana并分析日志数据

Amazon ES为每一个ES域都默认提供了Kibana的安装,你可以在域的展示页面找到Kibana endpoin的相关信息。

1. 在Amazon ES控制台,选择Kibana endpoin

2. 在Kibana中,为索引名称和模式选项键入logmonitor。该值是你为Web访问日志创建的AWS ES索引名称。来自AWS ELB的健康检查会产生Apache的访问日志,随后流经整个EKK数据线,最后在Kibana中被可视化展现出来供分析所用。

3. 在时间选择中,选择datetime

4. 在Kibana控制台,选择发现标签页来观察Apache日志。

Kibana提供了条形图、折线图、散点图、直方图、饼图等来对日志文件进行分析。

过去30天访问Web服务器的IP地址饼图

过去5分钟内访问Web服务器的IP地址条形图

你还可以将http响应、IP地址等各类信息绘制成图表,甚至组合它们,以此来提供对于Apache日志的更深洞见。

监控日志收集分析系统

在Firehose控制台上选择流数据,然后选择监控标签页来查询CloudWatch中针对Firehose发送系统的度量值。

当日志发送失败后,Amazon S3和Amazon ES上等日志会帮助你定位问题。比如,如下的截图显示了因为索引上的日期映射没有和源日志文件保持一致。

结论

本文中,我们展示了如何通过Amazon Kinesis Agent, Amazon ES和Firehose将Apache日志传输至Kibana并进行可视化分析。值得注意的是,Firehose会根据应用系统产生日志的速率来自动进行伸缩。获取更多如何扩展Amazon ES集群的信息,请参考Amazon ES 开发指南.

综上所述,使用类似Amazon ES和Amazon Kinesis Firehose这类的托管服务,让管理和维护日志收集分析系统变得十分轻松。更棒的是,你还可以通过在日志流数据上直接运行SQL语句来进一步提升EKK系统的性能和功能。而这一切都可以基于本文中给出的AWS CloudFormation 模板

 

译者介绍:

刘磊,曾供职于中国银联电子支付研究院,期间获得上海市科技进步一等奖,并申请7项国家发明专利。现任职于AWS中国专家服务团队,致力于为客户提供基于AWS服务的专业大数据解决方案、项目实施以及咨询服务。

利用AWS混合云容灾架构实现企业级IT的云转型(一)

作者:王宇

摘要:AWS混合云容灾架构不但能够实现企业级的应用云容灾,还能够帮助企业级客户平滑实现企业IT的云转型。

在我们谈论容灾时,我们在谈些什么?

容灾是一个非常传统的话题,是在产生IT系统的第一天开始就必须要考虑的问题。总的来说它主要是指“数据中心灾难、区域性灾难和人为误操作”三个方面造成对IT系统的灾难时的恢复工作。

在中国,“两地三中心”的容灾架构已经广泛的被企业级用户认可,成为企业级容灾架构的标准,但由于建设成本高,周期长等原因,实际按照此标准建设的企业少之又少。而AWS的混合云容灾架构,就是在AWS的云环境中实现“两地三中心”,同时利用AWS云中资源的弹性大幅度降低资源成本和建设以及运维的复杂性。

软件定义一切,AWS云容灾解放企业IT生产力

如果企业客户已经在自己的数据中心中完成了容灾环境的搭建,势必消耗了大量了资源,包括机架空间、电力、IT资源、人力资源等等,而容灾环境本身是一个并不产生经济效应的保障性系统,对企业资源的占用巨大。AWS云资源池通过软件定义的方式,能够打造与企业内部完全相同的复杂IT环境,实现企业级应用的完整镜像,随着应用容灾系统迁移至AWS云中,可以将企业现有的容灾中心转变成生产中心,从而扩大客户自建数据中心的承载能力,或大幅降低IT资源的运营成本。

随时容灾演练,确保备用环境可用性

在传统的容灾环境中,容灾演练是一个令人头疼的大问题,因为容灾环境的建设不是“一锤子买卖”,随着生产环境和数据的不断变化,容灾环境必须跟随生产环境改变,否则在发生灾难时就无法实现业务的快速切换和启动,因此,定期的容灾演练是必须的。而传统环境中的容灾演练要配合硬件和软件厂商,耗时耗力,效果还往往不尽如人意。在AWS云环境中,能够轻松实现容灾环境的复制,从而与生产环境并行的实现容灾环境的测试演练,通过实际的演练来验证容灾环境的可用性以及数据的完整性,在演练结束后可以随时将演练环境删除或关停,演练成本和复杂程度都大幅降低。

AWS云容灾实现秒级回滚,解决人为错误

在生产环境中,由于人为的误操作、系统升级、补丁等操作造成的对IT系统以及数据的破坏很难防范,尤其是有一些操作和BUG导致系统在运行一段时间后才能发现故障,而此时容灾环境的数据有可能已经被覆盖,难以恢复。在AWS云中实现的容灾环境能够借助数据快照、数据日志等功能,除了能够保存最新的业务数据意外,还能够实现数据的秒级回滚。在发现系统出现故障后,不但能够切换到容灾环境中的最新数据,还能够选择过去24小时中的任意时间点进行恢复,从而解决了容灾系统中的脏数据问题。

利用AWS容灾环境切换,实现生产系统的平滑上云

现有的IT生产系统环境往往错综复杂且数据量大,让这样的系统上云往往需要冗长的数据搬迁和环境搭建时间,生产系统面临长时间的停机,无法接受。AWS容灾解决方案能够与生产系统并行地传输生产数据,并在云中搭建与企业内部结构相同的生产系统镜像环境,待云中数据与生产中心数据同步一致后,以容灾切换的方式使生产业务切换至AWS云上,最大限度地降低了生产环境的停机时间,实现了平滑上云。

AWS云中容灾,只为实际使用量买单

从容灾系统的TCO上看,AWS容灾解决方案更是具备明显优势。无需前期对硬件、软件的采购和安装,省去了大量前提投入成本。更重要的是,容灾方案中AWS云中资源可以选择不开机或只开启少量小机型资源,对于不开机的资源将完全不收取EC2虚拟机资源的费用,又能保持EC2虚拟机的状态和后台数据的增量更新。经过我们的测算,一个典型的容灾系统项目,以5年为周期进行计算,TCO只需花费原有私有云容灾环境的1/3,而第一年的投入资金更是传统项目的1/10.

总结

容灾虽然是一个非常古老和传统的IT业务,但随着云计算技术的不断成熟和普及,它恰恰成为了一个非常适合率先在公有云中实现的业务。首先它的建设风险低,与生产系统完全并行,前期投入小,无需提前采购,而且它还能够成为企业上云过程中建设自身团队云能力的一个绝好机会,经过云容灾项目之后,企业对AWS云资源、云技术都会有一个全面的了解,且能够利用这个机会验证AWS云环境承载企业生产系统的能力到底如何,再逐步实现企业级IT环境的云转型。

(未完待续)

本次分享的内容先到这里,今后我们会继续针对AWS混合云容灾架构中的诸多关键技术要点进行细致的分享,敬请期待!

如对AWS混合云容灾架构解决方案感兴趣,请联系我们: yuwangcn@amazon.com

 

作者介绍:

王宇,AWS企业容灾解决方案业务拓展经理,目前负责AWS中国区的混合云、容灾和DevOps产品和解决方案。曾服务于VMware等传统私有云厂商,熟悉传统IT架构和私有云、混合云、公有云的解决方案融合。

 

如何使用 AWS Lambda 为 AWS Service Catalog 产品启动创建审批流程

利用 AWS Service Catalog,组织可以集中管理通常部署的 IT 服务,实现一致的监管以及帮助满足合规性要求。AWS Service Catalog 可为产品配置提供标准化环境。用户浏览其有权访问的产品 (服务或应用程序) 的列表,找到要使用的产品并自行将其作为已配置产品启动。AWS Service Catalog API 还提供对所有用户操作的编程控制。
假设您需要为用户的启动请求构建一个审批工作流。许多解决方案都可以使用 AWS Service Catalog API 来构建复杂的自定义工作流 (例如,ServiceNow)。在本博客文章中,我将从 AWS Service Catalog 管理员的角度介绍如何使用 AWS Lambda、Amazon API Gateway、AWS CloudFormation 和 Amazon Simple Notification Service (Amazon SNS) 构建简单的工作流审批流程。
为构建此审批流程,我将使用 WaitCondition WaitHandle 等 AWS CloudFormation 功能,并使用 AWS Lambda 作为自定义资源来创建简单的审批工作流。如果您正在寻找 AWS 原生解决方案来扩展现有 AWS Service Catalog 功能,则可使用此方法。这也有助于在产品启动时保留 AWS Service Catalog 用户界面。

架构概述:

  1. 用户从其可用产品列表中启动产品,并通过 AWS Service Catalog 界面填写所有必需的数据。您可以通过此输入信息获取用户的电子邮件地址。
  2. 对于需要管理员审批的产品,将有三个额外的 CloudFormation 资源:WaitHandle、WaitCondition 和自定义资源。将调用 Lambda 自定义资源以通知负责审批产品启动的管理员。堆栈将处于等待状态,直至它收到来自管理员的响应。
  3. 管理员收到有关产品启动的电子邮件通知,以及允许创建堆栈的审批 URL。该 URL 包含 WaitHandle 预签名 URL 作为参数,用于向堆栈发送继续操作的信号。
  4. 当管理员单击该 URL 时,API Gateway 后面的 Lambda 函数会收到管理员批准继续操作的信号。
  5. 如果管理员批准产品启动,则 Lambda 审批函数会发送确认以允许 WaitHandle 继续创建堆栈。否则,堆栈会在最长等待时间 12 小时之后回滚。
  6. 用户会在 AWS Service Catalog 控制台上收到完成或回滚状态。此外,管理员还可以联系用户,询问有关启动请求的更多信息,然后再进行审批。

构建步骤:

现在我们已经介绍了这些步骤,下面让我们构建审批流程所需的资源。我附上了一个 AWS CloudFormation 模板以方便您使用。当您启动该模板时,系统将提示您输入用于审批流程的电子邮件地址。在堆栈完成之后,将创建以下资源:
SNS 主题:一个 SNS 主题以及提供的电子邮件订阅。您将收到一封确认您的订阅的电子邮件。订阅该主题以接收消息。
SNS 通知函数:一个可发送审批邮件的 Lambda 函数。每当新产品启动需要审批时,都会调用此 Lambda 函数。此函数将获取 WaitHandle 预签名 URL 和用户电子邮件地址作为输入。
审批函数:一个通过发送 WaitHandle 预签名 URL 的状态来通知 CloudFormation 堆栈的 Lambda 函数。
除这些资源外,还将创建一个 API Gateway API 和一些 IAM 角色。
记下输出中的 Lambda 函数的 ARN。稍后您将需要此信息来测试设置。

测试:

要测试设置,您可以使用随附 CloudFormation 模板示例。这是由 Amazon 提供的、在 AWS 上部署 WordPress 的标准模板,但我已对其进行修改以引入审批流程,并添加了三个额外的资源:WaitCondition、WaitConditionHandle 和 NotificationFunction。
WaitCondition 和 WaitConditionHandle 用于暂停堆栈的创建,并在继续创建堆栈前等待信号。模板中的所有其他资源都取决于 WaitCondition 的审批状态。

WaitHandle:
Type: 'AWS::CloudFormation::WaitConditionHandle'
WaitCondition:
Type: 'AWS::CloudFormation::WaitCondition'
Properties:
Handle:
Ref: 'WaitHandle'
Timeout: '43200'

NotificationFunction 是一个自定义资源,它可触发负责发送审批电子邮件的 Lambda 函数。

NotificationFunction:
Type: Custom::NotificationFunction
Properties:
ServiceToken: ''
Region: !Ref "AWS::Region"
WaitUrl: !Ref WaitHandle
EmailID: !Ref UserEmail

您将需要下载该模板并修改 NotificationFunction 资源的 ServiceToken 参数,以指定您在上一部分中获得的 ARN。更新 Lambda ARN 后,就可以将该模板作为新产品添加到现有目录中,或在 CloudFormation 控制台中测试该模板。
当模板成功启动后,您将收到请求继续审批的电子邮件,内容类似于:

当您选择审批链接时,API 后面的 Lambda 函数将发送确认以允许 WaitHandle 继续创建堆栈。否则,堆栈将在最长等待时间 12 小时之后回滚。

故障排除:

如果您没有收到审批邮件,请查看 SNS 主题订阅状态。此外,请验证您是否在模板中指定了正确的 Lambda ARN。检查 Amazon CloudWatch 日志中是否有启动堆栈的任何异常或错误。此外,您还可以查看以下信息来源,获得有关 Amazon SNS、API Gateway 和 AWS Lambda 等服务的一般故障排除帮助:

总结:

现在,您可以通过添加三个资源从测试模板示例向您的 Service Catalog 堆栈中添加简单的审批工作流。有关从管理员控制台管理产品组合、产品和约束的更多信息,请查看此文档。
我希望本文和示例模板能够帮助您扩展 AWS Service Catalog 功能。欢迎在评论中留下您的反馈或建议。

动态DevOps环境中的IT治理

译者:殷实,AWS专业服务咨询顾问 |原文链接

动态DevOps环境中的IT治理

治理涵盖安全和生产力运营的协调,其目的是确保公司实现业务目标。 正在迁移到云端的客户可能处于实现治理的各个阶段。 每个阶段都有自己的挑战。 在这篇博文中(系列中的第一篇文章),我将讨论四步走的方法来自动化AWS服务的治理。

治理和DevOps环境

具有DevOps和敏捷思维的开发人员负责构建和运营服务。他们经常依靠中央安全小组制定和实施安全策略,寻求安全审查和批准,或实施最佳实践。
这些安全策略和规则并没有得到安全小组的严格执行。它们被视为开发人员为获得更多的使用AWS的灵活性而遵循的准则。然而,由于时间限制或重视度不足,开发人员可能并不总是遵循最佳实践和标准。如果这些最佳实践和规则得到严格执行,安全小组就可能成为瓶颈。
对于迁移到AWS的客户,这篇博文中描述的自动化治理机制将为开发人员保留灵活性,同时为安全团队提供控制。
在动态开发环境中,以下是一些常见的挑战:

  • 通过捷径完成任务,例如将安全凭证硬编码在代码中。
  • 成本管理,例如控制启动的实例的类型。
  • 知识传递。
  • 手动流程。

治理步骤

四步走的自动化治理方法:

在治理开始的时候,你需要实施一些(1)高风险操作的控制。在控制就绪后,你需要(2)监控你的环境,以确保你正确地配置了资源。监控将帮助你发现想要(3)尽快修复的问题。你还将需要定期地生成一份(4)审核报告,以展示所有内容都符合要求。
这篇博文中的例子协助阐明了四步走的自动化治理方法:中央IT团队允许其Big Data团队运行一个基于Amazon EMR集群的测试环境。该团队在100个t2.medium实例运行EMR任务,但是当一个团队成员使用100个r3.8xlarge实例来更快地完成任务时,业务会产生意外的费用。
中央IT团队关心治理,采取一些措施来防止这种情况再次发生:

  • 控制要素:团队使用CloudFormation来限制实例的数量和类型,并使用AWS身份和访问管理来允许只有某个组可以修改EMR集群。
  • 监控要素:团队使用AWS标记,AWS ConfigAWS Trusted Advisor来监控EMR实例限制,并确定是否有人超额使用了被允许的实例数。
  • 修复:团队创建一个自定义的AWS Config规则来终止那些不是指定类型的EMR实例。
  • 审核:团队在AWS Config中审查EMR实例的生命周期。

控制

你可以通过标准化配置(通过AWS CloudFormation),限制配置的选项(通过AWS服务目录)和控制权限(通过IAM)来防范错误。
AWS CloudFormation可以帮助你在单个软件包中控制工作流环境。 在这个示例中,我们使用CloudFormation模板来限制实例的数量和类型,使用AWS标记来控制环境。
例如,团队可以通过使用限制了实例类型和数量的CloudFormation来阻止选择r3.8xlarge实例类型的选用。

CloudForamtion模板示例

包含标记的EMR集群

{
“Type” : “AWS::EMR::Cluster”,
“Properties” : {
“AdditionalInfo” : JSON object,
“Applications” : [ Applications, … ],
“BootstrapActions” [ Bootstrap Actions, … ],
“Configurations” : [ Configurations, … ],
“Instances” : JobFlowInstancesConfig,
“JobFlowRole” : String,
“LogUri” : String,
“Name” : String,
“ReleaseLabel” : String,
“ServiceRole” : String,
“Tags” : [ Resource Tag, … ],
“VisibleToAllUsers” : Boolean
}
}

在AWS中AWS Service Catalog可用于分配经批准的产品(服务器,数据库,网站)。 这为IT管理员在哪些用户可以访问哪些产品的方面,提供了更多的灵活性。 AWS Service Catalog还使他们有能力根据业务标准执行合规性。

AWS IAM用于控制哪些用户可以访问哪些AWS服务和资源。 通过使用IAM角色,你可以避免在代码中使用root凭证来访问AWS资源。
在这个示例中,我们给予团队领导者完全的EMR访问包括控制台和API访问(不在此处介绍),并为开发者提供只读访问并且不提供控制台访问权限。 如果开发者想要运行这个任务,开发者只需要PEM文件。

IAM策略

以下策略使团队领导者拥有的完全的EMR访问:

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“cloudwatch:*”,
“cloudformation:CreateStack”,
“cloudformation:DescribeStackEvents”,
“ec2:AuthorizeSecurityGroupIngress”,
“ec2:AuthorizeSecurityGroupEgress”,
“ec2:CancelSpotInstanceRequests”,
“ec2:CreateRoute”,
“ec2:CreateSecurityGroup”,
“ec2:CreateTags”,
“ec2:DeleteRoute”,
“ec2:DeleteTags”,
“ec2:DeleteSecurityGroup”,
“ec2:DescribeAvailabilityZones”,
“ec2:DescribeAccountAttributes”,
“ec2:DescribeInstances”,
“ec2:DescribeKeyPairs”,
“ec2:DescribeRouteTables”,
“ec2:DescribeSecurityGroups”,
“ec2:DescribeSpotInstanceRequests”,
“ec2:DescribeSpotPriceHistory”,
“ec2:DescribeSubnets”,
“ec2:DescribeVpcAttribute”,
“ec2:DescribeVpcs”,
“ec2:DescribeRouteTables”,
“ec2:DescribeNetworkAcls”,
“ec2:CreateVpcEndpoint”,
“ec2:ModifyImageAttribute”,
“ec2:ModifyInstanceAttribute”,
“ec2:RequestSpotInstances”,
“ec2:RevokeSecurityGroupEgress”,
“ec2:RunInstances”,
“ec2:TerminateInstances”,
“elasticmapreduce:*”,
“iam:GetPolicy”,
“iam:GetPolicyVersion”,
“iam:ListRoles”,
“iam:PassRole”,
“kms:List*”,
“s3:*”,
“sdb:*”,
“support:CreateCase”,
“support:DescribeServices”,
“support:DescribeSeverityLevels”
],
“Resource”: “*”
}
]
}

以下策略使开发人员拥有只读访问:

{

“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“elasticmapreduce:Describe*”,
“elasticmapreduce:List*”,
“s3:GetObject”,
“s3:ListAllMyBuckets”,
“s3:ListBucket”,
“sdb:Select”,
“cloudwatch:GetMetricStatistics”
],
“Resource”: “*”
}
]
}

这些是IAM管理的策略。如果要更改权限,你可以创建自己的IAM自定义策略

监测

尽可能使用AWS CloudTrailAmazon CloudwatchAmazon VPCAmazon S3Elastic Load Balancing提供的日志。 你可以使用AWS Config,Trusted Advisor和CloudWatch的事件和警报来监控这些日志。
AWS CloudTrail可用于在AWS中记录API调用。 它可以帮助你解决问题,确保你的环境安全,并生成审核报告。 例如,您可以使用CloudTrail日志来识别谁启动了那些r3.8xlarge实例。

AWS Config可用于跟踪和执行规则,这些规则检查你的AWS资源的配置是否符合要求。你还可以根据你配置的规则一目了然地了解你的环境的合规性情况。
Amazon CloudWatch可用于对配置不正确的资源进行监控和报警。 CloudWatch的实体,包括监控指标,警报,日志和事件可帮助你监视AWS资源。使用监控指标(包括自定义的监控指标),你可以监控资源并获取可自定制的小控件的仪表板。 Cloudwatch日志可以用于从AWS提供的日志和你的系统日志中传输数据,这有助于问题修复和审核。
CloudWatch事件可以帮助你针对变更采取行动。 VPC流日志,S3和ELB日志为你提供数据,以便你在修复问题或优化环境时做出更明智的决定。
AWS Trusted Advisor分析你的AWS环境,并提供四个方面的最佳实践建议:成本,性能,安全性和容错能力。这个在线资源优化工具还包括有关AWS资源限制的警告。
我们将使用Trusted Advisor来确保这种资源限制不会成为启动100个实例的瓶颈:

问题修复

根据违规情况以及监控和展现资源配置的能力,你可能想要在发现配置不正确的资源导致安全性冲突时采取行动。 重要的是修复问题不会导致没有预期的后果,并且为你的执行的操作维护可审计的记录。

你可以使用AWS Lambda自动化一切。 当你使用Lambda与Amazon Cloudwatch 事件来修复问题时,你可以采取终止实例行动或者将新实例添加到 Auto Scaling 。你可以针对任何AWS API调用采取行动。 你还可以使用AWS Config托管规则和自定义规则进行问题修复。 在根据AWS Config规则获取有关环境的信息时,你可以使用AWS Lambda针对这些规则执行操作。 这有助于自动化的问题修复。

AWS Config查找运行中实例的类型

要解决我们示例中的问题,你可以实现AWS Config的自定义规则和触发器(例如,如果实例的类型大于.xlarge或被拆除出EMR群集,则该实例会被关机)。

审计

你做为审计员,将会希望在年底或季度末准备一份审计报告。你可以使用AWS Config资源自动化你的报表系统。
你可以查看AWS资源配置和历史记录,以便查看r3.8xlarge实例集群何时启动或者应用了哪个安全组。 你甚至可以搜索哪些被终止的实例。

AWS Config 资源

 

更多控制,监测和问题修复的示例

来自AWS专业服务团队的Armando Leite创建了一个利用Cloudwatch Events和AWS Lambda的治理框架示例来强制执行一组控件(无操作系统root的访问,无远程登录)。 当违规被注意到(监测)时,自动化措施会被采取来响应事件,并在必要时恢复到之前的良好状态(问题修复)。

  • 通过AWS Config的自定义规则或AWS CloudWatch事件去触发工作流,来进行修复(例如,关闭实例)
  • 监视用户的操作系统活动。 随着事件的发展,新的Lambda功能动态地启用更多的日志和订阅日志数据以实现进一步的实时分析。
  • 如果监测的结果是适合,将系统恢复到之前的良好状态。

 

译者

殷实,AWS专业服务咨询顾问,专注于企业客户在AWS上的运维和DevOps的评估,架构,设计和实施。

利用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 EC2 Container Service的持续集成/持续交付解决方案

基本概念

持续集成/持续交付

互联网软件的开发和发布,已经形成了一套标准流程,最重要的组成部分就是持续集成(Continuous integration,简称CI)和持续交付(Continuous delivery,简称CD)。

通过CI/CD构建自动化的代码交付管道,可以实现:

(1) 快速交付。通过CI/CD自动化软件发布的过程,可以更快速地发布新的功能,快速迭代反馈并让新功能更快提供给客户。

(2) 提高质量。自动化构建、测试和发布过程致使可以轻松测试每次代码更改并捕捉易于修复的小型漏洞,通过标准化发布过程运行每一项更改,从而保证应用程序或基础设施代码的质量。

(3) 可配置工作流。通过图形用户界面模拟软件发布过程的各个阶段。

容器

本文涉及到的另外一个概念是容器,相信大家都已经不再陌生,并且很多朋友已经在自己的环境中有实际的运行、部署基于容器的应用,这边简单的回顾下容器的几个重要优势:

一是因为容器可以跨平台,从而让程序猿可以享受到研发生产环境一致性的便利,也就是DevOps。在没有容器之前,常常一个应用做好了在笔记本上可以运转起来,在数据中心就运转不起来,因为操作系统版本不同、库版本不对;或者有的时候生产环境里出现了问题,在笔记本的开发环境中复制不出来。有了容器之后,这些问题就大大减少了。

其二,容器在虚拟机里面可以大幅度提升资源利用率。因为一旦把应用容器化,虚拟机资源就可以通过部署多个容器而得到充分利用,而不是每一个应用去申请一个虚拟机,造成资源的浪费。

Amazon ECS/ECR

Amazon EC2 Container Service (ECS)是一个托管的容器集群管理和调度服务, 可使您在 Amazon EC2 实例集群中轻松运行和管理支持 Docker 的应用程序。

使用 Amazon ECS 后,您不再需要安装、操作、扩展您自己的集群管理基础设施,可以根据资源需求和可用性要求在集群中安排支持 Docker 的应用程序。借助 Amazon ECS,您可以从一个容器扩展到覆盖数百个实例的数千个容器,而运行应用程序的方式并不会因此而变得复杂。您可以运行包括应用程序、批量作业和微服务在内的任何东西。Amazon ECS 将基础设施的一切复杂因素全部消除,让您能够集中精力设计、开发、运行容器化应用程序。

Amazon EC2 Container Registry (ECR) 是完全托管的 Docker 镜像仓库,可以让开发人员轻松存储、管理和部署 Docker 容器映像。Amazon ECR 集成在 Amazon EC2 Container Service (ECS) 中,从而简化产品工作流的开发。

本文主要介绍如何在AWS云上,使用Jenkins快速构建针对容器应用的持续集成/持续交付管道。

下图是整个CI/CD的流程图:

  1. 开发者commit/push新版本的软件工程到GitHub仓库
  2. GitHub的webhook触发Jenkins预先定义好的构建Pipeline
  3. Jenkins下载GitHub,并基于下载的DockerFile构建新的docker镜像并上传ECR仓库
  4. Jenkins调用aws cli更新ECS的task definition引用新的docker镜像并更新相关的service
  5. ECS基于新的service配置更新集群中的container

可以看到,整个代码的发布过程,开发人员只需要在本地开发新版本的软件并提交到GitHub,之后的一系列代码构建、部署等过程可以完全实现自动化,无需人为干预,大大提高了软件迭代的速度,为敏捷开发、微服务化提供支持,同时,可以根据需要添加测试步骤、代码审查、人工审批等步骤,构建一条更为强大灵活的代码交付流程。

 

  1. 准备工作启动一台EC2用于安装jenkins,本例使用Amazon Linux AMI,建议分配EIP(52.34.X.X),并且赋予合适role使其能够操作ECR和ECS
  2. 安装java jdk 1.8
  3. 安装并运行docker daemon,

    yum install docker –y

    chkconfig docker on

    service docker start

  4. 安装并运行jenkins

    wget -O /etc/yum.repos.d/jenkins.repo http://jenkins-ci.org/redhat/jenkins.reporpm –import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.keyyum install jenkins

    chkconfig jenkins on

    service jenkins start

  5. 将jenkins用户加入docker用户组,使其拥有docker cli执行权限
    usermod -a -G docker jenkins
  6. 安装git,jq
    yum install git jq –y

第一步 配置GitHub与Jenkins联动

生成GitHub token,用于jenkins访问GitHub

记录下生成的token字符串

为需要做CI/CD的GitHub创建hook,实现代码更新自动通知Jenkins,Payload URL设置Jenkins Server的地址,默认Jenkins监听8080端口

第二步 配置Jenkins的构建步骤

在浏览器中输入jenkins server的地址(52.34.X.X:8080),开始配置jenkins

初始化登入

安装推荐的插件

安装CloudBees Docker Build and Publish plugin,用于构建docker镜像并上传到ECR仓库

配置github插件,使得jenkins能够连接到github

点击Add GitHub Server增加GitHub服务器,并添加Credentials

在Secret中输入之前记录的GitHub Personal Access Token

点击Test connection测试连通性

创建jenkins项目

设置GitHub项目路径

源代码管理选择Git

勾选GitHub hook trigger for GITScm polling,使得github项目的更改自动触发构建行为

添加三个构建步骤

第一个步骤为通过aws cli登入ECR仓库

第二个步骤为通过CloudBees Docker Build and Publish plugin构建docker镜像并上传到ECR中

第三个步骤为通过脚本注册新的ECS task definition并更新service,实现服务部署,详细代码可以从如下链接获取

https://s3.cn-north-1.amazonaws.com.cn/junyublog/buildstep3.sh

第三步 测试

https://github.com/iwasnobody/ecs-cicd-jenkins

本例使用的GitHub工程对外提供一个apache PHP的静态页面

在本地PC上clone下工程兵修改工程下的src/index.php文件

commit并push到GitHub上

Jenkins界面可以看到自动触发了一次新的构建

查看新的镜像已经被上传到ECR

查看jenkins创建了新版本的task definition

查看service已经引用了新版本的task definition

访问应用,确认已经更新到最新版

 

作者介绍

余骏,AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广。在加入AWS之前,他在思科中国担任系统工程师,负责方案咨询和架构设计,在企业私有云和基础网络方面有丰富经验。

 

 

 

新增 – 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

现已推出 – AWS SDK for Java 2.0 的开发人员预览

AWS 开发人员工具团队一直苦心致力于 AWS SDK for Java 的开发,今天终于推出了 2.0 版开发人员预览版。这个版本是对旧 1.11.x 代码库的重大修改。新 SDK 构建在 Java 8 之上,重点在于一致性、不变性和易用性,包括经常请求的功能,例如支持非阻塞 I/O 以及在运行时选择所需的 HTTP 实现的能力。新的非阻塞 I/O 支持,比现有的服务客户端基于线程的异步变体实现更有效。每个非阻塞请求都返回一个 CompletableFuture 对象。版本 2.0 SDK 包括对早期 API 的许多更改。例如,它使用基于客户端生成器和不可变客户端的一致模型来代替客户端构造函数和可变方法的现有组合。该 SDK 还将用于配置多个区域的离散类集合折叠为单个区域类,并提供一组新的用于流式处理的 API。该 SDK 在 GitHub 上提供。您可以通过打开 GitHub 问题发送公共反馈,也可以按照通常的方式发送提取请求。要了解有关此 SDK 的更多信息,请阅读 AWS 开发人员博客上的AWS SDK for Java 2.0 – 开发人员预览

-Jeff

API Gateway 的Android SDK

1.  背景介绍

Amazon API Gateway 是一种完全托管的服务,可以帮助开发者轻松创建、发布、维护、监控和保护任意规模的 API。作为无服务器架构中的一个重要组成部分,已经有越来越多的用户熟悉并使用Amazon API Gateway。为了让大家更轻松地调用生成的API,Amazon API Gateway还提供了生成客户端SDK的功能,目前支持的客户端语言包括Java、JavaScript、iOS(Object-C)、iOS(Swift) 和 Android。

今天,我们通过一个具体的例子演示一下Android SDK,帮助大家快速上手,更方便轻松地使用Amazon API Gateway。

2.  配置部署 API

我们参考官方文档中的宠物店这个例子,配置一套代理HTTP接口的API。我们简化接口定义,以便突出Android SDK的使用,只做2个接口:

/pets

方法: GET

参数:

type String 宠物类型

page int 页码

/pets/{id}

方法: GET

参数: 无

2.1 创建 Model

我们的 API代理的后端接口还是这个宠物店的接口

http://petstore-demo-endpoint.execute-api.com/petstore/pets

我们先根据其返回结果创建相关的结果数据模型。

我们以Oregon区域为例,打开Amazon API Gateway管理控制台

https://us-west-2.console.aws.amazon.com/apigateway/home?region=us-west-2

点击 Create API

保持New API选中不变。

API name 填写petstore。

Description 填写A demo API for Android SDK.。点击 Create API按钮。

这时左侧导航链接会显示成 APIs > petstore> Resources。点击导航链接中的APIs > petstore> Models。这里已经显示有2个默认创建出来的Model。我们点击Create按钮再来创建一个。

2.1.1 Pets: 宠物列表的 Model

Model name* 填写 Pets

Content type* 填写 application/json

Model description 填写 A list of pets。

我们使用https://jsonschema.net/ 这个在线工具来生成Model schema。

Root ID 填写 pets。

我们直接访问 http://petstore-demo-endpoint.execute-api.com/petstore/pets

[
     {
         "id": 1,
         "type": "dog",
         "price": 249.99
     },
     {
         "id": 2,
         "type": "cat",
         "price": 124.99
     },
     {
         "id": 3,
         "type": "fish",
         "price": 0.99
     }
]

帖到 JSON 栏中,其它选项保持不变,点击Generate Schema按钮,结果生成在右侧的窗格中。

复制出来,粘贴到Model schema 格中即可。点击Creat Model按钮保存完成。

2.1.2 Pet: 宠物详情接口的 Model

点击Create按钮再来创建一个。

Model name* 填写 Pet。

Content type* 填写 application/json。

Model description 填写 A pet。

我们再使用https://jsonschema.net/ 这个在线工具来生成Model schema。

Root ID 填写 pet。

我们直接访问http://petstore-demo-endpoint.execute-api.com/petstore/pets/1

把得到的返回结果

{
    "id": 1,
    "type":
    "dog",
    "price":249.99
}

帖到 JSON 栏中,其它选项保持不变,点击Generate Schema按钮,结果生成在右侧的窗格中。复制出来,粘贴到Model schema 格中。点击Creat Model按钮保存完成。

2.2 配置API

2.2.1 宠物列表接口

左侧导航链接点击 APIs > petstore> Resources。保持最顶层的 / 为选中状态时,点击 Actions 下拉菜单,选择Create Resource。

Resource Name* 填写pets

Resource Path 自动填写了 pets。然后点击Create Resource按钮。

这时刚刚创建的/pets应该是选中状态,再点击Actions 下拉菜单,选择Create Method,在当时出现的方法菜单里选择GET,然后点后面的对号符确定。

然后在/pets – GET – Setup 页,Integration type 选HTTP。

Endpoint URL填写 http://petstore-demo-endpoint.execute-api.com/petstore/pets。

其它保持默认,点击Save按钮。

创建成功后,点击 Method Request 链接,在 Method Request配置页,点击URL Query String Parameters 展开之。

点击 Add query string 增加一个参数 type ,点击 Add query string 增加第二个参数 page。其它项保持默认。

点击Method Execution 链接返回,点击Method Response链接。在Method Response配置页,点击 200 左边的三角形,展开响应详情。在Response Body for 200下点击铅笔图标编辑之,把Model菜单下选择Pets,然后点击对勾图标保存。

点击Method Execution 链接返回,点击TEST链接,我们来测试一下。Query Strings 下面 type输入dog,page输入1,然后点击 Test按钮。右侧会显示出形如如下结果,表示这个API已经配置成功。

Request: /pets?type=dog&page=1

Status: 200

Latency: 271 ms

Response Body

[
     {
         "id": 1,
         "type": "dog",
         "price": 249.99
     },
     {
         "id": 2,
         "type": "dog",
         "price": 124.99
     },
     {
         "id": 3,
         "type": "dog",
         "price": 0.99
     }
]

2.2.2 宠物详情接口

左侧导航链接点击 APIs > petstore> Resources。保持最顶层的 /pets 为选中状态时,点击 Actions 下拉菜单,选择Create Resource。

Resource Name* 填写{petId}

Resource Path 自动填写了 –petid-,把它删掉,改成{petId}。然后点击Create Resource按钮。

这时刚刚创建的/{petId}应该是选中状态,再点击Actions 下拉菜单,选择Create Method,在当时出现的方法菜单里选择GET,然后点后面的对号符确定。

然后在/pets/{petId} – GET – Setup 页,Integration type 选HTTP。

Endpoint URL填写 http://petstore-demo-endpoint.execute-api.com/petstore/pets/{petId}。

其它保持默认,点击Save按钮。

创建成功后,点击 Method Request 链接,在 Method Request配置页,点击Request Paths展开之,确认这里已经有一条petId了。如果没有,请返回Create Resource 步骤检查。

点击Method Execution 链接返回,点击Method Response链接。在Method Response配置页,点击 200 左边的三角形,展开响应详情。在Response Body for 200下点击铅笔图标编辑之,把Model菜单下选择Pet,然后点击对勾图标保存。

点击Method Execution 链接返回,点击TEST链接,我们来测试一下。Query Strings 下面{petId}输入1,然后点击 Test按钮。右侧会显示出如下结果,表示这个API已经配置成功。

Request: /pets/1

Status: 200

Latency: 357 ms

Response
Body

{
     "id": 1,
     "type": "dog",
     "price": 249.99
}
2.3 部署API并生成SDK

2.3.1 部署API

左侧导航链接点击 APIs > petstore> Resources,Action 菜单点击 Deploy API,在弹出层里

Deployment stage 菜单下拉选 [New Stage]。

Stage name*填写 test。

Stage description 填写 test stage。

Deployment description 填写 first deploy。

点击 Deploy 按钮。部署成功后会跳转到test Stage Editor。可以看到

Invoke URL: 形如 https://abcde12345.execute-api.us-west-2.amazonaws.com/test

我们把这个 URL 后面接上前述配置过的API路径,再来测试一下。因为我们配置的没有AUTH难,所以可以简单的使用游览器直接访问,比如

https://abcde12345.execute-api.us-west-2.amazonaws.com/test/pets

可以得到宠物列表的JSON结果就表示部署成功了。同理可以再测试一下

https://abcde12345.execute-api.us-west-2.amazonaws.com/test/pets/1

2.3.1 生成SDK

在test Stage Editor页点击SDK Generation选项卡,Platform* 选Android。下面展开的内容,都和我们即将开发的Android App 包名有关,我们先定好包名为 com.example.petstore。相应的这里几项这样填写:

Group ID 填写com.example

Invoker package 填写完整包名com.example.petstore

Artifact ID 填写petstore

Artifact version 填写自己编排的版本号,比如1.0.0

然后点击Generate SDK按钮,弹出下载文件对话框,保存到本机即可。

这是一个ZIP压缩包,解压可以得到以下目录和文件。

│  build.gradle

│  LICENSE.txt

│  NOTICE.txt

│  pom.xml

│  README.md

└─src

└─main

└─java

└─com

└─example

└─petstore

│    PetstoreClient.java

└─model

Pet.java

Pets.java

PetsItem.java

先放在这备用。下面我们用 Android Studio 开始做 App 项目。

3.  Android 开发整合SDK

3.1 创建一个新的Android项目

我们打开Android Studio,新建一个项目,Application name 填写 Petstore,Company domain 填写 example.com,从而 Package name 成为com.example.petstore,和我们前面生成 SDK 时使用的包名保持一致。

然后一路点击Next ,使用默认配置(Empty Activity, Activity Name是MainActivity,Layout Name 是activity_main)创建一个项目。

3.2 整合API Gateway生成的Android SDK

使用 API Gateway生成的SDK其实有官方文档:

http://docs.aws.amazon.com/zh_cn/apigateway/latest/developerguide/how-to-generate-sdk-android.html

但是我们今天用更简便的方法,直接用build.gradle管理包,不需要按官方文档那样安装Maven再编译等。

项目创建起来后,我们在Project面板启用Project视图。

打开app/build.gradle,在 dependencies段添加以下几行,其实就是AWS SDK 的核心包,API Gateway的包以及用于解析JSON的gson包。

compile 'com.amazonaws:aws-android-sdk-core:2.4.+'
compile "com.amazonaws:aws-android-sdk-apigateway-core:2.4+"
compile 'com.google.code.gson:gson:2.8.0'

然后按提示点击Sync now同步项目。这时会下载上述3个依赖库,视网络状态可能需要一些时间。我们可以不用等待,继续后面的配置。

添加访问互联网权限, 打开/app/src/main/AndroidManifest.xml,在 <application 节点前面加上一行:

<uses-permission android:name="android.permission.INTERNET" />

我们打开之前下载的SDK压缩包解压的目录 src/main/java/com/example/petstore,把下面的文件和目录

│    PetstoreClient.java

└─model

Pet.java

Pets.java

PetsItem.java

复制到 Android项目中 com.example.petstore下面。完成的样子如下图所示:

3.3 编写代码用SDK实现调用API

我们使用Cognito进行验证,所以需要先创建一个Cognito 的 Federated identity pool,有关方法请参阅相关文档,这里不再赘述。

http://docs.aws.amazon.com/zh_cn/cognito/latest/developerguide/identity-pools.html

在Android Studio里打开 MainActivity.java。先定义2个常量

然后我们定义一个testPet() 方法。

最后在onCreate()方法里加上如下代码,新开线程做HTTP请求,就可以了。

到这里例子已经完成,我们运行一个App,顺利地话可以看到如下的日志输出,我们已经可以顺利得到API接口的响应结果了。

这是在模拟器上运行的弹出层效果的截图。

例子的源码在下面 git 库的 Petstore 目录,供大家参考。

https://github.com/xfsnow/android

使用时请记得把MainActivity.java里的COGNITO_POOL_ID 换成你自己真实的值,以及new CognitoCachingCredentialsProvider 时要使用你的COGNITO_POOL_ID所在的region 值。

4.  小结

Amazon API Gateway生成的客户端SDK主要功能包括以下几点:

  • 根据我们为各个接口定义的Model批量创建好相应的Model类。
  • 通过 AWS 核心SDK实现HTTP请求的验证。
  • 封装HTTP请求和响应。
  • 把响应结果通过Gson库转换成方便Android Java使用的Model类。

这个简单的例子也体现出生成的客户端SDK便利了客户端应用程序的开发。

 

作者介绍:

薛峰,亚马逊AWS解决方案架构师,AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内和全球的应用和推广,在大规模并发应用架构、移动应用以及无服务器架构等方面有丰富的实践经验。在加入AWS之前曾长期从事互联网应用开发,先后在新浪、唯品会等公司担任架构师、技术总监等职位。对跨平台多终端的互联网应用架构和方案有深入的研究。