AWS Elasticache 与 API 网关缓存 [英] AWS Elasticache Vs API Gateway Cache

问题描述

我是使用 AWS Lambda 的无服务器架构的新手，并且仍在尝试弄清楚某些部分是如何组合在一起的.我已将我的网站从 EC2(React 客户端和节点 API)转换为无服务器架构.React Client 现在使用 s3 静态 Web 托管，并且 API 已转换为使用 AWS Lambda 和 API Gateway.

I am new to Serverless architecture using AWS Lambda and still trying to figure out how some of the pieces fit together. I have converted my website from EC2 (React client, and node API) to a serverless architecture. The React Client is now using s3 static web hosting and the API has been converted over to use AWS Lambda and API Gateway.

在我之前的实现中，我使用 redis 作为缓存来缓存来自其他第三方 API 的响应.

In my previous implementation I was using redis as a cache for caching responses from other third party API's.

API Gateway 可以选择启用缓存，但我也研究了 Elasticache 作为一个选项.它们的价格相当，但 API Gateway 缓存略贵.

API Gateway has the option to enable a cache, but I have also looked into Elasticache as an option. They are both comparable in price with API Gateway cache being slightly costlier.

我在尝试使用 Elasticache 时遇到的一个问题是它需要在 VPC 中运行，而且我无法再调用我的第三方 API.

The one issue I have run into when trying to use Elasticache is that it needs to be running in a VPC and I can no longer call out to my third party API's.

我想知道使用一个比另一个有什么好处吗?现在我的缓存的主要目的是减少对 API 的请求，但这可能会随着时间的推移而改变.让一个 Lambda 专门用于首先检查 Elasticache 以查看是否存储了值以及是否触发另一个 Lambda 从 API 检索信息是否有意义，或者这是否可能.或者对于我的用例，API Gateway 缓存是更好的选择吗?

I am wondering if there is any benefit to using one over the other? Right now the main purpose of my cache is to reduce requests to the API but that may change over time. Would it make sense to have a Lambda dedicated to checking Elasticache first to see if there is a value stored and if not triggering another Lambda to retrieve the information from the API or is this even possible. Or for my use case would API Gateway cache be the better option?

或者可能是完全不同的解决方案.有点遗憾，主要是其他所有东西都符合免费套餐的条件，但拥有某种缓存每月会增加约 15 美元.

Or possibly a completely different solution all together. Its a bit of a shame that mainly everything else will qualify for the free tier but having some sort of cache will add around $15 a month.

我对这种设置仍然很陌生，因此将不胜感激任何形式的帮助或指导.谢谢！

I am still very new to this kind of setup so any kind of help or direction would be greatly appreciated. Thank you!

推荐答案

我想知道使用一个比另一个有什么好处吗?

Apigateway 内部使用 Elasticache 来支持缓存，因此在功能上它们的行为方式相同.使用 api 网关缓存的优点是 ApiGateway 在调用后端 lambda 之前检查 chache，因此您可以节省 lambda 调用由缓存提供的响应的成本.

Apigateway internally uses Elasticache to support caching so functionally they both behave in same way. Advantage of using api gateway caching is that ApiGateway checks chache before invoking backend lambda, thus you save cost of lambda invocation for response which are served by cache.

另一个区别是，当您使用 api 网关缓存时，缓存查找时间不会计入缓存未命中情况的29 秒集成超时"限制.

Another difference will be that when you use api gateway cache , cache lookup time will not be counted towards "29s integration timeout" limit for cache miss cases.

目前我缓存的主要目的是减少对 API 的请求，但这可能会随着时间的推移而改变.

我会建议您根据当前用例做出有关缓存的决定.您可以使用全新的缓存或不同的解决方案来满足其他缓存要求.

I will suggest to make your decision about cache based on current use case. You might use completely new cache or different solution for other caching requirement.

让一个 Lambda 专门用于首先检查 Elasticache 以查看是否存储了值以及是否触发另一个 Lambda 从 API 检索信息是否有意义，或者这是否可能.或者对于我的用例，API Gateway 缓存是更好的选择吗?

总的来说，我不会建议仅仅为了检查缓存值而使用额外的 lambda(只是为了避免延迟和加剧 lambda 的冷启动问题).无论哪种方式，如上所述，即使对于由缓存提供服务的请求，您最终也会为 lambda 调用付费.如果您使用 api gateway cache ，缓存的请求甚至不会到达 lambda.

In general, I will not suggest to have additional lambda just for checking cache value ( just to avoid latency and aggravate lambda's cold start problem ). Either way, as mentioned above this way you will end up paying for lambda invokation even for requests which are being served by cache. If you use api gateway cache , cached requests will not even reach lambda.

这篇关于AWS Elasticache 与 API 网关缓存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！