Как согреться AWS Lambda, вызываемый из API Gateway с интеграцией прокси - PullRequest
Новая
       76

Как согреться AWS Lambda, вызываемый из API Gateway с интеграцией прокси

0 голосов
/ 27 февраля 2019

Я определил лямбда-функцию, которая вызывается из API Gateway с интеграцией прокси.Таким образом, я определил для него путь активного ресурса:

enter image description here

И ссылался на мою лямбда-функцию:

enter image description here

Моя лямбда может обрабатывать запрос, например GET /myresource, POST /myresource.

Я пытался использовать эту стратегию, чтобы сохранить ее, описанную в acloudguru .Он состоит из настройки правила события CloudWatch, которое вызывает лямбду каждые 5 минут, чтобы она оставалась теплой.К сожалению, это не работает.

Я видел такое поведение:

  • Через некоторое время, скажем, через 20 минут, я звоню GET /myresource из API Gatewayи это занимает около 15 секунд.Последующие запросы продолжаются ~ 30 мс.Событие CloudWatch не имеет значения ...

  • Давайте предположим еще один длительный период без вызова шлюза.Если я подхожу к лямбда-консоли и вызываю ее напрямую (кнопка тестирования), она сразу же отвечает (менее 1 мс) на 404 (это нормально, потому что моя лямбда ожидает GET /myresource или POST /myresource).

enter image description here

Сразу после выполнения этой лямбда-консоли я вызываю GET /myresource из шлюза API, и это все еще занимает ~ 20 секунд.То есть функция все еще была холодной, несмотря на то, что ее вызывали с консоли Lambda.Это может объяснить, почему событие CloudWatch не работает, так как оно вызывает лямбду без установки метода / resource-url.

Итак, как я могу сделать этот конкретный случай с API-шлюзом с интеграцией прокси + Lambda остается теплымпредотвратить эти медленные первые запросы?

Ответы [ 2 ]

0 голосов
/ 27 февраля 2019

Денис совершенно прав насчет недетерминированного лямбда-поведения в отношении количества контейнеров, пораженных событиями CloudWatch.Я последую его совету, чтобы улучшить время запуска.

С другой стороны, мне удалось сделать так, чтобы мои события CloudWatch правильно воздействовали на лямбда-функцию, уменьшая (во многих случаях) количество холодных запусков.

Мне просто нужно было добавить дополнительный контроллер, сопоставленный с "/", с жестко закодированным ответом: 

@Controller("/")
class WarmUpController {

    private val logger = LoggerFactory.getLogger(javaClass)

    @Get
    fun warmUp(): String {
        logger.info("Warming up")
        return """{"message" : "warming up"}"""
    }
}

При этом вызов по умолчанию (/) из CloudWatch сохраняет большую часть тепла в контейнере.время.

0 голосов
/ 27 февраля 2019

На данный момент (2019-02-27) [1], периодическое правило события CloudWatch не детерминистически решает проблему холодного запуска.Но периодическое правило события CloudWatch уменьшит вероятность холодных запусков.

Причина в том, что сервер Lambda должен решить, использовать ли новый контейнер Lambda вместо существующего контейнера для обработки входящего запроса.Некоторые подробности, касающиеся повторного использования контейнеров Lambda, описаны в [1]

. Чтобы сократить время холодного запуска (а не уменьшить количество холодных запусков), можете ли вы попробовать следующее?1. увеличить объем памяти, выделенной для функции, 2. уменьшить размер пакета развертывания (например, удалить ненужные зависимости) и 3. использовать язык, такой как NodeJS, Python вместо Java, .Net

[1]Согласно сеансу переизобретения (39:50 при https://www.youtube.com/watch?v=QdzV04T_kec), команда Lambda рассчитывает улучшить задержку холодного запуска VPC в Lambda.

[2] https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/

...