导读

随着越来越强大的无服务器环境与内容分发网络（CDN）功能的结合，Amazon CloudFront使开发人员能够构建更接近终端用户执行功能的Web应用程序，根据用户的独特需求定制内容交付。本次会话深入探讨如何利用最新的边缘计算功能，同时优化性能和可扩展性。学习在边缘部署自定义逻辑的最佳实践和模式，使您能够充分利用CloudFront不断发展的功能。

演讲精华

以下是小编为您整理的本次演讲的精华。

2024年亚马逊云科技 re:Invent大会上的“Amazon CloudFront边缘计算的实际应用”(Practical Applications of Amazon CloudFront Edge Computing)环节由亚马逊云科技解决方案架构师Kamin Bogaj主讲。他首先阐明了本次讨论的重点是围绕亚马逊云科技的全球边缘基础设施，以Amazon CloudFront作为核心服务，使客户能够在边缘执行代码，为Web应用程序定制内容交付。

Kamin概述了会议议程，表示他们将首先回顾可用的边缘计算选项及其与CloudFront工作流程的集成。他强调了理解这一背景的重要性，因为CloudFront是所有依赖关系的源头，对这些依赖关系有深刻理解对于在架构中实施边缘计算解决方案至关重要。

随后，他们将探讨经过验证的使用案例，说明可以通过在边缘运行代码来解决哪些类型的问题，以及考虑这种方法的原因。最后，David Brown将分享提高性能、可扩展性和更好管理服务限制的最佳实践。

Kamin指出，虽然“边缘”一词可能与不同行业的各种技术相关联，但所有这些技术的共同特征是底层平台，因为它决定了部署模型、可用容量和可利用的功能。

对于本次讨论的主题，这将他们引向Amazon CloudFront，亚马逊云科技的内容交付网络，可以在全球范围内为各行业的客户改善Web应用程序交付。Kamin解释说，CloudFront的基础设施包括分布在84个城市和42个国家的400多个边缘节点(PoPs)，使全球终端用户能够低延迟获取内容。

Kamin接着深入探讨了CloudFront中可用的边缘计算选项，尤其是边缘函数。他解释说，边缘函数是可以在CloudFront的边缘位置执行的轻量级Node.js函数，允许客户修改查看器请求和响应。这种功能支持广泛的使用案例，如访问控制、缓存键规范化、响应渲染和源路由。

Kamin进一步阐述了边缘函数在CloudFront工作流程中的动态。他说明，边缘函数可以在请求-响应周期的不同阶段触发，包括查看器请求、源请求、源响应和查看器响应。每个触发器都提供了根据特定需求修改请求或响应的独特机会。

例如，查看器请求触发器允许函数在请求到达缓存之前执行，支持访问控制等用例，在这种情况下，未经授权的请求甚至可以在到达缓存之前被阻止。源请求触发器有助于缓存键规范化，提高可缓存性和受众细分。响应渲染用例涉及终止底层请求并从函数生成自定义响应，该响应可以被缓存并重用于后续请求。最后，源路由用例支持超出CloudFront本地基于路径的路由的高级源选择模式。

在响应路径上，Kamin强调，边缘函数可以弥补源逻辑的不当行为，例如添加缓存控制头、安全头，或补充在请求路径上执行的逻辑，如确保变体选择的会话粘性。

为了说明边缘函数的实际应用，Kamin提出了一个假设的新闻网站场景。该架构包括第三方内容管理系统(CMS)用于发布文章、CloudFront用于内容交付和性能优化，以及图像转换端点用于根据请求参数优化图像。

Kamin概述了该假设新闻网站的四个关键计划:

1.           解决滥用者利用图像转换端点扰乱缓存的问题，导致缓存未命中率增加、源负载加重和潜在服务中断。

2.           实施付费墙，启用基于订阅的服务。

3.           提供更好的方式来运行实验，如A/B测试，并为产品团队提供简单的界面来定义和启动实验。

4.           通过引入用户友好的URL来提高SEO排名，因为搜索引擎更青睐更具描述性的URL。

为了解决保护图像转换端点的第一个要求，Kamin建议利用查看器请求边缘函数来应用缓存键规范化。通过列出分辨率和屏幕尺寸等典型输入的离散值，该函数可以用最接近的匹配值覆盖不寻常的值，从而有效限制可能的缓存键变体数量，并缓解缓存扰乱问题。

对于实施付费墙的第二个要求，Kamin建议采用基于令牌的授权方法。在这种方法中，授权的客户端将持有加密签名的令牌，边缘函数将充当网关，验证令牌、签名和任何访问条件，如根据查看器国家或自治系统号码(ASN)限制访问。

为了适应不会持有授权令牌的SEO爬虫，Kamin建议利用亚马逊云科技 Web应用程序防火墙(WAF)及其机器人控制解决方案。机器人控制解决方案可以识别和验证SEO机器人流量，并用一个秘密头标记，边缘函数可以识别并跳过对经过验证的SEO爬虫的身份验证。

为了满足启用A/B测试和页面变体的第三个要求，Kamin建议使用键值存储作为产品团队推送页面配置的简单界面。当页面请求到达时，边缘函数将读取配置、将用户友好的URL转换为CMS可理解的原始URL，并随机选择适当的页面变体进行服务。

为了确保变体选择用例的会话粘性，Kamin建议实施一个补充的查看器响应边缘函数，该函数将设置一个包含所选页面变体值的cookie。后续的查看器请求将检查此cookie并服务相应的页面变体，而无需重新选择。

在介绍完假设场景后，Kamin介绍了AppsFlyer公司的Danny Torjeman，AppsFlyer是一家大量利用CloudFront边缘计算服务的客户，他将分享真实世界的使用案例和切实的结果。

AppsFlyer的研发副总裁Danny Torjeman表示，他很高兴能够在此次活动上发言，分享AppsFlyer的使用案例。他概述了AppsFlyer，将其描述为一个数字平台，用于衡量跨Facebook、Google、Amazon、TikTok和Snapchat等各种渠道的营销活动的有效性。

AppsFlyer的主要关注点是测量用户与应用程序的互动，包括安装、卸载以及应用程序所有者或其代表希望跟踪的重大应用内操作，以提高用户参与度和收入。Danny强调了AppsFlyer运营的大规模，他们的软件开发工具包(SDK)存在于全球数十亿台设备上，凸显了数据恢复力和亚马逊云科技高效接收和处理这些数据的能力的重要性。

Danny概述了他希望观众记住的三个关键要点:

1.           边缘计算对AppsFlyer的力量和价值。

2.           通过在一个半月内将90-95%的传入数据迁移到另一家云提供商的CDN，利用边缘计算功能而无需进行架构更改，从而实现了AppsFlyer架构的解耦。

3.           边缘计算为AppsFlyer带来的业务价值，导致客户满意度提高，最终使AppsFlyer感到满意。

为了强调AppsFlyer运营的规模，Danny分享了惊人的数字，包括每天处理约2200亿次广告展示(广告视图)、略少于点击量和事件，相当于在实时生产环境中每秒约250-260万个请求。

Danny接着深入探讨了AppsFlyer的入口高级架构，数据从各种平台和设备到达，经过Route 53进行DNS解析，然后通过CDN提供商进行分发。Amazon WAF附加用于安全和业务目的，正如Danny稍后将演示的那样。数据然后移动到应用程序负载均衡器(ALB)，并转发到实例，这些实例是Web处理程序，负责处理数据、实现逻辑将用户重定向到相关商店，以及AppsFlyer核心业务的下游处理。

Danny重点介绍了两个使用案例:

1.           用户代理处理和客户端提示

2.           Amazon WAF和CloudFront函数在源选择方面的协作

关于第一个使用案例，Danny解释了检索用户代理以进行广告互动的重要性，因为它对于确定用户的最佳商店以及为用户获取分配信用的归因逻辑至关重要。然而，随着Google引入了客户端提示来解决隐私问题，用户代理不再完全可用，必须明确请求增强用户代理数据。

Danny阐述了一种简单的方法，其中来自移动设备的点击将到达CloudFront、ALB和实例。与引入客户端提示之前不同，AppsFlyer无法检索到完整的用户代理。他们必须添加逻辑来识别缺失的用户代理数据，向客户端发送请求以获取增强的用户代理，接收响应，然后继续重定向。这种方法引入了显著的往返延迟和工程复杂性。

为解决这一问题，AppsFlyer利用了CloudFront函数，将逻辑推送到边缘。CloudFront函数不是将请求转发到其Web处理程序，而是识别缺失的用户代理，生成一个请求以增强客户端，并在收到增强的用户代理后，将请求转发到AppsFlyer的服务器。这种方法将延迟减少了300-500毫秒(大约30%的改善)，消除了在AppsFlyer服务器上进行复杂重定向流程逻辑的需求，并确保了无缝的用户体验。

第二个用例解决了识别请求来源的需求，无论是来自客户端还是代表具有相同用户代理的客户端的服务器。对于AppsFlyer来说，这种区分至关重要，因为重定向是一个计算密集型的过程，应该避免对服务器端请求进行不必要的重定向。

最初，AppsFlyer依赖于货币化网络和合作伙伴提供的可选查询参数来指示是否需要重定向。然而，这种方法缺乏控制力，因为合作伙伴可能无法始终如一地声明重定向的需求。

为了处理每分钟5000万个请求，AppsFlyer需要大约160个Kubernetes Pods，由于不必要的重定向和增加的计算需求而导致效率低下。

AppsFlyer通过Amazon WAF和CloudFront函数的协作解决了这个问题。他们为服务器和客户端请求定义了速率规则，根据速率对每个请求进行计数和标记，并使用Amazon WAF根据标记将请求转发到相应的ALB。这种方法消除了在ALB本身上使用复杂规则的需求。

为进一步优化解决方案，AppsFlyer利用CloudFront函数读取WAF分配的标记，并将请求路由到相关的ALB，有效地将选择源的逻辑与ALB解耦。

这种方法带来了两个好处:通过避免不必要的重定向来卸载源，以及将所需的计算实例从160减少到95，计算成本降低了40%。

在Danny的演讲之后，Amazon CloudFront的主要产品经理David Brown讨论了利用边缘计算服务的扩展和最佳实践。

David承认客户普遍担心边缘计算解决方案无法扩展以处理他们的工作负载。他向观众保证，虽然需要考虑一些限制，但了解这些限制将有助于确定CloudFront是否能够满足他们的需求。

David首先讨论了Lambda@Edge的限制和扩展考虑因素，Lambda@Edge是亚马逊云科技的无服务器计算服务，允许在CloudFront边缘位置运行函数。

需要考虑的第一个限制是并发性，它表示Lambda在一个区域中可以同时运行的函数实例数量。并发限制在该区域的所有Lambda函数里共享，包括Lambda@Edge和标准Lambda函数。

第二个限制是每秒事务数(TPS)或Lambda可以处理的请求数。这个限制是给定区域中并发限制的10倍。例如，如果并发限制是1000，TPS限制将是每秒10000个请求。

为了理解这些限制如何转化为现实世界场景，David提供了一个方程式，用于在请求/秒和所需并发性之间转换。如果函数的平均持续时间低于100毫秒，所需并发性可以通过将请求/秒除以10来计算。如果函数的平均持续时间超过100毫秒，所需并发性可以通过将请求/秒乘以函数持续时间(以秒为单位)来计算。

David举了一些例子加以说明，包括一个源请求函数，每秒5万个请求，缓存命中率为92%，导致每秒4000个请求命中Lambda，平均持续时间为200毫秒，需要800个并发实例。对于同样每秒5万个请求但平均持续时间为50毫秒的查看器请求函数，所需并发性将是5000。

转而讨论CloudFront Functions，David解释说，虽然没有并发扩展限制，但函数执行时间有限制。CloudFront Functions提供了一个名为计算利用率的指标，代表执行函数所花费的总允许时间的百分比。

为确定函数是否会被节流，CloudFront会计算最近50次函数调用的简单移动平均值。只要这个移动平均值保持在最大允许时间以下，函数就不会被节流，从而允许偶尔出现执行时间峰值而不影响应用程序。

接下来，David分享了优化代码和有效利用边缘计算服务的最佳实践:

1.           避免在CloudFront Functions中使用全局变量，因为每次调用都是一个新的实例，全局变量不会在调用之间保留状态。

2.           尽可能使用原生JavaScript函数而不是正则表达式，以获得更好的性能。

3.           使用Key-Value Store时，考虑进行多次读取，而不是将所有数据塞进单个键值对并在函数中解析，因为从内存读取比解析复杂的数据结构更快。

4.           对于Lambda@Edge函数，尝试不同的内存设置，因为更高的内存分配有时可以显著提高性能，而只会增加适度的成本。

5.           将不同事件触发器的相关函数打包到单个Lambda@Edge函数中，以减少冷启动并增加重用热实例的可能性。

6.           确保外部网络调用库在可能的情况下重用连接，因为Lambda在重用热实例方面效率很高，重用已建立的连接可以提高性能。

总之，本次会议全面介绍了Amazon CloudFront的边缘计算能力、AppsFlyer的实际用例以及优化性能、扩展和管理服务限制的最佳实践。演讲者强调了解CloudFront的上下文、依赖关系和限制的重要性，以便做出明智的决策并有效利用边缘计算解决方案。

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。