亚马逊AWS官方博客

Tag: 大咖专栏

挖掘EB级别数据的价值 – Redshift Spectrum介绍及最佳实践

随着数据存储技术的快速发展,众多企业客户可以以低成本存储PB级别甚者EB级别的数据。这使得大数据分析在近几年来不但成为现实而且愈发火热。然而真正实现海量数据的分析既要有存储海量数据的资源,又要有足够强大的分析能力。近年来我们看到数据分析能力的发展并没有追赶上存储技术的发展速度 。现实中企业客户虽然有了可以收集并存储大量数据的能力,但很多数据并不能被有效的分析甚至根本未作任何分析,形成了所谓的暗数据。这使得数据分析能力成为实现大数据分析的真正瓶颈。 作为一个托管的数据仓库服务,Amazon Redshift从它发布至今已经帮助全球成千上万的客户解决了PB级别数据的分析能力,实现了复杂SQL的快速查询。但随着数据的飞速增长,我们看到越来越多的客户数据开始逼近EB级别。对于这样体量的大数据,虽然Redshift也可以支持快速的复杂SQL查询,但毕竟我们需要启动更多的Redshift集群,消耗更多的CPU和存储成本,同时还要付出更多的数据加载时间。相反如果我们为了节省资源和成本把数据放在S3上,通过EMR集群也可以实现快速低成本的数据清理,但针对复杂的(诸如Join类)的查询速度会很慢,不能很好支持。这形成了一个鱼与熊掌不可兼得的选择题。 为了真正摆脱数据分析的瓶颈、消灭暗数据,我们的客户需要既能高效执行复杂的查询,又能享受高度可扩展的数据并行处理,也能利用近乎无限的低成本的S3存储资源,还要可以支持多种常用的数据格式。满足这种”既又也还”的任性就是我们的新服务Redshift Spectrum的使命。 Redshift Spectrum 介绍 Redshift Spectrum可以帮助客户通过Redshift直接查询S3中的数据。如同Amazon EMR,通过Redshift Spectrum客户可以方便的使用多种开放数据格式并享有低廉的存储成本,同时还可以轻松扩展到上千个计算节点实现数据的提取、筛选、投影、聚合、group、排序等等操作。Redshift Spectrum采用了无服务器架构,所以客户不需要额外配置或管理任何资源,而只需为Redshift Spectrum的用量付费。使用方面,Redshift Spectrum享有和Amazon Redshift一样的复杂查询的优化机制、本地数据的快速读取以及对标准SQL的支持。结合上述功能特点,Redshift Spectrum可以在几分钟内完成对EB级别的数据的复杂查询,这使它在众多大数据分析服务中脱颖而出。我们做了一个实验,在对一个EB的数据做涉及四个表的join,filter和group的查询时,1000个节点的Hive集群预估需要耗时5年,而Redshift Spectrum只用了173秒。 另外Redshift Spectrum 是Amazon Redshift的一个内置功能,所以使用Redshift Spectrum 对Redshift客户现有的查询服务和BI工具不会有任何影响。在Redshift Spectrum的底层,我们负责管理着成千上万的跨多个可用区的计算节点。这些节点根据客户查询任务的复杂度和数据量实现透明的扩展和分配,前端的客户无需做任何资源部署和配置。Redshift Spectrum也很好的支持了高并发 – 客户可以通过任何多个Amazon Redshift集群同时访问S3上的数据。 Redshift Spectrum 上一个查询任务的生命周期 一切从Redshift Spectrum的查询任务提交给Amazon Redshift集群的领导节点开始。首先,领导节点负责优化、编译、并推送查询任务给Amazon Redshift集群的计算节点。然后,计算节点从外部表获得数据目录,并基于查询任务里的join和filter动态移除不相关的数据分区。这些计算节点同时也会检测在Redshift本地是否已有部分查询数据,从而只从S3上扫描本地没有的数据以提升效率。 接下来,Amazon Redshift的计算节点会基于需要处理的数据对象生成多个查询需求,并行提交给Redshift Spectrum,Redshift Spectrum再据此启动上千个工作线程。 这些工作线程进一步从S3上扫描、筛选并聚合数据,将处理好的结果数据传回Amazon Redshift集群。最后,传回的结果数据在Redshift 集群本地作join和merge操作,然后将最终结果返回给客户。 Redshift Spectrum 的优势 Redshift Spectrum的架构设计有很多优势。第一,剥离计算与S3上的存储,使计算资源可以独立弹性扩展。第二,大幅提升了并发效率,因为客户可以用多个Redshift集群访问同一组S3上的数据。第三,Redshift Spectrum沿用了Amazon Redshift的查询优化机制,可以生成高效的查询规划,即便面对诸如多表join或者带统计函数(window function)的复杂查询也能胜任。第四,可以对多种格式的数据源直接查询 – Parquet, RCFile, […]

Read More

动态DevOps环境中的IT治理

译者:殷实,AWS专业服务咨询顾问 |原文链接 动态DevOps环境中的IT治理 治理涵盖安全和生产力运营的协调,其目的是确保公司实现业务目标。 正在迁移到云端的客户可能处于实现治理的各个阶段。 每个阶段都有自己的挑战。 在这篇博文中(系列中的第一篇文章),我将讨论四步走的方法来自动化AWS服务的治理。 治理和DevOps环境 具有DevOps和敏捷思维的开发人员负责构建和运营服务。他们经常依靠中央安全小组制定和实施安全策略,寻求安全审查和批准,或实施最佳实践。 这些安全策略和规则并没有得到安全小组的严格执行。它们被视为开发人员为获得更多的使用AWS的灵活性而遵循的准则。然而,由于时间限制或重视度不足,开发人员可能并不总是遵循最佳实践和标准。如果这些最佳实践和规则得到严格执行,安全小组就可能成为瓶颈。 对于迁移到AWS的客户,这篇博文中描述的自动化治理机制将为开发人员保留灵活性,同时为安全团队提供控制。 在动态开发环境中,以下是一些常见的挑战: 通过捷径完成任务,例如将安全凭证硬编码在代码中。 成本管理,例如控制启动的实例的类型。 知识传递。 手动流程。 治理步骤 四步走的自动化治理方法: 在治理开始的时候,你需要实施一些(1)高风险操作的控制。在控制就绪后,你需要(2)监控你的环境,以确保你正确地配置了资源。监控将帮助你发现想要(3)尽快修复的问题。你还将需要定期地生成一份(4)审核报告,以展示所有内容都符合要求。 这篇博文中的例子协助阐明了四步走的自动化治理方法:中央IT团队允许其Big Data团队运行一个基于Amazon EMR集群的测试环境。该团队在100个t2.medium实例运行EMR任务,但是当一个团队成员使用100个r3.8xlarge实例来更快地完成任务时,业务会产生意外的费用。 中央IT团队关心治理,采取一些措施来防止这种情况再次发生: 控制要素:团队使用CloudFormation来限制实例的数量和类型,并使用AWS身份和访问管理来允许只有某个组可以修改EMR集群。 监控要素:团队使用AWS标记,AWS Config和AWS Trusted Advisor来监控EMR实例限制,并确定是否有人超额使用了被允许的实例数。 修复:团队创建一个自定义的AWS Config规则来终止那些不是指定类型的EMR实例。 审核:团队在AWS Config中审查EMR实例的生命周期。 控制 你可以通过标准化配置(通过AWS CloudFormation),限制配置的选项(通过AWS服务目录)和控制权限(通过IAM)来防范错误。 AWS CloudFormation可以帮助你在单个软件包中控制工作流环境。 在这个示例中,我们使用CloudFormation模板来限制实例的数量和类型,使用AWS标记来控制环境。 例如,团队可以通过使用限制了实例类型和数量的CloudFormation来阻止选择r3.8xlarge实例类型的选用。 CloudForamtion模板示例 包含标记的EMR集群 { “Type” : “AWS::EMR::Cluster”, “Properties” : { “AdditionalInfo” : JSON object, “Applications” : [ […]

Read More

在AWS上部署SAP HANA – 您的选项是什么?

作者:Sabari Radhakrishnan, Amazon Web Services(AWS)的合作伙伴解决方案架构师 译者:戴俊, Amazon Web Services(AWS)的专业服务团队SAP顾问 | 原文链接 您是否计划将SAP应用程序迁移到SAP HANA平台或使用SAP HANA启动新的实施? 如果是这样,您可能会想知道Amazon Web Services(AWS)提供什么选项来运行SAP HANA工作负载。 在这篇博文中,我想讨论SAP HANA所需的核心基础架构组件以及AWS提供的构建模块,以帮助您构建AWS上的SAP HANA虚拟设备。 我希望这些信息可以帮助您了解概念层面的部署选项。 这是我们将在AWS主题上发布各种SAP的一系列博文中的第一篇,因此请经常回来看看。 如果您遵循SAP HANA定制数据中心集成(TDI)模式,内存,计算,存储和网络是SAP HANA所需的四个关键基础架构组件。 其中,内存是唯一取决于您的数据大小的变量。 计算,存储和网络的要求是从内存大小预设或派生的。 例如,根据内存大小,SAP已经有了标准的CPU核数到内存比的要求,以确定您需要进行计算的CPU核心数量。 关于存储,无论内存大小如何,您需要能够满足SAP HANA硬件配置检查工具(HWCCT)指南中规定的不同块大小和其他KPI的特定吞吐量要求。 最后,对于网络,特别是对于横向扩展情况,不论内存大小,您都需要能够在SAP HANA节点之间至少支持9.5 Gbps的网络吞吐量。 在过去的几年中,AWS与SAP紧密合作,以验证在AWS平台上运行SAP HANA工作负载的计算和存储配置。 我们如何实现这个目标的呢? 答案是,AWS已经设计了具有不同内存大小的Amazon Elastic Compute Cloud(Amazon EC2)实例,以满足SAP对SAP HANA的所有严格的性能要求,包括适用于计算的CPU核心到内存比例。 此外,Amazon Elastic Block Store(Amazon EBS)在许多情况下满足了TDI模型的存储KPI。 最后,EC2实例的网络带宽满足或超过了横向扩展模式下节点间通信的9.5 Gbps要求。 我们来仔细看看这些构建模块和配置选项。 内存和计算 AWS提供了几种EC2实例类型来支持不同类型的工作负载。有两个EC2实例系列非常适合SAP HANA工作负载:内存优化的R3和R4实例以及高内存X1实例。这些实例系列是针对内存中的工作负载(如SAP HANA)专门制定的。这些实例系列及其包含的实例类型为您提供了运行SAP […]

Read More

光环新网运营的AWS中国(北京)区域HPC集群创建

在上个博客“在AWS云上快速搭建高性能计算(HPC)集群”中,我们介绍了高性能计算的使用场景,框架和如何在AWS Global创建HPC集群,但在光环新网运营的AWS中国(北京)区域并不支持使用CFNCluster直接创建HPC,因此我们需要使用CloudFormation手工创建集群,整个过程并不复杂。步骤如下: 1.进入光环新网运营的AWS中国(北京)区域的Console,然后进入CloudFormation的服务。如下图: 2.点击 “Create New Stack”后,弹出下面的界面。 3.在界面中制定CloudFormation的模板文件如下。 https://s3.cn-north-1.amazonaws.com.cn/cfncluster-cn-north-1/templates/cfncluster.cfn.json 4.在后续界面中下面参数必须定义: Stack name:要创建HPC集群的名称 AvailablityZone:指定要在那个可用区创建HPC集群 VPCId:指定需要创建集群的VPCId MasterSubnetId:指定Master节点的子网ID KeyName:指定EC2服务器访问的key Scheduler:指定高性能计算的管理框架,默认是SGE,有Openlava,Torque等可以选择。 5.可选参数定义: InitialQueueSize:HPC集群的初始节点数 ComputeInstanceType:集群计算节点的类型 MasterInstanceType:Master节点的类型 MaxQueueSize:集群最大节点数 PlacementGroup:节点的放置组 对于全部的配置参数说明,可以参考下面链接: http://cfncluster.readthedocs.io/en/latest/configuration.html 6.点击Next后,输入集群的tag。 7.点击左下方的checkbox运行AWS Cloudformation帮助创建资源,然后点击创建。 8.等待当前HPC集群的创建状态变为COMPLETE,查看下方的Outputs消息输出,找到HPC Master节点的IP。 9.使用前面Output中的Master节点的IP或去Console中的EC2里面找到刚才创建的Master节点的机器,通过ssh连接,然后运行HPC的命令。 总结 在AWS中国区,你可以使用CloudFormation快速的创建HPC集群,AWS提供了丰富的服务器类型供你选择,你可以选择基于CPU或GPU等不同类型的服务器,也可以选择SGE,OpenLava等分布式资源管理软件来调度你的程序,如果我们不配置,默认的资源管理软件是SGE。 作者介绍 蓝勇,AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在DR解决方案、数据仓库、RDS服务、企业应用、自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前,在甲骨文中国担任资深售前工程师,负责售前方案咨询和架构设计,在数据库,中间件,大数据及企业应用方面有丰富经验。

Read More

在AWS云上快速搭建高性能计算(HPC)集群

1. 高性能计算的应用场景 科学家、工程师及科研者等经常需要使用大规模高性能计算集群(HPC)来解决计算密集或存储密集型计算的问题,常见的使用高性能计算的场景包括基因处理、金融建模与仿真、计算化学、物理建模与仿真、政府及科研项目等。在这些HPC应用中,通常需要使用HPC集群来帮助我们快速完成计算,从而减少研发成本和时间。比如基因公司为了完成遗传病组学研究,通常一次需要研究上万份基因的样本,分析上百T的数据,如果用自己机房的服务器来完成计算分析,需要数年的时间,如果使用HPC集群,提交基因分析任务,我们能使用集群的分布式资源管理器来调度并最大化的利用机器资源,在数天内完成分析任务,大大的节省计算的时间。常见的高性能计算的场景还包括:视频转码与编码、流体力学、天气预测、材料仿真、汽车碰撞仿真、风险建模、分子建模、上下文搜索、物流建模、地震勘探数据处理、基因数据计算、天体物理、深度学习、动画建模、微电子验证、图像处理、地理信息系统等。 2. 什么是高性能计算 通常所说的高性能计算使用的硬件一般分为两种情况: 高性能计算机 高性能计算机通常指使用了很多处理器(作为单个机器一部分)的机器。 比如说国内的高性能计算机“天河”、“曙光”、“神威-太湖之光”等,如“神威-太湖之光”由40个运算机柜和8个网络机柜组成,一台机柜装有1024块处理器,计算速度12亿亿次浮点运算次数。 高性能计算机集群 使用某一集群中的多台计算机(作为单个计算资源操作)的计算系统和环境。 这是通过将多台计算机,通过软件的方式组成集群,由集群的分布式资源管理器来负责集群中服务器资源的监控、调度等,我们可以将集群看做单个计算资源,然后将任务提交到集群,分布式资源管理器负责将任务调度到具体服务器执行。 比如在2013年的超级计算机500强的竞赛中,AWS使用多个C3实例组建了高性能计算机集群,使用了26496个核,计算峰值速度达593.5万亿次浮点运算次数,当年排名世界第64位。 当我们需要高性能计算的时候,通常由于机房的资源比较固定,很难有很多服务器给我们来组建集群,而借用高性能计算机如“曙光“,”神威“的成本非常高,也不太现实。这时在云上搭建高性能计算集群就非常方便,因为云上有无限量的计算及存储的资源,资源更弹性,计算过程中可以根据业务压力,调整集群服务器数量;在完成计算后,我们可以释放所有计算资源,大大降低了计算成本。 3. 如何使用AWS云搭建HPC集群 通过 AWS,您能在数分钟内完成高性能计算集群的创建,并将并行 HPC 任务的数量增加到大多数本地 HPC 环境都无法支持的规模,从而提高研究速度并缩短获得成效的时间。AWS 可按需提供针对特定应用程序进行优化的 CPU、GPU 和 FPGA 服务器,有众多的服务器类型选择,无需巨额资金投入,从而帮助降低成本。您有权限访问面向紧密耦合、IO 密集型和存储密集型工作负载的完全等分的高带宽网络,这使您能够在数千个核心之间横向扩展,从而更快获得成效。 4. 集群管理软件CFNCluster 您的HPC集群可能拥有成百上千台机器,手工搭建HPC集群意味着你需要创建所有服务器,配置所有软件,这个过程太复杂。为了简化这个操作,AWS提供了CFNCluster集群管理软件,它是由AWS开发和维护的高性能计算集群的框架,能帮助你在数分钟内完成集群的创建和生产部署,CFNCluster创建的集群支持SGE,OpenLava,Torque等高性能计算框架。下图是CFNCluster和HPC集群的关系图: 通过上图可知,通常我们需要在一台服务器上安装CFNCluster软件,然后通过CFNCluster创建和管理多个HPC的集群,HPC集群中的服务器安装了SGE, OpenLava等分布式资源管理器,你可以根据需要配置分布式资源管理器的类型 ,你也可以使用Cloudwatch监控服务,根据业务压力动态调整(AutoScaling)HPC集群计算节点的数量。当HPC集群创建完成后,你可以像以往使用HPC集群一样通过Master节点访问你的HPC集群。下面示例详细介绍了安装CFNCluster和创建HPC集群的详细过程: (1) 在AWS云中创建一台EC2服务器(使用Amazon Linux的AMI),并运行sudo pip install cfncluster安装CFNCluster,示例如下: sudo pip install cfncluster You are using pip version 6.1.1, however version 9.0.1 is available. […]

Read More

新功能- Collectd的Amazon CloudWatch插件

原文:https://aws.amazon.com/blogs/aws/new-cloudwatch-plugin-for-collectd/ 作者:Jeff Barr 我在2011年已介绍过Cloud Watch的特性,“您可以在Cloud Watch中查看图表、设置告警、并根据这些指标启动自动化操作,所使用的这些AWS资源指标会被存储于Cloud Watch中 。”您目前已有能力在Amazon Cloud Watch中存储一段时间范围内的业务、应用及系统的指标数据(参阅“Amazon Cloud Watch定制新指标”了解更多信息)。 今天我们将简化系统统计信息的采集过程,使用一个新的 CloudWatch plug for colletd将采集数据发送至CloudWatch中 。并通过collectd 多种类型信息的统计采集能力与cloudwatch存储、展示、警报和告警的功能的整合,您可以更好地获取EC2实例、本地硬件以及运行于其上应用程序的运行状态及其性能信息。该插件已经作为一个开源项目发布,我们期待您的反馈。 Collectd守护进程采用C语言编写,具有高性能和可移植性。它支持上百个插件 ,允许您收集有关Apache、Nginx Web服务器性能统计数据、memory usage 、 uptime等信息。 安装与配置 为了演示这些功能,我在EC2实例上安装并配置了Collectd服务及新Cloudwatch插件。 首先我创建了一条IAM策略,它具备将指标数据写入CloudWatch的权限: 然后我创建了一个IAM角色,允许EC2(运行collectd程序的实例)使用上述所建的策略: 如果我计划使用Collectd 插件从本地服务器或运行中的EC2实例收集统计信息,那请跳过这些步骤,采用创建一个具有适当权限的IAM用户作为替代方法。在我完成上述工作后,会将该用户的证书放在本地服务器或EC2实例中。 在策略和角色配置完毕后,选择该角色来启动一个EC2实例 登录并安装Collectd : $ sudo yum -y install collectd 然后获取插件和安装脚本,设置脚本为可执行,并运行该脚本: $ chmod a+x setup.py $ sudo ./setup.py 回答一些交互问题确认安装过程无误,在完成配置之后就可启动Collectd : Installing dependencies … OK Installing […]

Read More

使用AWS CodeDeploy和Auto Scaling组实现蓝绿部署

原文: https://aws.amazon.com/blogs/devops/performing-bluegreen-deployments-with-aws-codedeploy-and-auto-scaling-groups/ 作者:Jeff Levine,Amazon Web Services解决方案架构师 AWS提供的服务能够帮助大家利用云的力量来满足开发和部署的需求。AWS CodeDeploy可自动将代码部署到Amazon EC2或本地实例,并支持蓝绿部署方式。在这篇博文中,将讨论蓝绿部署的好处,并展示如何实现。 蓝绿部署的好处 蓝绿部署涉及两个生产环境: 蓝色环境指代正在使用的生产环境。 绿色环境则将发布一个新版本。 以下是蓝绿部署的一些优点: 可在绿色环境下进行测试,而不会中断蓝色环境。 切换到绿色环境不需要停机,只需要重定向用户流量。 问题发生时,可很方便地从绿色环境回滚到蓝色环境,只要将流量重定向回蓝色环境即可,而无需重新构建。 需要变更时,利用不可变基础设施原则初始化新的实例,避免实例配置产生不一致性。 AWS CodeDeploy提供了两种蓝绿部署的方式: 第一种,AWS CodeDeploy为Auto Scaling组创建了副本,启用新的Amazon EC2实例,将应用程序部署到这些新实例,然后重定向用户流量重定到新部署的代码。 第二种,可使用实例标签或Auto Scaling组来选择用于绿色环境的实例。AWS CodeDeploy会将代码部署到标记的实例上。 那么,如何设置你的第一个蓝色环境?最佳做法,当然是采用AWS CodeDeploy的in-place部署方式。当然也可以从已有的空白Auto Scaling组开始。 蓝绿部署的示例 我们来看一下如何使用Auto Scaling组来实现蓝绿部署。 概述 下图中,示例环境包括一组Amazon EC2实例,可作为AWS CodeDeploy的工作站。服务发布管理员或开发人员可以使用此工作站部署新版本的代码。蓝色环境包含一个Auto Scaling组,其中另有两个实例用作Web服务器。 Web服务器,最初将包含应用程序的第一个版本和AWS CodeDeploy客户端。负载均衡器以轮转的方式,将流量引导到两个Web服务器。 服务发布管理员使用工作站实例,将新版本的应用程序推送到AWS CodeDeploy,并启动蓝绿部署。 AWS CodeDeploy会创建Auto Scaling组的副本,启动两个新的Web服务器实例,并安装新版本的应用程序,然后将负载均衡器重定向到新实例。 原实例仍然是原Auto Scaling组的一部分。 如果需要,均可重新关联到负载均衡器中。 构建该示例的先决条件 以下是需要的准备工作。 具有使用Amazon EC2,Amazon S3,Amazon VPC,AWS CodeDeploy和AWS CloudFormation权限的IAM用户。 选定构建示例环境的AWS区域和可用区域。 Amazon EC2密钥对。 […]

Read More

Amazon S3新版管理控制台的正确打开方式

Amazon Simple Storage Service(简称S3)是AWS在2006年发布的第一款云服务产品,S3作为对象存储具有海量存储、接口灵活、11个9持久性、价格便宜等特点,特别适合存放静态文件如图片、视频、日志以及备份文件等等,同时S3是AWS大数据解决方案中重要组成部分,以EMRFS的形式与EMR(AWS托管的Hadoop平台)结合提供计算与存储分离的灵活架构。 熟悉S3控制台的小伙伴一定发现,自从5月份开始,控制台的界面焕然一新,甚至有点无处下手,但熟悉起来后又有些爱不释手,下面我们将介绍下新版控制台带来了哪些新的功能,以及如何给你的工作带来极大效率提升。 新版控制台的操作说明,图文并茂,详见: http://docs.amazonaws.cn/AmazonS3/latest/user-guide/what-is-s3.html 一、创建存储桶 创建存储桶的时候除了配置桶名、存储桶区域之外,还可以配置版本控制、日志、标签以及访问权限,现在用户可以在新版控制台使用“从现有存储桶复制设置”的功能,选择相同配置的存储桶即可,避免重复设置。 二、上传对象 在控制台下除了正常的通过点击上传按钮选择上传文件完成上传外,新版控制台支持在存储桶界面下,直接将待上传的对象拖放到页面上。通过新版控制台上传单个文件支持最大78GB。 对存储桶中对象的上传、删除、重命名等操作,页面底部可以看到该操作的进度及其他操作的历史记录。 三、ACL 我们可以通过配置存储桶及对象的ACL来实现存储桶和对象的访问控制,老版控制台的部分名称容易让人引起歧义,以存储桶ACL为例,如下图所示,其中查看权限是指查看该存储桶权限的权限,即查看该存储桶ACL的权限,而不是指查看存储桶的权限,编辑权限同样是指编辑权限的权限,不是编辑存储桶的权限。 在新版控制台中很好的避免了这点误区,分对象访问和权限访问,这里以存储桶的ACL举例,见下图: 其中一个新功能是我们可以在管理用户处添加其他帐号的规范ID(https://docs.aws.amazon.com/zh_cn/general/latest/gr/acct-identifiers.html )或帐号的Email向该帐号中的IAM user/role授权访问,以实现跨帐号访问,需要注意的是对方帐号的IAM user/role拥有对该存储桶的操作权限取决于此处我们设置的ACL以及对方帐号中IAM user/role本身policy设定的权限。 四、标签Tag S3标签是随S3新版控制台一起发布的一个服务特性。标签可以帮助你对存储桶以及对象进行分类或标记,类似我们给EC2等资源添加标签一样,每个S3标签也是一个键值对,每个对象最多可添加10个标签键值对,键值对大小写敏感。通过使用标签,我们可以创建基于标签的IAM policy以实现细粒度的权限控制,比如标签为PHI的值为true时,仅供只读。同时,在使用S3数据生命周期管理、分析、指标等功能的时候,可以创建基于标签的过滤器,实现细粒度的资源管理。 S3 标签作为新服务特性,相应的API也同步发布,比如PUT Object tagging, GET Object tagging, DELETE Object tagging以及其他支持标签的API如PUT Object, GET Object, POST Object, PUT Object-Copy,详细可参考: http://docs.aws.amazon.com/zh_cn/AmazonS3/latest/dev/object-tagging.html 需要注意的是,标签遵循最终一致性模型。 五、生命周期管理 数据通常从创建后会经历频繁访问、低频访问、极少访问的数据热度周期,相对于热数据,冷数据适合以成本更低的方式存储,比如热数据存放在S3 standard,冷数据存放在S3-IA,归档数据存放在Glacier等,以达到成本最优的目标。我们可以使用S3数据生命周期管理通过配置相应的规则来实现数据的生命周期管理,随着S3标签的发布,现在我们可以创建基于前缀和/或基于标签的规则,以实现更细粒度的资源管理。详细操作步骤见: http://docs.amazonaws.cn/AmazonS3/latest/user-guide/create-lifecycle.html 六、存储类分析 存储类分析是新发布的功能,通过该工具,我们可以更加直观的了解到存储桶中的数据活跃情况,帮助我们决策何时将不常访问的数据从S3 Standard转换为S3-IA,即为配置数据生命周期管理提供数据支持。 同时,可以创建筛选条件,选择对整个桶中对象或者具有某些前缀或标签的对象进行分析,即对对象进行分类分析,需要注意的是,分析是从启用该功能后一段时间后才能看到结果(通常是24~48小时),并不是可以立刻可以看到分析结果。 通过存储类分析,我们可以可视化的了解到存储桶数据在过去30天的检索量,占比,以及多个时间范围段内数据存储与检索的情况,该数据每天更新,并且可以以csv的格式导出到S3存储桶以供下载,可使用Quicksight等BI工具进行展现。 csv中字段说明见: http://docs.amazonaws.cn/en_us/AmazonS3/latest/dev/analytics-storage-class.html#analytics-storage-class-export-to-file 配置存储类分析详细操作步骤见: http://docs.amazonaws.cn/AmazonS3/latest/user-guide/configure-analytics-storage-class.html […]

Read More

利用Kong及AWS Lambda构建无服务器的后端逻辑

Kong是一个开源的API GW及微服务管理层,基于Nginx, Cassandra或者PostgreSQL构建,最初由Mashape开发,用于为其API Marketplace管理超过15,000个API和微服务,并于2015年开源。Kong具有如下优点: 可扩展性:通过简单地添加更多的机器,Kong可以轻松地水平缩放,这意味着您的平台可以处理几乎任何负载,同时保持低延迟。 模块化:可以通过添加新的插件来扩展,并通过RESTful Admin API轻松配置所有插件。 平台无关性:Kong可以运行在任何地方,包括本地数据中心及公有云,支持物理机,虚机及容器部署。 目前Kong的最新版本为0.10.2,支持的插件如下: 认证:Basic Authentication, Key Authentication, OAuth2.0 Authentication, OAuth 2.0 Introspection, HMAC Authentication, JWT, LDAP Authentication 安全:ACL, CORS, Dynamic SSL, IP Restriction, Bot Detection 流控:Rate Limiting, Response Rate Limiting, Request Size Limiting 无服务器架构:AWS Lambda, OpenWhisk 分析监控:Galileo, Datadog, Runscope 内容转换:Request Transformer, Response Transformer, Correlation ID 日志:TCP/UDP/HTTP Logging, File […]

Read More

利用Amazon ElastiCache寻找附近的X

基于地理信息的应用已经越来越深入到日常生活中,人们经常会在应用中寻找附近的朋友,车,餐厅或其它资源。而与此同时,随着物理网技术及设备的普及,应用需要更加实时和精确的处理来自各种数据源(包括用户手机,各种传感器设备及其他系统)的大量数据,以完成相关的搜索和计算距离等操作。 架构 对于开发者来说,Redis因为其性能上的优势往往会被采用作为位置数据的缓存,只是在3.2版本之前需要代码中把位置数据进行Geohash后才能有效的排序和分析。不过3.2版本后,Redis已经能够原生支持基于位置信息的存储,计算及搜索了。Amazon ElastiCache是AWS提供的托管型的数据缓存服务,借助该服务,用户能够在云中轻松部署、运行和扩展分布式内存数据存储或缓存。 Amazon ElastiCache 的Redis引擎是一项与 Redis 兼容的内存服务,兼具 Redis 的易用性和强大功能,同时还可为要求最苛刻的应用程序提供适用的可用性、可靠性和性能,提供单节点和多达 15 个分片的群集,从而可将内存数据扩展到高达 3.55TiB。这里,我们可以基于Elasticache并结合AWS其他服务构建出以下的示例架构: 1)终端设备获取GPS位置信息,定时或基于事件将数据上传到云端。在AWS上可以选择使用IoT或Kinesis等托管型服务作为数据收集的接收端,也可以使用部署在EC2/Lambda上的自定义服务。 2)所有位置信息写入可以自动扩展的DynamoDB,基本Schema包含设备Id/Timestamp/Geo location, 方便历史查询或轨迹查询。 3)打开DynamoDB流,用KCL或Lambda监听DynamoDB的数据改变,并将当前变化的位置数据更新到Elasticache中建立基于Geospatial的索引缓存。 4)手机应用搜索附近资源时,部署在EC2/Lambda的查询服务利用Elasticache geospatial直接获取结果。 实现 如前文所述,步骤1和2可选择的方案很多,比如采用AWS IoT服务甚至可以无需任何代码仅通过配置即可完成云端的功能讲数据实时写入相应的DynamoDB表中。因此,本文将着重介绍如何实现前文架构中的3和4步: a) 打开DynamoDB 流,获取流的ARN用于读取,如下图: 读取DynamoDB流数据有三种方式:利用Kinesis adapter,利用低级别API以及利用Lambda函数来进行读取。从易用性的角度来说,当然是Lambda函数最简单,不需要考虑shard,吞吐和checkpoint等问题而专注于业务逻辑。但是Lambda函数并不是在所有的AWS区域都支持,因此本文采用第一种方式利用Kinesis adapter完成读取。具体参考文档:http://docs.amazonaws.cn/amazondynamodb/latest/developerguide/Streams.KCLAdapter.html b) 在读取流的同时,我们需要将最新的地理位置信息利用GEOADD更新到Elasticache中。前文提到Redis在3.2版本后,Geospatial Indexing已经被原生支持,而它实际上是Sorted List数据结构的一种扩展,即排序 key扩展成了经纬度,如下图所示的数据结构,并且可以方便的使用基于地理信息的API,例如GEOADD——添加地理位置 。 通过Elasticache可以快速构建出一个Redis环境,包括支持shard的集群模式,如下图所示。 构建完成后,通过Elasticache提供的终端节点就可以访问cache了。 需要注意的是如果选择的Redis是集群模式,那么就得同步升级支持Redis集群模式的客户端SDK用以开发。因为Redis的集群提供的是分片功能,它会把不同的slots分布在不同的节点上,需要由客户端通过CRC16(Key)取模从而计算出数据在哪个节点上。目前可以支持redis集群模式的客户端有很多,比如本文用到的java的jedis以及nodejs的ioredis。 综合a,b两步的示例代码的StreamCacheProcessor.java如下(其余代码参考http://docs.amazonaws.cn/amazondynamodb/latest/developerguide/Streams.KCLAdapter.Walkthrough.CompleteProgram.html ): import java.nio.charset.Charset; import java.util.HashMap; import java.util.HashSet; import java.util.List; import java.util.Map; import java.util.Set; import org.apache.commons.logging.Log; […]

Read More