Porque o Google (quase) sempre responde as minhas

perguntas?

Fernanda G WeidenSite Reliability EngineerCluster Management

Missão

"to organize the world's information and make it universally accessible and useful"

O que o Google faz?

e muito mais...

O que está por trás disso tudo?

Sysadmin na indústria...

• Black-box softwareo pouca instrumentação, se existente

• Dimensionamento de hardwareo baseado nas necessidades do softwareo impulsionado por fornecedores

• Monitoramentoo Reação a falhas e imprevistos

Ooops...

Site Reliability Engineering

• "hope is not a strategy"o se você pensa que pode quebrar, provavelmente vaio se você pensa que não vai quebrar, definitivamente vaio de uma maneira que você não pensouo espetacular e "bizarramente"

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."

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

Site Reliability Engineering

• Código fonte é tudoo código controladoo builds e rollouts automatizados

• Sistema de revisão em par o estritos critérios de aceitação o guias de estilo, testes de pre-submito subject ownership/expertise

• Processo flexível: time, experts• Engineering driven (not management)

o Critérios técnicos prevalecem

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

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

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.

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

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 failovero desvia tráfego para outro cluster automaticamente

• Evita downtime de manutenção desviando tráfego

Balanceamento de carga multi-layer

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 transformao Escreve os resultados

• 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...

Perguntas?

Não se acanhe! Muito provavelmente sua pergunta será respondida :-)

Fernanda G Weiden <nanda@google.com>