亚马逊AWS官方博客

新上线!AWS CodeDeploy自动部署初相识

作为一个开发运维人员,您是否还在为:

1.    如何快速地将新版本应用部署到大批量服务器,无论其是云服务器EC2还是本地服务器?

2.    如何在部署过程中消除停机时间?

3.    如何规避易于出错的手工操作?

4.    在遇到问题时,如何快速回滚?并及时向您发送通知?

今天,我们很高兴地宣布:AWS的CodeDeploy服务能够助您一臂之力!它能够协助您将应用程序部署到 Amazon EC2 实例和/或非 Amazon EC2 实例的物理或虚拟设备。应用程序包扩:代码、Web 和配置文件、可执行文件、程序包、脚本等可部署的内容。AWS CodeDeploy 支持从 Amazon S3 存储桶和 GitHub 存储库部署应用程序。

您无需更改现有代码即可使用 AWS CodeDeploy。您可以使用 AWS CodeDeploy 控制跨 Amazon EC2 实例部署的速度,并定义要在每个阶段采取的操作。

AWS CodeDeploy 具备下列优势:

  • 自动部署。AWS CodeDeploy 可完全自动部署应用程序,并随您的基础设施进行扩展,让您能够部署到数千个实例。
  • 最大程度减少停机时间。AWS CodeDeploy 可以最大程度地提高应用程序的可用性。支持滚动部署和蓝/绿部署模式。并根据您配置的规则跟踪应用程序运行状况。
  • 停止并回滚。出现错误时,您可以自动或手动停止和回滚部署。
  • 易于采用。AWS CodeDeploy 与平台无关,适用于任何应用程序。您可以轻松重用设置代码。AWS CodeDeploy 还能与您的软件发布过程或持续交付工具链集成。

AWS CodeDeploy 支持如下2种部署模式

就地部署:对部署组中的实例依次执行脱机操作/更新应用/恢复联机的操作,完成滚动部署。

蓝绿部署:创建一组新的替换实例,并安装新版本的应用程序。成功后,切换流量到这些新实例,删除旧实例,完成部署。AWS CodeDeploy 运行您在切换流量之前,对新版本应用程序进行测试。如果发现问题,您可以快速回滚到旧版本。

此外,您还可以对蓝绿部署模式做更多控制:

  • 您可以选择是手工创建一组新实例,还是完全复制运行中的自动扩展组?
  • 您可以选择何时切换流量?按照什么比例切换流量?
  • 以及在部署完成后,是否删除旧实例?

下面,我们以一个具体示例来演示如何进行蓝绿部署。

第一步:启动部署向导,搭建测试应用。

步骤1:登录 AWS 管理控制台,选择AWS CodeDeploy 服务

步骤2:如果显示介绍页面,请选择 Get Started Now。如果显示 Applications 页面,请在 More info 中,选择 示例部署向导

步骤3:选择 Sample deployment

步骤4:选择 Blue/green deployment

步骤5: Key pair name 根据您账户中的设置选择,其它选项保持默认设置。

点击 Launch environment

此时,CloudFormation会为您创建一个堆栈 – 一个简单的Web网站:由一个ELB和3台Web服务器组成,并配置了自动扩展组。几分钟后,您将会看到Congratulations! Your environment is ready页面。

Sample application 部分,您可以点击http://BlueGreenLoadBalancer-xxx查看Web网站内容(注意背景色是蓝色)

在Sample blue/green deployment部分,记下新版本应用程序的S3地址 https://s3.cn-north-1.amazonaws.com.cn/aws-codedeploy-cn-north-1/samples/latest/SampleApp2_Linux.zip,后续步骤会用到。

第二步:修改部署模式为“蓝绿部署”

步骤1:在CodeDeploy控制台,选择  Applications -> BlueGreenDemoApplication(刚创建的应用程序) -> BlueGreenDemoFleet-xxx(刚创建的部署组)。在 Actions下拉菜单中,选择“Edit

步骤2:在新页面中,将 Deployment Type 设置为 Blue/green deployment,并点击 Save

注:在该页面中,您还可以设置更灵活的部署方式,是否发送通知,如何回滚等。

第三步:部署一个新版本

步骤1:在前一步返回的页面中,依旧选择之前的部署组 BlueGreenDemoFleet-xxx在 Actions下拉菜单中,选择 Deploy New Version

步骤2:在新页面中,在 Revision location* 中,填入之前记录的新版本应用程序所对应的S3地址:https://s3.cn-north-1.amazonaws.com.cn/aws-codedeploy-cn-north-1/samples/latest/SampleApp2_Linux.zip,并点击 Deploy

第四步:观察部署过程和结果

在接下来的页面中,您将会看到整个部署过程:

在EC2控制台,您会看到创建了3个新实例。

部署完毕后,在页面底部您可以看到新创建的3个实例接替了所有流量,原有的3个实例不再接收流量,并被终止。

您也可以随时在控制台的Applications -> Deployments 点击相应的部署ID查看详情。

使用浏览器重新刷新Web页面,背景色已变成绿色。

至此,蓝绿部署完毕。

测试完毕,为避免产生后续费用,请按照以下顺序清除所有资源:

  1. 替换环境的实例所属的 Auto Scaling 组。(删除 AWS CloudFormation 堆栈时,与原始环境中的实例关联的 Auto Scaling 组也将被删除。)
  2. 示例部署向导 创建的用于为蓝/绿部署提供原始环境的 CloudFormation 堆栈。
  3. 示例部署向导 创建的 AWS CodeDeploy 部署组和应用程序。

除了管理AWS 的EC2实例,AWS CodeDeploy还能够管理您本地数据中心的物理服务器和/或其它环境中的虚拟服务器,只需在其上安装相应的Agent即可实现混合云管理和部署。目前支持的操作系统包括:Amazon Linux/RHEL/Ubuntu/Windows。

如要获取更详细的帮助信息,请参考AWS CodeDeploy中文文档:http://docs.amazonaws.cn/codedeploy/latest/userguide/welcome.html

 

作者介绍:

田明晶

AWS解决方案架构师,拥有18年IT、互联网工作经验,曾在中国联通互联网中心、Sun、Oracle等公司担任售后,售前工程师;2014加入AWS,担任云技术支持工程师,现任职解决方案架构师。在存储、数据库方面有多年经验;对大数据、容器和各种前沿技术(深度学习、AI等)有浓厚的兴趣和技术积累。

CrowdTangle经验谈:如何立足AWS构建SaaS解决方案

马曾经是种极为重要的交通工具。

如果大家打算在150年前提供信使服务,就会意味着使用马匹作为交通工具能够带来远超步行的交付效率。当然,大家也必须雇专人照顾马匹、购买饲料并清理马厩——但这一切在马匹带来的速度优势面前简直不值一提。随着时间的推移,饲养马匹带来的相关技能将使得大家建立起自己的完整业务系统,从而更为高效地处理各类突发事件。

然而接下来汽车出现了,马匹作为交通工具的使命开始逐步被历史所淘汰。

当然,这一过程并非一蹴而就。第一辆行驶在街头的汽车并不会让您立刻破产。而且尽管汽车已经越来越多被主流所接受,大家仍然拥有一定的比较优势,证明并无转投汽车邮递方向的必要。然而,一旦以车辆为主要工具的同类企业开始出现,您的大麻烦将很快由可能变为现实。

在CrowdTangle公司,我们构建起一系列全球领先的工具选项,旨在帮助人们对社交媒体中的信息动态加以追踪。我们拥有一支工程师与才会人员团队,负责引导各大媒体企业、大联盟队伍以及其他用户找到其最关心的实时信息。更重要的是,我们的公司建立于2011年,并在过去五年中一直在使用AWS。我们过去曾经、未来也将坚信AWS能够作为我们建立完整业务的稳固基石。

AWS对我们而言就如汽车一般。

这样的比喻看似夸张,但其实非常客观。立足于AWS,我们得以建立起一套完全不同于以往五年的组织形式。具体来讲,AWS在四大主要方面对我们产生了影响:业务模式、人员聘用、规划以及速度——当然,这一切总结起来都可以归纳为“成本”二字,进而推衍为“生存”。

首先是商业模式。当最初建立这家企业时,我们并没有考虑利用物理介质承载我们的软件,亦没有考虑建立自己的基础设施。相反,我们选择了软件即服务(简称SaaS)这一模式,并借此获得了大量直接性收益:我们能够允许用户单纯通过访问网站的方式试用我们的产品; 我们能够在一天之内发布数十项功能与修复方案; 我们亦能够确保每位用户皆具备同样的受控使用体验。不过更重要的是,要交付业务产品,我们过去必须在起步时即承担沉重的资本支出。但在AWS的帮助下,我们无需此类初始成本即可让SaaS成为一种可行的发展选择,并在业务增长的同时不断扩大规模。

其次是人员招聘。AWS提供Amazon关系数据库服务(简称Amazon RDS),这是一项托管数据库服务,意味着我们不再需要雇用数据库管理员即可将该服务直接交付开发者使用(且使用英特尔至强E5处理器,代表性能质量亦可得到保证)。另外,AWS还拥有Elastic Beanstalk,这项服务允许我们更为轻松地在AWS之上部署自有应用程序,从而为前端及后端服务器设置独立环境并以一键式操作对其分别加以扩展。再有,AWS的托管NoSQL数据库服务Amazon DynamoDB使得我们不再需要四名全职工程师专门负责数据库的连接与运转。我们拥有TB级别的实时数据,可在个位数毫秒之内完成响应,而且在我个人看来该服务完全能够实现自我维护。在此基础之上,我的团队能够专注于考量如何推动业务发展,而不再需要为保持系统正常运作而分神。

第三项为规划。如果大家仍然生活在以马匹作为主要交通工具的时代,那么资源采购模式无疑是根据自身能力尽可能多地进行设备买入,直到您清楚地发现当前资本支出已经超过企业的承受能力。另外,大家需要研究各类新型设备、联系供应商、投入大量资金、等待设备发货、进行现场安装,并在其性能无法满足需求时尝试转售以收回一点成本。但在汽车时代下,如果我认为企业需要更多设备资源,则可在很短时间之内申请一项实例,并按小时为这一立即可用的资源支付成本。在相关任务完成之后,我可以关闭该实例并不再承担任何后续成本。更重要的是,实例本身的具体规模并不重要——我们完全可以根据需求申请与之匹配的资源容量。

最后,我想聊聊速度这个话题。由于我们选择在AWS之上建立自己的解决方案,因此我们得以拥有一支敏捷、能够快速交付资源并主要关注项目本身而非被迫思考系统维护工作的团队。我们不仅能够在业务范围内的项目进行快速转换,同时亦可以低成本方式实现探索性思路的实验性实施。每个新项目既可能中途失败,亦可能成为我们的下一款百万美元级产品——且二者在初始阶段完全相同,包括建立设想、克隆现有环境、建立项目分支、以实验性方式向客户交付并在获得好评后全面推向市场。

我们最近发现系统聚合部分的处理速度比预期更慢,因此我们开始尝试将其转移至Amazon Redshift。为了实现这一目标,我们首先申请了一个小型Redshift实例(注:未进行规划),并在完成初步测试之后将整体生产数据库复制到Redshift当中(注:研发速度)。“生产”性实验证明这一举措确实能够带来可观收益,因此我们为自己的系统建立起一整套辅助Amazon Kinesis-Redshift托管通道(注:尽管新增系统,但未招聘任何额外人员),而此举最终让我们获得了此前根本无法想象的新产品研发能力。那么这一切在传统模式下需要耗费多少成本?需要采取怎样的执行方式?项目中的各项因素能否拥有受控规模以保证不致造成巨大损失?我们总是从小笔投入着手,而正是这一点让我们能够保持所在业务领域的领导地位。

毫无疑问,未来的竞争对手必然同样借助汽车作为业务基础——在这样的历史背景下,单凭马匹如何在对抗中取胜?

欲了解更多关于CrowdTangle公司的信息,请点击此处参阅我们的官方网站。

Amazon EBS弹性卷修改实践

简介

在应用飞速的更新换代、数据量高速增长的今天,AWS的客户对EC2的块存储需求是随时间而改变的,很可能会多次需求增加容量或改变性能特性。在当今的24×7(全天候不间断)操作模式下,服务器没有停机的余地。因此,客户希望在应用不离线或不影响正常操作的情况下进行更改。换句话说,我们的客户希望他们的EBS卷更有弹性!

在2017年2月13日,AWS全球推出了一个新的EBS功能,称为弹性卷(Elastic Volumes),并使其适用于当前所有EC2实例可生成的EBS卷。在2017年2月17日,AWS中国区可以使用这项新功能。通过这一项功能,可以在EBS卷正在使用时增加卷的大小,调整性能或更改卷类型,并能在这些更改生效之前继续使用应用程序等运行在EC2实例上的程序功能。这一新功能的更新将大大简化企业或个人用户的许多规划管理,可以通过简单的API调用来及时更改存储基础架构,取代传统的需要几周或几个月的配置周期。

使用场景

1. 卷类型更改。在项目初期,为了更快部署应用,您初步设置块存储使用通用SSD卷(General Purpose SSD volumes),在获得一些使用经验后,发现吞吐量优化卷(Throughput Optimized volumes)是更好的选择,这时您只需要更改卷的类型就能够轻松解决问题。

2. IOPS性能调整。假设您在IOPS卷中运行一个关系型数据库,并设置它处理正常范围内的数据读写,由于每个月最后几天数据读写突增到正常水平的10倍,您只需要通过弹性卷短时间内获取更强大的读写配置来处理每月最高的数据读写,然后回调至正常配置来处理正常范围内的数据读写。

3. 卷存储增加。您获取了一个卷使用警告,提示您当前使用存储空间超过90%,这时您可以增加卷的大小,并扩展文件系统来匹配,弹性卷将以完全自动化的方式处理请求而不用停止EC2实例。

适用范围

AWS全部区域,包括海外和中国北京区域。

修改限制

所有卷大小的修改只能增加卷的大小!为了保护所有EBS卷中的数据,弹性卷修改仅允许增加卷的大小。如果您想将当前卷大小改小,可以先通过数据迁移工具将EBS卷中的数据移动到较小的卷,再将原来的卷删除。

1. 通用SSD卷:卷大小最小为1GiB,最大为16384GiB(16TiB);IOPS性能无法修改,最小为100,最大为10000,在最大最小值范围内为卷大小的3倍(卷大小单位为GiB),IOPS超频可达到3000。

2. 预配置IOPS SSD (io1):卷大小最小为4GiB,最大为16384GiB;IOPS性能可以修改,最小为100,最大为20000,在最大最小值范围内最大可调整至卷大小的50倍(卷大小单位为GiB)。

3. Cold HDD (sc1):卷大小最小为500GiB,最大为16384GiB;Cold HDD (sc1) 卷提供低成本的磁性存储,该存储以吞吐量而不是 IOPS 定义性能。此处无法做任何更改。

4. 吞吐量优化卷:卷大小最小为500GiB,最大为16384GiB;吞吐量优化卷提供低成本的磁性存储,该存储以吞吐量而不是IOPS定义性能。

5. 旧版磁介质卷:无法修改。磁介质是上一代卷。对于新应用程序,我们建议使用较新的卷类型。

数据截至至2017年2月17日,具体数据以AWS实时数据为准。更多有关EBS卷的相关信息,请查阅Amazon EBS卷类型

操作指南

您能通过AWS管理控制台、API调用或从AWS命令行界面(CLI)管理使用所有功能。下面将介绍AWS管理控制台对弹性卷修改的操作指南,获取更多API调用及命令行界面的操作方式,请访问AWS文档

修改本身不收取任何费用,您只需按实际使用量付费。更多定价信息,请访问EBS定价

一、引导卷(根分区)修改

登陆AWS中国区,并选择服务EC2,打开EC2面板后,鼠标左击点选左侧导航栏的“卷”。

打开卷面板后,选择您要调整的卷,点选“操作”打开下拉菜单,在下拉菜单中点选“Modify Volume”。

然后可以对卷类型、大小和预配置的IOPS(如果适用的话)进行任何符合需求的更改,修改检查完后,点击Modify按钮。

注意卷大小不能减小

注意预配置IOPS SSD卷的IOPS值不能大于卷大小的50倍(卷大小单位GiB)

在修改确认页面点击“Yes”按钮。

卷修改正在进行,请稍等一会儿。

卷修改完成。

卷修改验证。

二、未绑定到EC2实例卷修改

三、已绑定到EC2实例卷(未建立文件系统使用)修改

四、已绑定EC2到实例卷(建立文件系统并正在使用)修改

应用卷修改前。

应用卷修改后。

注意,卷的大小修改后,下一步是扩展文件系统,以便可以利用额外的存储空间。要了解如何执行此操作,请阅读在Linux上扩展EBS卷的存储空间或在Windows上扩展EBS卷的存储空间

注意事项

1.   在某些情况下,卷需要与EC2实例分离或停止实例才能进行修改。如果您在尝试对EBS卷应用修改时遇到错误消息,或者如果要修改附加到上一代实例类型的EBS卷,请执行以下步骤之一:

  • 对于非引导卷,先将卷从实例中分离,再应用修改,最后重新附加卷。
  • 对于引导卷,先停止实例,再应用修改,最后重新启动实例。

2.   弹性卷修改方法不支持上一代磁性卷。但是,您可以通过拍摄快照,并将快照还原到其他配置的EBS卷。

3.   不支持减小EBS卷的大小。但是,您可以通过创建较小的卷,利用应用程序级工具(如robocopy)进行数据转移。

4.   修改卷后,您需要等待至少六个小时,才能再对同一卷进一步更改,建议修改属性的时候,类型,IOPS,大小参数一次性完整设定。

5.   许多Linux AMI如今使用MBR方案,它只支持最多2047GiB的引导卷。如果您的实例未使用2TiB或更大的引导卷进行引导,则引导卷的大小被限制为2047GiB。

6.   在2016年11月1日之前附加到当前生成实例的卷需要执行以下操作之一,来初始化修改支持(这是一次性要求):

  • 停止并重新启动实例(重启前请一定备份卷数据!)。
  • 分离并重新附加卷。

7.   m3.medium实例被视为当前一代。m3.large,m3.xlarge和m3.2xl实例被视为上一代。更多有关上一代实例的内容,请参考实例类型

引导卷(根分区)操作实践:


卷修改前检查:

1.  确保最近一次卷修改在6小时之前。

2.  确认卷类型,如果为上一代磁性卷,您无法修改卷的类型及大小。您可以先将磁性卷中的数据拍摄快照并迁移至其余四种卷类型,再做更改。

3.  确认实例类型,如果为上一代实例,请先分离卷(非引导卷)或停止实例(引导卷)后再进行卷修改。

4.  确认实例上一次停止时间,如果在2016年11月1日之前,请先分离卷(非引导卷)或停止实例(引导卷)后再进行卷修改。

5.  一次性完整设定需要修改的卷类型,IOPS,大小参数,并等待卷修改完成。

参考

Amazon EBS Update–New Elastic Volumes Change Everything

作者介绍:

王元恺

AWS实习解决方案架构师,上海交通大学学生,有数年C++程序开发以及一年PHP前后端开发经验,同时致力于AWS云服务在国内的应用和推广。熟悉网站架设与网络应用开发,对于TCP/IP及网络协议有自己的理解和实践经验。

 

利用Mycat中间件实现RDS MySQL的分库分表及读写分离功能

随着移动互联网的兴起和大数据的蓬勃发展,系统的数据量正呈几何倍数增长,系统的压力也越来越大,这时最容易出现的问题就是服务器繁忙,我们可以通过增加服务器及改造系统来缓解压力,然后采用负载均衡、动静分离、缓存系统来提高系统的吞吐量。然而,当数据量的增长达到一定程度的时候,增加应用服务器并不能明显地提高系统的效率,因为所有压力都会传导到数据库层面,而大多数系统都是用一个数据库来存储和管理系统数据的,因而一个支持高性能、高并发并且易于扩展的数据库系统变的尤为重要。

Amazon RDS是AWS上托管的关系型数据库服务,目前支持业界主流的MySQL、Oracle、SQL Server、PostgreSQL、MariaDB引擎及AWS提供的Aurora,通过多可用区主备及读副本等技术,能够支持绝大部分的应用场景。

对于更大容量的数据库,可以使用Amazon Aurora,Aurora是一个关系型数据库引擎,结合了高端商用数据库的速度和可用性,同时还具有开源数据库的简单性和成本效益。Amazon Aurora 的设计与 MySQL 5.6 及PostgreSQL 9.6.1兼容,它提供的性能比同一硬件上运行的标准 MySQL 最多高达五倍,比PostgreSQL最多高达二倍。

下表是单个数据库实例能够支持的存储容量大小:

RDS数据库引擎 存储容量
MySQL 6TB
Oracle 6TB
PostgreSQL 6TB
MariaDB 6TB
SQL Server 4TB
Aurora 64TB

不过由于Aurora目前并未在所有region提供,比如中国北京,同时支持的引擎有限,对于中国区用户及使用其他数据库引擎的用户,不得不考虑其他的解决方案。随着近年来海量数据存储、并行计算、异构数据互联等一系列新技术在市场上不断出现。相信数据库行业的很多从业者都对传统关系型数据库的单点故障及容量问题头疼不已,而数据库分库分表也早已成为解决此类问题的基础。

本文要介绍的Mycat是一款面向企业级应用的开源数据库中间件产品,支持事务、ACID,能够对接Oracle、MySQL、DB2、SQL Server、MongoDB、SequoiaDB等数据库,支持透明的读写分离机制,支持各种MySQL集群,包括标准的主从异步集群、MySQL Galera Cluster多主同步集群等,通过大表水平分片方式支持100亿级大表的分布式存储和秒级的并行查询能力,内建数据库集群故障切换机制,实现自动切换,可满足大部分应用的高可用性要求。

配置步骤:

第一步 创建RDS数据库实例

创建一个RDS将会使用的参数组mycat

在分库分表的情况下,Mycat可以通过如下几种方式保证自增主键的全局唯 一:

1. 本地文件方式

在sequence_conf.properties文件中设置主键的当前值,最小值和最大值

2. 数据库方式

在其中一个 MySQL 节点中建立一张表,存放 sequence 的名称,当前值,步长 等信息,并通过存储过程修改更新信息
3. 本地时间戳方式

4. 注解方式

本例使用第二种方式,为了使存储过程能够顺利执行,需要修改参数组的log_bin_trust_function_creators为1

此外,可以按需设置时区及大小写不敏感

接着创建两台 RDS MySQL 实例,注意需要在创建的时候选择 mycat 参数组

本例使用 MySQL 5.6.34 版本,开启 Multi-AZ 及自动备份功能,并且为每个 MySQL RDS实例创建一个读副本做读写分离

数据库 endpoint 如下:

mysql1

mysql1.cbqbpwftrsrj.rds.cn-north-1.amazonaws.com.cn

mysql1-read-replica

mysql1-read-replica.cbqbpwftrsrj.rds.cn-north-1.amazonaws.com.cn

mysql2

mysql2.cbqbpwftrsrj.rds.cn-north-1.amazonaws.com.cn

mysql2-read-replica

mysql2-read-replica.cbqbpwftrsrj.rds.cn-north-1.amazonaws.com.cn

第二步 安装配置 Mycat

本例使用 Cento 6.7 创建 EC2

1. 安装epel及mysql源

rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm -ivh https://repo.mysql.com//mysql57-community-release-el6-9.noarch.rpm

2. 修改/etc/yum.repos.d/mysql-community.repo如下

3. 安装相关软件包

yum update -y
yum install mysql-server java-1.8.0-openjdk.x86_64 vim wget -y

4. 下载并安装Mycat

wget http://dl.mycat.io/1.6-RELEASE/Mycat-server-1.6-RELEASE-20161028204710-linux.tar.gz
tar xzvf Mycat-server-1.6-RELEASE-20161028204710-linux.tar.gz

5. 配置Mycat中间件

5.1 vim mycat/conf/server.xml
该配置文件主要用于创建 mycat 用户及 mycat 的系统参数设置,这里只列出保证mycat正常工作的参数配置,其中还有很多优化项需要读者根据需要自行修改,具体可以参考文末的参考书及链接

其中 sequenceHandlerType 为1表示使用数据库方式实现自增主键

5.2 vim mycat/conf/schema.xml

该配置文件主要用于配置逻辑库、表、分配规则、分配节点及数据源,同样这里的配置并不包括参数优化在内

上面配置有几个地方需要注意

1. 分片dn1和dn2分别对应于mysql1中的db1和mysql2中的db2,需要事先登入这两台 RDS 实例,并分别创建 db1 和 db2 数据库

2. user表会在两台RDS实例中分片,基于id字段,使用mod-long算法进行分片

3. orders 表作为 user 表的子表,使用 ER 关系表进行分片,是 Mycat 中避免跨库join 的其中一种方式,适用于有父子关系的两张表,这里 orders 表中的user_id 字段对应于 user 表中的 id 字段,当需要对 orders 表进行插入操作的时候,Mycat 会对 user_id 应用父表的 mod-long 算法找到具体的分片并插入,这样 order 表和user 表基于user.id=orders.user_id 的 join 操作可以在每个分片中进行,无需跨库

4. country表的type为global,设置为全局表,也就是在每个RDS实例中均有完整的 country 表信息,是 Mycat 中另外一种避免跨库 join 的方法,适用于内容较为固定,数据量不大的字典表

5. dataHost标签中的balance为3,实现读请求完全到readHost上进行

6. dataHost标签中的switchType为-1,意思是当writeHost故障的时候不进行切换,这是针对 RDS 特有的配置,由于 RDS 已经启用了 Multi-AZ 的功能,主库故障会自动切换到 standby 实例,无需 Mycat 切换到某台readHost

7. user,password为具体RDS实例的登入用户账号

8. user表和orders表设置了autoIncrement=true主键自增

9. mycat_sequence表用于存储其他表的自增主键信息

5.3 vim mycat/conf/rule.xml

该配置文件主要用于定义分片算法,由于本例使用两台 RDS实例,需要将 mod-long 分片算法的 data nodes 参数设成 2

5.4 vim mycat/conf/sequence_db_conf.properties

该配置文件用于设置主键自增表的自增信息,这里将 user 表和 orders 表的自增信息存到 dn1,也就是 RDS mysql1 中,注意这里的 USER,ORDERS 需要大写

5.5 启动 Mycat,并建表

./mycat/bin/mycat start &
mysql –h 127.0.0.1 –u root –p –P 8066

show databases 可以看到定义的逻辑库 test

下面是具体的建表语句

下面设置 user 表及 orders 表的自增主键的当前值为0,自增步长为1

5.6 配置实现主键自增的存储过程
存储过程需要在具体的 RDS 实例上创建,在这里是 RDS mysql1
mysql –h mysql1.cbqbpwftrsrj.rds.cn-north-1.amazonaws.com.cn -u root –p

第三步 功能验证

1. 登入Mycat

mysql –h 127.0.0.1 –u root –p –P 8066 use test;

2. 验证主键自增

3. 验证user表在两台RDS实例中分片

4. 验证country表为全局表,并且能够和user表做join

在两台 RDS 实例上可以看到 country 表的全部内容

5. 验证 orders 表的分片规则关联父表 user 表,即 orders 表中的 user_id 与 user 表中 id字段相等的行存储在同一个 RDS 实例中,并且两张表能够 join

在两台 RDS 上查看到 user 表与 orders 表的存储关系

6. 验证使用ShareJoin实现分片join

如上两种方式本质上是通过全局表或者相同的分片规则规避分片 join,SQL语句经过 Mycat 分发到各个 RDS 节点本地 join,然后在Mycat 中进行结果的汇聚,如果两张表都比较大,不适合作为全局表并且表与表之间没有类似的父子关系时,有两种方式解决

1. 增加冗余列,即人为在两张表中构建相同的两列,比如上例的 user.id 和orders.user_id,然后基于这两列来分片

2. 通过ShareJoin注解,ShareJoin本质上是将一条join语句拆分成单表的SQL语句,然后把各个节点的数据汇集
登入 RDS mysql1,对 orders 表人为插入一条 user_id 为奇数的信息,使得 orders 表的分片规则与 user 表的出现

此时再使用 join 语句将会丢失刚刚插入的那一行,因为 RDS mysql1 在本地执行 join 语句时,本地 user 表中并没有 user.id=1 的条目

通过在 SQL 语句前加上 ShareJoin 的注解,实现跨分片 join 功能

笔者在实际使用过程中发现,ShareJoin 并不是总能够正常工作,怀疑可能是 bug 或者语句限制,不到万不得已,建议使用上面的两种方式来规避跨库 join,比如上面的语句如果只是取出某几列,ShareJoin 并不总能正确输出

另外还有一种 Mycat 支持的跨分片join技术是 catlet,也叫做人工智能(HBT), 主要是参考了数据库中的存储过程的实现方式,需要用户根据系统提供的 API 接口在代码中实现跨分片 join,具体可以参考文末的参考书中的内容

7. 验证读写分离

修改 RDS 参数组 mycat,开启 general log

注意:开启 general log 会影响数据库的性能并占用存储空间,不建议在常规时间开启,这里只是用于验证
登入 Mycat,执行如下语句,可以看到在15:42:09-15:42:29的时间段内,一共执行了两次对 country 表的全表扫描,一次 user 表的全表扫描,和三次 user 表的单行查询,需要验证的结果如下:

1. 由于country表是全局表,只会在一台实例上执行,所以两台read-replica中一共可以看到两条语句

2. user表是分片表,所以全表扫描会在每台read-replica中看到一条语句

3. user表的单行扫描会按照Mycat的分片规则分配到相应的read-replica中执行

4. 所有语句不会出现在mysql1和mysql2写库的日志中

分别登入 mysql1,mysql2,mysql1-read-replica,mysql2-readreplica 执行 select * from mysql.general_log,查看 15:42:09-15:42:29 时间段内的日志

mysql1,mysql2 中没有执行的语句日志
mysql1-read-replica 中,可以看到两条 country 的全表扫描,一条 user 的全表扫描和user 表 id 为 2 的查询语句,其中全表扫描的 limit 100 为 Mycat 自动添 加,可以通过配置修改

mysql2-read-replica 中,可以看到一条 user 的全表扫描和 user 表 id 为 1,3 的查询语句,其中全表扫描的 limit 100 为 Mycat 自动添加,可以通过配置修改

第四步 配置 Mycat 的冗余

1. 设置Mycat开机自启动

vim /etc/rc.local,添加如下启动指令

sh /home/centos/mycat/bin/mycat start

2. 根据需要设置iptables防火墙策略

3. 创建 AMI,通过 AWS autoscaling-group,实现 Mycat 冗余及高可用,应用层对两台MyCat的负载均衡可以在应用层实现或者使用负载均衡器,由于这部分配置比较基础,此处不做详细介绍

最终拓扑图如下:

第五步 使用 Mycat-web 实现监控(可选)

Mycat-web为 Mycat 提供了一个基于 Web 的监控平台,功能非常丰富,可以对 Mycat实例,Mycat 所在机器的 JVM 以及具体的 MySQL 节点进行监控

1. 安装启动Mycat-web

本例使用一台独立的 EC2 安装,使用 Centos 6.7,配置 internet 可以访问

Mycat-web 依赖 zookeeper,需要先安装 zookeeper
wget http://mirror.bit.edu.cn/apache/zookeeper/stable/zookeeper- 3.4.9.tar.gz
cd zookeeper-3.4.9/conf
mv zoo_sample.cfg zoo.cfg
cd ../bin
./zkServer.sh start &
安装 Mycat-web
wget http://dl.mycat.io/mycat-web-1.0/Mycat-web-1.0-SNAPSHOT- 20170102153329-linux.tar.gz
cd ~/mycat-web/WEB-INF/classes
vim mycat.properties
zookeeper=localhost:2181(默认已经修改)
cd ~/mycat-web
./start.sh &

2. 配置Mycat-web

通过浏览器访问 mycat-web

添加 Mycat 节点

添加 JVM 节点

添加 MySQL 节点

接下来就可以通过 Mycat-web 查看系统的各项参数

目前有一个问题,Mycat-web 只能够收集到 read 的操作,所有 insert/delete/update 等写操作无法收集

通过 Mycat 服务端口 8066 登入一台 Mycat,执行一系列 select 及 insert 读写操作,退出后通过管理端口 9066 登入,查看日志发现所有 insert 写操作并未记录到日志中,因此可以确定不是 Mycat-web 的问题,而是可能由于 Mycat 本身配置不当或者由于 bug 导致写操作没有记录到日志中,已经在 github 上提交 issue,等待答复中

参考内容:

《分布式数据库架构及企业实践:基于Mycat中间件》

Mycat 自增主键配置:

http://deweing.github.io/2016/06/29/mycat-auto-increment.html

https://my.oschina.net/bodi666/blog/797277

作者介绍:

余骏

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

使用AWS控制台或命令行将AWS IAM角色附加到现有的Amazon EC2实例中

简介

AWS IAM(身份和访问管理服务)中的角色使您的应用程序在Amazon EC2上能够使用临时的安全凭证自动实现AWS服务的创建,发布和内容修改。使用这样的临时凭证是IAM的最佳做法,因为您不再需要在实例上维护一个或多个长期密钥。对EC2使用IAM角色也无需再使用必须手动或以编程方式管理的长期AWS访问密钥。

例如,应用程序必须通过AWS证书签署API请求。因此,如果您是应用程序开发人员,您需要一个策略来为EC2实例上运行的应用程序管理证书。您可以安全地将您的AWS证书分配至实例,从而允许这些实例上运行的应用程序使用您的证书签署请求,并保护其免受其他用户的影响。但是,要将凭证安全地分配至每项实例有一定难度,尤其是AWS以您的名义创建的实例,例如竞价型实例或Auto Scaling组中的实例。当您更换AWS证书时,您还必须能够更新每项实例上的证书。IAM角色能够委托授权以发出API请求,而不用创建并分配您的AWS证书。详细解决方案,请查阅文档适用于Amazon EC2的IAM角色

之前,IAM角色只能在实例创建设置时添加,这导致了过去创建的实例和忘记添加IAM角色的实例无法使用IAM角色操作实例,从而被迫重新部署实例及应用程序。从现在开始,您可以通过将IAM角色附加到现有的尚未被角色附加的EC2实例,来使用AWS提供的临时安全证书操作EC2实例,您还可以随时替换附加到现有EC2实例的IAM角色。

适用范围

文中的操作步骤已于2017年2月23日验证通过,其中AWS CLI版本1.11.48,在AWS全球和AWS中国区均能正常使用。

解决方案

1.   创建IAM角色

2.   将IAM角色附加给现有EC2实例(最初没有IAM角色附加)

3.   更换附加到Amazon EC2的IAM角色

4.   移除附加到Amazon EC2的IAM角色

本文假设您具有创建IAM角色的权限,并具有调用EC2 API的权限。

AWS命令行操作步骤中所有出现的占位符{Some Words},都应该替换为实际资源名称。

AWS控制台操作步骤

1.  打开EC2控制面板,并选择左侧边栏的“实例”。

2.  选择您的实例,依次点击上方的操作->实例设置->Attach/Replace IAM role

3.  打开IAM role下拉菜单,选择您想要附加给当前EC2的IAM角色,No Role代表不附加角色,选好后点击右侧的Apply按钮。选择并应用的过程实际上包含了:将IAM角色附加给现有EC2实例(最初没有IAM角色附加);更换附加到Amazon EC2的IAM角色;移除附加到Amazon EC2的IAM角色。

4.  如果您选择了No Rule(即移除EC2上的IAM角色),会显示如下页面:

5.  如果您未作出有效的修改,会显示如下页面:

6.  如果您的修改有效,会显示如下页面:

AWS命令行操作步骤

开始操作之前,请确保您的CLI版本大于等于1.11.48。如果您对当前自己的CLI版本有疑问,可以在命令行中执行以下命令进行版本查询:

$aws --version

如果您已经有 pip 和支持的 Python 版本,则可以使用以下命令安装 AWS CLI:

# pip install --upgrade --user awscli

一、创建IAM角色

在从AWS CLI创建IAM角色之前,必须先创建角色信任策略。信任策略允许AWS服务(如EC2)代表您的应用程序承担IAM角色。

要创建信任策略,请复制以下策略,并将其粘贴到使用名称{YourNewRole}-Trust-Policy.json保存的文本文件中,注意后缀名为.json:

♦AWS中国区

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Principal": {

"Service": "ec2.amazonaws.com.cn"

},

"Action": "sts:AssumeRole"

}

]

}

♦AWS全球

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Principal": {

"Service": "ec2.amazonaws.com"

},

"Action": "sts:AssumeRole"

}

]

}

 

现在您已成功创建信任策略,接下来创建IAM角色{YourNewRole}:

1.  基于信任策略创建IAM角色{ourNewRole},打开命令行并执行以下命令:

$aws iam create-role --role-name {YourNewRole} --assume-role–policy-document file://{FilePath}/{YourNewRole}-Trust-Policy.json

注意:  file:// 不能省略,策略路径可以是当前相对路径也可以是全路径。

例如:

相对路径: file://TestRole-Trust-Policy.json

全路径:

Windows:file://C:/test/TestRole-Trust-Policy.json

Linux: file:///data/test/TestRole-Trust-Policy.json

2.  给予此IAM角色访问帐户中资源的权限。在本示例中,我假设您的应用程序需要只读访问您帐户中的所有Amazon S3存储桶和存储桶中的对象。因此,您将使用AmazonS3ReadOnlyAccess AWS托管策略。有关AWS托管策略的详细信息,请参阅使用托管策略。在命令行中执行以下命令:

$aws iam attach-role-policy --role-name {YourNewRole} --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

3.  创建IAM实例配置文件{YourNewRole-Instance-Profile}。实例配置文件允许EC2将IAM角色{YourNewRole}传递给EC2实例。要了解更多信息,请参阅使用实例配置文件。在命令行中执行以下命令:

  $aws iam create-instance-profile --instance-profile-name {YourNewRole-Instance-Profile}

  $aws iam add-role-to-instance-profile --role-name {YourNewRole} --instance-profile-name {YourNewRole-Instance-Profile}

至此,您已成功创建IAM角色{YourNewRole}。

 

二、将IAM角色附加给现有EC2实例(最初没有IAM角色附加)

您现在可以将IAM角色{YourNewRole}附加到EC2实例{YourInstanceId}:

1.  获取现有EC2实例详细信息(记录InstanceId)。在命令行中执行以下命令:

$aws ec2 describe-instances

2.  将新创建的IAM角色{YourNewRole}的实例配置文件{YourNewRole-Instance-Profile} 附加到您的EC2实例{YourInstanceId}。在命令行中执行以下命令:

$aws ec2 associate-iam-instance-profile --instance-id {YourInstanceId} --iam-instance-profile Name={YourNewRole-Instance-Profile}

3.  验证IAM角色是否已附加到实例。在命令行中执行以下命令:

$aws ec2 describe-iam-instance-profile-associations

4.  打开AWS EC2控制台,查看实例的描述信息:

5.  进入EC2实例内,查看实例IAM角色具体信息:

$curl http://169.254.169.254/latest/meta-data/iam/security-credentials/{YourNewRole}

至此,您可以使用IAM角色访问AWS资源来更新应用程序,并把实例中的长期密钥删除。

三、更换附加到Amazon EC2的IAM角色

如果角色的使用需求发生改变,并且您希望通过修改IAM角色来授予EC2实例权限,则可以更换换附加到EC2的IAM角色。但是,这也将修改使用此IAM角色的其他EC2实例的权限。

可以采用调用replace-iam-instance-profile-association调用替换IAM角色命令, 将当前附加的IAM角色{YourNewRole}更换为另一个IAM角色{YourReplacementRole}(例如:EC2role2),而不终止您的EC2实例:

步骤:

1.  创建新的IAM实例配置文件{YourReplacementRole-Instance-Profile}指向新的IAM角色{YourReplacementRole},例如EC2Role。创建命令参考上节内容。

2.  获取现有EC2实例IAM附加信息(记录AssociationId)。在命令行中执行以下命令:

$aws ec2 describe-iam-instance-profile-associations

使用过滤条件和控制查询输出内容,获取指定EC2实例的

$aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-79dxxxx --query

    'IamInstanceProfileAssociations[*].{InstanceId:InstanceId,AssociationId:AssociationId}' --output table

3.  更换IAM角色。在命令行中执行以下命令:

$aws ec2 replace-iam-instance-profile-association --association-id {YourCurrentAssociationId}

    --iam-instance-profile Name={YourReplacementRole-Instance-Profile}

4.  根据AssociationId的值看出,IAM角色的更改已生效。打开AWS EC2控制台,查看实例的描述信息:

四、移除附加到Amazon EC2的IAM角色

在实际使用过程中,您的EC2可能不再需要通过角色使用AWS资源。这时候您可以选择移除附加在EC2上的IAM角色。

可以采用调用disassociate-iam-instance-profile调用移除IAM角色命令:

步骤:

1.  获取现有EC2实例IAM附加信息(记录AssociationId)。获取IAM信息命令参考上一节所述

2.  移除IAM角色。在命令行中执行以下命令:

$aws ec2 disassociate-iam-instance-profile --association-id {YourCurrentAssociationId }

3.  根据第二次查询现有EC2实例IAM附加信息为空可以看出,当前实例的IAM角色已被移除。

而在上述所有操作的过程中,均未影响EC2的运行状态。

总结:

做为安全最佳实践,让我们现在就行动起来,将所有需要使用AWS资源的Amazon EC2上添加对应的角色。

参考

[1]New! Attach an AWS IAM Role to an Existing Amazon EC2 Instance by Using the AWS CLI

[2]AWS命令行参考手册

[3]Demo脚本下载

 

作者介绍:

王元恺

AWS实习解决方案架构师,上海交通大学学生,有数年C++程序开发以及一年PHP前后端开发经验,同时致力于AWS云服务在国内的应用和推广。熟悉网站架设与网络应用开发,对于TCP/IP及网络协议有自己的理解和实践经验。

陈琳涛

AWS解决方案架构师。拥有超过15年的IT行业以及软件开发领域的工作经验。2000年投身互联网大潮,创办过自己的公司。长期从事网络相关研发和管理工作,热爱DevOps实践。随后,投身游戏行业,参与多个项目的研发,运维,上线工作。致力于使用云计算来帮助更多的创业者迈向成功。

巧用Amazon EMR节省数据分析成本

Amazon EMR是云上的数据分析平台,通过Amazon EMR的图形化或命令行接口,用户可以快速搭建和部署基于Amazon EC2实例的数据分析系统,并能动态扩展集群。Amazon EMR也可以读写其他AWS数据存储服务,例如Amazon S3和Amazon DynamoDB。

最新版本的Amazon EMR涵盖的服务包括:Hadoop、Zeppelin、Tez、Ganglia、HBase、Pig、Hive、Presto、ZooKeeper、Sqoop、Mahout、Hue、Phoenix、Oozie、Spark、Flink、Hcatalog。利用以上Amazon EMR包含的众多服务,用户能够实现日志文件分析、流式数据分析、机器学习、工作流管理等任务。本文就用户最常用的日志文件分析任务,巧用Amazon EMR以节省数据分析成本。

三个关键点

第一,使用Amazon S3存储待分析数据。使用Amazon S3存储数据主要有以下几方面优势。

  • 节约成本:相比使用HDFS集群,Amazon S3是单纯的存储服务,用户在存储数据文件的时候,只需要为使用的存储容量付费,无需为服务器及硬盘付费,而用机器搭建HDFS集群,这部分投入是必须的。
  • 数据持久性高:旨在提供99.999999999%的数据持久性,最大化地降低了数据丢失的可能。
  • 计算和存储分离:使用Amazon S3存储数据,实际上是实现了计算和存储的分离,这一点很关键,它使得Amazon EMR集群能够随时扩容、缩容、删除,降低了数据丢失的可能。
  • 无需修改程序代码:与HDFS存储相比,用户并不需要修改程序的代码。以Hive建表语句为例,只需要将Location的位置改为Amazon S3的目录即可,即LOCATION‘s3://sampledata/userrecord/’

第二,定时运行Amazon EMR集群。

日志文件分析这种批量数据处理的任务,并不是每时每刻都需要运行任务,可以每天定时运行Amazon EMR集群进行分析,分析完成后再将集群删除。与用户自己搭建数据分析集群相比,Amazon EMR让集群的创建非常容易,只需要一条命令即可搭建所需集群,这也让随时删除、随时创建集群具备可行性,如果没有Amazon EMR,相信用户不会将自己辛苦搭建起来的集群随便地删除。

定时运行集群与云计算的按需计费模式相结合,带来的最大优势就是节省成本。如果某个任务只需要1个小时就能得出分析结果,那么,与全天候运行的集群相比,定时运行的集群所节约的成本是非常可观的。

第三,利用外部存储。

  • 元数据:本文所提供的方案中使用的是Hive表结构数据,将其存储在外部的数据库中是因为Amazon EMR集群是定时运行的,因此,其元数据不要存储在本地,否则Amazon EMR集群关闭后,元数据也将被删除。
  • 计算结果:Amazon EMR定时运行产生的结果需要存储在外部,如Amazon S3中,或者存储在数据库中。

系统的架构

图1为一个典型架构,这里主要使用了Amazon EMR中的Hive、Presto及Sqoop服务,并利用Amazon RDS MySQL存储Hive元数据和查询结果数据。

在此架构中,Hive用来创建表,并维护表结构元数据,这些元数据被存储在Amazon RDS MySQL中。Presto用来执行查询,Presto利用Hive已经定义的表结构。Sqoop用来将Presto产生的结果数据转存到Amazon RDS的MySQL中。

以上这些步骤需要按照顺序在Amazon EMR每次启动的时候执行,实现这个顺序执行的功能,需要用到Amazon EMR的Step。在每一个Step中,用户可以自定义需要运行的任务,例如以上提到的Hive任务、Presto查询、数据转存等都可以放在Step中运行。

用户可以创建Amazon EMR集群,以及Amazon EMR集群创建成功后需要执行的Step,在一条AWS命令中事先写好,例如下面是一条简化过的命令,它创建了一个名为Loganaly的Amazon EMR集群,包含了Hive、Presto和Sqoop服务。Auto-terminate参数说明这个集群中所有的Step执行完成后,集群自动被删除。Configuration参数的内容指定了存储Hive元数据的数据库信息,例如IP、用户名等。Steps参数定义了所需要执行的任务。而在Instance-groups中定义了集群中机器的数量和配置。

aws--region cn-north-1 emr create-cluster --name "loganaly" --release-label emr-5.0.0 \

--applications Name=Hive Name=Presto Name=Sqoop \

--auto-terminate \

--configurations s://bucketname/cfgfile \

--steps \

Type=Hive,Name="HiveStep",Args=[……] \

Type=CUSTOM_JAR,Name="Presto2s3",Jar=$CODEDIR/script-runner.jar,Args=[……] \

Type=CUSTOM_JAR,Name="s3tomysql",Jar=$CODEDIR/script-runner.jar,Args=[……] \

--instance-groups \

Name=Master,InstanceGroupType=MASTER,InstanceType=m3.xlarge,InstanceCount=1 \

Name=Core,InstanceGroupType=CORE,InstanceType=r3.xlarge,InstanceCount=2 \

Name=Task,InstanceGroupType=TASK,InstanceType=r3.xlarge,InstanceCount=3

最后,用户需要让这个命令定时执行,那么,可以把这个命令放在/bin/bash脚本中,然后利用Linux crontab实现定期执行。或者利用Windows的定时任务实现定期执行。如果是在国外AWS区域,还可以利用竞价实例进一步节省成本。方法也很简单,仅需在Instance-group的参数中增加竞价的美元数即可。

--instance-groups \

Name=Master,InstanceGroupType=MASTER,InstanceType=m3.xlarge,BidPrice=0.2, InstanceCount=1 \

Name=Core,InstanceGroupType=CORE,InstanceType=r3.xlarge, BidPrice=0.2,InstanceCount=2 \

Name=Task,InstanceGroupType=TASK,InstanceType=r3.xlarge, BidPrice=0.2,InstanceCount=3

使用国外AWS区域的某个客户利用该方法分析每天产生的CDN日志,采用竞价实例的情况下,每天用于数据分析的投入不足1美元。

本文介绍的内容使用了Hive和Presto,实际上Amazon EMR中的Spark、Tez等服务都可以实现类似的功能,同样可以利用Amazon EMR的灵活创建和删除,以及使用Amazon S3作为存储的特性。

表1中列出了这些主要用到的数据分析型服务现在的特征,供读者参考选用。需要注意的是,随着社区产品的升级,这些特征并不是一成不变的,需要用户关注这些产品的变化,做出正确的选择。

针对本文中描述的方案,以下blog中有更详细的操作方法和代码,感兴趣的用户可参考:

https://aws.amazon.com/cn/blogs/china/amazon-emr/

作者介绍

韩小勇,AWS解决方案架构师,负责基于AWS的云计算方案架构咨询和设计,实施和推广,在加入AWS之前,从事电信核心网系统上云的方案设计及标准化推广。

利用Amazon Redshift构建新一代数据分析BI系统

本文主要介绍了Amazon Redshift新一代企业级云平台数据仓库服务,并结合实际的客户使用案例与场景描述了如何基于Amazon Redshift构建高可靠,性能优化,并且成本节约的数据仓库系统。因为Amazon Redshift优异的计算效率与性能,基于Amazon Redshift的BI系统被广泛地应用于互联网数据分析类场景,例如电商中产品维度报表的计算生成,社交类应用中用户画像计算与分析,或者用于替代传统的数据仓库的解决方案。

Amazon Redshift是性能优异并且完全托管的PB级别数据仓库服务。Amazon Redshift提供了标准SQL数据库访问接口,并且可以十分方便地与现有的主流商业智能数据分析工具整合,构建企业级数据仓库。

Amazon Redshift高性能硬件架构

Amazon Redshift底层硬件是基于高度定制化的高性能硬件节点,整个集群是由头节点(leader node,又称领导节点)与计算节点(compute node)的架构组成,如图1所示。其中,头节点负责与所有的客户端程序(标准SQL兼容的客户端,或者通过JDBC/ODBC访问的客户端应用)进行通信,并把对应的SQL命令进行编译后分发给底层的计算节点。同时,头节点还负责存储所有的数据仓库元数据(metadata)。需要注意的是,所有的计算节点同时也是存储节点(单个节点最大支持2TB的存储量)。每个计算节点上配置有定制化的高性能CPU、内存及直接连接硬盘的存储介质。当用户数据仓库的数据量增加的时候,可以通过动态地增加计算节点的数目,以及升级对应计算节点的硬件配置提升集群的存储容量与计算能力。同时,节点与节点的通信是基于AWS定制化的高速内网带宽,减少了因为数据传输带来的时延,提高了计算效率。

图1 Amazon Redshift架构示意图

目前,Amazon Redshift主要支持两大类计算节点类型——DS1/DS2与DC1。其中DS类型节点是为大数据量的工作复杂优化而设计,而且DS2是DS1的硬件升级版本。DC1主要应用于数据计算要求相对更高但是数据总量相对较小的场景。

从应用的角度结合上述架构看,Amazon Redshift的头节点负责基本的SQL编译,查询计划的优化,以及数据仓库原数据的存储。所有的用户数据会以列式存储的方式存放与计算节点之上。因为大部分数据仓库的应用计算围绕于具体的属性列做查询筛选,所以列式存储的计算方式大大提高了数据仓库的计算效率。同时,以MPP的架构组织数据为例,Amazon Redshift也从表设计的角度为用户提供了数据在计算节点的存放方式,用户可以根据具体的SQL表中的键值做分布式存放,或者对某些常用维度表做所有计算节点的全分布存放,从而大大减少数据在节点之间的传输,以提高整体的计算效率。从图1还可以看到,计算节点以MPP的方式并行的从Amazon S3、Amazon DynamoDB、SSH及Amazon EMR并发的实现数据快速加载。另外,Amazon Redshift的整体设计实现了数据的多份冗余存放(对用户使用量透明)——计算节点之间冗余存放,同时定期对数据以增量快照的方式存放于高持久度的Amazon S3之上。

基于Amazon Redshift的BI大数据分析架构

Amazon Redshift针对数据仓库提供了优异的计算与存储效率,利用Amazon Redshift托管服务可以十分方便地构建智能数据仓库系统。同时,因为AWS云计算平台提供了一整套完整的数据分析套件与工具,利用这些组件与Amazon Redshift相结合,可以十分轻松地实现性能优化、成本经济、可靠性强、安全度高的大数据分析架构。图2为一个典型的数据分析平台的基础数据架构。

图2 基于AWS数据分析组件的数据架构

图2中的架构是基于AWS的典型的实时与批量叠加的大数据分析架构。其中Amazon Kinesis是托管的高速实时流分析服务,可以从前端的应用服务器(例如Web服务器)或者移动的客户端(手机等移动设备或者IoT设备)直接注入流式数据,数据可以通过EMR进行流式处理和计算(例如基于Spark Stream的EMR计算框架),并将数据存储于Amazon DynamoDB或者对象存储S3之上。其中,Amazon DynamoDB是托管的高性能NoSQL数据库,可以承载100TB数据量级别而响应时间低于10毫秒。S3作为高可靠(11个9的持久度)的对象存储,在大量的AWS应用场景中,被作为典型的数据湖(data lake)的应用。利用Amazon EMR对S3上的原始数据进行基本的ETL或者结构化操作之后,可以直接从S3以SQL的“copy”命令复制到Amazon Redshift数据仓库中进行SQL的维度计算。另外,可以利用AWS集成的BI分析工具(Quick Sight)或者已有的商业套件直接实现对Amazon Redshift上的数据进行分析与展示。

在实际的业务场景中,数据库的来源包含Amazon DynamoDB或者Amazon RDS这类业务数据库,以及用户活动日志或者行为日志等Web前端日志。这些数据需要以增量的方式汇聚于AWS S3及ETL之后进入到Amazon Redshift之中。常用的做法,可以利用AWS的Data Pipeline服务直接定义对应的原端数据源及对应的后端数据目标,自定义采集周期,一次性配置之后就可以直接进行数据通路的增量拷贝。

小红书电商基于Amazon Redshift的用户数据分析

小红书是新一代的社区电商,它将海外购物分享社区与跨境电商相结合,精准捕捉85后和90后的消费升级需求,迅速发展成为极具影响力的全球购物分享社区。目前小红书的注册用户数量已超过1800万,其中近90%是女性、超过50%是90后。作为新一代消费人群,这些用户有着共同的价值观,更注重感觉和体验,对优质商品和生活充满向往。“社区+电商”的模式推动了小红书的快速发展,在电商平台成立的半年内,其销售额就达到7亿人民币。

与小红书自身高速发展的业务模式一样,小红书的数据架构与数据分析团队也经历了从基本日志服务器脚本分析到目前利用Amazon Redshift作为数据仓库与数据分析核心工具的演化。图3是目前小红书数据分析的主要架构。

图3 小红书数据架构示意图

NoSQL DB(主要是MongoDB)小红书的业务数据库数据,其中的数据库业务日志通过Fluentd的流式客户端经过Amazon Kinesis的方式进入到AWS中国北京区域。之后,Amazon Kinesis的流式数据会写入S3作为整个原始数据存储。当然,Amazon S3还会作为数据湖汇聚其他的前段web服务器的日志,或者其他的数据来源。其中,构建于AmazonEMR的Spark集群对S3中的日志进行批量和实时的ETL。之后,结构化的数据从S3通过并行的拷贝直接进入Amazon Redshift进行数据分析师与工程师的业务分析。整个数据分析链条与分析架构实现了端到端的实时分析。其中,数据通路上的各个组件,Amazon Kinesis、Amazon S3、Amazon EMR与Amazon Redshift可以十分简单与方便地实现水平扩展以提高计算与处理能力。因为S3作为整个数据架构的数据湖,并且基于S3自身分布式无限制的容量大小的设计,小红书的架构系统可以十分方便的实现数据容量的夸张和升级。同时,因为EMR利用EMRFS实现了存储S3(类似于传统的Hadoop集群的HDFS)与计算(EMR计算实例)的分离,从而从架构上解决了数据系统ETL弹性与增长的需求。小红书又利用Amazon Kinesis来实时地解析同步用户行为日志,并开发了销售实时监控系统。使用AWS使小红书在两个方面获益匪浅:其一是大幅度缩短了数据处理系统上线的时间;其二是改变了整个公司的业务模式。目前,小红书数据团队正在持续优化其数据处理架构,包括提供更直观的展示平台、提升处理速度等,同时包括Spark在内的离线计算系统也开始投入使用。目前,业务数据的增量以每个月3~5TB的存量增加,并且随着业务增加还有快速递增的趋势。

小红书的实际使用经验也已经被更多的电商用户及数据分析团队所采用。

综上所述,Amazon Redshift作为一款AWS数据仓库的明星产品,因为其优异的计算性能(10亿条记录TPC-H测试个位数秒级别)被越来越多的用户熟悉和使用,并且结合Amazon天然的高可扩展的云平台被广泛地应用于各个行业应用和数据分析中。

作者介绍

肖凌,AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内和全球的应用和推广,在大规模并发后台架构、跨境电商应用、社交媒体分享 、Hadoop大数据架构以及数据仓库等方面有着广泛的设计和实践经验。在加入AWS之前曾长期从事移动端嵌入式系统开发,IBM服务器开发工程师。并负责IBM亚太地区企业级高端存储产品支持团队,对基于企业存储应用的高可用存储架构和方案有深入的研究。

Capital One 与Alexa – 看美国银行业如何玩转人工智能

随着深度学习和语义分析技术的飞速发展,基于声音的人工智能受到不同行业、不同市场越来越多的青睐。就像触屏技术颠覆了整个个人移动设备行业一样,我们相信语音技术将会是未来的颠覆者之一。在这个领域已经有很多先驱的产品问世,而其中扮演主要角色之一的就是来自亚马逊的智能音箱Echo。

什么是Alexa?

我们先简单介绍一下Echo及其背后人工智能Alexa的故事。Echo是一个可以与用户对话的智能音箱,他帮助客户完成各种信息查询(诸如天气,行车路线规划等),执行各种日常任务(如闹钟,音乐等),还能帮助客户在亚马逊电商网站搜索并购买商品。其实Echo本身并不具备复杂的学习分析能力,它的智能部分是通过互联网连接到其云端的Alexa服务完成的。也就是说如果Echo是手,Alexa就是她云端的大脑。Echo的成功正是来自于Alexa。作为云端的人工智能,Alexa的Skill Kits被亚马逊开放出来供全球更多的智能设备制造商使用,这不仅帮助这些厂商更容易地完成他们自己的智能产品,更是打造了一个庞大的基于Alexa的生态圈。很多厂商将自己研发的新的Alexa Skills Kits开源共享,使得Alexa这个超级大脑在各行各业都有着越来越多的智能功能。而刚刚过去的AWS 2016 Re:Invent大会上,Alexa也被正式打造成AWS云计算的一个服务 – LEX提供给广大客户。

Capital One 与Alexa

如果在其他行业看到Alexa广泛应用,大家可能并不新奇。但如果说在传统谨慎的银行业看到Alexa依然能大展身手,不得不说是一个惊喜。下边我们来介绍一下全美最大的银行之一Capital One如何玩转Alexa从而给客户带来全新的银行体验。

Capital One 于2015年的Re:Invent大会公布了与AWS的合作。用他们CIO Rob Alexandar 的话来说:“金融行业吸引了全世界最难对付的的网络黑客。通过与AWS的深度合作,我们意识到在云中的运维要远比我们在自己本地的数据中心安全”。可见AWS的安全性对银行业来讲并不是一个技术问题,而更多的是一种思维模式的转换和对云常态的接纳。

在探索Alexa的应用上,去年Capital One已经提出了业务设计的原型,而今年他们真正完成了Capital One 基于Alexa的智能语音银行助手。从互联网应用的角度来讲,如果说网上银行或者手机银行是银行与客户的传统互动模式,那么现在智能语音银行将开启一个全新的客户互动体验。具体来说,Capital One基于Alexa开发并实现了如下功能(第一阶段):

  • 信用卡账单支付
  • 信用卡余额查询
  • 储蓄账户余额查询
  • 列出近期消费记录
  • 查询信用卡可用额度
  • 查询信用卡账单到期日
  • 账户信息概况/总览

不难看出,目前基于智能语音的服务主要是信息查询类服务,只有第一条是交易类的信用卡支付。究其原因,一方面信息查询类服务在Alexa的应用上本就是一个经典场景;另一方面从安全的角度来说,在最糟糕的情况下,如果别人窃取了你的Alexa语音助手账号,他所能做的唯一交易也仅是替你付清信用卡账单。当然,关于安全这点,我们后边会详细分析,接着我们要说说Capital One设计这个智能语音银行助手的一些心路历程:

首先,与其他大型企业或集团的慢决策风格相似,在谨慎的银行业接受并使用智能语音银行对Capital One来说无疑是一个大胆的尝试。除了组建专门的项目组之外,Capital One 采用了Conference Driven Development的模式,通过内部不同团队间的数次会议讨论,大力促成并推荐基于Alexa的项目。

其次,Capital One也调研了其广泛的客户群体,搜集客户的声音和反馈。根据调查结果,客户对可以解放双手的智能语音银行很感兴趣,并且除了查询信息,他们甚至接受转账交易类的服务;但客户同时也提出了对软硬件安全的担心,并且不希望自己的金融信息保存在提供智能语音服务的第三方那里(比如亚马逊)。同时,Capital One将调研中客户感兴趣的主要服务功能分成了两类,一是任务类,一是状态查询类(比如,总的来说我的金融资产状况是否健康?)。这方便后期的进一步功能开发。

第三,从语义分析的角度,Capital One 基于客户的各种需求,总结了一些需要注意的地方。例如,注意结合语境回答问题,避免对余额偏低的客户用玩笑的口吻回复(因为他们可能真的不富有)。再比如,避免问客户一些可以联网查询到的常识问题,避免用生硬晦涩的专业金融或法律法规词汇回答客户问题,尽量使回复简单易懂口语化。另外,相比于机械的回答,Capital One赋予了丰富的个人性格给智能语音银行助手,使其与客户的互动更人性化,甚至有时附带幽默感。最后,结合客户的谈话深度和广度,Capital One综合了客户常用的各种表述方式开发了新的Alexa Skills Kit,努力使智能语音银行助手既能对客户提出的、意图明显的问题进行快速回答,又能在一些模糊的、泛泛的话题上不失语境地与客户互动。比如针对近期信用卡的消费记录,Capital One总结了来自不同客户的150多种询问方式,并将其植入Alexa Skills Kit,使得智能语音银行助手在不同语境下都能更好的理解客户的问题。

第四,在安全的方面,Capital One 尽量平衡了安全与便捷之间的取舍。如果纯粹的追求安全,在客户使用智能语音银行之前,需要预先连接账号,手动登录mobile app 授权,回答安全问题,验证码等等。但这种需要额外手动操作的设计违背了智能语音银行的初衷 – 那就是无手操作的便捷性,也就是客户体验大打折扣。所以在权衡了客户体验与安全性之后,Capital One采用了下边几点作为其Alexa语音银行助手的安全管理原则:1)开发了软件OAuth用来对客户使用的第三方智能硬件授权,使得任何客户的语音信息不会在第三方保存。在这个案例下,Capital One对亚马逊的智能音箱Echo做了授权。2)一个可选的语音登录密码:对安全敏感的客户可以打开这个选项,读出其语音密码以登录。对安全不是那么敏感的客户可以关闭这个选项,直接登录智能语音银行助手。3)无需任何手动操作,无需登录mobile app。通过这几点措施,Capital One既满足了客户无手操作的便捷性,又保证了客户信息的足够安全。

最后,在研发方面Capital One也给出了他们总结的几点建议。比如,区分客户首次登录和后续登录时的对话方式,许多首次登录的问题和客户已回答的一些偏好应自动记录,在后续登录时避免重复提问。再如,建立反馈学习的机制,当客户告知语音助手他的回答不正确时,后台的应该有相应的程序捕捉并总结这些回答错误的问题,以便将来更好的完善改进智能语音助手。最后,通过借助beta 客户群和A/B 测试更好的收集早期反馈 。

时至今日,据悉Capital One智能语音银行助手项目的第二阶段也即将启动,会有更多的功能加入到Alexa智能语音银行助手中,比如敏感信息掩盖,信用卡激活,锁卡或解锁,信用卡使用周报等等。

总结

以上是Capital One 在Alexa智能语音技术上的一个成功实践,也是美国金融行业基于云计算和人工智能技术实现快速创新的一个缩影。它真实反映了金融服务贴近生活、服务大众的场景金融理念,与国内的普惠金融政策不谋而合。随着利率市场化和利息收入的不断下滑,国内的银行业相继发力低净值客户群,推动对私业务,通过互联网开拓更多的新服务以寻求业务增长。在云计算已经成为新常态的全球大环境下,在越来越多的云服务百花齐放助力企业快速创新的趋势前,金融改革浪潮下的银行家们,你们准备好了么?

作者介绍:

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

AWS文件存储网关初体验

1.    背景介绍

AWS Storage Gateway 是一项可以帮助用户实现在混合架构环境中将本地数据中心内设施与AWS云端存储进行无缝集成的服务。通过Storage Gateway可以简化本地IT环境与云端存储间移动数据,将数据存储到AWS云,并且实现备份,存档以及灾难恢复等主要功能。

Storage Gateway家族之前已经包含有基于卷接口以及磁带接口类型的网关设备,帮助用户可以在适当的场景下选择合适的方式去将本地的数据迁移到云端,在去年Las Vegas 举办的re:Invent大会上,AWS更进一步又推出基于文件接口(支持NFS3和NFS4.1)类型的存储网关,给用户提供了更多的选择,方便用户可以通过标准的文件协议将文件作为对象直接存储在Amazon S3上,这样不但可以借助于S3超高的持久性优势对文件进行持久化保存,还可以将S3对象的版本控制,生命周期管理以及跨区域复制等存储策略直接应用到存储对象中。

要使用文件存储网关服务,必须为存储网关下载虚拟机镜像,并从 AWS 管理控制台或存储网关 API 激活它。写入到 NFS 的文件成为 Amazon S3 中的对象, 文件与对象之间存在一对一的映射,对象使用 Amazon S3 托管的加密密钥 (SSE-S3) 在服务器端加密,所有数据传输通过 HTTPS 执行。

文件存储网关服务使用分段并行上传等技术,优化了网关与 AWS 之间的数据传输,以更好利用可用带宽。与缓存卷类似,系统维护本地缓存以提供对最近访问数据的低延迟访问,并减少数据传出成本。

新年伊始,让我们撸起袖子,一起来体验一下新型的存储网关带来的超能力,尝试如果使用文件存储网关这项新的功能来实现对本地文件的云端迁移。

2.    部署与配置存储网关

文件存储网关适用于将数据传入到 S3 以供应用日常使用、备份和存档到 AWS 云上不同类型的存储服务。

图1

在进入具体的安装部署环节之前,我们首先来了解一下使用文件存储网关中涉及到的主要调用流程。用户的应用服务器运行在自有数据中心内,在用户环境中部署文件存储网关(File Gateway),用户或应用服务器通过NFS客户端连接存储网关,利用网关,可以将 S3 中的存储桶作为 NFS 装载点,从而对文件进行写入和访问。

2.1  安装部署文件存储网关

首先登录到AWS Storage Gateway Console

https://console.amazonaws.cn/storagegateway/home?region=cn-north-1

2.1.1 选择网关类型

在导航窗格中,选择 Gateways,然后选择 Create gateway;

在 Select gateway type 页面上,选择 File gateway,然后选择 Next;

图2

2.1.2 选择主机平台

现阶段文件存储网关只支持本地运行在VMware ESXi虚拟化环境中,选择 Download image,下载安装包,解压后得到.ova类型文件;

图3

1)通过VMware vCenter控制台将Storage Gateway虚拟机部署到用户本地的虚拟化环境中。此处省略部署Storage Gateway虚拟机过程,详细步骤请参考:

http://docs.aws.amazon.com/zh_cn/storagegateway/latest/userguide/deploy-gateway-vmware.html

注意: 必须满足最低的主机配置要求;

选择Thick provisioned format磁盘类型;

确保存储网关主机上的时钟与网络时间协议 (NTP) 服务器同步。

2)添加存储网关本地磁盘存储

存储网关至少需要添加一个磁盘以便进行缓存,客户端对文件的访问会首先在缓存中去获取文件信息,这样将大大减少通过网络去S3直接获取文件的延迟,文件存储网关缓存最大值为16TB。

 建议:将用于缓冲区的磁盘专门使用一个数据存储。

2.1.3 连接网关

登录到VMware vCenter管理界面,点击网关虚拟机,在Summary页面中记录下网关IP地址信息

切换到AWS控制台界面,输入文件存储网关IP,选择 Connect to gateway

图4

2.1.4 激活网关

选择存储网关的时区并为网关命名,最后点击 Activate gateway

图5

2.1.5 配置本地磁盘

选择在步骤2.1.2中为文件存储网关配置的新挂载的磁盘作为网关的缓存,确定要用于缓存存储的磁盘。

图6

保存并完成配置任务,观察新创建的存储网关状态是否为Running

图7

2.2  创建文件共享

2.2.1 Amazon S3上创建存储桶,以便作为NFS挂载点保存文件;

2.2.2  创建文件共享

在Storage Gateway服务导航窗格上,选择 File shares,然后选 择 Create file share;

选择之前创建的网关,输入已建立好的S3存储桶名称,并且必须有访问存储桶的权限。我们可以创建新的IAM role或者通过已有的IAM role的方式来使用。

图8

如果使用已有IAM role,则请确保赋予如下的信任关系及访问权限

1)信任策略允许Storage Gateway

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "storagegateway.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId":"account-id"
        }
      }
    }
  ]
}

2)将IAM role赋予如下S3访问及操作权限,请注意中国区arn独特的标示    以及将存储桶名替换为之前需要访问的存储桶名称

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:GetAccelerateConfiguration",
                "s3:GetBucketLocation",
                "s3:GetBucketVersioning",
                "s3:ListBucket",
                "s3:ListBucketVersions",
                "s3:ListBucketMultipartUploads"
            ],
            "Resource": "arn:aws-cn:s3:::filegatewaybucket",
            "Effect": "Allow"
        },
        {
            "Action": [
               "s3:AbortMultipartUpload",
                "s3:DeleteObject",
                "s3:DeleteObjectVersion",
                "s3:GetObject",
                "s3:GetObjectVersion",
                "s3:ListMultipartUploadParts",
                "s3:PutObject"
            ],
            "Resource": "arn:aws-cn:s3:::filegatewaybucket/*",
            "Effect": "Allow"
        }
    ]
}

2.3  如何使用文件存储网关

现在我们已经安装部署了文件存储网关,并且创建了S3存储桶作为文件共享的容器,下面我们就以Microsoft  Windows操作系统为例,来看看如何实际使用文件存储网关。

2.3.1 将文件共享连接到Microsoft Windows 客户端

1)在 Windows 客户端中为 NFS 启用服务;

2)在 Windows 客户端的命令提示符下,键入挂载命令,将S3存储桶作为Windows系统映射的驱动器盘符:

mount –o nolock 网关IP 地址:/S3 存储桶名称 Windows 客户端上的驱动器盘符:

具体执行命令如下所示:

mount –o nolock 10.29.1.2:/filegatewaybucket Z: (注意命令最后的驱动器盘符的:)

2.3.2 测试文件网关

在 Windows 客户端上,导航到文件共享的驱动器盘符(Z:)。驱动器名称前面是您的 S3 存储桶的名称。

将一些文件或文件夹复制到驱动器。

图9

在 S3 管理控制台上,导航到您映射的存储桶。此时应该看到在您指定的S3 存储桶中复制的文件和文件夹。

图10

通过NFS 客户端可以对文件进行写入、读取、删除等操作。

读取操作首先访问本地磁盘中的缓存文件,如果文件不在缓存,则从 S3 中提取并添加到缓存中。写入操作,通过回写式缓存,将文件分段上传写入到 S3。

注意:如果使用Linux操作系统,可通过如下命令进行挂载,使用方法相似:

mount –t nfs –o nolock  网关IP:/S3存储桶名称 [MountPath]

3.    管理与监控存储网关

3.1  管理存储网关

除了使用AWS Storage Gateway管理控制台进行日常的管理和维护工作外,用户还可以通过使用默认用户名 sguser 和密码 sgpassword 来登录存储网关虚拟机的管理配置界面,下图为网关虚拟机本地控制界面。

图11

3.1.1 测试网络连接情况

键入3 测试网络连接情况

图12

键入 6 ,选择测试中国区,测试 Internet 连接。当排查网关的网络问题时,此测试可能会很有用,如果提示[FAILED]信息,请检查网络或防火墙配置是否正确。

图13

3.1.2 可用管理命令

键入 5 以打开 AWS Storage Gateway 控制台,键入 h 以打开 AVAILABLE COMMANDS (可用命令) 窗口。

图14

可以通过控制台命令行来获取网关的IP,修改密码以及申请支持等能力。

3.1.3 网关系统资源检查

键入6 可以查看网关资源配置情况,如果资源配置不满足要求,则会提示资源不足错误,网关将无法正常运行。

图15

3.2  监控存储网关

除了日常的管理工作,用户可以通过使用CloudWatch来监控与存储网关相关的主要参数,其中包括CloudBytesDownloaded,CloudBytesUploaded, CacheUsed, CacheHitPercentage等指标,通过不同指标可以监控Storage Gateway到云端上传及下载的使用量及Cache相关的使用情况,如下图所示。

用户还可以通过CloudTrail捕获Storage Gateway调用API的情况,并将日志文件保存在S3存储桶中 。

图16

4.    小结

文件存储网关服务的推出是对当前基于数据卷和 VTL 存储网关的一个补充,通过对标准的文件系统协议的支持,使得用户可以无需修改现有应用程序便可以将文件存储在云端。大大简化了混合架构模式下用户希望借助Amazon S3 来替代本地存储的过程,以帮助用户实现节约成本和更高持久化的保障。存储网关还通过本地缓存方式提供对数据的低延迟访问,集成 AWS Identity and Access Management (IAM) 进行访问控制,以及使用 AWS 管理控制台和 AWS Command Line Interface (AWS CLI) 进行管理操作。

当然,文件存储网关现阶段只支持VMware ESXi虚拟化环境,对于需要使用其他虚拟化软件的小伙伴还需要再耐心等待一下。另外,网络条件也将会成为影响文件存储网关使用体验的重要因素之一。

作者介绍:

周琦,亚马逊AWS解决方案架构师,拥有10年IT领域工作经验,先后在IBM,VMware等公司担任工程师及架构师等职位,现负责AWS云服务在国内的推广和支持工作,同时致力于企业混合云,DevOps以及微服务等领域的研究。

 

 

Amazon DynamoDB 让海量数据管理变为可能

随着大数据技术的发展,其数据集可以增长的非常庞大,以至于基于传统的关系型数据库管理系统及其工具集很难处理这些庞大的数据集。处理这些问题需要新的工具、框架、软件和服务。与此同时,越来越多的企业需要连续不断地访问数据,从而提高效率,改善用户体验。好的大数据工具集将以较低的成本,接近实时的速度提供可伸缩、高性能的数据管理和分析功能。企业借助于这些工具可以获得更强大的智能及竞争优势。

NoSQL(Not only SQL)非关系型数据库是近年来发展最为迅猛的大数据处理技术之一。在这一领域有非常多的产品和解决方案,包括众多的开源工程。如何选择一款合适的产品往往是困扰企业的难题。此外,企业应用场景各式各样,如何将NoSQL与企业IT融合也是一个重要的课题。如今的企业中,并非所有用例都直观地倾向于使用关系型数据库,或者都需要严格的ACID属性(特别是一致性和隔离性)。以Web为中心的企业中信息管理的新兴模式,使得“非关系型数据库”成为处理这些数据的最佳选择(较之关系型数据库来说)。NoSQL提供了对非结构化数据的支持,拥有支持分区的水平伸缩性,支持高可用性等。常见的NoSQL应用场景包括:日志挖掘、分析社交计算、外部数据聚合、前端订单处理系统、企业内容管理等。

Amazon DynamoDB是一种完全托管的NoSQL数据库服务,提供快速且可预测的性能,能够实现无缝扩展。Amazon DynamoDB可自动将表的数据和流量分布到足够多的服务器中,以处理客户指定的请求容量和数据存储量,同时保持一致的性能和高效的访问。所有数据项目均存储在固态硬盘(SSD)中,并在区域的多个可用区间自动复制,以提供内置的高可用性和数据持久性。例如,您可以使用Amazon DynamoDB创建数据库表,并可在表中存储和检索任意数量的数据和处理任何级别的请求流量。也可以通过AWS管理控制台创建新的Amazon DynamoDB数据库表、扩展或缩小表的请求容量而不导致停机或性能降低,还能查看资源使用率与性能指标。使用Amazon DynamoDB,你可以将操作和扩展分布式数据库的管理工作负担交给AWS服务,无须担心硬件预配置、设置和配置、复制、软件修补或集群扩展等问题。

使用Amazon DynamoDB能带来哪些好处

1    可扩展:Amazon DynamoDB旨在实现吞吐量和存储容量的高效无缝扩展

  • 预配置吞吐量:创建表时,只须指定所需的吞吐容量即可。Amazon DynamoDB会为您的表分配专用资源以满足性能要求,并自动将数据分区到足够多的服务器以满足请求容量。如果您的应用程序需求发生变化,只须使用AWS管理控制台或Amazon DynamoDB API调用更新表的吞吐容量即可。在扩展过程中,仍然能够保证之前的吞吐量水平没有下降。
  • 自动存储扩展:Amazon DynamoDB表中可存储的数据量没有限制,而且随着您使用Amazon DynamoDB写入API所存储数据量的增加,该服务会自动分配更多存储。
  • 完全分布式的无共享架构:Amazon DynamoDB可水平扩展并在数百台服务器中无缝扩展单个表。

2     快速、可预测的性能:Amazon DynamoDB的服务端平均延迟不超过10毫秒。该服务在固态硬盘中运行,其构建方式旨在任何规模均能保证服务性能持续优良,降低延迟。

3     轻松管理:Amazon DynamoDB是完全托管的服务,您只须创建数据库表,其余事情都交由该服务代劳。您无须担心硬件或软件预配置、设置和配置、软件修补、操作可靠的分布式数据库集群,也不必担心随着扩展的需要在多个实例间对数据进行分区等问题。

4     内置容错能力:Amazon DynamoDB内置容错能力,可在某个地区多个可用区域之间自动同步备份数据,以实现高效的可访问性,即使单台机器甚至设施出现死机,防护措施可保证数据万无一失。

5     灵活:Amazon DynamoDB没有固定模式。相反,每个数据项目可以有不同数量的属性。多种数据类型(字符串、数字、二进制数据和集)使数据模型更加丰富。

6     高效的索引:Amazon DynamoDB表中的每个项目均由一个主键标识,让您能够快速高效地访问数据项目。还可以就非键值属性定义二级索引,并使用替代键查询您的数据。

7     强一致性、原子计数器:与许多非关系数据库不同,Amazon DynamoDB允许您对读取操作使用强一致性检验以确保始终读取最新的值,从而使开发更加便捷。Amazon DynamoDB支持多种本地数据类型(数字、字符串、二进制数据和多值属性)。该服务还支持本地原子计数器,允许您通过调用单个API调用自动递增或递减数字属性。

8     安全:Amazon DynamoDB非常安全,采用经过验证的加密方法验证用户身份,以防未授权数据访问。此外,它还与AWS Identity and Access Management集成,为组织内的用户实现精细的访问控制。

9     集成监控:Amazon DynamoDB在AWS管理控制台中为您的表显示关键操作指标。该服务还与CloudWatch集成,以便您查看每个Amazon DynamoDB表的请求吞吐量和延迟,并轻松跟踪您的资源使用情况。

10  Amazon Elastic MapReduce集成:Amazon DynamoDB还与Amazon Elastic MapReduce(Amazon EMR)集成。Amazon EMR允许企业使用AWS服务中托管的即用即付计费Hadoop框架对大型数据集执行复杂分析。依赖Amazon DynamoDB的强大服务能力,客户可轻松使用Amazon EMR分析Amazon DynamoDB中存储的数据集,并在Amazon S3中存档结果,同时在Amazon DynamoDB中保存完整原始数据集。

AdRoll使用Amazon DynamoDB的案例

广告重定向旨在将网站访问者转变为客户。重定向是带动全球在线企业营收的主要因素之一,而AdRoll是该行业的领导者之一,为了有效地服务于广告,AdRoll需要能够灵活快速地增加容量,在极快的响应时间内实时中标,并通过自动化确保系统迅速响应竞价。

通过推出自己的实时竞价基础设施,AdRoll需要为四个大区中的每个用户都同步数据,这大约涉及数亿用户及每秒数万次写入。该公司不仅要应对实时写入海量数据这一艰巨任务,而且,竞价系统对于每个竞价请求有着100毫秒的严格上限,因此,AdRoll需要强力确保读取方面的性能。在评估了多种替代方案后,该公司决定使用Amazon DynamoDB来实现低延迟,确保吞吐量及快速扩展能力。

Amazon DynamoDB表由主键(分区键,或分区键和排序键)和属性组成,如表1所示。无模式设计意味着每个数据项目都可能具有数量不同的属性。多种数据类型(字符串、数字、二进制数据和集合)使数据模型更加丰富。AdRoll表设计为将Cookie用作分区键,将配置文件ID用作排序键,而将时间戳用作属性。AdRoll对所有表都使用了分区键和排序键。

         表1  Amazon DynamoDB表

分区键 排序键 属性
Cookie(用户ID) 配置文件 时间戳
“1234” “Segment1” “1378237387”
“1234” “Segment2” “1378237417”

通过将Amazon DynamoDB与Apache Storm配合使用,AdRoll只需不到50毫秒,即可在保持低成本的同时,复制其遍布世界各地的数据集,同时对竞价和对客户发布广告提供快速的响应时间。AWS服务提供的可扩展性同样使AdRoll获益匪浅。AWS服务使AdRoll能够处理来自Facebook、Google、Yahoo和其他高访问量网站的流量,借此,支持的每日展示次数超过了500亿。