🥇 Relational Database Service (RDS)

🍿 ¿Para qué sirve el servicio RDS?

RDS es un servicio que simplifica el montaje, operación, y escalamiento de una base de datos relación en AWS. RDS se encarga de las tareas comunes como respaldos, parches, escalamiento y replicación.

En unos minutos puede crear bases de datos en los sistemas mas populares y empezar a crear transacciones SQL. Posteriormente RDS se encargará de las tareas de mantenimiento de forma automática.

RDS simplifica el proceso de replicación de los datos para incrementar la disponibilidad, durabilidad o escalar mas allá de una sola instancia de bases de datos para aquellos procesos de grande cargas de trabajo en lectura de la base de datos.

RDS no provee acceso a las bases de datos mediante Shell y restringe el acceso a cierto procedimientos en el sistema y tablas que requieren privilegios avanzados. Típicamente se pueden usar las mismas herramientas para realizar queries, analizar, modificar y administrar una base de datos.

🍿 Instancias de bases de datos

RDS provee una Application Programming Interface (API) que permite crear y manejar una o mas instancias de bases de datos. Cada base de datos utiliza un motor de base de datos comercial u open source.

🥤 ¿Qué bases de datos son soportadas por AWS RDS?

Se pueden crear nuevas instancias de bases de datos utilizando la llamada CreateDBInstance en la API o utilizando la consola de administración. Las bases de datos existentes pueden ser modificadas utilizando la llamada ModifyDBInstance en la API. Una instancia de base de datos puede contener múltiples bases de datos, las cuales se pueden administrar dentro de la misma instancia de base de datos mediante comandos SQL.

Los recursos de computo y memoria son determinados por el tipo instancia de la base de datos. Se puede seleccionar una instancia. El rango de tipos de instancias se extiende de db.t2.micro con 1 virtual CPU (vCPU) y 1 GB de memoria, hasta db.r3.8xlarge con 32 vCPUs y 244 GB de memoria. Conforme se necesiten cambios con el tiempo, es posible cambiar el tipo y clase de instancia y el monto de computo y de la memoria. RDS realizará toda la migración de los datos a otra instancia de mayor o menor tamaño. Independientemente del tipo de instancia elegida, se puede realizar el control del tamaño y las características del performance del almacenamiento utilizado.

Amazon RDS soporta una gran variedad de motores, versiones y combinaciones de características. Muchas de las características y configuración típica es expuesta y manejada utilizando DB parameter groups (grupos de parametros para las bases de datos) y DB Option Groups (grupos de opciones para las bases de datos). El DB parameter groups funciona como contenedor de valores de la configuración del motor, que esta vacío por default. Para poder habilitar características específicas de un motor de DB se crea un DB option group y se configuran los valores de acuerdo a lo requerido.

Las bases de datos existentes e pueden migrar a RDS utilizando herramientas nativas y técnicas que varían dependiendo del motor. Para MySQL se puede exportar/importar un backup mediante mysqldump. También es posible utilizar MySQL Service, que brinda una interfaz gráfica que simplifica la migración de esquema y datos entre las bases de datos. También permite la conversión entre una base de datos y otra.

🍿 ¿Qué motores son soportados por RDS?

MySQL
Versiones MySQL 5.7, 5.6, 5.5 y 5.1
Motor OpenSource Community Edition con InnoDB.
Multi AZ Deployments para escalamiento horizontal.
PostgreSQL
Soporta 9.5.x, 9.4.x y 9.3.x.
Multi AZ Deployments para escalamiento horizontal.
MariaDB
Versiones 10.0.17
StraDB Storage Engine
Multi AZ Deployments para escalamiento horizontal.
Oracle
Oracle 11g y 12c.
Standard Edition One, Standard Edition y Enterprise Edition.
Se puede incluir la licencia para SE1 en el uso o utilizar la propia para todas las versiones.
MS SQL Server.
SQL Server 2008 R2, SQL Server 2012, SQL Server 2014
Express Edition, Web Edition, Standard Edition y Enterprise Edition.
Se puede incluir la licencia para Express,Web y Standard en el uso o utilizar la propia para cualquiera de ellas.
Aurora
Ofrecer servicios tipo enterprise con la simplicidad del opensource a un costo accesible.
Compatible con MySQL con hasta 5 veces mayor performance.
Cuando se crea una instancia de Aurora, se genera un cluster multi AZ que consta de un Primary Instance (soporta reads and writes) y uno y hasta 15 Secondary Instances (soporta solo operaciones de lectura).

🍿 ¿Cuáles son las opciones de almacenamiento de RDS?

RDS esta construido sobre EBS y permite seleccionar el tipo de almacenamiento basado en las preferencias de performance y requerimientos de costo. Dependiendo de la base de datos se puede escalar desde 4 hasta 6 TB en espacio y hasta 30,000 IOPS.

RDS soporta tres tipos de almacenamiento.

Magnético (Magnetic)
También llamado standard storage, ofrece costo efectivo que es ideal para aplicaciones con bajos requerimientos I/O.
Propósito General (General Purpose SSD)
También llamado gp2, puede proveer acceso mas rápido que el almacenamiento magnético. Es excelente para bases de datos de pequeño a mediano tamaño.
Provisioned IOPS (SSD)
Es diseñado para satisfacer las necesidades de cargas de trabajo intensivas.

🍿 ¿Qué sistemas de respaldos y recuperaciones están disponibles en RDS?

RDS provee dos mecanismos de respaldo de bases de datos: respaldos automatizados y snapshots.

Cada organización define un Recovery Point Objective (RPO) y Recovery Time Objective (RTO). Es común en sistemas enterprise tener un RPO en minutos y un RTO en horas o incluso días.

RPO define el máximo periodo de perdida de datos que es aceptable, en caso de una falla. Muchos sistemas respaldan los logs de transacciones cada 15 minutos, para permitir minimizar la perdida de datos en caso de un evento de borrado accidental o una falla del hardware.

RTO es definido el máximo periodo sin operaciones que es permitido para recuperar los datos de los backups y restablecer el sistema. Para sistemas grandes, puede tomar horas restaurar un backup completo.

🥤 ¿Cómo funcionan los respaldos automatizados en RDS?

RDS continuamente monitorea los cambios y respalda las bases de datos. Crea snapshots de los volúmenes de las DB, almacenando totalmente la instancia de base de datos y no solo bases de datos individuales. Se puede definir un periodo de retención cuando se crea la instancia de la base de datos, que por default sera de 1 día y se puede modificar hasta un máximo de 25. Cuando se elimina una instancia, se perderán todos los snapshots de la misma y no podrán ser recuperados.

Los respaldos automatizados ocurren diariamente durante un periodo de tiempo configurable de 30 minutos. Se puede realizar la recuperación de una DB Instance hasta un punto específico en el tiempo creando una nueva DB Instance.

🥤 ¿Cómo funcionan los snapshots manuales?

Ademas de los snapshots automáticos, es posible realizar snapshots manuales en cualquier momento. A diferencia de los automáticos, estos se preservan hasta que se eliminan manualmente.

Para bases de datos en operación, utilice Multi-AZ para minimizar el impacto del performance su snapshot. Durante el respaldo, el almacenamiento I/O puede ser suspendido mientras los datos son respaldados, y puede experimentarse elevados valores de latencia. Para las bases de datos Multi-AZ este periodo es menor.

🥤 ¿Cómo funciona el proceso de recuperación?

No es posible restaurar un snapshot a una base de datos existente. Una nueva instancia debe de ser creada cuando se restaura un snapshot. Cuando se restaura una DB Instance, solo los parámetros default de la base de datos y el security group son asociados con las instancias restauradas. Tan pronto como la restauración se complete, se deben asociar los parámetros necesarios a la base de datos y los security groups utilizados.

Cuando se utilicen respaldos automatizados, RDS combina los respaldos diarios realizados junto con los transaction logs para permitir restaurar la base de datos hasta cualquier punto durante el periodo de retención, usualmente, hasta los últimos 5 minutos.

🍿 Alta disponibilidad con Multi-AZ

Permite crear clusters de bases de datos a través de múltiples AZ, reduciendo la complejidad envuelta en esta tarea. Esto permite incrementar la disponibilidad de su base de datos utilizando replicación. Esto permite alcanzar los mas demandantes objetivos RPO y RTO utilizando replicación síncrona para minimizar RPO y RTO a minutos.

Multi-AZ permite posicionar una copia secundaria en otra AZ para propósitos de recuperación de desastres.

Endpoint:

mi_base_de_datos.#######.us-west-2.rds.amazonaws.com

Este nombre DNS que AWS es el que se utiliza para crear una conexión hacia su base de datos.

RDS automáticamente replica los datos desde la base de datos maestra en la instancia primaria, hacia la base de datos esclava en una instancia secundaria utilizando synchronous replication. Cada AZ utiliza su propia infraestructura, con una ingeniería para hacerla altamente confiable.

RDS realizará un failover para los siguientes eventos:

Los deployments de Multi-AZ son realizados únicamente con propósitos de recuperación; su intención no es mejorar el performance de la base de datos. La base de datos de reserva no esta disponible para realizar queries desde la instancia primaria. Para mejorar el performance utilizando múltiples instancias, utilice replicas de lectura, u otro tipo de cache de base de datos como Amazon ElastiCache.

🍿 Diferencias entre escalamiento vertical y horizontal

RDS permite escalar verticalmente y para algunas bases de datos horizontalmente.

🥤 ¿Cómo funciona el escalamiento vertical?

El escalamiento vertical consiste en añadir mas poder de computo, memoria y recursos de almacenamiento que permitan procesar mas transacciones, ejecutar mas queries y almacenar mas datos. Con RDS estos cambios pueden ser calendarizados y ocurrir durante los periodos de mantenimiento.

Después de seleccionar una instancia mas grande o pequeña, RDS realizará el proceso de migración con una interrupción mínima.

En cada db instance es posible escalar hasta 5 o 6 GB de espacio dependiendo del tipo de almacenamiento o el motor de base de datos. La expansión de almacenamiento es soportada para todas las bases de datos excepto SQL Server.

🥤 ¿Cómo funciona el escalamiento horizontal mediante particionamiento?

Una base de datos relacional puede ser escalada verticalmente hasta cierto punto donde la instancia alcanza su limite de tamaño. Particionar una base de datos en múltiples instancias o shards es una técnica común para manejar peticiones más allá de las capacidades de una instancia.

El sharding permite escalar horizontalmente permite escalar horizontalmente y manejar mas usuarios y peticiones pero requiere lógica adicional en la capa de aplicaciones. La aplicación puede decidir que ruta correcta utilizar para los shards, y se hace mas limitada en el tipo de queries que puede realizar. Las bases de datos como DynamoDB o Cassandra están diseñadas para escalar horizontalmente.

🥤 ¿Cómo funciona el escalamiento horizontal mediante replicas de lectura?

RDS soporta replicas de lectura que permiten escalar hacia arriba de manera elástica, mas allá de la capacidad de una instancia de base de datos para permitir cargas de trabajo de lecturas intensas.

Ejemplos en donde desplegar una o mas replicas de lectura es útil:

Por ejemplo un blog puede tienes muy pocas operaciones de escritura y muchas de lectura, por lo que la mayoría de la actividad de las bases de datos será read-only. Al descargar la actividad de lecturas en varias replicas, la instancia principal puede ocuparse solo de las operaciones de escritura.

🍦 ¿Qué bases de datos de RDS soportan replicas de lectura?

Las replicas de lectura son actualmente soportadas en RDS por MySQL, PostgreSQL, MariaDB y Aurora. Los updates realizados a la db instance fuente son replicados de manera asíncrona a la replica de lectura.

Es posible crear una o mas replicas de lectura dentro de una región, o a través de múltiples regiones. Es posible utilizar read replicas para servir trafico de lectura mas cercano a los usuarios globales y migrar las bases de datos a través de las regiones.

🍿 Seguridad en las bases de datos RDS

Asegurar las instancias de RDS y las bases de datos relacionales requiere un plan de manejo de desastres con muchas capas frecuentemente encontradas en sistema basados en bases de datos. Que incluyen infraestructura, base de datos y red.

Proteger el acceso a los recurso de la infraestructura usando políticas de IAM que limiten que acciones pueden realizar los administradores como CreateDBInstance y DeleteDBInstance.

Otra práctica de seguridad es desplegar una instancia de RDS en una red privada mediante VPC que limite el acceso de la red a las instancias de las bases de datos. Antes de esto primero debe crear un subgrupo de reg (db subnet group) que predefina que subredes están disponibles para despliegues de RDS. Ademas de restringir el acceso de red utilizando ACL’s y Security Groups para limitar el tráfico de entrada a una lista corta de direcciones IP.

A nivel de la base de datos, también sera necesario crear usuarios y garantizarles permisos para leer y escribir en las bases de datos. El acceso a la base de datos es controlado por el motor de la base de datos misma y su mecanismo de usuarios. Cree usuarios a nivel de la base de datos con contraseñas que utilicen combinaciones poderosas y que se roten frecuentemente.

Finalmente, proteja la confidencialidad de sus datos en transito y reposo con encriptación provista por RDS. Las características de seguridad varían ligeramente de un motor a otro, pero todos los motores soportan alguna forma de encriptación en transito y reposo. Es posible también conectarse mediante un cliente a una base de datos utilizando SSL para proteger los datos en transito. Y para aquellos en reposo, utilice Key Management Services (KMS) o Transparent Data Encryption (TDE). Todos los logs, respaldos y snapshots son encriptados por una instancia de RDS.

Bases de Datos en AWS RedShift
comments powered by Disqus