Migra a Amazon RDS for Oracle con optimización de costos

Por Nathan Fuzi, Arquitecto Principal de Soluciones Especialista en Oracle en AWS

Al migrar aplicaciones de bases de datos Oracle a AWS, tú tienes muchas oportunidades de modernizar y optimizar tu arquitectura. Esta migración proporciona mayor agilidad y flexibilidad, así como el potencial de migrar a un servicio totalmente gestionado como lo es Amazon Relational Database Service (Amazon RDS) for Oracle. RDS for Oracle ofrece cómputo escalable, respaldos automatizados, notificaciones de eventos, y más. También ayuda a liberar a los administradores de bases de datos y otro personal de TI de muchos aspectos tradicionales de administración de infraestructura de las bases de datos Oracle, permitiéndoles enfocar su atención en aspectos de la aplicación que generen más valor al negocio. En esta publicación, discutiremos varios de nuestros pasos frecuentemente recomendados para optimizar costos al migrar y ejecutar bases de datos Oracle en AWS. La implementación de estos pasos requiere conocimiento detallado de la base de datos y de la aplicación. Por lo anterior, esta publicación está orientada a Administradores de Bases de Datos (DBAs) y gerentes de DBAs.

Migrar es una gran oportunidad para optimizar costos al estimar adecuadamente los recursos que la carga de trabajo necesita, aprovechar la automatización de AWS y características que no se tienen en centros de datos tradicionales y reevaluar tus necesidades de soluciones legadas y de componentes de terceros. Aunque el tomar las aplicaciones y llevarlas a AWS sin cambios puede ser la ruta más fácil para ir a la nube, este método lleva consigo todos los aspectos legados y de sobre aprovisionamiento de recursos de la solución en premisas. Analizar las necesidades reales para el proyecto de migración te permite potencialmente evitar el migrar datos innecesarios, reducir el tiempo que la aplicación estará fuera de operación en comparación a implementar los cambios de forma separada, y ahorrar tiempo al combinar esfuerzos en las pruebas. Tú no necesitas resolver todo durante la migración, sino enforcarte en cambios con un claro retorno de inversión (ROI). Incluso podrías encontrar que ciertas aplicaciones pueden ser completamente retiradas o absorbidas dentro de otro sistema.

Retira lo que tú puedas

La primera sugerencia es obvia en un nivel: después de todo, no hay una más manera barata para ejecutar una aplicación que no ejecutarla en lo absoluto. Vale la pena verificar que cada base de datos y las aplicaciones que la usan sean aún relevantes cuando estás planeando su migración. Puede ser que estén ejecutándose porque nadie se tomó el tiempo de detenerlas o un sistema que ya estaba detenido, reinició su ejecución después de un incidente que tenía asociado un proceso de recuperación obsoleto. Conoce lo que estás moviendo, quiénes son los usuarios clave y qué es lo que la base de datos soporta antes de retirar o migrar la carga de trabajo.

Retirar una base de datos que se encuentra corriendo en Amazon RDS for Oracle es fácil: por omisión, el servicio toma una copia instantánea final de la instancia antes de borrarla. Tú puedes restaurar una copia instantánea posteriormente si determinas que necesitas acceso a aquellos datos. Amazon RDS te permite subir de versión a la copia instantánea si la versión mayor ha sido deprecada en el transcurso del tiempo.

Examina el uso de las características de la base de datos y cuestiona la necesidad de usar la versión Enterprise en lugar de la versión Estánda

Después de identificar una base de datos Oracle que necesitas migrar, examina los requerimientos y características de la edición de la base de datos Oracle. Para más información acerca de la Edición Empresarial (EE) vs la Edición Estándar (SE2), ir a Repiensa la Edición Estándar 2 de Oracle en Amazon RDS for Oracle.

La diferencia en precio entre EE y SE2 es substancial. Si una aplicación no requiere las características o complementos de la versión EE, migrar a SE2 puede eliminar dependencias de licencias EE y costos de soporte más altos, así como proporcionar una opción para ejecutarse en Instancias de Amazon RDS for Oracle con Licencia Incluida (LI) o en un motor de base de datos de código abierto. Las instancias LI te permiten pagar según el consumo por licencias de la base de datos Oracle, así como por la instancia de cómputo, lo anterior abre ahorros potenciales adicionales y evita compras de licencias y contratos de largo término. Amazon RDS for Oracle ofrece replicación síncrona a una segunda Zona de Disponibilidad y conmutación por error tanto para la versión EE, como para la SE2 con despliegues en múltiples zonas de disponibilidad, proporcionando una alternativa a Oracle Data Guard o a una replicación auto-gestionada de almacenamiento. Hemos discutido maneras para eliminar dependencias de características tales como particionamiento y métodos alternativos para la gestión de planes de SQL. Considera una combinación de Amazon RDS Performance Insights y Oracle Statspack para tus necesidades de análisis de desempeño, en lugar de Oracle Diagnostics and Tuning Packs for Oracle Enterprise Manager,  los cuales son licenciados por separado encima de la versión EE. Amazon RDS for Oracle soporta Oracle Transparent Data Encryption (TDE), la cual requiere del licenciamiento de la opción de Seguridad Avanzada, y Amazon RDS for Oracle también proporciona Amazon RDS storage encryption vía llaves de AWS Key Management Service (AWS KMS) de forma nativa.

Implementa afinaciones razonables a las consultas de la aplicación y a la instancia de Oracle y define una línea base de desempeño previo a la migración

Afinar una aplicación reduce su consumo de recursos, ya sea en el centro de datos o en la nube, y nosotros recomendamos realizar análisis regulares y afinaciones de aplicaciones de base de datos – especialmente antes de la migración. Una consulta que se está desempeñando pobremente impacta la experiencia del usuario, además requiere más recursos para ejecutarse. Más recursos consumidos – frecuentemente a lo largo de múltiples aspectos de operaciones de cómputo, memoria, almacenamiento y capacidad de procesamiento y ancho de banda de red – significan mayores costos que no agregan valor a la aplicación, y estos pueden ser reducidos o eliminados. Asegúrate de establecer una línea base del desempeño de la base de datos previo a la migración; esto te ayudará a determinar si los problemas de desempeño están relacionados con la migración misma o con la aplicación. Amazon RDS Performance Insights soporta la captura del plan de ejecución de consultas Oracle para ayudarte a identificar cambios durante la migración.

Examina el consumo reciente de recursos para las necesidades actuales y selecciona la clase y el tamaño apropiado de la instancia

Cuando estás determinando los requerimientos para los recursos de una aplicación con base de datos, es críticamente importante entender el consumo actual de recursos y no simplemente duplicar el consumo actual de recursos asignados. En un modelo de gastos de capital donde los servidores se renuevan típicamente cada pocos años, los administradores frecuentemente tienen sistemas sobre aprovisionados para el uso diario, anticipandose al crecimiento antes del siguiente ciclo de renovación. Esto lleva a una baja eficiencia de costos mientras que la carga de trabajo no necesita esos recursos adicionales. Sin embargo, cuando ejecutas tu aplicación en Amazon RDS for Oracle u Oracle de forma auto-gestionada en Amazon Elastic Compute Cloud (Amazon EC2), el aprovisionar una instancia más grande y a hacer disponibles más recursos a la base de datos conlleva solo unos pocos minutos de interrupción del servicio. Esto significa que es fácil responder rápidamente a cambios en la demanda de la carga de trabajo – ambos, incrementos y reducciones – en lugar de adivinar necesidades futuras. Esto también te habilita a permanecer actualizado con el último tipo de instancia con nuevos conjuntos de chips y unidades centrales de procesamiento más rápidas. Los nuevos conjuntos de chips y las velocidades más rápidas de reloj pueden significar que menos núcleos de CPUs sean requeridos para soportar una carga de trabajo dada, potencialmente permitiéndote reducir el tamaño de la instancia y ahorrar en costos. Oracle ha provisto herramientas como el Automatic Workload Repository (AWR, solo para la versión EE) y Statspack (EE y SE2) para ayudar a los Administradores de Bases de datos a evaluar requerimientos de desempeño y de recursos. Nosotros hemos construido una solución basada en datos de Oracle AWR para ayudarte a evaluar requerimientos de recursos a escala.

Recuerda: cuando tu aprovisionas un CPU para una base de datos comercial, tu estás generalmente obligado a pagar el costo de la licencia de base de datos ya sea que se use de forma activa el CPU o no. Tu objetivo debe ser minimizar el consumo de CPU y entonces aprovisionar solo lo que necesites para la carga de trabajo dada para evitar desperdiciar dinero en infraestructura y licenciamiento. Amazon RDS for Oracle ofrece la última generación de clases de instancia de EC2 con excelentes relaciones desempeño/precio y también ofrece instancias con memoria extendida con una relación de memoria-a-vCPU de hasta 32:1 para un dimensionamiento correcto. Adicionalmente, fíjate en bases de datos en premisas que han sido sobre aprovisionadas en CPU y RAM para compensar un almacenamiento de pobre desempeño. Amazon RDS for Oracle ofrece opciones de almacenamiento de bloque de alto desempeño y baja latencia con Amazon Elastic Block Storage (Amazon EBS). Asignando la cantidad y clase de almacenamiento a las necesidades de la base de datos puede ser más económico en el largo plazo que asignar núcleos adicionales y RAM.

Considera también tus requerimientos de desempeño reales para una aplicación, en contraste con su desempeño actual. De forma similar al sobre aprovisionamiento para el crecimiento futuro, asignar más recursos que los que se requieren para alcanzar tus objetivos de desempeño potencialmente significa un desperdicio de dinero en mejoras innecesarias de desempeño. Determina qué rendimiento necesitas hoy, y asigna recursos para alcanzar ese rendimiento, sin gastar más en alcanzar ganancias innecesarias.

Considera migrar grandes objetos y datos históricos a un almacenamiento de objetos, como Amazon S3

El almacenamiento de bloque es más caro que el almacenamiento de objetos. Muchas aplicaciones sin servidor pueden interactuar directamente con objetos en Amazon Simple Storage (Amazon S3), el cual es un almacenamiento de objetos altamente disponible y extremamente durable. Remplazar grandes objetos (LOBs) con URLs de Amazon S3 puede reducir drásticamente la capacidad total de almacenamiento requerida para la base de datos, moviendo los objetos donde otras aplicaciones pueden potencialmente interactuar con ellos más fácilmente, y haciendo la base de datos más pequeña y económica de ejecutarse. Adicionalmente, algunas bases de datos de código abierto interactúan con LOBs diferentemente, lo que significa que al removerlos de la base de datos puede ser un paso hacia una eventual migración a un motor de base de datos de código abierto. Esto va a requerir cambios a la aplicación, pero puede valer el esfuerzo para bases de datos en donde la mayoría de los datos está en la forma de LOBs.

Puedes considerar un enfoque similar para implementar el ciclo de vida de los datos, donde exportas una sola vez los datos viejos de una partición, de un rango de fechas, o de otras características de los datos, almacenando los archivos exportados en Amazon S3 y removiéndolos de la base de datos. En el evento que los datos sean necesarios después, puedes importarlos de regreso en la base de datos primaria o crear una instancia de base de datos separada para restaurar los datos históricos mientras sea necesario, y después eliminar esta instancia cuando ya no sea requerida. Oracle Data Pump puede exportar los datos, o puedes usar Oracle SQLcl o un procedimiento personalizado para exportar los datos directamente en un formato separado por comas (CSV) que, cuando es almacenado en Amazon S3, puede ser accedido por otras herramientas, como Amazon EMR, para análisis.

Determina requerimientos de alta disponibilidad y de recuperación de desastres por aplicación e implementa soluciones de forma granular

Aplicaciones críticas para el negocio requieren de alta disponibilidad (HA), y prácticamente cada aplicación necesita un plan de recuperación de desastres (DR). Pero los Objetivos de Recuperación en un Punto (RPOs) y los Objetivos de Recuperación en un Tiempo (RTOs) varían ampliamente por aplicación y ambiente. Con una arquitectura monolítica ejecutando bases de datos empaquetadas, cada núcleo tiene que estar licenciado para cada opción de la base de datos, ya sea que se utilice la opción o no. En Amazon RDS for Oracle, puedes tener cada base de datos en su propia instancia, permitiéndote habilitar características de HA, tales como despliegues en Múltiples Zonas de Disponibilidad y replicación basada en Oracle Data Guard dentro de una Región de AWS o incluso entre Regiones con réplicas de Oracle, esto de forma granular por instancia. Esto te permite optimizar la asignación de licencias y gastos para aplicaciones que realmente requieran estas características, mientras que aplicaciones con requerimientos menos demandantes de RPO y RTO pueden ser soportados por respaldos automatizados e incluso por respaldos automatizados entre Regiones.

Consolida aplicaciones pequeñas, que estén relacionadas en una sola base de datos, y separa grandes aplicaciones, que no estén relacionadas en sus propias bases de datos

Empacar bases de datos es todavía una práctica muy común: Un pequeño número de servidores físicos, con cada CPU licenciado para el software de base de datos, y un gran número de bases de datos pequeñas desplegadas en estos servidores para máxima eficiencia de costos de las licencias. Esto resulta en un número más pequeño de servidores e instalaciones de bases de datos a gestionar, pero la parte negativa es que este modelo presenta opciones reducidas para el hardware, el sistema operativo, o el mantenimiento de la base de datos sin impactar múltiples aspectos del negocio. Comprar un servidor pequeño para una base de datos es arriesgado – ¿Qué pasa si la base de datos crece más allá de las capacidades del servidor? En AWS, cambiar la clase de la instancia, con sus capacidades es eficiente y reduce el riesgo. Las aplicaciones pueden estar agrupadas o separadas según convenga a tus necesidades de negocio. En el panorama actual de los microservicios, hace sentido dividir las aplicaciones por sus necesidades individuales de dimensionamiento y escalamiento, de mantenimiento personalizado y ventanas, y soluciones de recuperación de desastres adecuadas a requerimientos individuales de RTO y RPO. Nosotros recomendamos solo agrupar aquellas aplicaciones que verdaderamente hagan sentido el ejecutarse juntas.

Considera un servicio de cache para peticiones frecuentes de objetos

El uso de cache para bases de datos relacionales con Amazon ElastiCache es otra área donde un sistema de propósito específico puede ayudar a transferir la carga que representa la ejecución frecuente de consultas y peticiones de objetos a un sistema de alto desempeño, con tiempos de respuesta incluso más bajos para las aplicaciones al tiempo que reduce la carga directa de la base de datos. Este tipo de cambio requiere cambios en la aplicación, pero puede ayudar a mejorar los tiempos de respuesta de la aplicación y reducir la cantidad de infraestructura asignada a la base de datos.

Aprovecha los servicios y características nativas de AWS

Después de examinar minuciosamente los requerimientos de cada aplicación de base de datos, considera qué funcionalidad puede ser transferida a un servicio gestionado. Amazon RDS for Oracle proporciona de forma opcional cifrado del almacenamiento de bloque para tu base de datos, y automáticamente respalda tu base de datos dentro de la Región y puede ser configurada para respaldarla en otras Regiones con unos cuantos clics. Con respaldos automatizados, tú puedes realizar una operación de restauración a un punto en el tiempo (PITR) hacia una nueva instancia de base de datos con unos pocos clics o con una sola llamada a un API. Tú puedes refrescar un ambiente no productivo de una copia instantánea de producción en minutos. También puedes usar réplicas para proveer opciones de DR y facilitar despliegues del tipo blue-green. Múltiples opciones están disponibles en AWS para mejorar tus operaciones en comparación con los ambientes en premisas, haciéndolos ejecutarse más rápido, con menor esfuerzo, y a un menor costo.

Apaga instancias cuando no las estés usando para ahorrar en cargos de instancias

Tú puedes detener instancias de EC2 y de RDS for Oracle como sea necesario y ahorrar en los costos de las instancias (el almacenamiento asignado aún tiene costo) hasta que las necesites disponibles otra vez. Tú puedes usar AWS Instance Scheduler o AWS Lambda para iniciar una instancia al principio del día y detenerla al fin del día, reduciendo significativamente los costos de instancias para ambientes que no necesitan una disponibilidad de 24×7. Para más información acerca del uso de Lambda con Amazon RDS, vea Calendarice el detener e iniciar Amazon RDS con AWS Lambda. También tenemos instancias ampliables para aplicaciones que tienen picos ocasionales, y estas instancias pueden ampliarse para absorber la carga adicional y proveer una mayor eficiencia de costos comparada con asignar instancias más grandes todo el tiempo.

Itera en estas mejores prácticas

Así como con la afinación del desempeño, la optimización de costos raramente se considera completa. Las aplicaciones cambian, en consecuencia, sus requerimientos de recursos y volúmenes de datos fluctúan. En la ausencia de procesos completos del ciclo de vida de los datos, una base de datos continuará creciendo con el tiempo. Aunque recomendamos frecuentemente el monitoreo del desempeño de la aplicación y de requerimientos de recursos, puedes también configurar alertas de  Amazon CloudWatch para notificar a los administradores de bases de datos cuando el consumo de recursos cruza umbrales superiores o inferiores, indicando que es tiempo de pensar acerca de escalar hacia arriba o hacia abajo. Puedes incluso configurar una función Lambda para realizar una operación de escalamiento cuando la alarma es disparada.

Una vez que tienes una buena idea de las necesidades de tu instancia, comprar una Instancia Reservada puede reducir substancialmente los costos de operación para instancias de Amazon RDS for Oracle. Si puedes eliminar la dependencia de características de la versión EE y migrar a SE2, también puedes considerar la opción de Licencia Incluida (LI) para Amazon RDS for Oracle. En el modelo de LI, no necesitas comprar licencias de Oracle de forma separada. AWS proporciona la licencia para el software de base de datos Oracle. En este modelo, si tienes una cuenta de Soporte de AWS con soporte para casos, contacta al Soporte de AWS tanto para Amazon RDS, como para peticiones de servicio de la base de datos Oracle.

Conclusión

En esta publicación, revisamos mejores prácticas para la optimización de costos al migrar bases de datos Oracle a Amazon RDS for Oracle. Porque cada ambiente es único, algunas de nuestras sugerencias tendrán mayor impacto que otras para tu caso específico.

Si tienes preguntas acerca de cómo planear tu migración o cómo implementar cualquiera de estas sugerencias, te pedimos que trabajes con tu equipo de cuenta para localizar un Socio de Negocio de AWS o involucrar un especialista de AWS para trabajar directamente contigo.

Este artículo fue traducido del Blog de AWS en Inglés

Acerca del autor

Nathan Fuzi es un Arquitecto Principal de Soluciones Especialista en Oracle en AWS. Él es un presentador frecuente en la Semana de Modernización de Datos de AWS y de Charlas Técnicas en Línea de AWS. Nathan trabaja directamente con clientes de AWS para migrar, ejecutar y optimizar sus aplicaciones de bases de datos en Amazon RDS for Oracle. Con más de 20 años de experiencia en bases de datos, él disfruta ayudando a los clientes a construir soluciones técnicas para resolver problemas de negocio.