Соединения MongoDB от AWS Lambda

Ответ 1

Функции AWS Lambda должны быть определены как функции без состояния, поэтому они не могут содержать состояние как пул соединений.

Эта проблема также была поднята в этом форуме форума AWS. 5 октября 2015 года инженер AWS Шон опубликовал, что вы должны не открывать и закрывать соединение для каждого запроса, создавая пул при инициализации кода вне блока обработчика. Но через два дня тот же инженер сообщил, что вы не должны этого делать.

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

Вместо подключения к MongoDB из вашей лямбда-функции вы можете использовать RESTHeart для доступа к базе данных через HTTP. Пул соединений для MongoDB поддерживается RESTHeart. Помните, что в отношении производительности вы будете открывать новое HTTP-соединение с RESTHeart по каждому запросу и не использовать пул соединений HTTP, как вы могли бы сделать в традиционном приложении.

Ответ 2

Restheart - это сервер на основе REST, который работает вместе с MongoDB. Он отображает большинство операций CRUD в Mongo для GET, POST и т.д., Запросы с расширяемой поддержкой, когда вам нужно написать собственный обработчик (например, специализированный запрос geoNear, geoSearch)

Ответ 3

Я запускал некоторые тесты, выполняющие функции Java Lambda, подключающиеся к Atlas MongoDB.

Как уже было сказано другими плакатами, Amazon повторно использует экземпляры, однако они могут быть переработаны и точное поведение не может быть определено. Таким образом, можно было бы закончить с устаревшими соединениями. Я собираю данные каждые 5 минут и нажимаю их на функцию лямбда каждые 5 минут.

Лямбда в основном делает:

• Создание или повторное использование соединения
• Запрос одной записи
• Запись или обновление одной записи
• закрыть соединение или оставить его открытым.

Фактический объем данных довольно низок. В зависимости от времени суток он варьируется от 1 до 5 кБ. Я использовал только 128 МБ.

Лямбдас побежал в N.Virgina, так как это место, где привязан свободный уровень.

При открытии и закрытии соединения каждый раз, когда большинство вызовов занимает от 4500 до 9000 мс. При повторном использовании соединения большинство вызовов составляет от 300 до 900 мс. При проверке консоли Atlas количество соединений остается стабильным. В этом случае стоит использовать повторное использование соединения. Создание соединения и даже отключение от набора реплик довольно дорого с использованием драйвера Java.

Для крупномасштабного развертывания следует выполнить более комплексные тесты.

Ответ 4

Вы должны считать, что lambdas не имеет апатрида, но реальность такова, что большую часть времени vm просто замерзает, а поддерживает некоторое состояние. Было бы глупо для Amazon создавать новый процесс для каждого запроса, чтобы они часто повторно использовали один и тот же процесс, и вы можете воспользоваться этим, чтобы избежать сбоев соединений.

Чтобы избежать соединения для каждого запроса (в случае повторного использования лямбда-процесса):

• Запишите обработчик, предполагая, что процесс повторно используется так, что вы подключаетесь к базе данных и используете lamba для повторного использования пула соединений (обещание db, возвращаемое с MongoClient.connect).

• Для того, чтобы лямбда не зависала, ожидая, когда вы закроете соединение db, db.close(), после обслуживания запроса сообщите, что он не ждет пустой цикл событий.

Пример:

var db = MongoClient.connect(MongoURI);

module.exports.targetingSpec = (event, context, callback) => {
  context.callbackWaitsForEmptyEventLoop = false;
  db.then((db) => {
    // use db
  });
};

Из документации о context.callbackWaitsForEmptyEventLoop:

callbackWaitsForEmptyEventLoopЗначение по умолчанию верно. Это свойство полезно только для изменения поведения обратного вызова по умолчанию. По умолчанию обратный вызов будет ждать, пока цикл событий Node.js не будет пуст, прежде чем заморозить процесс и вернуть результаты вызывающему. Вы можете установить для этого свойства значение false, чтобы запросить AWS Lambda, чтобы заморозить процесс вскоре после вызова callback, даже если в цикле событий есть события. AWS Lambda заморозит процесс, любые данные состояния и события в цикле событий Node.js(любые оставшиеся события в цикле событий, обработанные при вызове функции Lambda далее, и если AWS Lambda решит использовать замороженный процесс). Дополнительные сведения о обратном вызове см. В разделе Использование параметра обратного вызова.

Ответ 5

К сожалению, вам, возможно, придется создать свой собственный RESTful API для ответа на запросы MongoDB, пока AWS не найдет его. Пока у них есть только то, что вам нужно для их собственной базы Dynamo.

Ответ 6

В дополнение к сохранению соединения для повторного использования увеличьте выделение памяти для лямбда-функции. AWS распределяет процессор пропорционально распределению памяти и при изменении от 128 МБ до 1,5 Гбит время соединения, сниженное с 4 с до 0,5 с при подключении к атласу мангодба.

Подробнее здесь: https://aws.amazon.com/lambda/faqs/

Ответ 7

Я столкнулся с той же проблемой несколько раз назад, но я решил, поставив мое монго на тот же счет EC2. Я создал базу данных mongo на той же учетной записи AWS EC2, где находится моя функция лямбда.

Теперь я могу получить доступ к моему монго из функции лямбда с помощью частного IP.