Author: AWS Team


利用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架构和私有云、混合云、公有云的解决方案融合。

 

搭建基于S3的HBase读备份集群

作者:刘磊

当前aws的很多客户已经从将s3作为HBase的存储中获益,这当中包括更低的存储花费、更好的数据可靠性、更容易的扩展操作等待。比如FINRA就通过将HBase迁移到s3上将在存储上的花费降低了60%,此外还带来了运维上的便利,以及架构上的重大优化:将s3作为统一的存储层,实现了更彻底的存储和计算分离。在s3上部署HBase集群,可以让你在集群启动后立即进行数据查询操作,而不用等待漫长的快照恢复过程。

随着Amazon EMR 5.7.0的发布,现在你可以在集群层面进一步提升数据的高可用性和高可靠性,方法是基于同一个s3存储桶建立多个HBase的读备份集群。这会让你的数据通过读备份集群及时地被用户访问,即使在主集群遇到问题关闭的时候,当然你还可以通过在多个可用区中部署读备份集群来进一步增加数据访问服务的可靠性。

接下来的文章将告诉你如何在s3上建立HBase的读备份集群。

HBase 简介

Apache HBase是Apache Hadoop生态体系中的大规模、可扩展、分布式的数据存储服务。同时它还是开源的,非关系型的版本数据库,默认情况下运行在HDFS之上。它的设计初衷是为包含了数百万个列的数十亿行记录提供随机的、强一致性的、实时访问。同时它还和Apache Hadoop、Apache Hive和Apache Pig等大数据服务紧密结合,所以你可以轻易地为并行数据处理提供快速的数据访问。HBase数据模型、吞吐量、和容错机制能很好地为广告、web分析、金融服务和基于时间序列数据的应用等工作负载提供支持。

和其他很多Nosql数据库类似,HBase中的表设计直接影响着数据的查询和访问模式,根据这些模式的不同,查询的性能表现也会有非常大的差异。

HBase on S3

在建立基于S3的HBase读备份集群之前,你必须先学会HBase on S3的部署方法,本段为那些不熟悉HBase on S3架构的人提供了一些基本信息。

你可以通过将S3作为HBase的存储层,来分离集群的存储和计算节点。这使得你可以根据计算需求来规划集群,从而削减开支,毕竟你不再需要为HDFS上存储的3备份数据支付费用了。

HBase on S3架构中的默认EMR配置使用内存和本地磁盘来缓存数据,以此来提升基于S3的读性能。你可以在不影响底层存储的情况下任意地对计算节点进行伸缩,或者你还可以关闭集群来节省开支,然后快速地在另一个AZ中重新进行部署。

HBase on S3读备份集群应用案例

使用HBase on S3架构使得你的数据被安全、可靠地存储起来。它将数据和集群隔离进行存储,消除了因为集群异常终止带来数据丢失的可能性。尽管如此,在一些特殊情况下,你还是会希望数据能获得更高的可用性,比如集群异常终止或者整个AZ失效。另外一个情况是,通过多个集群访问一个S3上的根目录,你可以隔离HBase集群的读写操作,从而来降低集群的压力,提供更高SLA的查询服务。尤其是在主集群因为bulk load、heavy write、compaction等操作变得异常繁忙的时候。

下图展示了没有读备份的HBase on S3架构,在这个场景下,诸如集群终止和AZ失效等异常情况会使得用户无法访问数据。

S3上的HBase根目录,包含了HFile和表的原数据信息。

EMR 5.7.0之前的版本,无法将多个HBase集群指向同一个S3上的根目录,为了获得更高的可用性,你需要在S3上创建多个数据副本,并管理它们之间的一致性。

随着EMR 5.7.0的发布,现在你可以启动多个读备份集群并指向S3桶上同一个根目录,保证了你的数据通过读备份集群它们总是可达的。

下面是一些使用HBase读备份集群的例子,展示了启用前后的一些对比情况。

处于同一个AZ的HBase读备份集群:

处于不同AZ的HBase读备份集群:

基于S3的HBase读备份集群的另一个好处是可以更加灵活地根据具体的工作负载来规划你的集群。比如,虽然你的读负载很低,但还是想要获得更高的可用性,那么就可以启动一个由较小实例组成的规模较小的集群。另一个例子是当你遭遇bulk load时,在高峰期集群需要扩张到很大以满足计算需求,在bulk load结束后,集群可以立即缩减以节省开支。在主集群伸缩的时候,读备份集群可以维持一个固定的规模以对外提供稳定的查询服务。

步骤

使用下列的步骤来启动基于S3 的HBase读备份集群,这项功能只针对EMR 5.7.0之后的版本。

创建使用HBase on S3的EMR集群:

aws emr create-cluster --termination-protected --applications Name=Hadoop Name=Hive Name=HBase Name=Spark Name=Phoenix --ec2-attributes '{"KeyName":""}' --release-label emr-5.7.0 --instance-groups '[{"InstanceCount":1,"InstanceGroupType":"MASTER","InstanceType":"m3.xlarge","Name":"Master - 1"},{"InstanceCount":20,"BidPrice":"0.15","InstanceGroupType":"CORE","InstanceType":"m3.2xlarge","Name":"Core - 2"}]' --configurations '[{"Classification":"emrfs-site","Properties":{"fs.s3.consistent.retryPeriodSeconds":"1","fs.s3.consistent":"true","fs.s3.consistent.retryCount":"5","fs.s3.consistent.metadata.tableName":"YOUR_CONSISTENT_VIEW_TABLE_NAME"},"Configurations":[]},{"Classification":"hbase","Properties":{"hbase.emr.storageMode":"s3","hbase.emr.readreplica.enabled":"true"},"Configurations":[]},{"Classification":"hbase-site","Properties":{"hbase.rootdir":"s3:///"},"Configurations":[]}]' --service-role EMR_DefaultRole --name 'HBase Read Replica'

配置文件示例JSON

[ 
   { 
      "Classification":"hbase-site",
      "Properties":{ 
         "hbase.rootdir":"s3://{S3_LOCATION}",
      }
   },
   { 
      "Classification":"hbase",
      "Properties":{ 
         "hbase.emr.storageMode":"s3",
         "hbase.emr.readreplica.enabled":"true"
      }
   }
]

向主集群添加数据

需要特别注意的是,在使用HBase读备份集群时,你必须要确保主集群上所有的写操作都被刷新到S3桶的HFile中。读备份集群会读取这些HFile中的数据,任何没有从Memstore刷新到S3的数据都不能通过读备份集群访问。为了确保读备份集群总是读到最新的数据,请参考以下步骤:

  • 写入数据到主集群(大批量写入请使用Bulkload)
  • 确保数据被刷新到S3桶中(使用Flush命令)
  • 等待region 分割以及合并操作完成以确保HBase表的元数据信息保持一致性状态
  • 如果任何region发生了分割、合并操作,或者表的元数据信息发生了变化(表的增加和删减),请在从集群上运行refresh_meta命令
  • 当HBase表发生更新操作后,请在从集群上运行refresh_hfiles命令

从备份集群读区数据

你可以像往常一样从备份集群检索任何数据。

从主集群读取数据的截图:

从备份集群读取数据的截图:

可以看出,两个集群返回了同样的数据。

保持备份集群和主集群的一致性
为了保持备份集群数据和主集群的一致性,请参考以下建议:

在备份集群上:

1.运行refresh_hfiles命令:

  • HBase表中的数据发生变化时(增、删、改)

2.运行refresh_meta:

  • Region发生变化时(splits,compacts)或者集群中增加、删除了HBase表

在主集群上:

1.如果启用了compaction,运行compaction命令以避免Major Compation被触发引起数据的不一致性。

相关的属性和命令:
HBase属性:

Config Default Ex planation
hbase.meta.table.suffix “” Adds a suffix to the meta table name: value=’test’ -> ‘hbase:meta_test’
hbase.global.readonly.enabled False Puts the entire cluster into read-only mode
Hbase.meta.startup.refresh False Syncs the meta table with the backing storage. Used to pick up new tables or regions.

如果hbase.emr.readreplica.enabled被设置为true,那么上述属性会被自动设置好。

HBase命令:

Command Description
refresh_hfiles <Tablename Refreshes HFiles from disk. Used to pick up new edits on a read replica.
clear_block_cache <tablename> Clears the cache for the specified table.
refresh_meta Syncs the meta table with the backing storage. Used to pick up new tables/regions.

总结

现在你可以为HBase建立高可用的读备份集群,通过它,在主集群发生异常情况时,你仍然可以获取稳定的数据查询服务。

 

作者介绍

刘磊,AWS大数据顾问,曾供职于中国银联电子支付研究院,期间获得上海市科技进步一等奖,并申请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之前曾长期从事互联网应用开发,先后在新浪、唯品会等公司担任架构师、技术总监等职位。对跨平台多终端的互联网应用架构和方案有深入的研究。

通过机器学习自动优化 DBMS

本客座文章由卡内基梅隆大学的 Dana Van Aken、Geoff Gordon 和 Andy Pavlo 发布。本项目演示学术研究人员如何利用我们的 AWS Cloud Credits for Research Program 实现科学突破。点击:原文链接

数据库管理系统 (DBMS) 是所有数据密集型应用程序最重要的组成部分。它们可以处理大量数据和复杂工作负载。但它们拥有成百上千的配置“开关”,控制了诸如用于缓存的内存量以及将数据写入存储的频率等诸多因素,因此管理起来很困难。组织通常会聘请专家来帮助完成优化活动,但对许多组织来说专家的费用过于高昂。

卡内基梅隆大学数据库研究组的学生和研究人员开发了一款新工具 OtterTune,它可以针对 DBMS 配置开关自动查找较佳的设置。其目标是让每个人都可以轻松部署 DBMS,即使是毫无数据库管理专业知识的人。

与其他 DBMS 配置工具不同,OtterTune 利用在优化之前的 DBMS 部署期间获得的知识来优化新的部署。这可以显著缩短优化新 DBMS 部署所需的时间以及减少所需的资源。为此,OtterTune 维护了一个存储库,用于存储在之前的优化会话中收集的优化数据。它利用此类数据来构建机器学习 (ML) 模型,以捕获 DBMS 对不同配置的响应方式。OtterTune 使用这些模型来指导新应用程序的试验,进而推荐可改善最终目标 (例如,减少延迟或提高吞吐量) 的设置。

在本文中,我们将讨论 OtterTune ML 管道中的每一个组件,并演示这些组件如何彼此交互以优化 DBMS 配置。然后,我们将通过比较 OtterTune 推荐的最佳配置与数据库管理员 (DBA) 及其他自动优化工具选择的配置的性能,评估 OtterTune 对 MySQL 和 Postgres 的优化效力。

OtterTune 是一款开源工具,由卡内基梅隆大学数据库研究组的学生和研究人员开发。GitHub 上提供了所有代码,并且代码已获得 Apache 2.0 许可。

OtterTune 工作原理

下图显示了 OtterTune 的组件和工作流。

在新的优化会话开始时,用户须告知 OtterTune 要优化的最终目标 (例如,延迟或吞吐量)。客户端控制器连接到目标 DBMS,并收集其 Amazon EC2 实例类型和当前配置。

然后,控制器开始第一个观察期,观察 DBMS 并记录最终目标。该观察期结束后,控制器收集 DBMS 中的内部指标,例如,MySQL 从磁盘读取的页数以及写入磁盘的页数。控制器向优化管理器返回最终目标和内部指标。

OtterTune 的优化管理器收到指标时,将指标存储在存储库中。OtterTune 根据结果计算控制器应在目标 DBMS 上安装的下一个配置。优化管理器向控制器返回此配置,并估计优化此配置能够获得的预期改进。用户可以决定是继续还是终止优化会话。

备注

OtterTune 维护其支持的各 DBMS 版本的开关黑名单。该黑名单中包含无优化意义的开关 (例如,DBMS 存储文件的路径名称),或者可能导致严重或隐藏后果 (例如,可能导致 DBMS 丢失数据) 的开关。每个优化会话开始时,OtterTune 会向用户提供该黑名单,让用户添加他们不希望 OtterTune 优化的任何其他开关。

OtterTune 做出了一些假设,这些假设可能会限制其对某些用户的有用程度。例如,它假设用户拥有管理权限,允许控制器修改 DBMS 的配置。如果用户不具备该权限,则可以在其他硬件上部署另外一份数据库,用于进行 OtterTune 优化试验。这要求用户重播工作负载跟踪或转发来自生产 DBMS 的查询。有关假设和限制的完整讨论,请参阅我们的文章

机器学习管道

下图显示了在数据流过 OtterTune 的 ML 管道时如何得到处理。所有观察结果都保存在 OtterTune 的存储库中。

OtterTune 先将观察结果传入 Workload Characterization 组件。此组件确定能够最准确地捕获不同工作负载的性能差异和显著特点的一小部分 DBMS 指标。

接下来,Knob Identification 组件生成对 DBMS 性能影响最大的开关的排序列表。OtterTune 随后将所有此类信息馈送到 Automatic Tuner。此组件将目标 DBMS 工作负载映射到其数据存储库中最相似的工作负载,并再次使用此工作负载数据生成更好的配置。

我们来详细讨论一下 ML 管道中的每个组件。

Workload Characterization: OtterTune 使用 DBMS 的内部运行时指标来确定工作负载行为方式的特征。这些指标准确代表了工作负载,因为它们捕获了其运行时行为的许多方面。不过,许多指标都是多余的:一些指标其实是相同的,只是单位不同;还有一些指标表示 DBMS 的各独立组件,但它们的值高度相关。必须清除多余的指标,这可以降低使用这些指标的 ML 模型的复杂性。为此,我们基于 DBMS 指标的关联模式将它们集群化。然后,我们从每个集群中选择一个具有代表性的指标,具体而言就是最接近集群中心的指标。ML 管道中的后续组件会使用这些指标。

Knob Identification:DBMS 可能拥有数以百计的开关,但只有一小部分能够影响 DBMS 的性能。OtterTune 利用常用的功能选取技术 (称为 Lasso) 来确定严重影响系统整体性能的开关。通过向存储库中的数据应用此项技术,OtterTune 可以确定 DBMS 开关的重要性顺序。

然后,在提供配置建议时,OtterTune 必须决定使用多少个开关。使用过多开关会明显增加 OtterTune 的优化时间。使用过少开关则会导致 OtterTune 找不到最佳配置。为了自动完成此流程,OtterTune 使用一种增量方法。这种方法逐渐增加优化会话中使用的开关数。使用这种方法,OtterTune 可以先针对一小部分最重要的开关探究并优化配置,然后再扩展范围,考虑其他开关。

Automatic Tuner:Automated Tuning 组件在每个观察期后执行两步分析,确定 OtterTune 应该推荐的配置。

首先,系统使用在 Workload Characterization 组件中确定的指标的性能数据,来确定上一个优化会话中最能代表目标 DBMS 工作负载的工作负载。它将会话的指标与之前工作负载的指标进行比较,确定对不同开关设置做出相同反应的指标。

然后,OtterTune 选择另一个开关配置进行尝试。它会根据收集的数据以及存储库中最相似工作负载的数据,调整统计模型。使用此模型,OtterTune 可以预测 DBMS 在每个可能配置下的性能。OtterTune 优化下一个配置,换探索为利用,从收集信息以改善模型变为不断尝试在目标指标上做得更好。

实现

OtterTune 是用 Python 编写的。

对 Workload Characterization 和 Knob Identification 组件而言,运行时性能并不是主要考虑因素,因此我们使用 scikit-learn 来实现对应的 ML 算法。这些算法在后台进程中运行,从而在 OtterTune 存储库中有新数据可用时纳入这些数据。

而对于 Automatic Tuner,ML 算法是关键。它们在每个观察期之后运行,从而纳入新数据,以便 OtterTune 能够选取下一次尝试的开关配置。由于要考虑性能,我们使用 TensorFlow 来实现这些算法。

为了收集有关 DBMS 硬件、开关配置和运行时性能指标的数据,我们将 OtterTune 的控制器与 OLTP-Bench 基准测试框架集成在了一起。

试验设计

为进行评估,我们比较了使用 OtterTune 选择的最佳配置与使用以下配置的 MySQL 和 Postgres 的性能:

  • 默认:DBMS 提供的配置
  • 优化脚本:开源优化顾问工具生成的配置
  • DBA:DBA 选择的配置
  • RDS:由 Amazon RD 管理并部署在相同 EC2 实例类型上的 DBMS 的自定义配置

我们在 Amazon EC2 竞价型实例上进行了所有试验。我们在两个实例上运行了每个试验:一个针对 OtterTune 控制器,另一个针对目标 DBMS 部署。我们分别使用了 m4.large 和 m3.xlarge 实例类型。我们在配备 20 个内核和 128 GB RAM 的本地计算机上部署了 OtterTune 的优化管理器和数据存储库。

我们使用了 TPC-C 工作负载,它是评估联机事务处理 (OLTP) 系统性能的行业标准。

评估

对于我们在试验中使用的每个数据库 (MySQL 和 Postgres),我们测量了延迟和吞吐量。下图显示了结果。第一张图显示 99% 的延迟,表示最坏情况下完成事务的时间。第二张图显示吞吐量结果,以每秒完成的平均事务数衡量。

MySQL 结果

比较 OtterTune 生成的最佳配置与优化脚本和 RDS 生成的配置后发现,使用 OtterTune 配置,MySQL 的延迟减少了大约 60%,吞吐量提高了 22%-35%。OtterTune 还生成了几乎与 DBA 选择的配置一样出色的配置。

只有少数几个 MySQL 开关显著影响 TPC-C 工作负载的性能。OtterTune 和 DBA 生成的配置为每个这些开关提供了理想的设置。RDS 的表现稍差一些,因为它为一个开关提供了次优的设置。优化脚本的配置效果最差,因为它只修改了一个开关。

Postgres 结果

在延迟方面,与 Postgres 的默认设置相比,优化工具 OtterTune、DBA 和 RDS 生成的配置全都获得了类似的改善。我们或许可以把这些改善归功于 OLTP-Bench 客户端与 DBMS 之间的网络往返行程所需的开销。在吞吐量方面,与 DBA 和优化脚本选择的配置相比,OtterTune 建议的配置使 Postgres 的吞吐量提高了大约 12%,与 RDS 相比,提高了大约 32%。

与 MySQL 类似,只有少数几个开关显著影响 Postgres 的性能。OtterTune、DBA、优化脚本以及 RDS 生成的配置全都修改了这些开关,并且大部分提供了非常理想的设置。

结论

OtterTune 可自动完成为 DBMS 的配置开关寻找理想设置的过程。为优化新的 DBMS 部署,它会再次使用之前优化会话中收集的训练数据。由于 OtterTune 不需要生成初始数据集即可训练其 ML 模型,因此优化时间明显缩短。

接下来做什么?为适应 DBaaS 部署 (无法远程访问 DBMS 主机计算机) 的日益普及,OtterTune 将很快能够在无需远程访问的情况下,自动检测目标 DBMS 的硬件功能。

有关 OtterTune 的更多详细信息,请参阅我们的文章或 GitHub 上的代码。请密切关注本网站,我们即将在网站中提供 OtterTune 作为联机优化服务。
作者简介

Dana Van Aken 是卡内基梅隆大学计算机科学系的博士生,由 Andrew Pavlo 博士指导。她的主要研究课题是数据库管理系统。她目前的工作重点是开发自动化技术以使用机器学习来优化数据库管理系统。

Andy Pavlo 博士是卡内基梅隆大学计算机科学系数据库学科的助理教授,也是卡内基梅隆大学数据库研究组和并行数据实验室的一名成员。他的工作还需要与英特尔大数据科技中心协作。

Geoff Gordon 博士是卡内基梅隆大学机器学习系的副教授兼副教导主任。他的研究课题包括人工智能、统计机器学习、教育数据、游戏理论、多机器人系统,以及概率域、对立域和常规求和域的规划。

 

本文首发于亚马逊AWS官方博客网站,原创文章如转载,请注明出处。

 

 

VMware Cloud on AWS 现已推出

去年我曾向您介绍过我们正在和 VMware 的朋友一道所做的工作,那就是构建 VMware Cloud on AWS。正如我当时所分享的,这是一种原生的完全托管服务,直接在裸机 AWS 基础设施上运行 VMware SDDC 堆栈,以维持客户预期的弹性和安全性。这使得您能够从 AWS 的可扩展性和抗风险能力,以及作为我们的安全优先架构的基本组成部分的网络和系统级硬件功能中获益。

VMware Cloud on AWS 允许您利用您已经了解和拥有的东西。在迁移到公有云后,您现有的技能、在培训方面的投资、操作实践以及对软件许可证的投资仍然有价值且适用。作为这一举措的一部分,您可以将构建和运行数据中心、对硬件进行现代化改造以及进行扩展以满足瞬时或短期需求抛诸脑后。您还可以利用长长的 AWS 计算、数据库、分析、物联网、AI、安全、移动、部署和应用程序服务清单。

初期可用性
在融入了我们通过 Early Access Beta 计划从许多客户和合作伙伴那里收集到的反馈后,今天,在 VMworld 大会上,VMware 与 Amazon 共同宣布推出 VMware Cloud on AWS 的初始版本。该服务初期只在美国西部 (俄勒冈州) 区域推出,可通过 VMware 及 VMware Partner Network 成员获得。该服务旨在支持常见的使用情形,如数据中心扩展、应用程序开发和测试以及应用程序迁移。

该服务由 VMware 销售、交付、支持和计费。它支持自定义大小的虚拟机,运行 VMware 支持的任何操作系统,并使用单租户裸机 AWS 基础设施,以便您可以将 Windows Server 许可证带到云中。每个 SDDC (软件定义的数据中心) 由 4 到 16 个实例组成,每个实例有 36 个内核、512 GB 内存和 15.2 TB NVMe 存储。群集目前在单个 AWS 可用区 (AZ) 中运行,对跨可用区的群集支持正在准备阶段。您可以在几小时内启动整个 VMware SDDC,在几分钟内扩展或缩减主机容量。

NSX 网络平台 (由运行速度最高可达 25 Gbps 的 AWS Elastic Networking Adapter 提供支持) 支持多播通信、用于管理和计算的单独网络以及 IPSec VPN 隧道到本地防火墙、路由器等等。

下面概述了各部分是如何组合在一起的:

您如今使用的 VMware 和第三方管理工具 (vCenter ServerPowerCLIvRealize Suite 以及调用 vSphere API 的代码) 在您构建混合 VMware 环境 (结合现有本地资源以及在 AWS 中启动的资源) 时能够正常工作。此混合环境将使用一种新的 VMware 混合链接模式为您的本地和云资源创建单个统一视图。您可以使用熟悉的 VMware 工具来管理应用程序,而无需购买任何新的或自定义硬件、重新编写应用程序或修改运营模式。

您的应用程序和代码可以访问全套 AWS 服务 (数据库分析AI 服务都是不错的切入点)。使用这些服务将单独计费,并且您需要创建一个 AWS 账户

在 VMworld 上了解更多信息
如果您出席了在拉斯维加斯召开的 VMworld 大会,请务必参加 90 多场 AWS 专题研讨会中的一些:

另外,一定要顺便去看一看 300 号展台,跟我在 AWS 团队的同事打个招呼。

正在筹备中的工作
自去年以来,我们的团队已经走过漫长旅程,但事情已经有了很大进展!

VMware 和 AWS 不断投资,以便支持新的功能和使用情形,如应用程序迁移、数据中心扩展以及应用程序测试和开发。正在筹备中的工作包括增加更多 AWS 区域,支持更多使用情形 (如灾难恢复和数据中心整合),添加认证以及更深入地与 AWS 服务集成。

Jeff

原文链接,本文首发于亚马逊AWS官方博客网站,原创文章如转载,请注明出处。

挖掘EB级别数据的价值 – Redshift Spectrum介绍及最佳实践

随着数据存储技术的快速发展,众多企业客户可以以低成本存储PB级别甚者EB级别的数据。这使得大数据分析在近几年来不但成为现实而且愈发火热。然而真正实现海量数据的分析既要有存储海量数据的资源,又要有足够强大的分析能力。近年来我们看到数据分析能力的发展并没有追赶上存储技术的发展速度 。现实中企业客户虽然有了可以收集并存储大量数据的能力,但很多数据并不能被有效的分析甚至根本未作任何分析,形成了所谓的暗数据。这使得数据分析能力成为实现大数据分析的真正瓶颈。

作为一个托管的数据仓库服务,Amazon Redshift从它发布至今已经帮助全球成千上万的客户解决了PB级别数据的分析能力,实现了复杂SQL的快速查询。但随着数据的飞速增长,我们看到越来越多的客户数据开始逼近EB级别。对于这样体量的大数据,虽然Redshift也可以支持快速的复杂SQL查询,但毕竟我们需要启动更多的Redshift集群,消耗更多的CPU和存储成本,同时还要付出更多的数据加载时间。相反如果我们为了节省资源和成本把数据放在S3上,通过EMR集群也可以实现快速低成本的数据清理,但针对复杂的(诸如Join类)的查询速度会很慢,不能很好支持。这形成了一个鱼与熊掌不可兼得的选择题。

为了真正摆脱数据分析的瓶颈、消灭暗数据,我们的客户需要既能高效执行复杂的查询,又能享受高度可扩展的数据并行处理,也能利用近乎无限的低成本的S3存储资源,还要可以支持多种常用的数据格式。满足这种”既又也还”的任性就是我们的新服务Redshift Spectrum的使命。

Redshift Spectrum 介绍

Redshift Spectrum可以帮助客户通过Redshift直接查询S3中的数据。如同Amazon EMR,通过Redshift Spectrum客户可以方便的使用多种开放数据格式并享有低廉的存储成本,同时还可以轻松扩展到上千个计算节点实现数据的提取、筛选、投影、聚合、group、排序等等操作。Redshift Spectrum采用了无服务器架构,所以客户不需要额外配置或管理任何资源,而只需为Redshift Spectrum的用量付费。使用方面,Redshift Spectrum享有和Amazon Redshift一样的复杂查询的优化机制、本地数据的快速读取以及对标准SQL的支持。结合上述功能特点,Redshift Spectrum可以在几分钟内完成对EB级别的数据的复杂查询,这使它在众多大数据分析服务中脱颖而出。我们做了一个实验,在对一个EB的数据做涉及四个表的join,filter和group的查询时,1000个节点的Hive集群预估需要耗时5年,而Redshift Spectrum只用了173秒。

另外Redshift Spectrum 是Amazon Redshift的一个内置功能,所以使用Redshift Spectrum 对Redshift客户现有的查询服务和BI工具不会有任何影响。在Redshift Spectrum的底层,我们负责管理着成千上万的跨多个可用区的计算节点。这些节点根据客户查询任务的复杂度和数据量实现透明的扩展和分配,前端的客户无需做任何资源部署和配置。Redshift Spectrum也很好的支持了高并发 – 客户可以通过任何多个Amazon Redshift集群同时访问S3上的数据。

Redshift Spectrum 上一个查询任务的生命周期

一切从Redshift Spectrum的查询任务提交给Amazon Redshift集群的领导节点开始。首先,领导节点负责优化、编译、并推送查询任务给Amazon Redshift集群的计算节点。然后,计算节点从外部表获得数据目录,并基于查询任务里的join和filter动态移除不相关的数据分区。这些计算节点同时也会检测在Redshift本地是否已有部分查询数据,从而只从S3上扫描本地没有的数据以提升效率。

接下来,Amazon Redshift的计算节点会基于需要处理的数据对象生成多个查询需求,并行提交给Redshift Spectrum,Redshift Spectrum再据此启动上千个工作线程。 这些工作线程进一步从S3上扫描、筛选并聚合数据,将处理好的结果数据传回Amazon Redshift集群。最后,传回的结果数据在Redshift 集群本地作join和merge操作,然后将最终结果返回给客户。

Redshift Spectrum 的优势

Redshift Spectrum的架构设计有很多优势。第一,剥离计算与S3上的存储,使计算资源可以独立弹性扩展。第二,大幅提升了并发效率,因为客户可以用多个Redshift集群访问同一组S3上的数据。第三,Redshift Spectrum沿用了Amazon Redshift的查询优化机制,可以生成高效的查询规划,即便面对诸如多表join或者带统计函数(window function)的复杂查询也能胜任。第四,可以对多种格式的数据源直接查询 – Parquet, RCFile, CSV, TSV, Sequence, Avro, RegexSerDe等等。这意味着我们无需再做数据加载和转化,同时也消除了存储重复数据带来的成本浪费。第五,通过对开放数据格式的支持,客户的不同团队也可以借助其他的AWS服务访问同一组S3上的数据,实现协同办公。拥有上述这些优势的同时,因为Redshift Spectrum 是 Amazon Redshift的内置功能,客户同时也享受了与Amazon Redshift同级别的端到端的安全、合规、以及安全认证。

Redshift Spectrum最佳实践

使用Redshift Spectrum时,我们建议可以从数据分区,列数据结构和数据压缩这几个关键点出发实现S3上数据查询效率的提升以及降低查询成本。数据分区方面,按照日期、时间或其他客户自定义的key来对数据进行分区可以帮助Redshift Spectrum 在查询中动态的移除不相关分区以减少扫描的数据量。数据结构方面,我们推荐使用列存储,比如Parquet格式,这样Redshift Spectrum只需扫描要查询的列而不是整个数据,这可以进一步减少扫描的数据量。数据压缩方面,如果数据可以预先用Redshift Spectrum支持的压缩格式压缩,我们同样可以再次减少扫描的数据量。

另外,从数据访问频率来看,我们建议将频繁访问的数据放到Amazon Redshift集群中,以获得Redshift作为数据仓库服务带来的众多优势。同时,更多的海量数据可以以多种开放数据格式存储在S3上,比如历史数据或近期数据,利用Redshift Spectrum 将S3变成一个可随时支持SQL查询的数据湖。

下边再列举六个具体使用时的技巧:

  1. 使用多个临时Redshift 集群提升并发:Redshift Spectrum支持多个Redshift集群访问同一组S3上的数据,我们可以考虑在业务高峰期时临时开启多个Redshift集群,提升并发支持更多的查询任务。因为数据庞大的表我们可以放在S3上,所以这些临时Redshift集群本地只需存储相对少量的数据即可胜任,在高峰期过后可以关闭这些临时集群。这样客户用相对较小的几个集群就可以轻松应对高峰的大并发。
  2. 列存储文件的分区应尽量基于常用的数据列:常用来做filter、join等操作的数据列是分区的首选。另外,分区的粒度过细可能会使读取分区信息花费更多时间,但同时也会极大减少数据查询时的数据量。客户可以根据自己的实际情况权衡。最后,S3上的数据文件大小应尽量平均,例如10个256MB的文件要比1个1GB+6个256MB的文件读取更高效。
  3. 合理配置Redshift集群以优化Redshift Spectrum的性能:在Redshift Spectrum查询S3上的数据时,其并行线程取决于两个因素:(1) Query层面 – 每个slice上每个query可并行执行查询的线程数 (上限是每个slice每个query最多10个线程) (2) 节点层面 – 每个节点拥有的slice数量,不同类型节点的slice数量也不同。所以做一个简单的数学运算:当数据文件总数 ≤ (1) × (2),则在集群内部署更多的节点并不会提升性能。这个方法可以帮我们基于数据文件数量配置大小合理的Redshift 集群,从而在保证性能的同时减少资源浪费。
  4. 单表筛选、聚合类的查询在Redshift Spectrum上更有性能优势:这类没有join的查询任务通常性能瓶颈在I/O层面,比如数据扫面速度,这方面往往Redshift Spectrum可以比Redshift做的更快。
  5. 通过推送predicate类操作到Redshift Spectrum 提升对数据查询速度:Redshift Spectrum对S3上数据的扫描,投影,筛选,聚合等操作是独立于Redshift集群的。这类操作同时也不会占用Redshift集群的资源。常用的这类指令操作例如group by, like, count, sum, avg, min, max, regex_replace等等。我们可以善用这类操作减少Redshift集群的负载,提升查询效率
  6. 基于表的尺寸合理分配存储:我们建议尽量将大尺寸的表分成多个文件(诸如包含原始数据)放在S3上,而只将中小尺寸的表放入Redshift集群。这样在进行常规join查询时可以取得比较均衡的性能表现。

通过上述的介绍,希望大家对Redshift Spectrum有一个基本的了解。通过高度的并行处理,查询的优化以及对EB级别数据的复杂查询支持,相信Redshift Spectrum 能真正帮助企业客户挖掘海量数据的价值,在大数据分析上更进一步。

作者介绍

刘宁,致力于AWS数据库云服务的应用和推广。在加入AWS之前,他曾任微软中国企业服务部产品营销经理,华侨银行科技部IT产品经理,对企业应用设计及架构有着深刻了解。

原文链接:

https://aws.amazon.com/cn/blogs/big-data/amazon-redshift-spectrum-extends-data-warehousing-out-to-exabytes-no-loading-required/

https://aws.amazon.com/cn/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/

如何使用 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 SAM Local (Beta 版) – 在本地构建和测试无服务器应用程序

今天,我们将发布一款新工具 — SAM Local (Beta 版)。使用这款工具,您可以轻松在本地构建和测试无服务器应用程序。在本文中,我们将使用 SAM Local 快速构建、调试并部署一款应用程序,该应用程序允许我们通过对终端节点运行 curl 命令给 Tabs 或 Spaces 投票。AWS 去年推出了无服务器应用程序模式 (SAM),让开发人员能够更轻松地部署无服务器应用程序。如果您还不熟悉 SAM,请阅读我的同事 Orr 发布的一篇优秀文章,其中详细介绍了如何使用 SAM,读完该文章大约需要 5 分钟。SAM 的核心是基于 AWS CloudFormation 的强大开源规范,它可轻松将您的无服务器基础设施保持为代码并提供可爱的标识。

SAM Local 吸收了 SAM 的全部精华并将它们应用到您的本地计算机中。

有多种安装 SAM Local 的方法,但最简便的方法是通过 NPM。通过运行 npm install -g aws-sam-local 命令可以快速安装,但如果您希望获得最新版本,始终可以直接从来源安装: go get github.com/awslabs/aws-sam-local (这将创建一个名为 aws-sam-local 而非 sam 的二进制文件)。

我想要投票,因此我们来编写一款简单的 SAM 应用程序,将票投给 Spaces 而不是 Tabs。我们将使用非常简单但功能强大的 API Gateway 架构来处理 Lambda 函数,并将结果存储在 DynamoDB 中。最终,用户应能够对 API 运行 curl 命令 curl https://SOMEURL/ -d '{"vote": "spaces"}' 并返回票数。

我们首先来编写一个简单的 SAM template.yaml:

AWSTemplateFormatVersion : '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
  VotesTable:
    Type: "AWS::Serverless::SimpleTable"
  VoteSpacesTabs:
    Type: "AWS::Serverless::Function"
    Properties:
      Runtime: python3.6
      Handler: lambda_function.lambda_handler
      Policies: AmazonDynamoDBFullAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref VotesTable
      Events:
        Vote:
          Type: Api
          Properties:
            Path: /
            Method: post

我们创建一个 [dynamo_i] 表,并通过一个环境变量向我们的 Lambda 函数公开该表,该环境变量名为 TABLE_NAME

为了测试此模板是否有效,我继续调用 sam validate 确保我没有打错字。该命令返回 Valid! ,接下来我们继续处理 Lambda 函数。

import os
import os
import json
import boto3
votes_table = boto3.resource('dynamodb').Table(os.getenv('TABLE_NAME'))

def lambda_handler(event, context):
    print(event)
    if event['httpMethod'] == 'GET':
        resp = votes_table.scan()
        return {'body': json.dumps({item['id']: int(item['votes']) for item in resp['Items']})}
    elif event['httpMethod'] == 'POST':
        try:
            body = json.loads(event['body'])
        except:
            return {'statusCode': 400, 'body': 'malformed json input'}
        if 'vote' not in body:
            return {'statusCode': 400, 'body': 'missing vote in request body'}
        if body['vote'] not in ['spaces', 'tabs']:
            return {'statusCode': 400, 'body': 'vote value must be "spaces" or "tabs"'}

        resp = votes_table.update_item(
            Key={'id': body['vote']},
            UpdateExpression='ADD votes :incr',
            ExpressionAttributeValues={':incr': 1},
            ReturnValues='ALL_NEW'
        )
        return {'body': "{} now has {} votes".format(body['vote'], resp['Attributes']['votes'])}

我们在本地测试一下这个函数。我需要创建一个真实的 DynamoDB 数据库进行演示,并且需要通过环境变量 TABLE_NAME提供该数据库的名称。我可以使用 env.json 文件来执行该操作,也可以直接在命令行中传递它。首先,我可以通过调用
$ echo '{"httpMethod": "POST", "body": "{\"vote\": \"spaces\"}"}' |\
TABLE_NAME="vote-spaces-tabs" sam local invoke "VoteSpacesTabs"

来测试 Lambda 函数,它返回 Spaces 的票数,因此从理论上讲,函数内容全都正确无误。用键盘输入上述全部内容比较费劲,但我可以使用 sam local generate-event api 生成示例事件,并将该事件传递到本地调用。最简单的方式是在本地运行我们的 API。让我们运行: sam local start-api。接下来,我可以对我的本地终端节点运行 curl 命令进行测试。
我将运行命令 $ curl -d '{"vote": "tabs"}' http://127.0.0.1:3000/ ,该命令返回:“tabs now has 12 votes”。当然,第一次尝试编写此函数的效果并不完美。我编辑并保存了几次。热重载的其中一个优点是我可以随意更改函数,而不必执行任何额外的操作来测试新函数。这大大简化了迭代开发。

假设我们不希望通过网络访问真正的 DynamoDB 数据库。我们应该怎么做?我们可以下载 DynamoDB Local,并通过运行如下命令启动它: java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb。然后,我们可以在 Lambda 函数中使用 AWS_SAM_LOCAL 环境变量,以决定其行为方式。我们来稍微修改一下函数:

import os
import json
import boto3
if os.getenv("AWS_SAM_LOCAL"):
    votes_table = boto3.resource(
        'dynamodb',
        endpoint_url="http://docker.for.mac.localhost:8000/"
    ).Table("spaces-tabs-votes")
else:
    votes_table = boto3.resource('dynamodb').Table(os.getenv('TABLE_NAME'))

这样,我们就使用本地终端节点连接到本地数据库,这让在没有 WiFi 的环境下工作变得更轻松。

SAM Local 还支持交互调试!在 Java 和 Node.js 中,我只需传递 -d 标记和一个端口,即可立即启用调试程序。在 Python 中,我可以使用诸如 import epdb; epdb.serve() 之类的库并通过库进行连接。然后,我们可以调用 sam local invoke -d 8080 "VoteSpacesTabs" ,我们的函数将暂停执行,等待您逐步完成调试程序。

好的,我想我们已经准备就绪,现在开始部署吧!

首先,我将调用 sam package 命令 (该命令只是 aws cloudformation package 的别名),然后我将使用该命令的结果来运行 sam deploy命令。

$ sam package --template-file template.yaml --s3-bucket MYAWESOMEBUCKET --output-template-file package.yaml
Uploading to 144e47a4a08f8338faae894afe7563c3  90570 / 90570.0  (100.00%)
Successfully packaged artifacts and wrote output template to file package.yaml.
Execute the following command to deploy the packaged template
aws cloudformation deploy --template-file package.yaml --stack-name 
$ sam deploy --template-file package.yaml --stack-name VoteForSpaces --capabilities CAPABILITY_IAM
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - VoteForSpaces

这将转到我们的 API:

我将跳到生产阶段,并添加一些速率限制,以防你们过度投票,但另一方面,我们已经完成了本地工作并将它部署到云中,而这并不复杂。我非常享受第一次部署就成功的状态!

现在,您可以投票并实时查看结果了!http://spaces-or-tabs.s3-website-us-east-1.amazonaws.com/

我们希望 SAM Local 能够简化无服务器应用的测试、调试和部署。我们提供了 CONTRIBUTING.md 指南,并欢迎你们提交提取请求。请 @ 我们,让我们知道您构建的超酷应用程序。您可以查看我们的新增功能文章以及此处在线提供的文档。

Randall

AWS 纽约峰会 – 公告汇总

多么充实的一周!TaraRandallAna 和我一直忙于为我们在 AWS 纽约峰会上发布的公告撰写博客文章。下面提供的汇总信息可帮助您初步了解这一活动:

Amazon Macie – 这项新服务可以帮助您发现、分类和保护海量的内容。以机器学习和使用自然语言处理 (NLP) 为强大后盾,Macie 可以识别模式并提醒您各种可疑行为,并帮助您完成治理、合规和审计工作。您可以阅读 Tara 的博文,了解如何使用 Macie;您可以选择感兴趣的存储桶,自定义分类设置,并在 Macie 控制面板中查看结果。

AWS GlueRandall 的博文 (带有精美动画 GIF) 向您介绍了这种新的提取、转换和加载 (ETL) 服务。Glue 采用完全托管的无服务器架构;正如您在博文中看到的那样,Glue 可以爬取您的数据,推断模式,并使用 Python 生成 ETL 脚本。您利用各种各样的转换来定义将数据从一个位置移动到另一个位置的作业,每个作业都以代码形式表示,并以人类可读的形式存储。Glue 使用开发终端节点和笔记本,为您提供用于所构建脚本的测试环境。我们还宣布,Amazon Athena 现在已与 Amazon Glue 集成,并且 Apache Spark 和 Hive 在 Amazon EMR 上可用

AWS Migration Hub – 这项新服务可帮助您将应用程序产品组合迁移到 AWS。我的博文简要介绍了主要步骤,并说明了 Migration Hub 如何加速、跟踪和简化您的迁移工作。您可以从发现步骤开始,也可以跳过这些步骤并直接开始迁移。Migration Hub 可与我们的迁移合作伙伴提供的各种工具集成,建立在 Server Migration ServiceDatabase Migration Service 的基础之上。

CloudHSM 最新动态 – 我们对 AWS CloudHSM 进行了重大升级,使更多的用户可以享受到基于硬件的密钥管理的优势。该服务按即用即付的方式提供并完全托管。它是开放的,可与各种标准兼容,支持多种 API、编程语言和加密扩展。CloudHSM 是 AWS 的有机组成部分,可以通过 AWS 管理控制台AWS 命令行接口 (CLI) 和 API 调用来访问。请阅读我的博文了解更多信息,并了解如何设置 CloudHSM 集群。

保护 S3 存储桶的托管规则 – 我们向 AWS Config 添加了两个新规则,可帮助您保护您的 S3 存储桶。使用 s3-bucket-public-write-prohibited 规则可以确定具有公共写入访问权限的存储桶;而使用 s3-bucket-public-read-prohibited 规则可以确定具有全局读取访问权限的存储桶。正如我的博文中介绍的那样,您可以针对配置更改或按计划运行这些规则。这些规则使用了一些前沿的约束求解技术,而这些技术是我们对 AWS 使用自动化形式推理的更庞大计划的一部分。

面向所有客户的 CloudTrail – Tara 的博文介绍了 AWS CloudTrail 现在已对所有 AWS 客户可用,并且默认情况下是启用的。此外,Tara 回顾了 CloudTrail 的主要优点,并向您说明了如何查看事件历史以及深入了解单个事件。她还说明了如何创建另一个跟踪,以便与 CloudWatch 事件配合使用。

适用于 EFS 的静态数据加密 – 当您创建新文件系统时,现在可以选择一个用于加密文件系统上的文件内容的密钥。加密操作使用行业标准的 AES-256 算法进行。我的博文向您说明了如何选择密钥以及验证密钥是否正在使用中。

Jeff