Category: 计算


新功能 – EC2 实例和 EBS 卷的每秒计费功能

在过去,如果您需要使用计算能力,则需要购买或租用服务器。当我们在 2006 年推出 EC2 时,使用一个实例一个小时只需支付一小时的费用是头条新闻。即付即用模式激励我们的客户思考开发、测试和运行所有类型的应用程序的新方法。

如今,AWS Lambda 等服务证明我们可以在短时间内完成大量有用的工作。我们的许多客户都在设计适用于 EC2 的应用程序,以便能够在更短的时间内 (有时仅为几分钟) 充分利用大量实例。

EC2 和 EBS 的每秒计费
于 10 月 2 日开始生效,以按需、预留和竞价形式发布的 Linux 实例的使用将按 1 秒的增量计费。同样,EBS 卷的预置存储也将按 1 秒的增量计费。

每秒计费功能也适用于 Amazon EMRAWS Batch

Amazon EMR – 我们的客户增加了其 EMR 群集的容量以更快地获得结果。借助适用于群集中的 EC2 实例的每秒计费功能,添加节点要比以往任何时候都更经济高效。

AWS Batch – 我们的客户运行的许多批处理作业在 1 小时内即可完成。AWS Batch 已启动和终止竞价型实例;利用每秒计费功能,批处理将变得更划算。

Elastic GPUsElastic GPUs 的使用按秒计费,最少1分钟。

Provisioned IOPS – io1 EBS 卷的 Provisioned IOPS 按秒计费。

我们的一些更精明的客户已构建系统,通过在管理其游戏、广告技术或 3D 渲染队列时战略性地选择最有利的目标实例来从 EC2 中获得最大价值。每秒计费功能消除了这种额外的实例管理层的需要,并实现了所有客户和所有工作负载的成本节省。

虽然这将导致许多工作负载的价格降低(您知道我们喜欢降价),但我认为这并不是此改变的最重要方面。我相信,这种改变将激励您进行创新并以新的方式思考您的受计算限制的问题。您如何利用这一点来增强对持续集成的支持?这是否能改变您为开发和测试工作负载预置瞬态环境的方式?您的分析、批处理和 3D 渲染将会怎么样?

云计算的许多优势之一是,在您需要时预置或取消预置资源的弹性特性。通过对使用量每秒计费,我们使客户能够提高其弹性、节省资金,并且客户将被定位以利用计算中的持续改进。

需知信息
此更改在所有 AWS 区域中都是有效的,并且将于 10 月 2 日开始生效,适用于新发布的或已经运行的所有 Linux 实例。每秒计费功能目前不适用于运行 Microsoft Windows 或 Linux 发行版的实例,后者已按小时单独计费。每个实例均最少有 1 分钟计费。

列表价格和竞价市场价格仍按每小时列出,但计费单位下调至秒,预留实例使用量也按秒计算(您可以在 1 个小时内启动、使用和终止多个实例并获得所有实例的预留实例优势)。此外,账单将以十进制格式显示次数,如下所示:

AWS Marketplace 中的区域专用费、EBS 快照和产品仍按小时计费。

Jeff

使用AWS Lambda和AWS Step Functions轻松构建Serverless应用

作者: Vivian Zhang(张芸)

Serverless(无服务器)应用可以说是当前的行业热点,用户无需预配置或管理服务器,只需要部署功能代码,AWS Lambda会在需要的时候执行代码并自动缩放, 从每天几个请求到每秒数千个请求,轻松地实现FaaS (Function as a Service)。无服务器应用的使用场景非常广阔,从微服务架构,到批处理、流处理、运维自动化和移动计算。

实现Serverless应用,除了AWS Lambda还需要什么?

我们来看一个典型的基于Lambda的无服务器应用。

当我们将作为计算和存储实体的Lambda函数、消息队列、DB去掉,可以看到下面这张图。

这张图上的箭头,就是上一张图里Lambda函数之间的流程,或者可以称为Lambda函数之间的“胶水”,它们起到了编排协调各个Lambda函数的作用。通常在应用中,我们会需要有这样的一些流程:

  • 我想要顺序地执行方法。
  • 我想要并行地运行这些方法。
  • 我想要基于数据选择执行方法。
  • 我想要重试某些方法。
  • 我想要try/catch/finally。
  • 我想要代码运行一定时间或者等待一段时间……

通常我们可以通过方法调用、函数链、DB和消息队列来协调这些函数,实现流程。但是对于所采用的协调机制,我们都希望它具有以下功能:

  • 可以自动伸缩;
  • 不会丢失状态;
  • 可以处理错误和超时;
  • 可以简单的搭建和运维;
  • 可以审计。

这里我们介绍一种方式,采用AWS Step Functions协调Lambda函数之间的流程。

AWS Step Functions

AWS Step Functions是一个可视工作流服务,可用来轻松协调分布式应用程序和微服务的各个组件。用户从单个组件构建应用程序,每个组件都执行一个特定的功能,也就是Task(可以采用Lambda函数实现)。Step Functions提供了一种可靠的方法来协调这些组件并逐步完成应用程序中的这些功能,并且 提供了一个图形控制台,将应用程序的组件可视化为一系列步骤,它可以自动触发并跟踪每一个步骤,并在出现错误时重试,这样应用程序就可以每一次都按照预先设定的顺序执行。Step Functions会记录每一步的状态,因此当事情出错时,用户可以快速地诊断和调试问题。

要使用Step Functions构建应用,首先我们需要在Step Functions里创建State Machine(状态机),也就是对应每一个应用的工作流程。可以采用以下8种蓝图,包括7种预定义好的状态机和1种自定义的。创建好的状态机用JSON描述。

在每一个状态机里,我们需要定义一系列的State(状态),用来完成不同的功能:

  • Task:在状态机中完成特定的功能,可以采用Lambda函数实现。
  • Choice:在各种执行分支中进行选择。
  • Fail和Success:停止一个执行,并设为Fail或者Success。
  • Pass:简单地将输入传给输出,或者注入一些数据。
  • Wait:提供一定时间的延迟,或者等待到特定的时间/数据。
  • Parallel:并行地执行分支。

可以看出,上一节中我们所需要的协调和流程在这些状态中都得到了支持。其中的Task状态是用来真正实现应用的功能,而其他状态用来处理功能之间的流程。比如说,下面是一个名为HelloWorld,执行Lambda函数的状态。

下图是一个拥有所有状态的状态机:

在Console里看到一个创建好的状态机是这样:

我们点击New Execution并且传入input数据,就可以启动该状态机的一次执行,并且可以从界面上查看执行的情况。

此外也可以通过AWS SDKs,Step Functions API和AWS CLI来启动状态机的执行并且查看进程。

采用AWS Lambda和AWS Step Functions构建Serverless应用的例子

这里介绍一个镜像识别和后端处理的例子,展示如何使用 AWS Step Functions 编排一个集成 AWS Lambda、Amazon S3、Amazon DynamoDB 和 Amazon Rekognition 的无服务器处理工作流。此工作流处理上传至 Amazon S3 的照片,并从镜像中提取元数据,如地理位置、大小/格式、时间等。然后,它使用镜像识别功能标记照片中的对象,同时还生成照片的缩略图。该例子的源代码在github上:https://github.com/awslabs/lambda-refarch-imagerecognition

整个架构的流程如下:

  1. 一张图片上传到名为PhotoRepo的S3 bucket里,位于“Incoming/”前缀下。
  2. S3 upload event产生,触发了名为ImageProcStartExecution的Lambda函数,该函数启动了AWS Step Functions中ImageProc状态机的执行,并将S3 bucket和object key作为参数传入状态机。
  3. ImageProc状态机执行以下步骤:
  4. 从S3中读取文件并抽取出图片的元数据(格式、EXIF数据、大小等等);
  5. 基于上一步骤的输出,验证上传的文件格式是否支持(png或者jpg);如果不支持,抛出NotSupportedImageType错误并且结束执行。
  6. 将抽取出的元数据保存在ImageMetadata DynamoDB中。
  7. 并行地同时启动两个进程:
  • 1)    调用Amazon Rekognition探测图像文件的对象,如果探测到,将tag保存到ImageMetadata DynamoDB中;
  • 2)    生成缩略图并且保存在名为PhotoRepo的S3 bucket的“Thumbnails/”前缀下面。

可以通过源代码中的test web app上传图片来测试该图像识别和处理工作流的结果。

可以通过源代码中的CloudFormation template来创建该后端处理应用程序。

结论

用AWS Lambda函数定义应用程序需要执行的每一个特定功能,而用AWS Step Functions定义在各个功能中流转的流程,这样采用AWS Lambda和AWS Step Functions联合使用的方式,可以轻松地构建出Serverless应用。

此外,AWS 还提供一系列完全托管的服务,可以用来构建和运行无服务器应用程序。

参考

可以在我们的网站上下载到相关例子的sample code:https://github.com/awslabs/lambda-refarch-imagerecognition

关于AWS Step Functions的 更多内容请参考网站:https://aws.amazon.com/cn/step-functions/

关于AWS Lambda的更多内容请参考网站:https://aws.amazon.com/lambda/

关于AWS服务器平台请参考网站:https://aws.amazon.com/cn/serverless/

新增 – 适用于 Windows 的 Amazon EC2 Elastic GPU

作者:Randall | 原文链接

今天,我们高兴地宣布,适用于 Windows 的 Amazon EC2 Elastic GPU 正式推出。Elastic GPU 是一种 GPU 资源,可以挂载到 Amazon Elastic Compute Cloud (EC2) 实例来提升应用程序的图形性能。Elastic GPU 提供 medium (1GB)、large (2GB)、xlarge (4GB) 和 2xlarge (8GB) 几种大小,可以作为 G3 或 G2 等 GPU 实例类型 (用于 OpenGL 3.3 应用程序) 的成本更低的替代方案。您可以将 Elastic GPU 用于多种实例类型,灵活地为应用程序选择适当的计算、内存和存储资源,使之达到平衡。您现在就可以在 us-east-1 和 us-east-2 区域预配置 Elastic GPU。

对于 eg1.medium,Elastic GPU 的起始价仅为每小时 0.05 USD,即一小时五美分。如果我们将该 Elastic GPU 挂载到 t2.medium (0.065 USD/小时),一个使用 GPU 的实例每小时的总花费不到 12 美分。以前,最便宜的图形工作站 (G2/3 级) 的成本是每小时 76 美分。由此可见,新服务将使运行特定图形工作负载的成本降低 80% 以上。

何时应当使用 Elastic GPU?

Elastic GPU 最适合需要少量或间歇性附加 GPU 能力来实现图形加速和支持 OpenGL 的应用程序。Elastic GPU 支持 OpenGL 3.3 及更低版本的 API 标准,并且扩展的 API 支持不久也将推出。

Elastic GPU 并非实例的硬件部分。它们通过您子网中的 Elastic GPU 网络接口挂载到实例上,当您启动使用 Elastic GPU 的实例时,便会创建这么一个网络接口。下图显示了 Elastic GPU 是如何挂载的。

因为 Elastic GPU 是通过网络挂载的,所以必须预配置一个有足够网络带宽的实例来支持您的应用程序,这一点很重要。而确保实例安全组允许端口 2007 上的流量也同样重要。

任何可以使用 OpenGL API 的应用程序都可以利用 Elastic GPU,因此 Blender、Google Earth、SIEMENS SolidEdge 等都可以使用 Elastic GPU 来运行。甚至包括坎巴拉太空计划 (Kerbal Space Program)!

好了,现在我们知道了什么时候使用 Elastic GPU 及其工作原理,下面我们来启动一个实例并使用一个 Elastic GPU。

使用 Elastic GPU

首先,导航到 EC2 控制台并单击“Launch Instance”。接下来,选择一个 Windows AMI,如“Microsoft Windows Server 2016 Base”。然后,选择一个实例类型。确保选择“Elastic GPU”部分并分配一个 eg1.medium (1GB) Elastic GPU。

我们还将在高级详细信息部分包含一些用户数据。我们将编写一个简短的 PowerShell 脚本来下载并安装 Elastic GPU 软件。

<powershell>
Start-Transcript -Path "C:\egpu_install.log" -Append
(new-object net.webclient).DownloadFile('http://ec2-elasticgpus.s3-website-us-east-1.amazonaws.com/latest','C:\egpu.msi')
Start-Process "msiexec.exe" -Wait -ArgumentList "/i C:\egpu.msi /qn /L*v C:\egpu_msi_install.log"
[Environment]::SetEnvironmentVariable("Path",$env:Path + ";C:\Program Files\Amazon\EC2ElasticGPUs\manager\",[EnvironmentVariableTarget]::Machine)
Restart-Computer -Force
</powershell>

该软件将所有 OpenGL API 调用都发送到挂载的 Elastic GPU。

接下来,我们将仔细检查,以确保我的安全组已对 VPC 开放了 TCP 端口 2007,这样 Elastic GPU 才能与我的实例连接。最后,我们单击启动,等待实例和 Elastic GPU 完成预配置。完成这项工作最好的方法是创建一个可以挂载到该实例的单独的 SG。

您可以观看下面有关启动过程的动画。

或者,我们也可以通过 AWS CLI 使用如下的简短调用来进行启动:

$aws ec2 run-instances --elastic-gpu-specification Type=eg1.2xlarge \
--image-id ami-1a2b3c4d \
--subnet subnet-11223344 \
--instance-type r4.large \
--security-groups "default" "elasticgpu-sg"

然后,按照此处的 Elastic GPU 软件安装说明操作。

现在,通过查看任务栏中 Elastic GPU 的状态,可以看出 Elastic GPU 在正常运转并且已挂载。

我们欢迎您对该服务提出任何反馈意见,您可以单击 GPU 状态框左下角的反馈链接,让我们了解您使用 Elastic GPU 的体验。

Elastic GPU 演示

好了,我们已预配置了实例并挂载了 Elastic GPU。我在 AWS 的队友希望我谈谈可以运行哪些令人惊奇的精彩 3D 应用程序,但当我了解到 Elastic GPU 之后,我首先想到的就是坎巴拉太空计划 (KSP),因此我准备用它进行一次简短测试。毕竟,如果您不能将试飞员 Jebediah Kerman 送入太空,还要这套软件做什么呢?我下载了 KSP 并添加了发射参数 -force-opengl ,以确保我们将使用 OpenGL 进行渲染。下面您会看到我在建造太空船方面糟糕的尝试 – 过去我的表现可要好很多。考虑到我们使用的网络采用的是有损耗的远程桌面协议,情况还算顺利。

我本来想展示一张火箭发射的照片,但它甚至还没离开地面就意外地迅速解体了。我只好从头再来。

在此期间,我可以检查我的 Amazon CloudWatch 指标,看看在我玩游戏的这一小段时间里使用了多少 GPU 内存。

合作伙伴、定价和文档

为了继续为我们的客户打造出色体验,我们的 3D 软件合作伙伴 (如 ANSYS 和 Siemens) 正打算在 Elastic GPU 上利用 OpenGL API,目前他们正在认证 Elastic GPU 是否适合其软件。您可在此处了解有关我们的合作伙伴关系的更多信息。

可在此处找到有关 Elastic GPU 定价方面的信息。可在此处找到更多文档。

现在,我要失陪了,我还有几艘虚拟火箭要造。

Randall

Amazon EC2 Systems Manager让你轻松管理AWS混合云

作者:王宇

摘要: Amazon EC2 Systems Manager(SSM)是一套资源管理、配置的工具集,它不仅能够帮助客户完成AWS云中资源的管理,还能够将客户私有云中的资源统一纳入管理范围,是混合云架构中的管理利器。

IT资源在混合场景下应该如何管理?

对于要不要使用公有云资源的问题对于今天的企业来说已经不再是一个问题了,问题变成了要怎么用,怎么管,以及怎么和现有的企业IT环境进行整合。当前,大量企业客户都存在着部分应用或资源已经上云,而企业自己的数据中心中仍然保留着一部分的应用或资源,如何将这两部分的资源统一管理起来,做到有效的协同,是一个关键问题。而传统的网管或资源管理系统往往还无法支撑这个混合场景下的管理需求。

AWS在云资源管理问题上有着完整的解决方案

AWS从云资源的准备、配置、监控、合规、优化这五个方面提供了完整的云资源管理闭环工具集,今天我们介绍的Amazon EC2 Systems Manager(SSM)是在配置管理环节中的一个最常用的管理工具集。

Amazon EC2 Systems Manager(SSM)工具集

Run Command –远程执行常规管理任务

State Manager –定义和维护操作系统和应用程序的一致配置

Parameter Store – 运维参数的集中管理,如密码和连接字符串

Maintenance Window -在明确定义的时间窗口中安排运维任务,以尽量减少停机时间

Inventory –收集,查询和审计详细的软件清单信息

Patch Management –使用自定义的规则和预先安排的维护窗口维护操作系统补丁程序

Automation –使用简化的工作流自动执行日常运维任务

Run Command

Run Command能够通过远程发送命令的方式来管理AWS云以及客户自己数据中心中的IT资源。与以往的Run Command相比,现在还可以控制命令执行的并发数量。 这在远程执行命令时可以有效避免在同一时间使用太多共享资源的问题,例如内部更新或统一执行软件补丁程序。

State Manager

State Manager通过“Document”的定义,能够定义和维护操作系统和应用程序的一致配置。 创建一个“Document”,将它与一组目标实例关联,然后创建一个关联策略来指定什么时间和什么频率来应用这个“Document”。

使用标签指定目标可使这个关联应用到未来创建的实例中,并允许它在动态的,自动缩放的环境中按预定义的方式工作。还可以通过选择它并点击Apply Association Now来立即运行这个关联:

Parameter Store

Parameter Store是一个数字词典,它简化了要分发到实例的许可证密钥,密码和其他数据的存储和管理。 每个参数都有一个类型(字符串,字符串列表),以下是创建参数的方法:

Maintenance Window

Maintenance Window允许指定安装更新或其他系统维护操作的时间窗口。 例如创建一个周六的时间窗口,每个星期六四个小时:

创建维护窗口后,需要为其分配一组实例。 可以通过实例ID或标签来做到这一点:

然后需要注册一个在维护窗口时间段内执行的任务。 例如,可以运行一个Linux shell脚本:

Inventory

Inventory能够收集一组实例的软件和设置信息。 要访问Inventory,需要在托管实例清单中点击“Setup Inventory”:

“Setup Inventory”会创建一个由AWS拥有的文档和一组实例之间的关联。

Inventory运行后,可以选择一个实例,然后点击“Inventory”,以检查结果:

Patch Management

Patch Management可以帮助客户将Windows实例上的操作系统保持在最新状态。 在客户定义的维护窗口期间执行补丁程序,并且可以定义不同的基线。 “基线”指定了基于分类和严重性的补丁规则,以及要执行或忽略的补丁列表。

每个基线都可以应用于一个或多个补丁组。 补丁组内的实例都具有补丁组标签。 例如:

然后将标签值与基线相关联:

然后是使用AWS-ApplyPatchBaseline Document在维护窗口期间执行补丁程序:

还可以返回到托管实例列表,并使用过滤器来确定哪些实例需要补丁:

Automation

最后,Automation功能简化了常见的AMI构建和更新任务。 例如,你可以使用AWS-UpdateLinuxAmi Document每月构建一个新鲜的Amazon Linux AMI:

运行结果如下:

总结

Amazon EC2 Systems Manager是一套与日常运维工作结合非常紧密的运维工具,它不仅能够维护AWS云中资源,更能够在混合云架构中对企业自己数据中心中的资源进行管理,而且能够实现日常运维工作的自动化,大幅减低了混合云环境中的资源管理复杂程度和运维成本,是一个实在的运维管理好帮手。今天对EC2 Systems Manager的介绍就到这里了。希望对你的运维管理工作有所帮助。

如对AWS混合云架构解决方案感兴趣,请联系我们:

王宇    AWS企业混合云解决方案业务拓展经理    yuwangcn@amazon.com

 

作者介绍:

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

 

你需要知道的关于高IO EC2的事儿

作者:焦杨

故事背景

笔者长期在AWS从事架构师工作,人送焦导的外号。经常遇到客户抱怨:“我选了比原来大的机器,比原来快的硬盘,可EC2的IO怎么就是上不去,到底卡在哪里了啊?你们架构师到底怎么干活的啊?”,好了,今天我也不想再背这个锅了,我们一起把这个事儿好好说道说道。

基本原理

一开始,我们先来看看磁盘上的数据是怎么到达外网的。

第一步操作系统接到IO命令,然后驱动磁盘,从磁盘上读入数据到内存处理, 最后从网卡送出,通过交换机路由器送出到外部网络。 要更好的IO性能,硬件层面上看无非三板斧

  • 换个更块的硬盘
  • 换个更快的网卡和交换机
  • 更快的CPU、足够的内存、足够优化的

那到了AWS上,又变成什么样了呢?

  • 云上的图

你可能看出来了:

  • 物理机变成了EC2 instance。
  • 磁盘为了更灵活和更可靠,把它从机器里拿出来变成了EBS。
  • 外部的交换机/路由器由于VPC的存在,对用户变成透明的了。

稍微想想,发现实质完全没有变化。那是不是我们就可以用原有的三板斧解决性能问题了呢?

焦导的回答是:“完全没错,但是不足够”。

大家知道,公有云服务商为了保证服务质量,避免所谓的“吵闹的邻居”问题,也为了避免意外操作导致的超额费用,引入了大量的QoS特性。这里边既有我们熟悉的各个service的hard和soft的limit,也有对外暴露的各种配置选项。为了要实现高IO的目的,我们有必要对这些QoS特性有清晰的了解。

还是上边的那个图,把其中的关键部分标上号,下边一一说明

列举分析

1. EC2网络

AWS向客户提供SDN的VPC网络,屏蔽了交换机、路由器等网络基础设施。但是对单个EC2 实例的网络出口带宽是有明确的限制的。

你可能会说这不就是网卡限制吗?多加几个网卡不就行了。

请注意,增加多个网卡并不能增加单个EC2的总出口带宽。

更加详细的数据请查看这里http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-ec2-config.html

2 存储网络

默认情况下,刚才提到的EC2总带宽,包含了进出EC2实例的所有流量。熟悉网络的同学应该知道,这里边包含了EC2间的计算流量、访问存储设备的存储流量等的各种流量。

要优化性能,拿出单独的网络来走存储流量就可以了。这也就是我们通常说的计算、存储流量分离技术。在AWS里,我们把这个叫做”EBS优化“。

当然了,对于一些早期机型(i2,c3等),在使用了万兆网络的情况下。因为这根管子已经足够粗,流量混在一起问题也不是很大。

EC2机型EBS优化的更多信息,可以在这里找到http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-ec2-config.html

3 磁盘性能

要想获得高IO,选择合适的磁盘应该是最基本的了吧。是看重IOPS而选择SSD型,还是看重连续读写的磁盘吞吐而选择HDD,这是你要做出的关于磁盘的第一个决定。

这里要特别注意的几个点:

  • 单卷IOPS的具体值和容量正相关,对于GP2而言,基准值为3IOPS/GB
  • 对单卷有IOPS和吞吐量的限制, 两个因素同时起作用
  • 对连接了多个卷的实例,总体IOPS和吞吐量也分别有限制

另外需要注意的是,对于使用最多的GP2类型SSD,存在着读写突增特性(链接),无论多小的磁盘短时间内IOPS都可以到达3000,具体就不再展开说了。 参考这里http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

4 存储队列

卷存储队列是指等待设备处理的 I/O 请求的队列,它的长度表明了有多少I/O请求还没有得到执行。队列过长,读写延迟加大,队列过短,读写任务不饱满。要让EBS全速工作起来,需要有足够的任务,也就是说要让EBS始终处于忙碌的状态。

基于这个认识,有必要根据工作负载的具体状况,实时观察存储队列长度的情况。对工作负载进行适当调整,以便发挥底层设备的最大能力。

这个指标可以通过Cloudwatch的VolumeQueueLength 来观察。 http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-io-characteristics.html

综合和特例

还有一些特殊的情况也值得拿出来说一下: 如果我们特别在意存储网络的带宽的限制,完全可以使用带有instance-storage的实例类型,比如i系列和d系列。存储在本地,通过本地总线连接,就没有这个存储网络的限制啦。

某些情况下,追求极致的IOPS,也可以考虑使用条带化技术将多个卷合起来一起使用。

另外,如果我们的流量模型为从磁盘上一次读出,在计算节点上向多个client分发,简单的说就是具有fan-out效果的话,碰到瓶颈的地方大概率应该在EC2 intance的流出限制之上,而不是存储网络限制。

总结

总结一下,要获得期望的高IO。你需要准备

  • a. 合适的磁盘类型,磁盘个数,保证你需要达到IO在单卷和总卷限制范围以内。
  • b. 足够快的从磁盘到EC2的高速网络
  • c. 足够大的机型,以带来足够的inbound/outbound。
  • d. 适当的存储队列,保证磁盘够忙

好了,需要知道的所有关于EC2的IO性能的秘籍都在这儿了,马上动手,去榨干你购买的EC2的所有潜能吧。

作者介绍:

焦杨,AWS解决方案架构师,IT行业老兵,在Moto,NEC,路透,汉柏,AWS等国内外企业从业10余年。2011年之前,从事过web container, EJB container 和大型网站的后台研发工作,醉心于OO和设计模式。2011开始着手基于oVirt和Openstack的私有云平台研发工作,并亲密接触SDN,关注点随之转移到基础架构、分布式和高可用,自此自诩全栈工程师。 2015年加入AWS,担任解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计工作。,

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 无服务器应用模型和SAM模板的基本功能和特性,并带领大家用一个实例体验了通过CloudFormation部署SAM模板。在这一篇中,我们仍然结合实例讲解,为大家继续介绍使用AWS CodeBuild 构建 Lambda函数以及使用AWS CodePipeline实现自动化持续集成。

部署配置AWS CodeBuild

如果我们的Lambda函数使用了依赖库时,我们可以通过AWS CodeBuild来把依赖库编译进Lambda函数的部署包里。

AWS CodeBuild  是一个完全托管的构建服务,可用于编写源代码、运行测试并生成可立即部署的软件包。CodeBuild基于AWS管理的容器,从而实现用户无需配置、管理和扩展自己的构建服务器。CodeBuild 可持续缩放和并行处理多个生成任务,因此构建任务不必在队列中等待。使用CodeBuild,我们只需要按构建时使用计算资源的分钟数付费,从而无需为预置的构建服务器的空闲时间付费。

除了常见的Java之类的程序源码的构建,CodeBuild还可用于Lambda函数部署前的构建。下面我们用一个例子来具体说明。

请先从以下git库下载源码。

https://github.com/xfsnow/serverless/tree/master/sam/codebuild

这个例子中的Lambda函数需要Node.js 依赖库 time,我们使用CodeBuild在构建时安装这个这个time库,把它加入到 Lambda 函数的包中。

index.js 文件中以下这行,表示需要依赖库 time。

var time = require('time');

buildspec.yml 中

install:

    commands:

      - npm install time

表示在构建的安装步骤把 time 库安装进来。

  build:

    commands:

      - aws cloudformation package --template-file codebuild.yaml --s3-bucket <bucket-name> --output-template-file output_codebuild.yaml

这段其实就是使用在上一章节我们介绍过的aws cloudformation package 打包。

上传源文件

把buildspec.yml文件中的 <bucket-name> 等变量值替换成你的具体的值。

在当前目录下除了 md 文件的其它文件打包成 codebuild.zip,然后把这个 zip 文件上传你自己的 S3桶中。

配置 CodeBuild 项目

打开 CodeBuild 控制台

点击 Create project。

在 Configure your project 页

Project name 输入 serverlessCodebuild

Source provider 选择 Amazon S3

Bucket 栏选择我们的刚才上传 zip 文件的 S3 桶名称

S3 object key 输入 codebuild.zip。

Environment image 保持选择 Use an image managed by AWS CodeBuild

Operating system 选择 Ubuntu

Runtime 选 Node.js

Version 选择 aws/codebuild/nodejs:4.3.2

Artifacts type 选 Amazon S3

Bucket name 还选择我们的刚才上传 zip 文件的 S3 桶名称

确认 Create a service role in your account 已选中

Role name 输入 serverlessCodebuild

点击右下角 Continue 按钮

在 Review 页点击右下方的 Save and build 按钮。

创建成功后前进到 Build projects 列表页,此时刚刚新建的项目应该是选中的状态。点击左上角 Start build 按钮。

在 Start new build 页,直接点击右下角 Start build 按钮。

在 Build 页可以查看构建进行的进度信息。注意看 Phase details 下面的输出内容。 构建成功完成以后,可以到我们的 S3 桶中查看结果,可以看到创建出一个 serverlessCodebuild 目录,里面就是构建的成果—— output_codebuild.yaml 文件。我们把它下载到本地,就可以用它再执行 CloudFormation 部署。

使用 CloudFormation 部署

执行以下命令

aws cloudformation deploy \

   --template-file output_codebuild.yaml \

   --stack-name serverlessCodebuild \

   --capabilities CAPABILITY_IAM

顺利地话,会看到逐渐输出的返回结果

Waiting for changeset to be created..


Waiting for stack create/update to complete

Successfully created/updated stack - serverlessCodebuild

这时到 CloudFormation 的控制台已经创建出一个 serverlessCodebuild ,整个过程大约持续 1 到 2 分钟。

然后到 API Gateway 控制台,可以看到创建出的 serverlessCodebuild 的 API,点击其 Stages 下的 Prod 链接,可以看到形如下面的调用 URL: Invoke URL: https://xxxxxxxxx.execute-api.my-region.amazonaws.com/Prod

点击它,打开一个新窗口,显示

“The time in Los Angeles is Mon Aug 07 2017 03:32:42 GMT-0700 (PDT)”
表示已经部署成功。

部署配置AWS CodePipeline

每次都要手工执行aws cloudformation deploy命令来部署仍然有些繁琐,而且手工部署难免会有人工的失误。下面我们使用AWS CodePipeline来最终实现完全自动化的部署。

AWS CodePipeline 是一个托管的持续集成与持续交付服务,可以实现快速而可靠的应用程序和基础设施更新。每次更改代码时,CodePipeline 都会根据我们定义的发布流程模型构建、测试和部署代码,就像管道一样逐个步骤的执行流程中的每一步操作,还支持可选的人工审核步骤。和CodeBuild一样, CodePipeline也是只按实际使用量付费,同样无需为预置的资源空闲付费。

我们下面这个例子,Lambda函数还是使用了time依赖库,仍然使用CodeBuild安装依赖库、CloudFormation进行部署,这次我们配置CodePipeline来完成构建和部署的全部流程,实现持续集成。

总的操作流程主要是以下几步:

  1. 在 github 上创建一个库存放源文件。
  2. 创建一个 CodeBuild 项目,用于构建无服务器应用。
  3. 创建一个 IAM 角色,用于 CloudFormation 部署无服务器应用。
  4. 创建一个 CodePipeline 项目,把上述若干步骤和资源组建成管道。

在 github 上创建一个库存放源文件

请在你自己的github新建一个存储库,名为 serverlessCodepipepline。

从以下git库下载源码。

https://github.com/xfsnow/serverless/blob/master/sam/codepipeline

放在我们自已的 serverlessCodepipepline 库的根目录下。

把 buildspec.yml 中的 <bucket> 更新成自己的桶名称,再 commit 到 git 库中。

配置 CodeBuild 项目

  • 打开 CodeBuild 控制台,点击 Create project。

在 Configure your project 页

Project name 输入 serverlessCodepipeline

Source provider 选择 Github

Repository 选择 Use a repository in my account

Repository URL 输入我们自己的库的路径,比如 https://github.com/xfsnow/serverlessCodepipepline

  • Environment image 保持选择 Use an image managed by AWS CodeBuild

Operating system 选择 Ubuntu

Runtime 选 Node.js

Version 选择 aws/codebuild/nodejs:4.3.2

Build specification 保持选中 Use the buildspec.yml in the source code root directory

Artifacts type 选 Amazon S3

Bucket name 还选择我们在 buildspec.yml 中指定的 S3 桶名称

确认 Create a service role in your account 已选中

Role name 输入 serverlessCodebuild,点击右下角 Continue 按钮。

  • 在 Review 页点击右下方的 Save and build 按钮。

创建成功后前进到 Build projects 列表页,此时刚刚新建的项目应该是选中的状态。点击左上角 Start build 按钮。

在 Start new build 页,直接点击右下角 Start build 按钮。

  • 在 Build 页可以查看构建进行的进度信息。注意看 Phase details 下面的输出内容。

构建成功完成以后,可以到我们的 S3 桶中查看结果,可以看到创建出一个 serverlessCodepipeline 目录,里面就是构建的成果—— output-codepipeline.yaml 文件。

我们可以把它下载到本地看一下,后续我们继续配置 CodePipeline 就是用它来做无服务器资源的部署。

配置 IAM 角色

登录 AWS 管理控制台。点击左侧导航链接中的 Roles,点击 Create new role 按钮。

  • 在 Select role type 页选择 AWS Service Role,找到 AWS Cloudformation Role 点击其右边的 Select 按钮。
  • 在 Attach Policy 页,选择 AWSLambdaExecute。点击 Next Step 按钮。
  • 在 Set role name and review 页, Role name 输入 cloudformation-lambda-execution,然后点击 Create role 按钮。
  • 打开刚才创建的角色,在 Permissions 选项卡下,点击 Inline Policies 展开之,然后选择 click here 链接。

选择 Custom Policy,然后选择 Select。

在 Policy Name 中,输入 cloudformation-deploy-lambda ,然后将以下内容中的 region account_id 替换成你自己的值,粘贴到 Policy Document 字段中:

{

    "Statement": [

        {

            "Action": [

                "s3:GetObject",

                "s3:GetObjectVersion",

                "s3:GetBucketVersioning"

            ],

            "Resource": "*",

            "Effect": "Allow"

        },

        {

            "Action": [

                "s3:PutObject"

            ],

            "Resource": [

                "arn:aws:s3:::codepipeline*"

            ],

            "Effect": "Allow"

        },

        {

            "Action": [

                "lambda:*"

            ],

            "Resource": [

                "arn:aws:lambda:region:account-id:function:*"

            ],

            "Effect": "Allow"

        },

        {

            "Action": [

                "apigateway:*"

            ],

            "Resource": [

                "arn:aws:apigateway:region::*"

            ],

            "Effect": "Allow"

        },

        {

            "Action": [

                "iam:GetRole",

                "iam:CreateRole",

                "iam:DeleteRole"

            ],

            "Resource": [

                "arn:aws:iam::account-id:role/*"

            ],

            "Effect": "Allow"

        },

        {

            "Action": [

                "iam:AttachRolePolicy",

                "iam:DetachRolePolicy"

            ],

            "Resource": [

                "arn:aws:iam::account-id:role/*"

            ],

            "Effect": "Allow"

        },

        {

            "Action": [

                "iam:PassRole"

            ],

            "Resource": [

                "*"

            ],

            "Effect": "Allow"

        },

        {

            "Action": [

                "cloudformation:CreateChangeSet"

            ],

            "Resource": [

                "arn:aws:cloudformation:region:aws:transform/Serverless-2016-10-31"

            ],

            "Effect": "Allow"

        }

    ],

    "Version": "2012-10-17"

}    

点击 Validate Policy,然后点击 Apply Policy。

配置 CodePipeline 项目
打开 CodePipeline 控制台,点击 Create project。

  • 在 Step 1: Name 页

Project name 输入 serverlessCodepipeline,点击“Next Step” 按钮。

  • 在 Step 2: Source 页

Source provider 选择 Github,然后点击 Connect to GitHub 按钮,关联 GitHub 账号。按提示完成关联操作。

回到 AWS 页面后,Repository 选择前述我们自己创建的存储库。

Branch 选择 master ,点击“Next Step” 按钮。

  • 在 Step 3: Build 页

Build provider 选择 AWS CodeBuild

Configure your project 保持选中 Select an existing build project。

Project name 在下拉列表中选择我们前面创建的 serverlessCodepipeline 项目。

  •  在 Step 4: Deploy 页

Deployment provider 选择 AWS CloudFormation。

Action mode 选择 Create or replace a change set。

Stack name 输入 serverlessCodepipeline。

Change set name 输入 serverlessCodepipelineChangeSet。

Template file 输入 buildspec.yml 中指定的构建结果文件名 output-codepipeline.yaml。

Capabilities 选择 CAPABILITY_IAM。

Role name 选择我们前面创建的 IAM 角色 cloudformation-lambda-execution。 点击 Next Step 按钮。

  • 在 Step 5: Service Role 页

点击 Create Role 按钮,在弹出的 IAM AWS CodePipeline is requesting permission to use resources in your account 页面,直接点击右下角 Allow 按钮,返回后点击 Next Step 按钮。

  • 在 Step 6: Review 页面,直接点击右下角 点击右下角的 Create Pipeline 按钮。最后来到 serverlessCodepipeline 项目详情页。
  • 增加测试部署阶段 在 serverlessCodepipeline 详情页点击 Edit 按钮。

在 Staging 阶段下面点击 +Stage 链接。

在 Stage name 栏输入 Beta,然后点击其下面的 +Action 按钮。

在 Action category 中,选择Deploy。

在 Action name 中,输入 executeChangeSet。

在 Deployment provider 中,选择 AWS CloudFormation。

在 Action mode: 中,选择 execute a changeset。前一步我们已经创建了 ChangeSet,将 SAM 模板转换为完整的 AWS CloudFormation 格式,现在我们要使用 deployChangeSet 部署 AWS CloudFormation 模板了。

在 Stack name:中,输入 serverlessCodepipeline。

在 Change set name:中,输入 serverlessCodepipelineChangeSet。

选择 Add Action。

回到页面顶部点击 Save pipeline changes。

选择 Save and continue。

查看结果

我们在 serverlessCodepipeline 项目详情页稍等10秒左右,Pipeline 会自动开始第一次部署。可以随时查看到各个步骤的执行情况,比如:

Source
GitHub
Succeeded 2 min ago
d24ff81
最后等到 Beta 步骤也完成,这时到 CloudFormation 的控制台查看已经创建出一个 serverlessCodepipeline ,整个过程大约持续 3到5 分钟。

然后到 API Gateway 控制台,可以看到创建出的 serverlessCodepipeline 的 API,点击其 Stages 下的 Prod 链接,可以看到形如下面的调用 URL: Invoke URL: https://xxxxxxxxx.execute-api.my-region.amazonaws.com/Prod

复制此 URL,打开一个新窗口,粘贴进地址栏,然后在后面再输入 /time,组成形如

https://xxxxxxxxx.execute-api.my-region.amazonaws.com/Prod/time

的链接再访问之,显示

“The time in Los Angeles is Mon Aug 07 2017 03:31:39 GMT-0700 (PDT)”
表示已经部署成功。

然后我们模拟代码更新,把你自己的 github 存储库中的 README.md 文件编辑一下,然后 git commit 到 github 上去。 然后再回到 serverlessCodepipeline 详情页,稍等一会我们会看到从 Source 开始整个管道会再次执行一遍。

执行到每一步时,我们都可以点击 Detail 链接到相关服务的详情页查看具体进度。比如 CloudFormation 会创建出一个新的 serverlessCodepipelineChangeSet 来执行变更。

最后到 API Gateway 的 serverlessCodepipeline API,选择一个 Stage ,再点选 Deployment History 可以看到 Deployment date时间更新了。

小结

今天我们继续结合实例,为大家讲解了使用AWS CodeBuild 构建 Lambda函数以及使用AWS CodePipeline实现自动化持续集成。这些也是基于AWS 无服务器应用模型和SAM模板,再与其它AWS运维的服务集成,共同实现无服务器应用的自动化运维。

相关资源链接

Serverless Application Model (SAM):
https://github.com/awslabs/serverless-application-model

无服务器服务官网:

AWS Lambda: https://aws.amazon.com/lambda

Amazon API Gateway: https://aws.amazon.com/api-gateway

运维相关的服务:

CloudFormation: https://aws.amazon.com/cloudformation

CodeBuild: https://aws.amaz.com/codebuild

CodePipeline: https://aws.amazon.com/codepipeline

 

作者介绍:

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

用无服务器应用模型部署无服务器应用 (一)无服务器应用模型入门

作者:薛峰

背景介绍

AWS无服务器架构也涉及到多个AWS服务,如AWS Lambda、Amazon API Gateway、Amazon DynamoDB等。如何把这些服务资源方便地管理起来呢?今天我们介绍的AWS 无服务器应用模型(AWS Serverless Application Model,以下简称AWS SAM)就是一种解决方案,它是一个开源的模型,结合AWS自动运维相关的服务如AWS CloudFormation 和AWS CodePipeline,统一管理多种资源,实现我们的无服务器应用的持续集成和部署。

我们从SAM开始,用几个具体例子为大家介绍使用AWS服务实现持续集成的具体方法,帮助大家快速上手,体验其强大和便捷。

SAM 简介

松鼠SAM是AWS Lamba和无服务器应用模型的吉祥物,寓意轻便、灵活、敏捷。它头顶的头盔上是希腊字母 lambda ,代表了AWS无服务器核心服务 Lambda。

SAM是 AWS 2016年11月发布的一个应用架构模型。遵循开源协议,是一个开放的说明文档。通过开源协议方式发布,也体现了AWS推动开源流动的努力。

官方的github地址如下:

https://github.com/awslabs/serverless-application-model

SAM实质上是一个AWS CloudFormation 的扩展,基于AWS CloudFormation 并且为无服务器做了优化,它简化了无服务器资源的管理,增加了无服务器相关的新资源类型。

SAM模板简介

AWS CloudFormation标准模板语法比较复杂,SAM模板提供了一套简化的语法,我们先来看一个简单的例子:

AWSTemplateFormatVersion: '2010-09-09'

Transform: AWS::Serverless-2016-10-31

Resources: 

  GetHtmlFunction:

    Type:
AWS::Serverless::Function

    Properties:

      CodeUri: s3://sam-demo-bucket/todo_list.zip

      Handler:
index.gethtml

      Runtime:
nodejs4.3

      Policies:
AmazonDynamoDBReadOnlyAccess

      Events:

        GetHtml:

          Type: Api

          Properties:

            Path:
/{proxy+}

            Method: ANY 

  ListTable:

    Type:
AWS::Serverless::SimpleTable 

最上面是模板格式的版本号和Transform声明。Transform声明告诉 CloudFormation这是一个 SAM 模板,需要转换成标准模板再执行。它的值取固定值,这里是 AWS::Serverless-2016-10-31,告诉CloudFormation这个模板里的声明都是无服务器应用的描述,以及进行相应的转换。

其余的两段其实都是 Resources 节点的子节点。这2段就是具体资源的声明:

GetHtmlFunction 段,Type: AWS::Serverless::Function,意思是创建一个Lambda函数,它有若干属性,如CodeUri指定函数的代码在S3的URL,Runtime 指定运行时的语言和版本,Policies 指定它的 IAM策略,以赋给它处理下游资源的权限。

Events 段,声明Lambda函数要响应的事件源。这里只有一个事件源,即创建一个 API Gateway 的 API,它有几个 API 相关的属性,比如路径、请求方式。

ListTable 这个资源Type是 AWS::Serverless::SimpleTable ,现在实际上是创建一个DynamoDB 表格。这里没有额外属性,就是以默认的容量规模创建,DynamoDB表容量默认值是每秒5次读写。

SAM 模板功能特性

可以和其它非SAM CloudFormation资源混用在同一个模板里 。SAM模板只增加了3种新资源,Lambda函数、API 和 SimpleTable,我们还可以使用其它标准CloudFormation资源,比如 S3 桶, Kinesis流,Step Function等等。

其它CloudFormation的标准功能SAM模板都支持,比如使用参数、映射和输出等,允许我们在CloudFormation执行时动态传入参数等, CloudFormation的内置函数我们在SAM也都可以使用,如连接字符串、拆分字符串等等。ImportValue也可使用,允许我们从现有架构中直接调取参数值,可以不再使用参数、映射等方式。总之这些标准功能使SAM模板可以和CloudFormation模板一样享受动态化的便利。

SAM 基于 CloudFormation,所以也是支持YAML 和JSON两种格式。

SAM 模板特有资源类型

SAM 模板新增3个特有资源类型,前面的简单例子已经展示了 ,即:AWS::Serverless::Function,AWS::Serverless::Api,AWS::Serverless::SimpleTable。这是当前Transform版本为 AWS::Serverless-2016-10-31所支持的特有资源类型。将来还有可能增加更多资源类型,到时请注意升级换用相应的Transform版本号。

第1个特有资源AWS::Serverless::Function 就是声明Lambda函数,模板中的包括Lambda函数所有的属性,如Handler、运行时、代码地址、描述等等。Events用来声明事件源,同一函数可以支持多个事件源。 Policies 声明IAM策略。Environment 可以声明环境变量,可用于传递给 Lambda函数。另外还有 Tags声明标签,这是 AWS 管理资源的通用功能,比如用于资源分组,账单和成本分解等。

第2个特有资源是 AWS::Serverless::Api,用于声明 API Gateway,关于API的详细定义,在 DefinitionUri 指定的swagger.yml里。其余的属性不多,主要是:StageName 阶段名称、CacheClusterEnabled 是否启用API Gateway的缓存,以及 CacheClusterSize缓存的容量。最后的Variables是传递给API 的参数,比如阶段参数,也是用来灵活部署的。

第3个特有资源是AWS::Serverless::SimpleTable,用于创建 DynamoDb 表。我们需要做的就是声明一下主键、类型,以及配置的容量规模。

AWS::Serverless::Function 事件源
在SAM模板中AWS::Serverless::Function资源下 Events 节点声明事件源。我们知道AWS Lambda 是事件驱动的无服务器函数服务,所以事件源也是部署Lambda函数的重要属性。事件源可以有很多种,大体分为3类:

  • 数据状态变化,如S3对象的新增、删除。
  • 请求端点,这里主要指的是通过 API  Gateway 暴露为对外服务的 HTTP API 接口。
  • 资源状态变化,如EC2实例的启动、停止等状态。

具体产生的事件源来自这些服务:S3、SNS、Kinesis、DynamoDB、Schedule、CloudWatchEvent、AlexaSkill。各事件源的各种事件及属性全部支持。具体这里不再赘述,大家可以参考各服务的事件部分相关文档。

Lambda环境变量

Lambda环境变量是可以动态传递给我们的函数的键值对,比如IAM的验证凭据,API的密钥等等。Lambda环境变量是Lambda服务本身的功能,在无服务器应用模型SAM里,我们可以方便地把环境变量管理起来。在SAM模板中以 Parameters 节点来声明环境变量。可以通过标准环境变量API使用,如 Node.js 的process.env 或 Python的os.environ,即Lambda的环境变量会添加到Node.js 的process.env 里,方便咱们开发时使用。下面我们看一个环境变量的具体例子。

使用SAM模板管理Lambda环境变量

请先从以下git库下载源码。

https://github.com/xfsnow/serverless/tree/master/sam/parameters

我们打开 parameters.yaml,看下面这个片段。

Parameters:

  MyEnvironment:

    Type: String

    Default: testing

    AllowedValues:

      - testing

      - staging

      - prod

    Description: Environment of this stack of resources

这里我们声明了一个Lambda环境变量,变量名是MyEnvironment。它的属性都可以顾名思义,类型是字符串,默认值是testing,可取值是testing、staging和 prod。最后还有一个描述。我们建议给各种变量和资源添加描述,以清楚说明它们具体的使用情况。

ApiHelloFunction:

    Type: AWS::Serverless::Function

    Properties:

      Handler: index.handler

      Runtime: nodejs6.10

      Environment:

        Variables:

          S3_BUCKET: !Ref MyEnvironment

然后在声明Lambda函数时在 Variables: 段声明一个环境变量S3_BUCKET,它的值使用CloudFormatioin内置函数!Ref读取SAM模板中的环境变量MyEnvironment。

var bucketName = process.env.S3_BUCKET;

相应地,在我们的Lambda函数代码中,index.js 中上述这段就可以通过全局变量process.env 获取到S3_BUCKET这个环境变量值了。

用CloudFormation部署SAM模板

我们还使用上述Lambda环境变量这个例子,具体介绍一下CloudFormation部署的方法。

以下操作流程使用 AWS CLI 命令执行。准备环境及了解 AWS CLI 基本功能请参见 https://aws.amazon.com/cn/cli/

请先从以下git库下载源码。

https://github.com/xfsnow/serverless/tree/master/sam/parameters

把下面命令中的 <bucket-name> 等变量值替换成你的具体的值。

在当前目录下执行以下命令,把文件上传到S3并打包成可用于 CloudFormation 的模板文件。

aws cloudformation package \

    --template-file parameters.yaml \

    --s3-bucket <bucket-name> \

    --output-template-file packaged_parameters.yaml

确认已经生成 packaged_parameters.yaml 文件。

执行以下命令。–parameter-overrides MyEnvironment=prod 表示部署时为 CloudFormation 的模板参数指定值为 prod。

aws cloudformation deploy \

   --template-file output_parameters.yaml \

   --stack-name parameters \

   --capabilities CAPABILITY_IAM \

   --parameter-overrides MyEnvironment=prod

顺利地话,会看到逐渐输出的返回结果。

Waiting for changeset to be created..

Waiting for stack create/update to complete

Successfully created/updated stack - lambdaProxy

这时到 CloudFormation 的控制台已经创建出一个 lambdaProxy,整个过程大约持续 1 到 2 分钟。 然后到 API Gateway 控制台,可以看到创建出的 lambdaProxy 的 API,点击其 Stages 下的 Prod 链接,可以看到形如下面的调用 URL: Invoke URL: https://xxxxxxxxx.execute-api.my-region.amazonaws.com/Prod

点击它,打开一个新窗口,显示

{“bucketName”:”prod”}

表示已经部署成功。

再执行一次 aws cloudformation deploy,把 MyEnvironment 参数变成 testing

aws cloudformation deploy \

   --template-file output_parameters.yaml \

   --stack-name parameters \

   --capabilities CAPABILITY_IAM \

   --parameter-overrides MyEnvironment=testing

等待执行完毕后,刷新刚才的调用 URL,可以看到内容已经更新成了

{“bucketName”:”testing”}

这个例子演示了我们在SAM模板中定义的环境变量在具体部署时可以灵活赋成不同的值,然后部署出相应的效果。

小结

今天我们介绍了AWS 无服务器应用模型和SAM模板的基本功能和特性,并带领大家用一个实例体验了通过CloudFormation部署SAM模板。随着无服务器应用开发逐渐复杂,规模越来越大,涉及的服务和资源也会越来越多,SAM确实为我们提供了一种使用AWS服务进行统一管理的方法,希望大家多多体验。

下一篇中,我们将进一步为大家讲解使用AWS CodeBuild 构建 Lambda函数以及使用AWS CodePipeline实现自动化持续集成。

 

作者介绍:

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

如何使用 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 功能。欢迎在评论中留下您的反馈或建议。

光环新网运营的AWS中国(北京)区域HPC集群创建

在上个博客“在AWS云上快速搭建高性能计算(HPC)集群”中,我们介绍了高性能计算的使用场景,框架和如何在AWS Global创建HPC集群,但在光环新网运营的AWS中国(北京)区域并不支持使用CFNCluster直接创建HPC,因此我们需要使用CloudFormation手工创建集群,整个过程并不复杂。步骤如下:

1.进入光环新网运营的AWS中国(北京)区域的Console,然后进入CloudFormation的服务。如下图:

2.点击 “Create New Stack”后,弹出下面的界面。

3.在界面中制定CloudFormation的模板文件如下。

https://s3.cn-north-1.amazonaws.com.cn/cfncluster-cn-north-1/templates/cfncluster.cfn.json

4.在后续界面中下面参数必须定义:

Stack name:要创建HPC集群的名称

AvailablityZone:指定要在那个可用区创建HPC集群

VPCId:指定需要创建集群的VPCId

MasterSubnetId:指定Master节点的子网ID

KeyName:指定EC2服务器访问的key

Scheduler:指定高性能计算的管理框架,默认是SGE,有Openlava,Torque等可以选择。

5.可选参数定义:

InitialQueueSize:HPC集群的初始节点数

ComputeInstanceType:集群计算节点的类型

MasterInstanceType:Master节点的类型

MaxQueueSize:集群最大节点数

PlacementGroup:节点的放置组

对于全部的配置参数说明,可以参考下面链接:

http://cfncluster.readthedocs.io/en/latest/configuration.html

6.点击Next后,输入集群的tag。

7.点击左下方的checkbox运行AWS Cloudformation帮助创建资源,然后点击创建。

8.等待当前HPC集群的创建状态变为COMPLETE,查看下方的Outputs消息输出,找到HPC Master节点的IP。

9.使用前面Output中的Master节点的IP或去Console中的EC2里面找到刚才创建的Master节点的机器,通过ssh连接,然后运行HPC的命令。

  • 总结

在AWS中国区,你可以使用CloudFormation快速的创建HPC集群,AWS提供了丰富的服务器类型供你选择,你可以选择基于CPU或GPU等不同类型的服务器,也可以选择SGE,OpenLava等分布式资源管理软件来调度你的程序,如果我们不配置,默认的资源管理软件是SGE。

作者介绍

蓝勇,AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在DR解决方案、数据仓库、RDS服务、企业应用、自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前,在甲骨文中国担任资深售前工程师,负责售前方案咨询和架构设计,在数据库,中间件,大数据及企业应用方面有丰富经验。