亚马逊AWS官方博客

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

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 业务找出更类似的参考实施。 同行参考在当时对我们来说极其重要,因为没有任何值得称道的伙伴系统迁移资源可以帮助我们利用成熟的云采用模式。 […]

Read More

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

作者:Iris Fu 和 Cambron Carter 这是一篇由工程总监 Cambron Carter 和 GumGum 的计算机视觉科学家 Iris Fu 联合发布的访客文章。用他们自己的话说,“GumGum 是一家在计算机视觉领域具有深厚专业知识的人工智能公司,能帮助客户充分发挥网络、社交媒体及广播电视每天生产的图像和视频的价值。” 目标物检测的最新技术  检测是许多经典计算机视觉问题之一,已随着卷积神经网络 (CNN) 的采用而得到显著改善。随着 CNN 越来越多地用于图像分类,许多人都依靠粗糙和昂贵的预处理程序来生成候选区域 (region proposal)。通过诸如“选择性搜索”之类的算法根据区域的“客体性”(它们包含目标物的可能性) 生成候选区域,这些区域随后被馈送到训练用于分类的 CNN。虽然这种方法能得到准确结果,但需要很高的运行成本。Faster R-CNN,You Only Look Once (YOLO) 和 Single Shot MultiBox Detector (SSD) 等 CNN 架构通过将定位任务嵌入到网络中来折中解决该问题。 除了预测等级和置信度,这些 CNN 还尝试预测包含某些目标物的区域极值。在本文中,这些极值只是矩形的四个角点,通常称为边界框。先前提到的检测架构需要已经用边界框注释的训练数据,即,该图像包含一个人,而且此人在该矩形区域内。以下是分类训练数据和检测训练数据: 超级帅气又非常能干的工程师 我们开始对使用 Apache MXNet 和 Caffe 来训练 SSD 的体验进行比较。明显动机是以分布式方式训练这些新架构,而不降低准确性。有关架构的更多信息,请参阅“SSD: Single Shot MultiBox Detector”。 训练工具  对于这组实验,我们尝试了几款 […]

Read More

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是一个数字词典,它简化了要分发到实例的许可证密钥,密码和其他数据的存储和管理。 […]

Read More

你需要知道的关于高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 […]

Read More

基于S3的图片处理服务

作者:高寅敬 徐榆 1.背景介绍 随着移动互联网的快速发展,各种移动终端设备爆发式的增长,社交类APP 或者电商网站为了提升访问速度、提高用户体验,必须根据客户端的不同性能,不同屏幕尺寸和分辨率提供适当尺寸的图片。这样一来开发者通常需要预先提供非常多种不同分辨率的图片组合,而这往往导致管理难度的提升和成本的增加。 在这篇博客中,我们将探讨一种基于S3的图片处理服务,客户端根据基于HTTP URL API 请求实时生成不同分辨率的图片。 2.解决方案架构 为了保证图片服务的高可用,我们会把所有的图片(包括原图和缩率图)储存于AWS 的对象储存服务S3中,把图片处理程序部署于AWS EC2 中。大部分的图片请求都会直接由AWS S3返回,只有当S3中不存在所需缩率图时才会去请求部署于EC2 上的图片处理服务来生成对应分辨率图片。 业务流程: 用户客户端(通常是浏览器或者APP)发起请求200×200像素的图片 S3中未存在该尺寸缩率图,于是返回HTTP 302 Redirect到客户端 客户端根据 HTTP 302响应,继续请求部署于 EC2 上的图片处理服务 部署于EC2的图片处理服务,会从 S3 获取源图 图片处理服务,根据请求参数生成对应尺寸图片缩率图 图片处理服务将对应的图片返回给客户端 图片处理服务把缩率图存回到S3中,加速下一次客户访问 3.架构特点 相较于预先生成所有所需分辨率图片和传统的基于独立图片处理服务器,这种新的处理方式包含以下优点: 更高的灵活性: 当我们的前端开发人员对界面进行改版时,时常会涉及到修改图片尺寸。对所有原始图片进行缩放的批处理是十分耗时,高成本且易出错的。利用这种基于URL API的实时处理方式,前端开发者指定新的尺寸后,立即就能生成符合客户访问新的网页和应用对应的图片,提高了前端开发人员的开发效率。 更低的储存成本: 对于传统图片处理方式,在未使用之前预先批量生成所需分辨率图片,占用大量的储存空间,而且利用率并不高。 以按需方式生成图片,能减少不必要的储存空间,降低储存成本。 相对于独立图片处理服务器把图片完全储存于EC2的EBS卷,储存于S3 的成本也更低。 我们知道缩率图是属于可再生数据,所以我们在程序上 会把缩率图储存为 S3的去冗余储存类型,再次降低约13% 的存储成本。 更高的服务可用性: 我们可以看到,独立地部署单台图片服务器,无法支持大并发负载。同时存在单点故障 无法保证服务的高可用性,高可扩展性。 而基于S3的解决方案,大量的图片请求,由AWS S3 来完成,S3 会自动扩展性能,因此应用程序的运行速度在数据增加时不会减慢。 只有少量的未生成的图片尺寸才会用到部署于EC2 的图片服务器,并且我们图片逻辑服务器与图片储存S3是解耦合关系,我们还可以针对 […]

Read More

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 Agent和 GitHub 相关项目。 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 […]

Read More

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

Read More

搭建基于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 […]

Read More

用无服务器应用模型部署无服务器应用 (二)使用无服务器应用模型的持续集成

作者:薛峰 上一篇文章中我们介绍了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 […]

Read More

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

作者:薛峰 背景介绍 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: […]

Read More