Control de errores con DynamoDB

En esta sección se describen los errores de tiempo de ejecución y se explica cómo controlarlos. También se describen los mensajes y códigos de error específicos de Amazon DynamoDB. Para obtener una lista de los errores comunes que se aplican a todos los servicios de AWS, consulte Administración de accesos

Componentes de un error

Cuando el programa envía una solicitud, DynamoDB intenta procesarla. Si la solicitud se lleva a cabo correctamente, DynamoDB devuelve un código de estado HTTP de operación correcta (200 OK), así como el resultado de la operación solicitada.

Si la solicitud no se realiza correctamente, DynamoDB devuelve un error. Cada error tiene tres componentes:

Los SDK de AWS se encargan de transmitir los errores a la aplicación, para que pueda adoptar las medidas apropiadas. Por ejemplo, en un programa en Java, puede escribir una lógica try-catch para controlar una excepción ResourceNotFoundException.

Si no utiliza un SDK de AWS, tiene que analizar el contenido de la respuesta de bajo nivel de DynamoDB. A continuación se muestra un ejemplo de este tipo de respuesta.

HTTP/1.1 400 Bad Request
x-amzn-RequestId: LDM6CJP8RMQ1FHKSC1RBVJFPNVV4KQNSO5AEMF66Q9ASUAAJG
Content-Type: application/x-amz-json-1.0
Content-Length: 240
Date: Thu, 15 Mar 2012 23:56:23 GMT

{"__type":"com.amazonaws.dynamodb.v20120810#ResourceNotFoundException",
"message":"Requested resource not found: Table: tablename not found"}

Errores transaccionales

Para obtener información sobre los errores transaccionales, consulte Gestión de conflictos de transacciones en DynamoDB.

Mensajes y códigos de error

A continuación se muestra una lista de excepciones devueltas por DynamoDB, agrupados por su código de estado HTTP. Si ¿Reintentar? es Sí, puede volver a enviar la misma solicitud. Si ¿Reintentar? es No, debe corregir el problema en el lado del cliente antes de volver a enviar la solicitud.

Código de estado HTTP 400

El código de estado HTTP 400 indica que existe un problema en la solicitud; por ejemplo, se ha producido un error de autenticación, faltan parámetros obligatorios o se ha superado el rendimiento aprovisionado de una tabla. Debe corregir el problema en la aplicación antes de volver a enviar la solicitud.

Código de estado HTTP 5xx

Un código de estado HTTP 5xx indica un problema cuya resolución corresponde a AWS. Puede ser un error transitorio, en cuyo caso puede reintentar la solicitud hasta que se ejecute satisfactoriamente. En caso contrario, vaya al panel de AWS Service Health Dashboard para comprobar si existe algún problema operativo con el servicio.

Para obtener más información, consulte ¿Cómo resuelvo los errores HTTP 5xx en Amazon DynamoDB?

Control de errores en la aplicación

Para que la aplicación funcione sin problemas, es preciso agregar lógica que capture los errores y responda a ellos. Los enfoques habituales incluyen el uso de bloques try-catch o instrucciones if-then.

Los SDK de AWS llevan a cabo sus propios reintentos y comprobaciones de errores. Si se produce algún error al utilizar uno de los SDK de AWS, su código y descripción pueden ayudarle a solucionar el problema.

También debería aparecer el Request ID en la respuesta. El Request ID puede resultar útil si tiene que acudir a Support de AWS para diagnosticar el problema.

Reintentos de error y retroceso exponencial

Numerosos componentes de una red, como los servidores DNS, los conmutadores o los balanceadores de carga, entre otros, pueden generar errores en cualquier punto de la vida de una solicitud determinada. La técnica habitual para abordar estas respuestas de error en un entorno de red consiste en implementar los reintentos en la aplicación cliente. Esta técnica aumenta la fiabilidad de la aplicación.

Cada SDK de AWS implementa automáticamente una lógica de reintento. Puede modificar los parámetros de reintento de acuerdo con sus necesidades. Por ejemplo, tomemos una aplicación en Java que requiere una estrategia de conmutación por error rápida y no permite reintentos en caso de error. Con el AWS SDK for Java, podría usar la clase ClientConfiguration y proporcionar un valor de maxErrorRetry de 0 para desactivar los reintentos. Para obtener más información, consulte la documentación del SDK de AWS del lenguaje de programación específico.

Si no utiliza un SDK de AWS, debe reintentar las solicitudes originales que reciban errores de servidor (5xx). Sin embargo, los errores de cliente (4xx, salvo las excepciones ThrottlingException o ProvisionedThroughputExceededException) indican que es preciso revisar la solicitud en sí para corregir el problema antes de volver a intentarlo.

Además de los reintentos sencillos, cada SDK de AWS implementa un algoritmo de retroceso exponencial para mejorar el control de flujo. El retardo exponencial se basa en el concepto de utilizar tiempos de espera progresivamente más largos entre reintentos para las respuestas a errores consecutivos. Por ejemplo, las aplicaciones cliente podrían esperar 50 milisegundos antes de llevar a cabo el primer reintento, 100 milisegundos antes del segundo, hasta 200 milisegundos antes del tercero y así sucesivamente. Sin embargo, si la solicitud no se ha llevado a cabo correctamente al cabo de un minuto, el problema podría radicar en que el tamaño de la solicitud supera el rendimiento aprovisionado, y no en la tasa de solicitudes. Establezca el número máximo de reintentos de modo que se detenga al cabo de un minuto. Si la solicitud no se realiza correctamente, investigue las opciones de rendimiento aprovisionado.

La mayoría los algoritmos de retardo exponencial utilizan la fluctuación (el retraso aleatorio) para evitar conflictos sucesivos. Habida cuenta de que no está intentando evitar este tipo de conflictos en estos casos, no es preciso utilizar este número aleatorio. Sin embargo, si utiliza clientes simultáneos, la fluctuación puede ayudar a que las solicitudes tengan éxito con mayor rapidez. Para obtener más información, consulte la entrada del blog sobre Exponential Backoff and Jitter (Retroceso exponencial y fluctuación).

Operaciones por lotes y control de errores

La API de bajo nivel de DynamoDB admite las operaciones por lote de lectura y escritura. BatchGetItem lee elementos en una o varias tablas y BatchWriteItem coloca o elimina elementos en una o varias tablas. Estas operaciones por lote se implementan como encapsuladores en torno a otras operaciones de DynamoDB que no son por lote. Es decir, BatchGetItem invoca GetItem una vez para cada elemento del lote. De igual forma,BatchWriteItem invoca DeleteItem o PutItem, según proceda, para cada elemento del lote.

Una operación por lotes puede tolerar que algunas solicitudes individuales del lote no se lleven a cabo. Por ejemplo, tomemos una solicitud BatchGetItem para leer cinco elementos. Aunque algunas de las solicitudes GetItem subyacentes no se realicen, esto no provocará un error de toda la operación BatchGetItem. Sin embargo, si las cinco operaciones de lectura fallan, entonces el BatchGetItem completo falla.

Las operaciones por lotes devuelven información sobre las solicitudes individuales que no se realizan, para que pueda diagnosticar el problema y reintentar la operación. Para BatchGetItem, las tablas y claves principales en cuestión se devuelven en el valor UnprocessedKeys de la respuesta. Para BatchWriteItem, se devuelve información similar en UnprocessedItems.

La causa más probable de que no se realice una lectura o una escritura es la limitación controlada. Para BatchGetItem, una o varias tablas de la solicitud por lotes no tiene suficiente capacidad de lectura aprovisionada para admitir la operación. Para BatchWriteItem, una o varias de las tablas no tiene suficiente capacidad de escritura aprovisionada.

Si DynamoDB devuelve elementos sin procesar, debe reintentar la operación por lote para estos elementos. Sin embargo, recomendamos encarecidamente utilizar un algoritmo de retardo exponencial. Si reintenta la operación de forma inmediata, podría volver a producirse un error en las solicitudes subyacentes de lectura o escritura a causa de la limitación controlada de las tablas individuales. Si retrasa la operación por lotes mediante el retardo exponencial, será mucho más probable que las solicitudes individuales del lote se lleven a cabo correctamente.