• Save
Devops Madrid Marzo - Caso de uso en AWS
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Devops Madrid Marzo - Caso de uso en AWS

on

  • 1,301 views

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.

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.

Statistics

Views

Total Views
1,301
Views on SlideShare
605
Embed Views
696

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 696

http://juanvicenteherrera.es 696

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Devops Madrid Marzo - Caso de uso en AWS Presentation Transcript

  • 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 deRSS y redes sociales.●Cliente(app in Play store) desarrollado por Sony Japan●Lumata desarrolla y mantiene las APIs que proveen losdatos solicitados por la app cliente.●Todos los posts son procesados y almacenados ennuestro sistema(con menos de 3 días de antigüedad).●El sistema analiza los posts y recomienda otros enbase a varios algoritmos de recomendación).●Se espera que al final del 2013 haya alrededor de1.000.000 de usuarios registrados y 170.000 usuariosdiarios activos.●Todos los servidores están en AWS y los despliegues yla gestión de la configuración se administra medianteChef.●Nexus and Jenkins are used for CI.
  • 3. 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 VPCIAM – 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
  • 4. Network diagram
  • 5. 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.
  • 6. 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
  • 7. 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