Appgree

Appgree es una aplicación para la agregación de opinión en tiempo real que proporciona un mecanismo sencillo para la comunicación de ideas entre grandes grupos de personas como si de un ente único se tratara. Appgree nace con la ambición de convertirse en una nueva forma de comunicación con la que cualquier grupo de usuarios, independientemente de su tamaño, pueda expresarse con una voz única que represente fielmente al grupo en su conjunto y no a los usuarios individuales.

Objetivos

Dada la naturaleza del proyecto, se dan una serie de circunstancias que hacen que la utilización de un datacenter clásico sea prácticamente inviable debido a los costes de despliegue y operativos del mismo:

  • Alta escalabilidad y disponibilidad del servicio desde el primer momento.
  • Elevadísimo potencial de volumen de usuarios en los primeros meses tras la puesta en producción.
  • Concepto de aplicación muy propenso a picos de carga.
  • Tiempo de desarrollo para las primeras versiones de producto muy acotado (Menos de 6 meses para la puesta en producción por compromisos comerciales).

Con todas estas restricciones en mente, se decide utilizar una solución de computación en la nube para el alojamiento del servicio, concretamente Amazon Web Services, debido principalmente a su posición como lider del mercado y el elevado número de servicios gestionados que permiten la reducción del tiempo de implantación.

Gestión de la Configuración: Puppet

Con el objetivo de proporcionar un mecanismo de centralización y documentación de la configuración de la infraestructura, se implementó toda la configuración de sistemas en forma de manifiestos  y módulos de Puppet. Gracias a este servicio, toda la configuración de la plataforma se encuentra centralizada, modelada en forma de código versionable y permite  simplificar enormemente la implementación de cambios en la configuración sin necesitad de acceder a cada nodo de forma independiente. Adicionalmente, para facilitar las labores de ejecución paralela de tareas y realizar consultas de información local de un grupo de instancias se implementó Mcollective como mecanismo de orquestación de tareas.

Appgree - Puppet

Gestión de la configuración: Puppet + Mcollective

Para que este escenario sea posible con el mínimo de interacción por parte de los administradores de sistemas, se ha implementado un bootstrap personalizado de manera que todas las instancias se registran en estos servicios de gestión de forma automática y se le asignan una serie de propiedades en función de su rol dentro de la infraestructura, de manera que cada nodo o grupo de nodos es fácilmente localizable mediante filtros simples de Mcollective.

Alta Disponibilidad

Debido al potencial que tiene la aplicación en su uso por grupos masivos de personas desde cualquier parte del mundo, se hace crítico diseñar un sistema tolerante a fallos  y preparado para mantener el servicio operativo 24x7.

Diseño de Subredes y Zonas de Disponibilidad

La gestión de subredes en un entorno de cloud computing como AWS tal y como se entiende viniendo de una infraestructura OnPremise  pierde completamente su sentido gracias a la virtualización de las redes. En un escenario como el que nos ocupa podemos reducir la gestión de subredes a una distribución meramente funcional y “geográfica”. En la siguiente tabla se muestra la matriz de combinaciones elegida para una configuración de subredes de acuerdo a tres criterios:

  1. Zona de disponibilidad de AWS (3 en este caso).
  2. Visibilidad de la red pública/privada. Sólo aquellas instancias o servicios alojadas en redes públicas podrán contar con una IP pública.
  3. Ámbito de uso. En la práctica puede simplificarse como subredes destinadas a alojar instancias EC2 o servicios gestionados de AWS con disponibilidad de configuración en VPC (ELB, RDS, Elasticache, EMR…).

Esta clasificación permite una gestión sencilla de las tablas de rutas aplicadas en función de las zonas de disponibilidad (Rutas por defecto a través de NAT independientes) y determinar qué subredes contarán de forma automática con una IP pública al arrancar una instancia en dichas redes (EC2 Públicas).

Para la restricción del tráfico de red es preferible la implementación de grupos de seguridad, un mecanismo mucho más flexible y similar a las clásicas ACLs, con el añadido de permitir restricciones por pertenencia a grupo y no sólo por segmentos de red y CIDRs.

Con el objetivo de minimizar la superficie de ataque expuesta en Internet se ha tratado de minimizar el número de instancias EC2 en redes públicas y maximizar el uso de ELBs públicos, el servicio de balanceo de carga gestionado de AWS. Tan sólo las instancias de NAT  de cada zona de disponibilidad y la VPN administrativa se despliegan en este tipo de subredes.

Almacenes de Datos: RDS, S3 y SQS

Como en cualquier infraestructura de servidores, los sistemas de almacenamiento de datos constituyen el principal cuello de botella y origen de problemas estructurales debido a sus elevadas necesidades de acceso a disco y los problemas que representan las tareas de replicación, escalado y recuperación ante errores. Para solventar con garantías esta parte de la infraestructura y maximizar la disponibilidad del servicio se ha optado por la implementación de distintos servicios gestionados de AWS:

  • RDS: Gracias a este servicio, junto con la contratación de volúmenes SSD con IOPS provisionadas y la configuración en MultiAZ, se consiguieron cubrir todas las necesidades del proyecto: configuración del servicio en apenas unos minutos, failover automático con un downtime de escrituras acotado a 2 minutos (facilmente absorbible en tiempo de ejecución), gestión del escalado vertical automatizada, escalabilidad horizontal de lectura (disponibilidad del servicio para lecturas prácticamente del 100%), rendimiento de IO predecible, backups automatizados, monitorización con Cloudwatch inmediata, etc.
  • SQS: Este servicio de colas gestionado por AWS se implementa de forma intensiva para la ingestión de eventos generados por los usuarios de la aplicación, sincronización de tareas entre los múltiples servidores de ejecución batch y emisión de notificaciones. SQS proporciona un mecanismo altamente escalable y tolerante a fallos sobre el que apoyarse para el almacenamiento masivo de datos temporales pendientes de procesar.
  • S3: Una vez procesados los datos provenientes de alguno de los numerosos procesos estadísticos de Appgree, los resultados se almacenan en S3 para permitir un acceso masivo a los mismos sin necesidad de mantener una infraestructura de almacenamiento con dichas capacidades. Adicionalmente, todos los contenidos estáticos de la aplicación se almacenan en S3 para su distribución con Cloudfront.

Grupos de Autoescalado como Unidad Mínima de Aplicación

“Todo puede fallar” es una de las premisas con las que nace Appgree a la hora de enfocar los problemas de escalabilidad, y es por ello que ELB y Autoscaling se prestan como las mejores utilidades para acometer con éxito los fuertes requisitos de disponibilidad del servicio. Dichos servicios no sólo sirven como mecanismos simplificados para la implementación de clusters elásticos y escalables, sino que proporcionan una herramienta muy efectiva de auto-sanación de errores en nodos fallidos de la infraestructura. Todas las capas de aplicación de Appgree se han diseñado de forma que el Autoscaling pueda asociarse con un Healthcheck de ELB y este pueda desencadenar automáticamente el reemplazo de aquellas instancias que no pasen adecuadamente los thresholds especificados.

Appgree - Simplified Workflow

Arquitectura de aplicación simplificada

Si a esta filosofía le sumamos la implementación de múltiples zonas de disponibilidad podremos disponer de una disponibilidad muy elevada (99,99%).

El SPOF de la salida a Internet: Proxy HTTP Elástico

Uno de los principales problemas de la implementación de VPC en AWS es la falta de un mecanismo de tolerancia a fallos en las rutas por defecto de una subred, lo que hace que las instancias destinadas a proporcionar un acceso a servicios hospedados fuera de VPC deban atravesar una única instancia de NAT.

Debido al elevado número de servicios fuera de VPC de los que depende el correcto funcionamiento de Appgree (S3, SES, SQS…) el disponer de un acceso a Internet tolerante a fallos es crítico. Para ello se ha implementado un mecanismo de proxy HTTP/S basado en ELB y Autoscaling con instancias EC2 en subredes públicas:

Elastic HTTP Proxy

Proxy HTTP/S Elástico

El uso de este próxy ha permitido solventar con éxito el SPOF que supone la instancia de NAT para todas las APIs de AWS, todas ellas basadas en HTTPS. Por desgracia, para ciertos protocolos no “proxyficables” se sigue dependiendo de las instancias de NAT de cada zona de disponibilidad, con lo que se hace especial hincapié en la monitorización de dichos nodos.

Alta Escalabilidad

Gracias al diseño tolerante a fallos de las diferentes capas de aplicación, todas ellas orientadas al uso de autoscaling y servicios gestionados de AWS, todos ellos con capacidades inherentes de alta disponibilidad y escalabilidad, hacen que Appgree como aplicación tenga una elasticidad prácticamente completa, permitiendo que la infraestructura crezca y decrezca en función de la carga prácticamente a golpe de ratón desde la consola de AWS.

Sirvan como ejemplo ls estadísticas obtenidas durante las primeras fechas de puesta en producción de la aplicación, en las que compromisos comerciales con diversos medios de comunicación resultaron en una aceptación masiva de Appgree, con más de 350000 altas de usuarios en dos días. Appgree se vio en la necesidad de escalar su flota de servidores desde aproximadamente 30 nodos hasta más de 300 en apenas unas horas para luego volver a su estado inicial; de hecho, este proceso se repitió periódicamente durante varias semanas debido a su uso en uno de los shows televisivos más populares de España, todo ello sin pérdida o degradación de servicio y permitiendo a Appgree sus cifras de inversión en infraestructura a una fracción de lo que habría requerido desplegar semejante infraestructura en un datacenter tradicional.

Entornos de Desarrollo y Pruebas de Carga

Gracias al modelado de la infraestructura como código Puppet y al uso extensivo de AMIs (snapshots) para la implementación de autoescalado, los distintos equipos de desarrollo de Appgree cuentan con todas las herramientas a su disposición para el aprovisionamiento y despliegue rápidos de entornos de pruebas, con una disponibilidad equivalente a la del entorno de producción.

En estos escenarios, la implementación de horarios de disponibilidad, el uso de tipos de instancias con CPU a ráfagas (T2) y la contratación de instancias “spot” (puntuales) permite n reducir aun más los costes operativos del mantenimiento de estos entornos.

Para la realización de pruebas de latencia y carga a gran escala se hicieron uso de las mismas herramientas de autoescalado, en esta ocasión con clusters dispuestos en otras regiones de AWS, que simularan el acceso masivo de usuarios y garantizar que la infraestructura soportara los picos de carga esperados en los rpimeros días de vida de la aplicación. Durante estas pruebas se llegaron a utilizar más de 200 instancias para simular usuarios y cerca de 300 para la infraestructura de pruebas que debía soportar la carga. De nuevo, todo ello por una fracción del coste que habría supuesto disponer de semejante capacidad de cómputo en un datacenter tradicional gracias a la facturación por horas de AWS.

Monitorización y Alertas

Debido al volumen y heterogeneidad de los diferentes servicios que componen la infraestructura de Appgree, se ha decidido utilizar varios servicios diferentes para la consolidación de métricas de rendimiento y logs:

Monitorización y alertas

  • Amazon Cloudwatch: Todos los servicios de AWS se integran de forma inmediata con este servicio, lo que permite simplificar en gran medida la recolección de métricas de los servicios hospedados en AWS (EC2, ELB, RDS…).
  • Amazon ELB+S3: Todos los ELBs publicados, punto de entrada delos usuarios al servicio, exportan sus logs de acceso a S3 para su posterior análisis.
  • Elastic ELK: Para proporcionar una visión detallada de los eventos ocurridos en cualquier punto de la plataforma, se implementó un servicio de recolección de logs basado en las herramientas de Elastic Inc para el análisis de Syslog, Logs de Acceso de los ELBs públicos y múltiples ficheros de log de las distintas aplicaciones tanto de desarrollo interno como de terceros.
  • Ganglia: Aunque Cloudwatch proporciona todas las herramientas necesarias para la monitorización del rendimiento de la infraestructura, la implementación de un recolector de Ganglia y la distribución de agentes en todos los nodos permite la agregación de métricas por conceptos del negocio, ofrece un histórico de métricas mucho mayor y otorga la posibilidad de reportar métricas con una granularidad de segundos.
  • Nagios: Para la ejecución de healthchecks personalizados que comprueben el estado de los distintos servicios hospedados en las instancias EC2 se ha utilizado Nagios, el estándar “de facto” para la implementación de este tipo de servicios de monitorización.
    • Nagios + Ganglia: Para la ejecución de checks de rendimiento por métricas personalizadas sin conocer a priori las IPs de las instancias que componen la infraestructura en un momento dado y reducir el número de comprobaciones a ejecutar por cada nodo de Nagios se ha optado por integrar Nagios con Ganglia, debido a que este último constituye un repositorio de métricas centralizado donde toda la infraestructura reporta su estado. De esta forma, con una única llamada de API, Nagios puede alertar al personal de TI en caso de que cualquier instancia de cualquier cluster presente algún problema, sin necesidad de mantener checks individuales por instancia.
  • Amazon SNS: Debido a su integración inmediata con otros servicios de Amazon, la simplicidad de su API para la integración con aplicaciones de terceros y su modelo de notificación basado en suscripciones, SNS se utiliza para el envío de notificaciones tanto para las alertas generadas por Cloudwatch como las provenientes de los healthchecks de Nagios y de múltiples procesos internos del negocio.Appgree - Monitoring

Infraestructura de monitorización

Control de Costes

La flexibilidad a la hora de contratar recursos de cómputo y almacenamiento en un sistema de cloud computing como AWS hacen que en ocasiones, sobretodo a gran escala, sea mantener bajo control el inventario de todos los conceptos por los que AWS imputa un coste.

Para tener un control de recursos huérfanos, el correcto aprovechamiento de instancias reservadas y una visión en profundidad de los costes derivados de la infraestructura de servidores, se han implementado una serie de herramientas OpenSource publicadas por Netflix:

  • ICE: Esta herramienta analiza la facturación detallada que Amazon proporciona a sus clientes y ofrece un interfaz web donde poder ver rápidamente en qué productos se está invirtiendo el dinero con granularidad de hora. Adicionalmente, todos los recursos AWS de Appgree contienen una serie de etiquetas personalizadas que permiten que ICE muestre rupturas por conceptos del negocio y no sólo por productos AWS.
  • Janitor Monkey: Como parte de la “suite” de herramientas SimianArmy, Janitor Monkey se encarga de explorar la cuenta AWS de Appgree en busca de recursos sin uso, notificar a los administradores de su existencia, e incluso automatizar la eliminación automática de los mismos.
  • Conformity Monkey: Otro de los “monos” de Netflix, este se encarga analizar que todos los grupos de autoescalado y balanceadores de carga cumplan una serie de condiciones de conformidad entre las que destacan la correcta distribución de instancias entre las diferentes zonas de disponibilidad, la consistencia de subredes entre ELB y Autoscaling y múltiples configuraciones más que pueden estar en un estado inconsistente o sub-óptimo.

Seguridad

Una de las preocupaciones de Appgree a la hora de mover sus servidores a la nube era minimizar el riesgo de brechas de seguridad en el acceso a los distintos servicios que componen la infraestructura de negocio, tanto en la parte pública del mismo (E-Commerce) como en las aplicaciones internas. Para ello, se ha hecho uso de un gran abanico de opciones proporcionadas por los diferentes servicios de red y seguridad de AWS:

  • VPC: Todas las instancias EC2 del negocio se alojan dentro de VPC, un servicio de AWS que permite aprovisionar una sección de EC2 completamente aislada de Internet .
    • Subredes: Dentro de la VPC se aprovisionaron distintas subredes, cada una de ellas destinadas al alojamiento de ciertos tipos de servicios en base a su naturaleza: Acceso público o privado, instancias EC2 administradas por Appgree, servicios gestionados de AWS, Availability Zone, etc…
    • Security Groups: En lugar de implementar complejos mecanismos de firewall y ACLs de red, se optó por la utilización de Security Groups, una característica de la gestión de redes en EC2 que permite configurar restricciones de red en base a pertenencia a grupos de cada instancia y/o servicio gestionado de AWS.
    • NAT/VPN administrativa: Como se ha mencionado con anterioridad, VPC es una sección de red completamente aislada de EC2. Para proporcionar acceso a Internet y los distintos servicios de AWS hospedados fuera de la red interna (S3, SNS…) se configuró una instancia de NAT por cada zona de disponibilidad; como se menciona en apartados anteriores, este SPOF se consiguió solventar con la implementación de un proxy HTTP/S elástico. Adicionalmente, estas instancias sirven una VPN para el acceso administrativo a VPC desde ubicaciones remotas.
  • ELB: Para minimizar la superficie de ataque expuesta en Internet se decidió reducir el número de instancias EC2 en subredes con acceso público al mínimo posible. Tanto es así, que únicamente las instancias de Proxy, NAT y VPN Administrativa (una por zona de disponibilidad) son las únicas que cuentan con IPs públicas en toda la infraestructura. Todo el tráfico entrante correspondiente al uso de la aplicación se produce a través de los balanceadores de AWS, minimizando la superficie de ataque y centralizando la gestión de certificados SSL y algoritmos de cifrado.

Planes de Backup y Recuperación ante Desastres

Para simplificar el proceso de copias de seguridad y recuperación se ha hecho un uso intensivo de las capacidades que ofrece un servicio de cloud computing como Amazon Web Services:

  • EC2 y EBS
    • AMIs de todas las instancias preparadas para una eventual recuperación del servicio en caso de errores irrecuperables en las instancias de producción.
    • Snapshot periódicos de volúmenes de datos.
  • RDS
    • Backup integrado basado en snapshots de volúmenes de almacenamiento
    • Recuperación automática de la instancia en caso de errores graves que impidan restaurar el servicio.
    • Replicación de datos integrada en el servicio
  • S3 y Glacier
    • Almacenamiento de backups de ficheros mediante tareas programadas desde las instancias EC2 dedicadas al almacenamiento de datos.
    • Implementación de ciclos de vida para el archivado automático de backups en almacenamiento de bajo coste y eliminación de objetos antiguos.

 

 

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR
Q
Responsive Menu Clicked Image