Cómo la división de agricultura de Hexagon ahorró más del 60% y mejoró significativamente el rendimiento en sus bases de datos en Amazon RDS

Por Tarcisio Mello, Gerente de I+D en Hexagon,
Flávio Ximenes, Analista de Sistemas en Hexagon,
Lígia Harumi Yamamoto, Arquitecta de Soluciones en AWS.

Hexagon es líder mundial en sensores, software y soluciones independientes. La división de Agricultura de Hexagon desarrolla y proporciona soluciones de tecnología de la información que libera todo el potencial de la producción agrícola, generando importantes ganancias en eficiencia, productividad y sostenibilidad. Sus soluciones convierten los datos en información procesable que permite una planificación inteligente, una ejecución eficiente en el campo, un control preciso de la máquina y flujos de trabajo automatizados para optimizar las operaciones.

Según el Gerente de Investigación y Desarrollo de la división de Agricultura de Hexagon, Tarcísio Mello, dada la naturaleza de la solución, que trabaja con cientos de GB de datos enviados mensualmente por diversos equipos agrícolas monitoreados, esto representa un costo creciente de almacenamiento para RDS y también de DB , ya que una base de datos con un gran volumen de datos termina generando más consumo de CPU y memoria.

«Para tener una idea, cada 1 minuto, cada dispositivo envía un registro con información diversa, incluida una gran cantidad de sensores. Este registro es recibido y manejado por IoT y persiste en nuestro RDS Postgres. », explica Tarcisius.

En una búsqueda constante del mejor escenario costo-beneficio, comenzaron a trabajar para evitar este aumento continuo del volumen y los costos de almacenamiento, asegurando la calidad y el rendimiento de la solución, y manteniendo la competitividad en el mercado. Todavía existía el reto de no poder contar con un largo período de inactividad para realizar cualquier procedimiento, además de la necesidad de conservar los datos históricos durante un largo período después de su generación.

En este sentido, el equipo de la división de Agricultura de Hexagon inició un trabajo de optimización en su base de datos RDS PostgreSQL, que incluyó 7 fases, como explica Flávio Ximenes, el DBA de la compañía:

Fase 1: Actualización de la versión de base

El primer paso fue migrar la versión de la base de datos RDS Postgres 9.4 a la versión 11.2 en fases. Primero migró de 9.4 a 9.5, 9.5 a 9.6, 9.6 a 10.2 y finalmente de 10.2 a 11.2.

Fase 2: Particionar las tablas más voluminosas en RDS Postgres

Con la actualización del banco, se ganó la función de partición, que en la versión 9.4 aún no estaba disponible. La división de Agricultura de Hexagon dividió todas las tablas con alto volumen de datos por mes/año debido a la forma en que son consultadas por la aplicación. Sobre esta base de datos había una tabla con los datos recibidos de todos los sensores, y esta tabla representaba el 70% de su almacenamiento total.

«Nos dimos cuenta de que con la actualización, el analizador JSON y las funciones de lectura estaban funcionando mucho mejor que la versión anterior. Así que remodelamos la aplicación para dejar de usar esta tabla de sensores (usando JSON directo) y con eso pudimos eliminarla del banco. Con esta caída tuvimos una reducción significativa en el tamaño de la matriz, y eso nos trajo un «problema»: ¿cómo disminuir el tamaño de la base de datos sin tiempo de inactividad en la aplicación?«, dice Flavio.

Fase 3: Depurar datos antiguos para S3/Glacier generando archivos CSV «enriquecidos»

Después de eliminar la tabla de sensores, la división de Agricultura de Hexagon decidió purgar información de la base de datos antes de 12 meses, y por lo tanto tuvo una disminución aún mayor en el volumen de almacenamiento de la base de datos. Esto fue inicialmente 6,5 TB, y después de estos procesos de reducción del volumen de almacenamiento en la base de datos, se convirtió en 1,5 TB, lo que representa una reducción del 77% en el volumen total de la base de datos.

Durante el proceso de purga de estos datos, pasa por un proceso de enriquecimiento, en el que se incorpora información adicional sobre los campos de los registros de monitoreo, como información sobre equipos, operadores y actividad realizada en el campo. Inicialmente, esta purga enriquecida se realizó manualmente, se copió en S3 y se almacenó en la categoría Glacier Deep Archive.

Fase 4: Creación de un nuevo RDS (con menor volumen de almacenamiento)

La división de agricultura de Hexagon creó una nueva instancia de base de datos RDS paralela a su instancia de RDS de producción, con el tamaño final que necesitaban para la migración de datos. Esta instancia de RDS sólo se creó con los esquemas de las bases de datos, sin ninguna información introducida en sus tablas. Las pruebas de migración se realizaron con AWS DMS, pero debido a que tienen datos complejos en sus tablas, optaron por la extensión plogical de PostgreSQL para replicar los datos continuamente en la base de datos de destino. La copia se produjo en paralelo al uso de la aplicación, sin causar pérdida de rendimiento durante el proceso.

El proceso de replicación de los datos tomó 72 horas debido al alto volumen de datos, y después de este período, solo lo que se insertó o cambió se replicó en la base de datos de destino. Mantuvieron la replicación continua durante unos días, y después de la aprobación para el intercambio de la base de datos antigua a la nueva base de datos, lo hicieron con un tiempo de inactividad mínimo.

Fase 5: Cambie, en el entorno de producción, de la antigua instancia de base de datos de RDS a la nueva

Una vez completada la copia de datos, solicitaron una pausa programada para que los clientes de la aplicación intercambiaran la base de datos de producción. Detuvieron todos los servicios conectados a la base de datos y realizaron este intercambio: cambie el nombre de la base de datos actual (con el mayor volumen de almacenamiento) a otro nombre y cambie el nombre de la nueva base de datos con el nombre previamente asociado a la base de datos de producción. Después del cambio de nombre, la división de Agricultura de Hexagon reinició los servicios y todos los clientes ya se han conectado a la nueva base de datos. El tiempo de inactividad fue mínimo y el cambio no afectó la aplicación.

Fase 6: Eliminación de la antigua instancia de base de datos de RDS (con mayor volumen de almacenamiento)

Al intercambiar instancias de base de datos PostgreSQL de RDS, ya no era necesario mantener la instancia RDS antigua en ejecución. Como resultado, la división de Agricultura de Hexagon respaldó esta instancia de RDS como medida de precaución y la archivó en S3 Glacier Deep Archive, finalmente eliminándola de la antigua instancia de RDS.

Fase 7: Automatizar el proceso de purga de datos mensuales en la base de datos PostgreSQL de RDS

Después de todos estos pasos, la división de Agricultura de Hexagon automatizó el proceso de enriquecimiento y purga de datos. Mensualmente, ejecutan un proceso que se conecta a la base de datos de producción e identifican las tablas que se van a depurar. Después de este paso, ejecutan las consultas para generar los archivos en formato CSV y copiarlos en S3, luego borrando la tabla de la base de datos de producción. «Con esta acción, hemos logrado mantener la base de datos con un tamaño estable, sin un crecimiento muy grande», dice Flávio.

Resultados

«Después de estos procedimientos, pudimos optimizar nuestro entorno de bases de datos en más de un 60%, teniendo en cuenta los costos de almacenamiento y el tamaño de instancia de RDS, en entornos de desarrollo, pruebas, homologación y producción. Además de reducir costos, aún tenemos una mejora significativa en el rendimiento de las aplicaciones y en la ejecución de rutinas automatizadas como consolidación de datos, generación de métricas y alertas. » explica Tarcisio Mello.

También puede optimizar los costos de su base de datos, a partir de su análisis en varios aspectos.

Aquí hay cinco recomendaciones que le ayudarán a obtener un mayor valor en el uso de su base de datos:

1. Detener las instancias de RDS desde la funcionalidad «Detener e iniciar»: Esta funcionalidadespecialmente adecuada para entornos de desarrollo y pruebas que no requieren acceso a la base de datos las 24 horas del día, los 7 días de la semana, le permite reducir los costos asociados con su instancia de base de datos. Mientras la instancia está en pausa, se le cobrará el almacenamiento de la base de datos y el almacenamiento de copia de seguridad, pero no las horas de instancia de base de datos.

Desde esta función, la instancia de base de datos se puede pausar durante un máximo de 7 días; esto es para garantizar que se realice el mantenimiento necesario en las bases de datos. Sin embargo, el procedimiento «Stop and Start» se puede automatizar de forma programada mediante las funciones de Lambda que se invocan desde eventos programados.

Para facilitar la administración de la instancia de base de datos de RDS, cuando se inicia, se mantienen los valores desde el momento en que se pausó, como la configuración de punto final, los grupos de seguridad y los grupos de parámetros de base de datos. Para ver más detalles y empezar a usar la función «Detener y comenzar», lea este otro Blogpost.

2. Usar instancias reservadas de RDS:Este modelo es adecuado para escenarios en los que el uso de instancias es predecible. Un ejemplo de este escenario es un comercio electrónico, cuyas instancias de base de datos necesitan estar conectadas todo el tiempo, para ser consultadas por la aplicación web, que también necesita operar las 24 horas del día, los 7 días de la semana.

Puede reservar una instancia de base de datos de RDS con un compromiso de utilización de 1 o 3 años y recibir descuentos de hasta un 60% sobre el modelo bajo demanda. Las instancias reservadas están disponibles para Aurora, MySQL, MariaDB, PostgreSQL, Oracle y SQL Server. Para obtener más información, visite nuestra documentación sobre instancias reservadas de Amazon RDS.

3. Elija el tipo y el tamaño adecuados para su instancia de base de datos: existen varias familias de instancias de RDS, que se distribuyen entre familias de propósito general y optimizadas para memoria. Además, puede elegir entre diferentes combinaciones de CPU, memoria, almacenamiento y capacidad de red para definir el conjunto de recursos óptimo para la base de datos.

Realizar el tamaño correcto implica analizar continuamente las necesidades y patrones de rendimiento y uso de la instancia. Dado que las necesidades de recursos cambian constantemente, el tamaño adecuado debe convertirse en un proceso frecuente, de modo que pueda lograr una optimización de costos continua.

Más específicamente acerca de RDS, se recomiendan las siguientes métricas para determinar si la utilización real es menor que la capacidad de la instancia:

• Utilización media de la CPU;
• Utilización máxima de la CPU;
• Memoria RAM mínima disponible;
• Cantidad media de bytes leídos desde el disco por segundo;
• Cantidad media de bytes escritos en el disco por segundo

En función de estas métricas, puede ajustar la memoria y la potencia de cálculo de la instancia para asignar sólo los recursos que necesita a medida que los requisitos de rendimiento y capacidad cambian con el tiempo. Para obtener más información sobre las instancias de tamaño adecuado, visite nuestros Consejos para el tamaño adecuado en nuestra documentación de AWS.

Además, cuando actualiza la instancia de RDS a una generación más reciente, como de la generación M4 a M5, también puede lograr un mayor rendimiento y un menor costo por hora de la instancia de base de datos. Visite nuestra documentación de tipos de instancias de RDS para obtener información sobre las distintas familias y generaciones disponibles para las instancias de base de datos de RDS.

4. Considere el uso de Aurora Serverless para entornos de desarrollo y pruebas, y escenarios de demanda muy variable: Disponible para MySQL y PostgreSQL, Aurora Serverless solo se factura por el almacenamiento de bases de datos y la capacidad de E/S consumida por los datos mientras está activo.

Por lo tanto, en entornos donde la base de datos se utiliza sólo durante unas pocas horas del día, como entornos de desarrollo y pruebas, o incluso entornos de demanda muy variable, donde puede haber un largo período de no utilización de la base de datos, Aurora Serverless puede tener un alto costo-beneficio. Para obtener más información sobre Aurora Serverless, visite nuestra documentación de servicio .

5. Administre el ciclo de vida de sus datos: para los datos a los que ya no se accede con frecuencia, como en el caso de la división Agricultura de Hexagon, que realizó movimientos de datos creados antes de 12 meses, la adopción de una estrategia de ciclo de vida para sus datos puede contribuir a reducir al almacenar su base de datos.

Dicha gestión del ciclo de vida de los datos es posible mediante tareas automatizadas que mueven los datos a los que se accede menos desde la base de datos, como los datos históricos, por ejemplo, a un servicio de almacenamiento más rentable, como Amazon S3 o Amazon Glacier. Para obtener más información sobre el archivado de datos de bases de datos relacionales en Glacier, lea esta publicación de blog, que muestra paso a paso cómo puede realizar este procedimiento.

Una vez almacenado en S3, puede configurar ciclos de vida para estos datos en el propio bucket. Si estos datos sólo se necesitan durante un cierto período de tiempo, es posible configurar en el ciclo de vida la expiración de los datos después de un cierto período de tiempo. Sin embargo, si estos datos siguen siendo poco utilizados después de cierto tiempo, pero es necesario almacenarlos durante un cierto período de tiempo por razones de auditoría o cumplimiento, es posible configurar en el ciclo de vida la transición de estos datos a diferentes clases de Amazon S3, como S3 Infrecuente Access o Glacier, que ofrecen una mayor rentabilidad para los datos a los que se accede con menos frecuencia.

Conclusión

Utilizando estrategias de optimización en su base de datos RDS, la división de Agricultura de Hexagon logró ahorrar un 60% en costos y logró una mejora significativa del rendimiento. Verifique su entorno según lo indicado para lograr mejoras y ahorros de costes en su Amazon RDS. Para obtener aún más optimización en sus entornos, incluidos el costo y el rendimiento, visite nuestra página AWS Well-Architected Framework que ayuda a los arquitectos de la nube a crear infraestructuras seguras, resistentes, eficientes y de alto rendimiento para aplicaciones y mucho trabajo.

Sobre los autores

Tarcisio Mello es propietario del producto y certificado Scrum Master de Scrum.org y se desempeña como Gerente de I+D en la división de Agricultura de Hexagon.

Flávio Ximenes es Analista de Sistemas con especialización en Database y actúa como DBA en la división de Agricultura de Hexagon.

Lígia Harumi Yamamoto es Arquitecta de Soluciones en AWS, apoyando a clientes de diferentes ubicaciones y segmentos en sus trayectorias de innovación y transformación digital en la nube.