Easel.sh 构建自定义计算架构以规避 AWS Lambda Web Functions 的闲置内存计费

对于一个持续 200ms 的请求后紧接着 345 秒的闲置，AWS Lambda Web Functions 可能导致计费内存时间达到请求时长的约 1,700 倍。这一发现促使运行 Web 应用程序的平台 Easel.sh 放弃该服务，转而构建自己的计算基础设施，以获得对资源分配和成本的控制。

五分钟闲置问题

虽然 AWS Lambda Web Functions 被设计为可以缩减至零，但该平台会对执行环境整个生命周期消耗的内存进行计费。Easel.sh 发现这些环境在请求完成后不会立即终止，而是保持活跃 5–7 分钟。

在针对六个代表性环境的实验中，测得的闲置时间在 313 到 411 秒之间。由于没有可配置的闲置超时来缩短这些窗口，即使应用程序不执行任何工作，内存成本仍保持活跃。

此图说明了 Easel.sh 在测试 AWS Lambda Web Functions 期间发现的具体闲置时间。

由 HN Digest 根据 easel.sh 报告的数据绘制；数值按源文件显示。

对低流量工作负载的经济影响

计费结构对流量不可预测的应用程序构成了特定挑战。对于稳定的请求流，闲置内存成本被分散到许多交互中；然而，对于每天仅接收少量请求的应用，单个请求的成本可能会被随后的闲置周期主导。

Easel.sh 指出，在他们的测试中，内存约占计算和请求成本的 88%。对于支持数千个独立部署的平台来说，这些累积的闲置费用与高容量、持续流量的经济模型完全不同。

性能与基础设施的权衡

为了解决计费问题，Easel.sh 将应用程序执行迁移到他们自己运营的服务器上，仅将传统的 Lambda 用于溢出处理。此举允许他们在单台机器上跨多个应用程序共享容量，从而消除了每个环境的闲置费用。

此图解释了转向共享容量以减轻闲置时间成本的架构转变。

初始基准测试显示，这种自定义基础设施在包括 JSON API 和服务端渲染在内的各种工作负载中，提供了 1.5–3 倍更快的中位热请求时间。此外，在 12 分钟闲置后，自定义主机比 AWS Lambda Web Functions 实现了 3.5 倍更快的冷启动。

此图提供了在热请求场景中观察到的性能提升数据。

此视觉效果支持了关于在自营基础设施上显著加快冷启动的说法。

研究结果的局限性

Easel.sh 提供的性能数据基于单一区域 (us-east-1) 和特定的 Next.js 16 应用程序。该公司指出，这些是早期结果，不构成全面的多区域性能研究或持续吞吐量的基准测试。

虽然转向自营计算在这些测试中提供了更好的成本控制和性能，但它引入了管理容量、处理故障以及确保在多样化的用户应用程序之间进行高效资源分配的责任。