O documento discute como a engenharia de site reliability (SRE) do Google garante a confiabilidade dos serviços da empresa. A SRE envolve engenheiros de software trabalhando junto com administradores de sistemas para garantir redundância, dimensionamento adequado, monitoramento e processos de lançamento de software que permitam os serviços sobreviverem a falhas. A confiabilidade é fundamental no design, desenvolvimento e implantação de serviços do Google.

1. Porque o Google (quase)
sempre responde as minhas
perguntas?
Fernanda G Weiden
Site Reliability Engineer
Cluster Management

2. Missão
"to organize the world's information and make it
universally accessible and useful"

3. O que o Google faz?
e muito mais...

4. O que está por trás disso tudo?

6. Sysadmin na indústria...
• Black-box software
o pouca instrumentação, se existente
• Dimensionamento de hardware
o baseado nas necessidades do software
o impulsionado por fornecedores
• Monitoramento
o Reação a falhas e imprevistos

7. Ooops...

8. Site Reliability Engineering
• "hope is not a strategy"
o se você pensa que pode quebrar, provavelmente vai
o se você pensa que não vai quebrar, definitivamente vai
o de uma maneira que você não pensou
o espetacular e "bizarramente"

9. Reliability by Wikipedia
"Ability of a person or system to perform and maintain its
functions in routine circumstances, as well as hostile or
unexpected circumstances."

10. Site Reliability Engineering
• 50% sysadmins, 50% engenheiros de software
• Acesso completo ao código fonte
o participação em revisão de design
• PRR
• Instalação
o dimensionamento “job” - CPU, RAM, disk, network
• Capacity Planning
o crescimento orgânico, mudanças de infraestrutura,
lançamento de funcionalidades
• Monitores/alertas
• Gerenciamento de clusters
• Lançamento de software
• Engenharia de software

11. Site Reliability Engineering
• Código fonte é tudo
o código controlado
o builds e rollouts automatizados
• Sistema de revisão em par
o estritos critérios de aceitação
o guias de estilo, testes de pre-submit
o subject ownership/expertise
• Processo flexível: time, experts
• Engineering driven (not management)
o Critérios técnicos prevalecem

12. Números que todos engenheir@s de
computação deveria saber...
L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns
Mutex lock/unlock 100 ns
Main memory reference 100 ns
Compress 1K bytes with Zippy 2,500 ns
Send 2K bytes over 1 Gbps network 20,000 ns
Read 1 MB sequentially from memory 250,000 ns
Round trip within same datacenter 500,000 ns
Disk seek 10,000,000 ns
Read 1 MB sequentially from network 10,000,000 ns
Read 1 MB sequentially from disk 30,000,000 ns
Send packet CA->Netherlands->CA 150,000,000 ns

13. Filosofia de hardware no Google
• Eficiência em consumo de energia
• Datacenters com alta densidade de uso
• Software deve sobreviver outages planejados ou não
• Replique serviços inteiros, e não componentes de hardware

14. Um ano na vida de um cluster...
~0.5 overheating (power down most machines in <5 mins, ~1-2 days to recover)
~1 PDU failure (~500-1000 machines suddenly disappear, ~6 hours to come
back)
~1 rack-move (plenty of warning, ~500-1000 machines powered down, ~6 hours)
~1 network rewiring (rolling ~5% of machines down over 2-day span)
~20 rack failures (40-80 machines instantly disappear, 1-6 hours to get back)
~5 racks go “wonky” (40-80 machines see 50% packet loss)
~8 network maintenances (4 might cause ~30-minute random connectivity
losses)
~12 router reloads (takes out DNS and external vips for a couple minutes)
~3 router failures (have to immediately pull traffic for an hour)
~dozens of minor 30-second blips for dns
~1000 individual machine failures
~thousands of hard drive failures
... slow disks, bad memory, misconfigured machines, flaky machines, etc.

15. Google cluster
• 1000s máquinas, poucas configurações
• Sistema de arquivos (GFS) + Cluster scheduling system
• Geralmente 100s a 1000s de jobs ativos
o alguns com 1 task, outros com 1000s

16. Redundância e failover
• Deployment: N+2
o com crescimento de N, overhead por redundância diminui
(%)
o separação de dados de usuários e/ou aplicação
• Utilize balanceamento de carga como mecanismo de
failover
o desvia tráfego para outro cluster automaticamente
• Evita downtime de manutenção desviando tráfego

17. Balanceamento de carga multi-layer

18. Map reduce
• MapReduce
o Lê um monte de dados
o Mapeia: extrai somente a parte dos dados que são
interessante para determinado processo
o Shuffle e Sort
o Reduzir: agrega, resume, filtra ou transforma
o Escreve os resultados

19. • Reliability faz parte do processo de design,
desenvolvimento e deployment de um serviço.
• Assim como não existe queijo demais em pizza, não existe
redundância demais em serviços. Quanto mais 9s, melhor!
E ainda assim, nós somente quase sempre
respondemos suas perguntas...

20. Perguntas?
Não se acanhe!
Muito provavelmente sua pergunta será respondida :-)
Fernanda G Weiden <nanda@google.com>