首先

GraphQL缓存是一种通过在CDN上缓存GraphQL API的响应来卸载GraphQL服务器负载并加速API的缓存层。

我們在自家的EC網站LOWYA上導入了使用Amazon CloudFront的機制，該機制可以緩存ALB+ECS構建的GraphQL服務器的響應。因此，我們計劃在以下三篇文章中詳細介紹這個設置。

①背景和目的的介绍
②利用AWS Prototyping program进行开发
③在产品发布之前所解决的问题，以及導入所带来的效果

这篇文章是关于引言背景和目的的文章。

另外，发布包括本文在内的三篇文章是为了补充JAWS-UG SRE支部第四次演讲的内容。如果您有兴趣，请查看演讲资料。

关于导入效果

如果在第3篇文章中先写一下介绍效果，我们可以将AWS的总成本降低，因为ECS的成本节约超过了CloudFront的成本增加，并且API的响应时间在前端测量中最多改善了52%。如果您愿意，也可以阅读第2篇和第3篇的文章。

希望定位的读者

我在以下的读者中设想了一个人群。

• GraphQLをCDNでキャッシュする方法に関心がある人

• GraphQLを使用する開発者

サイト・サービスの可用性やパフォーマンスの課題に取り組むSRE・インフラエンジニア

这篇文章的内容可能不适用于以下情况。

1. 使用非 AWS 云服务，或使用 Akamai 或 Fastly 这样的 CDN

使用 AppSync

我会在此说明本文的前提条件。

• AWS を利用する

CloudFrontのオリジンとなるGraphQLサーバーは ALB + ECS（EC2でも可）で構成されている

引言的背景和目的

GraphQL caching 是指对 GraphQL 查询结果进行缓存的过程。

GraphQL缓存是指将GraphQL API的响应缓存到CloudFront，从而通过减轻GraphQL服务器的负载并加速API的缓存层。

通过使用现金贷款可以预期减少GraphQL服务器（原点）的基础设施成本，并提高其承受峰值负荷的能力。

导入的背景

GraphQL服务器的负载处理

当预测到将会出现访问集中（峰值）时，我们会事先实施扩展或增加规模的措施，但对于意外负载，自动扩展是我们所依赖的方式。虽然Fargate的启动时间已经有所改善，但在负载增加时由于目标跟踪扩展不能及时跟上，可能导致响应延迟或发生错误的情况。

AWS成本上涨

LOMYA的后端基础架构使用了ECS的容量提供程序，并且采用了常驻任务和按需任务的混合配置。与仅启动常驻任务相比，可以抑制成本增加，但因启动数百个任务而避免一定程度的费用增加是不可避免的。

对于Aurora来说，由于出现了尖峰事件，访问网站的次数会增加，直到恢复平时水平之前，需要进行扩展，从而导致成本增加。

未来即将面临的可扩展性问题

在不久的未来，扩大规模/扩展规模可能会达到限制的可能性。

针对数据库查询负载，可以通过使用Aurora读取端点来增加读取实例来应对，但是增加实例的数量和实例大小都有限制。而且成本也会很高，所以最好能够以更低成本的方式进行负载处理。

虽然很少会遇到达到ECS任务启动上限的情况，但也不能排除可能会达到配额限制的情况，这一点需要考虑在内。

导入的目的是什么？

希望能够改善上述问题，我们的目标是“缓存应该存储相同的响应结果，无论谁看到它”。

如果使用现金贷款可以将原始负载转移到内容分发网络 (CDN) 上，开发者可能能够以比调整应用程序和数据库查询或仅仅扩大/分散后端基础设施更便宜的费用来应对负载。

这篇文章的总结

本文介绍了GraphQL缓存的背景和目标。通过使用CloudFront，可以缓存“无论谁看到的响应都是相同的（应该是相同的）”，从而不仅可以减轻GraphQL服务器的负载，还可以提高速度。

我想在下一篇文章中描述一下关于GraphQL缓存的开发过程和背景。