亚马逊AWS官方博客

Category: 大咖专栏

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

白皮书:Amazon EC2 Container Service(ECS)上的微服务架构(下篇)

ECS上构建微服务架构 在构建微服务架构时面临的一个主要问题就是,如果减轻运行、维护、扩展和管理微服务架构所需大规模分布式集群资源的工作量和复杂性。目前主流的解决此问题的方案之一就是通过容器化部署和运行服务,降低运维和部署的复杂性。Amazon EC2 Container Service(ECS)是AWS提供的一个容器管理服务,能够应对和解决微服务架构的部署和运维中面临的种种挑战。 本章节首先介绍Amazon ECS及其架构和工作原理,然后介绍利用Amazon ECS及其他相关AWS服务分层构建的一个高可用、高可扩展性、容错的微服务,并讨论该方案中涉及的分布式系统监控、服务发现、异步通信等问题。 Amazon ECS 简介 什么是Amazon ECS Amazon ECS是一个高度可扩展伸缩、高性能容器管理服务,支持Docker容器[vi]并能够让你轻构地在EC2实例构建的集群中运行应用程序。 Amazon ECS能够让你轻松地进行安装、操作和扩展你的集群资源。使用简单的API调用,你就可以启动和停止基于Docker的应用程序、查询你的集群状态、还可以使用其他熟悉的服务,诸如安全组、ELB、EBS卷和AWS IAM角色。 Amazon ECS的特点 与Docker完美兼容:支持 Docker 并使您能够在 Amazon EC2 实例的集群间运行和管理 Docker 容器。Amazon ECS 所管理的集群中的每个 EC2 实例都运行有 Docker 守护程序,所以无论您将何应用程序打包为本地容器,它都将部署和运行在 Amazon ECS 上,无需进行任何配置更改。 内置集群托管:管理自己的容器管理基础设施通常涉及安装、操作、扩展自己的集群管理软件、配置管理系统和监控解决方案。这些系统的可用性和可扩展性架构和管理很难。Amazon ECS 消除了容器管理工作的复杂性。使用 Amazon ECS,您只需要启动容器实例集群并指定想要运行的任务即可,所有集群管理工作将由 Amazon ECS 完成。 编程控制:Amazon ECS 为您提供一组简单的 API,方便您集成和扩展服务。使用 API,您可以创建和删除集群、注册和取消注册任务、启动和终止 Docker 容器,并能提供集群及其实例的状态相关详细信息。您还可以使用 AWS CloudFormation[vii] 预置 […]

Read More

白皮书:Amazon EC2 Container Service(ECS) 上的微服务架构(上篇)

简介 微服务是一种软件开发的组织和架构方法,它可以加快软件交付周期、增强创新和自主性,提高软件的可维护性和可伸缩、可扩展性,同时也提高了企业开发和发布软件服务的能力。使用微服务架构,软件产品将由多个独立的、可通过API进行交互的服务组成。这些服务将由各个小团队独自负责。 通过本白皮书,我们将首先总结一下微服务架构的特性,讨论构建微服务架构面临的挑战和难题,然后介绍AWS的ECS容器集群服务,以及如何利用ECS结合其他AWS提供的服务解决微服务架构中遇到的难题。 什么是微服务架构 微服务架构的特性 近些年,微服务架构的概念变得越来越火[i],事实上微服务并非某项具体的技术或框架,它也不是软件工程学中新的概念,而是一些成功的,经过实践论证的概念的组合,比如面向对象方法论、敏捷开发、面向服务架构、API-first设计、以及持续集成。 “微服务”这个名词是一个概括性的术语,很难对其进行精确的定义。但是所有微服务架构方法都具有以下共同特性: 去中心化:微服务架构是由去中心化数据管理的分布式系统组成。它不依赖中心数据库上统一的数据库模式。每一个服务都有自己独立的数据模型。去中心化的另一个含义是,每个服务在开发、部署、管理和维护过程中也是相互独立的,不依赖某个中心系统。 独立:微服务架构中各个服务组件都可以独立进行更改、升级和替换,而不会影响其他服务组件的正常功能。同样,负责各个服务组件的团队之间也都是相互独立的,互不干扰的。 专注做好一件事:每个服务组件都是专注于某个问题域的功能集合,一旦某个服务复杂度到达一定程度,则应该考虑将其进行服务切分或对其进行再次微服务架构。 多语种:微服务并不是“一体通用”的方法,它允许各个团队根据自己的喜好选择最适合自己问题域的开发语言、开发工具。因此,微服务无论在操作系统、开发语言、数据存储还是工具,都是兼容的。也就是说,微服务是“多语种”的。 黑盒子:微服务中的服务都是按照“黑盒”设计的,也就是说,它们将内部逻辑对外隐藏进来,各个服务间通过定义良好的API进行通信,避免了暗含的相互依赖。 谁构建,谁运行:通常情况下,在生产环境中,构建了某个服务的团队负责该服务的运行和维护。这条规则也称之为DevOps[ii]。DevOps除了能让各个团队按照自己的安排独立工作外,还可以让开发人员更贴近软件产品的真正使用者,能帮助他们更好地了解用户的需求。微服务对于企业组织架构上的影响也是不容忽视的,正如康威定律所言,系统架构是公司组织架构的反映[iii]。 图1:微服务架构的特征 单体型架构 vs. SOA vs. 微服务架构 技术为业务而生,架构也为业务而出现,无论传统单体型架构、SOA和微服务都是因为业务的发展而出现。出现SOA以及微服务框架与业务的发展、平台的壮大密不可分。 单体型架构 当网站或者应用流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本,简化开发流程,适合于个人开发或者小团队开发一些功能单一的小产品使用。这是最传统的架构模式,一般整个系统都是有一个统一的数据中心,各个功能模块显式进行相互依赖(比如直接调用模块公开的方法)。当网站流量随着业务发展不断变大时,这种架构的应用在可扩展性、容错性(一旦某个功能模块被流量击溃,整个系统瘫痪)上存在致命性的缺陷。 SOA 当网站或者应用流量变大,单体型架构无法招架之时,可以采取面向服务架构方式,将应用根据系统维度、功能维度、读写维度或者模块维度进行划分成各个独立的服务组件,服务组件间通过某个约定的方式(比如Web Service或者HTTP REST API)进行通信。当服务越来越多,容量的难以准确评估,小服务导致资源浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率,这种架构一般仍然存在一个统一的数据中心或者调度中心。整个系统的可维护性、可扩展性相对于单体型架构得到提高,但在服务细粒度、隔度性、去中心化方面仍与微服务有差,另外就是SOA架构常常依赖于总线结构,利用可热插拔的中间件以及消息队列来完成服务与服务之间的解耦,对于总线结构的依赖也使得服务的独立性并没有被完全剥离。 微服务架构 在微服务架构中,每个服务都要去中心化,不存在单点故障问题。每个服务都要实现高可用、高负载,不会因为一个服务不可用而影响整套业务流。每个服务细粒度,专注于自己的问题域,与别的服务采用更好的Restful或者良好定义的API进行通信。服务都要高度通用化,即多种终端都可调用,不分语言和平台服务部署或升级简单,不会消耗大量人力并且部署过程不易出现人为错误,同时还具有快速注册与自动服务发现功能。 微服务的益处 许多AWS客户选择微服务架构来解决传统单体型架构中存在的敏捷性和可扩展性限制的问题。让我们来看看选择微服务架构能够带来哪些方面的益处吧。 敏捷 使用微服务的组织由多个负责运维独立服务的小团队组成。各个团队都是在界限明确的小范围内独立、快速地工作,从而起到减小迭代时间的效果。各个小团队效率的提升将使整个企业组织工作效率进行很大程序地提高。 图2标示由多个小团队组成的企业组织架构与由一个大团队组成的企业组织架构,在发布部署一个应用时的工作效率区别。 图2:部署微服务 创新 小团队可以独立自主地针对自己负责的问题域选择相关的技术、框架和工具,这就是创新的体现。职责与义务,让团队产生对自己的服务的责任感。 DevOps通过将开发与运维人员结合到一个团队中,让他们能更早地、更好地沟通,解决了开发部署过程中没必要的摩擦和矛盾。当应用程序部署时,敏捷的处理流程可以让开发和运维工作不再需要暂停下来,相反,整个软件交付周期,从提交代码到发布版本,整个流程将变成自动化的。测试一个新的想法,或者当新功能出现问题时及时回滚,将变得更加轻松。因为失败成本的降低,团队将更加乐于更改和创新。 质量 使用微服务架构您的应用程序,将一定程度上提高代码质量。这跟面向对象设计中提出的分模块开发有同样的效果:提高代码的可重用性、封装性和可维护性。 伸缩性 细粒度解耦的微服务架构另一个好处就是,它非常适合构建大规模系统。它允许针对不同的服务选择最适合的技术,这也是性能优化的体现。每个服务都可以使用最合适的开发语言和框架来实现,利用最优的数据持久化解决方案,并通过各自独立的服务配置进行调优。 合理解耦的微服务架构,可以独立地进行水平伸缩扩展。这相对于传统架构中使用的垂直伸缩有很大的优势。垂直伸缩指的是当业务量、流量增大时,升级硬件资源,将应用部署到“更大的机器”上,这会导致“机器硬件资源上限”和伸缩时宕机的问题。水平伸缩,通过将更多的服务部署到服务池(多个机器组成的集群)中,可以动态地适配流量,并且不会陷入单个机器资源上限问题。整个水平伸缩的过程将会是自动化的。另外,应用程序的可靠性将得到增加,因为出现问题的服务可以自动地被健康的服务替换掉,而不影响整个应用的运行。 可用性 微服务架构可以轻松实现故障隔离。通过健康检查、缓存、隔离仓、断路器等技术,可以减小当某个组件出现故障时的影响,从而保证应用的高可用性。 微服务架构面临的挑战 尽管拥有前面提到的那么多优点,但是微服务架构和所有其他架构一样,都不是解决所有问题的“银弹”。使用微服务架构也会面临一些挑战和难题。比如: 微服务架构都是分布式的,也就会存在所有“分布式计算误区”中提到的问题[iv]。 从单体型架构迁移至微服务架构,需要您准确地划分好各个服务间的界限,并且从应用层到数据库层松耦合代码依赖。 除此之外,在组织管理方面还存在着一些挑战,比如如何组建一个高效的团队,如何将团队转变成DevOps的生产模式,如何合理化开发团队与运维团队的沟通等。 本白皮书主要关注的是架构和运维方面遇到的挑战,如果想了解更多关于AWS如何运用DevOps的知识,请访问https://aws.amazon.com/devops[v] 架构复杂度 在传统单体型架构中,所有的复杂度和依赖都存在项目的代码库中。而对于微服务架构而言,复杂度变成了各个服务间的交互。 在架构上面临的挑战有处理异步通信、连锁故障、数据一致性问题、服务发现和授权认证等问题。 运维复杂度 […]

Read More

Amazon EC2 Container Service打造容器化的SaaS应用

概述 在SaaS化应用的改造中,容器技术的应用越来越广泛。相对于传统的虚拟机模式,容器化模式的隔离技术“更轻量”,“ 更快速”,“ 更便捷”. 目前业界越来越广的使用“容器”技术用于应用的微服务化改造,将自己产品的一些服务“微服务”化,构建基于云平台的SaaS化应用。 容器技术改造的难点 1. 技术的复杂性 容器技术应用的难点在于生产环境的实施及部署, 一般需要解决 容器资源编排调度 服务的自动发现及注册 容器的监控及报警 容器的扩展及收缩 这只是解决的部分问题,用户还必须去解决生产环境部署中怎样实现高可用部署及与公有云平台的集成问题。这使得Docker的生产化部署变得困难。 2. Docker编排框架的选型 许多人认为容器技术的价值在编排层,目前在容器的编排框架上主要的流派正在上演 “三国演义”包括,Google Kubernetes、Apache Mesos、Docker  DockerSwarm. Kubernetes,Mesos是目前市场上比较成熟的解决方案,占有较大的市场份额。DockerSwarm的优点是与Docker平台中的许多功能的集成,因为它平滑地内置于Docker平台中。上述三个编排框架都开放源代码,用户只需为技术支持服务付费。除了这些标准外还有许多初创公司也推出了自有的编排框架, 如Rancher使用Java语言开发了Cattle,它是Rancher实现的自有的一套基于Docker的编排引擎。众多的开源或自有的编排框架在不断发展,演进。这给客户的技术平台选型也带来极大的挑战。 Amazon EC2 Container Service(ECS) 为了降低容器平台生产部署的复杂性,Amazon ECS提供了一个平台来管理Docker容器。Amazon ECS是一项高度可扩展的高性能容器管理服务,您将不再需要安装、运维、扩展自己的群集管理基础设施。只需进行简单的 API 调用,您便可以启动和停止支持 Docker 应用程序,查询群集的完整状态,使用各种熟悉的功能,包括安全组、Elastic Load Balancing、EBS 卷和 IAM 角色。您可以使用 Amazon ECS 根据您的资源需求和可用性要求在您的群集中安排容器的置放。您还可以集成自己的或第三方的计划程序,以满足业务或应用程序的特定要求。Amazon EC2 Container Service 没有任何附加费用。您只需为您创建的用于存储和运行应用程序的 AWS 资源 (例如 EC2 实例或 EBS 卷) 付费。Amazon […]

Read More

云计算转型成熟度模型: 为您的上云行动制定有效策略的指南

云计算转型成熟度模型为帮助企业制定自己的上云之旅提供了指南。该模型定义了确定成熟阶段的特征,在进入下一阶段前必须完成的每个阶段的转型活动,以及在组织成熟度的四个阶段(包括项目,基础,迁移和优化)中实现的结果。 想了解您的企业目前处于云计算转型之旅的什么位置吗?下表可以帮您确定您的企业目前处于哪个阶段: 一旦您确定了目前处于哪个阶段,就可以遵循 AWS 入云框架(AWS CAF) 的指导开始您的下一步旅程了。CAF 可以为企业的入云之旅提供一个经济且高效的计划 。AWS CAF将复杂的迁移计划过程分解为可管理的重点领域, 无论您是需要帮助定义组织的云计算路线图,做应用程序开发的转型或大规模部署任务关键型工作负载,我们都可以按照AWS Cloud Adoption Framework的原则提供规范性的指导。 来自全面入云客户的建议 除了AWS CAF,我们也想分享来自不同行业的客户的建议,这些客户都已经决定将所有系统都迁移到AWS云平台之上(all-in on the AWS Cloud)。   “我们在入云之旅的沿途学到的一件事就是文化变革,文化变革可以将人们团结起来坚定地沿着这个旅程走下去,并且真正完成组织转型,不仅要说服人们我们选择的是正确的技术,重要的是要赢得民心,这样才能圆满地完成如云之旅。” —迈克·查普尔,IT服务交付高级主管,Notre Dame “我们选取了一些系统部署在AWS上,因为可以在Amazon内部进行快速配置, 这些系统运行得更快。 这是一个巨大的成功。 这种成功使我们对取得更多类似的成功产生了浓厚的兴趣。 所以在开始使用POC验证了AWS功能后,我们立即开始扩展到其他系统,直到完全迁移到AWS 。” —埃里克·盖革,IT的副总裁行动,芝加哥联邦住房贷款银行 “对我们来说,最重要的一件事就是,AWS的确能满足我们业务增长的需要。这不仅需要从能力角度来看,还要从区域扩张的角度来看。 这可以帮助我们把我们的业务模式推广到整个地区,最终跨越全球。” —马尔切洛·韦瑟尔勒,CEO,新加坡邮政   原文链接:https://aws.amazon.com/cn/blogs/publicsector/cloud-adoption-maturity-model-guidelines-to-develop-effective-strategies-for-your-cloud-adoption-journey/ 译者:刘育新 AWS云架构高级咨询顾问,获得AWS解决方案架构师专业级认证和DevOps工程师专业级认证,专注于云迁移解决方案。目前已为多家跨国公司及本土公司、合作伙伴提供上云迁移的咨询设计和实施服务,在加入AWS之前有近20年的IT架构设计和项目管理经验。

Read More

使用Apache Kylin和Amazon EMR进行云上大数据OLAP分析

作者:史少锋 Kyligence资深架构师,Apache Kylin committer & PMC   公司简介 上海跬智信息技术有限公司 (Kyligence) 是由Apache Kylin (首个来自中国的 Apache 软件基金会顶级开源项目) 核心团队组建,专注于大数据分析领域创新的数据科技公司。Apache Kylin是近两年迅速崛起的开源分布式大数据分析引擎,它充分利用Hadoop MapReduce,HBase,Spark等成熟技术,对超大数据集进行预计算(构建Cube),从而当在线查询请求到来时,通过检索Cube以亚秒级低延迟返回结果,实现真正的大数据上的交互式分析。对于用户来说,Kylin屏蔽了底层平台的技术细节,用户只需要掌握多维模型、数据仓库、SQL等知识,就可以通过Kylin的Web界面进行建模,Kylin将自动生成任务对数据进行计算。计算完成后用户即可通过各类可视化工具连入Kylin进行分析,易用性非常高。今天,Apache Kylin已经在众多企业得到广泛应用,如今日头条等。 解决方案 Kyligence为各行各业的客户提供基于AWS公有云平台的Hadoop数据仓库解决方案。Elastic MapReduce (Amazon EMR) 是AWS推出的云上Hadoop方案,这一方案使得Hadoop的部署、监控、扩容变的非常灵活方便。Amazon EMR将计算和存储分离,可以使用S3做数据存储,用户可随需启停Hadoop而不用担心数据丢失,用户只需为运行时使用的资源付费,从而大大减少运维成本。以最近发布的Apache Kylin v2.0和Amazon EMR 5.5(海外版)为例,在AWS云上使用Kylin是非常简单快速的。 1. 启动EMR集群 如果您已经有在运行的,包含了HBase 1.x服务的EMR集群,那么这一步可以跳过,您可以使用现有集群进行此实验。 EMR的启动非常简单,登录AWS控制台,选择Amazon EMR服务,点击“Create Cluster”,选择最新的5.5版本,类型为HBase: 这里您可以选择合适的硬件配置;默认是m3.xlarge 3个节点,其中1个节点为master,另外两个为core节点。选择合适的EC2 key pair,随后点击“Create cluster”,AWS便会开始自动安装和配置Hadoop/HBase集群。 大约20分钟后,集群状态显示为“Waiting Cluster ready”,这意味着集群准备就绪可以使用了。   2. 安装Apache Kylin 2.0 Apache Kylin以Hadoop client的方式运行,使用标准协议/API与集群交互。您可以将它安装在集群的任意节点上,通常建议安装在一个单独的client节点上。在这里我们为了简单,就把Kylin安装在master节点上。 在AWS控制台上,您可以获取SSH到Amazon EMR的方法;点击“Master public DNS”旁边的SSH链接,即可获得,如下图所示: SSH登录到master节点后,创建一个Kylin安装目录,下载并解压Apache Kylin […]

Read More

如何使用Apache Mahout在 Amazon Elastic Mapreduce上构建推荐系统

本篇博文首先简单介绍了机器学习,并给出了Apache Mahout项目的背景情况以及推荐系统中需要注意的一些细节,然后我们会构建一个电影推荐系统并写一个简单的web服务来提供给客户端查询结果。最后我们会列出学习和参与到Mahout社区中的一些方法。 机器学习 机器学习植根于人工智能,这意味着机器学习工具具有对数据问题的认知和自动决策能力,但是目前的机器学习算法并不包含真正意义上的计算思想。尽管如此,机器学习经常采用某种类型的自动化决策,并采用迭代的方式来最大化或最小化与模型性能相关的特征值。 机器学习领域包含许多主题和方法,通常有分类、聚类以及推荐等。 分类是基于其他已知(独立)变量的组合来预测未知(从属)变量的过程,例如预测银行的客户流失或某项音乐服务的订阅者数量。在这两种情况下,我们使用关于客户的已知变量来预测他们停止使用相关服务的趋势。 下表列出了几个可能的已知变量: 变量类型 例子 用户信息 城市、州、年龄、性别 行为方式 银行客户消费习惯、用户播放特定艺术家音乐的频率 环境因素 银行客户的费用评估、用户播放音乐时遭遇缓冲的频率 在进行分类工作时,我们通常针对包含从属变量真实取值的数据进行训练,然后通过比较留存测试数据的预测值和真实值的差距来评估模型的性能。 聚类是寻找事物集合和分组的过程。在几何学中,我们经常讨论N维空间中的聚类向量。举个例子,下面图中在二维空间中展示了四对由向量代表的人,每一个维度是一种支出类别,在本例中是娱乐支出和杂项支出。 左上角图中显示两人的支出数量是相近的,但是消费习惯则完全指向了不同的方向,所以这两人是不相似的。基于同样的原因,左下图中的两人就拥有相近的消费习惯。当然通常我们在分类时引入的维度是多于两个的,甚至是成千上万的维度,并且从数学上可以推广到任意有限的维度空间。 聚类的关键在于我们用来定义相似性的距离度量或者测量方法。一些常用的方法如欧几里德距离、余弦相似度(相似向量间的夹角的余弦值接近0,反之则接近1)以及Tanimoto系数(两个向量相同点占两个向量所有点的比例)。 推荐系统通常接收数据输入,通常是基于行为的数据,然后预测用户最终会倾向于哪个选项。过去十年推荐系统的流行很大程度上得益于Netflix Prize的推广,它在2006年到2009年间奖励给那些击败Netflix现有推荐系统的人。 推荐系统的性能以预测值和真实值之间的比较来得出,在生产系统中通常还结合A/B测试来进行优化。 Apache Mahout 大多数的Hadoop发行版本都包含了Apache Mahout,这其中就有Apache Bigtop和EMR。本质上Apache Mahout是一个机器学习的算法库,包含分类、聚类以及推荐等多种工具,可以被用于计算相似性和生成用户推荐等目的。Mahout使用Hadoop的Mapreduce框架来执行具体的计算过程,现在也支持新的计算框架,比如UC Berkeley’s AMPLab的Spark。 Mahout第一次bug修复发生在2008年1月,直到本篇博文写就之时,总共有1700个Jira tickets,其中54个依然是open状态。时至今日,社区中的贡献者和用户仍然在不停地针对代码和文档进行优化工作。 推荐系统 大多数人感觉到推荐系统的存在是从网页开始的,后台推荐系统会将结果显示在用户浏览网页的某一部分之上。这些包含推荐结果的网页帮助用户找到想买的商品、想听的音乐、想看的电影、想雇佣的人,甚至是约会的对象。 GroupLens研究团队于上个世纪90年代早期构建了USENET文章推荐系统,自此推荐系统技术开始了快速发展。随着时间的推移,推荐对象本身也发生了变化,除了新的文章,还有大量的在线行为值得分析,比如用户在网页上的点击链接行为;点赞和档案浏览;购物行为以及听音乐和看电影。 这些发展提供了基于用户行为进行推荐的可能性,能够帮助我们进一步改进推荐系统。 在USENET示例中,用户扫描作者和主题的文章列表,点击,阅读和关闭文章。 在线零售网站,购物者搜索产品,浏览产品页面,点击照片放大,阅读评论,并将产品添加到购物车。 在流媒体音乐网站上,音乐消费者搜索艺术家或专辑,播放曲目,通过曲目快速播放,并将艺术家添加到收藏夹,流媒体视频网站的工作方式类似。 在专业或个人联系的社交网站上,用户搜索并与其他人互动。 每个示例包括用户以某种方式与某些类型的项目进行交互的用户。 构建推荐系统 为了说明如何在EMR上通过Mahout建立分析型作业,我们决定构建一个电影推荐系统。我们会使用用户打分的电影评分数据,这些数据由GroupLens团队提供。推荐系统最终会为每一位用户推荐自己最感兴趣的电影。 1.  登录AWS账户 2.  配置EMR ruby客户端 3.  启动EMR集群 ./elastic-mapreduce –create –alive –name mahout-tutorial […]

Read More

AWS WAF – Web 应用程序防火墙初体验

1. 背景介绍 AWS WAF ,全称是Web Application Firewall ,即Web 应用程序防火墙,可以帮助用户保护Web 应用程序免受常见的Web漏洞攻击。通常这些攻击会损害Web应用的安全性,影响可用性,消耗过多的资源,增加成本,还降低响应速度和用户体验。 WAF可以让用户创建定制规则进行流量筛选,阻隔恶意访问,保障正常请求。比如,可以根据 IP 地址、HTTP 标头、HTTP 正文或 URI 字符串来筛选 Web 请求,这样便能阻止诸如 SQL 注入或跨站点脚本等常见攻击模式。 和其它诸多 AWS 服务一样,WAF 的所有功能也可以通过AWS管理控制台或API进行配置。这便利了用户团队的不同角色,不论是开发人员、DevOps工程师还是安全审查专家都可以方便使用,从开发到部署的全过程系统地管理Web应用的安全。 WAF 和AWS的Web相关服务紧密结合,目前支持CloudFront和Application Load Balancer。AWS WAF 让您能够创建集中化的规则集合,而后部署到多个网站上。用户通常有多个网站和 Web 应用程序,使用WAF可以只定义一组规则并复用于多个应用程序上。WAF也是AWS全托管的服务,用户无需担心其扩展和可用性。只需在正确的资源上启用WAF,无需部署任何额外软件即可完成部署。并且只需要部署一次,即可以全球的边缘节点全部生效。 作为防火墙,WAF当然也少不了监控和报警。WAF 可以让用户设置条件来监视哪些请求。提供准实时地 Web 流量监测报告,并以此信息来创建新的规则或使用 Amazon CloudWatch 的进行报警。 今天,我们以WAF实现防盗图这个常见应用场景,帮助大家快速上手,体验其强大和便捷。 2. 部署与配置WAF 现在主流的Web应用都使用了无cookie域名来加速静态内容,我们这里也进行类似的部署,如网站域名是 example.com,图片服务使用另一个域名 example_img.com。禁止盗图的效果可以从下表来概述。 调用图片的域名 响应效果 *.example.com 200 OK 其它非法域名 403 Forbidden WAF目前支持CloudFront和Application […]

Read More

通过AWS Config 管理AWS服务配置

在之前的一篇安全相关的文章《从永恒之蓝开始,安全防范没有结束》中,提到通过AWS Config自动规范AWS服务的安全、合规方面的配置。 为更好遵从各行业的合规要求,构建安全的IT环境,企业的安全团队一般都会在明确安全/管理边界的前提下,选择相关安全框架,用对应的风险评估方法梳理出符合自身业务特点的安全模型。根据安全模型,通常也会用各种文档标准化抽象为各种管理策略,例如可能包含以下常见的内容: 用户权限策略 访问控制策略 服务器安全策略 应用接入策略 网络分区策略 数据传输策略 数据存储策略 备份归档策略 日志记录策略 审计管理策略 ………. 在实际的应用场景中,标准策略可能会因为业务的变化或管理方式的变化动态调整,如何持续评估和审核在AWS云端的资源配置的合规性是否与企业规划一致?如何帮助用户在云端更好的实现变更管理,安全分析甚至自动修正不合规的配置 ?这种场景下,可以考虑用AWS Config 服务来帮忙。 一、AWS config 是什么 AWS Config 是一项托管服务,借助 Config您可以盘点AWS 资源、查看配置更改以及 AWS 资源之间的关系并深入探究详细的资源配置历史记录。使用 Config,还能通过自定义规则来定义所需的资源配置、内部最佳实践和指南,并依据这些规则评估您记录的配置。 AWS Config的主要应用功能: 评估您 AWS 资源配置是否具备所需设置。 获得与您的 AWS 账户关联的受支持资源的当前配置快照。 检索您的账户中的一个或多个资源配置。 检索一个或多个资源的历史配置。 在资源被创建、修改或删除时接收通知。 查看不同资源之间的关系。例如,您可能想要找到使用特定安全组的所有资源 AWS Config工作原理 更多AWS Config的信息可以参考https://aws.amazon.com/cn/config/ 二、 AWS config 配置测试 为了更好了解AWS Config的工作过程,以下 将以AWS安全组的配置监控为例做一个简短测试 。 1. 测试场景: […]

Read More