O documento discute estratégias para escalar aplicações e serviços em múltiplos data centers de forma a distribuir carga, tolerar falhas e fornecer alta disponibilidade, como balanceamento de carga, replicação e particionamento de dados, cache, microserviços e DNS anycast. A arquitetura proposta utiliza vários níveis de redundância para garantir que não haja pontos únicos de falha.

1. Escalabilidade
De uma máquina para múltiplos data centers

2. Quem somos?
POA & RJ
we’re hiring!

3. 2014 FIFA World Cup Brazil
7 x 1 x
580Gbps x
0.5M usuários simultâneos x
~= 1600 anos assistidos (todos jogos)

4. Não é uma apresentação sobre
Byzantine fault, 2PC, Paxos, RAFT, Threading,
Locks, Leader election, ZAB, Consensus
problem, CRDTs, CALM, CAP theorem

5. Escalabilidade

6. Disponibilidade

7. Tolerância a falhas

8. Servidor | Nó : Físico, Container, VM

9. BananaAPP em sete dias

10. 1º dia :: criação da app
databaseappserver

11. 1º dia :: carga não suportada
[h/top, w] [iostat, vmstat] [free -m] [df -h]

12. 2º dia :: 2 servidores
appserver
database

13. 2º dia :: a parte boa
Distribuímos a carga
Podemos tunar cada servidor de forma isolada

14. 2º dia :: a parte ruim
existêm pontos de falha

15. 2º dia :: ponto de falha
app
db

16. 3º dia :: começamos com app
database
app1
app2
?
?
?

17. 3º dia :: load balancer
Para qual nó
mandar?
E quando um nó
está fora?
round-robin, least
conn, weighted ...
/health_check.html,
tcp:80, upd:8080

18. 3º dia :: exemplos de LB
http {
upstream myapp1 {
server srv1.example.com weight=3;
server srv2.example.com;
}
server {
listen 80;
location / {
proxy_pass http://myapp1;
health_check uri=/health;
}
}
}
listen appname 0.0.0.0:80
mode http
stats enable
balance leastconn
option httpclose
option forwardfor
option httpchk HEAD /health HTTP/1.1
server srv1 srv1.example.com:80 check
server srv2 srv2.example.com:80 check
NGINX HAProxy

19. 3º dia :: usuário sem sessão
Nginx: sticky cookie srv_id expires=1h domain=.example.com path=/;
HAProxy: cookie srv_id insert indirect nocache
database redis, memcache, mongo…

20. 4º dia :: até agora
loadbalancer
database
app1
app2
memcached
redis ...

21. 4º dia :: pontos de falhas
loadbalancer
database
memcached
redis ...
Precisamos tolerar falhas

22. 5º dia :: Load Balancer (virtual ip)

23. 5º dia :: banco de dados
ABCD
C B
D A
B (B,C) C (C,A)
A (A,D) D (D,B)
Particionamento ReplicaçãoOriginal

24. 5º dia :: mongo

25. 5º dia :: cassandra

26. 5º dia :: melhorias
lb1 lb2
app1
app2
app3
appn
DB
Session
db1 db2
db3 db4
s1 s2

27. 5º dia :: + cache
lb1 lb2
app1
app2
app3
appn
DB
Session
db1 db2
db3 db4
s1 s2
Cache
c1
c2
c3

28. 5º dia :: exemplo de caching
proxy_cache_path /data/nginx/cache keys_zone=one:10m;
http {
upstream myapp1 {
server srv1.example.com;
server srv2.example.com;
}
server {
listen 80;
proxy_cache one;
location / {
proxy_cache_valid any 1m;
proxy_pass http://myapp1;
}
}
}
NGINX
lb1 lb2
a1
a2
Cache
c1
c2

29. 5º dia :: + microservices
Várias aplicações (API's)
Vendas
n1
c1 c1
n1
Busca
n1
c1 c1
n1
Recomendação
n1
c1
n1
Social
n1
c1 c1
n1n1
c1
n1
c1
“Monolítica”
app:
- Vendas
- Busca
- Recom.
- Social
- Transp.

30. 5º dia :: revisando
LB
lb1
lb2
UI Vendas
UI Vendas
DB
Session
db1 db2
db3 db4
s1 s2
Cache
l1
l2
l3
API
API
BigDataBuzz
h a d
Recomendação
Busca
Social

31. 5º dia :: um único data center...

32. 6º dia :: multihoming
replicação de dados
ilusão de ponto único

33. 6º dia :: replicação de dados
master / backup
master / master
2PC

34. 6º dia :: modelo master / backup
● assíncrono
● baixa latência
● alto throughput
● consistência eventual
● escrita só master

35. 6º dia :: modelo master / master
● assíncrono
● [média|alta] latência
● alto throughput
● cons. [eventual|forte]
Paxos
RAFT

36. 6º dia :: modelo 2PC
● no merges● síncrono
● alta latência
● médio throughput
● consistência forte
aceite
aceite
proposta
proposta
commit
commit

37. 6º dia :: database
Cassandra foi concebido com esse intuito

38. 6º dia :: única entrada n saídas

39. 6º dia :: anycast
NET Oi
Tim
Globo
Anúncio: (BGP)
res: 1.1.1.0/24
NET Oi
Tim
Globo
Anúncio: (BGP)
res: 1.1.1.0/24
1.1.1.2

40. 6º dia :: GSLB (Global Server Load Balancing)
banana.com
1.1.1.1
1.1.1.2
DNS ISP
ROOT
N th
GSLB
RTT | health check
DNS caching
RTT (latency)
DNS ISP diff. loc.
$$$ & Marketing

41. 6º dia :: GSLB multiples A records
$ dig a www.youtube.com

42. 6º dia :: GSLB multiples A records
não sabemos como yt funciona

43. 6º dia :: ping do BR para ...

44. 6º dia :: Cloud DNS/GSBL thing

45. 7º dia: you shall rest

46. BR-DKC101
Resumindo...
l
b
1
l
b
2
a
p
p
1a
p
p
2a
p
p
3
a
p
p
n
DB
Session
d
b
1
d
b
2d
b
3
d
b
4
s
2
Cach
ingc
1
c
2
c
3
s
1
US-DKC102
l
b
1
l
b
2
a
p
p
1a
p
p
2a
p
p
3
a
p
p
n
DB
Session
d
b
1
d
b
2d
b
3
d
b
4
s
2
Cach
ingc
1
c
2
c
3
s
1
JP-DKC103
l
b
1
l
b
2
a
p
p
1a
p
p
2a
p
p
3
a
p
p
n
DB
Session
d
b
1
d
b
2d
b
3
d
b
4
s
2
Cach
ingc
1
c
2
c
3
s
1
difícil
no silver bullet
sucesso

47. enquanto isso nas nuvens...

48. Bônus - Docker (docker-compose)

49. Bônus - Vagrant

50. Bônus - não confie em benchmarks

51. Links
Perguntas?
slideshare.net/leandro_moreira
twitter.com/lucasmundim
leandromoreira.com.br
Obrigado!!!

52. Referências
● https://f5.com/glossary/load-balancer
● http://leandromoreira.com.br/2015/04/26/fifa-2014-world-cup-live-stream-architecture/
● http://leandromoreira.com.br/2014/11/20/how-to-start-to-learn-high-scalability/
● http://nginx.org/en/docs/http/load_balancing.html
● https://www.digitalocean.com/community/tutorials/how-to-use-haproxy-to-set-up-http-load-balancing-on-an-ubuntu-vps
● https://academy.datastax.com/courses/
● http://en.wikipedia.org/wiki/Single_point_of_failure
● http://book.mixu.net/distsys/single-page.html
● https://www.howtoforge.com/high-availability-load-balancer-haproxy-heartbeat-debian-etch-p2
● http://docs.mongodb.org/manual/core/sharding-introduction/
● http://docs.mongodb.org/manual/core/replication-introduction/
● http://nginx.com/resources/admin-guide/caching/
● https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=en
● http://martinfowler.com/articles/microservices.html
● http://www.netflix.com/title/70140358
● http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html
● http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html
● http://docs.mongodb.org/manual/tutorial/deploy-shard-cluster/

53. Referências
● https://aphyr.com/tags/Distributed-Systems
● http://pbs.cs.berkeley.edu/pbs-vldb2012.pdf
● http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36737.pdf
● http://blog.empathybox.com/post/19574936361/getting-real-about-distributed-system-reliability
● https://www.usenix.org/legacy/events/nsdi06/tech/full_papers/freedman/freedman.pdf
● http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/35590.pdf
● http://tech.3scale.net/2014/06/18/redis-sentinel-failover-no-downtime-the-hard-way/
● http://www.slideshare.net/gear6memcached/implementing-high-availability-services-for-memcached-1911077
● http://docs.couchbase.com/moxi-manual-1.8/
● http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html
● http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/35590.pdf
● http://static.googleusercontent.com/media/research.google.com/en//archive/chubby-osdi06.pdf
● http://the-paper-trail.org/blog/distributed-systems-theory-for-the-distributed-systems-engineer/
● http://nil.csail.mit.edu/6.824/2015/papers/paxos-simple.pdf
● http://the-paper-trail.org/blog/consensus-protocols-paxos/
● donkeykong.com
● zelda.com
● http://backreference.org/2010/02/01/geolocation-aware-dns-with-bind/
● http://www.tenereillo.com/GSLBPageOfShame.htm
● http://backreference.org/2010/02/01/geolocation-aware-dns-with-bind/