亚马逊AWS官方博客

Tag: 大咖专栏

Amazon S3 深度实践系列之一:S3 CLI深度解析及性能测试

背景 作者在实际的工作当中遇到越来越多关于S3的实践问题,其中被问的最多的也是使用最广泛的工具就是AWS S3 CLI命令行;AWS S3 CLI命令行工具对大文件提供了默认的分段上传下载的能力,同时支持并发上传下载多个文件;AWS S3 CLI 命令行不仅仅提供了高级抽象的cp、sync等操作同时还提供了相对底层的s3api相关的操作以帮助客户应对各种高度定制化的应用场景。 本文通过实验帮助大家更好地理解AWS S3 CLI常用命令的底层原理及在AWS EC2上使用该命令行工具与AMAZON S3交互场景下,影响性能的几个关键要素及几个常见EC2实例类型上的上传下载测试性能情况。 本文是AMAZON S3深度实践系列之一,接着作者会带着大家从AWS CLI探索到Python boto3 S3多线程应用开发实践,再到如何利用前面学到的知识,基于AWS平台利用托管服务构建一个实用的跨区域迁移S3数据的解决方案架构探讨及实践。 基本概念 并发上传vs 分段上传 刚刚使用AWS S3命令行工具的时候,总是混淆分段上传和并发上传的含义;分段上传是指将单个大文件切分成多个小数据块进行上传,而并发上传特指有多个待上传文件或小数据块的情况下,利用多线程同时并发上传多个文件或小数据块。 如下图所示,分段上传首先将文件切分成固定数量的小数据块,再利用多线程并发上传这些小数据块,等 S3收到该文件所有的数据块之后再将它们合并成原始的文件存放在存储桶里。分段上传功能默认会帮你实现并发上传;这样做的好处,显而易见,既可以充分利用网络带宽进行文件处理,同时还可以在网络带宽有限的情况下,减小因网络抖动导致的整个大文件需要重传的问题,即当分段上传中的某个数据块因各种异常没能上传成功时,只需要重新尝试上传该数据块即可。 分段上传vs 断点续传 AWS CLI S3命令行工具默认并没有帮大家实现断点续传的功能,也就是说哪怕我们用cp或sync命令上传一个文件的时候,默认后台会做文件分片进行分段并发上传,但如果由于网络抖动导致其中某些数据块传输失败,那么整个文件又得需要重头开始上传。 但同时我们可以利用 AWS CLI s3api底层接口非常容易地实现断点续传,后面章节我们再展开探讨。 AWS CLI S3 cp命令是如何工作的? AWS S3 cp 命令是最常用的单文件和多文件复制方法,很多人使用过该命令,但大家知道该命令是如何帮我们执行文件复制的吗? 该命令有帮我们自动做分段上传和下载吗? 分段上传切分文件的依据是什么?每个数据块大小是多大? 这么多数据块,有多线程并发上传吗?我们可以指定线程数量吗? 多个文件的上传下载是如何工作的? 下面我们通过实验来观察和研究下这些问题,整个测试环境基于如下Amazon Linux上如下版本的AWS CLI命令行: aws-cli/1.11.132 Python/2.7.12 Linux/4.9.51-10.52.amzn1.x86_64 botocore/1.5.95 AWS […]

Read More

如何使用Amazon Macie 进行安全数据自动分类和用户行为监控

概述 当我们在Amazon S3中存储大量内容时,识别和分类其中潜在敏感数据可能会有点像在一个非常大的干草堆中找绣花针针,整个的过程是非常低效。那么能否有一种工具可以在数据加入到S3后就自动的识别敏感信息并自动进行分类? 同时在我们日常的工作中,访问数据的时间间隔及物理位置相对的固定。如果发生异常的事件,例如原来某个用户一天访问一到两个文件,但如果突然在某天访问超过一百个文件,能否由系统发出告警事件提醒相关人员进行相关检查,确保安全? 本文从如下几部分介绍Amazon Macie服务及主要功能,同时还列出常见使用场景,以及如何配置的简要步骤。希望能给大家带来帮助。 什么是Macie Amazon Macie 是一种支持人工智能技术的安全服务,可以帮助您通过自动发现、分类和保护存储在 AWS 中的敏感数据来防止数据丢失。Amazon Macie 使用机器学习来识别敏感数据 (例如,个人身份信息 [PII] 或知识产权),分配业务价值,提供此数据的存储位置信息及其在组织中的使用方式信息。 Amazon Macie 可持续监控数据访问活动异常,并在检测到未经授权的访问或意外数据泄漏风险时发出警报。 为什么要使用Macie 对现存的海量文件进行自动的分类并且根据不同的分类制定不同的监控策略,一旦发生异常的访问需要得到及时的告警,是每个组织面临的挑战。 Amazon Macie提供了简单高效并且安全的方案,Macie通过使用机器学习来了解存储的内容和用户行为,同时提供可视化界面,展示安全分类,从而使客户能够专注于保护敏感信息,而不是浪费时间手工的处理。 Amazon Macie内置检测个人身份信息(PII)或敏感个人信息(SP)的常见敏感信息的引擎,可以自动识别出S3存储文件是否包含例如个人身份信息(PII)或其他公司财报等敏感信息,在没有Macie之前,这样的工作都需要手工的处理或者使用第三方平台。而现在可使用Macie很容易解决上述问题。 Amazon Macie持续监控数据和账户凭证 。 在发现可疑行为或对实体或第三方应用程序进行未经授权的数据访问时撤销访问或触发密码重置策略,来防范安全威胁。当Amazon Macie发出警报时,您可以使用预先在Amazon CloudWatch设置的规则发送告警,以便迅速采取行动,保护数据。 Macie主要功能 Amazon Macie首先功能分为两部分,一方面是使用自然语言处理(NLP)来理解数据,Macie可以自动对您的S3桶中的数据进行分类。另外一个是使用机器学习理解用户访问数据的行为,同时利用动态分析数据访问模式的预测分析算法,并使用日常访问的用户行为数据不断的训练并优化模型。 Macie 主要功能 自动化处理数据:分析,分类和自动处理数据,从现有的数据和访问日志分析出有规律的历史模式,用户认证数据,用户位置信息及时间信息。 数据安全和监控: 主动监控 日志数据,检测到的异常情况,转发告警信息到CloudWatch 事件或和Lambda以进行后续处理,例如自动修复安全漏洞或者发送邮件通知。 主动预防的数据的丢失,提供即时保护,无需手动干预。 可视化分析:提供存储数据的可视化详细信息。 数据研究与报告:允许用户管理配置报告。 Macie如何运作 在数据分类过程中,Amazon Macie 识别 S3 存储桶中的对象,并将对象内容流式传输到内存中进行分析。 当需要对复杂文件格式进行更深入的分析时,Amazon Macie 将下载对象的完整副本,并在短时间内保存,直到完成对象的全面分析。Amazon Macie […]

Read More

使用AWS Lambda和AWS Step Functions轻松构建Serverless应用

作者: Vivian Zhang(张芸) Serverless(无服务器)应用可以说是当前的行业热点,用户无需预配置或管理服务器,只需要部署功能代码,AWS Lambda会在需要的时候执行代码并自动缩放, 从每天几个请求到每秒数千个请求,轻松地实现FaaS (Function as a Service)。无服务器应用的使用场景非常广阔,从微服务架构,到批处理、流处理、运维自动化和移动计算。 实现Serverless应用,除了AWS Lambda还需要什么? 我们来看一个典型的基于Lambda的无服务器应用。 当我们将作为计算和存储实体的Lambda函数、消息队列、DB去掉,可以看到下面这张图。 这张图上的箭头,就是上一张图里Lambda函数之间的流程,或者可以称为Lambda函数之间的“胶水”,它们起到了编排协调各个Lambda函数的作用。通常在应用中,我们会需要有这样的一些流程: 我想要顺序地执行方法。 我想要并行地运行这些方法。 我想要基于数据选择执行方法。 我想要重试某些方法。 我想要try/catch/finally。 我想要代码运行一定时间或者等待一段时间…… 通常我们可以通过方法调用、函数链、DB和消息队列来协调这些函数,实现流程。但是对于所采用的协调机制,我们都希望它具有以下功能: 可以自动伸缩; 不会丢失状态; 可以处理错误和超时; 可以简单的搭建和运维; 可以审计。 这里我们介绍一种方式,采用AWS Step Functions协调Lambda函数之间的流程。 AWS Step Functions AWS Step Functions是一个可视工作流服务,可用来轻松协调分布式应用程序和微服务的各个组件。用户从单个组件构建应用程序,每个组件都执行一个特定的功能,也就是Task(可以采用Lambda函数实现)。Step Functions提供了一种可靠的方法来协调这些组件并逐步完成应用程序中的这些功能,并且 提供了一个图形控制台,将应用程序的组件可视化为一系列步骤,它可以自动触发并跟踪每一个步骤,并在出现错误时重试,这样应用程序就可以每一次都按照预先设定的顺序执行。Step Functions会记录每一步的状态,因此当事情出错时,用户可以快速地诊断和调试问题。 要使用Step Functions构建应用,首先我们需要在Step Functions里创建State Machine(状态机),也就是对应每一个应用的工作流程。可以采用以下8种蓝图,包括7种预定义好的状态机和1种自定义的。创建好的状态机用JSON描述。 在每一个状态机里,我们需要定义一系列的State(状态),用来完成不同的功能: Task:在状态机中完成特定的功能,可以采用Lambda函数实现。 Choice:在各种执行分支中进行选择。 Fail和Success:停止一个执行,并设为Fail或者Success。 Pass:简单地将输入传给输出,或者注入一些数据。 Wait:提供一定时间的延迟,或者等待到特定的时间/数据。 Parallel:并行地执行分支。 可以看出,上一节中我们所需要的协调和流程在这些状态中都得到了支持。其中的Task状态是用来真正实现应用的功能,而其他状态用来处理功能之间的流程。比如说,下面是一个名为HelloWorld,执行Lambda函数的状态。 下图是一个拥有所有状态的状态机: 在Console里看到一个创建好的状态机是这样: 我们点击New Execution并且传入input数据,就可以启动该状态机的一次执行,并且可以从界面上查看执行的情况。 […]

Read More

Amazon EC2 Systems Manager让你轻松管理AWS混合云

作者:王宇 摘要: Amazon EC2 Systems Manager(SSM)是一套资源管理、配置的工具集,它不仅能够帮助客户完成AWS云中资源的管理,还能够将客户私有云中的资源统一纳入管理范围,是混合云架构中的管理利器。 IT资源在混合场景下应该如何管理? 对于要不要使用公有云资源的问题对于今天的企业来说已经不再是一个问题了,问题变成了要怎么用,怎么管,以及怎么和现有的企业IT环境进行整合。当前,大量企业客户都存在着部分应用或资源已经上云,而企业自己的数据中心中仍然保留着一部分的应用或资源,如何将这两部分的资源统一管理起来,做到有效的协同,是一个关键问题。而传统的网管或资源管理系统往往还无法支撑这个混合场景下的管理需求。 AWS在云资源管理问题上有着完整的解决方案 AWS从云资源的准备、配置、监控、合规、优化这五个方面提供了完整的云资源管理闭环工具集,今天我们介绍的Amazon EC2 Systems Manager(SSM)是在配置管理环节中的一个最常用的管理工具集。 Amazon EC2 Systems Manager(SSM)工具集 Run Command –远程执行常规管理任务 State Manager –定义和维护操作系统和应用程序的一致配置 Parameter Store – 运维参数的集中管理,如密码和连接字符串 Maintenance Window -在明确定义的时间窗口中安排运维任务,以尽量减少停机时间 Inventory –收集,查询和审计详细的软件清单信息 Patch Management –使用自定义的规则和预先安排的维护窗口维护操作系统补丁程序 Automation –使用简化的工作流自动执行日常运维任务 Run Command Run Command能够通过远程发送命令的方式来管理AWS云以及客户自己数据中心中的IT资源。与以往的Run Command相比,现在还可以控制命令执行的并发数量。 这在远程执行命令时可以有效避免在同一时间使用太多共享资源的问题,例如内部更新或统一执行软件补丁程序。 State Manager State Manager通过“Document”的定义,能够定义和维护操作系统和应用程序的一致配置。 创建一个“Document”,将它与一组目标实例关联,然后创建一个关联策略来指定什么时间和什么频率来应用这个“Document”。 使用标签指定目标可使这个关联应用到未来创建的实例中,并允许它在动态的,自动缩放的环境中按预定义的方式工作。还可以通过选择它并点击Apply Association Now来立即运行这个关联: Parameter Store Parameter Store是一个数字词典,它简化了要分发到实例的许可证密钥,密码和其他数据的存储和管理。 […]

Read More

你需要知道的关于高IO EC2的事儿

作者:焦杨 故事背景 笔者长期在AWS从事架构师工作,人送焦导的外号。经常遇到客户抱怨:“我选了比原来大的机器,比原来快的硬盘,可EC2的IO怎么就是上不去,到底卡在哪里了啊?你们架构师到底怎么干活的啊?”,好了,今天我也不想再背这个锅了,我们一起把这个事儿好好说道说道。 基本原理 一开始,我们先来看看磁盘上的数据是怎么到达外网的。 第一步操作系统接到IO命令,然后驱动磁盘,从磁盘上读入数据到内存处理, 最后从网卡送出,通过交换机路由器送出到外部网络。 要更好的IO性能,硬件层面上看无非三板斧 换个更块的硬盘 换个更快的网卡和交换机 更快的CPU、足够的内存、足够优化的 那到了AWS上,又变成什么样了呢? 云上的图 你可能看出来了: 物理机变成了EC2 instance。 磁盘为了更灵活和更可靠,把它从机器里拿出来变成了EBS。 外部的交换机/路由器由于VPC的存在,对用户变成透明的了。 稍微想想,发现实质完全没有变化。那是不是我们就可以用原有的三板斧解决性能问题了呢? 焦导的回答是:“完全没错,但是不足够”。 大家知道,公有云服务商为了保证服务质量,避免所谓的“吵闹的邻居”问题,也为了避免意外操作导致的超额费用,引入了大量的QoS特性。这里边既有我们熟悉的各个service的hard和soft的limit,也有对外暴露的各种配置选项。为了要实现高IO的目的,我们有必要对这些QoS特性有清晰的了解。 还是上边的那个图,把其中的关键部分标上号,下边一一说明 列举分析 1. EC2网络 AWS向客户提供SDN的VPC网络,屏蔽了交换机、路由器等网络基础设施。但是对单个EC2 实例的网络出口带宽是有明确的限制的。 你可能会说这不就是网卡限制吗?多加几个网卡不就行了。 请注意,增加多个网卡并不能增加单个EC2的总出口带宽。 更加详细的数据请查看这里http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-ec2-config.html 2 存储网络 默认情况下,刚才提到的EC2总带宽,包含了进出EC2实例的所有流量。熟悉网络的同学应该知道,这里边包含了EC2间的计算流量、访问存储设备的存储流量等的各种流量。 要优化性能,拿出单独的网络来走存储流量就可以了。这也就是我们通常说的计算、存储流量分离技术。在AWS里,我们把这个叫做”EBS优化“。 当然了,对于一些早期机型(i2,c3等),在使用了万兆网络的情况下。因为这根管子已经足够粗,流量混在一起问题也不是很大。 EC2机型EBS优化的更多信息,可以在这里找到http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-ec2-config.html 3 磁盘性能 要想获得高IO,选择合适的磁盘应该是最基本的了吧。是看重IOPS而选择SSD型,还是看重连续读写的磁盘吞吐而选择HDD,这是你要做出的关于磁盘的第一个决定。 这里要特别注意的几个点: 单卷IOPS的具体值和容量正相关,对于GP2而言,基准值为3IOPS/GB 对单卷有IOPS和吞吐量的限制, 两个因素同时起作用 对连接了多个卷的实例,总体IOPS和吞吐量也分别有限制 另外需要注意的是,对于使用最多的GP2类型SSD,存在着读写突增特性(链接),无论多小的磁盘短时间内IOPS都可以到达3000,具体就不再展开说了。 参考这里http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/EBSVolumeTypes.html 4 存储队列 卷存储队列是指等待设备处理的 I/O 请求的队列,它的长度表明了有多少I/O请求还没有得到执行。队列过长,读写延迟加大,队列过短,读写任务不饱满。要让EBS全速工作起来,需要有足够的任务,也就是说要让EBS始终处于忙碌的状态。 基于这个认识,有必要根据工作负载的具体状况,实时观察存储队列长度的情况。对工作负载进行适当调整,以便发挥底层设备的最大能力。 这个指标可以通过Cloudwatch的VolumeQueueLength 来观察。 http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-io-characteristics.html […]

Read More

EKK—基于AWS托管服务的日志收集分析系统

译者:刘磊 应用系统日志的收集分析对于运维来说是至关重要的。一个可靠、安全、可扩展的日志收集分析解决方案在分析应用系统异常终止原因时能够让一切都变得轻松起来。 在这篇博文里,我们会探讨除了流行的ELK(Elasticsearch, Logstash, and Kibana)解决方案之外的另一种选择,EKK解决方案(Amazon Elasticsearch Service, Amazon Kinesis, and Kibana)。EKK架构最大的好处是使得你不再需要自己亲自安装、部署、管理以及扩展日志收集分析系统,而将精力集中在分析日志,排除应用系统异常上面。 下面我们会介绍如何使用EKK架构来收集和分析Apache web服务器的日志,先来看看EKK架构的组成部分。 Amazon Elasticsearch Service是一个流行的搜索和分析引擎,主要用来提供实时的应用系统日志和点击类流量的分析服务。本文中我们会利用Amazon ES将Apache的日志存储并索引起来,作为一项托管服务,Amazon ES可以很轻松地在AWS云上进行部署、操作和扩展。此外使用托管服务,还能大大减轻管理上的工作,例如打补丁、异常监测、节点恢复、备份、监控等等。因为Amazon ES自身内部已经和Kibana进行了集成,所以省去了安装和配置等工作。获取Amazon ES的更多信息,请参考Amazon Elasticsearch Service。 Amazon Kinesis Agent 是一个易于安装的单机版Java应用程序,它负责收集和发送日志数据。它会持续监控Apache web服务器的日志文件,并且将新的数据不断地发送到传输数据流中。同时它还负责文件回滚、生成检查点、异常发生后的重试,以及以时间序列为准可靠地发送日志文件。获取更多利用Amazon Kinesis Agent的信息,请参考Amazon Kinesis Agent和 GitHub 相关项目。 Amazon Kinesis Firehose提供了往AWS中加载流式数据的捷径。本文中,Firehouse会获取并自动加载日志的流式数据到Amazon ES里,随后在S3中还会再进行一次备份。获取Amazon Kinesis Firehose的更多信息,请参考Amazon Kinesis Firehose。 有了AWS CloudFormation的帮助,你只需要使用一个模板就能快速实现EKK架构。模板里准备了Apache web服务器,并使用Amazon Kinesis Agent和Firehose将它的访问日志发送给Amazon ES集群,同时在S3中备份日志数据,最后使用Amazon ES Kibana endpoint来对你的日志进行可视化分析。 AWS CloudFormation template帮你快速完成如下工作: 准备Amazon […]

Read More

利用AWS混合云容灾架构实现企业级IT的云转型(一)

作者:王宇 摘要:AWS混合云容灾架构不但能够实现企业级的应用云容灾,还能够帮助企业级客户平滑实现企业IT的云转型。 在我们谈论容灾时,我们在谈些什么? 容灾是一个非常传统的话题,是在产生IT系统的第一天开始就必须要考虑的问题。总的来说它主要是指“数据中心灾难、区域性灾难和人为误操作”三个方面造成对IT系统的灾难时的恢复工作。 在中国,“两地三中心”的容灾架构已经广泛的被企业级用户认可,成为企业级容灾架构的标准,但由于建设成本高,周期长等原因,实际按照此标准建设的企业少之又少。而AWS的混合云容灾架构,就是在AWS的云环境中实现“两地三中心”,同时利用AWS云中资源的弹性大幅度降低资源成本和建设以及运维的复杂性。 软件定义一切,AWS云容灾解放企业IT生产力 如果企业客户已经在自己的数据中心中完成了容灾环境的搭建,势必消耗了大量了资源,包括机架空间、电力、IT资源、人力资源等等,而容灾环境本身是一个并不产生经济效应的保障性系统,对企业资源的占用巨大。AWS云资源池通过软件定义的方式,能够打造与企业内部完全相同的复杂IT环境,实现企业级应用的完整镜像,随着应用容灾系统迁移至AWS云中,可以将企业现有的容灾中心转变成生产中心,从而扩大客户自建数据中心的承载能力,或大幅降低IT资源的运营成本。 随时容灾演练,确保备用环境可用性 在传统的容灾环境中,容灾演练是一个令人头疼的大问题,因为容灾环境的建设不是“一锤子买卖”,随着生产环境和数据的不断变化,容灾环境必须跟随生产环境改变,否则在发生灾难时就无法实现业务的快速切换和启动,因此,定期的容灾演练是必须的。而传统环境中的容灾演练要配合硬件和软件厂商,耗时耗力,效果还往往不尽如人意。在AWS云环境中,能够轻松实现容灾环境的复制,从而与生产环境并行的实现容灾环境的测试演练,通过实际的演练来验证容灾环境的可用性以及数据的完整性,在演练结束后可以随时将演练环境删除或关停,演练成本和复杂程度都大幅降低。 AWS云容灾实现秒级回滚,解决人为错误 在生产环境中,由于人为的误操作、系统升级、补丁等操作造成的对IT系统以及数据的破坏很难防范,尤其是有一些操作和BUG导致系统在运行一段时间后才能发现故障,而此时容灾环境的数据有可能已经被覆盖,难以恢复。在AWS云中实现的容灾环境能够借助数据快照、数据日志等功能,除了能够保存最新的业务数据意外,还能够实现数据的秒级回滚。在发现系统出现故障后,不但能够切换到容灾环境中的最新数据,还能够选择过去24小时中的任意时间点进行恢复,从而解决了容灾系统中的脏数据问题。 利用AWS容灾环境切换,实现生产系统的平滑上云 现有的IT生产系统环境往往错综复杂且数据量大,让这样的系统上云往往需要冗长的数据搬迁和环境搭建时间,生产系统面临长时间的停机,无法接受。AWS容灾解决方案能够与生产系统并行地传输生产数据,并在云中搭建与企业内部结构相同的生产系统镜像环境,待云中数据与生产中心数据同步一致后,以容灾切换的方式使生产业务切换至AWS云上,最大限度地降低了生产环境的停机时间,实现了平滑上云。 AWS云中容灾,只为实际使用量买单 从容灾系统的TCO上看,AWS容灾解决方案更是具备明显优势。无需前期对硬件、软件的采购和安装,省去了大量前提投入成本。更重要的是,容灾方案中AWS云中资源可以选择不开机或只开启少量小机型资源,对于不开机的资源将完全不收取EC2虚拟机资源的费用,又能保持EC2虚拟机的状态和后台数据的增量更新。经过我们的测算,一个典型的容灾系统项目,以5年为周期进行计算,TCO只需花费原有私有云容灾环境的1/3,而第一年的投入资金更是传统项目的1/10. 总结 容灾虽然是一个非常古老和传统的IT业务,但随着云计算技术的不断成熟和普及,它恰恰成为了一个非常适合率先在公有云中实现的业务。首先它的建设风险低,与生产系统完全并行,前期投入小,无需提前采购,而且它还能够成为企业上云过程中建设自身团队云能力的一个绝好机会,经过云容灾项目之后,企业对AWS云资源、云技术都会有一个全面的了解,且能够利用这个机会验证AWS云环境承载企业生产系统的能力到底如何,再逐步实现企业级IT环境的云转型。 (未完待续) 本次分享的内容先到这里,今后我们会继续针对AWS混合云容灾架构中的诸多关键技术要点进行细致的分享,敬请期待! 如对AWS混合云容灾架构解决方案感兴趣,请联系我们: yuwangcn@amazon.com   作者介绍: 王宇,AWS企业容灾解决方案业务拓展经理,目前负责AWS中国区的混合云、容灾和DevOps产品和解决方案。曾服务于VMware等传统私有云厂商,熟悉传统IT架构和私有云、混合云、公有云的解决方案融合。  

Read More

搭建基于S3的HBase读备份集群

作者:刘磊 当前aws的很多客户已经从将s3作为HBase的存储中获益,这当中包括更低的存储花费、更好的数据可靠性、更容易的扩展操作等待。比如FINRA就通过将HBase迁移到s3上将在存储上的花费降低了60%,此外还带来了运维上的便利,以及架构上的重大优化:将s3作为统一的存储层,实现了更彻底的存储和计算分离。在s3上部署HBase集群,可以让你在集群启动后立即进行数据查询操作,而不用等待漫长的快照恢复过程。 随着Amazon EMR 5.7.0的发布,现在你可以在集群层面进一步提升数据的高可用性和高可靠性,方法是基于同一个s3存储桶建立多个HBase的读备份集群。这会让你的数据通过读备份集群及时地被用户访问,即使在主集群遇到问题关闭的时候,当然你还可以通过在多个可用区中部署读备份集群来进一步增加数据访问服务的可靠性。 接下来的文章将告诉你如何在s3上建立HBase的读备份集群。 HBase 简介 Apache HBase是Apache Hadoop生态体系中的大规模、可扩展、分布式的数据存储服务。同时它还是开源的,非关系型的版本数据库,默认情况下运行在HDFS之上。它的设计初衷是为包含了数百万个列的数十亿行记录提供随机的、强一致性的、实时访问。同时它还和Apache Hadoop、Apache Hive和Apache Pig等大数据服务紧密结合,所以你可以轻易地为并行数据处理提供快速的数据访问。HBase数据模型、吞吐量、和容错机制能很好地为广告、web分析、金融服务和基于时间序列数据的应用等工作负载提供支持。 和其他很多Nosql数据库类似,HBase中的表设计直接影响着数据的查询和访问模式,根据这些模式的不同,查询的性能表现也会有非常大的差异。 HBase on S3 在建立基于S3的HBase读备份集群之前,你必须先学会HBase on S3的部署方法,本段为那些不熟悉HBase on S3架构的人提供了一些基本信息。 你可以通过将S3作为HBase的存储层,来分离集群的存储和计算节点。这使得你可以根据计算需求来规划集群,从而削减开支,毕竟你不再需要为HDFS上存储的3备份数据支付费用了。 HBase on S3架构中的默认EMR配置使用内存和本地磁盘来缓存数据,以此来提升基于S3的读性能。你可以在不影响底层存储的情况下任意地对计算节点进行伸缩,或者你还可以关闭集群来节省开支,然后快速地在另一个AZ中重新进行部署。 HBase on S3读备份集群应用案例 使用HBase on S3架构使得你的数据被安全、可靠地存储起来。它将数据和集群隔离进行存储,消除了因为集群异常终止带来数据丢失的可能性。尽管如此,在一些特殊情况下,你还是会希望数据能获得更高的可用性,比如集群异常终止或者整个AZ失效。另外一个情况是,通过多个集群访问一个S3上的根目录,你可以隔离HBase集群的读写操作,从而来降低集群的压力,提供更高SLA的查询服务。尤其是在主集群因为bulk load、heavy write、compaction等操作变得异常繁忙的时候。 下图展示了没有读备份的HBase on S3架构,在这个场景下,诸如集群终止和AZ失效等异常情况会使得用户无法访问数据。 S3上的HBase根目录,包含了HFile和表的原数据信息。 EMR 5.7.0之前的版本,无法将多个HBase集群指向同一个S3上的根目录,为了获得更高的可用性,你需要在S3上创建多个数据副本,并管理它们之间的一致性。 随着EMR 5.7.0的发布,现在你可以启动多个读备份集群并指向S3桶上同一个根目录,保证了你的数据通过读备份集群它们总是可达的。 下面是一些使用HBase读备份集群的例子,展示了启用前后的一些对比情况。 处于同一个AZ的HBase读备份集群: 处于不同AZ的HBase读备份集群: 基于S3的HBase读备份集群的另一个好处是可以更加灵活地根据具体的工作负载来规划你的集群。比如,虽然你的读负载很低,但还是想要获得更高的可用性,那么就可以启动一个由较小实例组成的规模较小的集群。另一个例子是当你遭遇bulk load时,在高峰期集群需要扩张到很大以满足计算需求,在bulk load结束后,集群可以立即缩减以节省开支。在主集群伸缩的时候,读备份集群可以维持一个固定的规模以对外提供稳定的查询服务。 步骤 使用下列的步骤来启动基于S3 的HBase读备份集群,这项功能只针对EMR 5.7.0之后的版本。 创建使用HBase on […]

Read More

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

作者:薛峰 上一篇文章中我们介绍了AWS 无服务器应用模型和SAM模板的基本功能和特性,并带领大家用一个实例体验了通过CloudFormation部署SAM模板。在这一篇中,我们仍然结合实例讲解,为大家继续介绍使用AWS CodeBuild 构建 Lambda函数以及使用AWS CodePipeline实现自动化持续集成。 部署配置AWS CodeBuild 如果我们的Lambda函数使用了依赖库时,我们可以通过AWS CodeBuild来把依赖库编译进Lambda函数的部署包里。 AWS CodeBuild  是一个完全托管的构建服务,可用于编写源代码、运行测试并生成可立即部署的软件包。CodeBuild基于AWS管理的容器,从而实现用户无需配置、管理和扩展自己的构建服务器。CodeBuild 可持续缩放和并行处理多个生成任务,因此构建任务不必在队列中等待。使用CodeBuild,我们只需要按构建时使用计算资源的分钟数付费,从而无需为预置的构建服务器的空闲时间付费。 除了常见的Java之类的程序源码的构建,CodeBuild还可用于Lambda函数部署前的构建。下面我们用一个例子来具体说明。 请先从以下git库下载源码。 https://github.com/xfsnow/serverless/tree/master/sam/codebuild 这个例子中的Lambda函数需要Node.js 依赖库 time,我们使用CodeBuild在构建时安装这个这个time库,把它加入到 Lambda 函数的包中。 index.js 文件中以下这行,表示需要依赖库 time。 var time = require(‘time’); buildspec.yml 中 install: commands: – npm install time 表示在构建的安装步骤把 time 库安装进来。 build: commands: – aws cloudformation package –template-file codebuild.yaml –s3-bucket <bucket-name> –output-template-file output_codebuild.yaml 这段其实就是使用在上一章节我们介绍过的aws cloudformation […]

Read More

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

作者:薛峰 背景介绍 AWS无服务器架构也涉及到多个AWS服务,如AWS Lambda、Amazon API Gateway、Amazon DynamoDB等。如何把这些服务资源方便地管理起来呢?今天我们介绍的AWS 无服务器应用模型(AWS Serverless Application Model,以下简称AWS SAM)就是一种解决方案,它是一个开源的模型,结合AWS自动运维相关的服务如AWS CloudFormation 和AWS CodePipeline,统一管理多种资源,实现我们的无服务器应用的持续集成和部署。 我们从SAM开始,用几个具体例子为大家介绍使用AWS服务实现持续集成的具体方法,帮助大家快速上手,体验其强大和便捷。 SAM 简介 松鼠SAM是AWS Lamba和无服务器应用模型的吉祥物,寓意轻便、灵活、敏捷。它头顶的头盔上是希腊字母 lambda ,代表了AWS无服务器核心服务 Lambda。 SAM是 AWS 2016年11月发布的一个应用架构模型。遵循开源协议,是一个开放的说明文档。通过开源协议方式发布,也体现了AWS推动开源流动的努力。 官方的github地址如下: https://github.com/awslabs/serverless-application-model SAM实质上是一个AWS CloudFormation 的扩展,基于AWS CloudFormation 并且为无服务器做了优化,它简化了无服务器资源的管理,增加了无服务器相关的新资源类型。 SAM模板简介 AWS CloudFormation标准模板语法比较复杂,SAM模板提供了一套简化的语法,我们先来看一个简单的例子: AWSTemplateFormatVersion: ‘2010-09-09’ Transform: AWS::Serverless-2016-10-31 Resources: GetHtmlFunction: Type: AWS::Serverless::Function Properties: CodeUri: s3://sam-demo-bucket/todo_list.zip Handler: index.gethtml Runtime: nodejs4.3 Policies: AmazonDynamoDBReadOnlyAccess Events: GetHtml: […]

Read More