Webinar: Resiliencia y alta disponibilidad en Bases de Datos Aurora

Y muy bien, dando inicio el día de hoy nos acompaña la Ingeniera Daniela Blanco. La Ingeniera Daniela Blanco es líder de implementación aquí en CompuCloud, con diferentes certificaciones que impulsan lo que es su conocimiento en la nube de AWS, al igual que el Ingeniero Marco Chávez, consultor de soluciones de implementación en CompuCloud. Entonces muy bien, muchas gracias Ingeniera Daniela, Ingeniero Marco por acompañarnos el día de hoy. Y antes de dar inicio a lo que es Amazon Aurora, tal vez ustedes ya algunos nos conocen, algunos no, pero de igual manera aprovecho para platicarles un poquito sobre quién es CompuCloud. Nosotros somos una empresa líder en servicios administrados en la nube de Amazon web services. Estamos 100 % enfocados solamente en AWS, solamente trabajamos con esta nube por los beneficios que sabemos que da al cliente. Y de esto mismo nos hemos especializado en el diseño de arquitecturas Cloud, desde la planeación, la migración, lo que es implementación, administración, el respaldo y monitoreo de estas infraestructuras, al igual que la modernización de infraestructuras que es algo nuevo que se está trabajando y que nos ayuda a especializarnos en AWS. Pues diferentes certificaciones y reconocimientos. Las certific que aparecen de este lado derecho donde está Cloud Practitioner, Solution Architect, SYS Administrator, Seguridad Developer, estas son certificaciones que toma el equipo de ingenieros con el fin de especializarse en temas basados en la nube de AWS. Y las certificaciones que puede ver de su lado izquierdo en donde está Social Impact Recognition, que este es un una certificación que acabamos de recibir justamente este año, que está enfocada a lo que es el impacto social que ha tenido con pucloud. Nosotros trabajamos bajo un esquema de hackathons en universidades, en donde justamente reclutamos a equipo de ingenieros que son altamente competentes en lo que es la nube y que van saliendo de la universidad y nosotros lo que hacemos es apoyarlos en este tipo de prácticas dentro de CompuCloud para que aprendan de estas nuevas tecnologías y puedan abrirse al mundo profesional. Entonces esto es justamente el reconocimiento que recibimos en este año en el Partner Summit de México, al igual que en el 2019 estuvimos recibiendo también el reconocimiento como Consulting Partner del año. Y las certificaciones o especializaciones en donde todo el equipo trabaja son las que aparecen en la parte de aquí abajo, en donde es cuáles son las especificaciones como partner, nosotros somos un partner Advanced en AWS, existen diferentes niveles de partner que justamente nos da la certificación o las especializaciones al nivel que necesitamos tener para ofrecer estos servicios y soluciones al cliente. Trabajamos en un programa que es Well Architecture Framework, en el cual estamos certificados y especializados en lo que es las infraestructuras de AWS, basados en cinco pilares, por mencionar algunos, optimización de costos en la parte de seguridad, son cinco pilares base en los cuales al desarrollar una infraestructura en AWS se necesita tener una cierta especialización y mejores prácticas al momento de levantar estas infraestructuras y también al momento del que ya estamos trabajando dentro de ellas. También tenemos algunas otras certificaciones, por mencionar Amazon RDS Delivery, estos son SDPs especializados en soluciones de AWS, que justamente este además un RDS, estamos hablando sobre bases de datos, es por eso que hoy también hablamos sobre Aurora, por el nivel de certificación que tenemos. El Manage Service Provider es otra certificación, el cual hicimos una auditoría a través de AWS, en donde revisan todos los procesos que llevamos desde que llega un cliente hasta que termina su ciclo de vida. Otras certificaciones como Amazon API Gateway, que es otro servicio de AWS, una competencia enfocada al Service, Digital Service, en donde nosotros nos enfocamos en más allá de darle el servicio al cliente, que tu cliente, tu cliente final reciba esa alta disponibilidad y esa experiencia en la nube de AWS, 100 % compatible, 100 % disponible y que no tenga errores. Es una competencia en la cual estamos trabajando continuamente y estamos certificados para ofrecer este servicio a través de la nube de AWS. Y también algunos otros como la parte de migración, enfocados en Windows y migraciones de cualquier tipo que sea a la nube de AWS. Y por último también tenemos lo que es una certificación en ISO, esto en cuanto a lo que son los procesos que llevamos a cabo. Entonces bueno, esto es para que conozcan un poquito más cómo es CompuCloud, las certificaciones que estamos trabajando y que tenemos que actualizarnos con el fin de seguir aprendiendo en la nube de AWS. Y esto que estamos aprendiendo compartirlo con ustedes como nuestros clientes o como personas que quieren conocer un poquito más de lo que es Amazon Web Services. Y muy bien, para dar inicio, como les comenté, tenemos el día de hoy a la ingeniera Daniela Blanco, quien nos va a estar apoyando en platicarles un poquito más sobre esto que es Amazon Aurora. Entonces, ingeniera Daniela, no sé si ahí nos escucha.

Claro que sí, muchas gracias. Muy buenos días a todos. Muchísimas gracias por acompañarnos el día de hoy. Básicamente les voy a presentar la agenda que estaremos manejando en este webinar, que todo va enfocado al tema de alta disponibilidad y resiliencia, enfocado obviamente a las bases de datos Aurora. Estaremos viendo las generalidades de esta base de datos, la resiliencia y cuáles son aquellas, digamos, como estrategias o características asociadas a esta capa, en donde veremos copias de seguridad y restauración, temas de failover, replicación. También estarán las estrategias de alta disponibilidad, lo que son Cross region Replication, Global Database, Multi master Serverless y un tema, pues adicional que consideramos importante, el monitoreo con performance. Siguiente, por favor. Muy bien, igual si nos podrían apoyar a contestar esta pregunta que se presenta, es enfocada a bases de datos. ¿En Aurora actualmente cuentan con alguna base de datos aprovisionada?

Perfecto, ya estamos aquí recibiendo algunas respuestas y podemos ver que nos dice el 57% de las personas que nos acompañan nos comentan que no cuentan aún con una base de data provisionada y el 43% nos dice que sí. Muy bien, muchísimas gracias por su respuesta. Y ahora sí, ingeniera, si gusta seguimos con el tema de Amazon Aurora.

Gracias. Muchísimas gracias por su apoyo. OK, ya entrando en materia, vamos a comenzar con el tema de Amazon Aurora en sí, ¿Que es? Pues bueno, como sabrán, este tal cual es un motor de base de datos relacional que es completamente administrado, es una de las principales ventajas que nos ofrece. Principalmente se orienta a lo que es MySQL y Postgres, ¿OK? Y pues bueno, lo que hace este servicio administrado de esta base de datos es que combina, digamos que la velocidad y fiabilidad, como bien se menciona en el slide, junto con, digamos, las bases de datos comerciales, aquella sencillez y temas de rentabilidad que nos pueden ofrecer. Hablando de compatibilidad, ¿Qué significa esto en sí? ¿Es, digamos, que podemos migrar de una forma transparente o fácilmente aquellas bases de datos de MySQL y Postgres Aurora, incluso desde las RDS podríamos generar una migración pues un tanto transparente, digo, también depende mucho del motor que estemos manejando pero vamos a tener la mayor compatibilidad posible ya sea en temas de código, las aplicaciones, controladores y en algunas otras herramientas que ya se estén utilizando Probablemente se tengan que realizar algunos cambios, sí? ¿Y pueden que sean mínimos dependiendo también la estructura que se esté manejando OK? ¿Como podemos observar también nos ofrece un rendimiento cinco veces superior en el caso de MySQL y tres veces superior en el caso de Postgres Igual en un momento les estaré hablando un poco más de ello, vale? Siguiente por favor Muy bien, en sí vamos a ver cuáles son algunas de las características que ofrece Amazon Aurora Principalmente me voy a estar enfocando en tres puntos principales, digo, o sea, estamos hablando de resiliencia y alta disponibilidad entonces considero que los tres puntos que podemos ver Alto rendimiento y escalabilidad Alta disponibilidad y durabilidad Compatibilidad con migraciones, van a ver más adelante por qué es importante mencionarlo en este momento y completamente administrado, pues bueno, es lo que les comentaba, es uno de los beneficios que ya nos ofrece Alto nivel de seguridad y la rentabilidad pues bueno, son algunas cosas que vamos a estar vaya que podemos configurar dentro de la consola hay ciertos niveles o ciertos servicios que podemos estar integrando para mejorar el nivel de seguridad y la rentabilidad pues bueno, es más que nada el pago por uso que podemos estar haciendo Hablando de alto rendimiento y escalabilidad, si recordaban del punto anterior les decía que cinco veces superior en el caso de MySQL y tres veces superior en el caso de Postgres pero ¿Cómo es que se ofrece esta mejora importante en comparación con el rendimiento de las bases de datos tradicionales? ¿Pues digamos que existe una estruct estrecha relación o integración entre el motor de la base de datos y la capa de almacenamiento esto lo que ocasiona es que se reducen digamos que los tiempos de escritura en el sistema, minimiza la contención de los bloqueos también y elimina aquellos retrasos que pudieran estar afectando los subprocesos del procesamiento de la base de datos como tal y en escalabilidad estamos haciendo referencia más que nada, digamos que al autoincremento o aprovisionamiento del almacenamiento en el volumen no es lo mismo que si tenemos una base de datos en una instancia s que tenemos que estar aprovisionando desde un inicio, digamos 100 gigas de almacenamiento a que si colocamos esta base en nuestra RDS, digamos le colocamos no sé, 50 GB por ejemplo, se va a estar aprovisionando dependiendo las necesidades de la carga de trabajo, si estamos en una s pues tendremos que estar aprovisionando nosotros el almacenamiento ya sea el outbreak a nivel sistema operativo conlleva una serie de procesos adicionales, en este caso básicamente es seguir trabajando de forma normal que se va a estar aprovisionando, obviamente va a depender mucho de la lógica que se esté manejando en la aplicación, si hay algún tema de caché pues bueno, podría llegar a hacer ruido y sobreaprovisionarse, entonces pues bueno ahí hay que implementar quizás algún tema de eliminado o retención de caché o considerar algunos otros servicios adicionales, vale? ¿En el tema de alta disponibilidad y durabilidad, pues bueno, este punto en realidad se va a estar tratando más adelante, digo, existe una serie de estrategias de alta disponibilidad que se puede estar siguiendo, OK? ¿Entonces sí quisiera dejar este punto para más adelante y como último punto, la compatibilidad con las migraciones, por ejemplo de la pregunta que se hizo hace un momento de si utilizan bases de datos ya provisionadas, vaya, al momento de que nosotros hacemos uso de las RDS digamos tradicionales de estos servicios administrados podemos generar una migración un tanto transparente siempre y cuando sea el mismo motor de base de datos, sea mysql o Postgres podemos digamos que a partir de un snapshot generar la migración hacia RDS aurora, OK? Es una de las ventajas que nos da, en caso de que fuera algún otro motor pues bueno tendríamos que hacer uso de otras herramientas quizás como un esquema conversión tool para que los esquemas sean compatibles y se pueda generar esta migración y está a un lado del servicio de DMS que es un servicio que nos permite estar generando migraciones de datos de las bases de datos prácticamente en tiempo real se configura la instancia en donde se va a estar digamos que mandando la información y nosotros vamos a seguir trabajando, una vez que decimos ya sabes que ya estamos listos digamos que entramos a una ventana de mantenimiento para hacer el corte y se queda ese último punto guardado en dms, OK, siguiente por favor muy bien, vamos a entrar ahora en temas de resiliencia Pero ¿Qué es la resiliencia en sí? Como bien menciona el slide, pues es la capacidad que tiene la carga de trabajo para poder seguir llevando a cabo aquellas funciones y procesos previstos de forma correcta. Pero ¿Qué tenemos que hacer en realidad para tener esta resiliencia? Vaya, para tener la resiliencia necesitamos hablar de la infraestructura global de AWS, ¿OK? Como bien saben, esta infraestructura se compone de regiones y zonas de disponibilidad. Vale consola. Bueno, la región viene ubicada en la parte superior derecha y bueno, las regiones en sí nos proporcionan varias zonas de disponibilidad físicamente independientes unas de otras, ¿OK? Esto de alguna forma nos otorga esta alta disponibilidad de la que se va a hablar más adelante. ¿Estas se encuentran pues conectadas con redes de alto rendimiento para pues tener una baja latencia en este caso, OK? Al tener estas zonas de disponibilidad se nos permite poder diseñar mejor o utilizar mejor todos los servicios de AWS. ¿Por qué? Porque las zonas de disponibilidad nos permiten generar conmutaciones por error, que es un tema que igual se va a tratar más adelante. El failover. Esta conmutación se realiza a través de la zona de disponibilidad sin ningún tipo de interrupción. En sí los servicios manejan pues una capa o un parámetro que podemos ajustar entre cuántas zonas de disponibilidad lo queremos estar configurando. Entonces va a depender de la estrategia que queramos. Esto de utilizar más zonas de disponibilidad no significan costos adicionales al momento de que lo estamos determinando, pero sí nos garantiza que nos vamos a poder recuperar quizás de una forma automática, dependiendo también la lógica que estemos utilizando en la carrera de trabajo. Además de esta infraestructura, pues es necesario el uso de otras características que voy a mencionar a continuación. Muy bien, el primer punto del cual quisiera hablar hablando de la resiliencia son las copias de seguridad y restauración. Backup and restore. Hay tres puntos, digamos aquí, backups automatizados, los snapshots y el restore. La restauración como tal, al hablar de los backups automatizados, por sí sola la solución cuenta con una, digamos de forma ya predeterminada, un esquema de respaldos, ¿OK? Que básicamente al momento de que lo lanzamos tenemos que marcar un check y vamos a tener nuestros respaldos automatizados. Se puede llegar a tener una retención entre 1 y 35 días. ¿Sí, es un tanto diferente a las políticas de Data Live SQL Manager que podemos estar configurando en servicios como s podrían ser mayores, pero este es un parámetro por default que nos da la solución, OK? Adicional a esta capa, digamos automatizada de backups que podemos estar generando, también se cuenta con un esquema, digamos de recuperación, ¿Vale? De hasta los últimos cinco minutos en el tiempo, entonces prácticamente vamos a tener que definir un RTO y un RPO, pero por sí nos vamos a poder recuperar, bueno, vamos a poder recuperar la información de cinco minutos atrás, ¿OK? En el tema de los snapshots en sí, los snapshots nosotros los podemos crear el instante de forma manual sin ningún tipo de problema, eso sí, es muy importante que se tenga un buen seguimiento del ciclo de vida del proyecto por temas de costos, por ejemplo, porque los snapshots manuales no se eliminan de forma automática, eso si nosotros los creamos tenemos que eliminarlos de forma manual, ¿OK? En comparación con los backups automatizados, pues bueno, se encuentra una retención definida y eso es lo que va a estar haciendo que se vayan eliminando de forma automática al momento de crear estos snapshots igual no existe alguna afectación en el performance, en realidad es muy transparente este proceso, igual podemos generar copias de los backups hacia otro tipo de región o compartir estos backups entre cuentas. ¿Cuáles son las ventajas que esto nos? ¿Que esto nos ofrece al copiar nuestra información o nuestro snapshot instantánea hacia otra región? En caso de alguna falla en la región principal, nosotros vamos a poder levantar este recurso en una nueva región. Si, puede que sea un proceso manual, pero si lo ven desde la perspectiva de que algo llegase a fallar y necesitamos la continuidad del negocio, pues creo que es ahora que podamos llegar a invertir por el levantamiento de todos los recursos, pues es muy buena, no nos podríamos estar recuperando hasta cierto punto rápidamente. Igual el compartir estos backups con otras cuentas de AWS, puede ser una cuenta propia o alguna cuenta de tercero, dependiendo, pues bueno, igual nos ofrece esta versatilidad ya que vamos a poder levantar nuestros recursos en una consola nueva, o sea, básicamente en una cuenta diferente, ¿OK? ¿Y la restauración? Bueno, el tiempo de restauración si va a depender mucho del tamaño, no va a ser el mismo tiempo, digamos 10 minutos por ejemplo para una RDS Aurora que será unos 100 gigas a una aurora de, no sé, 800 GB por ejemplo, obviamente el tiempo va a ser muchísimo mayor como podemos ver en la imagen. Voy a hacer referencia por el último punto de que siempre se crea un clúster nuevo, podemos observar que en realidad se van a estar generando los backups automáticos a lo largo del tiempo, que es ahora sí que la tablita, la barrita azul en este caso, ahí podemos ver cómo se están generando nuestros backups. Al momento de que nosotros queremos hacer una restauración, pues bueno, como bien decía, se va a restaurar en un clúster nuevo, es decir, vamos a tener una instancia de Aurora nueva para hacer esa recuperación y va a tomar ahora sí que el snapshot que nosotros estemos determinando, dependiendo cuál estemos seleccionando, ¿OK? En sí los backups van a estar digamos, generando respaldos incrementales de los datos, ¿OK? Si se va a hacer un. Obviamente va a ser una copia general en algún momento, pero usualmente este proceso es un proceso incremental, así que prácticamente vamos a estar pagando por la diferencia de datos, o sea, de la escritura que hubo entre el original, entre el origen y el último respaldo que se esté generando. Muy bien, siguiente por favor. Me gustaría pasar también el tema de replicación. Muy bien, el tema de replicación porque es importante. En sí Aurora pues usa la funcionalidad de replicación que ya viene integrada dentro de todos los motores de base de datos. Digamos que para crear una especie de una instancia especial de réplica de lectura a partir de una instancia de origen, las actualizaciones, como podemos ver en la imagen, se realiza una replicación de forma asíncrona entre nuestro origen, ahora sí que nuestro origen y el destino al cual queremos copiar la información que puede ser nuestra réplica de lectura. ¿Esto en qué nos ayuda? Pues puede reducir mucho la carga de la instancia de la base de datos de origen hacia instancia de consulta. En este caso aquí vamos a empezar a hacer referencia a los endpoints del clúster y los endpoints de lectura y escritura, que son un punto importante, ya que para algunas estrategias es muy necesario utilizarlas, porque si utilizamos nuestro endpoint del clúster, ahora sí que general, podemos tener como una, digamos que una mejor estructura al momento de hacer una recuperación, ¿Vale? En sí la replicación nos permite tener hasta 15 réplicas, es decir, ahora sí que vamos, nuestra pauta va a ser la zona de disponibilidad que estemos configurando, ¿OK? Es muy importante que lo que les mencionaba de la infraestructura global, es muy importante definir, yo podría decir como mínimo unas tres o cuatro zonas de disponibilidad dentro de. Dentro de nuestra RDS. ¿Esto no quiere decir que vamos a tener cuatro instancias de nuestra Aurora, sino que vamos a tener la disponibilidad de poder levantar nuestro recurso a través de estas cuatro facetas, OK? ¿Una de las ventajas también que es el segundo punto que se menciona es que las réplicas se realizan de forma, cómo decirlo? ¿Como utiliza el mismo almacenamiento subyacente no existe una pérdida de la información, o sea no hay una pérdida de procesamiento ni pérdida de los datos, la replicación se realiza al momento, utiliza el mismo almacenamiento y no hay necesidad de tener que levantar digamos que otro tipo de storage para que nuestra instancia esté funcional, OK? Es una de las ventajas que nos ofrece, nuestros nodos de lectura van a seguir utilizando el mismo almacenamiento y es la información que va a estar consultando al momento de que pues bueno lo particionemos por los endpoints que les voy a platicar un poco de ello más adelante. Siguiente por favor. Muchas gracias. ¿Este en sí es el resumen, ahora sí que en temas de Aurora de la replicación, vaya les mencionaba que nos permite tener hasta 15 réplicas que va a estar a lo largo de las zonas de disponibilidad que nosotros estemos configurando el tipo de replicación es en milisegundos y es asíncrona, OK? Es una gran ventaja, tiene un bajo rendimiento en el impacto que pueda puede existir en la instancia principal, o sea realmente no se notaría si existe un impacto en este caso las réplicas se realizan dentro de la misma región, son estrategias digamos multi az, igual existen estrategias globales que más adelante se les estará platicando también funciona como ahora sí que destino de conmutación por error sin la pérdida de datos por el tema del almacenamiento subyacente que les comentaba anteriormente y la conmutación también se realiza de forma automática. Algunas cosas que no se pueden hacer pues bueno es digamos el configurar el retraso que existe de la replicación, ese es un parámetro que nosotros no podemos definir sino que la propia herramienta digamos que lo va ajustando en este caso y tampoco soporta digamos que esquemas diferentes con respecto al origen, esto no sé si recuerdan que les comentaba dentro de las características de migración el hecho de que por ejemplo si queremos tener un motor de base de datos diferentes a MySQL y a Postgres y lo queremos pasar a Aurora tendríamos que utilizar un Schema conversión tool para que sea compatible, en este caso digamos que no se admite porque como también es una réplica exacta de lo que nosotros ya tenemos en la instancia original o en esta aurora original, es por ello que no podemos hacer este tipo de cambios, OK, Siguiente por favor. Bien, otro punto importante es el failover o conmutación por error. En sí el failover es, vaya, es el modo en el que opera ahora sí que no solamente la aurora sino pues múltiples recursos o diversas estrategias en el que un componente secundario digamos que asume aquellas funciones de nuestro componente principal, es decir, si este no era un recurso productivo se tiene que volver productivo para poder solver o darle continuidad a la carga de trabajo. Por ejemplo, les voy a explicar pues ahora sí que la imagen que aparece del lado derecho les mencionaba anteriormente los endpoints de los clúster, que tenemos tres el principal, el de clúster y el endpoint de escritura y de lectura. Si podemos observar el moradito viene siendo nuestro endpoint del clúster y el rojo viene siendo nuestro endpoint de lectura, OK, ¿Qué ocurre cuando existe alguna falla en una zona de disponibilidad o simplemente ocurre una falla en nuestra base de datos principal, digamos que en nuestra instancia de escritura, En este caso lo que sucede aquí es que se tiene que generar esta conmutación de manera automática para que las aplicaciones pues bueno, puedan reanudar sus operaciones haciendo las consultas a la base de datos con la mayor brevedad posible, OK, Si disponemos ya de alguna réplica de lectura lo que hace es que digamos que de forma automática lo que es el endpoint va a estar como orquestando hacia dónde se va a estar yendo el tráfico? Cuando ocurre una falla, digamos que esta instancia deja de estar funcional y la que era un endpoint de lectura o una instancia de lectura, una réplica de lectura, como lo queramos ver, esta va a ser promovida, Writer o Master va a ser promovida a una instancia de escritura como bien se menciona en el primer punto, pero ¿Cómo se define cuál va a ser la instancia que va a estar tomando? Para eso hay algunos parámetros que también podemos ajustar como permite hasta 15 réplicas podemos estar ajustando de 0 a 15 el valor y va a tomar la que menor valor tenga, en este caso podemos observar en el circulito naranja que vienen unos valores de 0 y otro de 5, es por ello que como podemos observar en la primera instancia nos viene marcado con una X, esta se realiza la conmutación hacia la segunda instancia que tiene un valor de cero y no hacia la tercera que tenía un valor de 5, OK, bueno, hasta aquí vamos bien, cuando falla esta instancia, pues obviamente se reemplaza el recurso, en este caso como tenemos esta alta disponibilidad de tres zonas, lo va a reemplazar en la zona 2. En aquellos casos en donde solamente tengamos una AZ configurada, lo que va a ser nuestro recurso es recuperarnos en esa misma Z, si va a tardar más el proceso de recuperación en este caso porque se tiene que volver a lanzar dentro de la misma AZ, si es que fue ahora sí que un problema de nuestra misma base de datos lo que hizo que ésta se cayera, ¿Vale? En caso contrario, pues se estima un tiempo aproximado de recursos, recuperación o de conmutación de 30 segundos aproximadamente o incluso pudiera llegar a ser menos, este es el ejemplo, es por ello que es importante el uso de estos endpoints generales del clúster y el de lectura, porque como les mencionaba anteriormente, pues bueno, ayuda también a disminuir digamos que la carga de nuestra instancia cuando mandamos solamente las consultas a la instancia correspondiente en lugar de estar haciendo peticiones al general. De igual forma, por ejemplo, si se ejecutan temas de Aurora Serverless y es lo que les decía, si se encuentra en la misma AZ, lo que va a hacer es que en el caso de Aurora igual va a volver a lanzar ahora sí que digamos como la instancia dentro de la misma AZ que tengamos configurado, o sea, tanto para Aurora tradicional como para Aurora Serverless, el esquema de recuperación o de failover va a ser el mismo y es por ello es, les reitero, es muy importante contar con estas estrategias de alta disponibilidad o al menos ajustar los parámetros correctamente para que nos podamos recuperar cuando llegase a surgir un problema. ¿OK? Siguiente por favor. Gracias. Y bueno, vamos a entrar a las estrategias de alta disponibilidad, les voy a hablar acerca de la alta disponibilidad para comenzar, ¿Vale? En sí, esta es la capacidad que nos permite garantizar la continuidad de los servicios incluso en situaciones de deficiencia, que era del ejemplo de failover que les comentaba. ¿Una de las ventajas o que implica la alta disponibilidad también, pues bueno, como les coloco aquí la separación del almacenamiento y el cómputo, aquí estamos hablando digamos de temas monolitos y desacoplados, OK? Este también es la, digamos de aquí podemos partir para temas de alta disponibilidad, porque no es lo mismo, no es lo mismo que tengamos un monolito, ¿Vale? A que tengamos nuestros aplicativos desacoplados, porque si falla el aplicativo y estamos desacoplados. Este, pues bueno, quizás tengo un tema de autoescalamiento y se lanza mi instancia otra vez y puedo recuperar quizás la carga web, por ejemplo Y si falla la base de datos, pues bueno, son estas estrategias que les estaba comentando hace un momento. Pero si falla nuestra. Ahora sí que nuestro aplicativo estando en un monolito ya se vuelve más complejo, en este caso hay que recurrir quizás a otro tipo de estrategias, temas de ERP, RTO y RPO bien definido para podernos recuperar de forma satisfactoria. Bien, en sí todos los servicios de AWS cuentan con un nivel de SLA, es por ello que ahora sí que coloqué esta imagen. En sí el SLA es el que nos va, digamos, definir un nivel de recuperación, en este caso para Aurora es entre un 99 y un 99.99%. Pero ¿Cómo podemos llegar a ese 99? ¿Noventa y nueve por ciento? Obviamente va a depender de cómo se va a estar estructurando la carga de trabajo y la cantidad de acetas que se estén definiendo. ¿Vale? Eso es nuestro punto de partida. En sí, pues bueno, ya para conocer cuál es el porcentaje de CLA de toda nuestra carga de trabajo hay que multiplicar todos los valores y lo vemos así para sacar un valor general de recuperación y pues bueno, partir de ello para definir qué otras estrategias generales necesitamos para aumentar nuestro SLA y que pues bueno, nuestra carga de trabajo sea muy tolerante a fallos. ¿OK? Muy bien. Bueno, les hago el micrófono en este caso a mi compañero Marco Chávez para que les hable acerca de las estrategias de alta disponibilidad. Muchísimas gracias.

Muchas gracias, Ingeniera Daniela. Buenos días a todos y muchas gracias por asistir a este webinar de Aurora. Mi nombre es Marco Chávez, soy consultor del área de implementaciones y pues bueno, voy a hablar sobre el tema de Cross region Replication. Y bueno, previamente vimos un poco sobre la replicación dentro de la misma región, entonces continuaré con el Cross region Replication. Prácticamente la verdad es muy parecido al de la replicación en una región, pero obviamente con la bondad de que esta replicación sucede hacia otra región de AWS y pues prácticamente esto se traduce en que nos permite acercar los datos a aquellas regiones en donde tenemos clientes y nos ayuda a reducir la latencia. Y básicamente por allí, de la misma manera que tenemos la replicación en la misma región, también aquí con Cross Region Replication podemos promover un nodo de réplica a un nodo maestro, tanto para facilitar temas de migraciones, como ayudarnos a recuperarnos ante un desastre. ¿Y básicamente cómo funciona esta replicación a bajo nivel? Básicamente el escritor de clúster de réplica aplica estos cambios de manera lógica, por lo tanto el tema del retraso de la réplica puede estar sujeto a la demanda de la carga de trabajo. ¿OK? Muy bien, pasemos a la siguiente presentación. Equipo por favor. Muy bien, y bueno, quizás hayan escuchado hablar de Aurora Global Database, OK, podemos pasar a la presentación siguiente, equipo. Prácticamente Aurora Global Database es un servicio que nos ayuda a mejorar tanto su RTO y su RPO, ¿Si? Básicamente con Amazon Aurora Global Database podemos aprovisionar nuestras bases de datos en múltiples regiones de AWS, lo que también se traduce en una menor latencia en nuestras lecturas globales y una recuperación ágil cuando sea afectada totalmente una región. Muy bien, pasemos a la siguiente presentación para ver cómo se ve un esquema de Global Database. Básicamente por aquí en la imagen que vemos es la arquitectura de una Global Database en Aurora. Prácticamente podemos ver por allí el esquema que está en amarillo, es nuestra región principal, la cual se compone de un nodo master y de dos nodos de réplica. Y básicamente le podemos ir añadiendo nuestras regiones secundarias. Del lado derecho podemos ver que tenemos dos regiones secundarias, como es la de Irlanda y la de Norte de Virginia. Y del lado izquierdo podemos verla la región de Oregón. ¿Básicamente podemos tener hasta cinco regiones secundarias como les menciono, obviamente esto para tanto para reducir la latencia entre nuestras diferentes regiones, como para en caso de que alguna región se llegue a caer, sí? Y pues una de las bondades que tienen estas bases de datos globales, pues es su alto rendimiento, son hasta 200 mil escrituras por segundo el retraso de réplica, es decir, cuando se da de alta un dato o se actualiza en el nodo principal y se copia hacia, por ejemplo, Oregón, nuestra región secundaria, pues básicamente el tiempo que tarda es menor a un segundo. ¿Y pues no se diga en temas de recuperación, la recuperación es hasta menos de un minuto, si? Cuando se llega a caer una una región, prácticamente si se llega a caer Ohio, en menos de un minuto ya tenemos nuestra región secundaria de Virginia funcionando. Y como les mencionaba, pues soporta múltiples regiones de manera secundaria, podemos tener hasta 5 regiones y soporta la conversión en sitio hacia Global Database. Esto quiere decir, si yo ya tengo mi clúster de Amazon Aurora a lo mejor en single o multi azúcar puedo añadir, puedo Convertirlo sin problemas a Global Database sin hacer mayor esfuerzo. Muy bien, pasemos a la siguiente diapositiva equipo para ver más que nada qué ventajas tiene Global Database, ya como lo vimos anteriormente nos ayuda a reducir nuestra latencia a las lecturas globales y en temas de escalamiento no se diga, seguimos teniendo las mismas bondades que ahora, lo que se traduce a que podemos aprovisionar más instancias de solo lectura a otra región secundaria, y como les mencionaba la replicación de los clústeres primarios a secundarios se realiza de manera muy rápida e impacta realmente muy poco en el performance de la base de datos. Y ahora sí que la mayor ventaja aquí de usar Aurora Global Database es que el RTO es de menos de un minuto y el RPO de un segundo, que básicamente lo que mencionaba, el RPO se traduce en el LAG de la réplica y el RTO de dar de alta esa nueva región que queremos usar. Muy bien y bueno pasemos a la siguiente presentación equipo, más que nada quizás se pregunten cuál es aquella diferencia entre Aurora Global Database y Cross Region Replication, básicamente la verdad se escuchan muy similares, sin embargo Aurora Global Database es una solución que está precis pensada para la alta disponibilidad, por lo tanto AWS ha desarrollado una infraestructura dedicada para realizar precisamente la replicación de los datos de manera física entre las diferentes regiones, en comparación con Cross Región Replication si que básicamente usa la replicación lógica, lo que como lo mencionaba en pocas palabras los retrasos de la copia se verán afectados afectados por la carga de trabajo que exista. AWS nos recomienda utilizar Aurora Global Database para la recuperación ante desastres. Muy bien y ahora pasemos a el siguiente tema que es Aurora Multimáster para aquellas aplicaciones que tengan un mayor nivel de importancia en cuanto a las escrituras, es por ello que existe Aurora Multibaster, el cual prácticamente nos permite tener dos nodos de manera simultánea. Básicamente por aquí podemos ver un diagrama a alto nivel de lo que es Aurora Multimáster, podemos ver que tenemos dos aplicaciones que están escribiendo de manera simultánea a los nodos de escritura, el nodo 1 y el nodo 2 son nuestros nodos de escritura que están recibiendo esas peticiones de nuestras aplicaciones y estos nodos comparten el volumen de almacenamiento para estar haciendo estas escrituras. Básicamente dentro de las características que tenemos en Aurora Multimaster es que como lo veíamos aquí en el diagrama es que obviamente utilizan el mismo volumen de almacenamiento y pues en caso de que llegue a fallar un nodo, por ejemplo si llega a fallar el nodo 2 no afectaría en nada al nodo 1 y obviamente lo podemos recuperar independientemente sin afectar a nuestra carga de trabajo. Y pues un punto muy importante es que como tal el uso de Aurora Multimáster no tiene costo adicional, solamente pagamos la infraestructura que utilizamos, obviamente vamos a pagar el nodo, pero como tal el software no tiene ningún costo adicional. Muy bien, ahora pasemos a la siguiente presentación para ver un poco el tema de la disponibilidad continua con Aurora Multimáster. Bueno, bueno, prácticamente tiene casi las mismas bondades que Aurora Single Master o Multi AZ. Básicamente con Aurora Multimaster tenemos disponibilidad continua, ya que como les mencionaba tenemos dos nodos independientes que escriben en un almacenamiento compartido. Otro punto muy importante, al igual que Aurora, obviamente tenemos esa alta durabilidad ya que a bajo nivel Amazon AWS hace seis copias a lo largo de la región, teniendo dos copias en cada zona en cada zona de disponibilidad. Y pues otro punto por mencionar es que es compatible con SQL, es decir, soporta indexes, constraints, triggers, procedures, función al igual que como lo venimos manejando con Aurora normal, sigue teniendo esa compatibilidad. Y pues otro punto muy importante es la escala de escritura, que quizás es una de las características más importantes ya que Aurora Multimaster ha sido precisamente diseñada para la resolución optimizada de los conflictos de escritura que pueden surgir en estos esquemas de Multimáster. OK, y muy bien, para pasar al siguiente tema, creo que amerita un poco hablar de temas serverless, la verdad que con el auge de estas tecnologías se merece su propia presentación y básicamente también en Aurora tenemos el servicio serverlessi que básicamente es serverless en Aurora es un clúster de base de datos con cómputo escalable automáticamente tanto verticalmente hacia arriba como hacia abajo. ¿Y cuáles son los casos ideales de esta tecnología? Muchas veces tenemos nuestros clientes que utilizan sus bases de datos para pruebas y desarrollo, entonces esto se traduce en ahorro de costos cuando las bases de datos nos están utilizando, obviamente allí tenemos nuestras etapas de desarrollo, a lo mejor nada más nuestra desarrolladores están dos horas cada día o inclusive puede haber semanas en las que no estén utilizando la base de datos, entonces pues este tema de serverless nos ayuda mucho con los costos, además que simplifica las canalizaciones de prueba y desarrollo. Otro punto muy ideal para el uso de serverless es para aquellas aplicaciones que son multi inquilino con almacenes de datos de un solo inquilino, ya que nos permite igual el ahorro de costos gracias a esta capacidad de gestión automatizada. ¿OK? Y sobre todo aquellos casos ideales son las aplicaciones con carga variable o poco frecuente, ya que tienen picos de actividad que la verdad son muy difíciles de predecir para aquellas cargas que a lo mejor constantemente estamos aprovisionando nuestro clúster, que estamos cambiando de familia o demás. Entonces estos casos nos ayudan mucho las tecnologías serverless, ya que como lo mencionaba nos ayudan al tema del escalado automatizado y es en muy poco tiempo, además que esto al final de cuentas de tenerlo en temas serverless en comparación a aprovisionado, pues se traduce al final de cuentas en ahorro de costos debido a la variabilidad. OK, muy bien. Y bueno, para pasar a la siguiente presentación, creo que es muy importante hablar del monitoreo, ya que es una parte esencial de nuestras cargas de trabajo. Y vamos a ver aquellos servicios que se integran de monitoreo con Aurora, que prácticamente tenemos cuatro diferentes sabores. Y pues prácticamente el primer servicio a lo mejor ya lo conocen, es el de CloudWatch Metrics, el cual básicamente nos permite supervisar aquellas métricas principales, tanto como el CPU, la RAM, además otras métricas ya como lo son de rendimiento a nivel de transacción y ver tanto la latencia que está teniendo. Otro servicio también que nos ayuda con el monitoreo es el cloudware Logs, el cual básicamente nos permite publicar los registros de las bases de datos, tanto de los errores que están teniendo las bases de datos, aquellos quizás de auditorías o posiblemente las consultas lentas o los slug queries que pueden estar afectando nuestras bases de datos y todo esto lo llevamos a un almacén de registro centralizado como lo es cloudwatch Logs. También tenemos otra herramienta de monitoreo, la cual es el Monitoreo mejorado, que cual prácticamente nos permite añadir métricas específicas de la base de datos con hasta un segundo de granularidad. Y finalmente tenemos el servicio de Performance Insight, el cual prácticamente es un servicio que nos permite ver el rendimiento a nivel de consulta y de espera que pueda haber. Ya para finalizar en la siguiente presentación a lo mejor se pregunten, bueno, ¿Cuál es la diferencia entre el CloudWatch y el monitoreo mejorado? Recordemos que CloudWatch está integrado a Aurora, por lo tanto no tiene un costo adicional para las métricas por defecto, mientras que el monitoreo avanzado si tiene un costo adicional. Otro punto muy importante es el tema de la granularidad. Cloudwatch nos permite hasta un minuto de granularidad o mayor, mientras que como lo veíamos con el monitoreo mejorado, tenemos hasta un segundo. Y otra ventaja aquí del monitoreo mejorado es que lo podemos mandar a cloudwatch Logs para tener registros centralizados, podemos utilizar métricas ahora sí que más precisas y granulares y son muy útiles para la investigación. Prácticamente. En resumen, el monitoreo avanzado ahora sí que tiene la bondad de que tiene un agente a nivel de base de datos, ya que cloudwatch realmente es un monitoreo que está sobre el hipervisor de RDS. Realmente nosotros no tenemos, no alcanzamos a ver sobre qué tecnología están y demás, pero si Amazon nos dice que el monitoreo mejorado está a nivel de base de datos, mientras que CrowdWatch todo el monitoreo está a nivel del iPad revisor. Muy bien, entonces esto sería todo de mi parte, les agradezco mucho su atención, les cedo los micrófonos aquí al equipo para la presentación de los ejecutivos comerciales. Muchas gracias.

Muchísimas gracias Ingeniero Marco, Ingeniera Dani, por su aportación en el webinar del día de hoy. Y bueno, creo que este tema estuvo muy interesante, como pueden ver que con Amazon Aurora podemos potencializar las aplicaciones de rendimiento intenso y sus cargas de trabajo críticas, a la vez que pues mantenemos la compatibilidad total con MySQL y PostgreSQL por una décima parte del costo de lo que son las bases de datos comer. Y también como vimos, podemos crear aplicaciones con disponibilidad multi AZ con SLA garantizado del 99.99% como lo estábamos viendo con la Ingeniera Dani, en cuanto al tiempo de disponibilidad y replicación global con su recuperación de desastres entre regiones entre menos de un minuto, como lo vimos también con el Ingeniero Marco, y obviamente mejorar lo que es la productividad y disminuir el costo total de propiedad con una base de datos que está completamente administrada y que incluye innovaciones como lo vimos con la tecnología sin servidor de la parte de serverless, de modo que nos podemos centrar en crear aplicaciones que satisfagan la necesidad de nuestros usuarios y obviamente migrar fácilmente las bases de datos MySQL o Postgres hacia Aurora y a la inversa a través de estas herramientas estándar o ejecutar aplicaciones SQL Server que sean heredadas a base de Aurora con cambios mínimos en el código para hacer esta nueva innovación o este nuevo cambio. Y bueno, como pueden ver aquí les estoy compartiendo lo que son las personas, los consultores comerciales de CompuCloud, que está el ingeniero Carlos González y la ingeniera Zadia Olivares, con quienes se pueden apoyar a cualquier duda que tengan. Y también abro justamente en este momento a través de chat, si tienen alguna duda que quieran preguntar a lo que son los ingenieros que nos acompañan el día de hoy, lo pueden colocar por este medio.