亚马逊AWS官方博客

巧用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亿。

AWS Snowmobile——在数周内将数EB数据迁移至云端

将大规模数据由内部环境迁移至云端往往是业务转移工作中的最大挑战——但这种挑战本不必存在。即使配合高速传输连接,将PB甚至EB规模的影片库、财务记录、卫星图像或者科学数据通过互联网进行转移仍然需要耗时数年甚至数十年。从商业角度来看,添置新型网络或者升级现有连接显然并不现实,特别是考虑到转移完成后数据中心将不再需要这样奢侈的网络资源。

去年我们公布了AWS Snowball服务(具体请参阅AWS Snowball——利用Amazon提供的存储设备在一周内迁移1 PB数据)作为大规模数据迁移的一种可行方案。凭借着80 TB高存储容量,这些设备能够很好地解决大多数客户面临的难题,而且其目前已经得到广泛采用。

然而,对于拥有EB级别内部存储规模的客户,这80 TB容量仍然显得相当可怜。通过计算,他们发现要完成全部数据的迁移需要大量设备,并且需要解决令人头痛的大规模物流寄送问题。

AWS Snowmobile介绍

为了满足此类客户的实际需求,我们在AWS re:Invent 2016上公布了Snowmobile服务。这一安全数据存储车可容纳高达100 PB数据,从而帮助大家在数周之内将EB级别数据迁移至AWS当中(如果必要,您还可以使用多辆存储车)。其设计目标在于帮助来自金融服务、媒体及娱乐、科学乃至其它行业的客户解决问题。Snowmobile可接入您的网络并作为本地NFS挂载式分卷使用。大家可利用现有备份与归档工具将需要上传至Amazon简单存储服务(简称S3)或者Amazon Glacier的数据导入其中。

从物理结构来看地,Snowmobile采用一款坚固耐用且难于侵入的,尺寸为45英尺长、9.6英尺高、8英尺宽海运集装箱作为外壳。Snowmobile具备防水防恶劣天气设计,能够随意停靠在您现有数据中心附近。每台Snowmobile需要使用350千瓦交流电源; 如果大家现场不具备充足电力,我们还可提供发电机供其运作。

在安全层面,Snowmobile将包括从监管追踪到视频监控在内的多个逻辑与物理保护层,并加以结合。用户的数据利用AWS密钥管理服务(简称KMS)提供的密钥进行加密,而后才会被写入设备当中。每套集装箱都配备有GPS追踪,其利用蜂窝或者卫星连接与AWS方面进行通信。我们将在Snowmobile行进过程中安排一辆安保车全程保护。在Snowmobile处于您的内部基础设施附近时,我们还可以提供专门的安保人员进行配合。

每台Snowmobile中包含一根网络线缆,连接在一台高速交换机上,能够通过多条40 Gb/S的连接以1 Tb/S的速率传输数据,从而实现高速数据交换能力。假定大家的现有网络能够在传输速度上达到这一水平,则可在约10天时间内装满一台Snowmobile。

Snowmobile的运作

我个人手头没有EB级别数据中心,我当然也没有足够的空间容纳这一45英尺长的大型集装箱。不过为了帮助大家更好地理解Snowmobile的运作流程,我决定使用自己的乐高组装台,并借此建立起一套缩小模型。我希望大家能够喜欢这种以小见大的解释方式!

下面从客户的数据中心起步。其之前就已经构建完成,而且已经颇有年头。机架中塞满了不同年份的磁盘与磁带驱动器,每一台都包含有珍贵的关键性业务数据。而您和您的同事则不得不将大量时间投入到规划楼层面积、追踪线路排布以及尽可能压榨性能方面:

而管理者则越来越沮丧,不知道这样勉强为之的作法还能持续多久:

幸运的是,一位同事每天都在关注博客,而她借此找到了解决问题的办法:

在与AWS进行通话之后,双方很快安排了一次会议:

大家齐聚AWS办公室,希望了解更多与Snowmobile以及迁移计划相关的细节信息:

大家围在Snowmobile微缩模型周边,连小狗也来凑热闹。管理者则拍下了照片:

一辆Snowmobile出现在您的数据中心附近:

AWS Professional Services(专业服务)帮助大家将其与设施对接,从而开始进行数据传输:

Snowmobile重新驶回AWS,而您的数据亦按照指定要求导入至云端!

Snowmobile在 DigitalGlobe的表现

作为我们的合作伙伴,DigitalGlobe公司利用Snowmobile将100 PB卫星图像数据迁移至AWS当中。以下为Jay Littlepage(前Amazon员工,现任DigitalGlobe公司基础设施与运营副总裁)对于这项服务的评论:

与多数大型企业一样,我们也在努力将IT运营负载由自有数据中心迁移至AWS。我们的地理空间大数据平台GBDX自建立以来始终以AWS作为运行基础。但我们的高分辨率卫星影像已经拥有16年的收集历史,其覆盖地球表面60亿平方公里面积且始终存放在自有设施之内。我们虽然已经开始将归档逐步迁移至AWS,但整个过程缓慢且效率低下。我们的卫星每年都在生成更多地球拍摄影像(10 PB),而其总量甚至超过了以往迁移能力的上限。

我们需要一套解决方案,能够把我们现有的100 PB归档快速迁移至AWS环境当中,但在Snowmobile出现之后并无可行的途径可用。DigitalGlobe公司目前能够将全部原始影像归档直接通过一辆Snowmobile转移至Amazon Glacier存储库内。AWS Snowmobile运营人员提供极为出色的定制化服务,他们协助进行了配置、监控与物流追踪。利用Snowmobile强大的数据传输能力,我们得以越来越快地将影像归档导入至AWS端,这使得我们的客户及合作伙伴能够快速获取海量数据集。通过在GBDX当中使用AWS的弹性计算平台,我们将能够运行分布式图像分析、以前所未有的速度揭示全球范围内的环境变化速度与格局发展趋势,并以较内部设施更具成本效益的方式获得洞察结论。如果没有Snowmobile,我们无法在这么短的时间内传递如此庞大的数据集或者为客户创造新的商业机遇。Snowmobile已经成为真正的游戏规则改变者!

需要了解的情况

以下为大家应当了解的,与Snowmobile相关的一些情况:

数据导出——这项服务的最初目标在于实现面向AWS的数据导入。但我们很清楚,也有一部分客户希望借此实现数据导出,从而建立起更为快速高效的灾难恢复用例。

推出时间——Snowmobile目前已经在全部AWS服务区正式上线。正如在以上章节中所提到,其并不属于自助服务型产品。大家可以同AWS方面的销售人员讨论实际需求以及需要进行导入的具体数据类型与规模。

价格——目前还无法公布确切的定价信息。然而,我们可以保证Snowmobile在速度与实施成本上优于基于网络的数据传输模式。

-Jeff

原文链接:

https://aws.amazon.com/cn/blogs/aws/aws-snowmobile-move-exabytes-of-data-to-the-cloud-in-weeks/

使用Amazon CloudFront签名URL+S3实现私有内容发布

前言

Amazon CloudFront 是一个全球性内容分发网络 (CDN),可实现网站、API、视频内容或其他 Web 资产的快速分发。用户可以使用CloudFront来加速分发保存在Amazon S3存储桶上的各种内容,比如文档、图片、媒体文件和软件安装包等。很多AWS客户在使用CloudFront+S3通过互联网向自己的最终用户提供内容下载的时候,也希望能够限制到只允许合法的用户下载,比如那些已经通过了身份认证或已经付费的用户,避免开放下载可能造成的数据安全和流量成本等问题。进一步,这些AWS客户还希望能够限制其最终用户可以执行下载操作的日期时间段,发起下载请求的来源IP地址范围等等。使用CloudFront的签名URL功能就可以帮助AWS客户实现其私有内容的安全发布。

CloudFront签名URL功能简介

CloudFront的签名URL功能通过在普通的Http或Https请求中添加经过哈西和签名认证的策略内容,来保护私有内容不受非法访问。当收到来自客户端比如浏览器、移动App或桌面应用对特定资源的访问请求后,CloudFront会首先利用保存的密钥解密请求中包含的签名部分内容,检查是否完整和正确。然后CloudFront继续分析解密出的权限策略内容,并根据权限策略定义的限制条件来决定是否向客户端提供请求资源。

AWS客户可以开发Web服务或工具软件来向自己的最终用户提供签名URL,就可以让这些最终用户在受限的条件下安全地访问通过CloudFront发布的内容,比如存储在S3中的图片。

AWS客户除了可以在签名URL的权限策略定义中直接限制资源请求客户端可以访问的资源种类、请求发生时间、来源IP地址范围以外,结合CloudFront既有功能还可以进一步限制其发出请求的协议类型(Http或Https)、访问域名类型(CloudFront自动分配域名或客户自有域名)。

整体技术方案

需求

在正式开始创建CloudFront私有内容发布之前,我们首先要明确在创建过程中的一些主要的选项。对于这些选项的不同设置会影响最终所创建的私有内容发布的效果。好在通过CloudFront发布私有内容的主要步骤基本类似,通过了解一个典型的CloudFront私有内容发布的完整过程就可以快速理解和掌握其他方式的发布过程。下面的表格列出了几个主要可选项和我们本次演示所做的选择。

 

选项 值域 本次选择
源站类型

S3存储桶,

普通Web服务器

S3存储桶
客户端到CloudFront的协议类型

Http,

Https

Https
CloudFront到源站的协议类型

Http,

Https

Https
CloudFront发布点的类型

Web发布点,

RTMP发布点

Web发布点
CloudFront发布点的域名类型

CloudFront自动分配的域名,

客户自有域名

客户自有域名
签名类型

签名URL,

签名Cookie

签名URL
权限策略类型

Canned Policy,

Custom Policy

Custom Policy

架构

一般地,一个完整的高性能私有内容发布平台主要包括四部分:内容源站,加速CDN,身份认证和权限管理,资源请求客户端。基于上面的需求分析,我们可以明确本次介绍中的四部分组成:

  • 内容源站:S3存储桶
  • 加速CDN:CloudFront
  • 身份认证和权限管理:签名URL生成器

说明:这次功能演示并没有包括用户身份认证部分。这部分功能读者可以基于基本的签名URL生成器功能基础上继续添加。比如开发一个Web服务,在最终用户请求某个资源的时候先校验其身份,要求其先输入正确的用户名和密码,然后再为请求的具体资源自动产生签名URL并返回请求客户端。

  • 资源请求客户端:用户浏览器,移动APP或桌面客户端应用


演示

当我们完成本次CloudFront签名URL+S3实现私有内容发布的相关设置和开发后,具体的演示过程如下:

1)   向S3存储桶上传需要发布的内容,比如图片文件或视频文件。

2)  利用签名URL生成器为上传的资源产生签名URL

3)  在测试机的浏览器中输入签名URL并发送请求给CloudFront

4)  CloudFront验证签名URL

5)  如果被请求资源已经在CloudFront当前边缘节点的缓存中,直接返回被请求资源。

6)  如果被请求资源还不在CloudFront当前边缘节点的缓存中:

a) CloudFront从S3存储桶取回被请求资源

b)  CloudFront将被请求资源返回浏览器

c)  CloudFront在当前边缘节点缓存该资源

使用CloudFront签名URL+S3实现私有内容发布的完整步骤

完整的步骤将分为以下几个主要部分分别执行:

(一) 创建CloudFront密钥对

(二) 创建S3存储桶

(三) 上传SSL安全证书

(四) 创建CloudFront Web发布点

(五) 更新 CloudFront Web 发布点,启用签名URL功能

(六) 开发签名URL生成器

(七) 验证测试

(一)创建CloudFront密钥对

1.  使用AWS 根账号登录Global AWS Web控制台

2.  访问“服务”→“安全、身份与合规”→“IAM”

3.  查看“安全状态”,点开“删除您的根访问密钥”,执行“管理安全证书”

4.  访问“CloudFront密钥对”,执行“创建新的密钥对”。

5.  下载创建的CloudFront密钥对对应的私钥文件,记录下密钥对的访问键值比如“BPMAJW4W4KMUGDSHRGWD”,这些内容在后面步骤开发签名URL生成器的时候都要用到。

f45c89a82b15:cert weimen$ ls *.pem

pk-APKAJW4W4KMUGDXXXXXX.pem

说明:产生和验证CloudFront签名URL需要用到信任的AWS账号所创建的CloudFront密钥对。这个信任的AWS账号既可以是创建CloudFront发布点的IAM用户所属的AWS账号(Self),也可以是其他任何信任的AWS账号。

请注意:普通IAM账号无法创建CloudFront密钥对,必须是用根账号。

 

(二)创建S3存储桶

1.  使用具有完整S3操作权限的IAM用户登录Global AWS Web控制台

2.  访问“服务”→“存储”→“S3”,执行“创建存储桶”。

3.  在对话框中输入存储桶名称比如“cdntest0001”,选择区域,执行“创建”。

4.  记录下创建的存储桶名称,在后面步骤创建CloudFront Web发布点的时候会用到。

5.  传测试图片文件比如“earth.jpg”到新创建的S3存储桶中

6.  选中新建存储桶比如“cdntest0001”,点击“属性”标签,点开“权限”,可以看到这时候存储桶策略为空,ACL设置只允许创建者访问。

(三)上传SSL安全证书

1.  如果尚未安装AWS 命令行客户端(CLI), 请参照官方文档链接下载和安装AWS CLI: http://docs.aws.amazon.com/zh_cn/cli/latest/userguide/installing.html

2.  查找或新建一个IAM用户和对应API访问密钥(Access Key),需要保证该IAM用户拥有IAM SSL安全证书管理权限。

a)  关于如何创建IAM用户,请参见:

http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/id_users_create.html#id_users_create_console

b)  关于如何为IAM用户创建API访问密钥,请参见:

http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/id_credentials_access-keys.html

c)  关于如何为IAM用户设置权限策略,请参见:

http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/access_policies_create.html

http://docs.aws.amazon.com/zh_cn/cli/latest/userguide/cli-iam-policy.html

3.  执行“aws configure”,设置IAM用户API访问密钥和默认区域名,默认区域可以为任一海外区域。

f45c89a82b15:cert weimen$ aws configure

AWS Access Key ID [****************6ZXA]: 

AWS Secret Access Key [****************NOLI]: 

Default region name [us-east-1]: 

Default output format [json]: 

4.  如果还没有CA签发的SSL安全证书,请提前完成申请,具体申请过程请参考相关CA的业务介绍说明。

5.  使用相关工具查看CA签发的安全证书内容,确认该证书包含正确域名信息。

6.  列表CA提供的证书相关文件,确认安全证书文件、私钥文件和证书链文件都存在。

f45c89a82b15:cert weimen$ ls -l

total 24

-rwxr-xr-x@ 1 weimen  ANT\Domain Users  2065  1  4 21:54 mw.homyusc.com.crt

-rwxr-xr-x@ 1 weimen  ANT\Domain Users  1700  1  4 21:54 mw.homyusc.com.key

-rwxr-xr-x@ 1 weimen  ANT\Domain Users  3449  1  4 21:54 root_bundle.crt

7.  确认上面的文件内容都是X.509 PEM格式。如果不是,请使用对应工具先转化文件格式。下面的例子介绍了如何使用openssl将一个非PEM格式的.crt文件转化为PEM格式。

openssl x509 -in mycert.crt -out mycert.pem -outform PEM

8.  检查证书相关文件内容,确保格式正确

a)  安全证书文件mw.homyusc.com.crt

-----BEGIN CERTIFICATE-----

MIIFxzCCBK+gAwIBAgIQMwrcYbUzB6y7QHQiyYQuwTANBgkqhkiG9w0BAQsFADCB

hTELMAkGA1UEBhMCUEwxIjAgBgNVBAoTGVVuaXpldG8gVGVjaG5vbG9naWVzIFMu

......

SkHCiJ3TLFqNNL7D/Lou5XuUVx9OdPneDrG3qXA2KDkFFSNIbI3TJKJ0icKOJyYj

hk6nE3hxn8S8PXJ670YaPozQRhT2ZW4hF10vpzZ5PY1cMZ+TCaKyTrlY0g==

-----END CERTIFICATE-----

b)  私钥文件mw.homyusc.com.key

-----BEGIN RSA PRIVATE KEY-----

MIIEowIBAAKCAQEApeF7s/+BxjqPxri2DOhDla2XECfiJe02qG5TOLagm5e8niww

17ZmE6Ay5qR45Z8Tszkk1x3PPi0mSdkLeo24Nn9B1pwDpIIZZS3S5Pyiojz4Vu4J

......

ShsRa1MdKkWqHtWpu9HDPQwKqHhF6Z9d8MV+xGw7aieq63LfGGq0EmlMBWHRBpIQ

wV6SRCOf2YY1gHuftjmURyvNnoqntZtFfN2HHcO8QmfpRW2zpizZ

-----END RSA PRIVATE KEY-----

c)  证书链文件root_bundle.crt

-----BEGIN CERTIFICATE-----

MIIEzjCCA7agAwIBAgIQJt3SK0bJxE1aaU05gH5yrTANBgkqhkiG9w0BAQsFADB+

MQswCQYDVQQGEwJQTDEiMCAGA1UEChMZVW5pemV0byBUZWNobm9sb2dpZXMgUy5B

......

y+WutpPhI5+bP0b37o6hAFtmwx5oI4YPXXe6U635UvtwFcV16895rUl88nZirkQv

xV9RNCVBahIKX46uEMRDiTX97P8x5uweh+k6fClQRUGjFA==

-----END CERTIFICATE-----

 

-----BEGIN CERTIFICATE-----

MIIEtDCCA5ygAwIBAgIRAJOShUABZXFflH8oj+/JmygwDQYJKoZIhvcNAQELBQAw

PjELMAkGA1UEBhMCUEwxGzAZBgNVBAoTElVuaXpldG8gU3AuIHogby5vLjESMBAG

A1UEAxMJQ2VydHVtIENBMB4XDTA4MTAyMjEyMDczN1oXDTI3MDYxMDEwNDYzOVow

......

QVkppV4ig8OLWfqaova9ML9yHRyZhpzyhTwd9yaWLy75ArG1qVDoOPqbCl60BMDO

TjksygtbYvBNWFA0meaaLNKQ1wmB1sCqXs7+0vehukvZ1oaOGR+mBkdCcuBWCgAc

eLmNzJkEN0k=

-----END CERTIFICATE-----

9.  上传SSL安全证书到AWS IAM服务

命令格式:aws iam upload-server-certificate –server-certificate-name [自定义的已上传证书名] –certificate-body [PEM格式证书文件] –private-key [PEM格式私钥文件] –certificate-chain [PEM格式证书链文件] –path [访问路径

f45c89a82b15:cert weimen$ aws iam upload-server-certificate --server-certificate-name MyTestCert

--certificate-body file://mw.homyusc.com.crt--private-key file://mw.homyusc.com.key

--certificate-chain file://root_bundle.crt --path /cloudfront/test/

{

    "ServerCertificateMetadata": {

        "ServerCertificateId": "ASCAIZCBMIGVKID653NV2",

        "ServerCertificateName": "MyTestCert",

        "Expiration": "2018-01-04T03:30:35Z",

        "Path": "/cloudfront/test/",

        "Arn": "arn:aws:iam::591809XXXXXX:server-certificate/cloudfront/test/MyTestCert",

        "UploadDate": "2017-01-15T02:13:07.848Z"

    }

}

请注意

  • 证书文件前面的“file://”不能省
  • –certificate-chain 不能省,如果没有值,就表示是用根证书。
  • –path访问路径必须是以“/cloudfront/”开头,以“/”结尾。

(四)创建CloudFront WEB发布点

1.  使用具有完整S3和CloudFront操作权限的IAM用户登录Global AWS Web控制台

2.  访问“服务”→“网络和内容分发”→“CloudFront”,执行“Create Distribution”。

3.  选择创建Web发布点

4.  请按照如下表格内容选择或输入内容:

字段名 输入值 说明
Origin Domain Name 刚刚创建的存储桶名,比如“cdntest0001” 通过下拉列表可选择
Restrict Bucket Access Yes 限制只能够通过CloudFront访问S3存储桶内容
Origin Access Identity Create a New Identity 如果您之前已经有创建的OAI,可以选择“Use an Existing Identity”,并选中该OAI,否则就让系统帮您创建一个。
Grant Read Permissions on Bucket Yes, Update Bucket Policy 自动更新S3存储桶策略, 添加CloudFront OAI用户对存储桶的读取权限。
Viewer Protocol Policy HTTPS Only 客户端只能够使用Https协议访问发布点
Alternate Domain Names 输入您的自有域名,比如“mw.homyusc.com” 该域名需要与上传的SSL安全证书中包含的域名信息一致。
SSL Certificate Custom SSL Certificate (example.com): 使用自己上传的SSL安全证书而不是默认的CloudFront安全证书。
Custom SSL Certificate (example.com): 选择之前上传到IAM服务的自有SSL安全证书
Custom SSL Client Support Only Clients that Support Server Name Indication (SNI) 部分不支持SNI的浏览器客户端将不能访问发布资源
Logging On
Bucket for Logs 选择S3存储桶 存放日志文件的S3存储桶
Log Prefix 输入CloudFront日志文件名前缀,比如“MyLog” 便于区分CloudFront日志文件和其他类型文件

5.  其余设置都保留默认值

6.  执行“Create Distribution”,记录下创建的Web发布点域名,形如“dz60cvvsxhzn8.cloudfront.net”。

7.  访问“服务”→“存储”→“S3”,查看之前创建的存储桶已经发生了权限改变:

a)  存储桶ACL增加了“awsdatafeeds”账号的读写权限,目的是实现cloudfront日志文件上传。

b)  存储桶策略增加了CloudFront OAI用户账号的只读权限,实现CloudFront访问S3存储桶内容。

8.  刚刚创建完成的Web发布点将处于“In Progress”(正在部署)状态。

9.  请耐心等待Web发布点最终变为“Deployed”(完成部署)状态。

10.  请访问您的自有域名的管理服务,创建或修改cname记录将自有域名比如“mw.homyusc.com”指向新创建的Web发布点CloudFront域名比如“dz60cvvsxhzn8.cloudfront.net”。

11.  检查自有域名的cname记录设置有效

f45c89a82b15:cert weimen$ dig mw.homyusc.com

 

; <<>> DiG 9.8.3-P1 <<>> mw.homyusc.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13861

;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 4, ADDITIONAL: 4

 

;; QUESTION SECTION:

;mw.homyusc.com.                                             IN            A

 

;; ANSWER SECTION:

mw.homyusc.com.                              19           IN            CNAME dz60cvvsxhzn8.cloudfront.net.

dz60cvvsxhzn8.cloudfront.net. 60 IN              A             52.84.26.216

12.  在测试电脑的浏览器中输入未签名的访问URL,使用https协议和自有域名,格式形如“https://mw.homyusc.com/earth.jpg” 。

a)  浏览器就可以显示来自S3存储桶中的图片

b)  浏览器中可以查看到之前上传的SSL安全证书

说明:在这个阶段我们暂时还没有启用签名URL功能,只是设置了“自有域名”和S3存储桶“来源访问限制”功能。如果能够通过Https协议正常显示S3中的图片文件,说明前面的步骤设置正确无误。

(五)更新CloudFront WEB发布点,启用签名URL功能

1.  使用具有完整CloudFront操作权限的IAM用户登录Global AWS Web控制台

2.  访问访问“服务”→“网络和内容分发”→“CloudFront”

3.  选中之前创建的Web发布点,执行“Distribution Settings”

4.  选中“Behavior”标签,编辑“Default (*)”。

5.  设置“Restrict Viewer Access (Use Signed URLs or Signed Cookies)”为“Yes”

6.  设置“Trusted Signers”为“Self”

说明:表示使用当前登录的IAM用户所对应的AWS 账号来签名URL请求,“Trusted Signers”设置需要对应之前在创建的CloudFront密钥对时使用的AWS根账号。

13.  执行“Yes,Edit”按钮提交更新

14.  刚刚更新完成的Web发布点将处于“In Progress”(正在部署)状态。

15.  请耐心等待Web发布点最终变为“Deployed”(完成部署)状态。

(六)开发签名URL生成器

CloudFront支持使用各种开发语言和工具产生签名URL。在这篇博客里,我提供了一个使用JAVA语言开发签名URL生成器的完整例子。整个项目包括源码和依赖的库文件都打包成了完整的Eclipse项目文件,用户只需要下载后执行Eclipse的项目导入操作就可以进行代码研究和测试。

JAVA版的签名URL生成器主要依赖了一个第三方开源项目jets3t的相关库文件。jets3t项目开发了一套完整的JAVA工具来访问Amazon S3、Amazon CloudFront和 Google Storage Service。 关于jets3项目的详情请参考其官网链接。

下面的步骤详细介绍了如何使用jets3t相关工具类来开发CloudFront签名URL生成器:

1.  使用openssl转换下载的PEM格式CloudFront密钥对对应私钥文件成为DER格式

f45c89a82b15:cert weimen$ openssl pkcs8 -topk8 -nocrypt -in pk-APKAJW4W4KMUGDXXXXXX.pem -inform PEM -out cdnPK.der -outform DER

2.  下面的代码片段展示了签名URL生成器的实现细节:

a)  读取DER格式的CloudFront 密钥对的私钥文件

b)  构造被签名URL

c)  构造定制访问权限策略

d)  执行签名

e)  输出签名后的URL

public static void main(String[] args) throws Exception

{

    //1.加载Hash和签名算法类

    Security.addProvider(

    new org.bouncycastle.jce.provider.BouncyCastleProvider());

 

    // ================================================================

    // ================2.签名相关参数====================================

    // ================================================================

 

    //2.1.CloudFront为发布点分配的域名或者用户自己的域名

    String param_DistributionDomain = "自己的域名或cloudfront发布点的域名";

    //String param_DistributionDomain = "mw.homyusc.com";

 

    //2.2.转化成"*.der"格式的私钥文件

    String param_PrivateKeyFilePath = "本地保存的*.der格式的cloudfront密钥对私钥文件的带路径文件名";

    //String param_PrivateKeyFilePath = "/Users/weimen/signedurl/cert/cdnPK.der";

 

    //2.3.S3存储桶中文件的访问Key值

    String param_S3ObjectKey = "需要被访问的S3存储桶内文件访问key值";

    //String param_S3ObjectKey = "earth.jpg";

 

    //2.4.CloudFront密钥对对应的访问KEY值

    String param_KeyPairId = "使用根账号创建的CloudFront密钥对Key值";

    //String param_KeyPairId = "APKAJW4W4KMUGDXXXXXX";

 

    //2.5.待签名的URL

    //具体协议(http/https)需要和CloudFront发布点设置对应

    String param_UrlToBeSigned = "http://或者https://"

                          + param_DistributionDomain

                          + "/"

                          + param_S3ObjectKey;

 

    /*

    String param_UrlToBeSigned = "https://"

                          + param_DistributionDomain

                          + "/"

                          + param_S3ObjectKey;

    */

 

 

    //3.加载私钥文件内容

    byte[] derPrivateKey =

        ServiceUtils.readInputStreamToBytes(

            new FileInputStream(param_PrivateKeyFilePath));

 

    // ================================================================

    // ================4.定制策略相关参数================================

    // ================================================================

 

    //4.1.权限策略生效的路径,可以使用"*"和"?"来实现批量匹配,

    //具体协议(http/https)需要和CloudFront发布点设置对应

    String param_PolicyResourcePath = "http://或者https://"

                              + param_DistributionDomain

                              + "/"

                              + param_S3ObjectKey;

    /*

    String param_PolicyResourcePath = "https://"

                                + param_DistributionDomain

                                + "/"

                                + param_S3ObjectKey;

    */

 

    //4.2.签名URL失效时间   

    Date param_DateLessThan = ServiceUtils.parseIso8601Date("UTC格式的签名URL失效时间");

    //Date param_DateLessThan = ServiceUtils.parseIso8601Date("2017-06-30T22:20:00.000Z");

 

    //4.3.请求客户端的Ip地址范围CIDR设置(可选参数)    

    String param_limitToIpAddressCIDR = "CIDR格式的请求源IP地址范围";

    //String param_limitToIpAddressCIDR = "0.0.0.0/0";

 

    //4.4.签名URL生效时间(可选参数,不输入立即生效)

    Date param_DateGreaterThan = ServiceUtils.parseIso8601Date("UTC格式的签名URL生效时间");

    //Date param_DateGreaterThan = ServiceUtils.parseIso8601Date("2017-01-01T06:31:56.000Z");

 

    //5.根据输入参数创建定制策略

    String policy =

        CloudFrontService.buildPolicyForSignedUrl(

            param_PolicyResourcePath,

            param_DateLessThan,

            param_limitToIpAddressCIDR,

            param_DateGreaterThan   

    );

 

    System.out.println("[INFO]实际构造的的定制策略内容是【" + policy + "】");

 

 

    //6.执行实际签名操作(哈希+签名+Base64编码)

    String signedUrl =

    CloudFrontService.signUrl(

           param_UrlToBeSigned,

           param_KeyPairId,   

           derPrivateKey,

           policy

    );

 

    System.out.println("[INFO]输出的签名URL内容【" + signedUrl + "】");

 

}

3.  读者通过研究上面的代码和注释就可以快速理解签名URL产生的大致流程,然后根据实际需要替换代码中的“签名相关参数”和“定制策略相关参数”(蓝色字体部分),就可以快速开发出属于自己的签名URL生成器。如果需要完整的代码例子,请直接下载对应的Eclipse项目文件。

4.  例子代码产生的签名URL内容类似下面的例子:

https://mw.homyusc.com/earth.jpg?Policy=eyJTdGF0ZW1lbnQiOiBbey

JSZXNvdXJjZSI6Imh0dHBzOi8vbXcuaG9teXVzYy5jb20vZWFydGguanBnIiwiQ29uZGl0aW9uIjp7

IkRhdGVMZXNzVGhhbiI6eyJBV1M6RXBvY2hUaW1lIjoxNDk4ODYxMjAwfSwiSXBBZGRyZXNzIjp7IkFXU

zpTb3VyY2VJcCI6IjAuMC4wLjAvMCJ9LCJEYXRlR3JlYXRlclRoYW4iOnsiQVdTOkVwb2NoVGltZSI6MT

Q4MzI1MjMxNn19fV19&Signature=rJq1~uW3HZIVChPs5X5K9DnM2haH8oy488wXDAIJ6X6DBQAtVJAh

soHkPU3zaChCSGt9wG2uyuC-KslzhAw85K1b~EL52fOhuPf0uJOFAb5PUYW8R4BSyflE-

snFfzQs8laanuSmmpHNCDhGw3YrqPjFSBxm~03F5t2ElizLF~0nQdheZHLrnTrdPUMgHK6ffnANjnETul3aB4

JAzV8N1Wi5YtjjiTApiPQMJ8QrQaPScq9SonQbZdgqYuG5bzAdTxlW2gRwOfsftKSGNVK8uhczlParWZD8wa-

A5PWEaUznaBfHz1Arwiu~JnVGQTqhNPaAZs2BO95t4tqaVSrlWw__&Key-

Pair-Id=APKAJW4W4KMUGDXXXXXX

(七)验证测试

1.  当获得了经过签名的URL后,用户就可以在自己的浏览器中输入该签名URL,或者将签名URL提供给自己开发的桌面客户端或移动APP来访问S3存储桶中的对应文件。

2.  用户还可以继续测试各种异常场景:

a)  直接使用S3文件的URL访问

b)  通过CloudFront域名而不是用户自有域名访问

c)  使用Http协议而不是Https协议访问

d) 在允许的时间段之外访问

e)  使用允许的源IP地址段之外访问

基于我们之前的设置,这些操作都将返回失败消息。

总结

这篇博客完整的介绍了如何利用Amazon CloudFront签名URL功能安全地发布存放在S3存储桶中的私有内容。读者通过研究和学习签名URL生成器的源码,演练完整的CloudFront私有内容发布创建步骤,就可以快速掌握Amazon CloudFront签名URL功能的正确配置和使用方法。

 

例子源码
https://s3.cn-north-1.amazonaws.com.cn/mwpublic/projects/signedurl/SignedURL.zip

参考链接

Amazon CloudFront产品介绍

https://aws.amazon.com/cn/cloudfront/

Amazon S3产品介绍

https://aws.amazon.com/cn/s3/

创建CloudFront Web发布点

http://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/distribution-web.html

利用CloudFront发布私有内容

http://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html

在CloudFront中使用Https

http://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/using-https.html

利用Java语言开发签名URL

http://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/CFPrivateDistJavaDevelopment.html

利用C#和.Net框架开发签名URL

http://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/CreateSignatureInCSharp.html

利用PHP开发签名URL

http://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/CreateURL_PHP.html

上传和管理CloudFront安全证书

http://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-procedures.html

签名URL定制策略

http://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html

jets3t官网

http://www.jets3t.org/

作者介绍:

蒙维

AWS解决方案架构师,负责基于AWS的云计算方案架构咨询和设计,有超过十年以上电信行业和移动互联网行业复杂应用系统架构和设计经验,主要擅长分布式和高可用软件系统架构设计,移动互联网应用解决方案设计,研发机构DevOps最佳实施过程。

 

AWS Snowball Edge——更多存储容量、本地端口与Lambda函数

正如在之前的文章中已经提到,我们于去年推出了AWS Snowball服务(AWS Import/Export Snowbal——利用Amazon提供的存储设备一周内传输1 PB数据),并随后对各项相关更新进行了整理。总体而言,Snowball服务最初是一台50 TB数据传输设备,其设计目标在于强调物理接入及数据安全等要求。一年之后,这项服务的存储容量有所提升,目前达到80 TB,同时还增加了任务管理API、HIPAA认证、HDFS导入与S3适配机制,同时亦可用于更多AWS服务区。

不过最重要的是,这些改进并不会影响该设备的基本特性。一年以来,众多AWS客户将初代Snowball应用于不同类型的物理环境当中,并借此实现包括大数据、基因组学以及数据收集在内的各类工作负载的迁移工作。我们发现这款设备还拥有更为广泛的施展空间。

很多客户掌握着规模庞大且增长速度极快的数据集(通常达数百TB),而其网络连接能力无法将这些数据及时上传至云端,同时现有物理环境则几乎达到极限。客户们希望收集产生自农田、工厂、医院、飞机乃至油井中的数据——从车间监控到视频摄制再到物联网设备信息收集。客户希望能够利用单一模式实现高度简化的数据存储与转发,并在数据到达时进行本地处理。他们希望在数据到达时对其进行过滤、清理、分析、组织、追踪、总结以及监测。他们希望扫描输入数据以掌握其模式或者存在的问题,而后在发现特定情况时快速发出通告。

全新Snowball Edge

现在,我们将Snowball Edge正式加入AWS阵容。这款设备扩展了Snowball的适用范围,其中包含了更多连接方式、存储资源、集群化横向可扩展性,可立足现有S3与NFS客户端进行接入的存储端点以及Lambda支持下的本地处理功能。

从物理角度讲,Snowball Edge的设计目标在于提供一套适用于工业、航空航天、农业以及军事类用例的环境。其新的外形设计亦可实现机架内安装,从而帮助大家发挥其中新增的集群化功能。

下面就让我们看看Snowball Edge带来的各项新特性!

更多连接选项

Snowball Edge拥有出色的连接能力,允许大家从多种高速选项中做出选择。在网络方面,大家可以使用10GBase-T、10或25 Gb SFP28或者40 Gb QSFP+。您的物联网设备能够利用3G蜂窝网络或者Wi-Fi向其中上传数据。如果这还不够,Snowball Edge还提供了一个PCIe扩展端口。

如此丰富的连接选项允许大家以高达每秒14 Gb的速度将数据复制至Snowball Edge当中; 这意味着复制100 TB数据仅需要19小时左右。而从开始到结束,整个导入周期(即由初始数据传输到数据实现S3内可用)大约需要一周,其中包括设备寄送及后续处理的时间。

更高存储容量

Snowball Edge包含100 TB存储容量。

通过集群化方式实现横向扩展

大家可以轻松将两台或者更多Snowball Edge设备配置至单一集群当中,从而提升存储容量及耐用性,同时继续通过单一端点访问全部存储内容。举例来说,将六台设备进行集群化对接将能够提供一套存储容量达400 TB的集群,其耐用性可达99.999%。这意味着大家能够移除其中两台设备而数据仍受到严格保护。

大家还可将该集群扩展至PB级别,并通过简单移除及接入设备实现规模伸缩。此类集群拥有自我管理能力,大家不需要考虑其软件更新或者其它维护工作。

要构建这样一套集群,大家只需要在设置任务时勾选“Local compute and storage only(只使用本地计算与存储)”选项并随后勾选“Make this a cluster(将此创建为集群)”即可,具体如下图所示:

新的存储端点(S3与NFS)

如果您已经拥有某些备份、归档或者数据传输工具,例如S3或者NFS,那么大家可以利用其直接立足Snowball Edge实现数据存储及访问。如果大家创建一套包含两台或者更多设备的集群,则同一端点将可适应于其中全部设备; 这意味着大家能够将这类集群视为本地网络附加型存储资源。

Snowball Edge支持一组强大的S3 API子集,其中包括LIST、GET、PUT、DELETE、HEAD以及Multipart Upload。其同时支持NFS v3与NFS 4.1。

在利用Snowball Edge作为文件存储网关并通过NFS进行访问时,文件与目录元数据(包括对应权限、所有关系以及时间戳)都将被映射至S3元数据,并在数据被存储至S3内时得以保留。大家可以利用这一特性进行数据迁移、引导AWS Storage Gateway(存储网关)或者存储内部文件以在各内部应用间实现共享。

Lambda支持的本地处理

大家现在可以利用Python编写AWS Lambda函数并利用其处理通过Snowball Edge上传至S3存储桶内的数据。

这些函数能够(正如之前所提到)在数据到达时对其进行过滤、清理、分析、整理、追踪以及总结。Snowball Edge允许大家向数据收集及数据处理系统当中添加智能化与高复杂度功能。

我们初步支持S3 PUT操作,且大家可以将同一条函数应用于每个存储桶。各函数必须由Python编写,且运行在配置有128 MB内存的Lambda环境当中。

在订购Snowball Edge的同时,大家即可进行函数配置:

我们建议大家首先在云端对函数进行测试,而后再将其加入订单。

价格与上线时间

Snowball Edge在设计上允许进行即插即用式部署。您的现场同事不需要对其进行额外配置或者管理。其配备的LCD显示面板能够提供状态信息并播放设置视频。内置代码能够自动更新; 意味着其不需要进行例行软件维护。大家可以通过AWS管理控制台(亦可通过API及CLI访问)检查其状态并对已部署设备进行最新配置变化查询。

每台Snowball Edge的服务周期价格为300美元,寄送成本另计。大家保留每台设备的最长时限为10天; 在此之后,您需要每天支付30美元。大家可以以本地方式运行Lambda函数而不必承担任何费用。

原文链接:

https://aws.amazon.com/cn/blogs/aws/aws-snowball-edge-more-storage-local-endpoints-lambda-functions/

敬请期待——Amazon EC2 Elastic GPU

在之前的文章中,我们曾经探讨过基于GPU的通用计算所带来的优势,而最近P2实例更是升级到可以搭载16 块GPU。正如之前所提到,GPU能够提供极为强大的处理能力与资源规模,同时可有效降低您时间及整体计算成本。

今天,我很高兴向大家公布一项我们正在努力开发的全新GPU功能。大家将能够很快向现有的各种EC2实例类型中加入图形加速机制。在使用G2或者P2实例时,实例的具体规模将决定其中包含的GPU数量。虽然这种方式适用于多数应用类型,但我们认为,同样存在大量需要配合更新且更为灵活的GPU使用模式的应用实例。

Amazon EC2 Elastic GPU

即将推出的Amazon EC2 Elastic GPU允许大家充分发挥这两类优势。大家可以选择最适合自身应用的EC2实例类型及规模,而后在启动该实例时指定您需要使用Elastic GPU,并从以下四种选项中做出选择:

名称 GPU内存
eg1.medium 1 GiB
eg1.large 2 GiB
eg1.xlarge 4 GiB
eg1.2xlarge 8 GiB

现在,大家已经能够在启动新实例时自由创建EBS分卷。而在这项服务推出后,您将可以通过类似的方式使用Elastic GPU,即在启动过程中通过停止、修改与启动等选项指定必要的GPU资源规模——整个变更过程非常轻松。

从 OpenGL开始

我们的Amazon优化型OpenGL库将自动检测并使用Elastic GPU。作为初步方案,目前我们能够在Windows环境下支持Open GL,并计划未来为Amazon Linux AMI及其它OpenGL版本提供支持。我们还将整合对其它3D API的支持能力,具体包括DirectX以及Vulkan(如果大家对此抱有兴趣,请与我们联系)。我们还将在未来的版本中把Amazon优化型OpenGL库添加至现有微软Windows AMI当中。

OpenGL在渲染方面表现出色,但客户要如何查看渲染后的成果?问得好!选项之一是利用NICE的桌面云可视化工具将渲染内容以流媒体形式交付至任意HTML 5兼容型浏览器或者设备当中(AWS于今年早些时候收购了NICE)。支持最新版的Firefox与Chrome浏览器,以及全部智能手机与平板设备。

 

我相信这种独特的硬件与软件结合方案将适用于各类3D视觉与技术计算应用的托管用例。我们目前已经有两家客户与我们分享春反馈意见。

ANSYS公司企业解决方案与云副总裁Ray Milhem告诉我们:

ANSYS Enterprise Cloud提供一套虚拟化模拟数据中心,其专门面向AWS进行优化。该云服务提供丰富的交互式图形体验,可用于支持端到端工程技术模拟流程,帮助我们的客户交付各类创新型产品设计方案。利用Elastic GPU,ANSYS公司将能够更为轻松地以符合客户价格与性能需求的方式提供出色体验。我们已经对运行在Elastic GPU上的ANSYS应用进行了认证,旨在帮助客户更为高效地立足云环境实现创新。

西门子产品生命周期管理(简称PLM)公司NX产品管理副总裁Bob Haubrock同样给出了非常积极的反馈意见:

Elastic GPU堪称云环境下计算机辅助设计(简称CAD)的游戏规则改变者。凭借Elastic GPU的帮助,我们的客户现在能够在Amazon EC2之上配合专业级图形处理能力运行西门子PLM NX,同时充分发挥AWS提供的灵活性、安全性及全球化规模优势。西门子PLM对于NX在EC2 Elastic GPU平台上得到认证感到振奋,其将帮助我们的客户推动边界设计与工程技术创新。

新的认证程序

为了帮助软件供应商与开发者确保自身应用程序充分发挥Elastic GPU及其它基于GPU方案的全部潜能,我们今天启动了AWS Graphics Certification Program(AWS图形认证程序)。该程序旨在提供信用认证及工具选项,帮助客户以自动化方式快速在各类受支持的实例与GPU类型组合之上进行应用程序测试。

敬请期待

一如既往,我们将在这一服务正式上线后及时发布更多细节信息,敬请期待!

原文链接:https://aws.amazon.com/cn/blogs/aws/in-the-work-amazon-ec2-elastic-gpus/

 

从IaaS到FaaS—— Serverless架构的前世今生

今天大多数公司在开发应用程序并将其部署在服务器上的时候,无论是选择公有云还是私有的数据中心,都需要提前了解究竟需要多少台服务器、多大容量的存储和数据库的功能等。并需要部署运行应用程序和依赖的软件到基础设施之上。假设我们不想在这些细节上花费精力,是否有一种简单的架构模型能够满足我们这种想法?这个答案已经存在,这就是今天软件架构世界中新鲜但是很热门的一个话题——Serverless(无服务器)架构。

什么是Serverless

如同许多新的概念一样,Serverless目前还没有一个普遍公认的权威的定义。最新的一个定义是这样描述的:“无服务器架构是基于互联网的系统,其中应用开发不使用常规的服务进程。相反,它们仅依赖于第三方服务(例如AWS Lambda服务),客户端逻辑和服务托管远程过程调用的组合。”

最开始,“无服务器”架构试图帮助开发者摆脱运行后端应用程序所需的服务器设备的设置和管理工作。这项技术的目标并不是为了实现真正意义上的“无服务器”,而是指由第三方云计算供应商负责后端基础结构的维护,以服务的方式为开发者提供所需功能,例如数据库、消息,以及身份验证等。简单地说,这个架构的就是要让开发人员关注代码的运行而不需要管理任何的基础设施。程序代码被部署在诸如AWS Lambda这样的平台之上,通过事件驱动的方法去触发对函数的调用。很明显,这是一种完全针对程序员的架构技术。其技术特点包括了事件驱动的调用方式,以及有一定限制的程序运行方式,例如AWS Lambda的函数的运行时间默认为3秒到5分钟。从这种架构技术出现的两年多时间来看,这个技术已经有了非常广泛的应用,例如移动应用的后端和物联网应用等。简而言之,无服务器架构的出现不是为了取代传统的应用。然而,从具有高度灵活性的使用模式及事件驱动的特点出发,开发人员/架构师应该重视这个新的计算范例,它可以帮助我们达到减少部署、提高扩展性并减少代码后面的基础设施的维护负担。

Serverless的历史

Serverless这个概念并不容易理解。乍见之下,很容易让人混淆硬件服务器及软件上的服务与其所谓的“服务器”差别。在这里强调的所谓“无服务器”指的是我们的代码不会明确地部署在某些特定的软件或者硬件的服务器上。运行代码托管的环境是由例如AWS这样的云计算厂商所提供的。

Serverless这个词第一次被使用大约是2012年由Ken Form所写的一篇名为《Why The Future of Software and Apps is Serverless》的文章。这篇文章谈到的内容是关于持续集成及源代码控制等内容,并不是我们今天所特指的这一种架构模式。但Amazon在2014年发布的AWS Lambda让“Serverless”这一范式提高到一个全新的层面,为云中运行的应用程序提供了一种全新的系统体系结构。至此再也不需要在服务器上持续运行进程以等待HTTP请求或API调用,而是可以通过某种事件机制触发代码的执行,通常这只需要在AWS的某台服务器上配置一个简单的功能。此后Ant Stanley 在2015年7月的名为《Server are Dead…》的文章中更是围绕着AWS Lambda及刚刚发布的AWS API Gateway这两个服务解释了他心目中的Serverless,“Server are dead…they just don’t know it yet”。到了2015年10月份,在那一年的AWS re:Invent大会上,Serverless的这个概念更是反复出现在了很多场合。印象中就包括了“(ARC308)The Serverless Company Using AWS Lambda”及“(DVO209)JAWS: The Monstrously Scalable Serverless Framework”这些演讲当中。随着这个概念的进一步发酵,2016年10月在伦敦举办了第一届的Serverlessvconf。在两天时间里面,来自全世界40多位演讲嘉宾为开发者分享了关于这个领域进展。

在Serverless的世界里面,AWS扮演了一个非常重要的角色。但是AWS并不是唯一的Serverless架构服务的供应商。其他厂商,例如Google Cloud Functions、Microsoft Azure Functions、IBM OpenWhisk、Iron.io和Webtask等各种开源平台都提供了类似的服务。

Serverless与FaaS

微服务(MicroService)是软件架构领域业另一个热门的话题。如果说微服务是以专注于单一责任与功能的小型功能块为基础,利用模组化的方式组合出复杂的大型应用程序,那么我们还可以进一步认为Serverless架构可以提供一种更加“代码碎片化”的软件架构范式,我们称之为Function as a Services(FaaS)。而所谓的“函数”(Function)提供的是相比微服务更加细小的程序单元。例如,可以通过微服务代表为某个客户执行所有CRUD操作所需的代码,而FaaS中的“函数”可以代表客户所要执行的每个操作:创建、读取、更新,以及删除。当触发“创建账户”事件后,将通过AWS Lambda函数的方式执行相应的“函数”。从这一层意思来说,我们可以简单地将Serverless架构与FaaS概念等同起来。

FaaS与PaaS的比较

乍看起来,FaaS与PaaS的概念在某些方面有许多相似的地方。人们甚至认为FaaS就是另一种形式的PaaS。但是Intent Media的工程副总裁Mike Roberts有自己的不同看法:“大部分PaaS应用无法针对每个请求启动和停止整个应用程序,而FaaS平台生来就是为了实现这样的目的。”

FaaS和PaaS在运维方面最大的差异在于缩放能力。对于大部分PaaS平台,用户依然需要考虑缩放。但是对于FaaS应用,这种问题完全是透明的。就算将PaaS应用设置为自动缩放,依然无法在具体请求的层面上进行缩放,而FaaS应用在成本方面效益就高多了。AWS云架构战略副总裁Adrian Cockcroft曾经针对两者的界定给出了一个简单的方法:“如果你的PaaS能够有效地在20毫秒内启动实例并运行半秒,那么就可以称之为Serverless”。

Serverless架构的优点

  • 降低运营成本:

Serverless是非常简单的外包解决方案。它可以让您委托服务提供商管理服务器、数据库和应用程序甚至逻辑,否则您就不得不自己来维护。由于这个服务使用者的数量会非常庞大,于是就会产生规模经济效应。在降低成本上包含了两个方面,即基础设施的成本和人员(运营/开发)的成本。

  • 降低开发成本:

IaaS和PaaS存在的前提是,服务器和操作系统管理可以商品化。Serverless作为另一种服务的结果是整个应用程序组件被商品化。

  • 扩展能力:

Serverless架构一个显而易见的优点即“横向扩展是完全自动的、有弹性的、且由服务提供者所管理”。从基本的基础设施方面受益最大的好处是,您只需支付您所需要的计算能力。

  • 更简单的管理:

Serverless架构明显比其他架构更简单。更少的组件,就意味着您的管理开销会更少。

  • “绿色”的计算:

按照《福布斯》杂志的统计,在商业和企业数据中心的典型服务器仅提供5%~15%的平均最大处理能力的输出。这无疑是一种资源的巨大浪费。随着Serverless架构的出现,让服务提供商提供我们的计算能力最大限度满足实时需求。这将使我们更有效地利用计算资源。

Serverless的架构范式

移动应用后台Serverless参考架构

实时文件处理Serverless参考架构

Web应用Serverless参考架构

物联网应用后台参考架构

实时流处理Serverless参考架构

美丽新世界

技术上不可能有应用程序可以不依赖于服务器,必须要有某种硬件来支持应用程序。但是以AWS Lambda为代表的Serverless架构可以使得开发人员专注于程序功能本身,而让AWS处理与服务器部署、存储和数据库相关的所有复杂性工作。这听起来很简单,但是实现起来却并不简单。这种新的架构打破了人们的习惯思维,它让服务器不可见,并提供了一个极具成本效益的服务。Serverless架构仅有两年的历史,仍处于起步阶段。未来,这个领域还会有更大的进步,这将是非常有趣的。它给所有开发人员带来的是软件架构和应用程序部署的美丽新世界。

作者介绍:

费良宏

费良宏,AWS首席云计算技术顾问,拥有超过20年在IT行业以及软件开发领域的工作经验。在此之前他曾经任职于Microsoft、Apple等知名企业,任职架构师、技术顾问等职务,参与过多个大型软件项目的设计、开发与项目管理。目前专注于云计算以及互联网等技术领域,致力于帮助中国的开发者构建基于云计算的新一代的互联网应用。