AWS лямбда с Elasticache Redis без NAT - PullRequest
1 голос
/ 09 марта 2020

Я собираюсь упомянуть мои потребности и то, что у меня сейчас есть, так что терпите меня. Во-первых, лямбда-функция, скажем, F1 , которая при вызове получает 100 ссылок с сайта. Большинство из этих ссылок говорят о том, что 95 совпадают с тем, когда F1 вызывался в прошлый раз, поэтому дальнейшая обработка должна выполняться только с этими 5 «новыми» ссылками. Одним из решений было записать в базу данных Dynamodb уже обработанные ссылки, и каждый раз при вызове F1 запрашивать базу данных и пропускать эти ссылки. Но я обнаружил, что «чтение базы данных», хотя в миллисекундах, удваивает время выполнения лямбды, и это может сложиться, особенно если F1 вызывается часто и если есть, скажем, миллион обработанных ссылок. Поэтому я решил использовать Elasticache с Redis.

Я быстро обнаружил, что к Redis можно получить доступ только тогда, когда F1 работает на том же VP C и поскольку F1 требуется доступ к inte rnet, вам нужен NAT. (Я не очень разбираюсь в сетях). Поэтому я следовал рекомендациям, настроил VP C и NAT и заставил все работать. Я был в восторге от улучшения производительности, почти снизил ожидаемую стоимость лямбды в два раза до 30 долларов в месяц. Но потом я обнаружил, что NAT не входит в бесплатный уровень, и мне приходится платить почти 30 долларов в месяц только за NAT. Это не идеально для меня, так как этот проект может разрабатываться месяцами, и я чувствую, что я плачу ту же сумму, что и compute только за inte rnet доступ .

Я хотел бы знать, делаю ли я какие-либо фундаментальные ошибки. Я правильно использую Elasticache? Есть ли лучший способ получить доступ к Redis и inte rnet? Есть ли способ структурировать мой стек по-другому, чтобы я сохранил производительность, не выплачивая в два раза больше суммы после окончания бесплатного уровня. Может быть, добавить еще одну функцию лямбда? У меня нет никаких идей. Любые минутные улучшения приветствуются. Спасибо.

1 Ответ

0 голосов
/ 09 марта 2020

Есть много способов сделать это sh, и у всех есть некоторые компромиссы. Несколько других идей для вас:

  1. Запуск F1 без VP C. Он будет иметь подключение напрямую к DynamoDB без необходимости использования NAT, что позволит вам сэкономить на стоимости шлюза NAT.

  2. Запустите вашу функцию на экземпляре micro EC2, а не в Lambda, и сохранить ссылки на некоторые файлы на локальном диске или даже на Redis. Я думаю, что, несмотря на всю шумиху вокруг сервера, люди иногда переоценивают сложность (и стабильность) простого запуска ОС. Управлять не так сложно, легко создавать резервные копии, и это может быть вариант в зависимости от ваших требований к доступности и других потребностей.

  3. Сохраните данные своей ссылки на S3 и настройте Конечная точка VP C до Конечная точка шлюза S3 . Не уверен, что это будет достаточно быстро для ваших нужд.

...