Отладка AWS Lambda: распространенные ошибки вызова и способы их устранения

Ошибки вызова AWS Lambda обычно возникают по одной из трех причин: вызывающий объект не может вызвать функцию, Lambda не может запустить среду выполнения или ваш код запускается, а затем завершается с ошибкой. Самый быстрый способ исправить ситуацию — определить, на каком этапе произошел сбой, прежде чем изменять память, тайм-аут, политики IAM или настройки VPC.

Начните с CloudWatch Logs, затем в указанном порядке проверьте разрешения, настройки обработчика, зависимости и сеть.

Установка базового уровня отладки: CloudWatch Logs

Прежде чем изменять функцию, проверьте группу журналов /aws/lambda/YourFunctionName. Обычное выполнение Lambda обычно включает следующие строки журнала платформы:

1. START: Указывает на начало выполнения.
2. END: Указывает на завершение выполнения.
3. REPORT: Предоставляет сводные метрики (Duration, Billed Duration, Memory Used, Max Memory Used и сведения трассировки X-Ray).

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

Устранение ошибок разрешений и доступа

Ошибки разрешений, пожалуй, являются наиболее распространенной причиной сбоя вызова Lambda. Обычно они делятся на две категории: у функции нет разрешения на выполнение или у вызывающего объекта нет разрешения на вызов функции.

Сбои роли выполнения (роли IAM)

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

Распространенные отсутствующие разрешения:

Требуемый доступ к сервису	Необходимые действия политики IAM
Ведение журнала в CloudWatch	logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents
Подключение к VPC	ec2:CreateNetworkInterface, ec2:DeleteNetworkInterface, ec2:DescribeNetworkInterfaces
Чтение S3/DynamoDB	s3:GetObject, dynamodb:GetItem и т.д.

Исправление:

1. Перейдите к конфигурации функции Lambda в консоли AWS.
2. Проверьте вкладку "Permissions" и просмотрите прикрепленную политику роли IAM.
3. Убедитесь, что роль имеет базовую управляемую политику AWS AWSLambdaBasicExecutionRole или что ее пользовательская политика включает необходимые действия CloudWatch.
4. Добавляйте только те разрешения сервиса, которые действительно нужны вашему коду, например s3:GetObject для определенного префикса корзины.

Ошибки политики на основе ресурсов (разрешения на вызов)

Если ваша Lambda вызывается другим сервисом (например, S3, API Gateway, SNS или межаккаунтным вызовом), этому сервису требуется явное разрешение на вызов вашей функции.

Симптом: Сервис (например, S3) пытается запустить Lambda, но в журналах CloudWatch ничего не появляется, и сервис сообщает об ошибке.

Исправление: используйте команду CLI add-permission или эквивалентную настройку консоли, чтобы предоставить права на вызов. Например, разрешение корзине S3 вызывать функцию:

aws lambda add-permission \
    --function-name my-processing-function \
    --statement-id S3InvokePermission \
    --action lambda:InvokeFunction \
    --principal s3.amazonaws.com \
    --source-arn arn:aws:s3:::my-trigger-bucket

Для межаккаунтных вызовов проверьте обе стороны: у вызывающего объекта должно быть разрешение IAM на вызов lambda:InvokeFunction, а у функции Lambda должна быть политика на основе ресурсов, разрешающая этого вызывающего объекта.

Ошибки конфигурации и ограничения ресурсов

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

Ошибки тайм-аута функции

Тайм-аут функции — распространенный сбой, указывающий на то, что выполнение превысило максимально отведенное время. Lambda принудительно завершит выполнение и зарегистрирует ошибку Task timed out.

Диагностика:

1. Проверьте строку REPORT в журналах CloudWatch. Посмотрите на Duration по сравнению с настроенным тайм-аутом.
2. Если время ожидания функции истекает рано (например, через 5 секунд при 30-секундном лимите), узким местом, скорее всего, является инициализация или подключение (например, ожидание поиска DNS).

Исправления:

• Увеличьте тайм-аут: Если задача по своей сути длительная (например, обработка больших данных), увеличьте тайм-аут (до 15 минут).
• Оптимизируйте код/зависимости: Если задача выполняется медленно, профилируйте код, чтобы выявить узкие места. Убедитесь, что для любых внешних вызовов в коде определены разумные тайм-ауты.
• Управляйте холодными стартами: Большие процессы инициализации могут способствовать тайм-аутам. Используйте подготовленный параллелизм Lambda, если холодные старты критичны.

Ошибки исчерпания памяти

Если вашей функции требуется больше ОЗУ, чем выделено, она аварийно завершится и зарегистрирует OutOfMemoryError или подобное сообщение, в зависимости от среды выполнения.

Диагностика: Проверьте метрику Max Memory Used в строке REPORT CloudWatch. Если это значение постоянно близко к настроенному Memory Size или равно ему, у вас может быть утечка памяти или недостаточно ресурсов.

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

AWS Lambda Power Tuning может помочь сравнить настройки памяти для конкретной рабочей нагрузки.

Неправильная конфигурация обработчика (Runtime.HandlerNotFound)

Это происходит, когда Lambda не может найти точку входа, определенную в конфигурации функции.

Симптом: Error: Runtime.HandlerNotFound или подобный сбой при запуске.

Исправление: Проверьте, что поле Handler в настройках функции соответствует структуре: [имя_файла].[имя_функции]. Например, для функции Python, определенной в my_code.py с функцией входа lambda_handler, обработчик должен быть установлен как my_code.lambda_handler.

Для Node.js имена обработчиков следуют модулю и экспортированной функции, например index.handler для экспортированной функции handler в index.js.

Проблемы с сетью и подключением к VPC

Когда функция Lambda настроена на выполнение внутри Virtual Private Cloud (VPC), она получает доступ к частным ресурсам, но по умолчанию теряет доступ к общедоступному Интернету.

Отсутствие доступа в Интернет

Если ваша Lambda находится в VPC и ей необходимо подключаться к внешним сервисам, ей нужен маршрут к Интернету через NAT-шлюз или другой одобренный путь выхода. Размещение функции в публичной подсети не дает ей публичного IP-адреса.

Симптом: Сбои HTTP-соединения, тайм-ауты при доступе к общедоступным конечным точкам.

Исправления:

1. Убедитесь, что функция прикреплена к частным подсетям, предназначенным для рабочих нагрузок Lambda.
2. Убедитесь, что эти частные подсети имеют запись в таблице маршрутизации, направляющую исходящий интернет-трафик (0.0.0.0/0) на NAT-шлюз.
3. Если Lambda требуется доступ только к сервисам AWS в частном порядке, рассмотрите возможность использования конечных точек VPC, таких как шлюзовые конечные точки для S3 и DynamoDB или интерфейсные конечные точки для поддерживаемых сервисов.

Ограничения групп безопасности и сетевых ACL

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

Исправление: разрешите исходящий трафик от группы безопасности Lambda к целевому порту и разрешите входящий трафик в целевой группе безопасности от группы безопасности Lambda. Например, функции Lambda, подключающейся к PostgreSQL, нужен исходящий TCP 5432 от Lambda и входящий TCP 5432 на стороне базы данных.

Если у роли выполнения отсутствуют необходимые разрешения EC2 для сетевых интерфейсов для доступа к VPC, Lambda может выйти из строя при подготовке сетевого взаимодействия VPC, необходимого для запуска функции.

Неправильные конфигурации развертывания и среды выполнения

Эти проблемы связаны со структурой пакета кода или выбранной средой выполнения.

Ошибки зависимостей и пакетов

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

Симптом: Исключения времени выполнения, такие как module not found, cannot import name или No such file or directory (особенно часто встречаются в Python или Node.js).

Исправления:

1. Локальная среда vs. среда Lambda: Убедитесь, что вы создаете зависимости в среде, соответствующей среде выполнения Lambda (например, используйте pip install -t . для Python, чтобы правильно разместить зависимости).
2. Используйте слои Lambda: Упакуйте более крупные стабильные зависимости в слои Lambda, чтобы уменьшить размер основного пакета развертывания и ускорить развертывание.
3. Проверьте путь: Убедитесь, что ваша конфигурация среды выполнения правильно указывает на расположение установленных зависимостей.

Размер и формат пакета развертывания

Lambda имеет ограничения на размер пакета развертывания, и эти ограничения различаются в зависимости от того, загружаете ли вы zip-файл напрямую, загружаете через Amazon S3, используете слои или развертываете образ контейнера. Проверьте текущие квоты Lambda для вашего метода упаковки, прежде чем реструктурировать большую функцию.

Симптом: Развертывание завершается ошибкой размера, или большой пакет способствует более медленным холодным запускам.

Исправления:

• Сокращение: Удалите ненужные файлы, документацию и зависимости разработки.
• Слои: Переместите статические ресурсы или большие зависимости в слои Lambda.
• Образы контейнеров: Для очень больших приложений рассмотрите возможность развертывания функции в виде образа контейнера из Amazon ECR.

Проблемы с событиями и полезной нагрузкой

Некоторые сбои вызова возникают из-за самого события:

• Некорректный JSON: Консольные тесты и вызовы CLI требуют допустимых полезных нагрузок JSON.
• Неожиданная форма события: Событие S3, событие API Gateway и событие EventBridge имеют разные поля.
• Поведение повторных попыток асинхронного вызова: Асинхронные вызовы могут повторяться после сбоев и могут отправлять неудачные события в место назначения или очередь недоставленных сообщений, если это настроено.

Для прямого теста CLI захватите ответ и журналы:

aws lambda invoke \
    --function-name my-function \
    --payload '{"ping": true}' \
    --cli-binary-format raw-in-base64-out \
    response.json

Опция --cli-binary-format raw-in-base64-out обычно требуется в AWS CLI v2 при передаче необработанного JSON непосредственно в командной строке.

Сводка шагов по устранению неполадок

При обнаружении ошибки вызова следуйте этому систематическому подходу:

1. Сначала проверьте CloudWatch: Ищите немедленные ошибки, зарегистрированные сервисом Lambda до строки START.
2. Проверьте роль IAM: Убедитесь, что роль выполнения функции имеет все необходимые разрешения (ведение журнала, VPC и доступ к сервисам).
3. Просмотрите конфигурацию: Проверьте имя обработчика, настройку памяти и лимит тайм-аута.
4. Проанализируйте настройки VPC: При использовании VPC проверьте группы безопасности, сопоставления подсетей и таблицы маршрутизации (особенно для доступа к NAT-шлюзу).
5. Проверьте зависимости: Убедитесь, что все необходимые библиотеки правильно упакованы и доступны среде выполнения.

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