亚马逊AWS官方博客

AWS Team

Author: AWS Team

手把手教你调校AWS PB级数据仓库

什么是一个好的数据仓库? Redshift是AWS云计算中的一个完全托管的,PB级别规模的数据仓库服务。即使在数据量非常小的时候(比如几百个GB的数据)你就可以开始使用Redshift,Redshift集群可以随着你数据的增加而不断扩容,甚至达到PB级。云计算中数据仓库的优势非常明显,不需要license,不需要预先配置非常大的数据仓库集群,扩容简单,仅仅需要为你实际所使用的数据仓库付费。 Redshift作为一个企业级数据仓库完全支持SQL语法,无学习成本,支持很多种客户端连接,包括各种市场上的BI工具,报表以及数据分析工具。 Redshift的概览 Redshift通过支持大规模并行处理(MPP),列式存储,对不同列数据使用不同数据压缩算法,关系型数据仓库(SQL),灵活的扩容管理等众多优点,兼顾了数仓性能,同时也考虑学习成本及使用成本。 Redshift系统架构及要点 图1,Redshift系统架构图 主节点负责客户端与计算节点之间的所有通讯,编译代码并负责将编译好的代码分发给各个计算节点处理,负责分配数据到不同的计算节点,主节点对客户不可见的,无需客户管理主节点的压力,更重要的是主节点免费。 计算节点是具体的干活的,并处理好的任务送给主节点进行合并后返回给客户端应用程序。每个计算节点都有自己独立的CPU,内存以及直连存储。Redshift集群规模大小通常就是指计算节点的个数以及计算节点机器类型。 节点分片是指将计算节点被分成若干的分片,根据计算节点类型不同,每个节点包含的分片数量不同,通常1个vCPU对应一个分片,ds2的机型除外。每个分片都会分配独立的内存及存储资源,接受来自主节点分配的任务。分片跟另外一个重要概念Dist Key紧密相关, 这里先提一下,接下来会具体介绍Dist Key。 排序键(Sort Key)是一个顺序键,即Redshift会根据这个键来将数据按顺序存储在硬盘上。Redshift的查询优化程序(只要理解有这么个东西存在就好,客户不需要任何维护,对客户也是透明的)也会根据这个排序来进行执行查询优化计划。这是Redshift性能调优的一个非常重要的参数。 分配键(Distribution Key)是控制加载到表的数据如何分布在各个计算节点的一个键,有好几种分布的风格,接下来会重点讲到,这是Redshift调优的非常重要的另外一个参数。 Redshift的几个常用最佳实践 选择最佳排序键 如果最近使用的数据查询频率最高,则指定时间戳列作为排序键的第一列; 如果您经常对某列进行范围筛选或相等性筛选,则指定该列作为排序键; 如果您频繁联接表,则指定联接列作为排序键和分配键; 熟悉Redshift的朋友可能知道可以指定多列作为排序键,而且排序键还有两种方式,组合式和交叉式。限于篇幅的原因,在接下来的调优测试中我们采用的是某一列作为排序键,如果有对其他排序键风格感兴趣的朋友,可以单独联系我们进行讨论。 选择最佳分配键 选择表分配方式的目的是通过在执行查询前将数据放在需要的位置来最大程度地减小重新分配步骤的影响,最好这个查询不需要二次移动数据。 分配键有三种风格,均匀分布(Even),键分布(Key),全分布(All),默认是均匀分布。 根据共同列分配事实数据表和一个维度表; 事实数据表只能有一个分配键。任何通过其他键联接的表都不能与事实数据表并置。根据联接频率和联接行的大小选择一个要并置的维度。将维度表的主键和事实数据表对应的外键指定为 DISTKEY。 根据筛选的数据集的大小选择最大的维度; 只有用于联接的行需要分配,因此需要考虑筛选后的数据集的大小,而不是表的大小。 在筛选结果集中选择基数高的列; 例如,如果您在日期列上分配了一个销售表,您可能获得非常均匀的数据分配,除非您的大多数销售都是季节性的。但是,如果您通常使用范围受限谓词进行筛选以缩小日期期间的范围,则大多数筛选行将位于有限的一组切片上并且查询工作负载将偏斜。 将一些维度表改为使用 ALL 分配; 如果一个维度表不能与事实数据表或其他重要的联接表并置,您可以通过将整个表分配到所有节点来大大提高查询性能。使用 ALL 分配会使存储空间需求成倍增长,并且会增加加载时间和维护操作,所以在选择 ALL 分配前应权衡所有因素。 优化COPY,提高数据加载速度 当你将要数据加载到Redshift的某个表时,不要让单个输入文件过大,最好是将这些输入文件切成多份,具体数量最好是跟分片数量匹配,这样可以充分利用所有分片,配合分配键能达到最佳效果。 图2,COPY输入的最优方式 让COPY选择自动压缩 作为数据仓库,Redshift通常会需要大量导入数据,这时使用做多的,效率最好的是COPY命令。在使用COPY时建议将COMPUPDATE参数设置为ON,这样数据在加载进库时是自动压缩的,好处是可以节省存储空间,提高查询的速度,不过这会增加数据加载进表的时间,这个可以根据你的业务需求,再具体衡量。 Redshift调优实战 测试结论 选择合适的排序键,分配键,及自动压缩对表的查询速度,存储效率很大提升。本次测试中,优化后查询速度有高达75%的提升,存储空间节省50%。 相同节点类型情况下,多节点性能比单节点性能提升明显。本次测试中,采用了4节点与单节点对比,4节点查询速度比单节点提升75%。 节点数量相同的情况下,dc系列节点的查询速度比ds系列节点的查询速度要快。本次测试中,采用了dc1.large和ds1.xlarge两种节点类型进行对比,dc系列节点的查询速度比ds系列快20% 。 使用JOIN与不使用JOIN查询速度无明显差别。本次测试中,三个不同的查询及对应的JOIN查询,在查询速度上的差别非常小。这部分的详细测试结果,请参见附录一。 查询速度达到一定值时,再增加节点对查询优化的效果有限。本次测试中,在相同环境中,将节点数量从8个dc1.large节点增加到12个dc1.large节点,三个查询只有一个查询的速度有一定提升,其他2个查询速度基本没有太大变化。这部分的详细测试结果,请参见附录二。 图3,调优前后性能对比图 […]

Read More

分布式神经网络框架 CaffeOnSpark在AWS上的部署过程

一、介绍 Caffe 是一个高效的神经网络计算框架,可以充分利用系统的GPU资源进行并行计算,是一个强大的工具,在图像识别、语音识别、行为分类等不同领域都得到了广泛应用。有关Caffe的更多内容请参考项目主页: http://caffe.berkeleyvision.org/ 不过Caffe的常用部署方式是单机的,这就意味着它的水平扩展能力受到了限制。使用者可以通过在系统中添加多个GPU的方式提高并发度,不过其并发能力最终受到单系统可支撑的GPU数量的限制。同时,神经网络计算往往又是计算消耗很大的,所以人们在使用Caffe的时候都可能会希望有一种并行计算框架可以支持Caffe。 而我们知道Spark是基于内存的计算框架,基于Yarn, Mesos或者是Standalone模式,它可以充分利用多实例计算资源。因此,如果能够结合Caffe和Spark,Caffe的能力将得到更充分的发挥。 基于这些原因,Yahoo开源的CaffeOnSpark框架受到的极大的关注。 有关CaffeOnSpark的源代码和相关文档,请大家参考: https://github.com/yahoo/CaffeOnSpark 今天我们要进一步讨论的是如何在AWS EC2上部署CaffeOnSpark, 充分利用AWS服务提供的GPU实例构建强大的分布式神经网络计算框架。 在CaffeOnSpark的文档中有明确指出EC2上部署CaffeOnSpark的步骤,具体请参考: https://github.com/yahoo/CaffeOnSpark/wiki/GetStarted_EC2 但是文档的一些部分写得比较简单,初步接触的读者可能在执行过程中遇到一些问题,所以在这里将我个人的安装配置过程整理了一下供大家参考。 安装过程大概可以分为四部分: 下面会在“环境准备”一节中具体描述这几个步骤的细节。 二、环境准备 首先我们打开文档https://github.com/yahoo/CaffeOnSpark/wiki/GetStarted_EC2, 看看文档中刚开始的部分对于环境准备的要求。 里面首先提到我们需要准备“EC2 Key pair”, 就是要准备EC2启动需要的密钥对。当然,为了创建“EC2 Key pair”,为了启动EC2,你首先需要一个AWS账号。有关AWS账号的申请和基本使用这里就不细述了,请参考其它相关文档。需要注意的是你拿到的AWS账号需要有基本的权限才能完成CaffeOnSpark的安装工作,其中包括创建EC2实例,创建安全组等。 “EC2 Key pair”是你在创建EC2实例时创建的密钥对,创建过程中你有一次机会下载私钥文件,就是文中提到的pem文件。如果你之前没有创建过EC2,你也可以直接在EC2控制台的“网络与安全->密钥对”界面中点击“创建密钥对”按钮进行创建。同样,创建过程中你有一次机会下载pem文件,下载后注意保管好该文件,后面都会依赖这个文件。 按文档的描述,有了以上的资源以后就可以执行以下命令: 为了准备环境,我们需要先理解一下上面的脚本。脚本的刚开始部分是一系列变量的定义,我们先了解这些变量的作用。 第一句比较简单,从变量名可以知道这是指定了要使用的AMI的ID: 这个镜像是一个已经安装好Spark、CaffeOnSpark,并加载了常用神经网络测试数据的Ubuntu镜像。该镜像由CaffeOnSpark团队提供,已经共享给所有AWS账号。 不过稍有AWS使用经验的同学会意识到,这样的命令是针对特定的区域(Region)的,因为同一个AMI镜像拷贝到不同AWS区域时它们的AMI ID是不一样的。在命令行中如果指定了一个AMI的ID,就意味着这些命令只能在特定的AWS区域正常工作。 所以我们需要继续查看后续命令,看看哪里指定了区域。幸运的是,命令的第二行就是指定区域的命令: 我们知道区域代码“eu-west-1”指的是欧洲(爱尔兰) 区域,意味着我们运行完这个样例后我们的CaffeOnSpark群集是运行在欧洲(爱尔兰) 区域的。因为EC2 key pair也是按区域分的,所以我们创建的EC2 key pair也应该是在欧洲(爱尔兰) 区域。 为了在欧洲(爱尔兰) 区域创建你的EC2 key pair,你可以点击AWS控制台右上角的区域选择框,选择欧洲(爱尔兰) 区域,然后再按步骤进入EC2的控制台创建EC2 key pair. 同时,你也可以去EC2控制台的“映像->AMI”界面查找镜像ID为ami-5ff7782c的镜像,记得查看时选择“映像类型”为“公有映像”,而不是“我拥有的”。找到这个镜像你还可以仔细查看一下其它相关信息。 如果你发现镜像列表中没有ID为ami-5ff7782c的镜像,有可能你阅读本文的时候相关方已经更新了新的镜像,你可以去CaffeOnSpark的主页 https://github.com/yahoo/CaffeOnSpark […]

Read More

打造DIY版Echo:树莓派+ Alexa 语音服务

关于本文 本文详细阐述了如何在Java客户端和Node.js服务器上使用和测试Alexa语音服务。 本实例需要用Node.Js来获取Login的授权码。 本指导提供详细的操作指南对于在取得示例授权码、依赖性和在运行Pi的过程中相应的硬件部署。对于Windows, Mac,或者通用的Linux指令,可以看这里的向导。 开始 所需硬件 1. Raspberry Pi 2 (Model B) –在亚马逊上购买。升级:当然,Raspberry 3也是可以的,请点击这里查看详细操作。Pi的用户-请点击这里来获取帮助。 2. 微型的-USB 电源线 供树莓派来使用(包括在树莓Pi中) 3. 微型的 SD 卡– 需要预装NOOBS – Raspberry Pi 8GB Preloaded (NOOBS) Micro SD Card 4. 网线 5. USB 2.0 小型麦克风 – Raspberry Pi 没有自带麦克风,需要外接来与Alexa进行交互-在亚马逊上购买 6. 外部扬声器3.5mm音频插座/立体声耳机插孔-在亚马逊上购买 7. 一个 USB 鼠标和键盘,以及一个支持HDMI的外部显示器 – 如果由于某种原因无法通过SSH协议进入到你的树莓派时,我们也推荐你使用USB键盘、鼠标和一个便于使用的HDMI显示器。稍后可以查看关于“SSH”协议的内容。 8. 无线WiFi适配器(可选)在亚马逊上购买 所需技能 1. […]

Read More

将VMware 中的Ubuntu 12.04 映像导入成Amazon EC2 AMI

(本操作文档部分叙述内容与技术知识引用自AWS官方网站) 要在 Amazon EC2 中使用您的 VM,您必须首先将其从虚拟化环境中导出,然后使用 AWS Command Line Interface (AWS CLI) 或 API 工具将其导入 Amazon EC2。(AWS Console不支持从VM导入AWS的操作功能。) 从总体上看,要将VM导入到Amazon EC2中,需要经过以下五个步骤: 1. 安装 AWS CLI。 2. 为 VM 导入 Amazon EC2 做准备。 3. 从虚拟化环境中导出 VM。 4. 将 VM 导入 Amazon EC2。 5. 在 Amazon EC2 中启动实例。 本次实验使用VMware Workstation 10,把Ubuntu原生镜像ubuntu-12.04.5-desktop-amd64.iso导入到VMware Workstation 10。自行个性化操作后,利用VMware Workstation 10导出OVF映像的功能,获得VM的vmdk文件。并用AWS CLI,以流优化型 ESX 虚拟机磁盘 […]

Read More

使用Docker封装IPSec安全网关

随着云成为新常态,越来越多的客户开始采用AWS云服务,使用VPN隧道安全的连接到AWS成为一个常见的场景。本文介绍一种仅需少量交互与配置即可与多个AWS VPC建立动态路由VPN连接并在各个互联VPC之间转发流量的方案。该方案主要使用了Docker、IPSec套件strongSwan、动态路由软件BIRD,并在此基础上,使用AWS SDK for Python( Boto 3)、docker-py等实现快速建立与AWS VPC的动态VPN。 项目中使用的Dockerfile、相关的shell脚本以及Python应用等源文件均已经在这里开放,做为一种快速部署Customer Gateway的方法,供各位读者参考。 本文假定读者从概念上理解AWS VPC、IPSec VPN以及动态路由协议BGP。如果希望了解更多如何与AWS VPC建立VPN连接的信息,读者可以参考 AWS VPC 网络管理员指南。 如何使用 我们从最基本的场景开始,假定您需要将本地网络与单个AWS VPC通过IPSec隧道互联。 图中Customer Gateway应为一台可以访问Internet且IP固定的 Linux服务器, 这台服务器将作为IPSec网关和BGP路由器,将内部网络与AWS VPC通过IPSec隧道和BGP动态路由协议连接起来。 在Customer Gateway上执行如下预备工作: 一、我们需要 预先安装和配置好docker引擎; 二、我们的脚本使用了Python和一些第三方库,所以需要安装Python 2.7或更新版本以及Python包管理工具,例如pip 三、通过pip安装如下软件包; a. boto3 —— AWS SDK for Python,用于获取VPN连接的配置信息 b. xmltodict —— 便于python处理XML格式的数据 c. docker-py —— 用于连接docker engine并创建、运行容器 四、配置boto3连接AWS的 IAM凭证,需要注意使用的IAM用户需要拥有执行describe_vpn_connections API所需的权限。 $ cat  ~/.aws/credentials [default] […]

Read More

如何使用AWS Auto-reboot和Auto-recovery进一步提升单机高可用

根据AWS的推荐设计原则,搭建一个云端应用系统时,需要记住的一个原则是“design for failure”,也就是系统架构设计的时候需要考虑到应用系统的每一个层面,包括硬件和软件是可能出现故障的,并据此在应用系统架构设计上消除单一故障点,从而实现高可用性的系统架构。 有些应用由于历史或其他原因,没有按照这个原则设计高可用的架构,因此在部署上存在单一故障点,比如某一台EC2实例的软件或者底层硬件出现故障的时候会影响到这部分应用。如何保证或者大大提高单机EC2的可用性是非常重要的问题。 针对这些用户的需求,AWS推出了两个非常有用的监控功能:自动重启(auto reboot)EC2实例的CloudWatch警报和自动恢复(auto recovery)EC2实例的CloudWatch警报。这两个警报能够在你设定的阀值内自动重启因为实例故障或者底层硬件故障的EC2实例,最快时间恢复实例健康,从而大大降低了down机时间,让应用系统快速从软件或者底层的软硬件故障中自动地恢复,大幅度提升应用的整体可用性。具体介绍如下: 自动恢复EC2实例的CloudWatch警报 任何物理机都可能发生故障,云端的物理主机也不例外。使用AWS云平台,当底层硬件发生故障时,你无需人工干预或者联系AWS的支持工程师帮助您处理并恢复实例,通过事先创建CloudWatch 的StatusCheckFailed_System(状态检查失败(系统))警报监控 EC2 实例,在实例运行的物理主机发生底层硬件故障的时候能够自动触发警报,一方面根据配置发送通知给贵司相关人员,另一方面以最快时间将实例迁移到健康的物理硬件上,并保持实例 ID、私有 IP 地址、弹性 IP 地址以及所有实例元数据不变。 自动恢复实例的Cloudwatch警报有以下要求: ·       仅支持C3、C4、M3、R3 和 T2 实例类型 ·       仅支持VPC 中的实例,不支持EC2-Classic 实例 ·       仅支持完全使用EBS 存储的实例,不支持使用任何实例存储卷的实例 自动重启EC2实例的CloudWatch警报 以前当您遇到由于实例内部的软件故障导致实例无法正常访问时,你只能选择手动重启实例让实例从故障中恢复,这个过程由于需要人工的干预,可能导致较长时间的实例不可访问。现在,您可以创建Cloudwatch的StatusCheckFailed_Instance(状态检查失败(实例))警报监控 EC2 实例,并在实例运行状况检查失败时自动重启此实例,从而实现在短短几分钟时间内即可重启您的实例并恢复实例。重启实例时,其仍驻留在相同的物理主机上,因此您的实例将保留其公有 DNS 名称、私有 IP 地址及其实例存储卷上的任何数据。 如何配置 为了大幅度提升单机的高可用性,建议您在一个实例上同时配置上述两种Cloudwatch警报,以监控软硬件故障并自动恢复实例。配置的时候需要注意的一点是:使用IAM user创建两个警报,其中自动重启EC2实例的警报的检测周期必须要大于自动恢复实例的警报的检测周期,比如下面例子中,自动重启EC2实例的检测周期是3,自动恢复EC2实例的检测周期是2。 自动重启EC2实例的警报的示例(StatusCheckFailed_Instance): 自动恢复EC2实例的警报的示例(StatusCheckFailed_System):   更多信息请参考 http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/DeveloperGuide/UsingAlarmActions.html#AddingRecoverActions http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/DeveloperGuide/UsingAlarmActions.html#AddingRebootActions  

Read More

AWS CTO对过去十年的经验总结 – 十条军规

作者 Werner Vogels 发布于 2016年3月14日 10 Lessons from 10 Years of Amazon Web Services AWS(Amazon Web Service) 开始于 2006 年 3 月 14 日 Amazon S3 的发布,距今已有十年时间。回首过去十年,我们在构建和运营 AWS 云计算服务中积累了大量的经验教训——这些服务不仅需要确保安全性、可用性和可扩展性,同时还要以尽可能低廉的成本提供可预测的性能。考虑到 AWS 是世界范围内构建和运营此类服务的开拓者,这些经验教训对我们的业务来说至关重要。正如我们多次重申的,“经验不存在压缩算法”。考虑到 AWS拥有每月超过一百万的活跃用户,而这些用户也许会为数以亿计的自家客户提供服务。因此,积累上述经验教训的机会在 AWS 比比皆是, 在这些经验教训中,我挑选了一些分享给大家,希望对各位也能有所帮助。 1.构建可持续演进的系统 从做 AWS 的第一天开始,我们就清楚地认识到,我们在做的这套软件不是一劳永逸的。现在可以用的软件,一年之后很可能将不再适用。我们的预期是,随着(用户)数量级的增加一或两次,我们都需要重新检视和适当修改我们已有的架构,以便解决扩展性的问题。 但是我们无法采取过去常用的通过检修停机进行系统升级的方式来实现上述目标,因为世界各地诸多业务都依赖着我们平台所提供的7 x 24 小时的可用性。因此,我们需要构建一个在引入新的软件构件时不会引起服务瘫痪的架构。Amazon 杰出的工程师 Marvin Theimer 有一次开玩笑说,Amazon S3 这项服务的持续演进用开飞机来形容最为贴切。我们最开始开的是一架单引擎的赛斯纳,一段时间后升级成一架波音 737,之后又换成了一支波音 747 小队,而现在更像是由空中巨无霸空客 A380 组成的一支大型机队。自始至终,我们一边通过空中加油确保飞机的正常飞行,一边在万米高空上将 AWS […]

Read More

AWS的十年创新之路

2006年3月14日,计算时代的新纪元由此拉开帷幕。就在这一天,Amazon Web Services发布了Simple Storage Service(简称S3)。从技术角度讲,Simple Queuing Services的发布时间更早一些,但S3的发布真正点燃了这场云计算的燎原烈火。我对那一天仍然记忆犹新。当时我在Frontbridge Technologies公司担任总经理,这是一家由微软全资掌控的子公司,负责提供云托管邮件反垃圾、反恶意与归档服务。结合这番经历,我意识到云托管服务能够为客户带来的可观价值。我也意识到,客户热爱如此高效的配置方式与如此多样的低成本实现途径——这一切让我的态度发生了转变。那时的我得出了肯定的结论,云托管将成为未来的新方向。 不过Amazon Simple Storage Service的发布仍然令我感到大开眼界。当时技术行业每天都会发布上百项方案,其中大部分完全引不起我的兴趣——甚至连看一眼的愿望都没有。然而S3的发布则彻底改变了游戏规则。这项服务的最大亮点在于低廉到夸张的成本水平。其使用成本几乎比我们目前多数据中心冗余存储体系低出两个数量级。但更具颠覆性的是,用户可以利用手中的信用卡完成存储资源购买与配置。没有财务审批、没有专家建议、没有RFP、没有厂商选择流程、没有厂商谈判也没有数据中心空间核算。直接登录,着手使用——就这么简单! 除了低廉的成本与便捷的配置方式之外,更让我意外的是这一技术成果的发布由Amazon——而非传统企业IT厂商——来完成。那些急于追求高利润、总会设置复杂谈判并喜欢在许可使用审计上做文章的厂商没能拿出这样的成果,而Amazon做到了。而这种令大多数企业IT部门欢呼雀跃的即时管理能力则让Amazon以不胜而胜的方式获得了可观的利润。这真的颠覆了我的认知——一家具有颠覆性的厂商、一种具有颠覆性的模式、一种低冲突配置途径外加一种起价极低并随时间推移而变得更低的价格设定。 S3的发布引发了整个技术行业的关注与惊叹——即使是那些发货量极大、且不会因此遭受任何营收损失的厂商。我被这款产品彻底迷住了,并最终编写了数千行代码以将S3作为底层存储系统。有时候S3显得比较笨拙,有时候则锐不可当,但为其编写应用让我坚定了自己的观点——这将成为其它更伟大事物的开端。 从决定编写应用到将该应用付诸运行共花掉了我几天时间,其中还包括调试与测试工作——当月末我收到了自己的Visa卡账单。我一直都清楚S3的价格非常便宜,但最终发现应用程序的整个开发与测试过程只花掉了3.08美元,这样的结果还是让我难以置信。在开发结束之后,我立刻将全部测试数据保存在了S3当中,而第二个月的账单来了——承惠0.07美元。 面对如此颠覆性的服务方案,我开始在企业内部发布评述博文并将其展示给包括CTO与CEO在内的众多高管人员。我在表达中还使用了一张Al Vermeulen——S3上的一名早期开发者——照片,外加一些S3的工作原理并阐述了其差异性所在——当然,还有我拿到的两张AWS账单。我的表达重点在于,这绝不是Amazon公司搞出的什么噱头或者小实验,而是真正实现基础设施服务交付的根本性新途径。存储只是第一步,计算也一定会很快跟进。 我对AWS的兴趣与时俱进,并在2007年参加了一次Amazon组织的用户会议——我最终于2008年正式加入了其技术团队。 作为AWS工程技术团队的一员,新环境给我留下的第一印象就是一个“快”字——决策制定流程非常迅速,新思路能够很快以代码形式推出,并立刻被交付至客户手中。这一切都让传统企业IT的响应速度看起来像是大陆板块漂移。我记得自己曾经半开玩笑地回忆过往角色称:“我们在十年中只发布了两次客户可能需要、也可能不需要的更新。”现在新功能正以惊人的频率推出,我们甚至很难追踪其推进节奏。 AWS的另一种有趣特质在于对产品及工程技术相关争论的处理方式。这类争议会频繁出现,而且AWS内部的辩论之声要远超过任何其它企业。这些决策的制定流程让我意识到,AWS除了拥有卓越的数据处理能力外,亦能够快速中止争论并拿出结论性意见。在AWS,我们不再自以为是地制定“战略”并强行说服客户认同其适用性,而是推出适合自身业务环境的方案,并通过面向服务的快速投入帮助更多客户快速享受至由其带来的便利。如此一来,优秀的服务能够快速演进为卓越的服务。 在过去的一系列角色中,我发现争论带来的思维碰撞根本无法切实转化为成果,甚至在多年之后仍然毫无动静。但在AWS,各部门几天之内就能够解析客户使用量数据并迅速将注意力转移到执行层面。相较于过往的缓慢节奏,这样的进度确实让人耳目一新。AWS的大部分工作成果最终被交付至客户手中,而不像我过去的工作那样将大部分精力耗费在解决内部矛盾上。这种出色的交付速度让AWS客户尽享优势,同时也为工程师带来了充满激情的梦幻般工作环境。 客户的认同正是创新成果的绝佳验证,而且毫无疑问,客户表现出的最大信任就是将全部业务迁移至云基础设施当中。Netflix成为第一家决定将100%业务负载交由云环境打理的企业。以下是一些已经全面登陆云端的客户:   2010年,Netflix   2013年,凯宾斯基酒店   2013年,Suncorp Group   2014年,Infor   2014年,日本通运   2014年,美国圣母大学   2014年,美国全国民主学会(NDI)   2015年,英国卫报媒体集团 从个人角度来看,企业客户决定全面拥抱云服务作为自身惟一基础设施已经成为整个技术行业最令人兴奋也最引人注目的实例。不过作为AWS创新速度的另一种实例,请大家跟随我的脚步纵观其在过去十年中掀起的一波又一波变革浪潮。 原文链接:http://perspectives.mvdirona.com/2016/03/a-decade-of-innovation/

Read More

为AWS北京区管理控制台集成ADFS访问

原英文链接:http://blogs.aws.amazon.com/security/post/Tx71TWXXJ3UI14 在我们使用AWS的过程中, AWS IAM 是我们接触的第一个服务, 它具有强大的功能,可使您在AWS IAM中通过管理用户, 用户组, 策略, 角色, 证书, 密钥等来灵活而精确的控制对AWS 服务和资源的访问和权限. 同时在很多企业内部, 一般都已经部署了自己的用户管理及授权系统, 如何将AWS的用户管理及授权纳入现有系统则成为企业的想要解决的一个问题. 本文将介绍如何将企业内部Windows活动目录(Active Directory)和AWS通过ADFS(Active Directory Service) 进行集成, 从而实现在活动目录中管理用户对AWS服务和资源的访问和授权. 在AWS IAM中, 我们提供了对SAML的支持, 这个功能可以让我们可以和支持该标准的身份提供商进行联合从而实现单点登陆. 对于很多使用微软活动目录的企业, 我们可以使用Windows自带的ADFS进行和AWS IAM的集成. 工作原理: 在我们进行详细配置之前, 可以先看一下工作原理: 1.       首先用户访问和AWS做了集成的ADFS站点 (https://ADFS/adfs/ls/IdpInitiatedSignOn.aspx) 2.       用户在登陆页面输入用户名及密码, 提交以后ADFS将联系AD进行用户验证 3.       用户浏览器收到ADFS返回的SAML 断言 4.       用户浏览器将用户断言Post到AWS的Sign-in SAML终结点 (https://signin.amazonaws.cn/saml), Sign-in将调用AssumeRoleWithSAML API接口请求临时安全凭证并使用其构建管理控制台的登陆链接 5.       用户浏览器转向使用构建的登陆链接进行登陆 配置活动目录: 1.       在活动目录中及建立用户adfsuser, 邮件地址设为adfsuser@examplecom 2.       在活动目录中建立两个组AWSBJS-Admin, […]

Read More

媒体洞察 | 让企业自由发展的云时代

2016-03-15 AWS 缺乏敏捷性并且行动速度滞后的企业在当今社会是难以具有竞争力的,看看那些初创公司对那些存在已久的行业都做了什么便知道了。 随着云计算的快速发展及概念的普及,云计算已经成为各类型企业发展的新常态。目前,世界上已经有许多家企业正快速地将自身应用向云端迁移,以此实现更加自由的创新和发展。这些企业不仅包括初创公司(例如 Dropbox、Airbnb、Pinterest、Hailo、WeTransfer),还包括许多成熟的大企业(例如壳牌、强生、通用电气、飞利浦、Netflix 和三星)。 与此同时,我们看到了大量的中国企业也正通过云计算的应用加速了发展的步伐。比如,小米正通过云计算服务开拓全球范围的智能手机用户;远景能源通过云计算管理着世界各地的智能风场;猎豹移动通过云计算为全球的用户提供手机安全的保障。 如今,云计算为企业提供了充分的平台空间和技术支持,让企业更为自由地发展成为可能。 打破传统的IT 部署 云计算可以让企业自由地构建和使用 IT 基础设施。在现如今的市场环境中,这已然成为了企业的发展基础。具体而言,云计算能够让企业自由灵活地使用IT 基础设施,以此在一定程度上让企业实现无限制的自由发展。 对于这些企业而言,若要开发面向用户或客户的完美体验及服务,来自云基础设施提供商的强大支持是必不可少的。而且,构建灵活的IT 基础设施需要两个关键因素——快速提供广泛、稳健的技术平台并且让其“唾手可得”。 云计算能够使这些企业拥有此类新能力,并且能够借助广泛而有深度的服务平台快速部署自身的 IT 资源。 因此,灵活的云基础设施不仅让企业行动的更快,而且能够为其消除所面临的诸多障碍。 例如AWS 可以在几分钟内为用户配置数千台服务器,可以在全球范围内为用户提供由多个数据中心支持的高可用性服务,可以在一个统一的平台上提供用户所需的功能和服务。同时,AWS 提供的不仅仅是大量的产品,而是深度的功能,满足用户对计算、存储、加密、数据库、访问控制等多方面的需求。让用户在使用云资源时更自由灵活。 每个人都是技术专家 在云问世之前,企业因成本过高而无法保存它们想要保留的全部数据。现在,云计算可以实现数据采集、存储、分析和共享,让企业享受到从未有过的方便和实惠。此外,目前企业内部真正能做分析的人的数量是很少的,通常只有那些技术人员才可以享受这些数据分析服务。但是,企业或客户也希望非技术人员能够以不太昂贵且便于操控的方式更快地了解数据现状,快速获得他们可转化为行动的洞察力。 通过云计算服务,非技术人员同样具备了数据分析“能力”,他们甚至能够利用移动设备分析数据。利用云平台服务,企业还可以享受关于数据的云自由,从大量数据中获取实际价值、然后将分析数据结果用于进一步的发展。自从使用云计算以来,企业已在数据分析上变得非常自由,正在以基于数据的方式有效地从事多种类型的开发和研究。 如Amazon QuickSight 就完全不同于旧式的解决方案,工程师再也不需要在首次可视化之前花费数周、甚至数月做数据建模了。其提供的可视化数据服务,其能够捕获图形、表格或故事,并可实现数据在内部或外部分享。 在云间自由穿梭 大约在2015 年,我们开始看到企业支持新用例(例如流传输数据)的需求:在我们的家中、工作场所、甚至在油田等场所有数百万个设备,它们连续传输数据——有时达到每小时数TB。借助云计算服务,处理起这些数据来比以往容易得多。 由于云计算的发展,企业的数据可在云间“自由穿梭”。但是,许多企业想通过更简单的方式将流数据载入云。 云服务可以有弹性地扩展支持大量的数据,让企业以时段或块大小连接数据,让企业能够利用标准的方法压缩数据。如果企业愿意,它们还可以选择在入站时加密数据并在使用时解密,方便地存储和轮换密钥。 摆脱数据迁徙的限制 向开源数据库迁移是企业追求更佳性能和更大灵活性的结果。然而,从专有数据库向开源数据库迁移不太容易。正如我们许多客户所证实的那样,云计算已彻底改变技术提供商和客户之间的关系。因此,企业可以摒弃专有数据库并自由地选择新数据库。 专有数据库的解决方案非常昂贵,它们具有专有属性并且拥有大量的锁定。这些数据库的供应商会核查客户,一旦发现任何不合规的应用方式,便会处罚客户。这也是许多客户想尽快摆脱专有数据库的原因。 但是借助这些开源数据库就想获得最佳性能是非常困难的。AWS 发布的新数据库引擎 Amazon Aurora,以开源数据库的价格向客户提供能够与商业级数据库相媲美的性能。从 2015 年7 月正式上市以来,Amazon Aurora 已经成为Expedia、通用电气、太平洋燃气电力公司 (PG&E) 和NBC 环球等企业使用的云服务。 不惧差异化的数据迁移 基于业务差异化,每家企业通常会选择不同的解决方案迁移数据入云。在云计算服务的支持下,用户可以以非常短的停机时间向开源数据库迁移较大规模的生产数据。企业也可以从源向云端新目标连续复制数据,并通过实时监控跟踪进度。这样就使得原本要花很长时间的迁移设置变得更迅速、更节约成本。 AWS 对多样化迁移方案的广泛支持使得其有能力帮助通用电气(GE) 在未来:从分散独立的数据中心向 AWS 迁移 9000 多个工作负载,包括 […]

Read More