亚马逊AWS官方博客

AWS Team

Author: AWS Team

AWS Marketplace 中的 Box 平台 – Lambda 蓝图和示例代码

Box 是一个基于云的文件共享和内容管理系统,具有一个最近已在 AWS Marketplace 中提供的 API (Box 平台 – 云内容管理 API)。凭借一系列协作相关功能的推出,以及对安全性的重视,Box 已经在许多企业中得到了广泛应用 (请参见其成功案例页面中的列表)。 Box API 允许开发人员将内容体验构建到 Web 和移动应用程序中。今天我想向您介绍一些 [lambda] 蓝图和模板,这些蓝图和模板将可以帮助您在构建 AWS 应用程序时使用此 API 来简化用户身份验证和将元数据添加到新上传的内容中。这些模板基于 Box 节点 Lambda 示例而创建,可作为您开发工作的一个强大起点。我们来看一看这些蓝图,顺便查看一些我们在 Box 的好友所撰写的博客文章。 适用于 Lambda 的 Box 蓝图 蓝图显示了您如何通过 [apigateway] 调用 Box API 和将 Box webhook 连接到 Lambda 函数。要找到它们,请直接打开 Lambda 控制台,搜索 box: 第一个蓝图使用存储在 BOX_CONFIG 环境变量中的安全凭证。您可以从 Lambda 控制台内设置此变量: 此蓝图中的代码会检索并记录通过凭证确定的用户的 […]

Read More

全新推出 – Auto Scaling for Amazon DynamoDB

Amazon DynamoDB 拥有十万多的客户,客户身处各种行业,使用案例也各不相同。这些客户依赖于 DynamoDB 在任何规模下都能提供的一致性能和覆盖全球 16 个地理区域的服务网络。最近我们注意到一个趋势,客户正在使用 DynamoDB 来为他们的无服务器应用程序提供支持。这是一个很好的搭配:使用 DynamoDB,您无需考虑配置服务器、执行操作系统和数据库软件修补或跨可用区配置复制以确保高可用性之类的事情 – 您只需创建一些表,然后开始添加数据,其他的交给 DynamoDB 处理。 DynamoDB 提供预置容量模式,可以让您设定您的应用程序所需的读取和写入容量。尽管这让您无需考虑服务器,在 AWS管理控制台中进行简单的 API 调用或按钮单击就可以对表的配置进行更改,但客户已经在询问我们,有没有方法让管理 DynamoDB 容量变得更加轻松。 现在,我们推出了 Auto Scaling for DynamoDB,可帮助您实现表和全局二级索引容量管理的自动化。您只要指定所需的目标使用率,并提供读取和写入容量的上限和下限。之后,DynamoDB 将利用 Amazon Cloudwatch 警报来监控吞吐量占用情况,并根据需要上调或下调预置容量。Auto Scaling 对于所有新表和索引默认启用,您还可以对现有表和索引配置此功能。即使您不在左右,DynamoDB Auto Scaling 也将监控您的表和索引,并根据应用程序流量的变化自动调整吞吐量。这使您可以更加轻松地管理 DynamoDB 数据,帮助您最大程度地提高应用程序的可用性,并帮助您降低 DynamoDB 成本。我们来看看它是如何工作的…… 使用 Auto Scaling 现在当您创建新表时,DynamoDB 控制台会提出一组适宜的默认参数。您可以原样接受它们,也可以取消选中“Use default settings”,然后输入您自己的参数: 以下是您输入自己的参数的方式: 目标使用率以占用容量与预置容量的比值来表示。以上参数将允许提供足够的空间,使占用容量能够在读取或写入请求突增时倍增 (请参阅容量单位计算,了解更多有关 DynamoDB 读取和写入操作与预置容量之间关系的信息)。预置容量的变化是在后台发生的。 Auto Scaling 的实际操作 为了了解这项重要的新功能的实际操作,我按照入门指南中的指示进行了操作。我启动了一个全新的 […]

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

利用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

使用 Amazon Redshift 中的查询监控规则管理查询工作负载

本文主要介绍了如何利用Amazon Redshift的WLM(工作负载管理)功能,监控数据仓库的查询性能,从而优化队列优先级并保障关键任务的执行。本文还列出了三个常见场景,给出了简单的配置过程。 众所周知,数据仓库的工作负载由于周期性、潜在高开销的数据探索查询以及SQL开发人员不同的技能水平等会出现比较大的性能变化。 为了在面临高度变化的工作负载下仍然能使Redshift集群获得较高的性能,Amazon Redshift工作负载管理(WLM)使您能够灵活地管理任务优先级和资源使用情况。通过配置WLM,短时间,快速运行的查询不会停留在需要较长时间运行的查询之后的队列中。 但尽管如此,某些查询有时可能会陷入不相称的资源分配,并影响系统中的其他查询。 这种查询通常被称为流氓查询或失控查询。 虽然WLM提供了一种限制内存使用并将超时查询移动到其他队列的方法,但多重精细控制依然很需要。您现在可以使用query monitoring rules查询监视规则为查询创建资源使用规则,监视查询的资源使用情况,然后在查询违反规则时执行操作。 工作负载管理并发和查询监控规则 在Amazon Redshift环境中,单个集群最多可以同时连接500个连接。 吞吐量(Throughput)通常表示为每小时的查询量以最大化性能,但像MySQL这样的行数据库使用并发连接数进行衡量。 在Amazon Redshift中,工作负载管理(WLM)可以最大限度地提高吞吐量,而不太考虑并发性。 WLM有两个主要部分:队列和并发。 队列允许您在用户组或查询组级别分配内存。 并发或内存是如何进一步细分和分配内存到一个查询。 例如,假设您有一个并发度为10的队列(100%内存分配)。这意味着每个查询最多可以获得10%的内存。 如果大部分查询需要20%的内存,那么这些查询将交换到磁盘,导致较低的吞吐量。 但是,如果将并发度降低到5,则每个查询分配20%的内存,并且最终结果是更高的吞吐量和更快的SQL客户端响应时间。 当从行数据库切换到基于列的数据库的时候,常见的错误认知是认为更高的并发性将产生更好的性能。 现在你了解了并发性,这里有更多关于查询监控规则的细节。 您可以基于资源使用情况定义规则,如果查询违反了该规则,则会执行相应的操作。 可以使用十二种不同的资源使用指标,例如查询使用CPU,查询执行时间,扫描行数,返回行数,嵌套循环连接等。 每个规则包括最多三个条件,或谓词,和一个动作。谓词由一个指标,比较条件(=、<、>),和一个值组成。如果所有的谓词满足任何规则,该规则的行动被触发。可能的规则操作包括日志记录、跳过任务和中止任务。 这样就可以在导致严重问题前捕获流氓或失控查询。该规则触发一个动作来释放队列,从而提高吞吐量和响应速度。 例如,对于专用于短时运行查询的队列,您可能会创建一个规则来中止超过60秒的查询。 要跟踪设计不当的查询,您可能会有另一个规则记录包含嵌套循环的查询。 在Amazon Redshift控制台中有预定义的规则模板让您使用。 使用场景 使用查询监控规则来执行查询级别的操作,从简单地记录查询到中止查询,以下所有采取的操作都记录在STL_WLM_RULE_ACTION表中: 日志记录(log):记录信息并继续监视查询。 跳出(hog):终止查询,并重新启动下一个匹配队列。 如果没有其他匹配队列,查询将被取消。 中止(abort):中止违反规则的查询。 以下三个示例场景显示如何使用查询监视规则。 场景1:如何管理您临时查询队列中的未优化查询? 连接两个大表的失控查询可能返回十亿行或更多行。 您可以通过创建规则来中止返回超过十亿行的任何查询来保护您的临时队列。 在逻辑上如下所示: IF return_row_count > 1B rows then ABORT. 在以下截图中,任何返回BI_USER组中超过十亿行的查询都将中止。 场景2:如何管理和控制未调优的CPU密集型查询? 偶尔引起CPU飙升的查询不一定有问题。 然而,持续的高CPU使用率可能会导致其他并发运行查询的延迟时间增加。 例如,在较长时间内使用高百分比CPU的未调优查询可能是由于不正确的嵌套连接引起的。 […]

Read More

如何在Amazon EC2 Container Service上实现服务高可用的自动伸缩

1. 简介 Amazon EC2 Container Service (ECS)是Amazon提供的一项Docker容器管理服务,可以让您轻松构建、运行、管理您的Docker容器服务。ECS Service是ECS的重要组件,它可以在集群中运行指定数量的任务,当某个任务不可用时,它会重新启动新的任务,维持住任务的指定数量。这个特性从一定程度上保证了服务的可用性,但当面对突发流量,ECS本身并不能动态地进行任务数量的扩展,当流量较少时,ECS也无法动态地进行任务数量的缩减。为解决此问题,可以使用Auto Scaling和Amazon CloudWatch等实现服务的自动伸缩,保证服务高可用。本文将介绍一个运用Auto Scaling在ECS中实现服务高可用的方案,并通过对方案构建过程的剖析,让您对高可用、自动伸缩的服务架构有更进一步的了解。 2. 方案构建 2.1 整体结构图 本方案使用AWS CloudFormation模板声明整个资源堆栈所需资源和相关配置,并实现自动化构建。关于AWS CloudFormation相关知识,请通过以下链接了解:CloudFormation入门。 从上面这个结构图可以看出以下主要组成部分: 初始由两个跨AZ的Container Instance组成的ESC Cluster。 初始ESC Service中有两个task。 Service Auto Scaling与CloudWatch结合,当Service维度的 CPUUtilization与Threshold满足设定的触发条件时,触发CloudWatch Alarm,CloudWatch Alarm根据设定的Scaling Policy进行Task数量伸缩。 Auto Scaling Group与CloudWatch结合,当Cluster维度的CPUReservation与Threshold满足设定的触发条件时,触发CloudWatch Alarm,CloudWatch Alarm根据设定的Scaling Policy进行实例数量的伸缩。 2.2 准备工作 (1)准备好CloudFormation模板脚本 请从这里(点我)下载用于构建整个资源堆栈的模板脚本文件。 或者通过点击下面按钮来运行堆栈: (2)准备好Lambda Function 本方案在Auto Scaling Group中的实例关闭时,会调用一个实现自动切换Draining状态的Lambda Function。那么在构建整个堆栈之前,需要先准备好这个Lambda Function。这里我们使用Python编写了这个脚本auto_drain.py来实现此功能。您可以了载包含了这个脚本的压缩包(点我)。 下载完成后,请将它上传到您账户上同个Region的S3 Bucket中。记住这个S3 Bucket Name,在构建堆栈时,将它传给Lambda Function S3 […]

Read More

使用Amazon EC2 Systems Manager取代堡垒机

通常情况下,堡垒机(也称为“跳转机”)是在系统中访问私有主机的一个最佳实践。例如,您的系统可能包含一个不希望被公开访问的应用服务器,当需要在这台服务器上进行产品的更新或系统补丁程序的管理时,您通常会登录到堡垒机,然后从那里访问(即“跳转到”)应用服务器。 本文将向您介绍使用Amazon EC2 Systems Manager替换您的堡垒机,实现在服务器上运行命令的同时缩小系统攻击平面并获取更好的可见性。 堡垒机方案 堡垒机最好仅向特定的IP地址范围开放,这个地址范围通常可设定为您单位的企业网络。使用堡垒机的好处是,任何对内部服务器的访问都被限定到一种方式:通过单个或一组堡垒机。为了获取进一步的隔离,堡垒机通常被安放在单独的VPC中。 这种设计方案如下图所示: 应用服务器运行在与管理VPC对等相连的一个VPC的私有子网中。 应用服务器设定了一个安全组规则,其仅允许来自管理VPC中堡垒机所在安全组的22端口访问(本文的示例仅针对端口22和SSH访问。Windows用户可将其相应的替换为端口3389和RDP访问)。同样,堡垒机也设定了一个安全组规则,其仅允许来自公司网络IP地址空间的22端口访问。 由于应用服务器运行在私有子网中,所以它只能通过VPC公共子网中的NAT网关来建立出站公网连接。 假设您希望查看应用程序服务器的网络接口,您需要执行以下步骤: 将应用服务器的私钥安装在堡垒机上。 从可信网络(如公司网络)发起,在堡垒机上建立SSH会话。 从堡垒机发起,建立SSH会话到应用服务器。 运行“ifconfig”命令。 如需保存命令的结果,您可以复制和粘贴命令的输出,或者将输出重定向到文件。 这个方案中的安全措施限制了对应用服务器和堡垒机的访问,但堡垒机模式存在一些缺点: 像任何基础设施服务器一样,堡垒机必须进行管理和维护。 运行时会产生成本。 允许堡垒机访问的每个安全组都需要设置一个安全组入口规则,即SSH(用于Linux)的22端口或RDP的3389端口(用于Windows服务器)。 堡垒机和应用服务器的RSA密钥需要进行管理、保护和轮换。 SSH操作无缺省日志记录。 替代方案 Systems Manager允许您在被管理的服务器上远程执行命令,而不使用堡垒机(此功能称为EC2 Run Command)。安装于服务器上的代理程序会自动轮询Systems Manager以确定是否有命令在等待执行。 此方案具备以下优点: 使用AWS托管服务,这意味着Systems Manager组件具备高可用性。 Systems Manager通过IAM策略设定是否允许用户或角色远程执行命令。 Systems Manager代理程序需要IAM角色和策略才能允许它们调用Systems Manager服务。 Systems Manager不可更改的记录每个执行的命令,从而提供了可审计的命令历史,包括:  o   执行命令的内容  o   执行命令的主体  o   执行命令的时间  o   命令的输出摘要 当AWS CloudTrail在当前区域中启用时,CloudTrail会记录每个事件,并写入Amazon CloudWatch Logs。 使用CloudTrail和CloudWatch规则,您可以将Systems Manager事件用作自动响应的触发器,例如Amazon SNS通知或AWS Lambda函数调用。 […]

Read More

基于Amazon EC2 Container Service构建安全高可用的Docker私有库

1. 背景 Docker hub作为docker官方镜像仓库,提供了大量Docker镜像的托管服务。但使用它来托管企业私有Docker镜像存在一些问题,比如: (1)Docker hub托管私有镜像的服务目前只面对收费账户; (2)使用Docker hub托管私有镜像并不适合一些特殊场景,比如工作环境网络是内网,不允许访问外网,那就更不可能到Docker hub去下载镜像。 在这种情况下,如果能构建一个安全可靠的Docker私有库,将会是一个更好的选择。本文将介绍在Amazon EC2 Container Service基础上结合AWS Elastic LoadBalancer、AWS Autoscaling Group、AWS S3及Docker官方提供的registry镜像构建安全、高可用的Docker私有库的方案,帮助您轻构实现这一需求。 2. 方案详解 我们会使用AWS CloudFormation服务,使用自定义的模板脚本声明所需的资源,实现自动化构建。接下来结合我们的模板脚本对本方案进行详细介绍。 注意:以下内容与代码相关部分只贴出主要代码,部分代码用…表示省略;红字部分请替换成您自己账号相关的信息。 完整模板代码地址:https://s3-us-west-2.amazonaws.com/blog.leonli.org/registry.yml          或者点击按钮直接在控制台中运行: 2.1 架构图 根据以上架构图,基本数据传输过程为: (1)Docker客户端向镜像仓库发送的pull/push等命令事实上都是通过docker daemon转换成restful请求的形式再发送给镜像仓库的。在本架构中,我们利用AWS Elastic LoadBalancer(简称ELB)接收客户端发来的请求,作为整个架构的接入层。由于我们要求数据是通过TLS加密传输的,所以我们需要使用AWS IAM中的server certificate(由AWS IAM账户上传的TLS证书)与ELB关联,实现对客户端发来的请求进行加密。 (2)ELB会将请求反向代理给后端分布在不同可用区的两台Container Instance(安装了Docker运行环境的EC2实例),Container Instance中运行了Docker registry服务。当请求到达registry时,我们需要首先使用内置在registry中的用户认证文件(比如本架构中使用apache htpasswd创建的基本用户名密码保护文件),进行用户认证,认证不通过,则驳回请求,认证通过,才可以读写数据。 (3)我们将数据统一存储在一个只供创建者使用的S3 Bucket中。 2.2 基于AWS ECS运行Docker Registry服务 Amazon EC2 Container Service (ECS) 是一项高度可扩展的高性能容器管理服务,它让您能够在托管的 Amazon EC2 […]

Read More

新增 – EC2 Auto Scaling 的目标跟踪策略

最近我介绍过 DynamoDB Auto Scaling,并演示了它如何使用多个 CloudWatch 警报来实现 DynamoDB 表的自动容量管理。此功能在后台使用了一种更为通用的 Application Auto Scaling 模型,我们计划以后逐渐在多项不同 AWS 服务中投入使用该模型。 这一新的 Auto Scaling 模型包括一项重要的新功能,我们称之为目标跟踪。在创建使用目标跟踪的 Auto Scaling 策略时,需要为特定 CloudWatch 指标选择一个目标值。然后,Auto Scaling 旋转相应的旋钮 (打个比方) 推动指标趋向于目标,同时调整相关的 CloudWatch 警报。比起使用初始步进扩展策略类型来手动设置范围和阈值而言,采用对应用程序有意义的任何指标驱动的单元来指定期望的目标,通常来说要更简单,也更为直接。不过,您可以结合使用目标跟踪和步进扩展来实现高级扩展策略。例如,您可以使用目标跟踪实现扩展操作,使用步进扩展实现缩减操作。 现在面向 EC2 现在我们为 EC2 Auto Scaling 增加了目标跟踪支持。您现在可以创建应用程序负载均衡器请求计数、CPU 负载、网络流量或自定义指标 (Request Count per Target 是新指标,也是在今天发布) 驱动的扩展策略: 这些指标都具有同一个重要的特性:添加额外的 EC2 实例会推动指标下降 (但不会改变总体负载),反之亦然。 要创建使用目标跟踪的 Auto Scaling 组,只需输入策略名称、选择一个指标,然后设置所需的目标值: 您可以选择禁用策略的缩减功能。如果禁用,您可以手动缩减,也可以使用独立的策略。您可以使用 AWS Management Console, […]

Read More

AWS 深度学习之旅

如果您和我一样,就会对人工智能 (AI)、机器学习 (ML) 和深度学习这些主题有极大兴趣和深感兴奋。AI、ML 和深度学习的应用越来越广泛,对我来说,这意味着艾萨克·阿西莫夫博士的科幻小说、《星球大战》中机器和医疗的进步,以及让柯克船长和他的《星际迷航》舰员能够“前往没有人去过的地方”的那些技术都可成为现实。 大多数对前述主题感兴趣的人都熟悉深度学习支持的 AI 和 ML 解决方案,如实现图像和视频分类的卷积神经网络、语音识别、自然语言接口和推荐引擎。但是,设置基础设施、环境和工具,让数据科学家、机器学习实践者、研究科学家和深度学习爱好者/拥护者能够深入钻研这些技术并不总是那么容易。大多数开发人员都渴望能够快速上手深度学习,从而使用深度学习技术来训练模型和开发解决方案。 因此,无论您是经验丰富的数据科学家,还是急切想在这方面入门的开发人员,我都乐意分享一些资源,帮助您快速构建深度学习解决方案。 深度学习资源 Apache MXNet 是 Amazon 选择的深度学习框架。借助强大的 Apache MXNet 框架和 NVIDIA GPU 计算,您可以在 AWS 云中方便地启动您的可扩展深度学习项目和解决方案。随着您开始探索 MxNet 深度学习,有很多自助教程和数据集可供您使用: 启动 AWS 深度学习 AMI:该指南可引导您完成基于 Ubuntu 启动 AWS 深度学习 AMI 的步骤 MXNet – 创建计算机视觉应用程序:该实践教程使用预构建的笔记本指导您完成使用神经网络实现计算机视觉应用程序来识别手写数字的整个过程 AWS 机器学习数据集: AWS 在您可以免费访问的 AWS Marketplace 中托管机器学习数据集。这些大型数据集可供任何人用来分析数据,而无需下载或存储这些数据。 预测和提取 – 学习使用预先训练的模型来进行预测:该实践课程将指导您借助预先训练的模型并使用完整 Imagenet 数据集来进行预测和特征提取。 AWS 深度学习 AMI […]

Read More