亚马逊AWS官方博客

1.概述 Serverless即无服务器架构正在迅速举起，AWS Lambda 和AWS API Gateway作为Serverless 架构主要的服务，正受到广泛关注，也有越来越多用户使用它们，享受其带来的便利。传统上来说，Lambda 和API Gateway主要用以实现RESTful接口，其响应输出结果是JSON数据，而实际业务场景还有需要输出二进制数据流的情况，比如输出图片内容。本文以触发式图片处理服务为例，深入挖掘Lambda 和 API Gateway的最新功能，让它们支持二进制数据，展示无服务器架构更全面的服务能力。 先看一个经典架构的案例——响应式主动图片处理服务。 Lambda配合 S3 文件上传事件触发在后台进行图片处理，比如生成缩略图，然后再上传到 S3，这是Lambda用于事件触发的一个经典场景。 http://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html 在实际生产环境中这套架构还有一些局限，比如： 后台运行的图片处理可能无法保证及时完成，用户上传完原图后需要立即查看缩略图时还没有生成。 很多图片都是刚上传后使用频繁，一段时间以后就使用很少了，但是缩略图还不能删，因为也可能有少量使用，比如查看历史订单时。 客户端设备类型繁多，一次性生成所有尺寸的缩略图，会消耗较多Lambda运算时间和 S3存储。 如果增加了新的尺寸类型，旧图片要再生成新的缩略图就比较麻烦了。 我们使用用户触发的架构来实现实时图片处理服务，即当用户请求某个缩略图时实时生成该尺寸的缩略图，然后通过 CloudFront缓存在CDN上。这其实还是事件触发执行Lambda，只是由文件上传的事件主动触发，变成了用户访问的被动触发。但是只有原图存储在S3，任何尺寸的缩图都不生成文件不存储到S3。要实现此架构方案，核心技术点就是让Lambda和API Gateway可以响应输出二进制的图片数据流。 总体架构图如下： 主要技术点： 涉及服务都是AWS完全托管的，自动扩容，无需运维，尤其是 Lambda，按运算时间付费，省去 EC2 部署的繁琐。 原图存在 S3 上，只开放给 Lambda 的读取权限，禁止其它人访问原图，保护原图数据安全。 Lambda 实时生成缩略图，尽管Lambda目前还不支持直接输出二进制数据，我们可以设置让它输出base64编码后的文本，并且不再使用JSON结构。配合API Gateway可以把base64编码后的文本再转换回二进制数据，最终就可以实现输出二进制数据流了。 用 API Gateway 实现 图片访问的URL。我们常见的API Gateway用来做RESTful 的API接口，接口的 URL形式通常是 /resource?parameter=value，其实还可以配置成不用GET参数，而把URL中的路径部分作参数映射成后端的参数。 回源 API Gateway，缓存时间可以用户自定义，建议为24小时。直接支持 HTTPS，支持享用AWS全球边缘节点。 CloudFront […]

背景介绍 相信AWS的用户对AWS CloudFormation都不会陌生。AWS CloudFormation是实现IAC（Infrastructure as Code）自动化运维的一项重要服务，可以帮助用户对 AWS资源进行建模和设置，以便能花较少的时间管理这些资源。CloudFormation中有两个重要选项：Mappings段和Parameters段，可以帮助用户组织模板里的参数和映射，让用户更好地自定义堆栈，以实现模板的重用和复用。比方说可以用Mappings管理对应AWS上不同region的AMI ID，或者管理企业内部的不同部门。 但是当用户所在的组织越来越多地采用IAC自动化时，mappings和parameters的数量也会急剧增长，给CloudFormation模板的编写和维护带来复杂度。 解决方案 本文里我们介绍一种方法：用当前流行的Serverless计算AWS Lambda 和Amazon DynamoDB自动地管理AWS CloudFormation模板中的Parameters和Mappings。 本文中主要用到了以下几种 AWS服务： 1、DynamoDB表：Amazon DynamoDB是一个NoSQL数据库，这里我们采用它保存CloudFormation模板中所有的mappings和parameters。不仅可以实现集中存放，而且可以依赖DynamoDB的接口实现方便快速地增删和查找。比方说在我们的sample code中，整个企业采用这样一张表：partition key包括组名（比如说team1、team2等）和环境（比如说development、test、production等），sort key保存应用的名字。这个表里的数据类似这样： 当我们把这些数据都insert到DynamoDB中后，可以在AWS console里看到表中的内容是这样的： 2、Lambda方法：AWS Lambda又称为Serverless的计算，通过它你可以运行你的code而不需要预配置或者管理任何服务器。这里我们采用Lambda方法实现CloudFormation和DynamoDB之间的关联，它从CloudFormation模板接收primary key和sort key作为输入，查找DynamoDB表，并且返回所有的key-value数据。 3、Custom lookup resource：这是CloudFormation里的一个自定义资源，与一个Lambda方法绑定。CloudFormation除了可以定义已有的AWS资源，还支持几种自定义资源，包括这种以Lambda方法作为后端的自定义资源。当这种自定义资源创建、更新或者删除时，CloudFormation自动地向Lambda API发起请求，引发方法并将请求的数据传给Lambda方法，本例中所请求的数据是primary key，返回的数据是key-value数据。通常在一个组织中只需要建立这一个custom resource，所有的CloudFormation模板都可以复用它。下图是sample code里建立的custom resource： 让我们将这几种服务组合起来，并且定义好它们之间的交互顺序，整个解决方案就是下图展示的这样： 那么整个的交互顺序如下： 1、用户创建DynamoDB表，插入所需的mappings和parameters数据。 2、CloudFormation模板中的custom resource调用Lambda方法，用组名和环境名称（“teamname-environment”）作为partition key，用应用名称（”appname”）作为sort key。 3、Lambda方法用partition key和sort key作为输入查询DynamoDB表。 4、DyanamoDB将结果返回给Lambda方法。 5、Lambda方法将这些key-value数据作为结果返回给模板中的custom resource。 6、custom resource拿到数据后，堆栈里的其他资源可以通过Fn::GetAtt的方式获得这些数据。 结论 通过这种方式，可以将我们创建堆栈所需的固定部分保存在模板中，而将可变部分mappings和parameters保存在方便增删改查的DynamoDB中，用Lambda实现两者之间的关联。对于大型组织来说，这样可以提高运维效率，也是使用CloudFormation的一种最佳实践。 参考 可以在我们的网站上下载到相关的sample […]

负载均衡器在应用架构设计中是重要的组件，负责接收来自客户端的流量，将流量按一定的算法转发给后端的一组实例，并将后端实例的响应再返回给客户端。AWS提供一款托管的负载均衡服务， Elastic Load Balancer（简称ELB），ELB除了能够做负载均衡分发流量之外，还能对后端的实例健康检查，并将流量仅转发给通过健康检查的实例，同时ELB还能与自动扩展组（Auto Scaling Group）以及监控服务（CloudWatch）配合，设置根据后端实例CPU使用率的高低，流量大小，处理时间长短等指标，自动完成添加或缩减实例数量。 ELB又分两种，Classic ELB和Application Load Balancer（简称ALB），ELB的一个重要组件是侦听器，前者支持4层和7层的协议和端口（TCP，SSL，HTTP，HTTPS），对后端实例按轮询（TCP协议）或者最少未完成请求数（HTTP协议）的算法对后端实例进行流量转发。 ALB是应用层负载均衡器，支持HTTP/HTTPS的协议，与Classic ELB不同的是，ALB支持基于请求路径的分发，即根据HTTP标头的请求URL路径的不同，分发给后端不同的目标组（Target Group）。目标组是一个或多个目标（这里的“目标”可以是EC2实例）的集合，通常一组目标运行相同的应用或服务，一个目标可以注册到一个或多个目标组中。在目标组中可以配置运行状况检查，实例监控，等待连接耗尽及粘性会话等等。ALB中的规则决定了如何将流量路由到后端不同的目标组，每条规则对应一个目标组、条件及优先级，一旦匹配规则，则执行相应的流量路由，比如将请求URL中路径是/api的请求路由给运行api服务的目标组，将请求URL中路径是/mobile的访问路由给mobile的目标组。 两者的转发模型可见下图。 过去ALB仅支持基于请求路径的流量分发，客户为了实现基于主机名的分发往往使用多组Classic ELB或Classic ELB + Nginx集群的方式，现在ALB提供了新功能，即可以基于主机名进行路由分发，详情请参考: https://aws.amazon.com/cn/elasticloadbalancing/applicationloadbalancer/ 接下来，我们将详细介绍如何使用ALB完成基于主机名的流量分发。 本例中我们将创建以下资源： （1）1个ALB； （2）5个目标组，分别为api-prod，api-sandbox，mobile-prod，mobile-sandbox，default； （3）每个目标组注册不同的EC2实例，其中api-prod目标组将注册两个EC2实例； （4）一个侦听器； （5）创建基于主机名和路径的分发规则，实现流量的分发。 1、创建目标组 2、输入目标组名称，选择协议（HTTP/HTTPS）及端口，ALB所在的VPC，配置运行状况检查（协议，路径，阈值等）。此处我们选择了默认HTTP，路径/。 3、注册实例 目标组的重要实体是目标（比如说EC2实例），在此将实例注册到目标组下面，注意选中实例后点击”添加到已注册”，然后保存。此处我们选中了该目标组对应的实例ALBDemo_api_prod，ALBDemo_api_prod_2两个实例。您可以向一个或多个目标组注册多个目标实例以便满足需求。只要注册过程完成且新注册的目标实例通过初始运行状况检查，负载均衡器就会开始将请求路由至此目标。同样，您也可以从目标组取消目标注册。 同理创建api-sandbox，mobile-prod，mobile-sandbox，default目标组，此处省略创建过程。 创建完成后，选中目标组，在目标页我们可以看见注册到该目标组的实例的状态，healthy表示实例正常，另外该状态还有unhealthy（实例未通过健康检查），initial（实例注册中），unused（无流量传入，该目标组未注册到ALB）等。 4、创建负载均衡器 下面我们来创建ALB 5、选择ELB类型 这里我们选择应用程序负载均衡器ALB 6、配置负载均衡器 输入ALB名称，模式可选择该ALB面向Internet或是内部使用；配置侦听器协议，端口，根据需要可以配置多个侦听器，此处我们选择HTTP/80；同时选择ALB部署在哪个可用区及子网，建议多可用区方式部署，同样将应用部署在多可用区，达到高可用的设计目标。 7、配置安全设置 如果侦听器配置了HTTPS，需要配置证书。使用HTTPS，ELB可以完成与客户端的SSL安全连接的建立与SSL卸载，减轻后端服务器的压力。 如果从ACM（AWS Certificate Manager）申请过证书，则可以直接选择该证书，也可以自己上传证书到IAM或者在此上传证书。由于此次我们仅配置了HTTP 80端口侦听器，此处将不配置证书。配置安全证书的截图如下： 8、配置安全组 安全组的概念及用法此处不做复述，我们可以为ALB配置安全组，仅允许指定的协议、端口及来源的流量进入ALB 9、配置路由 这里可以选择”现有目标组”，选择我们前面的创建的default目标组。此处只能选择一个目标组，我们可以在创建完成后，对此ALB添加编辑规则的时候对应路由规则添加目标组。 10、注册目标 11、审核 创建完成后，可以在负载均衡器的控制台看到该ALB的相关描述与信息。 12、配置规则 选中该ALB，在页面下方的侦听器下按端口选择“查看/编辑规则”。 13、添加/编辑规则 […]

Amazon Virtual Private Cloud (Amazon VPC) 是 AWS 提供的虚拟私有网络服务，允许您在 AWS 云中预配置出一个采用逻辑隔离的部分，让您在自己定义的虚拟网络中启动 AWS 资源。您可以完全掌控您的虚拟联网环境，包括选择自有的 IP 地址范围、创建子网，以及配置路由表和网关。 除了提供IP资源及网络连接，Amazon VPC还提供DNS及DHCP等基础设施服务。当您将实例启动到默认 VPC 中时，我们为实例提供与其公有 IPv4 和私有 IPv4 地址对应的公有和私有 DNS 主机名。当您在非默认 VPC 中启动实例时，我们会为实例提供私有 DNS 主机名，并根据您为 VPC 和实例指定的设置来决定是否提供公有 DNS 主机名。 对于 us-east-1 区域，公有 (外部) DNS 主机名采用 ec2-<public-ipv4-address>.compute-1.amazonaws.com 形式，对于其他区域，则采用 ec2-<public-ipv4-address>.region.amazonaws.com 形式。例如，公有IP为54.222.212.110的EC2实例，其公有DNS名为ec2-54-222-212-110.cn-north-1.compute.amazonaws.com.cn。我们将公有 DNS 主机名解析为该实例在所在网络外的公有 IPv4 地址及其在所在网络内的私有 IPv4 地址。 私有 (内部) DNS 主机名解析为实例的私有 IPv4 地址，并对 […]

Twitch 是当今面向开发人员、玩家和艺术家的领先社区流媒体视频平台之一。每天有数百万人在访问 Twitch，通过与其他热情洋溢的在线流媒体参与者一起加入实时研讨会，观看他人的媒体并讨论他们的爱好。Amazon Web Services 也融入到这股潮流中，于去年 11 月份增设了 AWS Twitch 频道，将最新的 AWS 技术带给众多 Twitch 粉丝。AWS Twitch 频道每周都会开展各种实时互动式编程和制作者研讨会，专门面向不同等级的云爱好者。有关即将进行的研讨会系列和以前广播的详细信息，或者希望见到我们的团队，请访问 https://aws.amazon.com/twitch/。 AWS Twitch 频道在全年将会有许多节目，每个节目都有不同的主题、主持人和话题。目前，有两个节目可供您收看：使用 AWS 实时编写代码和 AWS Maker Studio 节目。在使用 AWS 实时编写代码节目中，技术传播者 Randall Hunt、Julio Faerman 和 Abby Fuller 从开发人员的角度构建几乎涵盖所有 AWS 服务的应用程序和解决方案。作为一名 Twitch 粉丝，您在观看节目时能够利用一项非常好的功能，也就是可以确定播放的位置。此外，来自 Amazon、AWS 和社区的贵宾将加入到我们的 Twitch 主讲人队伍中，讨论如何在 AWS 平台上构建非常棒的新项目和实施。AWS Maker Studio 在 5 月 17 日首次播出节目，并为我们的所有人介绍专门面向制作者的项目和解决方案。主讲人 Todd Varland、Trevor […]

我每个月都会多次在西雅图的执行简报中心与 AWS 客户畅谈。我会介绍我们的创新过程，并讨论如何根据客户的要求和反馈更好地制定每个 AWS 产品的路线图。一个很好的例子就是，在我们的努力下，AWS 已经成为 SAP 业务解决方案产品组合的理想平台。多年来，我们的客户向我们透露，他们在 AWS 中运行大规模 SAP 生产应用程序，而我们一直努力为他们提供旨在满足其工作负载的 EC2 实例。由于 SAP 安装始终是任务关键型应用产品，因此 SAP 对其产品可以在特定类型和大小的 EC2 实例上使用进行认证。我们直接与 SAP 合作以取得认证，并使 AWS 成为运行其产品的强大可靠的平台。下面快速回顾我们在这个领域的一些最重要的公告： 2012 年 6 月 – 我们扩大了在 AWS 上提供的经过 SAP 认证的解决方案系列。2012 年 10 月 – 我们宣布 SAP HANA 内存中数据库现在可以在 AWS 上开展生产运行。2014 年 3 月 – 我们宣布，SAP HANA 现在可以在具有高达 244 GB 内存的 cr1.8xlarge […]

信息安全现状 时钟进入到2017年，物联网安全，DDoS攻击和勒索软件被越来越多的国内外信息安全预测机构列为年度最大信息安全威胁。上周爆发的勒索软件WannaCry （又称作永恒之蓝）已席卷全球99个国家，让各类技术宅男们和信息安全的童鞋们又错过了一个美好的周末。尽管目前该病毒已被安全人员找到了阻止其传播的方法，但是类似的安全事件依然给我们敲响了云端安全运维的警钟。 WannaCry事件回顾，5月12日晚， WannaCry 蠕虫病毒在全球大肆爆发。据外媒报道，攻击在99个国家实施了超过75000次攻击。该攻击利用漏洞MS17-010中的某些版本的SMB服务器协议进行传播，利用Windows 445 端口的安全漏洞潜入电脑并对多种文件类型加密并使用户无法打开，攻击者称需支付比特币解锁，补丁程序已于2017年3月14日发布，但未打补丁的用户有可能遭受此次攻击。通过这个事件我们发现只要是购买正版操作系统并及时更新补丁的用户，都不会受到影响。永久解决办法有2个，1.开启windows的自动更新功能，将最新补丁打上； 2.对于部分比较老的windows系统可以手动下载更新包并安装。 这样的安全事件不是第一次也不会是最后一次，要确保我们的信息安全，需要做的事情有太多，比如完善的信息安全应对机制，一系列自动化运维工具或服务，坚决的执行能力以及定期的审核机制。如果你恰好开始关心信息安全，而我们又专业，不妨看看AWS是如何看待信息安全的。 AWS信息安全理念 数据属于谁？ 虽然是一个老生常谈的问题，但确实一个非常重要的问题，而且答案永远只有一个，数据属于客户。当你上云之后，如何确保你的数据真的属于你是很多客户评估是否上云时最纠结的问题！在AWS，你可以非常清晰的从上图中看到这个界限。所有操作系统以上（包括操作系统本身）的内容都是客户自己自主可控，AWS没有任何权限访问，同时如果你使用的是AWS提供的Windows或者Linux镜像，该镜像 的补丁机制是全球一致管理的，我们会从各个合作厂商那得到补丁，并第一时间更新到镜像里。如果是开篇提到的流氓攻击，在AWS上的客户可以不需要担心了，因为该补丁在镜像中自动更新了。 如何确保我在云上是安全的？ 如何数据安全可能是一个说上三天三夜都没法说完的话题，今天我们从AWS信息安全最佳实践出发，给大家从几个层面来分析信息安全的层级，并重点介绍如何帮助客户在理解理念之后的安全落地问题。首先我们可以看到在云上我们需要这么几个维度的安全，底层基础架构的安全，网络的安全，权限及审计的安全，服务本身的安全，事先预防等等。总之，信息安全从来都不是靠说的，而是靠做的，所以接下来我们给大家做一些简单示范，让你在使用AWS时更加得心应手。 底层基础架构的安全 熟悉AWS的同学可能知道，AWS底层的虚拟化平台使用的是Xen，套用一句官话，不管我们的工程师是多么的小心，我们依然需要时刻告知我们的客户对于AWS服务底层安全的疑虑，所以大家可以在以下链接找到关于Xen的信息安全公告，同时大家也可以从AWS信息安全白皮书中看到AWS如何对于底层基础架构的安全设计，限于篇幅的原因本文不作展开。 Xen Security Advisiories https://aws.amazon.com/cn/security/security-bulletins/ AWS Security Best Practices https://d0.awsstatic.com/whitepapers/aws-security-whitepaper.pdf 网络安全 上云的安全 当你的数据需要上云时，你有三种非常安全的方式来传输您的数据，通过TLS加密的HTTPS协议将数据直接通过互联网传输到S3， 建立专用VPN进行数据传输以及通过专线将AWS与您的数据中心打通，并将AWS纳入您现有的全球专线网络中，让你全球任何一个办公室或者数据中心都通过内网的方式随时的安全访问云端的数据或者系统，如同您多了一个拥有无限扩展能力的远端数据中心。 云上的安全 当您的数据或者系统已经部署在AWS上时，你可以通过上图的简单示意图来对您的系统进行网络隔离及控制。比如，你可以按照不同的应用划分不同的VPC，不同的VPC之间网络隔离，同时在同一个VPC内设置不同安全级别网络区域，如公有访问区，DMZ区，私有网络区。利用VPC内的免费防火墙工具安全组，网络ACL来对云端的机器及网段进行精细化控制。如图上的例子，你可以通过图形界面在安全组上关闭该机器137,139,445 端口就能轻松的规避本文开篇提到的流氓攻击。如果您确实需要开启这些端口，也可以在安全组内指定对具体的源IP开放端口，或者将这些机器放置在私有网段，当这些私有网段的机器需要访问互联网的某些站点进行补丁升级等操作时，通过NAT的方式允许VPC的出向流量。 如果您还需要对VPC内不同私有网段的机器访问进行更精细化控制，还可以通过另外一个免费的防火墙网络ACL来实现。 当您的网络与AWS云端VPC通过VPN或者专线联通时，你还可以通过路由表来控制您哪些数据中心的网段可以访问云端的哪些网段。 权限及审计安全 当你的业务上云后，你可能面临不同人员需要管理你云端资源，这些人可能包括，您公司的开发人员，运维人员，财务部，人事部以及您外部形形色色的服务供应商或者运维外包供应商，如何给予这些人员适当权限去访问他们需要访问的AWS资源以及事后审核这些人员的访问情况，是很多企业客户迫切需要解决问题。 AWS IAM不但可以轻松解决上述所有访问权限问题，还可以帮您打通绝大部分企业遇到的SSO问题，让你数据中心的AD或者第三方机构与AWS建立授权机制，当您的用户在本地AD通过验证后，直接访问AWS上的数据，无需重复创建用户。同时可以给所有IAM用户开启复杂密码功能，并强制用户每隔一段时间修改密码。 内审或者外审通常是一个企业每年必做的事情，在AWS只需开启CloudTrail服务就可以自动记录所有AWS资源的使用情况，下图是一个CloudTrail的简单示例，我们可以看到什么时间哪个用户对什么资源做了什么事情。 同时还可以进一步查看某个事件的详细信息，便于审核，如下图所示： 服务本身的安全机制 由于AWS服务众多，限于篇幅的原因，本文重点讲解AWS虚拟机(EC2)的安全，如您对其他服务也很感兴趣，欢迎阅读AWS安全白皮书。 AWS Security Best Practices https://d0.awsstatic.com/whitepapers/aws-security-whitepaper.pdf      Amazon EC2多层安全模型 Amazon EC2多层安全模型包含底层物理服务器的操作系统，虚拟操作系统或者客户操作系统，防火墙和签名的API调用。目标是防止EC2内的数据被未授权的系统或者用户访问，在不牺牲客户配置灵活性的时，尽最大限度保证EC2本身的安全。 Amazon EC2当前利用了一个AWS高度定制化的Xen […]

1. 前言 AWS最近刚刚宣布了一项关于数据库迁移的新feature，支持Mongodb数据库作为源端，迁移到目标端Dynamodb中，这样可以使MongoDB的用户充分利用DynamoDB数据库提供的技术优势，譬如完全托管服务，高性能低延迟（毫秒级），精细化粒度控制等等。由于最近项目中涉及很多数据库迁移的事情，同时也对NOSQL数据库异构平台迁移非常感兴趣，写了这篇文档供大家参考。 2. DMS服务介绍 DMS作为数据迁移服务支持下面三种迁移类型： 迁移源库中存在的数据到目标库 迁移源库中存在的数据并且复制新增加的数据到目标库 只复制新增加的数据库 数据迁移时源端和目标端设置 MongoDB作为源端 AWS DMS支持Mongodb作为源端的版本为2.6.x和3.0.x，MongoDB 作为一个基于文档存储的数据库，数据模式非常灵活，支持JSON和BJSON格式进行存储。当前AWS DMS 支持MongoDB作为源端以两种模式进行迁移，它们分别是文档模式和表模式。在文档模式中，需要设置参数extractDocID＝true和nestingLevel＝none，在复制时不支持collection的重命名。在表模式中需要启用表模式需要设置nestingLevel＝one，另外在选择CDC时它不支持添加新的collection和重名collection。 DynamoDB作为目标端 使用Dynamodb作为目标端时需要配置partion key和Object mapping。 具体注意事项请参考官方文档链接： http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MongoDB.html 3. 配置步骤 3.1 安装Mongodb 安装Mongodb的方式有多种方法，可以选择Marketplace或者AWS提供的cloudformation以及手动下载Mongodb软件进行安装，我选择手动安装Mongodb2.6.12版本。 A、登录EC2，获取如下软件： ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org_2.6.12_amd64.deb ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-mongos_2.6.12_amd64.deb ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-tools_2.6.12_amd64.deb ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-server_2.6.12_amd64.deb ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-shell_2.6.12_amd64.deb B、安装软件包： ubuntu@ip-172-31-60-214:~$ sudo dpkg -i mongodb-org* C、创建数据目录和日志目录： ubuntu@ip-172-31-60-214:~$ sudo mkdir /data /log […]

相信大家已经都知道，Amazon DynamoDB 是一项全托管的NoSQL 数据库服务，适合所有需要一致性且延迟低于 10 毫秒的任意规模的应用程序，支持文档和键值存储模型。使用DynamoDB，可创建数据库表来存储和检索任意量级的数据，并提供任意级别的请求流量。现在，DynamoDB还提供了Auto-Scaling的功能，即可以通过你预先设置的阈值自动扩展和缩减表的吞吐量，做到完全弹性自动伸缩的目的，真正达到让你的数据库按实际吞吐量进行付费。 这么高的并发量却依然可以保持服务器的平均延迟在个位数毫秒，这让DynamoDB受到了非常多用户的青睐。然而随着大数据时代的数据暴增，很多客户的场景比较特殊，他们对数据库的响应时间越来越苛刻，甚至需要达到微秒的级别！这无疑给DynamoDB数据库又带来了一个难题。甚至也有客户会提到，能不能在DynamoDB前面放一层类似Redis的Cache服务呢？如果这样做的话，需要自己搭建缓存数据库，并且解决DynamoDB和Redis之间的数据同步问题；同时还要重写代码实现业务逻辑，比如如果数据在缓存中，则立即返回，如果数据没有在缓存中，则必须从数据库里面读取，将数据写入到缓存中，然后再返回。 当用户还带着这样的担心时，现在，Amazon DynamoDB已经整合了这一特性，推出了一个新的功能，即Amazon DynamoDB Accelerator，简称DAX。这是一种完全托管并且高度可靠的内存缓存，即使每秒种的请求量达到数百万，却依然可以将Amazon DynamoDB的响应时间从数毫秒缩短到数微秒！其实在很多场景都可以用到DAX，比如实时竞拍、秒杀、电商、社交游戏等场景，DAX可以提供快速的内存读取性能；再比如在产品促销日，读取访问量会明显上升，但是销售日结束访问量就会回归正常，诸如此类读取密集型的工作负载但同时又对成本敏感的应用都可以使用DAX服务。像类似于Expedia、Twilio、Genesys、eyeview等客户都已经率先用上了DAX服务 目前，DAX还是处于预览版，您可以点击链接进行申请。接下来，让我们创建一个DAX集群，赶紧体验一下微秒级别的响应测试吧！ 1. DAX集群的原理 上图中可以看到，DAX起了一组缓存的节点（目前最多可以是10个节点），并将这些节点置放在VPC内部，应用程序部署在EC2上，这样EC2和DAX Cluster通过内网直接访问。关于DAX的内存缓存，主要是DynamoDB的读和写操作： （1）最终一致性的读取操作，支持GetItem、BatchGetItem、Query、Scan接口，如果读取在DAX缓存中命中，将直接从DAX集群里读取；如果是第一次读取没有命中，那就从DyanmoDB里面读取。 （2）写入操作支持BatchWriteItem、UpdateItem、DeleteItem、PutItem接口，写入的时候数据先写入到DynamoDB表，确认写入成功之后，然后再写到DAX集群（item cache），这个操作只有在DynamoDB表和DAX集群都写入了数据的时候才算成功。如果由于一些原因这个操作失败了，那么这个item将不会缓存到DAX里面，并且会抛出一个exception。这种方式可以让缓存和数据库的数据保持一致性和完整性，不会出现过期数据在缓存里面。 （3）如果DAX有多个节点时，会选取一个主节点（primary node），多个从节点（read replica node），数据最终会分布到所有节点上，但对于客户端来说，只需要关心唯一的DAX连接地址，已经内置了负载均衡和路由策略，并且自动执行故障检测、故障恢复、软件修补等管理任务。 接下去，我们将模拟这一过程，进行实际测试。 2. 启动DAX集群 首先启动一个DAX集群，指定集群的节点数（目前节点最多为10个），我们建议您在生产环节中启用两个以上的节点，并将这些节点置放在不同的可用区中，从而提高高可用。设置好相应的IAM Role和Policy。Policy可以配置“只读”权限，或者“读和写”权限。更多关于权限配置可以参考: http://s3.amazonaws.com/dynamodb-preview-dax/DAX.access-control.html 接下去设置DAX集群的子网组，DAX集群的节点会部署在这些子网里面。选定VPC和相对应的子网，并设置安全组。安全组入站需要打开DAX所用到的8111端口。 接下去配置DAX的参数组，指定Cache的Query TTL和Item TTL值。TTL的时间小到可以是“秒”，大到可以到“天”。 也可以自定义选定维护窗口，如果需要的话可以再加一个SNS通知，这样只要集群有维护就会立刻以短信，或者邮件等形式通知到您。 到这里，DAX集群就创建成功了。DAX集群会有一个唯一的endpoint地址，例如，这里是 dax-cluster-demo.bnsilv.clustercfg.dax.usw2.cache.amazonaws.com:8111 另外可以看到在这个例子中DAX集群启动了3个节点。 DAX集群具体的3个节点 3. 启动EC2 ，作为应用程序的server，同时作为DAX的client 如果仅作为测试，可以启动一台t2.micro的小型机器（Amazon Linux）。 EC2通过监控检查，启动成功。 4. 安装Java应用程序 （1）首先通过客户端连接到这台Amazon Linux EC2 （2）安装Java SDK sudo yum install […]

背景 在Amazon Redshift 数据仓库为核心的用户，常常陷入一个困境，要想利用该MPP架构的云端数据仓库能力，用户通常需要利用Redshift的 copy命令将数据从S3并行拷贝到Redshift中，如果在数据量比较大的情况下，成本上的考量和业务上的诉求的矛盾会让用户犹豫不定； 尤其突出的矛盾是，客户的业务部门的需求涵盖数据范围同时包含数据仓库的数据和放在S3上的中间或者原始数据集，此时，我们能怎么做？ AWS大数据最佳实践的启示 AWS大数据最佳实践告诉我们要将数据的存储和处理、分析相分离，比如在Amazon EMR服务架构中（如下图），要分析的数据集按照一定的格式压缩存储在Amazon S3上，在EMR中通过Hive定义外表关联到S3上的数据，但不复制到EMR本地，从而实现了数据存储和分析处理的解耦；在大量的用户实践中，我们发现如此的架构优化，可以帮助客户节约大量的存储成本，同时，EMR分析集群无状态化，可以按需动态启动和停止EMR集群，从而优化了计算成本。同理，我们能否在Redshift数据仓库中引入类似的外部表的概念呢？ Amazon Redshift Spectrum简介 Amazon Redshift Spectrum是Redshift的一个新特性，它可以帮助客户将Redshift的分析能力从本地存储扩展到Amazon S3数据湖中海量的非结构化数据而不需要加载数据。通过Redshift Spectrum您可以将热数据存储到 Amazon Redshift 群集中，以获得本地磁盘性能；同时使用 Amazon Redshift Spectrum 将您的查询扩展到 Amazon S3 中存储的冷数据，以获得无限的可扩展性和低成本。 详细情况请参考官方介绍：https://aws.amazon.com/cn/redshift/spectrum/ 目标人群及应用场景 该新功能的推出完善了Redshift数据仓库用户的大数据分析的应用场景，客户可以直接利用Redshift和Redshift Spectrum的能力同时处理本地和S3上的数据集；所以，目标受众是Redshift数据仓库的用户比如金融，电商，游戏等等行业客户。 从应用场景来看，可以满足如下业务需求： 针对数据仓库本地数据和S3上的数据提供一致的、熟悉的数据仓库操作体验 提供终端用户统一的BI或者SQL客户端接入 跨数据仓库热数据和S3冷数据的复杂混合查询 满足低频的业务全数据的低成本即席查询 大数据处理示例管道 本大数据处理示例管道展示了以Redshift数据仓库为核心的典型用户场景，原始数据，中间结果和ETL处理之后的数据都保存在数据湖Amazon S3上；用户通过BI工具或者熟悉的SQL客户端通过Redshift（包括Redshift Spectrum）操作所有的业务数据，包括大数据量的原始数据和存储在数据仓库本地的热数据；客户无需专门为了某个业务的特殊需求，将数据从冷数据从S3复制到Redshift本地再作分析。 支持的数据格式 Redshift Spectrum 使用您已使用的开发数据格式在 Amazon S3 中直接查询数据，这些格式包括 文本文件如 CSV格式文件 日志文件如TSV格式 列式格式如Apache Parquet和Hive中的RCFile格式文件 二进制文件：Sequence格式文件 压缩格式支持：gzip、snappy、bz2 […]