利用Graviton2和CloudFront为S3对象存储动态生成缩略图

作为开发人员，经常要提供各种尺寸的图像，以确保不同屏幕尺寸和分辨率的设备都有出色的访问体验。这样对于图片的管理就会变得非常复杂。存储在S3上的图片经常会被处理成各种尺寸，以适应网站和APP。

本文将阐述一种方式，当设备访问S3上图片的时候，会生成一张适当尺寸的图片返回设备。

实际在2017年时，亚马逊云科技发布了一个解决方案——Serverless Image Handler

https://aws.amazon.com/solutions/implementations/serverless-image-handler/

这个方案利用Lambda和API Gateway动态的生成的缩略图。本文所实现的功能与Serverless Image Handler完全一致，但本文利用了新发布的Graviton2机型，在拥有海量工作负载且变化平缓的前提下，可以达到对成本大幅度优化。可以从下表看出Serverless Image Handler与Graviton2处理缩略图所适用的不同场景：

本解决方案优势

灵活地处理图片：只需在URL中添加需要生成的图片尺寸，即可动态生成，并且借助Graviton2升级的浮点运算性能，可以更加快速地对图片进行处理。

优化成本：仅当一张图片需要改变其尺寸时，才会触发并快速生成。这样可以尽可能地节约存储空间。并且利用Graviton2处理图片，比相同规格的Intel芯片EC2实例便宜20%。

高可靠性：本方案利用了CloudFront的Origin Group功能，确保了访问S3对象不会出现404的情况。并且利用Auto Scaling Group，使处理图片的Graviton2 EC2实例也保持高可靠性。

架构概览

如果用户通过APP访问一张原始图片，会先请求这张原始的图片的缩略图，这样可以更快加载图片。这个请求被转发至CloudFront。CloudFront有Origin Group的功能，这个功能可以让一个CloudFront分发有两个源站，如果第一个源站返回400或500，CloudFront分发会把请求转发给设定的第二个源站。利用CloudFront的Origin Group功能，我们让S3存储桶成为第一个源站，当请求的缩略图没有找到，CloudFront会把请求转发给我们设置的第二个源站：一个Auto Scaling Group Gravition2集群，这个集群会提取URL中信息,URL里提供的bucket名称和原始图片名称以及需要修改成的长宽，从S3存储桶找到原始图片，然后把缩图略返回并且保存回S3存储桶。

1.用户请求原始图片thumber-test.example.com/test.jpg的300像素乘以300像素缩略图，这个缩略图的URL为thumber-test.example.com/test.jpg/thumb_300_300.jpg

2.通过CloudFront分发的Origin Group，将请求转发至第一个源站S3存储桶。

3.如果缩略图S3:// thumber-test/test.jpg/thumb_300_300.jpg存在，则直接返回，整个流程结束。如果缩略图不存在，则S3存储桶返回400。

4.由于S3存储桶返回的是400，根据CloudFront Origin Group的设定，将请求转发给第二个源站：一个Auto Scaling Group Gravition2集群。

5.Gravition2集群上的应用程序对请求URL进行分析，提取原始图片名称jpg，以及缩略图尺寸300 X 300。从S3存储桶下载原始图片S3://thumber-test/test.jpg，并对其进行尺寸修改。

6.程序在名为thumber-test 的S3存储桶中创建文件夹：“jpg/”，将缩略图thumb_300_300.jpg上传至其中。

7.同时也返回给CloudFront缩略图文件。

8.CloudFront将文件返回至用户。

部署指南

1.首先我们参考这篇blog：

https://aws.amazon.com/cn/blogs/china/use-graviton2-example-to-build-a-cost-effective-php-load-operating-environment/

其中2.1、2.2和2.3，搭建一个基于Gravition2 EC2实例的php运行环境。如果用于生产，可以搭建一个Auto Scaling Group，但搭建ASG并不是本文重点，所以仅以单台EC2实例为例。

2.将https://github.com/nwcd-samples/thumber/blob/main/s3thumber.php 文件放入EC2实例上的/usr/share/nginx/html/目录，并且设置为默认首页。

3.创建一个名为thumber-test的S3存储桶，在“备用域名(CNAMEs)”填入一个二级域名，并且确保子域名与S3存储桶名称一致，如：thumber-test.example.com，并上传图片jpg至存储桶。

4.打开CloudFront服务，创建一个基于thumber-test存储桶的分配。然后点击进入刚创建的分配，选择“源和源组”，点击“创建源”，在“源域名”中填入新创建的Gravition2 EC2实例的域名。

1.在相同页面，选择“源组”中的“创建源组”，依次添加S3存储桶源和EC2实例源。并在“故障转移条件”中勾选404与403。

2.在标签栏选择“行为”，选择默认行为，点击“编辑”，在“源或源组”处选择刚创建的源组ID，然后保存。

3.将二级域名thumber-test.example.com的CNAME指向分发的域名。

4.此时可以进行验证，在浏览器输入https:// thumber-test.example.com/test.jpg/thumb_300_300，会返回一张长宽为300像素的图片。进入名为thumber-test的S3存储桶，可以看到多了一个名为“jpg/”的文件夹，里面有一文件名为thumb_300_300。像素尺寸可以根据需求自由修改。

结论

部署完成后，我们使用同样大小机型，c6g.large、c5.large、c5a.large，模拟客户生产环境中进行测试，测试数据集由10%的5M以下，20%的20M以上图，以及70%的5M到20M大小图片组成。经过测试可以得到以下结果（由于可能实际系统参数、数据集等细节不同，会造成最终测试结果不同，所以隐去了测试结果具体数值）：

可以看出，c6g.large在同样大小的机型中，运行php修改图片大小程序性能最好，价格最低。并且c6g还有尺寸更小的实例，可以利用c6g实例搭建auto scaling group，其弹性粒度比另外两种实例更佳。

本篇作者

夏焱

亚马逊云科技解决方案架构师

目前专注于容器化解决方案。在加入亚马逊云科技之前，曾就职于惠普、IBM等科技公司，从事数据中心基础架构相关工作，拥有十余年技术服务经验。