亚马逊AWS官方博客

使用 AWS EC2 上的 Apache MXNet 和 Multimedia Commons 数据集来估计图像位置

作者:Jaeyoung Choi 和 Kevin Li | 原文链接

这是由国际计算机科学研究院的 Jaeyoung Choi 和加州大学伯克利分校的 Kevin Li 所著的一篇访客文章。本项目演示学术研究人员如何利用我们的 AWS Cloud Credits for Research Program 实现科学突破。

当您拍摄照片时,现代移动设备可以自动向图像分配地理坐标。不过,网络上的大多数图像仍缺少该位置元数据。图像定位是估计图像位置并应用位置标签的过程。根据您的数据集大小以及提出问题的方式,分配的位置标签可以是建筑物或地标名称或实际地理坐标 (纬度、经度)。

在本文中,我们会展示如何使用通过 Apache MXNet 创建的预训练模型对图像进行地理分类。我们使用的数据集包含拍摄于全球各地的数百万张 Flickr 图像。我们还会展示如何将结果制成地图以直观地显示结果。

我们的方法

图像定位方法可以分为两类:图像检索搜索法和分类法。(该博文将对这两个类别中最先进的方法进行比较。)

Weyand 等人近期的作品提出图像定位是一个分类问题。在这种方法中,作者将地球表面细分为数千个地理单元格,并利用带地理标记的图像训练了深层神经网路。有关他们的试验更通俗的描述,请参阅该文章

由于作者没有公开他们的训练数据或训练模型 (即 PlaNet),因此我们决定训练我们自己的图像定位器。我们训练模型的场景灵感来自于 Weyand 等人描述的方法,但是我们对几个设置作了改动。

我们在单个 p2.16xlarge 实例上使用 MXNet 来训练我们的模型 LocationNet,该实例包含来自 AWS Multimedia Commons 数据集的带有地理标记的图像。

我们将训练、验证和测试图像分离,以便同一人上传的图像不会出现在多个集合中。我们使用 Google 的 S2 Geometry Library 通过训练数据创建类。该模型经过 12 个训练周期后收敛,完成 p2.16xlarge 实例训练大约花了 9 天时间。GitHub 上提供了采用 Jupyter Notebook 的完整教程

下表对用于训练和测试 LocationNet 和 PlaNet 的设置进行了比较。

LocationNet PlaNet
数据集来源 Multimedia Commons 从网络抓取的图像
训练集 3390 万 9100 万
验证 180 万 3400 万
S2 单元分区 t1=5000, t2=500
→ 15,527 个单元格
t1=10,000, t2=50
→ 26,263 个单元格
模型 ResNet-101 GoogleNet
优化 使用动量和 LR 计划的 SGD Adagrad
训练时间 采用 16 个 NVIDIA K80 GPU (p2.16xlarge EC2 实例) 时为 9 天
12 个训练周期
采用 200 个 CPU 内核时为两个半月
框架 MXNet DistBelief
测试集 Placing Task 2016 测试集 (150 万张 Flickr 图像) 230 万张有地理标记的 Flickr 图像

在推理时,LocationNet 会输出地理单元格间的概率分布。单元格中概率最高的图像的质心地理坐标会被分配为查询图像的地理坐标。

LocationNet 会在 MXNet Model Zoo 中公开分享。

下载 LocationNet

现在下载 LocationNet 预训练模型。LocationNet 已使用 AWS Multimedia Commons 数据集中带地理标记的图像子集进行了训练。Multimedia Commons 数据集包含 3900 多万张图像和 15000 个地理单元格 (类)。

LocationNet 包括两部分:一个包含模型定义的 JSON 文件和一个包含参数的二进制文件。我们从 S3 加载必要的软件包并下载文件。

import os

import urllib

import mxnet as mx

import logging

import numpy as np

from skimage import io, transform

from collections import namedtuple

from math import radians, sin, cos, sqrt, asin

path = 'https://s3.amazonaws.com/mmcommons-tutorial/models/'

model_path = 'models/'

if not os.path.exists(model_path):

os.mkdir(model_path)

urllib.urlretrieve(path+'RN101-5k500-symbol.json', model_path+'RN101-5k500-symbol.json')

urllib.urlretrieve(path+'RN101-5k500-0012.params', model_path+'RN101-5k500-0012.params')

然后,加载下载的模型。如果您没有可用 GPU,请将 mx.gpu() 替换为 mx.cpu():

# Load the pre-trained model

prefix = "models/RN101-5k500"

load_epoch = 12

sym, arg_params, aux_params = mx.model.load_checkpoint(prefix, load_epoch)

mod = mx.mod.Module(symbol=sym, context=mx.gpu())

mod.bind([('data', (1,3,224,224))], for_training=False)
mod.set_params(arg_params, aux_params, allow_missing=True)

grids.txt 文件包含用于训练模型的地理单元格。

第 i 行是第 i 个类,列分别代表:S2 单元格标记、纬度和经度。我们将标签加载到名为 grids 的列表中。

# Download and load grids file

urllib.urlretrieve('https://raw.githubusercontent.com/multimedia-berkeley/tutorials/master/grids.txt','grids.txt')

# Load labels.

grids = []

with open('grids.txt', 'r') as f:

for line in f:

line = line.strip().split('\t')

lat = float(line[1])

lng = float(line[2])

grids.append((lat, lng))

该模型使用半径公式来测量点 p1 和 p2 之间的大圆弧距离,以千米为单位:

def distance(p1, p2):

R = 6371 # Earth radius in km

lat1, lng1, lat2, lng2 = map(radians, (p1[0], p1[1], p2[0], p2[1]))

dlat = lat2 - lat1

dlng = lng2 - lng1

a = sin(dlat * 0.5) ** 2 + cos(lat1) * cos(lat2) * (sin(dlng * 0.5) ** 2)
return 2 * R * asin(sqrt(a))

在将图像提供给深度学习网络之前,该模型会通过裁剪以及减去均值来预处理图像:

# mean image for preprocessing

mean_rgb = np.array([123.68, 116.779, 103.939])

mean_rgb = mean_rgb.reshape((3, 1, 1))


def PreprocessImage(path, show_img=False):

# load image.

img = io.imread(path)

# We crop image from center to get size 224x224.

short_side = min(img.shape[:2])

yy = int((img.shape[0] - short_side) / 2)

xx = int((img.shape[1] - short_side) / 2)

crop_img = img[yy : yy + short_side, xx : xx + short_side]

resized_img = transform.resize(crop_img, (224,224))

if show_img:

io.imshow(resized_img)

# convert to numpy.ndarray

sample = np.asarray(resized_img) * 256

# swap axes to make image from (224, 224, 3) to (3, 224, 224)

sample = np.swapaxes(sample, 0, 2)

sample = np.swapaxes(sample, 1, 2)

# sub mean

normed_img = sample - mean_rgb

normed_img = normed_img.reshape((1, 3, 224, 224))
return [mx.nd.array(normed_img)]

评估并比较模型

为了进行评估,我们使用两个数据集:IM2GPS 数据集和 Flickr 图像测试数据集,后者用于 MediaEval Placing 2016 基准测试

IM2GPS 测试集结果

以下值表示 IM2GPS 测试集中正确位于与实际位置的每个距离内的图像的百分比。


Flickr 图像结果

由于 PlaNet 中使用的测试集图像尚未公开发布,因此不能直接比较这些结果。这些值表示测试集中正确位于与实际位置的每个距离内的图像的百分比。


通过目测检查定位图像,我们可以看到该模型不仅在地标位置方面表现出色,而且也能准确定位非标志性场景。

使用 URL 估算图像的地理位置

现在我们试着用 URL 对网页上的图像进行定位。

Batch = namedtuple('Batch', ['data'])

def predict(imgurl, prefix='images/'):

download_url(imgurl, prefix)

imgname = imgurl.split('/')[-1]

batch = PreprocessImage(prefix + imgname, True)

#predict and show top 5 results

mod.forward(Batch(batch), is_train=False)

prob = mod.get_outputs()[0].asnumpy()[0]

pred = np.argsort(prob)[::-1]

result = list()

for i in range(5):

pred_loc = grids[int(pred[i])]

res = (i+1, prob[pred[i]], pred_loc)

print('rank=%d, prob=%f, lat=%s, lng=%s' \

% (i+1, prob[pred[i]], pred_loc[0], pred_loc[1]))

result.append(res[2])

return result


def download_url(imgurl, img_directory):

if not os.path.exists(img_directory):

os.mkdir(img_directory)

imgname = imgurl.split('/')[-1]

filepath = os.path.join(img_directory, imgname)

if not os.path.exists(filepath):

filepath, _ = urllib.urlretrieve(imgurl, filepath)

statinfo = os.stat(filepath)

print('Succesfully downloaded', imgname, statinfo.st_size, 'bytes.')
return filepath

来看看我们的模型如何处理东京塔图片。以下代码从 URL 下载图像,并输出模型的位置预测。

#download and predict geo-location of an image of Tokyo Tower

url = 'https://farm5.staticflickr.com/4275/34103081894_f7c9bfa86c_k_d.jpg'
result = predict(url)

结果列出了置信度分数 (概率) 排在前五位的输出以及地理坐标:

rank=1, prob=0.139923, lat=35.6599344486, lng=139.728919109

rank=2, prob=0.095210, lat=35.6546613641, lng=139.745685815

rank=3, prob=0.042224, lat=35.7098435803, lng=139.810458528

rank=4, prob=0.032602, lat=35.6641725688, lng=139.746648114

rank=5, prob=0.023119, lat=35.6901996892, lng=139.692857396

仅通过原始纬度和经度值,很难判断地理位置输出的质量。我们可以通过将输出制成地图来直观地显示结果。

在 Jupyter Notebook 上使用 Google Maps 直观显示结果

为了直观地显示预测结果,我们可以在 Jupyter Notebook 中使用 Google Maps。它让您能够看到预测是否有意义。我们使用一个名为 gmaps 的插件,它允许我们在 Jupyter Notebook 中使用 Google Maps。要安装 gmaps,请按照 gmaps GitHub 页面上的安装说明操作。

使用 gmaps 直观显示结果只需几行代码。请在您的 Notebook 输入以下内容:

import gmaps


gmaps.configure(api_key="") # Fill in with your API key


fig = gmaps.figure()


for i in range(len(result)):

marker = gmaps.marker_layer([result[i]], label=str(i+1))

fig.add_layer(marker)

fig

事实上,排在第一位的定位估算结果就是东京塔所在的位置。

现在,试着对您选择的图像进行定位吧!

鸣谢

在 AWS 上训练 LocationNet 的工作得到了 AWS 研究与教育计划的大力支持。我们还要感谢 AWS 公共数据集计划托管 Multimedia Commons 数据集以供公众使用。我们的工作也得到了劳伦斯·利弗莫尔国家实验室领导的合作 LDRD 的部分支持 (美国能源部合同 DE-AC52-07NA27344)。

 

新增 – 适用于 Windows 的 Amazon EC2 Elastic GPU

作者:Randall | 原文链接

今天,我们高兴地宣布,适用于 Windows 的 Amazon EC2 Elastic GPU 正式推出。Elastic GPU 是一种 GPU 资源,可以挂载到 Amazon Elastic Compute Cloud (EC2) 实例来提升应用程序的图形性能。Elastic GPU 提供 medium (1GB)、large (2GB)、xlarge (4GB) 和 2xlarge (8GB) 几种大小,可以作为 G3 或 G2 等 GPU 实例类型 (用于 OpenGL 3.3 应用程序) 的成本更低的替代方案。您可以将 Elastic GPU 用于多种实例类型,灵活地为应用程序选择适当的计算、内存和存储资源,使之达到平衡。您现在就可以在 us-east-1 和 us-east-2 区域预配置 Elastic GPU。

对于 eg1.medium,Elastic GPU 的起始价仅为每小时 0.05 USD,即一小时五美分。如果我们将该 Elastic GPU 挂载到 t2.medium (0.065 USD/小时),一个使用 GPU 的实例每小时的总花费不到 12 美分。以前,最便宜的图形工作站 (G2/3 级) 的成本是每小时 76 美分。由此可见,新服务将使运行特定图形工作负载的成本降低 80% 以上。

何时应当使用 Elastic GPU?

Elastic GPU 最适合需要少量或间歇性附加 GPU 能力来实现图形加速和支持 OpenGL 的应用程序。Elastic GPU 支持 OpenGL 3.3 及更低版本的 API 标准,并且扩展的 API 支持不久也将推出。

Elastic GPU 并非实例的硬件部分。它们通过您子网中的 Elastic GPU 网络接口挂载到实例上,当您启动使用 Elastic GPU 的实例时,便会创建这么一个网络接口。下图显示了 Elastic GPU 是如何挂载的。

因为 Elastic GPU 是通过网络挂载的,所以必须预配置一个有足够网络带宽的实例来支持您的应用程序,这一点很重要。而确保实例安全组允许端口 2007 上的流量也同样重要。

任何可以使用 OpenGL API 的应用程序都可以利用 Elastic GPU,因此 Blender、Google Earth、SIEMENS SolidEdge 等都可以使用 Elastic GPU 来运行。甚至包括坎巴拉太空计划 (Kerbal Space Program)!

好了,现在我们知道了什么时候使用 Elastic GPU 及其工作原理,下面我们来启动一个实例并使用一个 Elastic GPU。

使用 Elastic GPU

首先,导航到 EC2 控制台并单击“Launch Instance”。接下来,选择一个 Windows AMI,如“Microsoft Windows Server 2016 Base”。然后,选择一个实例类型。确保选择“Elastic GPU”部分并分配一个 eg1.medium (1GB) Elastic GPU。

我们还将在高级详细信息部分包含一些用户数据。我们将编写一个简短的 PowerShell 脚本来下载并安装 Elastic GPU 软件。

<powershell>
Start-Transcript -Path "C:\egpu_install.log" -Append
(new-object net.webclient).DownloadFile('http://ec2-elasticgpus.s3-website-us-east-1.amazonaws.com/latest','C:\egpu.msi')
Start-Process "msiexec.exe" -Wait -ArgumentList "/i C:\egpu.msi /qn /L*v C:\egpu_msi_install.log"
[Environment]::SetEnvironmentVariable("Path",$env:Path + ";C:\Program Files\Amazon\EC2ElasticGPUs\manager\",[EnvironmentVariableTarget]::Machine)
Restart-Computer -Force
</powershell>

该软件将所有 OpenGL API 调用都发送到挂载的 Elastic GPU。

接下来,我们将仔细检查,以确保我的安全组已对 VPC 开放了 TCP 端口 2007,这样 Elastic GPU 才能与我的实例连接。最后,我们单击启动,等待实例和 Elastic GPU 完成预配置。完成这项工作最好的方法是创建一个可以挂载到该实例的单独的 SG。

您可以观看下面有关启动过程的动画。

或者,我们也可以通过 AWS CLI 使用如下的简短调用来进行启动:

$aws ec2 run-instances --elastic-gpu-specification Type=eg1.2xlarge \
--image-id ami-1a2b3c4d \
--subnet subnet-11223344 \
--instance-type r4.large \
--security-groups "default" "elasticgpu-sg"

然后,按照此处的 Elastic GPU 软件安装说明操作。

现在,通过查看任务栏中 Elastic GPU 的状态,可以看出 Elastic GPU 在正常运转并且已挂载。

我们欢迎您对该服务提出任何反馈意见,您可以单击 GPU 状态框左下角的反馈链接,让我们了解您使用 Elastic GPU 的体验。

Elastic GPU 演示

好了,我们已预配置了实例并挂载了 Elastic GPU。我在 AWS 的队友希望我谈谈可以运行哪些令人惊奇的精彩 3D 应用程序,但当我了解到 Elastic GPU 之后,我首先想到的就是坎巴拉太空计划 (KSP),因此我准备用它进行一次简短测试。毕竟,如果您不能将试飞员 Jebediah Kerman 送入太空,还要这套软件做什么呢?我下载了 KSP 并添加了发射参数 -force-opengl ,以确保我们将使用 OpenGL 进行渲染。下面您会看到我在建造太空船方面糟糕的尝试 – 过去我的表现可要好很多。考虑到我们使用的网络采用的是有损耗的远程桌面协议,情况还算顺利。

我本来想展示一张火箭发射的照片,但它甚至还没离开地面就意外地迅速解体了。我只好从头再来。

在此期间,我可以检查我的 Amazon CloudWatch 指标,看看在我玩游戏的这一小段时间里使用了多少 GPU 内存。

合作伙伴、定价和文档

为了继续为我们的客户打造出色体验,我们的 3D 软件合作伙伴 (如 ANSYS 和 Siemens) 正打算在 Elastic GPU 上利用 OpenGL API,目前他们正在认证 Elastic GPU 是否适合其软件。您可在此处了解有关我们的合作伙伴关系的更多信息。

可在此处找到有关 Elastic GPU 定价方面的信息。可在此处找到更多文档。

现在,我要失陪了,我还有几艘虚拟火箭要造。

Randall

Amazon Aurora 数据库快速克隆

作者:Jeff Barr | 原文链接

今天,我想快速展示一下 Amazon Aurora 中我认为非常有用的一项功能:数据库快速克隆。利用 Aurora 的底层分布式存储引擎,您可以快速、经济地创建数据库的写入时复制克隆。

在我的职业生涯中,我经常需要花时间等待一些有代表性的数据样本,以便用于开发、试验或分析。如果我有一个 2TB 的数据库,则在执行任务之前,等待数据副本准备就绪的时间可能长达几个小时。即使在 RDS MySQL 内,我也仍需花几个小时等待快照副本完成,然后才能测试架构迁移或执行某些分析任务。Aurora 以一种非常有趣的方式解决了这个问题。

借助 Aurora 的分布式存储引擎,我们可以完成一些使用传统数据库引擎通常不可行或成本高昂的操作。通过创建指向各个数据页面的指针,存储引擎可实现数据库快速克隆。然后,当您更改源或克隆中的数据时,写入时复制协议会为该页面创建一个新副本并相应地更新指针。这意味着,以前花 1 小时才能完成的 2TB 快照恢复任务现在只需大约 5 分钟即可完成 – 其中大部分时间用于预配置新 RDS 实例。

创建克隆所花的时间与数据库大小无关,因为我们指向同一存储。这样还可让克隆操作变得非常经济实惠,因为我只需为更改的页面 (而非整个副本) 支付存储费用。数据库克隆仍是一个常规的 Aurora 数据库集群,具有所有相同的持久性保证。

接下来,我们克隆一个数据库。首先,选择一个 Aurora (MySQL) 实例,并从“Instance Actions”中选择“create-clone”。

接下来,将克隆命名为 dolly-the-sheep 并对其进行预配置。

大约 5 分 30 秒后,我的克隆已变为可用状态,然后,我开始进行一些大型架构更改,但发现性能未受到任何影响。由于 Aurora 团队做出了一些改进以支持更快的 DDL 操作,因此,与传统 MySQL 相比,架构更改本身的完成速度更快。如果我想让其他团队成员对架构更改执行一些测试,则随后可以创建克隆的克隆,甚至是三次克隆,依次类推,同时我还能继续更改自己的克隆。这里需要注意的是,从 RDS 的角度而言,克隆是第一类数据库。我仍然拥有其他 Aurora 数据库支持的所有功能:快照、备份、监控等。

我希望这项功能可以在基于 Amazon Aurora 试验和开发应用程序方面,为您和您的团队节省大量时间与资金。您可以参阅 Amazon Aurora 用户指南详细了解这项功能,并且我强烈建议您关注 AWS 数据库博客。Anurag Gupta 发布的有关 quorum 和 Amazon Aurora 存储的文章十分有趣。

有后续问题或反馈?请发送电子邮件至 aurora-pm@amazon.com 与我们联系,或在此发表评论。我们很想了解您的想法和建议。

Randall

新增 – 通过 IP 地址在 AWS 和本地资源间实现应用程序负载均衡

作者:Jeff Barr / 原文链接

去年,我介绍了有关新型 AWS 应用程序负载均衡器的信息,并展示了如何针对 EC2 实例以及在容器中运行的微服务,用它进行第 7 层 (应用程序) 路由。

在向 AWS 迁移的这个漫长过程中,有些客户会构建混合应用程序。这些客户告诉我们,他们希望使用单个应用程序负载均衡器,在现有本地资源以及 AWS 云中运行的新资源组合中分配流量。其他客户则希望将流量分配到分散在两个或多个 Virtual Private Cloud (VPC) 中的 Web 或数据库服务器中,在同一实例上托管 IP 地址不同但端口号相同的多项服务,并为不支持服务器名称指示 (SNI) 的客户端提供基于 IP 的虚拟托管支持。还有一些客户则希望在同一实例上 (或许是在容器内) 托管某项服务的多个实例,同时使用多个界面和安全组来实施精细访问控制。

这些情况会出现在各种混合、迁移、灾难恢复和本地使用情形及场景中。

路由到 IP 地址
应用程序负载均衡器现在可以将流量直接路由到 IP 地址,以满足这些使用情形。这些地址可以与 ALB 位于同一 VPC 中、位于同一区域中的对等 VPC 中、位于与 VPC 连接的 EC2 实例上 (通过 ClassicLink),或者位于 VPN 连接或 AWS Direct Connect 连接另一端的本地资源上。

应用程序负载均衡器已将目标分成了目标组。在今天发布的版本中,每个目标组现在都有一个目标类型属性:

instance – 和以前一样,目标通过 EC2 实例 ID 进行注册。

ip – 将目标注册为 IP 地址。您可以对负载均衡器 VPC 内的目标使用来自负载均衡器 VPC CIDR 的任何 IPv4 地址,对负载均衡器 VPC 之外的目标 (包括对等 VPC、EC2-Classic,和可通过 Direct Connect 或 VPN 访问的本地目标) 使用 RFC 1918 范围 (10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16) 或 RFC 6598 范围 (100.64.0.0/10) 内的任何 IPv4 地址。

每个目标组都有负载均衡器和运行状况检查配置,并一如既往地将指标发布到 CloudWatch。

假设您正处于将应用程序迁移到 AWS 的过渡阶段,或者希望使用 AWS 通过 EC2 实例来扩充本地资源,并需要将应用程序流量分配到 AWS 和本地资源中,则可以将所有资源 (AWS 和本地) 注册到同一个目标组并将该目标组与负载均衡器相关联。或者,您也可以使用两个负载均衡器在 AWS 和本地资源中实现基于 DNS 的加权负载均衡,即一个负载均衡器用于 AWS,另一个负载均衡器用于本地资源。如果应用程序 A 的后端位于 VPC 中,而应用程序 B 的后端位于本地,在这种情况下您就可以将每个应用程序的后端放在不同的目标组中,并使用基于内容的路由将流量路由到每个目标组。

创建目标组
接下来,我将介绍如何在创建应用程序负载均衡器的过程中创建目标组,从而将流量发送到一些 IP 地址。输入一个名称 (ip-target-1),并将 ip 选为目标类型:

然后输入 IP 地址目标。此类地址可以来自托管负载均衡器的 VPC:

也可以是上述某个私有范围 (适用于位于托管负载均衡器的 VPC 之外的目标) 内的其他私有 IP 地址:

检查设置并创建负载均衡器之后,只要指定的 IP 地址通过运行状况检查,系统便会向其发送流量。每个负载均衡器最多可以包含 1000 个目标。

我可以随时检查目标组并编辑目标集:

如您所见,在我抓取这个屏幕截图时其中一个目标的运行状况不佳 (这是故意设计的)。每个目标组的指标都会发布到 CloudWatch;我可以在控制台中查看这些指标,还可以创建 CloudWatch 警报:

现已推出
此功能现已在所有 AWS 区域推出,您可以立即开始使用。

Jeff

使用云伙伴系统,让您的迁移之旅不再孤单

Edmunds.com 全面迁移到 AWS 的相关经验

伙伴系统这个概念已经使用了数十年,应用范围涵盖生活的许多方面,包括学习、工作和探险。无论涉及哪一方面 (比如大学新生与其学长配对、空军飞行员与其僚机驾驶员或者您的周末潜水伙伴),大多数伙伴系统不外乎两个目的。一个是安全性,通常出现在需要双方相互照顾的体育或危险活动中。另一个是新入学的学生或新来的员工与经验更丰富的伙伴配对以便获得培训和指导,以免出现常见的新手错误,从而自信满满地快速进步。

就我个人来讲,如果 2012 年在我开始全面向云迁移时拥有云伙伴,一定能帮我解决不少难题并省去实验的麻烦。当时,我是北美地区最大的汽车购物网站之一 Edmunds.com 的首席信息官。

但与现在不同的是,当时很难从正在成功迁移的其他公司找到大量伙伴系统资源。如果具备大规模全面的参考案例 (除 Netflix 之外)、托管迁移计划或成熟的咨询合作伙伴生态系统,则迁移工作会容易得多。幸运的是,现在有大量专注于云迁移的人员、流程和技术,这意味着,组织再也不用像我们当时迁移 Edmunds.com 那样孤军奋战了;而且,加快云使用率和更大限度节省成本的相关专业技术水准也在不断提升,这使全面迁移战略变得比以往更加可行。

作为一名终身冲浪爱好者,我可以告诉您,如果有伙伴系统的帮助,即使在危险条件下,冲浪也不是什么了不起的事情。单打独斗被认为是终极精神追求。而如今,如果我要去世界上的陌生地方冲浪,则更愿意采用更加实用的方法。在登上冲浪板之前,我会试着找一位曾经去过那里的“伙伴”,从他那里了解所需的所有海浪相关信息。例如,珊瑚礁有多浅?有鲨鱼出没吗?哪种潮汐状况最适合冲浪?听取了这些方面的建议并学习了别人的经验后,我心中的疑虑通常会打消不少,而且冲浪体验也会得到提升。

最近,我加入了一个前任首席信息官 (他们构成 AWS 企业战略团队) 团体。我们的目标是帮助技术高管思考和拟定其云优先策略,为此我们所采取的一种方法是:制定和简化新型迁移加速计划,以利用我们所积累的知识 (经验是没有压缩算法的)。作为前任首席信息官和 AWS 客户,我们曾经负责过自己的云迁移工作,并在此过程中帮助过各种类型和规模的企业完成了转型,我们的经历就像我到一个新地方冲浪时从伙伴那里获得提示和建议一样。

回想一下,我从 Edmunds.com 迁移经历中得到了三点重要启示;正如您将看到的,即使我们在 2016 年初关闭了最后一个 Edmunds.com 数据中心,我们经历的过程也仍然与大部分企业迁移当前所经历的云采用阶段非常接近 —

我们将完全停止运营这个高性能数据中心

实际上,这不是当时的确切想法。作为当时的首席信息官,我的主要目标是交付技术能力,以超前满足业务需求。在进行云迁移前的 7 年里,我们不知疲倦地工作,开发出了一种被认为极其高效的基础设施运营和 DevOps 实践。但是,这种效率需要企业付出代价,尽管它提供了每日自动发布能力和前所未有的可靠性。这种代价就是,公司需要将越来越多的有限资源分配给支持代码 (私有云和 DevOps 工具集),从而导致没有足够的资源用于面向客户的应用程序代码 (新的客户功能和服务)。我们需要一种新的模式来控制支持代码与客户代码的比率,而不用牺牲任何功能。

2011/2012 年出现的新兴云趋势为企业提供了一种备选方案,它强调与单个公司孤军奋战相比,公有云 (尤其是 AWS 的规模) 能提供更好的基础设施和更优质的服务,而且价格更具竞争力。然而事实却不容乐观,围绕它的新闻层出不穷,报道内容无外乎:与成熟的本地安装相比,云更加昂贵且不太稳定。Netflix 早期曾采用 AWS,当时的情况有力地证明了这一论点:较成熟的大型企业可以在云中运行关键操作;但当时,我们无法为 Edmunds.com 业务找出更类似的参考实施。

同行参考在当时对我们来说极其重要,因为没有任何值得称道的伙伴系统迁移资源可以帮助我们利用成熟的云采用模式。

在缺乏这方面知识的情况下,我们分两步构建了我们的业务案例,这最后成为了任何公司进行云迁移的标准做法:

  1. 概念验证项目,即展示在云中运行关键操作的可行性。
  2. 全面云运营的实际财务模型,它能够经受住时间的考验,并至少展示出与当前基础设施的支出状况基本相当 (或成本更低) 的特征。

事后想来,决定采用完整版核心 Edmunds.com 网站来验证云的可行性并不是进行概念验证的最快或最简单的选择。但在将近 6 个月时间内经过几个专门的工程师的反复试验后,我们获得了无可争议的证据,甚至连之前总是跟我们唱反调的人都认为,云是 Edmunds.com 的最佳选择。如今,AWS 和出色的系统集成商开发了伙伴系统方法 (如停放区,这是 AWS 云采用框架的一个组件),让迁移业务案例比我们当初采取的方法进展得更加快速。

我们对结果非常满意,进而转入下一步,开始深入探究云经济。这时,我们尚未发现通过采用云原生架构实现的生产力的巨大飞跃,但我们相信迁移到云不太可能会毁掉公司。

开发财务模型似乎是一项同样让人望而却步的任务。此类模型必须真实,并且必须避免激进的优化假设。我们已经做到了高效和节俭,但老实说,我不知道最后我们的运营费用是会增加还是会减少。因此,经过一个多月的分析,我惊讶地发现,我们开发的保守财务模型证明,在完成向 AWS 迁移的两年计划 (与主要数据中心租约到期时间一致) 后,我们竟然会节省一小笔运营费用。这还不包括资本设备支出每年所节省的数百万美元。这个计划也有点像沙袋,因为它以纯粹的简单地搬运假设为基础,而我们确信在整个迁移过程中运营支出会大幅降低,但我们不知道如何提前证明这一点。

财务模型表现不俗,概念验证结果也极具说服力,因此,我们怀着激动的心情向首席运营官做了汇报,这次汇报受到了热烈欢迎,首席运营官立即批准了我们的 AWS 迁移建议。

我要指出的一个形式上的错误是,我过分强调了自由现金流的节省。我几乎完全忽略了运营支出这个优势,认为它不是通过审批的前提条件;相反,我将侧重点放在了更大的组合现金节省数字上。但结果证明,支持运营支出预测假设对首席运营官而言更加重要。

现在 AWS 云经济小组重点关注的是,增强业务案例宣传信息和预测更深层次的云费用节省的能力。但是,这样一个通过成熟技术帮助客户进行迁移和 TCO 建模的团队当时尚未完全成形。现在,AWS 云经济小组会在云迁移早期提供一些最好的伙伴系统资源,因为该小组拥有数千个迁移的相关数据,此类数据可通过最大限度提高业务案例中的服务器利用率和员工工作效率,帮助预测和量化节省的费用。

我认为我们实际上要在这方面取得成功

它并非不堪一击。但如果项目涉及每一个应用程序和系统,就会面临相当大的风险,而且企业绝不会容忍因后端增强功能而导致的任何延迟或中断。不过,完成应用程序和数据迁移后,您会发现组织最大的风险与停机或性能问题毫不相干,而是与能否完成迁移相关。在迁移过程中停滞不前不仅会影响您的云 TCO 模型,还会让公司长期无法专注于优先事务。

如前所述,在云迁移中尽早“寻找伙伴”真得非常重要。已经创建的大量伙伴系统资源可帮助避免我们在 Edmunds.com 迁移中遇到的诸多难题,而 AWS 迁移加速计划 (MAP) 等计划或 AWS Database Migration Service (DMS) 等工具就是广泛使用且具有针对性的伙伴系统资源的两个示例。所开发的这些资源融合了来自数千个客户迁移的意见和经验,此类计划和工具涵盖了大量成熟的迁移模式,例如,从 Oracle 迁移到 Amazon 的 RDS 托管数据库服务

尽管如此,在独自完成迁移的过程中,我们确实学到了一些有价值的东西。我相信,对于任何想要顺利轻松地到达终点的云驱动型组织来说,这些知识尤为重要 —

  1. 调整您的初始迁移原则并不会对架构造成损坏或导致迁移失败。您的云迁移策略原则必须足够灵活,以适应云灵活性及在云中运行的新经验。实际上,我们在开始 Edmunds.com 迁移时所秉持的原则是,仅利用核心计算 (EC2) 和存储 (S3、EBS)。但是,我们之所以这么做是因为对更高级别的 AWS 服务 (如 Amazon RDSAmazon CloudWatch Amazon DynamoDB) 缺乏了解。我们很快意识到这些新型云原生服务的集成和成本优势,包括在客户代码上花费更多时间的功能。现在,Edmunds.com 使用的 AWS 服务有三十多种。
  2. 为重构决策使用两周法则。我们是在灵活的原则 (可为我们提供重构机会) 下开始我们的两年迁移计划的;但由于数据中心租约的原因,任何因素都不能延迟两年目标,因此,直接迁移通常成为默认方法。然而,在迁移工作全面展开之后,团队却开发出了沿用至今的特定的两周经验法则。如果我们能在两周内重构堆栈内的次优组件或服务,我们就会重构,而不是直接迁移。例如,基于 NFS 的共享存储架构位于重构列表的前面,但它不符合两周法则,因此,我们将其安排在了迁移窗口的末期。另一方面,诸如负载均衡、缓存、OS 分配和 DNS 等许多对象也在迁移过程中使用新的两周法则进行了重构。根据迁移时间表或开发周期,您可能需要使用不同的时间段,但两周或一个开发冲刺是 Edmunds.com 的最优约束条件。此处提到的优质伙伴系统资源是指 AWS Application Discovery Service,系统集成商使用这项服务帮助公司发现和映射应用程序的依赖关系,然后再确定哪些内容适合直接迁移,哪些有机会重构。现在,您可以通过最近发布的 AWS Migration Hub 跟踪迁移状态。我会在以后的文章中介绍两周法则的其他相关信息。但在此期间,请务必阅读“将应用程序迁移到云的 6 大策略”,作者是 Stephen Orban,目前担任 AWS 全球企业战略主管。这篇文章很有启发性,提供了非常实用的构建思路。
  3. 您无需弃用现有团队并重新聘用一组云专家。Edmunds.com 没有专门为云迁移招聘一名员工,更不用说“云专家”了。在这方面我们的经验是:建立清晰的领导机制和等效的云卓越中心 (CCoE),并设定明确的目标和关键结果。我们的云迁移团队负责人 Ajit Zadgaonkar 的最初职责是领导我们的自动化测试团队 (SDET)。在与传统运营团队协作进行自动化配置及持续集成和交付方面,他的团队已经具备一定的经验。同样,Stephen Orban 也就此主题发布了一篇文章,建议您阅读他的这篇文章:“You Already Have the People You Need to Succeed With the Cloud”(您已经拥有成功实现云迁移所需的人才)。在这方面,需要考虑的另一个重要事项是,您要在新来的云/开发运营工程师与现有团队之间做出选择,前者对您的环境一无所知,后者在关键应用程序的依赖关系、流程和业务需求方面拥有多年的实践经验。我的 AWS 同事 Jonathan Allen Capital One 中详细介绍了他经历的这个过程,以培训现有团队并让其为云迁移做好准备。

弄清楚人员和文化等因素与您做出的技术决策同等重要,因为在迁移加速进行并涉及更多应用程序时,他们使内部伙伴系统能够确保组织内的一致性。

我庆幸自己没有把未来搞砸

第三点也是最后一点启示更多的是关于迁移结束之后的事宜 – 从我在组织内的新职位和角度来看。在我们完成向 AWS 的迁移之后不久,我不再担任首席运营官/首席信息官,转而成为 Edmunds 的首位首席数字官。担任这个职务后,我的主要职责是开发下一代广告平台并将新的商业模式推向市场,例如,在线汽车零售和消息传递应用程序。因此,我从云服务提供者变身为消费者。回想起来,我绝对是一名要求苛刻的客户!

将所有应用程序和数据都按计划迁移到 AWS 之后,Edmunds.com 成功地将 IT 开支削减了 30%。通过开始使用云原生架构 (自动扩展、微服务、临时计算) 优化或重新思考堆栈的每一个组件,或者通过直接使用 AWS 服务将组件完全替换掉,团队实现了更大的节省。我的新团队努力完成的许多计划都有技术框架,这与最初迁移到 AWS 的对象不同,而且在有些情况下,它们完全是无服务器的。现在,已经出现了针对无服务器架构的新兴伙伴生态系统,它正在改变云和本地安装之间的对比结果。

这些新型 AWS 服务 (如 AWS LambdaAWS Elastic BeanstalkAmazon Kinesis AWS GLUE) 绝不可能由 Edmunds.com 在内部合理地开发出来,但它们以之前难以想象的速度为客户提供了新功能。展望未来,在数据中心内可以完成的操作与云原生服务之间的差距只会越来越大。例如,主流的机器学习和人工智能与普通 Web 应用程序所要求的技术框架大相径庭。在内部维护这些不同的技能组合和专门的计算容量对大部分组织来说绝非最佳选择。

我会在以后的文章中,持续提供这方面的见解和建议。当然,目的是为了帮助您尽快上手,以便重塑自己的技术和业务。

在此期间,请试用伙伴系统,尽快开始或完成您的迁移。然后,您将可以使用云原生服务,减少用于维护基础设施的支持代码义务并交付更多客户代码。

最大的变化从简单的步骤开始 —

Philip Potloff
@philippotloff
potloff@amazon.com
企业战略家

 

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

作者:Iris Fu 和 Cambron Carter

这是一篇由工程总监 Cambron Carter 和 GumGum 的计算机视觉科学家 Iris Fu 联合发布的访客文章。用他们自己的话说,“GumGum 是一家在计算机视觉领域具有深厚专业知识的人工智能公司,能帮助客户充分发挥网络、社交媒体及广播电视每天生产的图像和视频的价值。”

目标物检测的最新技术 

检测是许多经典计算机视觉问题之一,已随着卷积神经网络 (CNN) 的采用而得到显著改善。随着 CNN 越来越多地用于图像分类,许多人都依靠粗糙和昂贵的预处理程序来生成候选区域 (region proposal)。通过诸如“选择性搜索”之类的算法根据区域的“客体性”(它们包含目标物的可能性) 生成候选区域,这些区域随后被馈送到训练用于分类的 CNN。虽然这种方法能得到准确结果,但需要很高的运行成本。Faster R-CNN,You Only Look Once (YOLO) 和 Single Shot MultiBox Detector (SSD) 等 CNN 架构通过将定位任务嵌入到网络中来折中解决该问题。

除了预测等级和置信度,这些 CNN 还尝试预测包含某些目标物的区域极值。在本文中,这些极值只是矩形的四个角点,通常称为边界框。先前提到的检测架构需要已经用边界框注释的训练数据,即,该图像包含一个人,而且此人在该矩形区域内。以下是分类训练数据和检测训练数据:

超级帅气又非常能干的工程师

我们开始对使用 Apache MXNet 和 Caffe 来训练 SSD 的体验进行比较。明显动机是以分布式方式训练这些新架构,而不降低准确性。有关架构的更多信息,请参阅“SSD: Single Shot MultiBox Detector”

训练工具 

对于这组实验,我们尝试了几款 NVIDIA GPU:Titan X、1080、K80 和 K520。我们使用 Titan X 和 1080 在内部进行了几次实验,但也使用了基于 AWS GPU 的 EC2 实例。此帖子仅限于 g2.2x 和 p2.8x 实例类型。幸运的是,我们已经有一些使用 MXNet 的可用 SSD 实施方案,例如这个,在此次讨论的实验中我们就使用了这个实施方案。值得注意的是,为了使实验更详尽,您应该将其他常见框架 (如 TensorFlow) 的基准测试数据也包含在内。

速度:使用 MXNet 调整批处理大小和 GPU 计数的影响

首先,我们来看看使用 MXNet 的多 GPU 训练会话的性能影响。前几个实验侧重于在 EC2 实例上使用 MXNet 对 SSD 进行训练。我们使用 PASCAL VOC 2012 数据集。这第一个练习的目的是了解 GPU 计数和批处理大小对特定 GPU 速度的影响。我们使用了几种不同的 GPU 来说明它们的绝对性能差异。如果您想进一步探索,还可了解有关不同 GPU 的价格和性能的许多信息。让我们从 g2.2x 实例附带的 K520 开始:


请注意,在批处理大小不变的情况下,添加额外的 g2.2x 实例 (每个实例一个 K520) 会使每台机器有大致恒定的速度。因此,每小时的训练周期数几乎呈线性增加。添加机器应该能继续缩短运行时间,但在某一点上可能会影响准确性。我们不在此处探讨这种情况,但需要提一下。

然后,我们想看看在本地 1080 上是否观察到这一趋势:

如预期的一样,一个 1080 轻松胜过五个 K520。除了发现的这个情况外,该实验也引起了一些人的质疑。我们发现在组合中再加入一个 1080 时,每个 GPU 的速度会大大降低。由于本实验中的进程间通信通过以太网进行,因此一开始我们认为自己受到了办公网络的限制。但根据 Iperf 数据,该假设并不成立:

我们的测试表明,我们办公网络中的带宽和传输量都高于两个 EC2 实例之间的这两个值。这就引出了我们的下一个问题:如果批处理大小是导致效率低下的原因怎么办?

啊哈!虽然仍比使用一个 1080 慢得多,但在增加一个 1080 (在单独的机器上) 的同时增加批处理大小可提高速度。我们来看一下训练对具有多个互连 GPU 的机器的影响:


我们使用了自己的内部 NVIDIA DevBox,其中包含四个 Titan X。保持批处理大小不变,但增加 GPU 数量 (技术上减少每个 GPU 的单个批处理大小),可将速度提高大约 2.5 倍!这就引出了一个显而易见的问题:如果我们增加每个 GPU 的批处理大小会怎样?

我们观察到,当我们保持批处理大小恒定 (16),并增加同一机器上的 GPU 数量时,最终速度也会提高大约 2 倍。我们本想进一步探索,但 DevBox 风扇嗡嗡作响,让我们无法再增加批处理大小。我们 1080 实验的奇案仍然无解,作为一个悬而未决的问题而为人所知。AWS 的潜在解决方案可能是使用放置组,在本文中我们不探讨此方案。

准确性:使用 MXNet 调整批处理大小的影响

由于我们花那么精力来调整批处理大小,因此值得探讨一下调整批处理大小如何影响准确性。目标很简单:我们希望在保持准确性的同时尽可能地缩短训练时间。我们在用于徽标检测的内部数据集中进行了这组实验。我们使用 MXNet 在一个 p2.8x large 实例上开展这些实验。如果检测区域和地面实测区域之间的交并比为 20% 或更高,则我们认为检测是正确的。首先,我们尝试了批处理大小 8:

训练的三个不同阶段的查准率查全率曲线。SSD 使用 300×300 像素的输入尺寸,批处理大小为 8。

如果我们同等地对查准率和查全率进行加权,就会得到大约 65% 的查准率和查全率。让我们看看使用 MXNet 调整 SSD 中的输入尺寸时会发生什么:

SSD 使用的输入尺寸为 512×512 像素,其他所有数据均与上一个实验相同。

此时,我们实际上看到性能有所改善,查准率和查全率均为 70% 左右。输入尺寸仍为 512×512 像素,我们来研究一下调整批处理大小对准确性有何影响。同样,我们的目标是保持准确性,同时尽可能缩短运行时间。

SSD 使用的输入尺寸为 512×512 像素,批处理大小为 64。准确性与之前的实验不差上下。

再试一次!准确性保持一致,我们可以通过更大的批处理大小来缩短训练时间,从而从中获益。本着科学的精神,让我们进一步深入实验…

SSD 使用的输入尺寸为 512×512 像素,批处理大小为 192。准确性与之前的实验不差上下。

基本相同,虽然我们的操作准确性与上一曲线相比有所下降。尽管如此,我们成功地保持了准确性,同时将批处理大小增加了 24 倍。重申一下,每个实验都是使用 MXNet 在实施了 SSD 的 p2.8x large 实例上进行的。下面是批处理大小实验的总结,显示了各个实验不差上下的准确性:

MXNet 的 SSD 与使用 Caffe 训练的 SSD 一样准确。

要点是准确性不差上下。言归正传,我们来研究一下训练时间:

使用多种批处理大小的 Caffe 和 MXNet 的训练时间汇总。

当批处理大小增加时,预计减少的训练时间是显而易见的。不过,为什么我们在 Caffe 中增加批处理大小时,训练时间会大幅增加?我们来看看这两个 Caffe 实验的 nvidia-smi:

使用 Caffe 训练时 nvidia-smi 的输出,使用的批处理大小 8。请注意 GPU 使用率的波动。

GPU 要处理反向传播的巨大计算开销,这通过使用率峰值反应出来。为什么使用率会波动?可能是因为需要将训练数据从 CPU 批量传输到 GPU。在这种情况下,当 GPU 等待下一个批处理加载时,使用率将下降为 0%。我们来看看将批处理大小增加为 16 后的使用率:

使用 Caffe 训练时 nvidia-smi 的输出,使用的批处理大小 16。

使用率停滞的情况更为夸张,揭示出显而易见的低效率。这解释了为什么增加批处理大小后训练时间反而增加的现象。这并不新鲜或出乎意料。事实上,我们使用 Keras (和 TensorFlow 后端) 训练 Siamese-VGG 网络时,也遇到过这个问题。关于这个话题的讨论通常倾向于“您的模型越复杂,您能感知到的 CPU 到 GPU 的瓶颈就越少。”虽然这是事实,但并没有多大帮助。是的,如果您通过增加计算梯度的方式让 GPU 承担更多工作,一定会看到平均 GPU 利用率的增加。我们不想增加模型的复杂性,即使我们这样做了,也不是为了帮助我们实现总体目标。在这里,我们关注的是绝对运行时间,而不是相对运行时间。

如果对我们的实验加以总结,那就是使用 Caffe 的 SSD 训练时间远远多于使用 MXNet 的训练时间。使用 MXNet,我们观察到训练时间稳步减少,直至我们达到 192 这一批处理大小临界规模。仅通过采用 MXNet,我们就将训练时间从 21.5 小时缩短为 4.6 小时。与此同时我们没有发现准确性有所降低。这么说绝不是在攻击 Caffe – 它是我们非常看重的一个框架 – 而只是为了庆祝 MXNet 取得的成功。我们可以通过多种方式批评数据加载问题。也许 Caffe2 已经解决了这个问题。在这里我想说明的是我们并不需要这么做,如果有任何东西能够让机器学习开发人员感到暖心,那就是编写尽可能少的代码。虽然我们还有一些问题尚未得到解答,但这是采用新工具时的正常现象。我们很乐意被当做“实验豚鼠”,并且对 MXNet 的未来充满希望。

 

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是一个数字词典,它简化了要分发到实例的许可证密钥,密码和其他数据的存储和管理。 每个参数都有一个类型(字符串,字符串列表),以下是创建参数的方法:

Maintenance Window

Maintenance Window允许指定安装更新或其他系统维护操作的时间窗口。 例如创建一个周六的时间窗口,每个星期六四个小时:

创建维护窗口后,需要为其分配一组实例。 可以通过实例ID或标签来做到这一点:

然后需要注册一个在维护窗口时间段内执行的任务。 例如,可以运行一个Linux shell脚本:

Inventory

Inventory能够收集一组实例的软件和设置信息。 要访问Inventory,需要在托管实例清单中点击“Setup Inventory”:

“Setup Inventory”会创建一个由AWS拥有的文档和一组实例之间的关联。

Inventory运行后,可以选择一个实例,然后点击“Inventory”,以检查结果:

Patch Management

Patch Management可以帮助客户将Windows实例上的操作系统保持在最新状态。 在客户定义的维护窗口期间执行补丁程序,并且可以定义不同的基线。 “基线”指定了基于分类和严重性的补丁规则,以及要执行或忽略的补丁列表。

每个基线都可以应用于一个或多个补丁组。 补丁组内的实例都具有补丁组标签。 例如:

然后将标签值与基线相关联:

然后是使用AWS-ApplyPatchBaseline Document在维护窗口期间执行补丁程序:

还可以返回到托管实例列表,并使用过滤器来确定哪些实例需要补丁:

Automation

最后,Automation功能简化了常见的AMI构建和更新任务。 例如,你可以使用AWS-UpdateLinuxAmi Document每月构建一个新鲜的Amazon Linux AMI:

运行结果如下:

总结

Amazon EC2 Systems Manager是一套与日常运维工作结合非常紧密的运维工具,它不仅能够维护AWS云中资源,更能够在混合云架构中对企业自己数据中心中的资源进行管理,而且能够实现日常运维工作的自动化,大幅减低了混合云环境中的资源管理复杂程度和运维成本,是一个实在的运维管理好帮手。今天对EC2 Systems Manager的介绍就到这里了。希望对你的运维管理工作有所帮助。

如对AWS混合云架构解决方案感兴趣,请联系我们:

王宇    AWS企业混合云解决方案业务拓展经理    yuwangcn@amazon.com

 

作者介绍:

王宇,AWS企业容灾解决方案业务拓展经理,目前负责AWS中国区的混合云、容灾和DevOps产品和解决方案。曾服务于VMware等传统私有云厂商,熟悉传统IT架构和私有云、混合云、公有云的解决方案融合。

 

你需要知道的关于高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

综合和特例

还有一些特殊的情况也值得拿出来说一下: 如果我们特别在意存储网络的带宽的限制,完全可以使用带有instance-storage的实例类型,比如i系列和d系列。存储在本地,通过本地总线连接,就没有这个存储网络的限制啦。

某些情况下,追求极致的IOPS,也可以考虑使用条带化技术将多个卷合起来一起使用。

另外,如果我们的流量模型为从磁盘上一次读出,在计算节点上向多个client分发,简单的说就是具有fan-out效果的话,碰到瓶颈的地方大概率应该在EC2 intance的流出限制之上,而不是存储网络限制。

总结

总结一下,要获得期望的高IO。你需要准备

  • a. 合适的磁盘类型,磁盘个数,保证你需要达到IO在单卷和总卷限制范围以内。
  • b. 足够快的从磁盘到EC2的高速网络
  • c. 足够大的机型,以带来足够的inbound/outbound。
  • d. 适当的存储队列,保证磁盘够忙

好了,需要知道的所有关于EC2的IO性能的秘籍都在这儿了,马上动手,去榨干你购买的EC2的所有潜能吧。

作者介绍:

焦杨,AWS解决方案架构师,IT行业老兵,在Moto,NEC,路透,汉柏,AWS等国内外企业从业10余年。2011年之前,从事过web container, EJB container 和大型网站的后台研发工作,醉心于OO和设计模式。2011开始着手基于oVirt和Openstack的私有云平台研发工作,并亲密接触SDN,关注点随之转移到基础架构、分布式和高可用,自此自诩全栈工程师。 2015年加入AWS,担任解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计工作。,

基于S3的图片处理服务

作者:高寅敬 徐榆

1.背景介绍

随着移动互联网的快速发展,各种移动终端设备爆发式的增长,社交类APP 或者电商网站为了提升访问速度、提高用户体验,必须根据客户端的不同性能,不同屏幕尺寸和分辨率提供适当尺寸的图片。这样一来开发者通常需要预先提供非常多种不同分辨率的图片组合,而这往往导致管理难度的提升和成本的增加。

在这篇博客中,我们将探讨一种基于S3的图片处理服务,客户端根据基于HTTP URL API 请求实时生成不同分辨率的图片。

2.解决方案架构

为了保证图片服务的高可用,我们会把所有的图片(包括原图和缩率图)储存于AWS 的对象储存服务S3中,把图片处理程序部署于AWS EC2 中。大部分的图片请求都会直接由AWS S3返回,只有当S3中不存在所需缩率图时才会去请求部署于EC2 上的图片处理服务来生成对应分辨率图片。

业务流程:

  1. 用户客户端(通常是浏览器或者APP)发起请求200×200像素的图片
  2. S3中未存在该尺寸缩率图,于是返回HTTP 302 Redirect到客户端
  3. 客户端根据 HTTP 302响应,继续请求部署于 EC2 上的图片处理服务
  4. 部署于EC2的图片处理服务,会从 S3 获取源图
  5. 图片处理服务,根据请求参数生成对应尺寸图片缩率图
  6. 图片处理服务将对应的图片返回给客户端
  7. 图片处理服务把缩率图存回到S3中,加速下一次客户访问

3.架构特点

相较于预先生成所有所需分辨率图片和传统的基于独立图片处理服务器,这种新的处理方式包含以下优点:

更高的灵活性:

当我们的前端开发人员对界面进行改版时,时常会涉及到修改图片尺寸。对所有原始图片进行缩放的批处理是十分耗时,高成本且易出错的。利用这种基于URL API的实时处理方式,前端开发者指定新的尺寸后,立即就能生成符合客户访问新的网页和应用对应的图片,提高了前端开发人员的开发效率。

更低的储存成本:

对于传统图片处理方式,在未使用之前预先批量生成所需分辨率图片,占用大量的储存空间,而且利用率并不高。

以按需方式生成图片,能减少不必要的储存空间,降低储存成本。

相对于独立图片处理服务器把图片完全储存于EC2的EBS卷,储存于S3 的成本也更低。

我们知道缩率图是属于可再生数据,所以我们在程序上 会把缩率图储存为 S3的去冗余储存类型,再次降低约13% 的存储成本。

更高的服务可用性:

我们可以看到,独立地部署单台图片服务器,无法支持大并发负载。同时存在单点故障 无法保证服务的高可用性,高可扩展性。

而基于S3的解决方案,大量的图片请求,由AWS S3 来完成,S3 会自动扩展性能,因此应用程序的运行速度在数据增加时不会减慢。

只有少量的未生成的图片尺寸才会用到部署于EC2 的图片服务器,并且我们图片逻辑服务器与图片储存S3是解耦合关系,我们还可以针对 基于EC2的图片处理服务 进行横向扩展,比如把图片服务程序 加入到 Web服务器层,配合 负载均衡器 ELB、自动伸缩组 AutoScaling 来实现自动伸缩。

4.服务部署

为了服务部署能更接近生产环境,我们以下所有步骤将以创建一个以域名为 images.awser.me 的图片服务为例,来详细介绍如何基于AWS 来部署。

 

在EC2上部署图片处理服务

1.创建一台EC2服务器,并赋予 具有S3 访问权限的IAM 角色,配置正确的安全组开启 HTTP 80端口访问权限。

2.  示例程序基于PHP,所以需要确保服务器安装了 Apache 2.4 和PHP 7.0 以上。以及PHP 图片处理的相关的组件:ImageMagick、ImageMagick-devel 。

参考 基于Amazon Linux 的安装命令:

yum -y install httpd24 php70 ImageMagick  ImageMagick-devel php70-pecl-imagick php70-pecl-imagick-devel

3.  从 github 或者 从S3 下载图片处理程序,修改 根目录 resize.php 文件,bucketName 变量为你的域名或者是你的储存桶名称,例如:$bucketName=’images.awser.me’。

将程序部署于你的 web 目录底下,并且确保 能通过EC2 公网IP  进行访问。

例如:http://52.80.80.80/resize.php?src=test_200x200.jpg

最好为你的图片服务器设置一个域名,我们这里设置了 imgpro.awser.me。

例如: http://imgpro.awser.me/resize.php?src=test_200x200.jpg

这里记录下你的 EC2 Web 访问地址,在下一步的 S3 储存桶配置中会用到。

创建和配置S3储存桶

1.  创建储存桶

由于我们在生产环境中,需要使用指定的域名来访问S3资源。所以我们需要在S3 控制台 创建储存桶时,把储存桶名称设置为我们的域名,如: images.awser.me。

2.  储存桶权限控制

在刚刚创建的S3 储存桶,权限选项卡中 选择储存桶策略填写如下内容(注意修改 images.awser.me 为你的域名 或者 储存桶名称) 开启匿名访问

{

  "Version":"2012-10-17",

  "Statement":[

    {

      "Sid":"AddPerm",

      "Effect":"Allow",

      "Principal": "*",

      "Action":["s3:GetObject"],

      "Resource":["arn:aws-cn:s3:::images.awser.me/*"]

    }

  ]

}

3.  开启静态网站托管

在刚刚创建的S3储存桶,属性选项卡中 开启 静态网站托管 ,并配置 重定向规则 为以下示例内容(请修改HostName 为上一步骤 所创建的EC2 Web访问地址):

<RoutingRules>

  <RoutingRule>

    <Condition>

      <KeyPrefixEquals/>

      <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>

    </Condition>

    <Redirect>

      <Protocol>http</Protocol>

      <HostName>imgpro.awser.me</HostName>

      <ReplaceKeyPrefixWith>resize.php?src=</ReplaceKeyPrefixWith>

      <HttpRedirectCode>302</HttpRedirectCode>

    </Redirect>

  </RoutingRule>

</RoutingRules>

记录终端节点名称 例如:images.awser.me.s3-website.cn-north-1.amazonaws.com.cn

在DNS 服务商 添加一个CNAME记录 ,把你的自定义域名 如images.awser.me 解析到 该终端节点上。

4.  配置S3 存储桶生命周期,自动清理缩率图

随时时间推移,我们会发现我们保存着在大量过时的缩率图,造成储存空间的浪费。其实我们可以利用S3存储桶的生命周期功能,来实现一定时间范围以外的缩率图自动清理。

在S3储存桶管理选项卡中,选择 添加生命周期规则

由于我们在图片缩放程序中,产生缩率图的过程,已经给所有缩率图打上了一个特殊标签 thumbnail = yes,那么我们就可以在生命周期规则中,把该标签作为过滤条件,这样才不会影响储存桶中的其他资源(如原图)。

然后在过期选项中设置,过期时间为30天。

这样配置完以后,所有缩率图生成三十天后会自动清理,来节省储存和管理成本。

5.测试图片缩放

首先上传一张测试图片至S3存储桶,我们选择一张经典的地球图片作为测试 命名为earth.jpg。

1.测试使用 S3 终端节点访问,测试储存桶 权限是否配置正确:

http://images.awser.me.s3-website.cn-north-1.amazonaws.com.cn/earth.jpg

2.测试使用 自定义域名访问,测试储存桶命名以及DNS 配置是否正确

http://images.awser.me/earth.jpg

3.测试图片缩放功能是否正常,尝试请求一张 200×200 像素的图片:

http://images.awser.me/earth_200x200.jpg    

如果一切正常,我们可以看到浏览器 会自动跳转访问

http://imgpro.awser.me/resize.php?src=earth_200x200.jpg

并返回200×200 像素的图片。

4.测试S3 缓存是否生效,当我们第二次访问

http://images.awser.me/earth_200x200.jpg                                                                                                                     如果一切正常,我们可以观察到 浏览器 没有做跳转。

6.总结

以上内容是对基于S3的图片处理服务解决方案的一个简单实现,也提到一部分生产环境可能遇到的问题,比如图片服务器的自定义域名、使用S3 低冗余储存类型来降低成本、缩率图的自动清理等。

其实实际生产环境还可以对成本进行进一步优化,比如可以分析S3 产生的访问日志,找出访问记录比较久远的对象 、调用S3 API 对长久未使用的缩率图进行定时清理,甚至可以根据日志做分析 找出热门的图片格式需求,提前针对热门图片生产缩率图,提高用户体验。

另外通过以上的架构描述可以看出,由于AWS 所提供的所有云服务都有丰富的API 接口 和详细的配置选项,它就像一个乐高玩具一般,开发人员或者架构师可以脑洞大开随意去组合它成为自己想要的产品。

 

作者介绍:

高寅敬,AWS解决方案架构师,负责基于AWS云计算方案架构的咨询和设计,在国内推广AWS云平台技术和各种解决方案。在加入AWS之前就职于美国虚拟运营商Seawolf海狼通讯,超过7年的互联网通信应用系统开发和架构经验。
超过5年的AWS实践经验, 精通基于AWS全球分布式VoIP系统的开发、运营及部署,深度理解AWS核心的计算、网络、存储以及云计算的弹性伸缩。

徐榆,AWS实习架构师,研究生一年级对云计算/大数据和人工智能有一定研究。

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 AgentGitHub 相关项目

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 ES集群。
  • 准备Amazon EC2实例。
  • 安装2.4.23版本的Apache HTTP服务器。
  • 在Apache HTTP服务器之上安装Amazon Kinesis Agent。
  • 准备ELB(弹性负载均衡)。
  • 创建Amazon ES索引和相应的日志对应关系。
  • 创建Amazon Kinesis Firehose发送系统。
  • 创建所有的IAM角色以及相应的权限规则。例如,Firehose需要将日志数据备份到S3中,那么就需要往目标S3桶上传数据的权限。
  • 为Firehose发送系统配置CloudWatch 日志流和日志组,以便在日志发送出现异常时进行排查。

EKK架构示意图:

要搭建本文中的EKK架构,你需要以下先决条件:

  • US West区域的Amazon EC2密钥对。
  • US West区域的S3桶。
  • US west区域的默认VPC。
  • 具有管理员权限的IAM角色,用来确保Amazon ES和Amazon S3通过Firehose获取到EC2上的日志数据

让我们开始吧:

从启动AWS CloudFormation模板开始创建整个系统

1. 在AWS CloudFormation控制台上,选择来 启动模板。请确保你在US West区域。

提示:如果你想下载这个模板并随后上传至AWS CloudFormation,你可以从随后给出的S3桶里面下载模板到你本地的电脑中。

2. 选择下一步

3. 在详细设置页面,提供以下信息:

a)软件栈名称:为你的EKK系统命名

b)实例类型:选择安装Apache HTTP服务器的EC2实例类型

c)密钥:选择US West区域的密钥对

d) SSH位置:可以通过SSH连接到EC2实例的IP地址范围,默认为0.0.0.0/0

e)web服务端口:Web服务器的监听端口,默认为80

4. 选择下一步

5. 在选项页面,为AWS CloudFormation模板提供你想要的可选信息,然后选择下一步。

6. 在回顾页面,检查模板的各项设置,点击确认然后选择创建系统。

整个创建过程大约耗时10-15分钟。

配置Amazon Kinesis Agent

等待AWS CloudFormation创建完整个EKK系统,然后开始配置Amazon Kinesis Agent。

1. 在AWS CloudFormation控制台中,选择资源标签页,找到Firehose发送系统的名称。你在随后的第3步中需要它来配置Agent。

2. 在输出标签页,找到并记录下Web服务器的公有IP地址。你随后需要通过它SSH登录到Web服务器上配置Agent。获得更多关于通过SSH连接EC2实例的信息,请参考通过SSH登录你的Linux实例.

3. 在Web服务器的命令行上,运行以下命令:

sudo vi /etc/aws-kinesis/agent.json

该命令会打开配置文件,agent.json,内容如下:

{ "cloudwatch.emitMetrics": true, "firehose.endpoint": "firehose.us-west-2.amazonaws.com", "awsAccessKeyId": "", "awsSecretAccessKey": "", "flows": [ { "filePattern": "/var/log/httpd/access_log", "deliveryStream": "", "dataProcessingOptions": [ { "optionName": "LOGTOJSON", "logFormat": "COMMONAPACHELOG" } ] } ] }

4. 将在资源标签页获得的Firehose发送系统名称填入deliveryStream栏目中,然后保存并退出。

5. 在命令行上运行以下命令:

sudo service aws-kinesis-agent restart

6. 在AWS CloudFormation 控制台中查看Amazon ES对应的逻辑ID域

7. 在AWS Elasticsearch服务页面中你可以查看到由AWS CloudFormation创建的ES集群

配置Kibana并分析日志数据

Amazon ES为每一个ES域都默认提供了Kibana的安装,你可以在域的展示页面找到Kibana endpoin的相关信息。

1. 在Amazon ES控制台,选择Kibana endpoin

2. 在Kibana中,为索引名称和模式选项键入logmonitor。该值是你为Web访问日志创建的AWS ES索引名称。来自AWS ELB的健康检查会产生Apache的访问日志,随后流经整个EKK数据线,最后在Kibana中被可视化展现出来供分析所用。

3. 在时间选择中,选择datetime

4. 在Kibana控制台,选择发现标签页来观察Apache日志。

Kibana提供了条形图、折线图、散点图、直方图、饼图等来对日志文件进行分析。

过去30天访问Web服务器的IP地址饼图

过去5分钟内访问Web服务器的IP地址条形图

你还可以将http响应、IP地址等各类信息绘制成图表,甚至组合它们,以此来提供对于Apache日志的更深洞见。

监控日志收集分析系统

在Firehose控制台上选择流数据,然后选择监控标签页来查询CloudWatch中针对Firehose发送系统的度量值。

当日志发送失败后,Amazon S3和Amazon ES上等日志会帮助你定位问题。比如,如下的截图显示了因为索引上的日期映射没有和源日志文件保持一致。

结论

本文中,我们展示了如何通过Amazon Kinesis Agent, Amazon ES和Firehose将Apache日志传输至Kibana并进行可视化分析。值得注意的是,Firehose会根据应用系统产生日志的速率来自动进行伸缩。获取更多如何扩展Amazon ES集群的信息,请参考Amazon ES 开发指南.

综上所述,使用类似Amazon ES和Amazon Kinesis Firehose这类的托管服务,让管理和维护日志收集分析系统变得十分轻松。更棒的是,你还可以通过在日志流数据上直接运行SQL语句来进一步提升EKK系统的性能和功能。而这一切都可以基于本文中给出的AWS CloudFormation 模板

 

译者介绍:

刘磊,曾供职于中国银联电子支付研究院,期间获得上海市科技进步一等奖,并申请7项国家发明专利。现任职于AWS中国专家服务团队,致力于为客户提供基于AWS服务的专业大数据解决方案、项目实施以及咨询服务。