Porque o Google (quase)      sempre responde as minhas              perguntas?Fernanda G WeidenSite Reliability EngineerCl...
Missão"to organize the worlds 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 software   o pouca instrumentação, se existente• Dimensionamento de hardware  o basead...
Ooops...
Site Reliability Engineering• "hope is not a strategy"  o   se você pensa que pode quebrar, provavelmente vai  o   se você...
Reliability by Wikipedia "Ability of a person or system to perform and maintain its  functions in routine circumstances, a...
Site Reliability Engineering• 50% sysadmins, 50% engenheiros de software• Acesso completo ao código fonte   o participação...
Site Reliability Engineering• Código fonte é tudo   o código controlado   o builds e rollouts automatizados• Sistema de re...
Números que todos engenheir@s decomputação deveria saber...L1 cache reference                           0.5 nsBranch mispr...
Filosofia de hardware no Google•   Eficiência em consumo de energia•   Datacenters com alta densidade de uso•   Software d...
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 ...
Google cluster• 1000s máquinas, poucas configurações• Sistema de arquivos (GFS) + Cluster scheduling system• Geralmente 10...
Redundância e failover• Deployment: N+2   o com crescimento de N, overhead por redundância diminui      (%)   o separação ...
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 det...
• Reliability faz parte do processo de design,  desenvolvimento e deployment de um serviço.• Assim como não existe queijo ...
Perguntas?Não se acanhe!Muito provavelmente sua pergunta será respondida :-)Fernanda G Weiden <nanda@google.com>
Estratégias de escablabilidade para serviços online
Upcoming SlideShare
Loading in...5
×

Estratégias de escablabilidade para serviços online

460

Published on

Estratégias de escablabilidade para serviços online - Fernanda Weiden (Google)

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
460
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Estratégias de escablabilidade para serviços online

  1. 1. Porque o Google (quase) sempre responde as minhas perguntas?Fernanda G WeidenSite Reliability EngineerCluster Management
  2. 2. Missão"to organize the worlds information and make it universally accessible and useful"
  3. 3. O que o Google faz?e muito mais...
  4. 4. O que está por trás disso tudo?
  5. 5. 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
  6. 6. Ooops...
  7. 7. 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"
  8. 8. 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."
  9. 9. 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
  10. 10. 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
  11. 11. Números que todos engenheir@s decomputação deveria saber...L1 cache reference 0.5 nsBranch mispredict 5 nsL2 cache reference 7 nsMutex lock/unlock 100 nsMain memory reference 100 nsCompress 1K bytes with Zippy 2,500 nsSend 2K bytes over 1 Gbps network 20,000 nsRead 1 MB sequentially from memory 250,000 nsRound trip within same datacenter 500,000 nsDisk seek 10,000,000 nsRead 1 MB sequentially from network 10,000,000 nsRead 1 MB sequentially from disk 30,000,000 nsSend packet CA->Netherlands->CA 150,000,000 ns
  12. 12. 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
  13. 13. 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 comeback)~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 connectivitylosses)~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.
  14. 14. 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
  15. 15. 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
  16. 16. Balanceamento de carga multi-layer
  17. 17. 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
  18. 18. • 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...
  19. 19. Perguntas?Não se acanhe!Muito provavelmente sua pergunta será respondida :-)Fernanda G Weiden <nanda@google.com>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×