1 of 39

1

2 of 39

Scalability

Basics, application to systems, teams and processes

3 of 39

Hello!

I am Fran Ortiz

@fortiz2305

I am Edu Ferro

@eferro

https://www.eferro.net

3

4 of 39

What is scalability?

Wikipedia’s definition

Scalability: Capability of a system to handle a growing amount of work by adding resources to the system.�

Mathematical definition

Function, with size or load on the X axis, and throughput on the Y axis.

4

Nosotros nos vamos a centrar a partir de ahora en la definición de escalabilidad como función, hay una relación entre dos variables, donde una depende del valor del valor de la entrada (input y output).

Veremos como el throughput es dependiente de la carga o el tamaño que tiene el sistema.

Importante: aunque nos vayamos a centrar en la definición matemática, no habrá mucha matemática ni ningún requisito para la charla. Lo que queremos transmitir es una serie de modelos mentales que nos proporcionen algo de intuición

Otros posibles inputs:

Concurrencia
Número de requests
Tasa de llegada
Tamaño de equipo

Definicion de escalabilidad�Es una función

Load: -> Cost -> number of node-> Team size -> company size

Throughput : num transacciones/s bytes/s Served, Num operaciones/s

No es lo mismo performance

Performance -> Wait time (desde el punto de vista del usuario)

Un algoritmo puede ser escalable, y tener un mal rendimiento. Es muy típico, un algoritmo no paralelo suele tener mucho mejor rendimiento, hasta un punto, el problema es que típicamente a partir de un punto no pude ir más rápido o tener más carga

5 of 39

Scalability vs. Performance

5

Performance measures the speed/latency of a single request.

Scalability measures the ability of a system to handle a growing amount of work.

6 of 39

6

7 of 39

Linear Scalability

Ideal case

7

1

8 of 39

Linear Scalability

Ideal case: throughput increases linearly with load.
Examples:

100 operations/s with 1 node -> 400 operations/s with 4 nodes.
Adding people to an organisation, the organisational capacity to do work increases linearly with the number of people.

8

9 of 39

Linear Scalability: ideal case

9

Throughput increases linearly with load.

10 of 39

10

11 of 39

Amdahl’s Law

Contention factor

11

2

12 of 39

Contention factor

Contention factor measures the effect of waiting or queueing for shared resources.

12

13 of 39

Amdahl’s Law: contention factor

13

Contention factor: measures the effect of waiting or queueing for shared resources.

14 of 39

14

0% 1% 2% 5%

15 of 39

Contention factor: examples

Teams

Centralized tasks/processes

Systems�

Monolith infrastructure
Optimization engines

15

Centralized tasks/processes

-> Tareas y conocimiento especializado dependiente de un reducido grupo de personas

-> DB migrations

-> deployments

-> decisiones técnicas importantes

-> identificado silos y bottlenecks / identificacion cultura de heroes

-> automatizacion y el selfservice (como requisito a la automatizacion) (DB migrations, transalations, creacion servicios mejorable)

-> trabajo explícito por eliminar silos, pairing, tech concerns a nivel de squad y generales

Monolith infrastructure

-> <10 clientes. 1 Operacion (calculo) al dia -> 1 EC2 -> 1xcliente EC2

-> Contencion para integracion/pruebas/ajustes (computacion)

-> k8s contencion por computacion eliminada (hasta un punto)

-> Actualmente BD como contencion/bottleneck para el siguiente paso de escalabilidad

Optimization Engines -> siguiente

16 of 39

Nextail Optimization engine

16

17 of 39

Universal Scalability�Law (USL)

Coherence factor

17

3

18 of 39

Coherence factor

Coherence factor refers to the time spent restoring a common view of the world or getting an agreement across different processors.

18

19 of 39

The Universal Scalability Law

19

Coherence factor

Contention factor

😭

20 of 39

Why is coherency quadratic?

N workers = N(N-1) pairs of interactions.

20

21 of 39

USL: examples

Teams

Very large teams�
Minimize team dependencies

Systems�

Nextail BI Subsystem

21

Very large teams

-> Equipos muy grandes. factor de coherencia alto, se pierde la velocidad -> coordination overhead (N²)

-> Solución? división en equipos más pequeños con responsabilidades bien definidas y con responsabilidad end-to-end. Se reduce la necesidad de sincronización continua. Se habla menos, con más abstracción.

Minimize team dependencies

-> plataforma self service

-> toma decisiones más descentralizada

-> division modulos/funcionalidades por squad

-> desacoplamiento de lo posible

-> Criterios de aceptacion

-> tech concerns

-> RFCs / RFKs

Nextail BI Subsystem

-> Scheduler escalable en horizontal (sharding, eventos)

-> Permite gestionar colas (y definir esas colas en base al punto de contencion que tiene cada trabajo)

-> Permite reducir contencion, haciendo dinamico el compute, pero teniendo en cuenta los bottlenecks para no saturar un punto de contención

22 of 39

Nextail BI Subsystem

22

Nextail BI Subsystem

BI: proceso donde se realizan una serie de agregaciones/cálculos sobre datos que nos pasa el cliente (ventas, stocks…)

-> Proceso secuencial: un tipo de dato detrás de otro. Algunos de ellos son dependientes, otros no

-> 1er paso: identificar qué tipos de datos se pueden agregar/calcular en paralelo. Mediante eventos empezamos cada cálculo tan pronto como es posible.

-> En ese punto tenemos muchos procesos en paralelo, el factor de contención disminuye bastante. A partir de ahí, decisiones para que el factor de coherencia no aumente, que los procesos en paralelo no se tengan que comunicar entre ellos. Algunas de esas decisiones: hay un cálculo que depende de que terminen dos de los procesos en paralelo, se ejecuta cada vez que termina cada uno de ellos, pero no queremos que se tengan que comunicar, guardar estado, etc.

-> Durante este proceso, también se ha producido un cambio de tecnología que nos ha reducido bastante el factor de contención: Aurora to Redshift (por el tipo de queries es mucho más óptima), no pasamos tiempo esperando por BBDD

23 of 39

Nextail BI Subsystem

23

Nextail BI Subsystem

BI: proceso donde se realizan una serie de agregaciones/cálculos sobre datos que nos pasa el cliente (ventas, stocks…)

-> Proceso secuencial: un tipo de dato detrás de otro. Algunos de ellos son dependientes, otros no

-> 1er paso: identificar qué tipos de datos se pueden agregar/calcular en paralelo. Mediante eventos empezamos cada cálculo tan pronto como es posible.

-> En ese punto tenemos muchos procesos en paralelo, el factor de contención disminuye bastante. A partir de ahí, decisiones para que el factor de coherencia no aumente, que los procesos en paralelo no se tengan que comunicar entre ellos. Algunas de esas decisiones: hay un cálculo que depende de que terminen dos de los procesos en paralelo, se ejecuta cada vez que termina cada uno de ellos, pero no queremos que se tengan que comunicar, guardar estado, etc.

-> Durante este proceso, también se ha producido un cambio de tecnología que nos ha reducido bastante el factor de contención: Aurora to Redshift (por el tipo de queries es mucho más óptima), no pasamos tiempo esperando por BBDD

24 of 39

Queueing Theory

24

4

25 of 39

Queueing Theory

25

😭

😉

Source: Queueing Theory in Practice

26 of 39

Queues

> 80% utilization -> rapid degradation
100% utilization -> inf waiting time

Three regimes:

everything is okay
Oh wait
F**k

26

27 of 39

27

28 of 39

28

High variability

Low variability

29 of 39

Queuing: examples

Teams

Operations team vs each team has operations
Front/Back teams vs End to End teams

Systems�

From monoqueue to multi queue

29

30 of 39

Little’s Law

30

31 of 39

Little’s Law: examples

Teams/Processes

WIP limits in each team
Flow optimization (instead of resource optimization)
Self-service platform (no ops team)

31

32 of 39

Conclusions

32

5

33 of 39

Mental models

Linear scalability
Amdahl’s Law
Universal Law of scalability
Queueing Theory
Little’s law

33

34 of 39

Think about scalability

Nextail

Design to support x2 size / x10 clients
Think about x20 (size/clients)
Imagine/Brainstorm x100 (size/clients)

34

35 of 39

35

36 of 39

36

37 of 39

References

Scalability is Quantifiable: The Universal Scalability Law, Baron Schwartz
Queueing Theory in Practice, Eben Freeman
Coherence Penalty for Humans, Michael Nygard
Applying the USL to Organizations, Adrian Colyer
Applying the USL to Distributed Systems, Neil J. Gunther
Applied Performance Theory, Kavya Joshi
Super Sizing Your Servers and the Payback Trap, Neil J. Gunther

37

38 of 39

Thanks!

Any questions ?

You can find us at

@eferro
@fortiz2305

38

39 of 39

39