Apresentação do Artigo Web Search for a Planet: The Google Cluster Architecture Publicado em IEEE Micro Março 2003, pg.22-28 Luiz A.Barroso, Jeffrey Dean, Urs Hölze Frank Juergen Knaesel fknaesel@inf.ufsc.br
Introdução/Motivação Poucos web services necessitam tanto poder computacional quanto um sistema de busca Em média, cada query realizada no Google lê centenas de Mbytes e consome dezenas de bilhões de ciclos de CPU Para atender a esta demanda, é necessária uma infraestrutura comparada à das instalações dos maiores supercomputadores do planeta
Web Search for Planet Introdução/Motivação Combinando mais de 15000 COTS (Commercial Off-The-Shelf) com tolerância a falhas implementada no nível do software, foi criada uma solução que possui custobenefício mais atraente do que as soluções feitas com poucos computadores de alto custo/desempenho.
Objetivo Apresentar como a fragmentação/replicação (paralelização) de um BD (Banco de Dados) pode proporcionar alta disponibilidade e alto desempenho nas aplicações que fazem uso deste.
Overview da Arquitetura Google A arquitetura Google fornece confiabilidade em software, ao invés de hardware: Desta forma podem ser utilizados COTS, que custam muito mais barato do que as soluções de confiabilidade baseadas em hardware Os índices de busca são particionados: As queries podem rodar em múltiplos processadores. Assim, não é necessário ter performance máxima em um único processador.
Overview da Arquitetura Google A confiabilidade/alta disponibilidade dos web services do Google foi feita no nível de software, efetuando a replicação dos serviços em máquinas diferentes, detectando e manipulando falhas de forma automática.
Servindo uma Query Quando um usuário entra com uma query, o browser do usuário faz primeiro uma busca DNS para resolver o domínio para um endereço IP em particular. Para fornecer capacidade suficiente para manipular o tráfego de queries, existem vários clusters distribuídos geograficamente. Cada cluster possui mais de 1000 máquinas e a configuração geográfica distribuída provê proteção contra falhas catastróficas do data center (terremotos, longos períodos sem energia, etc...).
Servindo uma Query Um sistema de balanceamento de carga baseado em DNS seleciona um cluster pela proximidade geográfica do usuário com o cluster físico. Além disso, o sistema de balanceamento de carga considera a capacidade disponível nos clusters para minimizar o tempo de resposta. Depois disto o browser do usuário envia uma requisição HTTP para um destes clusters e a query é processada localmente.
Servindo uma Query No cluster local, um segundo sistema balanceador de carga monitora o conjunto disponível de GWS (Google Web Servers) para servir a query. Depois de receber uma query, o GWS coordena a execução da query e formada os resultados em uma resposta para o browser do usuário.
Servindo uma Query
Parte 1 Primeiramente, os servidores de índice (que são particionados para diminuição da carga e paralelização da query) consultam um índice invertido que mapeia cada palavra para uma lista de documentos selecionados (hit list). Os servidores então fazem a intersecção das hit lists encontradas para determinar um conjunto de documentos relevantes para a query e calculam uma pontuação que será utlizada para ordenar os resultados.
Parte 1 Desafio: Os documentos originais compreendem algumas dezenas de TBytes, enquanto os índices invertidos também é da ordem de alguns TBytes Felizmente, a pesquisa é altamente paralelizada dividindo os índices em pedaços, cada um deles contendo um subconjunto randômico do índice global. Para cada pedaço do índice, existe um conjunto de máquinas destinadas a serví-lo.
Parte 1 Cada requisição escolhe uma máquina dentro do conjunto utilizando um sistema balanceador de carga intermediário. Se uma destas máquinas "cai", o balanceador de carga redireciona automaticamente a requisição para outra máquina (interrupção do nodo e redução da capacidade).
Parte 1 De qualquer sorte, o sistema permanece ininterrupto e todas as partes do índice continuam disponíveis, porque cada uma destas partes do índice estão replicadas em vários outros servidores. O resultado final da primeira parte da execução da query é uma lista ordenada de identificadores de documentos
Parte 2 A segunda parte da execução da query envolve o processo de pegar esta lista ordenada de identificadores e obter a partir dela, o título e a url destes documentos (doc servers). Os "doc servers" devem ter acesso online a uma cópia de baixa latência de toda a Web. De fato, devido a replicação necessária para performance e alta disponibilidade dos serviços, o Google armazena dezenas de cópias da Web em seus clusters.
Parte 2 Assim como na fase de busca aos índices dos documentos (index servers), a estratégia e particionar o processamento deste processo pela: distribuição randômica dos documentos em pedaços menores (paralelização) possuir múltiplas réplicas para manipulação e alta disponibilidade de cada pedaço roteamento de requisições através de um sistema de balanceamento de carga
Outras Tarefas Complementando a fase de busca aos index servers e aos doc servers, o GWS também efetua: verificação e sugestão ortográfica sistema de anúncios relevantes à query Depois de concluídas cada uma das fases, o GWS gera a página HTML e a devolve ao usuário.
Replicação Alta Disponibilidade/Tolerância a Falhas O acesso aos índices e outras estruturas de dados é feita somente para leitura. Atualização não ocorrem com freqüência Execução de atualizações através do desvio das queries Particionamento dos índices x fusão barata Speed-up linear