亚马逊AWS官方博客

结合深度学习网络 (GAN 和 Siamese) 生成逼真的高品质图像

由于深度学习依靠用于训练它的数据的数量和质量,因此公司花费了大量资金来获得良好的图像数据。通常,公司会使用昂贵的人工注释或其他劳动密集型任务,如拍摄大量产品或人员照片。这种方法的成本高昂且不能扩展。训练计算机以生成高品质图像可大大降低成本并推动业务增长。

在这篇文章中,我用简单的术语解释由我的一些 Amazon 同事共同撰写的标题为“从语义上分解生成式对抗网络的潜在空间”的学术论文中介绍的概念。本文介绍了生成式对抗网络 (GAN)、Siamese 网络 (SN) 的实际应用,以便能够从语义上分解 GAN (SD-GAN)。

GAN 和 SN 是相对高级的深度学习符号,您可以单独使用 GAN 和 SN,也可以将其与其他深度学习符号结合使用来解决实际问题。通过将这些符号结合使用,AI 应用程序能够解决更多的难度更大且更复杂的业务问题。例如,面向 AI 的主要难题之一是缺少带注释或标记的数据。高品质的、带注释的数据的成本非常高,因此仅大型公司或资金充足的公司能够获得此类数据。通过使用深度学习方法 (如本文中介绍的那些方法),可让更多的公司从几个示例生成高品质数据。

我将说明作者如何使用 GAN、SN 和 SD-GAN 分析实际图像,并使用它们生成带同一人员或对象的受控变体的“假”图像。根据您设置的参数或“观察属性”,这些假图像可能看起来像是从不同的视角拍摄的、使用了不同的光照或具有更高的分辨率或其他类似变体。通过使用本文中介绍的图像分析方法,您可以创建出非常真实的图像,这些图像看起来像已使用 Photoshop 专门处理过或是使用 3D 模型创建的。

图 1:使用本文中介绍的方法生成的示例。每行均显示同一面部的变体。每列均使用相同的观察属性。

什么是生成式对抗网络?

生成式对抗网络 (GAN) 是适用于神经网络的相对较新的深度学习架构。它们是由蒙特利尔大学的 Ian Goodfellow 与其同事在 2014 年共同开发的。一个 GAN 训练两个不同的网络,二者彼此针对,因此它们具有对抗性。一个网络通过拍摄一个实际图像并尽可能多地修改该图像来生成图像 (或任何其他示例,如文本或语音)。另一个网络尝试预测图像是“假”还是“真”。第一个网络 (称为“G 网络”) 学会生成 更佳的图像。第二个网络 (称为“D 网络”) 学会辨别 真假图像。其辨别能力随时间的推移不断增强。

(more…)

使用 Apache MXNet 和 Apple Core ML 将机器学习引入 iOS 应用程序

作者:Sebastien Menant – Amazon Web Services 的解决方案架构师;Pracheer Gupta – 帕洛阿尔托的 AWS 深度学习团队的成员 / 原文链接

利用 Apple 在 WWDC 2017 上发布的 Core ML,iOS、macOS、watchOS 和 tvOS,开发人员现在可以轻松地将机器学习模型集成到其应用程序中。这使得开发人员只需编写几行代码即可为用户带来智能的新功能。利用 Core ML,移动开发人员能够更方便地使用机器学习。它可让您进行快速原型设计,并使用不同的传感器 (如摄像机、GPS 等) 来创建具有比以往更强大的功能的应用程序。

MXNet 社区的成员 (包括来自 Apple 和 Amazon Web Services (AWS) 的参与者) 已展开合作以生成用于将使用 MXNet 构建的机器学习模型转换为 Core ML 格式的工具。利用此工具,开发人员能够轻松构建面向 Apple 设备的由机器学习支持的应用程序。借助此转换工具,您现在将获得适用于支持深度学习的应用程序的快速管道。您可以从 AWS 云中使用 MXNet 的可扩展的高效分布式模型训练迁移到 Apple 设备上的快速运行时推理。

为了支持该转换工具的发布,我们已决定构建一个出色的 iOS 应用程序。我们从上一篇 AWS AI 博客文章 在 AWS EC2 上使用 MXNet 和 Multimedia Commons 数据集估计图像的位置获得了灵感,这篇文章介绍了用于预测图片拍摄位置的 LocationNet 模型。

在这篇博客文章中,我们说明了如何设置环境以将 MXNet 模型转换为 Core ML,转换现有模型,然后将模型导入用 Swift 编写的示例 iOS 应用程序中。iOS 应用程序向模型提供图片,从而预测图片拍摄位置,然后在交互式地图上显示该位置。出于性能的考虑,我们建议您在安装了 iOS 11 测试版的物理 iOS 设备 (如 iPhone) 上运行该应用程序,但您也可以在 Xcode 9.0 测试版附带的模拟器上试用该应用程序。

请注意,在编写 Xcode 9 时,iOS 11 和 Core ML 仍为测试版,并且您需要 Apple 开发人员计划 账户来下载 Xcode 和 iOS。但是,在今年晚些时候公开发布这些产品后,您便能使用 Mac 上的应用商店和 iOS 设备上的软件更新来获取它们。

MXNet 和该转换工具的安装

已在 macOS High Sierra 10.13 测试版 8 上安装并测试该工具。但是,只要您未在 Mac 上的 Core ML 模型上运行推理,便能在 macOS El Capitan (10.11) 及更高版本上运行该转换器。

要运行该转换工具,您需要安装 Python 2.7。

运行以下命令可安装 MXNet 框架以及 mxnet-to-coreml 工具:

pip install mxnet-to-coreml

MXNet 模型的转换

已在单个 p2.16xlarge Amazon EC2 实例上使用 MXNet 来训练 LocationNet 模型,该实例包含来自 AWS Multimedia Commons 数据集的带有地理标记的图像。它会在 MXNet Model Zoo 上公开分享。

与任何 MXNet 模型一样,LocationNet 包含两个部分:

  • 一个包含模型定义的 JSON 文件
  • 一个包含参数的二进制文件

继续并下载存储在 Amazon S3 上的 .json 模型定义.params 模型参数

此外,您还将需要从 GitHub 存储库下载类文件 grids.txt,该文件包含用于训练模型的地理单元格。已使用 Google 的 S2 Geometry Library 通过训练数据创建该文件。此文本文件中的每一行都采用 S2 单元格标记、纬度和经度的形式 (例如,8644b594 30.2835162512 -97.7271641272)。iOS 应用程序中的 Swift 代码将删除 S2 单元格标记信息,并且仅使用坐标。

按 GitHub 存储库中对该转换工具的描述,我们现在将转换模型。

在将所有内容下载到同一目录中后,请运行此命令:

mxnet_coreml_converter.py --model-prefix='RN101-5k500' --epoch=12 --input-shape='{"data":"3,224,224"}' --mode=classifier --pre-processing-arguments='{"image_input_names":"data"}' --class-labels grids.txt --output-file="RN1015k500.mlmodel"

在内部,该模型首先由在内存中重新创建整个符号图的 MXNet 进行加载。转换器浏览此符号图,并将每个运算符转换为其 Core ML 等效项。提供给转换器的一些参数由 MXNet 用来生成该图,而其他参数由 Core ML 用来预处理输入 (在将输入传递到神经网络之前) 或以特定方式处理神经网络的输出。

您应看到正在处理模型的多个层的转换工具,然后通过所生成文件的名称确认 SUCCESS。在后面的阶段,您将生成的文件 RN1015k500.mlmodel 导入 Xcode 项目中。

(more…)

Apple Core ML 和 Keras 支持现适用于 Apache MXNet

我们对于 Apache MXNet 版本 0.11 的可用性感到很兴奋。利用此版本,MXNet 在社区发展以及酝酿 Apache 项目方面都达到了重要里程碑。参与者 – 包括来自 Apple、Samsung 和 Microsoft 的开发人员 – 向此版本提交了代码。到目前为止,该项目已有 400 多名参与者。该项目现已将其代码库完全迁移至 Apache,并且已使其首个正式版本成为孵化项目。我们在上一篇博客中讨论了此版本的一些重要功能。本博客文章将简要回顾这些重点内容。

使用 MXNet 模型将机器学习构建到适用于 iOS、macOS、watchOS 和 tvOS 的应用程序中

利用 Apple 在 WWDC 2017 上发布的 Core ML 版本,开发人员现在可以轻松地将机器学习模型集成到其应用程序中,这使得他们只需编写几行代码即可为用户带来智能的新功能。我们已开始了解这些功能 (如增强实境) 将如何改变我们体验周围环境的方式。随着快速发展的 AI 空间中的功能的扩展,开发人员将有权访问新的机器学习模型,这些模型能够开启用于增强体验的新功能。

Apple 已将代码提交至 Apache MXNet 项目,以方便应用程序开发人员使用一流的模型。MXNet 现在与 Core ML 结合在一起,使开发人员能够利用 MXNet 在云中构建和训练机器学习模型,然后将这些模型导入 Xcode 中,以便您能够在应用程序中轻松构建智能的新功能。您可以从适用于各种应用程序的预训练模型的 MXNet Model Zoo 中选择,也可以构建您自己的模型。此版本为您提供一种用于将 MXNet 模型转换为 Core ML 格式的工具 (预览版)。要将 MXNet 模型导入 Apple 的 Core ML 格式中,您将需要安装转换器并运行 Python 命令以转换训练的模型。安装转换器只是执行一条简单命令:

pip install mxnet-to-coreml

按照本教程,了解如何构建由机器学习支持的用于确定图片中地点的地理位置的简单 iOS 应用程序。有关说明以及端到端示例,请访问此 GitHub 存储库

(more…)

在云中自动实现合规性的 3 个好处

“建立声誉需要 20 年的时间,而毁掉声誉只需 5 分钟。” — Warren Buffett

在我的技术生涯中,我一直支持遵从性和安全需求。在某些情况下,这些要求是极其苛刻的 - 例如,当我的团队为国防部审核做准备时,花费了几个月的时间,超出了我们时间的 50%。但是,在几乎所有的情况下,我都能够促进使用自动化的解决方案来使我们的生活更轻松,同时提高我们的安全性和遵从性水平。现今,移至云为您提供了明显改善合规性工作的可能性,而不需要在人力和成本上有同样的显著提升。

我来解释一下 –

合规官通常负责评估和管理企业财务、组织和声誉的风险。在企业环境中,这是一项艰巨的任务,因为人员、流程和技术的复杂性,加上跨行业和地理区域的监管差异。

企业和合规性之间也存在着一种天然的紧张关系。企业必须进行产品创新并改善客户体验。另一方面,合规性团队专注于限制或防止风险暴露,这可能与引入新产品和新特性相冲突。这就是合规性团队经常寻求维持现状的原因。底线是企业和合规性之间的自然紧张关系 - 有时运行状况 - 可能会导致关系紧张并经常导致成本增加,以及减慢上市速度。

通常,合规性团队会进行年度合规性评估、撰写报告和设定补救目标。随后,为业务和技术团队提供对任何发现结果进行补救的时间安排。产品经理和技术领导者了解合规性的重要性,但他们通常将评估视为“练习”并且从价值生成中分散注意力。对他们来说,企业领导者担心年度合规性报告的结果,因为他们认为这些“非功能性”要求会将资源重定向到未来几个季度的战略路线图中未包含的事情上。此外,在开发过程中,合规性常常被作为事后的补充。但遗憾的是,经验告诉我们,如果放任不管,合规性问题最终可能会转化为技术债务。

尽管合规性过程通常被认为是繁重的,但结果可以为客户增加有意义的价值。实际上,根据法律和道德的考虑,合规性应该被看作是一种质量的度量,确保了良好的客户体验,特别是在审查包含了安全性、可靠性和响应性的情况下。您的云策略可在这里扮演重要角色 - 方式是转化企业和合规性利益相关者之间的关系,从而改善企业及其客户的结果。更具体地说,通过在产品或服务生命周期的早期包含合规性要求,您可确保您满足政策和法规目标,同时改善您的价值主张。

方法如下 –

首先,迁移到 AWS 是一种直接的节省。在我自己的云之旅中,我发现 AWS 责任共担模式可让我们获益。以前,我们必须管理物理基础设施才能确保法规遵从性。当我们不得不采购硬件以支持技术计划时,这就造成了额外的延迟。它也总是增加我们的运营负担,因为它通常意味着基础设施团队的工作更多,而不需要额外的人员。通过将我们的工作负载迁移到云,我们将维护一个安全的、合规的物理基础设施的责任转移给了 AWS,从而带来了我们永远无法提供的资源和专业知识。换句话说,我们能够提升我们的能力,同时减少我们必须自己保护的表面积。这为我们的运营团队腾出了时间来专注于其他的增值工作,例如,创建其他自动化。

AWS 责任共担模型

其次,将工作负载转移到云可鼓励更大的自动化。可以基于标准化的和经过批准的模板部署环境,然后可以进行版本控制。此概念称为“基础设施即代码”,安全性和合规性的好处是深远的。在将基础设施作为代码进行管理时,可使用脚本自动验证基础设施来确保遵循安全最佳实践。AWS 还支持在 AWS Config 中定义可自动验证的合规性规则。因此,在使用自动化时,合规性团队可在每次系统更改时验证法律和安全需求,而不是依赖于定期的系统审查。此外,合规性和安全性测试自动化可推入软件开发过程中,并有可能在部署到生产环境之前防止策略违规。最后,可以在每日的报告中捕捉到这些发现,并发送到一个将问题分配给某个特定个体的票证系统,甚至可以触发一个自动修复响应。例如,Capital One 已开发出名为云 Custodian 的规则引擎,此引擎用于在其云平台中定义策略并以编程方式强制实施策略。

第三,当自动化过程或手动审查发现问题时,可更轻松地部署补救措施。例如,在基础设施存在漏洞的情况下,基础设施模板可在代码中进行修改并将自动应用于所有未来的实现。如果应用程序中存在此问题,则可通过将修复部署到应用程序,或通过实现补偿控件 (例如,将规则添加到 AWS Web 应用程序防火墙) 来缓解风险。

随着时间的推移,您的云策略可形成一种积极的合规性文化,将合规性和安全性作为增值的以客户为中心的活动。当您的产品团队在产品待办事项列表中将合规性要求作为用户案例包含时,或当开发人员定期向其软件开发过程添加与合规性相关的测试时,您将实现此里程碑。

如果您已在 AWS 中实现合规性过程的自动化,或者您想要了解有关此主题的更多信息,请告诉我。与此同时,这里还有一些其他的资源可能会有所帮助 –

自动在 AWS 上执行管理

如何监控 AWS 账户配置更改和对 Amazon EC2 安全组的 API 调用

AWS 上的 DevSecOps 简介 — Slideshare

期待再次相会,

– Thomas

thoblood@amazon.com
@groberstiefel
http://aws.amazon.com/enterprise/

 

使用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/

使用 AWS EC2 上的 Apache MXNet 和 Multimedia Commons 数据集来估计图像位置

作者:Jaeyoung Choi 和 Kevin Li | 原文链接

这是由国际计算机科学研究院的 Jaeyoung Choi 和加州大学伯克利分校的 Kevin Li 所著的一篇访客文章。本项目演示学术研究人员如何利用我们的 AWS Cloud Credits for Research Program 实现科学突破。

当您拍摄照片时,现代移动设备可以自动向图像分配地理坐标。不过,网络上的大多数图像仍缺少该位置元数据。图像定位是估计图像位置并应用位置标签的过程。根据您的数据集大小以及提出问题的方式,分配的位置标签可以是建筑物或地标名称或实际地理坐标 (纬度、经度)。

在本文中,我们会展示如何使用通过 Apache MXNet 创建的预训练模型对图像进行地理分类。我们使用的数据集包含拍摄于全球各地的数百万张 Flickr 图像。我们还会展示如何将结果制成地图以直观地显示结果。

我们的方法

图像定位方法可以分为两类:图像检索搜索法和分类法。(该博文将对这两个类别中最先进的方法进行比较。)

Weyand 等人近期的作品提出图像定位是一个分类问题。在这种方法中,作者将地球表面细分为数千个地理单元格,并利用带地理标记的图像训练了深层神经网路。有关他们的试验更通俗的描述,请参阅该文章

由于作者没有公开他们的训练数据或训练模型 (即 PlaNet),因此我们决定训练我们自己的图像定位器。我们训练模型的场景灵感来自于 Weyand 等人描述的方法,但是我们对几个设置作了改动。

我们在单个 p2.16xlarge 实例上使用 MXNet 来训练我们的模型 LocationNet,该实例包含来自 AWS Multimedia Commons 数据集的带有地理标记的图像。

我们将训练、验证和测试图像分离,以便同一人上传的图像不会出现在多个集合中。我们使用 Google 的 S2 Geometry Library 通过训练数据创建类。该模型经过 12 个训练周期后收敛,完成 p2.16xlarge 实例训练大约花了 9 天时间。GitHub 上提供了采用 Jupyter Notebook 的完整教程

下表对用于训练和测试 LocationNet 和 PlaNet 的设置进行了比较。

LocationNet PlaNet
数据集来源 Multimedia Commons 从网络抓取的图像
训练集 3390 万 9100 万
验证 180 万 3400 万
S2 单元分区 t1=5000, t2=500
→ 15,527 个单元格
t1=10,000, t2=50
→ 26,263 个单元格
模型 ResNet-101 GoogleNet
优化 使用动量和 LR 计划的 SGD Adagrad
训练时间 采用 16 个 NVIDIA K80 GPU (p2.16xlarge EC2 实例) 时为 9 天
12 个训练周期
采用 200 个 CPU 内核时为两个半月
框架 MXNet DistBelief
测试集 Placing Task 2016 测试集 (150 万张 Flickr 图像) 230 万张有地理标记的 Flickr 图像

在推理时,LocationNet 会输出地理单元格间的概率分布。单元格中概率最高的图像的质心地理坐标会被分配为查询图像的地理坐标。

LocationNet 会在 MXNet Model Zoo 中公开分享。

下载 LocationNet

现在下载 LocationNet 预训练模型。LocationNet 已使用 AWS Multimedia Commons 数据集中带地理标记的图像子集进行了训练。Multimedia Commons 数据集包含 3900 多万张图像和 15000 个地理单元格 (类)。

LocationNet 包括两部分:一个包含模型定义的 JSON 文件和一个包含参数的二进制文件。我们从 S3 加载必要的软件包并下载文件。

import os

import urllib

import mxnet as mx

import logging

import numpy as np

from skimage import io, transform

from collections import namedtuple

from math import radians, sin, cos, sqrt, asin

path = 'https://s3.amazonaws.com/mmcommons-tutorial/models/'

model_path = 'models/'

if not os.path.exists(model_path):

os.mkdir(model_path)

urllib.urlretrieve(path+'RN101-5k500-symbol.json', model_path+'RN101-5k500-symbol.json')

urllib.urlretrieve(path+'RN101-5k500-0012.params', model_path+'RN101-5k500-0012.params')

然后,加载下载的模型。如果您没有可用 GPU,请将 mx.gpu() 替换为 mx.cpu():

# Load the pre-trained model

prefix = "models/RN101-5k500"

load_epoch = 12

sym, arg_params, aux_params = mx.model.load_checkpoint(prefix, load_epoch)

mod = mx.mod.Module(symbol=sym, context=mx.gpu())

mod.bind([('data', (1,3,224,224))], for_training=False)
mod.set_params(arg_params, aux_params, allow_missing=True)

grids.txt 文件包含用于训练模型的地理单元格。

第 i 行是第 i 个类,列分别代表:S2 单元格标记、纬度和经度。我们将标签加载到名为 grids 的列表中。

# Download and load grids file

urllib.urlretrieve('https://raw.githubusercontent.com/multimedia-berkeley/tutorials/master/grids.txt','grids.txt')

# Load labels.

grids = []

with open('grids.txt', 'r') as f:

for line in f:

line = line.strip().split('\t')

lat = float(line[1])

lng = float(line[2])

grids.append((lat, lng))

该模型使用半径公式来测量点 p1 和 p2 之间的大圆弧距离,以千米为单位:

def distance(p1, p2):

R = 6371 # Earth radius in km

lat1, lng1, lat2, lng2 = map(radians, (p1[0], p1[1], p2[0], p2[1]))

dlat = lat2 - lat1

dlng = lng2 - lng1

a = sin(dlat * 0.5) ** 2 + cos(lat1) * cos(lat2) * (sin(dlng * 0.5) ** 2)
return 2 * R * asin(sqrt(a))

在将图像提供给深度学习网络之前,该模型会通过裁剪以及减去均值来预处理图像:

# mean image for preprocessing

mean_rgb = np.array([123.68, 116.779, 103.939])

mean_rgb = mean_rgb.reshape((3, 1, 1))


def PreprocessImage(path, show_img=False):

# load image.

img = io.imread(path)

# We crop image from center to get size 224x224.

short_side = min(img.shape[:2])

yy = int((img.shape[0] - short_side) / 2)

xx = int((img.shape[1] - short_side) / 2)

crop_img = img[yy : yy + short_side, xx : xx + short_side]

resized_img = transform.resize(crop_img, (224,224))

if show_img:

io.imshow(resized_img)

# convert to numpy.ndarray

sample = np.asarray(resized_img) * 256

# swap axes to make image from (224, 224, 3) to (3, 224, 224)

sample = np.swapaxes(sample, 0, 2)

sample = np.swapaxes(sample, 1, 2)

# sub mean

normed_img = sample - mean_rgb

normed_img = normed_img.reshape((1, 3, 224, 224))
return [mx.nd.array(normed_img)]

评估并比较模型

为了进行评估,我们使用两个数据集:IM2GPS 数据集和 Flickr 图像测试数据集,后者用于 MediaEval Placing 2016 基准测试

IM2GPS 测试集结果

以下值表示 IM2GPS 测试集中正确位于与实际位置的每个距离内的图像的百分比。


Flickr 图像结果

由于 PlaNet 中使用的测试集图像尚未公开发布,因此不能直接比较这些结果。这些值表示测试集中正确位于与实际位置的每个距离内的图像的百分比。


通过目测检查定位图像,我们可以看到该模型不仅在地标位置方面表现出色,而且也能准确定位非标志性场景。

使用 URL 估算图像的地理位置

现在我们试着用 URL 对网页上的图像进行定位。

Batch = namedtuple('Batch', ['data'])

def predict(imgurl, prefix='images/'):

download_url(imgurl, prefix)

imgname = imgurl.split('/')[-1]

batch = PreprocessImage(prefix + imgname, True)

#predict and show top 5 results

mod.forward(Batch(batch), is_train=False)

prob = mod.get_outputs()[0].asnumpy()[0]

pred = np.argsort(prob)[::-1]

result = list()

for i in range(5):

pred_loc = grids[int(pred[i])]

res = (i+1, prob[pred[i]], pred_loc)

print('rank=%d, prob=%f, lat=%s, lng=%s' \

% (i+1, prob[pred[i]], pred_loc[0], pred_loc[1]))

result.append(res[2])

return result


def download_url(imgurl, img_directory):

if not os.path.exists(img_directory):

os.mkdir(img_directory)

imgname = imgurl.split('/')[-1]

filepath = os.path.join(img_directory, imgname)

if not os.path.exists(filepath):

filepath, _ = urllib.urlretrieve(imgurl, filepath)

statinfo = os.stat(filepath)

print('Succesfully downloaded', imgname, statinfo.st_size, 'bytes.')
return filepath

来看看我们的模型如何处理东京塔图片。以下代码从 URL 下载图像,并输出模型的位置预测。

#download and predict geo-location of an image of Tokyo Tower

url = 'https://farm5.staticflickr.com/4275/34103081894_f7c9bfa86c_k_d.jpg'
result = predict(url)

结果列出了置信度分数 (概率) 排在前五位的输出以及地理坐标:

rank=1, prob=0.139923, lat=35.6599344486, lng=139.728919109

rank=2, prob=0.095210, lat=35.6546613641, lng=139.745685815

rank=3, prob=0.042224, lat=35.7098435803, lng=139.810458528

rank=4, prob=0.032602, lat=35.6641725688, lng=139.746648114

rank=5, prob=0.023119, lat=35.6901996892, lng=139.692857396

仅通过原始纬度和经度值,很难判断地理位置输出的质量。我们可以通过将输出制成地图来直观地显示结果。

在 Jupyter Notebook 上使用 Google Maps 直观显示结果

为了直观地显示预测结果,我们可以在 Jupyter Notebook 中使用 Google Maps。它让您能够看到预测是否有意义。我们使用一个名为 gmaps 的插件,它允许我们在 Jupyter Notebook 中使用 Google Maps。要安装 gmaps,请按照 gmaps GitHub 页面上的安装说明操作。

使用 gmaps 直观显示结果只需几行代码。请在您的 Notebook 输入以下内容:

import gmaps


gmaps.configure(api_key="") # Fill in with your API key


fig = gmaps.figure()


for i in range(len(result)):

marker = gmaps.marker_layer([result[i]], label=str(i+1))

fig.add_layer(marker)

fig

事实上,排在第一位的定位估算结果就是东京塔所在的位置。

现在,试着对您选择的图像进行定位吧!

鸣谢

在 AWS 上训练 LocationNet 的工作得到了 AWS 研究与教育计划的大力支持。我们还要感谢 AWS 公共数据集计划托管 Multimedia Commons 数据集以供公众使用。我们的工作也得到了劳伦斯·利弗莫尔国家实验室领导的合作 LDRD 的部分支持 (美国能源部合同 DE-AC52-07NA27344)。

 

新增 – 适用于 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 Aurora 数据库快速克隆

作者:Jeff Barr | 原文链接

今天,我想快速展示一下 Amazon Aurora 中我认为非常有用的一项功能:数据库快速克隆。利用 Aurora 的底层分布式存储引擎,您可以快速、经济地创建数据库的写入时复制克隆。

在我的职业生涯中,我经常需要花时间等待一些有代表性的数据样本,以便用于开发、试验或分析。如果我有一个 2TB 的数据库,则在执行任务之前,等待数据副本准备就绪的时间可能长达几个小时。即使在 RDS MySQL 内,我也仍需花几个小时等待快照副本完成,然后才能测试架构迁移或执行某些分析任务。Aurora 以一种非常有趣的方式解决了这个问题。

借助 Aurora 的分布式存储引擎,我们可以完成一些使用传统数据库引擎通常不可行或成本高昂的操作。通过创建指向各个数据页面的指针,存储引擎可实现数据库快速克隆。然后,当您更改源或克隆中的数据时,写入时复制协议会为该页面创建一个新副本并相应地更新指针。这意味着,以前花 1 小时才能完成的 2TB 快照恢复任务现在只需大约 5 分钟即可完成 – 其中大部分时间用于预配置新 RDS 实例。

创建克隆所花的时间与数据库大小无关,因为我们指向同一存储。这样还可让克隆操作变得非常经济实惠,因为我只需为更改的页面 (而非整个副本) 支付存储费用。数据库克隆仍是一个常规的 Aurora 数据库集群,具有所有相同的持久性保证。

接下来,我们克隆一个数据库。首先,选择一个 Aurora (MySQL) 实例,并从“Instance Actions”中选择“create-clone”。

接下来,将克隆命名为 dolly-the-sheep 并对其进行预配置。

大约 5 分 30 秒后,我的克隆已变为可用状态,然后,我开始进行一些大型架构更改,但发现性能未受到任何影响。由于 Aurora 团队做出了一些改进以支持更快的 DDL 操作,因此,与传统 MySQL 相比,架构更改本身的完成速度更快。如果我想让其他团队成员对架构更改执行一些测试,则随后可以创建克隆的克隆,甚至是三次克隆,依次类推,同时我还能继续更改自己的克隆。这里需要注意的是,从 RDS 的角度而言,克隆是第一类数据库。我仍然拥有其他 Aurora 数据库支持的所有功能:快照、备份、监控等。

我希望这项功能可以在基于 Amazon Aurora 试验和开发应用程序方面,为您和您的团队节省大量时间与资金。您可以参阅 Amazon Aurora 用户指南详细了解这项功能,并且我强烈建议您关注 AWS 数据库博客。Anurag Gupta 发布的有关 quorum 和 Amazon Aurora 存储的文章十分有趣。

有后续问题或反馈?请发送电子邮件至 aurora-pm@amazon.com 与我们联系,或在此发表评论。我们很想了解您的想法和建议。

Randall

新增 – 通过 IP 地址在 AWS 和本地资源间实现应用程序负载均衡

作者:Jeff Barr / 原文链接

去年,我介绍了有关新型 AWS 应用程序负载均衡器的信息,并展示了如何针对 EC2 实例以及在容器中运行的微服务,用它进行第 7 层 (应用程序) 路由。

在向 AWS 迁移的这个漫长过程中,有些客户会构建混合应用程序。这些客户告诉我们,他们希望使用单个应用程序负载均衡器,在现有本地资源以及 AWS 云中运行的新资源组合中分配流量。其他客户则希望将流量分配到分散在两个或多个 Virtual Private Cloud (VPC) 中的 Web 或数据库服务器中,在同一实例上托管 IP 地址不同但端口号相同的多项服务,并为不支持服务器名称指示 (SNI) 的客户端提供基于 IP 的虚拟托管支持。还有一些客户则希望在同一实例上 (或许是在容器内) 托管某项服务的多个实例,同时使用多个界面和安全组来实施精细访问控制。

这些情况会出现在各种混合、迁移、灾难恢复和本地使用情形及场景中。

路由到 IP 地址
应用程序负载均衡器现在可以将流量直接路由到 IP 地址,以满足这些使用情形。这些地址可以与 ALB 位于同一 VPC 中、位于同一区域中的对等 VPC 中、位于与 VPC 连接的 EC2 实例上 (通过 ClassicLink),或者位于 VPN 连接或 AWS Direct Connect 连接另一端的本地资源上。

应用程序负载均衡器已将目标分成了目标组。在今天发布的版本中,每个目标组现在都有一个目标类型属性:

instance – 和以前一样,目标通过 EC2 实例 ID 进行注册。

ip – 将目标注册为 IP 地址。您可以对负载均衡器 VPC 内的目标使用来自负载均衡器 VPC CIDR 的任何 IPv4 地址,对负载均衡器 VPC 之外的目标 (包括对等 VPC、EC2-Classic,和可通过 Direct Connect 或 VPN 访问的本地目标) 使用 RFC 1918 范围 (10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16) 或 RFC 6598 范围 (100.64.0.0/10) 内的任何 IPv4 地址。

每个目标组都有负载均衡器和运行状况检查配置,并一如既往地将指标发布到 CloudWatch。

假设您正处于将应用程序迁移到 AWS 的过渡阶段,或者希望使用 AWS 通过 EC2 实例来扩充本地资源,并需要将应用程序流量分配到 AWS 和本地资源中,则可以将所有资源 (AWS 和本地) 注册到同一个目标组并将该目标组与负载均衡器相关联。或者,您也可以使用两个负载均衡器在 AWS 和本地资源中实现基于 DNS 的加权负载均衡,即一个负载均衡器用于 AWS,另一个负载均衡器用于本地资源。如果应用程序 A 的后端位于 VPC 中,而应用程序 B 的后端位于本地,在这种情况下您就可以将每个应用程序的后端放在不同的目标组中,并使用基于内容的路由将流量路由到每个目标组。

创建目标组
接下来,我将介绍如何在创建应用程序负载均衡器的过程中创建目标组,从而将流量发送到一些 IP 地址。输入一个名称 (ip-target-1),并将 ip 选为目标类型:

然后输入 IP 地址目标。此类地址可以来自托管负载均衡器的 VPC:

也可以是上述某个私有范围 (适用于位于托管负载均衡器的 VPC 之外的目标) 内的其他私有 IP 地址:

检查设置并创建负载均衡器之后,只要指定的 IP 地址通过运行状况检查,系统便会向其发送流量。每个负载均衡器最多可以包含 1000 个目标。

我可以随时检查目标组并编辑目标集:

如您所见,在我抓取这个屏幕截图时其中一个目标的运行状况不佳 (这是故意设计的)。每个目标组的指标都会发布到 CloudWatch;我可以在控制台中查看这些指标,还可以创建 CloudWatch 警报:

现已推出
此功能现已在所有 AWS 区域推出,您可以立即开始使用。

Jeff

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

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
企业战略家