ecs codemotion

Cómo generar una Arquitectura Cloud autoescalable para tu software LAMP

MADRID · NOV 27-28 · 2015

Quien somos

ENGISOFT CLOUD SERVICES Empresa especializada en tecnología Cloud bajo Amazon Web Services (AWS)

www.engisoftcloud.com

• David Regordosa: Cloud Area Manager• Toni Tebas: CTO / Solution Architect

MADRID · NOV 27-28 · 2015

https://es.linkedin.com/in/davidregordosa

@pisukeman

[email protected]

https://es.linkedin.com/in/ttebas

@ttebas

[email protected]

Objetivo de la presentación

1. ¿Qué es una arquitectura autoescalable en alta disponibilidad?

2. ¿Por qué apostar por las arquitecturas Cloud Autoescalables?

3. Hands-On: Demo arquitectura autoescalable vía consola AWS

MADRID · NOV 27-28 · 2015

Infraestructura autoescalable con alta disponibilidad

MADRID · NOV 27-28 · 2015

1. ¿Qué es la alta disponibilidad?Infraestructura autoescalable con alta disponibilidad

MADRID · NOV 27-28 · 2015


AWS está hospedado en 9 regiones distintas

alrededor del mundo.

Cada región tiene n Availability Zones

Cada Availability Zone está aislada de las

otras, pero conectadas a través de enlaces

de baja latencia (red local)

MADRID · NOV 27-28 · 2015


MADRID · NOV 27-28 · 2015

Una arquitectura con datos

replicados en distintas Availability

Zones es una arquitectura en alta

disponibilidad (HA)

2. ¿Qué es una arquitectura autoescalable?Infraestructura autoescalable con alta disponibilidad

MADRID · NOV 27-28 · 2015


Una arquitectura capaz de crecer

y decrecer para ajustarse a la

carga del sistema en tiempo real

y en caliente.

MADRID · NOV 27-28 · 2015

2. ¿Qué es una arquitectura autoescalable?

Balanceador de carga

• Reparte las peticiones entre las distintas

instancias que forman la capa

autoescalable

• Detecta estado de salud de las instancias

y saca de balanceo las que no responden

satisfactoriamente (health check)


MADRID · NOV 27-28 · 2015

Capa de autoescalado

• Capa compuesta por un número variable

de instancias.

• Escalable Multi-Zona (con paridad de

instancias en ambas zonas)

• Crece y decrece según reglas establecidas

por sysadmin

• Cloud Watch, toma metricas de

tiempo de respuesta, consumo CPU,

latencias, etc…

• Scheduled scaling: Crece y decrece según

planificación (para sistemas con

comportamientos periódicos predecibles)


MADRID · NOV 27-28 · 2015


MADRID · NOV 27-28 · 2015

Capa de autoescalado

• Capa compuesta por un número variable

de instancias.

• Escalable Multi-Zona (con paridad de

instancias en ambas zonas)

• Crece y decrece según reglas establecidas

por sysadmin

• Cloud Watch, toma metricas de

tiempo de respuesta, consumo CPU,

latencias, etc…

• Scheduled scaling: Crece y decrece según

planificación (para sistemas con

comportamientos periódicos predecibles)


MADRID · NOV 27-28 · 2015

HEALTH CHECK+

AUTO SCALING =

SELF HEALING

Backend – BD

Servicio RDS de AWS:

• Permite escalado vertical en caliente

• Puede mantener una BD slave en otra

availability zone, con una replicación

síncrona, manteniendo el compromiso de

la alta disponibilidad

• Si BD Master cae, RDS en caliente redirige

IP de Master a Slave, convierte Slave en

Master y crea otra Slave en otra Availability

Zone


MADRID · NOV 27-28 · 2015

Backend – BD

RDS permite crear copias de solo lectura

para:

1. Descargar el servidor Master de carga de

CPU

2. Para tareas programadas de alto

consumo de CPU

3. En caso de no querer trabajar en alta

disponibilidad, mantener una copia de

seguridad en caliente


MADRID · NOV 27-28 · 2015

Backend – BD (Copias Solo Lectura)

Amigo DEVELOPER!, al loro:

1. Derivar las consultas SELECT a la copia

de solo lectura, Implica Desarrollo

2. Cuidado con Read after Write!

3. Revisar latencias de replicado, ya que:

1. Saturación copias lectura: Más

copias de solo lectura

2. Saturación Master BD: Otras

optimizaciones (escalado vertical,

cacheo en memoria, etc.)


MADRID · NOV 27-28 · 2015

S3

• Servicio de objetos duradero, seguro,

altamente escalable

• Usado para almacenar media assets entre

las instancias del autoescaling group

• Para usar S3 en los CMS es necesario:

• S3FS, un Filesystem FUSE

(Filesystem in User Space) que

permite montar S3 Bucket como un

filesystem local

• O bien realizar modificaciones a nivel

de PHP, htaccess, configuración

apache, … (no es trivial)

• O dejar de usarlo….


MADRID · NOV 27-28 · 2015

AMAZON EFS(Elastic File System)

Servicio de almacenamiento de archivos

compartido por instancias de una

misma región, de baja latencia y

elástico (NFS)


MADRID · NOV 27-28 · 2015

….y usar:

Mejoras “opcionales” para nuestra infraestructura

Mejoras

• CDN Cloudfront

• Servicio web de entrega de

contenido, para disminuir la latencia

dirigiendo las llamadas a la

ubicación más cercana

• Elasticache

• Servicio de cacheado de información

para evitar problemas de cacheo con

autoescaling group. Compatible con:

• Memcached

• Redis

• Elastic File System

MADRID · NOV 27-28 · 2015

¿Por qué apostar por las arquitecturas Cloud Autoescalables?

MADRID · NOV 27-28 · 2015

¿Por qué apostar por las arquitecturas Cloud Autoescalables?El dilema del WORST CASE

• Es muy difícil poder calcular el numero de

usuarios que tu servicio web tendrá

• Tu servicio web puede no tener patrones

periódicos que permitan realizar una

estimación diaria del número de usuarios

y el uso que darán a la infraestructura

MADRID · NOV 27-28 · 2015

¿Debo aprovisionar servidores

para que mi infraestructura

pueda soportar el peor escenario

posible (Worst Case) ?


• Imaginemos un servicio web con el

siguiente patrón de uso.

MADRID · NOV 27-28 · 2015


OPCIÓN 1: Invertimos en servidores que nos

cubran el peor escenario posible (Worst

Case)

• Solo durante el Worst Case estamos

pagando la infraestructura que

necesitamos

• El resto del tiempo estamos pagando por

una infraestructura que no usamos

• El Worst Case siempre puede ser Worst

y en ese caso necesitaríamos ampliar

capacidad de nuestros servidores (tiempo

de aprovisionamiento, coste, migración…)

MADRID · NOV 27-28 · 2015


OPCIÓN 2: Invertimos en servidores que nos

cubran la media de las necesidades de

nuestra plataforma

• Menor coste respecto opción 1

• Mala experiencia de usuario en momentos

en los que la infraestructura esta por

encima de sus posibilidades

MADRID · NOV 27-28 · 2015


• 46% de los usuarios no volverán a un

website caído

• 74% de los usuarios abandonarán un

website que tarde más de 4 segundos en

cargar

• Cada segundo que tarde en cargar tu web,

pierdes un 7% de conversión, 11% menos

de page views y 16% menos en customer

satisfaction

MADRID · NOV 27-28 · 2015


OPCIÓN 3 (y mejor ):

INFRAESTRUCTURAS AUTOESCALABLES

(paga por uso, y gana en rendimiento)

MADRID · NOV 27-28 · 2015


• Todo negocio busca captar el máximo

posible de USUARIOS Y/O CLIENTES

• Por lo que tu infraestructura debe estar

preparada, porque…….

MADRID · NOV 27-28 · 2015


…… los USUARIOS pueden llegar todos de

golpe!!!

MADRID · NOV 27-28 · 2015

Mejor apostar por la

autoescalabilidad y que tu

infraestructura se adapte por sí

sola a las fluctuaciones de carga

¿Nuestra web ha salido en

Meneame?

<Demo>

…

</Demo>

MADRID · NOV 27-28 · 2015

¡Muchas Gracias!

Encontraréis esta presentación en

www.engisoftcloud.com

MADRID · NOV 27-28 · 2015

https://es.linkedin.com/in/davidregordosa

@pisukeman

[email protected]

https://es.linkedin.com/in/ttebas

@ttebas

[email protected]

ecs codemotion

Technology