Como determinar si Amazon DynamoDB es apropiada para sus necesidades, y luego planificar su migraciónn

Por Lex Crosett Arquitecto de Soluciones Empresariales,

Werner Vogels, CTO de AWS, suele bromear diciendo que AWS se dedica a la “gestión de dolores para las empresas”, lo cual llega a la raíz de muchos de los desafíos de TI a los que se enfrentan los clientes de AWS. Simplemente preguntar “¿Dónde podemos ofrecer a los clientes el mayor beneficio?” a menudo resulta en una discusión de las bases de datos y los costos de licencia relacionados, la administración del rendimiento y la escalabilidad y el costo de la mano de obra especializada de los administradores. Un servicio de base de datos NoSQL totalmente administrado, como Amazon DynamoDB, puede abordar estos desafíos y ofrecer muchos beneficios.

En esta entrada de blog, explico cómo evaluar DynamoDB como un posible servicio de base de datos para su aplicación y, a continuación, explico cómo planificar la migración a DynamoDB, incluyendo prácticas recomendadas.

Libertad de Bases Datos (Database Freedom)

En AWS, creemos en la libertad de bases de datos (database freedom). Le recomendamos que evalúe y elija la base de datos adecuada para el tipo de datos, el modelo de acceso y la escalabilidad que necesita. También creemos que sus desarrolladores y administradores de sistemas deben tener la libertad de crear y operar sus aplicaciones y dejar la gestión de operaciones en manos de AWS. Esto es particularmente importante para las operaciones de bases de datos a gran escala.

Las aplicaciones nativas de la nube suelen ser arquitectónicamente diferentes de las aplicaciones tradicionales (legacy), y se implementan con regularidad utilizando múltiples capas de procesamiento (tiers) con acoplamiento flexible y escalamiento automático. Es importante tomarse el tiempo necesario para considerar sus opciones y probarlas según sea necesario. Crea en la persistencia políglota: elija la tecnología de base de datos adecuada para sus aplicaciones tradicionales y nativas de la nube. Resista la tentación de utilizar el mismo enfoque de base de datos para cada desafío de desarrollo de aplicaciones.

AWS hace que la selección y entonación de la base de datos correcta sean más sencillos y menos costosos que con los motores de bases de datos comerciales, ya que ofrece facilidad de experimentación y precios. Las opciones de bases de datos disponibles en el portafolio de AWS están aumentando rápidamente en número y capacidad, impulsadas en parte por la adopción de microservicios, el Internet de las cosas (IoT – Internet of Things) y los requisitos de muchos tipos de soluciones analíticas especializadas. Puede aprovisionar y administrar la mayoría de los motores de bases de datos de código abierto o de terceros a través de AWS Marketplace y otros repositorios, y operarlos en las instancias de Amazon EC2 del tamaño adecuado o mediante Amazon Relational Database Service (Amazon RDS).

O puede dejar que AWS se encargue del trabajo de operaciones y evitar los costos del administrador de la base de datos mediante un servicio totalmente administrado, como DynamoDB. Werner Vogels observó que aproximadamente el 70 por ciento de las necesidades de bases de datos de Amazon.com no requerían un modelo relacional y podían atenderse mejor con una bases de datos NoSQL clave-valor. Por eso hemos concebido y creado DynamoDB. DynamoDB se utiliza a menudo para operaciones de baja escala debido a su simplicidad, pero también destaca en operaciones de extremadamente alta escala, como las que exige Amazon.com

Es DynamoDB el servicio de base de datos correcto par su caso de uso?

Usted debe considerar utilizar DynamoDB si:

1. Ha tenido problemas de escalabilidad con otros sistemas de gestión de bases de datos tradicionales.
2. Está en pleno desarrollo de una aplicación o servicio. No siempre tiene sentido migrar aplicaciones tradicionales que no están en desarrollo, a menos que esté dispuesto a invertir tiempo y esfuerzo para volver a implementar la capa de acceso a datos, las sentencias SQL incrustadas en el código (inline SQL code) o los procedimientos y funciones almacenados de esa aplicación.
3. Está trabajando con una carga de trabajo transaccional (OLTP). Lecturas y escrituras de alto desempeño son fáciles de manejar con DynamoDB, y puede contar con un rendimiento constante, independientemente del nivel de carga al que esté sometida su aplicación.
4. Está desarrollando una aplicación de misión crítica que debe estar disponible permanentemente sin ningún tipo de intervención manual.
5. Tiene personal insuficiente para la administración de la capacidad adicional de la base de datos requerida y necesita reducir la carga de trabajo de su equipo de operaciones.
6. Requiere de un alto nivel de durabilidad de datos, independientemente de su estrategia de respaldo y recuperación de bases de datos.
7. No tiene datos suficientes para pronosticar picos y valles en el rendimiento requerido de la base de datos.

Pautas de adecuación de DynamoDB

Antes de decidir utilizar DynamoDB como su motor de bases de datos, usted debería contestar “Sí” a la mayoría de las siguientes preguntas:

1. ¿Puede organizar sus datos en jerarquías o una estructura de datos agregada, consolidada en una o dos tablas?
2. ¿Es importante la protección de sus datos?
3. ¿Las copias de seguridad tradicionales son poco prácticas o tienen un costo prohibitivo debido a la velocidad de actualización o volumen de datos?
4. ¿La carga de trabajo de la base de datos varía significativamente según la hora del día o está impulsada por una alta tasa de crecimiento o por eventos de alto tráfico?
5. ¿Su aplicación o servicio requiere sistemáticamente un tiempo de respuesta en milisegundos de un solo dígito, independientemente de la carga de trabajo y sin esfuerzo de entonación?
6. ¿Necesita proporcionar servicios en una configuración escalable, replicada o global?
7. ¿Su aplicación necesita almacenar datos en el rango de tamaño de múltiples terabytes?
8. ¿Está dispuesto a invertir en una curva de aprendizaje NoSQL corta pero posiblemente pronunciada para sus desarrolladores?

Algunas cargas de trabajo inadecuadas para DynamoDB incluyen:

• Servicios que requieren acceso a consultas ad-hoc. Si bien es posible utilizar marcos relacionales externos para implementar relaciones entre entidades en las tablas de DynamoDB, estos suelen ser engorrosos.
• Implementaciones de procesamiento analítico en línea (OLAP) / almacén de datos. Estos tipos de aplicaciones generalmente requieren la distribución y la unión de tablas de hechos (fact tables) y dimensiones (dimension tables) que proporcionan de forma inherente una vista normalizada (relacional) de los datos.
• Almacenamiento de objetos binarios grandes (BLOB). DynamoDB puede almacenar elementos binarios de hasta 400 KB, pero DynamoDB no suele ser adecuado para almacenar documentos o imágenes. Un patrón arquitectónico mejor para esta implementación es almacenar punteros a objetos de Amazon S3 en una tabla de DynamoDB

Si después de revisar estas consideraciones decide que DynamoDB es adecuado para sus necesidades, está listo para recorrer la siguiente sección de planificación de la migración.

Planificando la migración a DynamoDB

Al migrar una carga de trabajo de base de datos relacional a DynamoDB, debe considerar la posibilidad de implementar una prueba de concepto inicial. También puede ejecutar sistemas en paralelo durante una fase de prueba para identificar todas las variables no conocidas durante la fase de planificación. Lo mejor es un enfoque ágil e iterativo. Para obtener una descripción más detallada de los pasos de planificación de la migración de esta sección, consulte “Prácticas recomendadas para migrar de un RDBMS a Amazon DynamoDB”

Para simplificar, vamos a suponer que el escenario de migración es de un RDBMS local a DynamoDB. Sin embargo, otros escenarios de migración también pueden seguir estos pasos.

1. Entrenamiento de Desarrolladores

Al migrar un sistema basado en datos de un centro de cómputo a la nube, el primer paso es volver a capacitar a los desarrolladores para que puedan cambiar de usar SQL incrustado en su código a realizar llamadas de API a un sistema NoSQL como DynamoDB.

Reserve tiempo de formación para sus desarrolladores utilizando el contenido de los recursos para desarrolladores de Amazon DynamoDB. Los recursos para desarrolladores incluyen laboratorios auto guiados, ejemplos de clientes y capacitación de alta calidad. Un desarrollador típico tarda unos días en ponerse al día con DynamoDB y necesita unos días más para experimentar y configurar sus herramientas de desarrollo para una codificación eficiente y pruebas unitarias.

Tenga en cuenta que DynamoDB local es una versión descargable de DynamoDB que su equipo de desarrollo puede utilizar para escribir y probar aplicaciones sin acceder al servicio web de DynamoDB. Una vez que el código esté completo, solo debe realizar unos pocos cambios para que se ejecute en el servicio web. El uso de este enfoque también le permite evitar el costo de usar DynamoDB para el desarrollo y las pruebas.

El equipo de desarrollo también debe explorar el uso de índices secundarios locales y globales para respaldar la optimización de consultas en los pares nombre-valor de las tablas migradas. Los índices secundarios globales funcionan de forma transparente como las tablas de DynamoDB gestionadas por AWS, y su uso implica un costo adicional. Utilice índices secundarios globales solo cuando sea necesario.

2. Conversión de Datos

Teniendo en cuenta consideraciones de tamaño y almacenamiento, evalúe la posibilidad de convertir las tablas existentes en una sola tabla de la base de datos de origen antes de la migración, para ahorrar tiempo y esfuerzo más adelante en el proceso de migración. También puede crear una tarea programada de base de datos que genere datos de forma periódica para la migración a AWS. Revise los consejos para la desnormalización en Primeros pasos para modelar datos relacionales en DynamoDB, que incluyen sugerencias de modelado relacional para ayudarlo en este proceso.

Para facilitar el proceso de conversión, hay disponibles herramientas de terceros de varios socios de AWS en AWS Marketplace para canalizar sus datos desde un RDBMS y otras fuentes a DynamoDB. Las herramientas de AWS Marketplace tienen la ventaja de ser consumibles por horas y envían los eventos de facturación a su factura de AWS. Cuando haya terminado de utilizar la solución AWS Marketplace, puede terminar su uso y dejar de pagar por el recurso.

3. Migración de los Datos

Cuando la tabla desnormalizada o los datos de origen exportados estén listos, piense si los datos se migrarán todos de una vez en un lote o en un lote con un paso de sincronización de transacciones recientes antes de cambiar del origen de migración al destino. AWS Database Migration Service (AWS DMS) trata a DynamoDB como un destino de migración, siendo la fuente una base de datos relacional, Amazon S3, o MongoDB. Muchos de los escenarios de migración que admite AWS DMS también pueden usar AWS Snowball para mover terabytes de datos como un paso intermedio. Con AWS DMS, solo paga el costo de la instancia de Amazon EC2 que utiliza durante el proceso de replicación y movimiento de datos. La mayoría de los proyectos de migración de DynamoDB mueven datos mediante AWS DMS y, a continuación, hacen el cambio de plataforma después de un período de replicación y pruebas.

Una regla general es que si la migración de datos tarda más de una semana dado el ancho de banda disponible para el movimiento de datos, debería considerar la posibilidad de utilizar Snowball para la migración inicial. Snowball es una solución de transporte de datos a escala de petabytes que utiliza dispositivos diseñados para ser seguros para transferir grandes cantidades de datos dentro y fuera de la nube de AWS. El uso de Snowball soluciona muchos desafíos comunes con las transferencias de datos a gran escala, incluidos los altos costos de red, los largos tiempos de transferencia, y problemas de seguridad. Con Snowball, mueve los datos al dispositivo local que luego se transporta de forma segura a un centro de cómputo de AWS. A continuación, su contenido se carga en Amazon S3 que puede importar a DynamoDB utilizando AWS Data Pipeline o AWS DMS de la manera descrita anteriormente.

4. Modelo de Consistencia de Datos

Una consideración para la carga de trabajo es el modelo de consistencia de lectura (read consistency model) necesario después de cada actualización de la tabla. DynamoDB escribe actualizaciones de tablas en tres zonas de disponibilidad en cada región de AWS para garantizar la durabilidad y, por lo general, todos los datos se escriben en todas las ubicaciones en un segundo o menos.

DynamoDB soporta tres modelos de consistencia de lectura (read consistency models): consistencia eventual (eventual consistency), consistencia fuerte (strong consistency) y transaeiifccredjgfuteldjidehuuvurlvffbgfbbribgnulb

ccional. A menos que especifique un modelo de consistencia de lectura diferente para la aplicación, DynamoDB utiliza lecturas con consistencia eventual. Si su aplicación y los usuarios pueden aceptar lecturas con consistencia eventual, en las que una consulta puede potencialmente producir resultados desactualizados, puede aprovisionar menos capacidad y sus costos serán los más bajos de las tres opciones de consistencia.

Si selecciona lecturas con consistencia fuerte (strong consistency), DynamoDB retorna una respuesta con los datos más actualizados de todas las operaciones de escritura exitosas, y la capacidad y los costos aprovisionados son mayores.

Para las aplicaciones transaccionales en las que la última escritura debe estar siempre disponible para todas las solicitudes del cliente, las API transaccionales son la mejor opción. Para soportar transacciones y simplificar la experiencia del desarrollador a la hora de realizar múltiples cambios en múltiples tablas siguiendo el patrón de diseño relacional todo-o-nada (all-or-nothing), DynamoDB realiza dos lecturas o escrituras para cada elemento que participa en la transacción: una para preparar la transacción y otra para confirmar (commit) la transacción. Si bien el costo de cada lectura y escritura es el mismo, esto aumenta el número total de lecturas y escrituras para cualquier cambio transaccional dado y, por lo tanto, es la opción de actualización de tablas y el modelo de consistencia de lectura más costoso.

5. Seguridad y Cifrado de Datos

Si utiliza el enfoque de migración recomendado en esta publicación, sus datos se cifran en tránsito durante la migración. Al crear una tabla nueva en DynamoDB, el cifrado en reposo está habilitado de forma predeterminada. El cifrado de DynamoDB en reposo utiliza el Estándar de cifrado avanzado de 256 bits (AES-256) que ayuda a proteger sus datos del acceso no autorizado. El mecanismo de cifrado en reposo se integra con AWS Key Management Service (AWS KMS) para administrar la clave de cifrado que se utiliza para cifrar las tablas. Esta funcionalidad elimina la carga operativa y la complejidad que implica la protección de datos confidenciales. No hay reducción del rendimiento ni carga de costos asociada con el cifrado.

Cuando crea una tabla nueva, puede elegir una de las dos opciones de cifrado disponibles para crear y usar una clave maestra de cliente (CMK) en AWS KMS con fines de cifrado de tablas. La primera opción es una CMK propiedad de AWS, el tipo de cifrado predeterminado. Con esta opción predeterminada, DynamoDB utiliza una sola CMK generada por el servicio para cifrar las tablas. Si esta clave no existe, DynamoDB la crea y administra para usted sin costo adicional y no se puede deshabilitar.

La segunda opción de cifrado se denomina CMK administrada por AWS. Si elige esta opción, la CMK se crea y almacena en su cuenta y la administra AWS KMS (se aplican cargos de AWS KMS). Con esta opción, puede ver la CMK y la política asociada a su clave en su cuenta de AWS, pero no puede cambiar la política asociada a su clave que se creó para que DynamoDB la utilice. Esta segunda opción tiene un valor importante para la supervisión desde el punto de vista de seguridad y auditoría, ya que puede revisar las operaciones de cifrado y descifrado de las tablas de DynamoDB que crea al ver las llamadas a la API realizadas a AWS KMS en los registros de AWS CloudTrail.

De forma predeterminada, las comunicaciones hacia y desde DynamoDB utilizan el protocolo HTTPS que protege el tráfico de red mediante el cifrado SSL/TLS, incluidas las comunicaciones de la interfaz de línea de comandos de AWS y el SDK de AWS.

6. Seguridad de Red – Punto de Enlace de VPC para DynamoDB

La mayoría de los clientes de AWS accederán a DynamoDB desde su VPC mediante un punto de enlace de VPC seguro (secure VPC endpoint) para DynamoDB. Esto alivia los problemas de seguridad asociados a tener que conectarse a DynamoDB desde una subred privada a través de una puerta de enlace de traducción de direcciones de red (network address translation gateway), o desde una puerta de enlace privada virtual (virtual private gateway), o una puerta de enlace de Internet (Internet gateway). Para lograr una seguridad óptima en tránsito entre las diferentes capas de la aplicación y DynamoDB, debe planificar habilitar los puntos de enlace de la VPC para la instancia de DynamoDB.

7. Desempeño – Rendimiento y Escalado Automático

Se requiere muy poco esfuerzo de administración para gestionar el rendimiento de DynamoDB. El servicio funciona según lo esperado con poca variación en el tiempo de respuesta en función de la configuración de rendimiento establecida. Puede utilizar varias de las capacidades más nuevas del servicio para automatizar la planificación del rendimiento y aliviar los posibles errores al establecer la configuración inicial de rendimiento de sus tablas en DynamoDB.

En primer lugar, utilice la guía Capacidad de rendimiento para lecturas y escrituras. Una capacidad mayor a lo que necesita tiene el potencial de aumentar el costo por encima de lo que usted desea, y una capacidad inferior a la necesaria puede reducir el desempeño de las aplicaciones.

En segundo lugar, debe considerar la posibilidad de habilitar el escalado automático para la tabla para no tener que preocuparse por configurar incorrectamente las unidades de capacidad de lectura y escritura. Con el escalado automático, AWS sube y baja la capacidad en función del rendimiento que necesita a lo largo del tiempo. Puede establecer límites para el escalado en función de consideraciones de costos y también utilizar Amazon CloudWatch y la consola de DynamoDB para monitorear las operaciones de escalado automático y asegurarse de que no haya establecido el límite superior del escalado automático demasiado bajo. Con este enfoque, no debería tener que gestionar el escalado automático a lo largo del tiempo.

También puede decidir cambiar al modo de capacidad bajo demanda de DynamoDB y permitir que AWS gestione todas las actividades de escalado por usted.

8. Requerimientos de Desempeño Extremos – Microsegundos versus Milisegundos?

Si su carga de trabajo requiere un rendimiento extremadamente alto con un tiempo de respuesta medido en microsegundos en lugar de milisegundos de un solo dígito, puede probar Amazon DynamoDB Accelerator (DAX). También puede utilizar la aceleración en memoria de DAX para reducir la capacidad de lectura aprovisionada en DynamoDB necesaria para una aplicación con altos requerimientos de lectura, con lo cual se reduce el costo de las operaciones de DynamoDB en la mayoría de los casos.

9. Consideraciones de Confiabilidad

Después de migrar los datos a DynamoDB, debe proteger el contenido de la tablas con copias de seguridad para poder recuperarse de eventos de pérdida de datos. Dado que DynamoDB es un servicio regional, también debe considerar la posibilidad de recuperarse de cualquier falla regional del servicio de DynamoDB.

Con respecto a la protección de datos tradicional, DynamoDB soporta la recuperación a un punto en el tiempo (PITR). A menos que pueda proteger el contenido de las tablas de otro modo o reconstruirlo desde una ubicación fija como Amazon S3, debe habilitar PITR para proteger los datos de la tabla de daños provocados por aplicaciones o errores de usuario. Si debe recuperar una tabla, se recupera a través de la creación de una tabla nueva y debe restablecer la configuración de capacidad, límites de escalado automático, y otros elementos de configuración relacionados.

DynamoDB también soporta la copia de seguridad y la restauración a petición para que pueda proteger sus datos por separado según un cronograma o cuando sea necesario. No hay ningún impacto en el rendimiento de las tablas y el proceso de respaldo se completa en segundos. Las copias de seguridad se catalogan y almacenan para su recuperación. Estas copias de seguridad también se pueden usar para protegerlo contra la eliminación involuntaria de tablas, ya que se conservan independientemente del estado de la tabla.

10. Confiabilidad Multi-Regional

Para implementar su aplicación en varias regiones de AWS o en todo el mundo, debe considerar el uso de tablas globales. Puede usar tablas globales para implementar sus tablas de DynamoDB de forma global en las regiones soportadas mediante la replicación multimaestro. Es importante seguir las prácticas recomendadas para tablas globales y habilitar el escalado automático para una administración adecuada de la capacidad. Tenga en cuenta que las lecturas fuertemente consistentes (strongly consistent reads) solo se pueden usar en una región de la colección de tablas globales, donde las lecturas de consistencia eventual (eventually consistent reads) son el único tipo de lecturas disponibles.

11. Optimizando Capacidad y Costos

Después de migrar los datos, es importante que optimice el uso de DynamoDB. Consulte los siguientes puntos para obtener consejos sobre cómo optimizar su capacidad y costos en DynamoDB.

AWS anunció recientemente una funcionalidad denominada modo de capacidad bajo demanda. Utilizar la funcionalidad bajo demanda permite que AWS ajuste su capacidad de lectura y escritura para que coincida con los picos y valles requeridos en todo momento, sin tener que crear y mantener un modelo de capacidad inicial y escalado automático. Sin embargo, si su aplicación tiene una capacidad relativamente estable, es posible que la modalidad bajo demanda no reduzca los costos de operación.

Es importante que entienda lo siguiente con relación los precios de DynamoDB:

• Cuando está en funcionamiento, paga una tarifa fija por hora en función de la capacidad aprovisionada o una tarifa bajo demanda cuando utiliza ese modo de capacidad.
• El precio de las unidades de capacidad de lectura y escritura se establece por región.
• Puede utilizar el escalado automático para asegurarse de que siempre utiliza la capacidad mínima.
• Si puede utilizar lecturas consistentes eventualmente (eventually consistent reads), hágalo porque el mismo nivel de capacidad admite dos veces más lecturas que las hechas con consistencia fuerte (strongly consistent reads).
• Tenga en cuenta los costos de transferencia de datos regionales si ha implementado tablas de DynamoDB en varias regiones.
• Asegúrese de administrar cuidadosamente los cargos por transferencia de datos interregionales.
• Utilice Amazon CloudWatch, AWS Cost Explorer y AWS Budgets para gestionar la capacidad y costos incurridos.
• Como cliente de DynamoDB, puede comprar capacidad reservada por adelantado. Si puede predecir su necesidad de rendimiento de lectura y escritura de DynamoDB, la capacidad reservada ofrece ahorros significativos con respecto al precio normal de la capacidad de rendimiento aprovisionada de DynamoDB. (Tenga en cuenta que la capacidad reservada no se aplica al modo de capacidad bajo demanda porque solo paga por las solicitudes que realiza y no por el aprovisionamiento de capacidad)

Como ocurre con la mayoría de las actividades de optimización de AWS, es importante supervisar e iterar sobre el uso de DynamoDB para asegurarse de pagar solo por los recursos de rendimiento y almacenamiento que realmente necesita.

Resumen

En este artículo, expliqué cómo evaluar DynamoDB como un posible servicio de base de datos para su aplicación y cómo planificar la migración a DynamoDB. Si tiene preguntas o comentarios sobre esta publicación, inclúyalos en la sección de comentarios a continuación.

Este artigo foi traduzido do Blog da AWS em Inglés.

Acerca del autor

Lex Crosett es un arquitecto de soluciones empresariales de AWS radicado en Boston.

Traductor

Camilo Leon es un Arquitecto de Soluciones Principal especializado en bases de datos en Amazon Web Services radicado en San Francisco. Camilo Trabaja con clientes de AWS para proporcionar orientación y asistencia técnica en servicios de bases de datos relacionales, ayudándoles a mejorar el valor de sus soluciones cuando utilizan AWS.