Escalabilidade  e  Disponibilidade  em  Sistemas  Distribuídos  

Renato  Lucindo  DevDay  2013  

Renato  Lucindo    

       @rlucindo    

       /lucindo  

Escalabilidade  e  Disponibilidade  em  Arquiteturas  Web  

Renato  Lucindo  DevDay  2013  

Internet  

Internet  

Internet  

Internet  

Internet  

Internet  

Internet  

Escalabilidade   Disponibilidade  

Escalabilidade  

•  Habilidade  do  sistema  de  assimilar  carga  crescente  

•  Escalabilidade  VerFcal  – Adicionar  recursos  em  um  único  nó  

•  Escalabilidade  Horizontal  – Adicionar  mais  nós  ao  sistema  

Escalabilidade  

Escalabilidade  

Escalabilidade  

ParFcionamento  

Escalabilidade  

Como  encontrar  os  dados?  

Disponibilidade  

•  Habilidade  do  sistema  em  assimilar  falhas  de  soOware  e  hardware  

•  Ausência  de  ponto  único  de  falha  

Disponibilidade  

Disponibilidade  

Disponibilidade  

Réplicas  

Disponibilidade  

Como  manter  consistência?  

Evolução  de  Arquitetura  

Internet   Aplicação   Dados  

Evolução  de  Arquitetura  

Internet   Aplicação   Dados  

Cache  

Evolução  de  Arquitetura  

Internet   Aplicação   Master  

Cache  

Slave  

Evolução  de  Arquitetura  

Internet   Aplicação   Master  

Cache  

Slave  

Fila  

Aplicação  

Evolução  de  Arquitetura  

Internet   Aplicação   Master  1  

Cache  

Slave  1  

Fila  

Aplicação  

Master  2  

Slave  2  

Performance  

Cache    Fila    

PubSub    …  

Ciclo  de    “desenvolvimento  arquitetural”  

   while  True:        -­‐  Ache  o  gargalo        -­‐  Remova  o  gargalo  

Escalabilidade  –  Solução  

•  ParFcionamento  •  Sharding  –  Índice  central  – Hash  –  Índice  voláFl  

Escalabilidade  –  Solução  

Internet   Aplicação   Shard  2  

Shard  3  

Shard  1  

Escalabilidade  –  Solução  

Internet   Aplicação   Shard  2  

3   4  

1   2  

Shard  3  

Shard  1  

3   4  

1   2  

3   4  

1   2  

Disponibilidade  –  Solução  

•  Réplicas  •  Granularidade  – RAID  – Failover  – Dados  

Disponibilidade  –  Solução  

Disponibilidade  –  Solução  

Disponibilidade  –  Solução  

Disponibilidade  –  Solução  

Problemas  

Teorema  CAP  

Fonte:  hbp://blog.nosqlFps.com/2011/04/cap-­‐diagram-­‐for-­‐distribuFon.html  

Teorema  CAP  

Fonte:  hbp://blog.beany.co.kr/archives/275  

Teorema  CAP  •  Consistência:  todas  as  operações  (leituras/escritas)  resultam  num  estado  global  consistente  

•  Disponibilidade:  todas  as  requisições  (em  nós  sem  falha)  devem  ter  uma  resposta  válida  

•  Tolerância  a  Par5ção  (de  rede):  os  nós  podem  não  conseguir  se  comunicar  

Escolha  DOIS  

Teorema  CAP  

 C  +  A:  problemas  na  rede  podem  fazer  o  sistema  ficar  indisponível  

Teorema  CAP  

 C  +  P:  clientes  nem  sempre  conseguem  realizar  operações  

Teorema  CAP  

 A  +  P:  clientes  podem  ler  dados  inconsistentes  (valores  anFgos  ou  não  terminados)  

Teorema  CAP  

•  Na  práFca,  C  +  A  e  C  +  P  são  o  mesmo:  – C  +  A:  não  é  tolerante  a  parFção  de  rede  – C  +  P:  não  é  disponível  quando  uma  parFção  de  rede  ocorre  

•  Problema:  P  –  parFção  de  rede  – Mais  comum:  Latência  de  rede.  

•  Escolha  UM  – Consistência  – Disponibilidade  

Falácias  de  Sistemas  Distribuídos  

•  L.  Peter  Deutsch/Sun  –  1991  

Falácias  de  Sistemas  Distribuídos  

•  L.  Peter  Deutsch/Sun  –  1991  – The  network  is  reliable  

Falácias  de  Sistemas  Distribuídos  

•  L.  Peter  Deutsch/Sun  –  1991  – The  network  is  reliable  – Latency  is  zero  

Falácias  de  Sistemas  Distribuídos  

•  L.  Peter  Deutsch/Sun  –  1991  – The  network  is  reliable  – Latency  is  zero  – Bandwidth  is  infinite  

Falácias  de  Sistemas  Distribuídos  

•  L.  Peter  Deutsch/Sun  –  1991  – The  network  is  reliable  – Latency  is  zero  – Bandwidth  is  infinite  – The  network  is  secure  

Falácias  de  Sistemas  Distribuídos  

•  L.  Peter  Deutsch/Sun  –  1991  – The  network  is  reliable  – Latency  is  zero  – Bandwidth  is  infinite  – The  network  is  secure  – Topology  doesn’t  change  

Falácias  de  Sistemas  Distribuídos  

•  L.  Peter  Deutsch/Sun  –  1991  – The  network  is  reliable  – Latency  is  zero  – Bandwidth  is  infinite  – The  network  is  secure  – Topology  doesn’t  change  – There  is  one  administrator  

Falácias  de  Sistemas  Distribuídos  

•  L.  Peter  Deutsch/Sun  –  1991  – The  network  is  reliable  – Latency  is  zero  – Bandwidth  is  infinite  – The  network  is  secure  – Topology  doesn’t  change  – There  is  one  administrator  – Transport  cost  is  zero  

Falácias  de  Sistemas  Distribuídos  

•  L.  Peter  Deutsch/Sun  –  1991  – The  network  is  reliable  – Latency  is  zero  – Bandwidth  is  infinite  – The  network  is  secure  – Topology  doesn’t  change  – There  is  one  administrator  – Transport  cost  is  zero  – The  network  is  homogenous  

Evolução  Arquitetural  

 while  True:        -­‐  Ache  o  gargalo        -­‐  Remova  o  gargalo  

 •  Logs,  contadores,  gráficos  •  Testes:  load  &  kill  

Evolução  Arquitetural  

Load  

Evolução  Arquitetural  

Load  

$ kill -STOP …

NÃO  EXISTEM  SOLUÇÕES  PRONTAS  

Resumo  

 while  True:        -­‐  Ache  o  gargalo        -­‐  Remova  o  gargalo  

 •  Escalabilidade:  ParFção  de  dados  •  Disponibilidade:  Réplicas  •  Performance:  Cache,  Filas,  PubSub,  …  

Leia!  

Obrigado!    

       @rlucindo    

       /lucindo