Saltar al contenido

¿Cómo soluciono los problemas de integración de API Gateway para las funciones de Lambda?

11 minutos de lectura
0

Quiero solucionar los problemas de integración de Amazon API Gateway para las funciones de AWS Lambda.

Resolución

Activación del registro de API

Sigue estos pasos:

  1. Abre la consola de API Gateway.
  2. En el panel de navegación, selecciona API y, a continuación, elige tu API.
  3. En el panel de navegación, elige Etapas y, a continuación, selecciona tu proxy.
  4. En Registros y seguimiento, selecciona Editar.
  5. En Registros de CloudWatch, selecciona un nivel en el menú desplegable.<br id=hardline_break/> Nota: Para ver los registros completos de solicitudes y respuestas, selecciona la opción Seguimiento de datos con el nivel de registro establecido en Registros de errores e información. Se recomienda no activar el seguimiento de datos para las API de producción, ya que puede registrar datos confidenciales.
  6. Elige Métricas detalladas.
  7. En Registro de acceso personalizado, completa los pasos siguientes:<br id=hardline_break/> Selecciona Habilitar el registro de acceso.<br id=hardline_break/> En Acceder al ARN del registro del destino, introduce el nombre de recurso de Amazon (ARN) de un grupo de registro de Amazon Data Firehose o CloudWatch.<br id=hardline_break/> Nota: Solo las API de REST admiten el ARN de Firehose.
  8. Introduce un formato de registro.
  9. Selecciona Guardar.

Determinar los tipos de integración, verificar los errores y realizar los pasos siguientes para resolverlos

Sigue estos pasos:

  1. Determina si una integración de proxy de Lambda o una integración personalizada de Lambda está configurada en API Gateway. Para verificar el tipo de integración, comprueba el valor de la integración del proxy de Lambda en Solicitud de integración.

  2. Comprueba que los errores de API Gateway se correspondan con los errores de Lambda. Ejecuta la siguiente consulta de Información de registros de CloudWatch para encontrar un código de estado de error durante un periodo de tiempo específico:

    parse @message '(*) *' as reqId, message
        | filter message like /Method completed with status: \d\d\d/
        | parse message 'Method completed with status: *' as status
        | filter status != 200
        | sort @timestamp asc
        | limit 50
  3. Ejecuta la siguiente consulta de Información de registros de CloudWatch para buscar registros de errores de Lambda durante el mismo periodo de tiempo:

    fields @timestamp, @message
        | filter @message like /(?i)(Exception|error|fail)/
        | sort @timestamp desc
        | limit 20
  4. Según el tipo de error que identifiques en tus registros, elige una de las siguientes opciones:<br id=hardline_break/> Si recibes el siguiente error, completa los pasos de la sección Resolver problemas de simultaneidad.

    (#####) Lambda invocation failed with status: 429. Lambda request id: ##########
    () Execution failed due to configuration error: Rate Exceeded.
    (#####) Method completed with status: 500

    Si recibes alguno de los siguientes errores, completa los pasos de la sección Resolver problemas de tiempo de espera.<br id=hardline_break/> Para una integración personalizada de Lambda:

    < Integration timeout:
    (#####) Method response body after transformations: {"errorMessage":"2019-08-14T02:45:14.133Z ########-####-####-####-############ Task timed out after ##.01 seconds"}
    > Integration timeout:
    (#####) Execution failed due to a timeout error

    Para una integración de proxy de Lambda:

    < Integration timeout:
    (#####) Endpoint response body before transformations: {"errorMessage":"2019-08-14T02:50:25.865Z ########-####-####-####-############ Task timed out after ##.01 seconds"}
    > Integration timeout:
    (#####) Execution failed due to a timeout error

    Si recibes el siguiente error, completa los pasos de la sección Resolver errores de la función.

    (#####) Execution failed due to configuration error: Malformed Lambda proxy response
    (#####) Method response body after transformations: {"errorMessage": "Syntax error in module 'lambda_function'"}

Resolver problemas de simultaneidad

Recibes errores de limitación 429 o errores 500 cuando las solicitudes adicionales llegan de API Gateway más rápido de lo que tu función de Lambda puede escalar.

Para resolver estos errores, analiza las siguientes métricas de CloudWatch: Count (API Gateway), Throttles (Lambda) y ConcurrentExecutions (Lambda). Ten en cuenta lo siguiente:

  • Count (API Gateway) es el número total de solicitudes de API durante un periodo de tiempo específico.
  • Throttles (Lambda) es el número de solicitudes de invocación limitadas. Cuando todas las instancias de la función procesan solicitudes y no hay simultaneidad disponible para escalar verticalmente, Lambda rechaza las solicitudes adicionales con el error TooManyRequestsException. Las solicitudes restringidas y otros errores de invocación no se cuentan como invocaciones o errores.
  • ConcurrentExecutions (Lambda) es el número de instancias de funciones que procesan eventos. Si este número alcanza tu cuota de ejecuciones simultáneas para la región de AWS, se limitan las solicitudes de invocación adicionales. Lambda también limita las solicitudes de invocación cuando el número de instancias de la función alcanza el límite de simultaneidad reservado que configuraste en la función.

Nota: Para obtener más información, consulta Métricas de API Gateway y Uso de métricas de CloudWatch con Lambda.

Si estableces una simultaneidad de reserva para la función de Lambda, aumenta el valor de simultaneidad de reserva. O bien, elimina el valor de simultaneidad inversa de la función de Lambda. A continuación, la función se basa en el conjunto de ejecuciones simultáneas no reservadas.

Si no configuras la simultaneidad de reserva en la función de Lambda, consulta la métrica ConcurrentExecutions para averiguar el uso. Para obtener más información, consulta Cuotas de Lambda.

Resolver problemas de tiempo de espera

El límite de tiempo de espera de integración predeterminado es de 29 segundos para todas las integraciones de API Gateway. Puedes enviar una solicitud de cuota para aumentar el límite de tiempo de espera de integración predeterminado a más de 29 segundos para las API regionales y las API privadas. Sin embargo, un aumento del tiempo de espera de la integración puede requerir una reducción de la cuota de aceleración a nivel regional para tu cuenta de AWS.

Nota: Si aumentas el límite de tiempo de espera de la integración, asegúrate de cambiar el valor de tiempo de espera predeterminado de 29 segundos por el nuevo valor. Por ejemplo, cambia el valor de tiempo de espera predeterminado de 29 segundos en las integraciones en las que quieras aplicar el aumento. A continuación, vuelve a implementar la API para activar el nuevo límite de tiempo de espera de la integración.

Al crear una API de API Gateway con integración de Lambda, es posible que te encuentres con una de las siguientes situaciones:

  • El valor del tiempo de espera es inferior al valor del tiempo de espera de la integración.
  • El valor del tiempo de espera es mayor que el valor del tiempo de espera de la integración.

Si el tiempo de espera de la función de Lambda es inferior a 29 segundos, comprueba los registros de Lambda para investigar este problema. Si la función de Lambda debe ejecutarse después de 29 segundos, invócala de forma asincrónica.

Para la integración personalizada de invocación asincrónica de Lambda, sigue estos pasos:

  1. Abre la consola de API Gateway.
  2. Desde el panel de navegación, selecciona API y, a continuación, elige tu API.
  3. Elige Recursos y, a continuación, elige tu método.
  4. Elige Solicitud de integración.
  5. Elige Solicitud de método.
  6. Amplía los encabezados de las solicitudes HTTP.
  7. Selecciona Agregar encabezado.
  8. En Nombre, introduce un nombre para tu encabezado. Por ejemplo: X-Amz-Invocation-Type<br id=hardline_break/> Importante: Debes asignar tu encabezado desde «Evento». Debes utilizar comillas simples.

Para la integración de proxy de Lambda, utiliza dos funciones de Lambda: la función A y la función B. API Gateway invoca primero la función A de forma sincronizada. A continuación, la función A invoca de forma asincrónica la función B. La función A puede devolver una respuesta correcta a API Gateway cuando la función B se invoca de forma asincrónica.

Si usas una integración de proxy de Lambda, puedes cambiar la integración por una integración personalizada. Sin embargo, para transformar la solicitud o la respuesta a tu formato específico, debes configurar las plantillas de asignación. Para obtener más información, consulta Configurar la invocación asíncrona de la función de Lambda del backend.

Nota: Como una función de Lambda asíncrona se ejecuta en segundo plano, el cliente no puede recibir datos de una función de Lambda directamente. Debes tener una base de datos intermedia para almacenar cualquier dato persistente.

Resolver errores de funciones

Si recibes un error de función al invocar la API, comprueba si hay algún error de sintaxis en la función de Lambda. Este error también aparece si la función de Lambda no devuelve un objeto JSON válido que API Gateway espera para las integraciones de proxy.

Desde los registros de ejecución de API Gateway, puedes revisar el valor de AWS Integration Endpoint RequestID en los registros:

(#####) AWS Integration Endpoint RequestId : YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY

A continuación, ejecuta la siguiente consulta de Información de registros de CloudWatch para buscar registros de errores de Lambda durante el mismo periodo de tiempo:

fields @timestamp, @message, @requestId, @logStream
| filter @requestId = 'YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY'
| sort @timestamp asc

Para resolver este error, sigue los pasos de la sección Activar el registro para tu API y tu etapa.

Anular las respuestas incorrectas del código de estado de la API de REST

Si API Gateway devuelve un código de estado incorrecto, crea una plantilla de asignación para anular el código de estado incorrecto por el código de estado correcto. Puedes anular las respuestas del código de estado en integraciones que no sean de proxy con las API de REST.

Nota: Esta configuración de plantilla de asignación solo se aplica a las API de REST. Para las API HTTP, consulta How do I map the response status codes for API Gateway integrations in HTTP APIs? (¿Cómo puedo asignar los códigos de estado de respuesta para las integraciones de API Gateway en API HTTP?).

Por ejemplo, si API Gateway devuelve un código de estado 200 en lugar de 4## o 5## de una función de Lambda, completa los pasos siguientes:

  1. Abre la consola de API Gateway y, en el panel de navegación, selecciona API.

  2. Elige tu API de REST y, a continuación, elige la pestaña Respuesta de integración.

  3. En la configuración de respuestas de integración, selecciona Editar.

  4. Expande Plantillas de asignación y, a continuación, selecciona Agregar plantilla de asignación.

  5. En Tipo de contenido, introduce application/json.

  6. En el editor de plantillas de asignación, introduce el siguiente código:

    #set($inputRoot = $input.path('$'))
    $input.json("$")
    #if($inputRoot.toString().contains("error"))
    #set($context.responseOverride.status = 400)
    #end
  7. Selecciona Guardar.

El parámetro $context.responseOverride.status anula el código de estado a 400 en lugar de la asignación predeterminada en el panel de respuestas de integración.

Para obtener más información, consulta Anulación de los parámetros de solicitud y respuesta y de los códigos de estado de la API para las API de REST en API Gateway.

Configuración de las integraciones de la API de REST de modo que devuelvan los encabezados de CORS necesarios

Para devolver los encabezados de CORS necesarios en tu respuesta, configura la función de Lambda o servidor de proxy HTTP de tu backend. Debes incluir los dominios permitidos en el valor del encabezado Access-Control-Allow-Origin en forma de lista.

En el caso de las integraciones de proxy, no puedes configurar una respuesta de integración en API Gateway para modificar los parámetros de respuesta que devuelve el backend de la API. En una integración de proxy, API Gateway reenvía la respuesta del backend directamente al cliente. Debes configurar la función de Lambda o la integración HTTP para que devuelva los encabezados CORS necesarios.

Para integraciones que no sean de proxy, deberás configurar manualmente una respuesta de integración en API Gateway para devolver los encabezados de CORS necesarios. Utiliza la consola de API Gateway para configurar CORS. La consola agrega automáticamente los encabezados de CORS necesarios al recurso configurado.

Para obtener más información, consulta ¿Cómo puedo solucionar los errores de CORS de mi API de API Gateway?

Integraciones de proxy de Lambda de carga útil binaria

Una carga útil binaria es cualquier cosa que no sea una carga útil de texto. Por ejemplo, una carga útil binaria puede ser un archivo .jpeg, un archivo .gzip, etc. Esto incluye datos binarios genéricos, como los de una aplicación .pdf, una imagen .jpeg o una aplicación .zip.

Para gestionar las cargas útiles binarias para las integraciones de proxy de Lambda, debes codificar en base64 la respuesta de tu función y configurar los binaryMediaTypes de tu API. Para gestionar las cargas útiles binarias de las integraciones que no son de proxy, debes agregar los tipos de medios a la lista binaryMediaTypes del recurso RestApi.

Para obtener más información, consulta Tipos de medios binarios para las API de REST en API Gateway.

Información relacionada

Gestionar los errores de Lambda estándares en API Gateway

Gestionar los errores de Lambda personalizados en API Gateway