¿En qué consiste Elasticache AWS?
Es un servicio web que simplifica el montaje y administración de ambientes de cache en memoria distribuidos.
Elasticache redis vs memcached
Con ElastiCache se puede elegir entre motores como Memcached o Redis y rápidamente lanzar un cluster. Debido a que este es un servicio manejado, se puede utilizar con pocas modificaciones en sus aplicaciones existentes que usan Memcached o Redis, solo es necesario cambiar el endpoint de los archivos de configuración.
Con Memcached se pueden implementar un número de patrones de caching. El patrón mas común es cache-aside, en el cual la aplicación verifica primero dentro del cache para determinar si existen los datos requeridos, si no se encuentra se consulta entonces a la base de datos y se escriben los resultados en el cache, de tal forma que la próxima petición pueda leer los datos del cache en lugar de consultar la base de datos.
Si bien esto es posible de manejar por si mismo en un EC2, ElastiCache le permite delegar la instalación, administración de parches y actualizaciones y monitoreo de AWS de forma que se pueda enfocar en las aplicaciones. ElastiCache también provee un número de características para mejorar la fiabilidad de deployments críticos. Si se monta Memcache en un nodo, puede entrar en estado de disparidad, ElastiCache en AWS puede detectar y recuperar del estado de fallo de un nodo cache. Con el motor de Redis ElastiCache hace muy sencillo montar replicas de lectura y recuperación de fallos del primary a una replica en un evento donde se presente un problema.
Patrones de acceso de los datos (Data Access Patterns)
Retraer una llave de la memoria del cache siempre será mas rápido que el query de base de datos mas optimizado. Se debe evaluar el patrón de acceso a los datos antes de que se decida almacenarlo en el cache. Un buen ejemplo de algo para mantener en cache es la lista de productos en un catálogo. Para un sitio web ocupado, la lista de items pueden ser retraídos miles de veces por segundo. Aun cuando esto tiene sentido almacenar los items mas solicitados, también se puede beneficiar de items que no son frecuentemente accesados.
Existen algunos items de los datos que no deben ser cacheados. Por ejemplo, si se genera una página única durante cada request, es probable que no se deban cachear los resultados de la página. Sin embargo incluso cuando la página cambia cada momento, tiene sentido hacer un cache de los componentes de la página que no cambian.
Motores de Cache
Amazon ElastiCache permite rápidamente desplegar cluster de dos tipos de motores de cache: Memcached y Redis. En un nivel superior, ambos parecen muy similares, pero soportan una variedad de casos distintos y proveen distinta funcionalidad.
Memcached provee una interface sencilla que permite escribir y leer objetos en la memoria mediante datos key/value. Con ElastiCache se puede crecer o contraer de forma elástica un cluster de nodos Memcached para conseguir la demanda requerida. Se puede particionar el cluster en shards y soportar operaciones paralelas para muy alto performance. Memcached lidia con los objetos como si fueran blobs que pueden ser leídos mediante un unique key. Lo que se ponga en los objetos es decisión del usuario, y típicamente son los resultados serializados de una consulta a una base de datos. Esto puede ser strings o datos binarios.
ElastiCache soporta un numero de versiones recientes de Memcache. Cuando una nueva versión es liberada, AWS simplifica el proceso de actualización, permitiéndole crear un nuevo cluster con la versión mas reciente.
En 2013 ElastiCache añado soporte para el uso de clusters Redis. Mas allá de los objetos soportados por Memcached, Redis soporta una serie de datos como strings, lists y sets.
Elasticache redis persistence (persistencia)
A diferencia de Memcached, Redis soporta la habilidad de persistir de la memoria al disco. Esto crea snapshots que almacenan los datos para recuperar y replicarles. Los clusters de Redis soportan hasta cinco replicas para descargar las peticiones de lectura. En el caso de fallo del nodo primario, una replica de lectura puede ser promovida y se convierte en el nuevo master utilizando grupos de replicación Multi-AZ.
Elasticache redis cluster
Redis también tiene características avanzadas que hacer fácil ordenar y rankear datos. Algunos casos comunes incluyen una tabla de posiciones par aplicaciones web o como un broker de alta velocidad de mensajes en sistemas distribuidos. Con el cluster de redis, se puede aprovechar una abstracción de publish y subscribe que permita desacoplar los componentes de las aplicaciones. Esto brinda la flexibilidad de cambiar como se consumen los mensajes en el futuro sin tener que afectar el componente que esta produciendo los mensajes en primer plano.
Nodos y clusters
Cada deployment de ElastiCache consiste en uno o mas nodos en un cluster. Hay diferentes tipos de nodos disponibles para elegir basados en su caso de uso y los recursos necesarios. Un cluster sencillo de Memcached puede contener hasta 20 nodos. Los clusters de Redis estan compuestos de un nodo simple; sin embargo múltiples cluster pueden ser agrupados en un Redis replication group (grupo de replicación de Redis).
Los nodos individuales son derivados de un subset de instancias de EC2 como t2, m3, r3. Los tipos específicos pueden cambiar con el tiempo, pero hoy los rangos van de t2.micro con 555 MB de memoria hasta r3.8xlarge con 237 GB de memoria, con muchas opciones intermedias. El nodo cache de la familia t2 es el ideal para desarrollo y bajo volumen con picos ocasionales, pero ciertas características quizá no estén disponibles. La familia m3 es una buena mezcla de computo y memoria, mientras que la familia r3 esta optimizada para uso intensivo de la memoria.
Dependiendo de las necesidades, quizás sea necesario elegir un grupo de algunos nodos grandes o muchos pequeños en el cluster de grupo de replica. Como se necesiten los cambios en la aplicación, también es posible añadir o remover nodos con el tiempo. Cada nodo viene con un monto preconfigurado de memoria, con un pequeño monto de memoria asignada al motor y al sistema operativo mismo.
Aunque es un panorama indeseable, se debe planear para potenciales fallas de un nodo cache. Para los clusters de Memcached, se puede decrecer el impacto de las fallas de un nodo cache utilizando un numero mas largo de nodos con una capacidad mas pequeña, en lugar de utilizar solo nodos grandes.
En el caso de que ElastiCache detecte fallos en un nodo, reemplazara el cluster. Durante este tiempo, su base de datos experimentara un incremento de carga significativo. En el caso de Redis ElastiCache detectará la falla y reemplazará el nodo primario. Si la replicación Multi-AZ esta habilitada, una replica de lectura puede de manera programática promoverse a primaria.
Memcached y AutoDiscovery
Para los clusters particionados a través de múltiples nodos, ElastiCache soporta AutoDiscovery con la librería del cliente provista Auto Discovery simplifica el código de su aplicación sin requerir conocimiento de la infraestructura topológica del cluster del cache en su aplicación.
Elasticache connections
El cliente auto discovery le proporciona a sus aplicaciones la habilidad de identificar automáticamente todos los nodos en un cluster de cache y de iniciar y mantener conexiones a todos estos nodos. El auto discover client esta disponible para .NET, Java y plataformas PHP.
Escalamiento
ElastiCache permite ajustar el tamaño de los ambientes para cubrir las necesidades de cargas conforme evoluciona en el tiempo. Añadiendo nodos de cache adicional le permite de manera sencilla expandir horizontalmente y cumplir con mayores valores de performance de lectura o escritura. Y poder elegir diferentes clases de nodos cache para escalar de forma vertical.
Horizontal Scaling
ElastiCache añade funcionalidad adicional para permitir que se escale horizontalmente el tamaño del ambiente del cache. Esto varia dependiendo del motor que se seleccione. Con Memcache se puede particionar los datos y escalar horizontalmente hasta 20 nodos o mas. Con AutoDiscovery, su aplicación puede descubrir nodos Memcached que son añadidos o removidos del cluster.
Un cluster de Redis consiste de un nodo cache sencillo que maneja transaccions de lecturas y escrituras. Clusters adicionales pueden ser creados y agrupados en el grupo de replicación de Redis. Mientras solo se tenga un nodo que maneje los comandos de escritura, se pueden tener hasta 5 replicas manejando peticiones de solo lectura.
Vertical Scaling
Soporte para escalamiento vertical esta mas limitado con ElastiCache. Si se desea cambiar el tipo del nodo cache y escalar los recursos de computo verticalmente, el servicio no permite que se redimensione el cluster de esta forma. Es posible sin embargo, crear un nuevo cluster con los tipos de nodos requeridos y empezar a redirigir el tráfico al nuevo cluster. Es importante entender que un nuevo cluster de Memcached siempre inicia vacío, mientras que un cluster de Redis puede inicializarse desde un backup.
Replicación y Multi-AZ
La replicación es una técnica útil que provee rápida recuperación en caso de una falla en un nodo y también sirve para manejar altos volúmenes de consultas mas allá de la capacidad de un solo nodo. Los clusters de ElastiCache ejecutando Redis soportan ambos de los requerimientos de estos diseños. A diferencia de Redis, los clusters cache ejecutando Memcached son servicios en memoria independientes sin ningún servicio de protección de datos redundante.
Los clusters de cache ejecutando Redis soportan el concepto de grupo de replicación, este consiste de hasta seis clusters, con cinco de ellos funcionando como replicas de lectura. Esto permite estallar horizontalmente para escribir código en la aplicación que descargue las lecturas en alguno de estos cinco bancos.
Multi-AZ Replication Groups
Se pueden crear grupos de replicación Multi-AZ que permitan incrementar la disponibilidad y minimizar la perdida de datos. Multi-AZ simplifica el proceso de lidiar con una falla mediante la automatización del reemplazo del nodo primario.
En el caso de que el evento primario falle o que no pueda ser localizado, Multi-AZ seleccionará y promocionará un segundo nodo con una replica de lectura para convertirse en el nuevo primario, y un nuevo nodo se provisionará para reemplazar el fallido. ElastiCache entonces actualizará el sistema DNS con el nuevo primary node permitiendo a la aplicación continuar procesando sin ningún cambio de configuración y con solo una interrupción momentánea.
Es importante tener en cuenta que la replicación entre clusters es realizada de manera asíncrona, existirá un pequeño retardo de los datos para que estén listos en todos los nodos del cluster.
Backup y recovery
Cuando se ejecuta Redis se puede permitir que los datos persistan desde la memoria del disco y se cree un snapshot. Cada snapshot es una copia total de los datos que pueden ser utilizados. Para recuperar un punto específico en el tiempo o para crear una copia para otros propósitos. Los snapshots no pueden ser creados por clusters utilizando el motor Memcached porque es un motor de solo-memoria que siempre inicia vació. ElastiCache utiliza las capacidades nativas de Redis para generar un backup de base de datos que se almacenará en S3.
Los snapshots requieren que los recursos de memoria y computo puedan realizar y tener impacto en el performance de los clusters en uso. ElastiCache intentará diferentes técnicas de respaldo dependiendo del monto de memoria disponible. Una buena practica es montar un grupo de replicación y realizar un snapshot de una replica de lectura en lugar de un nodo primario.
Ademas de iniciar manualmente los snapshots, estos pueden ser creados de forma automática. Se puede configurar una ventana para que la operación del snapshot sea completada y especificar cuantos días de backups se desea almacenar. Los snapshots manuales están almacenados de forma indefinida hasta que se borren manualmente.
Utilice una combinación de snapshots manuales y automáticos para alcanzar los objetos de recuperación para su cluster de Redis. Memcached existe solamente en la memoria y no tiene capacidad de realizar respaldos.
Ya sea si los snapshots fueron creados automáticamente o manualmente, el snapshot puede ser utilizado para crear un nuevo cluster en cualquier tiempo. Por default, el nuevo cluster tendrá la misma configuración que el cluster origen, pero se pueden sobreescribir estas configuraciones. También se pueden restaurar de un archivo RDB generado por otro cluster compatible con Redis.
Control de Acceso
El control de acceso al cluster de ElastiCache es controlado primeramente restringiendo el acceso de entrada a través de la red al cluster. El tráfico de entrada es restringido mediante security groups. Cada security group define uno o mas reglas de entrada que restringen las fuentes de tráfico.
Cuando se despliega dentro de un VPC, cada nodo tendrá una dirección privada IP, dentro de una o mas subredes que seleccione. Los nodos individuales no pueden ser accedidos desde el Internet o desde instancias de EC2 fuera de la VPC. Además es posible restringir los ingresos de la red a nivel de la subred modificando el control de acceso de la red (ACL’s).
El acceso al manejo de la configuración y la infraestructura del cluster es separado del acceso a la infraestructura de Memcached o Redis. Utilizando IAM, se pueden definir políticas que controlen que usuarios de AWS pueden manejar la infraestructura de ElastiCache.
Algunas acciones clave como administrador que se pueden realizar incluyen:
- CreateCacheCluster
- ModifyCacheCluster
- DeleteCacheCluster
Los clusters de Redis además soportan:
- CreateReplicationGroup
- CreateSnapshot
