AWS Elasticache Vs кеш шлюза API

Question

Я новичок в архитектуре без серверов, использующей AWS Lambda, и все еще пытаюсь выяснить, как некоторые из этих частей сочетаются друг с другом.Я преобразовал свой веб-сайт из EC2 (клиент React и API узла) в безсерверную архитектуру.React Client теперь использует статический веб-хостинг s3, и API был преобразован для использования AWS Lambda и API Gateway.

В моей предыдущей реализации я использовал redis в качестве кэша для кэширования ответов от сторонних API.

API-шлюз имеет возможность включить кэш, но я также рассмотрел Elasticache в качестве опции.Они оба сопоставимы по цене с кешем API Gateway, который немного дороже.

Одна проблема, с которой я столкнулся при попытке использовать Elasticache, заключается в том, что он должен быть запущен в VPC, и я больше не могу вызывать свои сторонние API.

Мне интересно, есть ли какая-то польза от использования одного над другим?Сейчас основная цель моего кеша - сократить количество запросов к API, но со временем это может измениться.Имеет ли смысл иметь Lambda, предназначенную для проверки Elasticache, чтобы сначала проверить, есть ли сохраненное значение, и если нет запуска другой Lambda для получения информации из API, или это вообще возможно.Или для моего случая использования кеш API Gateway будет лучшим вариантом?

Или, возможно, совершенно другое решение вместе.Немного обидно, что в основном все остальные будут претендовать на бесплатный уровень, но наличие какого-то кеша будет приносить около 15 долларов в месяц.

Я все еще очень новичок в такого рода настройках, поэтому любая помощь или направление будут с благодарностью.Спасибо!

Answer 1

Мне интересно, есть ли какая-либо польза от использования одного над другим?

Apigateway внутренне использует Elasticache для поддержки кэширования, поэтому функционально они оба ведут себя одинаково.Преимущество использования кэширования шлюза api заключается в том, что ApiGateway проверяет chache перед вызовом лямбда-кода бэкэнда, таким образом, вы экономите затраты на лямбда-вызов для ответа, который обслуживается кешем.

Еще одно отличие состоит в том, что при использовании кэша шлюза API время поиска в кэше не будет учитываться в пределе «время ожидания интеграции 29s» для случаев пропуска кэша.

Сейчас основнойЦель моего кеша - уменьшить количество запросов к API, но со временем это может измениться.

Я предлагаю принять решение о кеше на основе текущего варианта использования.Вы могли бы использовать совершенно новый кеш или другое решение для других требований к кешированию.

Будет ли целесообразно иметь лямбда-адрес, предназначенный для проверки Elasticache, чтобы сначала проверить, есть ли сохраненное значение и если нет запуска другого лямбдаполучить информацию из API или это вообще возможно.Или для моего случая использования кеш API Gateway будет лучшим вариантом?

В общем, я не буду предлагать иметь дополнительную лямбду только для проверки значения кэша (просто чтобы избежать задержки и усугубить проблему холодного запуска лямбды)).В любом случае, как упомянуто выше, таким образом, вы в конечном итоге заплатите за лямбда-вызов, даже за запросы, которые обслуживаются кешем.Если вы используете кеш шлюза api, кэшированные запросы даже не доходят до лямбды.