Время ожидания AWS Lambda

Question

Я испытываю неожиданные скачки времени ожидания для функции AWS Lambda. Функция вызывается ~ 7 миллионов раз в день - постоянные номера звонков происходят каждые 5 минут. Пики, которые я вижу, обычно составляют около 1000 тайм-аутов в течение получаса. В остальное время обычно нет таймаутов.

Вот пример дня с таймаутами, подсчитанными по оси Y.

Время ожидания для функции составляет 30 секунд. Функция имеет среднее время выполнения ~ 50 мс и ожидаемое максимальное время работы ~ 5 секунд для большого ввода. Функция использует среду выполнения Python3.6 и не использует функцию ENI / VPC Lambda, поэтому холодный запуск обычно занимает всего пару секунд.

Чтобы выяснить время ожидания, я копался в журналах CloudWatch во время истечения времени ожидания. Не было сообщений журнала или исключений из тайм-аутов, только сообщение: Task timed out after 30.03 seconds.

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

def business_logic():
    ...
    queue.put(result)

def lambda_handler(event, context):
    thread = threading.Thread(target=business_logic)
    thead.start()

    while queue.empty():
        if seconds_running > 10:
            comprehensive_logging()

Я проверил это правильно, добавив спящие в business_logic и подтвердив, что функция comprehensive_logging. Однако во время фактических таймаутов comprehensive_logging не было , никогда не достигалось.

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

Вопрос

• Есть ли в этой теории вода?
• Есть ли другие возможные причины, которые я мог упустить из виду?
• Кто-нибудь испытывал что-нибудь подобное?

Другие детали:

• Функции вызываются напрямую с подписанным запросом SigV4
• Я использую библиотеку Chalice для обработки запросов.
• Есть несколько больших двоичных файлов, с которыми Python взаимодействует при каждом выполнении через SWIG
• Функция не не взаимодействует с какими-либо внешними ресурсами

Примечание. Я неохотно добавляю подробное ведение журнала для всех вызовов из-за стоимости CloudWatch.

Answer 1

Рассматривали ли вы изменение настройки тайм-аута для функции? 30 может быть по умолчанию с чашей по умолчанию. Но если это будет превышено, то вы действительно не получите запись, так как она прекращается до того, как это произойдет. Я бы установил тайм-аут на несколько минут, а затем посмотрел в журналах долгосрочно работающие функции, чтобы узнать, может ли это выявить проблему. Вы не увидите тайм-ауты на графике, потому что это происходит только тогда, когда оно прекращается. Но Lambda записывает время выполнения, поэтому вы должны иметь возможность фильтровать на основе этого.

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

Что вызывает функция? Внешние HTTP API? Сервисы AWS?

Кроме того, вам может понадобиться AWS X-Ray SDK для отладки, это может дать вам более глубокое представление о сбоях Lambda.