En esta charla compartiremos la experiencia que tuvimos al implementar este tipo de arquitectura, los problemas con los que nos topamos, las bondades de usar ECS, las mejoras y recomendaciones en base a nuestra aventura y como unimos cada uno de los puntos dese compilar, correr y entregar.

1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Christian Melendez, AWS UserGroup Guatemala
10 de Agosto, 2017
Micro Servicios con ECS

2. Agenda
• ¿Micro servicios?
• ¿Qué es ECS?
• Auto Escalamiento en ECS
• Caso de Estudio

3. ¿Micro Servicios?

4. ¿Micro servicios?
• Escalamiento horizontal (mas copias)
• No dependen del estado
• Se pueden desarrollar independientemente
• Se pueden publicar independientemente
• Una sola responsabilidad
• Experimentar tecnologias emergentes
• Agregan complejidad

5. ¿Micro servicios?

6. ¿Qué es ECS?

7. ¿Qué es ECS?
• EC2 Container Service
• Manejador de contenedores Docker
• No te preocupas de manejar un cluster (i.e. K8s)
• Aplicaciones con un modelo de micro servicios
• Aplicaciones ETL

8. ¿Qué es ECS?

9. Contenedores e Imágenes

10. Definición de Tasks
{
"family": "webserver",
"containerDefinitions": [
{
"name": "web",
"image": "nginx",
"cpu": 99,
"memory": 100,
"portMappings": [{
"containerPort": 80,
"hostPort": 80
}]
}]
}

11. Programación de Tasks

12. Cluster y Agente ECS

13. ¿Y los puertos?

14. ¿Qué es un ALB?
• Application Load Balancer
• Mas de un contenedor por host
• Encargado del port mapping (ej. X => 80)
• Rutas por path en query string (ej. /api => servicio X)
• Case sensitive
• Reglas por puerto expuesto
• Contenedor misma ruta

15. ¿Qué es un ALB?

16. ¿Qué es un ALB?

17. Auto Escalamiento en ECS

18. Auto escalamiento en ECS
• Recursos reservados
• Unidades de CPU (1 Core = 1024 Unidades)
• Memoria por MiB
• Facilita tener la misma configuración (CPU y Memoria)
• Idealmente en múltiplos de 8

19. Auto escalamiento en ECS
• 1 instancia con 4 CPU y 4 GiB de Memoria
• Task definida con 1,500 CPU y 768 MiB de Memoria
# de Tasks
CPU
Reservado
Memoria
Reservada
Estado
1 ~36% (1500) 18.75% (768) OK
2 ~72% (3000) 37.50% (1536) OK
3 108% !! 56.25% (2304) FAIL

20. Auto escalamiento en ECS
• 1 instancia con 4 CPU y 4 GiB de Memoria
• Task definida con 1,000 CPU y 768 MiB de Memoria
• Escalar > 70% CPU Reservado
# de Tasks
CPU
Reservado
Memoria
Reservada
Estado
1 ~25% (1000) 18.75% (768) OK
2 ~50% (2000) 37.50% (1536) OK
3 ~75% (3000) 56.25% (2304) OK
4 ~50% (4000) 37.50% (3072) OK

21. Auto escalamiento en ECS
• Limite = (1 - max(Reserva de Contenedor) /
Capacidad Total de una sola Instancia) * 100
• 1 Instancia de 4096 Unidades de CPU
• 1 Contenedor de 1500 Unidades de CPU
• Limite = (1 – 1500 / 4096) * 100
• Limite = 63.38%

22. Auto escalamiento en ECS

23. Caso de Estudio

24. Caso de Estudio
• Tradicional: ASG, AMI, ELB, CloudFormation
• Todos los servicios convivían en la misma instancia
• Se publicaban todos los servicios cada vez
• Necesitábamos probar TODOS los servicios
• 1 publicación por semana (con suerte)
• Los ambientes no eran similares (infra y autom)
• Servicios self-hosted .NET (Linux, Mono, ServiceStack)

25. ¿Por qué no otro orquestador?
• Curva de aprendizaje
• No tenemos necesidad de manejar un master
• Integración con IAM es trivial
• Escalamiento es fácil de implementar *
• ECS es gratis
* https://aws.amazon.com/blogs/compute/how-to-automate-container-instance-draining-in-amazon-ecs/

26. Estrategia de adopción
• PoC con servicios dummy (manualmente)
• PoC con servicios parecidos (misma tecnología)
• Viabilidad de la operación de servicios (monitoreo, logs)
• Implementación e integración de servicios
• Dockerizar cada servicio
• Automatizar build y deploy (por servicio)
• Homogenización de ambientes (Route 53 y zonas privadas)
• Incrementar porcentaje de pruebas automatizadas
• En todas las etapas se hizo prueba de carga

27. ¿Despliegue de servicios?
• Route 53
• ALBs

28. ¿Despliegue de servicios? Siempre disponible
• Actualizar Task Definition
• 100% tasks todo el tiempo
• 2x cantidad de tasks
• Drenar conexiones
• Detiene la version anterior

29. ¿Despliegue de servicios? Continuo
• Jenkins (CI/CD)
• Terraform (IaaC)
• Nexus (Registro de Imagenes)
• Build desde development (se promueve)

30. ¿Qué implicación tuvo en los servicios?
• Las versiones tiene que ser compatibles (v1 y v2)
• Servicio debe correr en foreground
• Usualmente solo debe correr un proceso
• Si el contenedor se detiene, detiene el proceso
• ALB para service discovery (alias records)
• Usar configuraciones por ambiente (env vars)
• No mas self-hosted
• Logs a consola en lugar de archivos (stderr, stdout)

31. Lo Bueno
• Recuperación sin intervención humana
• Solicitudes fallidas al mínimo
• Al topar memoria, se crea una nueva task
• Auto escalamiento a nivel de servicio e instancia
• Identificar fallos por servicio (ej. memory leak)
• Servicios ya no compiten por recursos
• 4 publicaciones a la semana
• Rollbacks con un par de clicks (o re deploy)

32. Lo Malo
• Las conexiones no se drenan al terminar instancias
• Quitar instancias del cluster provoca downtime *
• No hay rebalanceo de contenedores
• Contenedor hereda permisos del host

33. Monitoreo y Logs
• Solamente una forma de extraer logs
• Docker Loggin Driver: CloudWatch Logs
• CPU y Memoria reservada (auto escalamiento host)
• CPU y Memoria utilizada (auto escalamiento servicio)
• Espacio en disco
• AMI incluye un disco de 22-GiB LVM (no montado, no df -h)
• Agente ECS limpia imágenes y contenedores antiguos
• Errores 5XX y 4XX en ALB y Target Groups

34. ¿Qué sigue?
• Mejorar estrategia de logging
• Mejorar la tolerancia a fallos (cascada, ej. Netflix Hystrix)
• Optimizar recursos (instancias)
• Incrementar porcentaje de pruebas automatizadas
• Replicar en otros sistemas

36. ¡Gracias!
@Christianhxc
cmelendeztech.com