Хорошо ли AWS Lambda для API-отдыха в реальном времени? - PullRequest
0 голосов
/ 28 августа 2018

Я изучаю AWS Lambda и беспокоюсь о синхронизированных запросах в реальном времени. Тот факт, что лямбда имеет «холодный старт», не подходит для обработки петиций GET.

Представьте, что пользователь использует приложение и выполняет HTTP-запрос GET для получения Продукта или списка Продуктов. Если лямбда неактивна, то для ответа потребуется 10 секунд. Я не считаю это приемлемым время отклика. Хорошо или плохо использовать AWS Lambda для классического (синхронизация ответов) API Rest?

Ответы [ 3 ]

0 голосов
/ 28 августа 2018

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

Существует много дискуссий о задержке лямбды, например:

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

Несколько важных факторов, связанных с задержкой запроса:

  • холодный пуск => большая задержка
  • шаблоны запросов являются важными факторами при холодных запусках
  • если вам нужно развернуть в VPC (вложение ENI => более высокая задержка холодного запуска)
  • с использованием CloudFront -> Шлюз API -> Лямбда (больше уровней => большая задержка)
  • выбор языка программирования (Java, вероятно, самая высокая задержка при холодном запуске, Go наименьшая)
  • размер среды Lambda (больше ОЗУ => больше ЦП => быстрее)
  • Лямбда-счет и лимиты параллелизма
  • стратегия предварительного прогрева
0 голосов
/ 29 августа 2018

Мы успешно использовали AWS Lambda с разумным и приемлемым временем отклика. (API на основе REST / JSON + лямбда AWS + доступ к базе данных Dynamo).

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

Существуют методы разогрева, упомянутые в вышеприведенных постах.

0 голосов
/ 28 августа 2018

Как пользователь AWS Lambda + API Gateway (с Serverless Framework), мне тоже приходилось сталкиваться с этим.

Проблема, с которой я столкнулся:

  • Несколько запросов в день на лямбду (недостаточно, чтобы держать лямбды в тепле)
  • Приложение, критичное ко времени (пользователь разговаривает по телефону, ожидая ответа из текста в речь)

Как я обошёл это:

Идея состояла в том, чтобы найти способ вызывать критические лямбды достаточно часто, чтобы они не простужались.
Если вы используете Serverless Framework, вы можете использовать плагин serverless-plugin-warmup , который делает именно это.
Если нет, вы можете скопировать его поведение, создав работника, который будет вызывать лямбды каждые несколько минут, чтобы они оставались теплыми. Для этого создайте лямбду, которая будет вызывать другие лямбды, и запланируйте запуск CloudWatch каждые 5 минут или около того. Обязательно вызывайте свои лямбды для хранения с пользовательским значением event.source, чтобы вы могли выйти из них раньше, не запуская никакого реального бизнес-кода, поместив следующий код в самом начале функции:

if (event.source === 'just-keeping-warm) {
  console.log('WarmUP - Lambda is warm!');
  return callback(null, 'Lambda is warm!');
}

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

...