Caso de uso de una plataforma montada en AWS expuesto en la mesa redonda del grupo Devops Madrid en la reunión de Marzo del 2013.

1. Madrid Devops Marzo 2013
● Mesa redonda sobre AWS
● Socialife: Caso de uso(y éxito) en AWS
● Juan Vicente Herrera Ruiz de Alejo
● Service Operations Manager en Lumata
● @jvicenteherrera
● http://www.linkedin.com/in/jvherrera

2. Socialife – El proyecto
●Agregador y recomendador de feeds provenientes de
RSS y redes sociales.
●Cliente(app in Play store) desarrollado por Sony Japan
●Lumata desarrolla y mantiene las APIs que proveen los
datos solicitados por la app cliente.
●Todos los posts son procesados y almacenados en
nuestro sistema(con menos de 3 días de antigüedad).
●El sistema analiza los posts y recomienda otros en
base a varios algoritmos de recomendación).
●Se espera que al final del 2013 haya alrededor de
1.000.000 de usuarios registrados y 170.000 usuarios
diarios activos.
●Todos los servidores están en AWS y los despliegues y
la gestión de la configuración se administra mediante
Chef.
●Nexus and Jenkins are used for CI.

4. System stats
Components EC2
– Production env(reserved instances): 43
– Custom API(Java)
nodes with current DAU. On demand
– Beanstalk instances for scale out
– RabbitMQ – Staging env: 30 nodes (Reserved instances
for ½ day)
– Redis
– 10 Load Balancers
– MongoDB (Sharding)
– 25 Security Groups
– Splunk
– 15 Key Pairs
– Varnish
– US east region
– Apache
● S3
– Alfresco
– 2 buckets VPC
IAM – 7 Network ACLs
VPC
– Multi-Factor Authentication – 10 Elastic IPs
Device(Virtual Token in – 1 VPC(2 in the future)
smartphones) – 1 Customer Gateway
– 1 Internet Gateway
– 3 Groups – 1 Virtual Private
– 6 Subnets Gateway
– 18 Users – 5 Route Tables – 1 VPN Connection

5. Network diagram

6. Pros
● Nuestras APIs son state-less por lo que se pueden escalar
horizontalmente de manera muy fácil. Se crean nodos de 0 mediante
Chef.
● Muy sencillo hacer performance tests mediante la escalabilidad vertical
que permiten las instancias. Muy rápido crear nodos de más potencia de
procesamiento en caso de ser necesario.
● Recreación de nodos ante desastre controlada con
snapshots(MongoDB) o Chef(resto de nodos stateless)
● Buena gestión de usuarios mediante VMFA, IAM, keypairs, certificados
y credenciales de usuario
● Buena seguridad mediante ACLs y Security Groups
● Buena integración con Chef. Bootstrap de máquinas con Chef
● Soporte técnico de rápida respuesta y consultoría personalizada para el
proyecto por parte de Amazon.

7. Contras
● Te debes adaptar al tamaño de las instancias que
no son personalizables
● No tienes control sobre la evolución de los
productos de los que depende tu servicio
● No tienes acceso a los logs de algunas
instancias(load balancers por ejemplo)
● Peligro de acoplamiento a los servicios AWS y su
consecuente dificultad para migrar a otro DC si
fuera necesario

8. Consejos
● Altamente recomendable tener réplicas de servidores balanceados en diferentes
zonas de disponiblidad para evitar downtime en caso de problemas técnicos de
Amazon en una zona.
● Analizar mediante performance tests el número de nodos mínimo que van a estar
funcionando 24*7 y sus tamaños para reservar las instancias. Reduce el coste
hasta 2/3.
● Recomendable usar un gran número de instancias pequeñas cercanas al 100% de
uso de CPU, en lugar de tener pocas máquinas potentes, y balancear peticiones
entre ellas.
● Pedir al soporte técnico aumentar las limitaciones iniciales de instancias que
pueden correr de manera simultáneas en EC2 (20)
● Pre warming de los Load balancers si se espera aumento de tráfico exponencial en
lugar de progresivo.
● Para determinados balanceos de servicios usar TCP en lugar de HTTP. El balanceo
de las peticiones a los diferentes nodos de nuestras APIs mediante TCP
internamente, solucionó algunos problemas de cabeceras HTTP y las sesiones sin
cerrar. Solo usamos balanceo HTTP para las peticiones que llegan al Apache
público.
● Usar Cloudformation para crear recursos de red