Presentación de nuestra solución cloud en Amazon Web Services destinada a la gestión de Apps con interacción a tiempo real entre usuarios y gestores de contenidos multimedia.
2. Aplicación destinada a un grupo de comunicación de ámbito nacional.
Smartphones Android y iPhone.
Aplicación para ver e interacturar dinámicamente con eventos en directo.
Información en ambos sentidos: Pull y Push.
3. Reto
• Aplicación con requisito de Alta Disponibilidad (Visibilidad tele-
espectadores cobertura nacional).
• Grandes picos de carga en virtud de la audiencia de un programa y
del uso de la aplicación.
• Infraestructura escalable (y reducible) de forma dinámica y
automática.
• NoSQL Database.
5. Auto Scaling (1)
• AMIs distintas para cluster PUSH/PULL.
• Tras el despliegue de la instancia se ejecuta un script de instalación que obtiene la aplicación de un
repositorio compartido (S3).
• Cada instancia nueva obtiene la última versión de la aplicación = cluster siempre con la versión
correcta.
• Una instancia fallida es relanzada por AS automáticamente y quedará agregada al balanceador (ELB).
• Los volúmenes EBS conectados a las instancias EC2 se consideran volátiles y los datos que en ellos se
almacenan se consideran prescindibles (logs). Las instancias y sus volúmenes se “reciclan”.
6. Auto Scaling (2)
• Métrica Auto Escalado: Consumo CPU medio del cluster (podemos cambiarla en el futuro).
• 75% CPU 10 minutos = se agrega una nueva instancia al cluster.
• 40% CPU 10 minutos = se elimina.
• Podemos cambiar fácilmente el tipo de instancia EC2 (CPU+RAM) para adaptarla a las necesidades
de la aplicación.
• Diseño de la aplicación Stateless con repositorio en S3.
7. Monitorización
Aprovechamos el servicio de monitorización CloudWatch para ofrecer transparencia y
nuevas funcionalidades.
Por ejemplo:
• El cliente dispone de visibilidad del número de instancias en funcionamiento y uso de
las mismas (CPU, RAM, etc).
• CloudWatch realiza previsión de coste EC2 y disponemos de alertas sobre umbrales
de coste previsto y poder reaccionar antes de que este coste se produzca.
• El cliente dispone de visibilidad del consumo de DynamoDB Units en tiempo real
sobre cada tabla. Se pueden tomar decisiones de cambio sobre los valores de lectura
y escritura contratados.
8. Backup
• Instancias EC2 no lo requieren (están formadas por una AMI y una copia
de la aplicación ya protegido por S3).
• El servicio AWS DynamoDB no proporciona Backup (por ahora) = Nos lo
hacemos nosotros.
• Exportación de datos y su almacenamiento desde los recursos de Celingest
en AWS.
9. Nueva forma de trabajar (1):
Para aprovechar la flexibilidad debemos ser flexibles
también
• AWS no hace magia. Herramientas conocidas utilizadas de
forma distinta.
• Diálogo bidireccional entre ambos equipos (Desarrollo -
Sistemas).
• Diseño de aplicación Stateless.
• Repositorio de aplicación externo (para Producción y
Desarrollo).
• Health-Check de aplicación para monitorización.
10. Nueva forma de trabajar (2)
• Acceso a CloudWatch y a AWS Console: Desarrollo ve lo que
Sistemas ve.
• Cambios futuros de una infraestructura "viva": Potencia de las
instancias, DynamoDB Units, Número de tablas, Algoritmo de
Auto Scaling.
• El coste ya no será "fijo cada mes". Un elemento más a
monitorizar (es necesario hacer pedagogía con nuestro CFO).
11. Futuro
• Consolidación logs/métricas en recurso externo (CloudWatch
= 15 días).
• Entorno de Preproducción y Test.
• Entorno de Datamining y almacenamiento de datos antiguos.
• Listo para IPv6 (ELB lo incluye).