Estratégias de escablabilidade para serviços online
Upcoming SlideShare
Loading in...5
×
 

Estratégias de escablabilidade para serviços online

on

  • 665 views

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

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

Statistics

Views

Total Views
665
Views on SlideShare
657
Embed Views
8

Actions

Likes
0
Downloads
4
Comments
0

4 Embeds 8

http://blogdoguto.sublimeds.com 4
http://flavors.me 2
http://mezura.com.br 1
http://gutocosta.flavors.me 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Estratégias de escablabilidade para serviços online Estratégias de escablabilidade para serviços online Presentation Transcript

    • Porque o Google (quase) sempre responde as minhas perguntas?Fernanda G WeidenSite Reliability EngineerCluster Management
    • 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 baseado nas necessidades do software o impulsionado por fornecedores• Monitoramento o Reação a falhas e imprevistos
    • Ooops...
    • 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"
    • 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 é 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
    • 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
    • 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 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.
    • 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 failover o 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 transforma o 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>