Бессерверный пул соединений с базами данных

Question

Я пытаюсь создать приложение на aws, которое на 100% без сервера (за исключением базы данных на данный момент), и я сталкиваюсь с тем, что база данных является узким местом.Мое приложение может очень хорошо масштабироваться, но моя база данных имеет конечное число подключений, которые она может вместить, и в какой-то момент мои лямбды будут выходить за этот предел.Я могу выполнять пул соединений вне обработчика в моих лямбдах, так что есть соединение с базой данных для каждого лямбда-контейнера, а не для каждого вызова, и хотя это увеличивает количество одновременных вызовов до того, как я достигну своего предела соединения, ограничение все еще существует.

У меня два вопроса.1. Решает ли это серверное сияние путем автоматического масштабирования, чтобы увеличить количество экземпляров, чтобы удовлетворить потребность в большем количестве соединений.2. Есть ли другие решения этой проблемы?

Кроме того, от других разработчиков, заинтересованных в работе без серверов, я пытаюсь сделать что-то, что не стоит делать?Мне нравится, как легко развертывание с безсерверной средой, но лучше ли просто работать с микросервисами в чем-то вроде Kubernetes?

Answer 1

Лучшие практики AWS рекомендует воспользоваться преимуществами горячего старта.Подробнее об этом вы можете прочитать здесь: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.Lambda.BestPracticesWithDynamoDB.html

Answer 2

Я считаю, что есть два возможных решения этой проблемы:

Первый и самый простой вариант - воспользоваться «горячим состоянием лямбды», это концепция, когда Lambda повторно использует контекст выполнения для последующих вызовов.Согласно предложению AWS

Все объявления в вашем коде функции Lambda (вне кода обработчика, см. Модель программирования) остаются инициализированными, обеспечивая дополнительную оптимизацию при повторном вызове функции.Например, если ваша функция Lambda устанавливает соединение с базой данных, а не восстанавливает соединение, исходное соединение используется в последующих вызовах.Мы предлагаем добавить логику в ваш код, чтобы проверить, существует ли соединение до его создания.

По сути, в то время как лямбда-функция является горячей стадией, она "может / должна" повторно использовать открытое соединение (я).

Ограничения следующие:

• вы повторно используете соединение только для одного лямбда-типа, поэтому, если у вас есть 5 лямбда-функций, вызываемых все время, вы все равно будете использовать 5 соединений
• когда у вас есть всплеск лямбда-вызовов, включая параллельные исполнения, этот подход становится менее эффективным, поскольку лямбда будет выполняться в новом контексте выполнения для большинства запросов

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

Хотя второй вариант обеспечивает более согласованное решение, он требует гораздо большегоинфраструктура.

• вам потребуетсядля запуска отдельного экземпляра для пула, и если вы хотите сделать все правильно, возможно, по крайней мере, два экземпляра и балансировщик нагрузки (если не используются контейнеры).

Хотя это может быть слишком сложно для обеспечения такого количествадополнительная инфраструктура для пула подключений, она по-прежнему может быть допустимым вариантом в зависимости от масштаба проекта, вашей существующей инфраструктуры (может быть, вы уже используете контейнеры) и экономически выгод