Por quase 20 anos, o Google fornece sistemas inimaginavelmente complexos e de grande escala, sensíveis às solicitações dos usuários. O mecanismo de pesquisa do Google encontra a resposta para todas as perguntas em uma fração de segundo, o Google Maps com a mais alta precisão reflete o cenário terrestre, e o Google Mail está disponível no modo 365/24/7 e, em essência, se tornou o primeiro armazenamento em nuvem pública. Esses sistemas são perfeitos? Não, eles também falham, quebram e se tornam obsoletos, como qualquer equipamento. Nós simplesmente não percebemos. O fato é que há mais de dez anos, o Google desenvolve a exclusiva tecnologia de Engenharia de confiabilidade do site, que garante operação ininterrupta e desenvolvimento progressivo de sistemas de software de qualquer complexidade. Este livro é um depósito de experiência acumulada pelo Google ao longo de muitos anos, o trabalho coletivo de muitos especialistas destacados e um recurso indispensável para qualquer engenheiro que queira desenvolver e manter qualquer produto com a mais alta qualidade e com mais eficiência.
SRE do Google em termos de SRE
Os data centers do Google (data centers) são significativamente diferentes dos data centers tradicionais e de "farms" de pequenos servidores. Essas diferenças introduzem problemas adicionais e oportunidades adicionais. Este capítulo discute os desafios e oportunidades específicos dos data centers do Google e apresenta a terminologia que será usada ao longo do livro.
EquipamentoA maioria dos recursos de computação do Google está localizada em data centers projetados pela empresa, que possuem sistema de fornecimento de energia, sistema de refrigeração, rede interna e equipamentos de computação [Barroso et al., 2013]. Ao contrário dos datacenters típicos fornecidos pelos fornecedores aos seus clientes, todos os datacenters do Google estão equipados com o mesmo1. Para evitar confusão entre o hardware e o software do servidor, neste livro, usamos a seguinte terminologia:
- máquina (computador) - uma unidade de equipamento (ou, possivelmente, uma máquina virtual);
- servidor - uma unidade de software que implementa um serviço.
Qualquer servidor pode ser iniciado em máquinas, portanto, não alocamos computadores específicos para programas de servidor específicos. Por exemplo, não temos uma máquina específica na qual o servidor de correio esteja em execução. Em vez disso, os recursos são alocados pelo nosso sistema de gerenciamento de cluster Borg.
Entendemos que esse uso do termo "servidor" não é padrão. É mais comum designar dois conceitos ao mesmo tempo: um programa que serve conexões de rede e, ao mesmo tempo, uma máquina que executa esses programas, mas quando falamos sobre o poder computacional do Google, a diferença entre os dois é significativa. Assim que você se acostumar com a nossa interpretação da palavra "servidor", ficará mais claro para você por que é importante usar essa terminologia especializada, não apenas diretamente no Google, mas ao longo deste livro.
Na fig. 2.1 demonstrou a configuração do data center do Google.
- Dezenas de carros são colocados nas prateleiras.
- As prateleiras estão em fileiras.
- Uma ou mais linhas formam um cluster.
- Geralmente, na construção de um data center (DPC), ou data center, vários clusters estão localizados.
- Vários edifícios de data center próximos uns dos outros compõem o campus.
Dentro de cada data center, todas as máquinas devem poder se comunicar efetivamente entre si, por isso criamos um switch virtual (switch) muito rápido com dezenas de milhares de portas. Isso foi possível conectando centenas de switches desenvolvidos pelo Google em uma “fábrica” baseada na topologia da rede Clos [Clos, 1953], chamada Jupiter [Singh et al., 2015]. Na sua configuração máxima, o Jupiter suporta taxa de transferência de 1,3 Pb / s entre servidores.
Os data centers são conectados entre si usando nossa rede global de backbone B4 [Jain et al., 2013]. O B4 possui uma arquitetura de rede configurável por software e usa o protocolo de comunicação aberta OpenFlow. B4 fornece ampla largura de banda a um número limitado de sistemas e usa controle flexível de largura de canal para maximizar seu valor médio [Kumar et al., 2015].
Software de sistema que "organiza" o equipamento
O software que fornece o gerenciamento e administração de nossos equipamentos deve ser capaz de lidar com sistemas enormes. Falhas de hardware são um dos principais problemas resolvidos com a ajuda do software. Dado o grande número de componentes de hardware em um cluster, eles acontecem com bastante frequência. Em cada cluster, milhares de máquinas geralmente falham em um ano e milhares de discos rígidos falham. Se você multiplicar esse número pelo número de clusters que operam em todo o mundo, o resultado é impressionante. Portanto, queremos isolar os usuários de tais problemas, e as equipes envolvidas em nossos serviços também não querem se distrair com problemas de hardware. Cada campus do data center possui equipes responsáveis pelo suporte ao equipamento e à infraestrutura do data center.
Gerenciamento de máquinas
Borg (Figura 2.2) é um sistema de gerenciamento de cluster distribuído [Verma et al., 2015], semelhante ao Apache Mesos. A Borg gerencia trabalhos em nível de cluster.
Borg é responsável pelo lançamento de trabalhos do usuário. Essas tarefas podem ser serviços em execução constante ou processos em lote como o MapReduce [Dean e Ghemawat, 2004]. Eles podem consistir em várias (às vezes milhares) de tarefas idênticas (tarefas) - por motivos de confiabilidade e porque um processo, via de regra, não é capaz de processar todo o tráfego do cluster. Quando Borg inicia a tarefa, ele encontra as máquinas para executar suas tarefas e ordena que iniciem o programa do servidor. Borg então monitora o status dessas tarefas. Se a tarefa não funcionar corretamente, ela será destruída e reiniciada, possivelmente em outra máquina.
Como as tarefas são distribuídas livremente entre máquinas, não podemos usar endereços IP e números de porta para acessá-los. Esse problema é resolvido por um nível adicional de abstração: ao iniciar uma tarefa, o Borg aloca um nome para a tarefa e um número (índice) para cada tarefa usando o serviço de nomes Borg (BNS). Em vez de usar o endereço IP e o número da porta, outros processos se associam às tarefas da Borg pelo nome do BNS, que depois converte o BNS em endereço IP e número da porta. Por exemplo, o caminho do BNS pode ser uma sequência como / bns / <cluster> / <user> / <task_name> / <task_number>, que é então traduzida (é comum dizer "permitido" nas redes) no formato <endereço IP>: <port> .
Borg também é responsável pela alocação de recursos para atribuições. Cada tarefa deve indicar quais recursos são necessários para concluí-la (por exemplo, três núcleos de processador, 2 GB de RAM). Usando a lista de requisitos para todas as tarefas, o Borg pode distribuir tarefas de maneira ideal entre máquinas, levando em consideração as considerações de tolerância a falhas (por exemplo, o Borg não iniciará todas as tarefas de uma tarefa no mesmo rack, pois a troca desse rack será um ponto crítico em caso de falha) tarefas).
Se uma tarefa tenta pegar mais recursos do que o solicitado, a Borg a destrói e reinicia (já que geralmente é preferível ter uma tarefa que às vezes falha e reinicia do que não é reiniciada).
Armazenamento
Para acesso mais rápido aos dados, as tarefas podem usar o disco local das máquinas, mas temos várias opções para organizar o armazenamento persistente no cluster (e mesmo os dados armazenados localmente serão movidos para o armazenamento em cluster). Eles podem ser comparados aos sistemas de arquivos em cluster do Luster e do Hadoop Distributed File System (HDFS) com uma implementação de código aberto.
O armazenamento oferece aos usuários a capacidade de acessar com facilidade e confiabilidade os dados disponíveis para o cluster. Como mostrado na fig. 2.3, o repositório possui várias camadas.
1. A camada mais baixa é chamada D (do disco, embora o nível D use os discos rígidos tradicionais e as unidades flash). D é um servidor de arquivos que roda em praticamente todas as máquinas de cluster. No entanto, os usuários que desejam acessar seus dados não gostariam de se lembrar em qual máquina estão armazenados, portanto a próxima camada está conectada aqui.
2. A camada D acima é a camada Colossus, que cria um sistema de arquivos no cluster que oferece a semântica usual do sistema de arquivos, além de replicação e criptografia. Colossus é o sucessor do GFS, o sistema de arquivos do Google (Ghemawat et al., 2003).
3. Em seguida, existem vários serviços semelhantes a bancos de dados criados acima do nível do Colossus.
- Bigtable [Chang et al., 2006] é um sistema de banco de dados não relacional (NoSQL) capaz de trabalhar com bancos de dados do tamanho de petabytes. O Bigtable é um banco de dados disperso, tolerante a falhas, multidimensional e ordenado, indexado por chaves de linha, coluna e registro de data e hora; cada valor do banco de dados é uma matriz arbitrária e não interpretada de bytes. O Bigtable também suporta replicação entre data centers.
- Spanner [Corbett et al., 2012] oferece uma interface semelhante a SQL para usuários que exigem integridade e consistência de dados ao acessar de qualquer lugar do mundo.
- Vários outros sistemas de banco de dados estão disponíveis, como o Blobstore. Todos eles têm suas próprias forças e fraquezas (ver capítulo 26).
Rede
A rede do Google é gerenciada de várias maneiras. Como mencionado anteriormente, usamos uma rede configurável por software baseada no OpenFlow. Em vez de roteadores inteligentes, usamos switches tolos não tão caros em combinação com um controlador central (duplicado), que pré-calcula a melhor rota na rede. Isso permite que você use um equipamento de comutação mais simples, liberando-o da busca de rotas demorada.
A largura de banda da rede deve ser alocada corretamente. Como o Borg limita os recursos de computação que uma tarefa pode usar, o Bandwidth Enforcer (BwE) gerencia a largura de banda disponível para maximizar o rendimento médio. A otimização da largura de banda não se relaciona apenas ao custo: o gerenciamento centralizado de tráfego resolve uma série de problemas extremamente difíceis de resolver por uma combinação de roteamento distribuído e gerenciamento convencional de tráfego (Kumar, 2015).
Alguns serviços têm trabalhos em execução em vários clusters localizados em diferentes partes do mundo. Para reduzir o tempo de atraso dos sistemas distribuídos globalmente, gostaríamos de direcionar os usuários para o data center mais próximo que possua a capacidade adequada para isso. Nosso Global Software Load Balancer (GSLB) realiza o balanceamento de carga em três níveis:
- balanceamento de carga geográfica para consultas DNS (por exemplo, para www.google.com ), é descrito no capítulo 19;
- balanceamento de carga no nível dos serviços do usuário (por exemplo, YouTube ou Google Maps);
- balanceamento de carga no nível RPC (Remote Procedure Call), descrito no Capítulo 20.
Os proprietários do serviço especificam nomes simbólicos para eles, uma lista de endereços BNS do servidor e o desempenho disponível em cada site (geralmente é medido em consultas por segundo - consultas por segundo, QPS). Posteriormente, o GSLB roteia o tráfego para os endereços BNS especificados.
Outro software do sistema
Existem outros componentes importantes no software do data center.
Serviço de bloqueioO Chubby Lock Service [Burrows, 2006] fornece uma API semelhante ao sistema de arquivos para servir bloqueios. O Chubby lida com bloqueios em todos os datacenters. Ele usa o protocolo Paxos para acessar de forma assíncrona o consenso (consulte o capítulo 23).
O gordinho também desempenha um papel importante na escolha de um assistente. Se, para algum serviço, cinco réplicas de uma tarefa são fornecidas com o objetivo de aumentar a confiabilidade, mas em um determinado momento apenas uma delas faz o trabalho real, o Chubby é usado para selecionar essa réplica.
O Chubby é ótimo para dados que requerem confiabilidade de armazenamento. Por esse motivo, o BNS usa o Chubby para armazenar a proporção de caminhos do BNS para o endereço IP: pares de portas.
Monitoramento e alertaQueremos ter certeza de que todos os serviços estão funcionando corretamente. Portanto, estamos lançando muitas instâncias do programa de monitoramento Borgmon (consulte o capítulo 10). A Borgmon recebe regularmente valores de referência dos serviços monitorados. Esses dados podem ser usados imediatamente para notificação ou armazenados para processamento e análise subsequentes, por exemplo, para construção de gráficos. Esse monitoramento pode ser usado para fins como:
- configurar alertas para problemas urgentes;
- comparação de comportamento: a atualização do software acelerou o servidor;
- avaliação da natureza das mudanças no consumo de recursos ao longo do tempo, necessárias para o planejamento da capacidade.
Nossa infraestrutura de software
A arquitetura do nosso software foi projetada para que seja possível usar os recursos de hardware do sistema com mais eficiência. Nosso código inteiro é multiencadeado, portanto, uma tarefa pode usar facilmente vários núcleos. Para suportar painéis, monitoramento e depuração, cada servidor inclui uma implementação de servidor HTTP como uma interface através da qual são fornecidas informações e estatísticas de diagnóstico para uma tarefa específica.
Todos os serviços do Google se "comunicam" usando a infraestrutura RPC (chamada de procedimento remoto) chamada Stubby. Existe uma versão de código aberto, chamada gRPC (consulte
grpc.io ). Freqüentemente, uma chamada RPC é feita mesmo para rotinas no programa local. Isso permite reorientar o programa para as chamadas de outro servidor para obter maior modularidade ou conforme o código do servidor original aumenta. O GSLB pode executar o balanceamento de carga RPC da mesma maneira que nas interfaces de serviço externas.
O servidor recebe solicitações de RPC do front-end e envia a RPC para o back-end. Usando termos tradicionais, o front-end é chamado de cliente e o back-end é chamado de servidor.
Os dados são transferidos de e para o RPC usando o protocolo de serialização - os chamados buffers de protocolo ou, brevemente, protobufs. Esse protocolo é semelhante ao Thrift do Apache e possui várias vantagens sobre o XML quando se trata de serializar dados estruturados: é mais simples, três a dez vezes mais compacto, 20 a 100 vezes mais rápido e exclusivo.
Nosso ambiente de desenvolvimento
A velocidade do desenvolvimento do produto é muito importante para o Google, por isso criamos um ambiente especial que aproveita ao máximo nossa infraestrutura [Morgenthaler et al., 2012].
Com exceção de alguns grupos cujos produtos são de código aberto e, portanto, usam seus próprios repositórios separados (por exemplo, Android e Chrome), os engenheiros de software do Google trabalham em um repositório comum [Potvin, Levenberg, 2016]. Essa abordagem tem várias aplicações práticas que são importantes para o nosso processo de produção.
- Se um engenheiro encontrar um problema em um componente fora de seu projeto, ele poderá corrigi-lo, enviar as alterações propostas (“lista de alterações” - lista de mudanças, CL) ao proprietário para consideração e, em seguida, implementar as alterações feitas na ramificação principal do programa.
- Alterações no código-fonte no projeto de um engenheiro requerem consideração - realização de uma auditoria (revisão). Todo o software passa esse estágio antes da adoção.
Quando o software está sendo montado, a solicitação de montagem é enviada para servidores especializados de data center. Até a criação de grandes projetos é rápida, porque você pode usar vários servidores para compilação paralela. Essa infraestrutura também é usada para testes contínuos. Sempre que uma nova lista de alterações (CL) aparece, são executados testes de todos os softwares que podem ser afetados direta ou indiretamente por essas alterações. Se a estrutura detectar que as alterações interromperam a operação de outras partes do sistema, notificará o proprietário dessas alterações. Alguns projetos usam o sistema push-on-green ("envio com sucesso"), segundo o qual a nova versão é automaticamente enviada para operação comercial após a aprovação nos testes.
Shakespeare: exemplo de serviço
Para demonstrar como o Google desenvolve um serviço em um ambiente industrial, considere um exemplo de serviço hipotético que interage com as tecnologias do Google. Suponha que desejemos oferecer um serviço que permita determinar em quais obras de Shakespeare a palavra que você mencionou ocorre.
Podemos dividir o sistema em duas partes.
- Um componente de processamento em lote que lê todos os textos de Shakespeare, cria um índice e o grava no Bigtable. Essa tarefa (mais precisamente, a tarefa) é executada uma vez ou, possivelmente, ocasionalmente (afinal, algum novo texto de Shakespeare pode aparecer!).
- Um aplicativo front-end que processa solicitações do usuário final. Essa tarefa está sempre em execução, pois a qualquer momento, um usuário de qualquer fuso horário pode pesquisar nos livros de Shakespeare.
O componente de processamento em lote será o serviço MapReduce, cujo trabalho é dividido em três fases.
1. Na fase de mapeamento, os textos de Shakespeare são lidos e divididos em palavras separadas. Esta parte do trabalho será concluída mais rapidamente se vários processos de trabalho (tarefas) forem iniciados em paralelo.
2. Na fase Aleatória, as entradas são classificadas por palavra.
3. Na fase Reduzir, as tuplas do formulário (palavra, lista_produtos) são criadas.
Cada tupla é escrita como uma string no Bigtable, a chave é a palavra.
Solicitar ciclo de vida
Na fig. 2.4 mostra como a solicitação do usuário é atendida. Primeiro, o usuário clica no link shakespeare.google.com no navegador. Para obter o endereço IP apropriado, o dispositivo do usuário converte ("resolve") o endereço usando o servidor DNS (1). A consulta DNS acaba sendo encerrada no servidor DNS do Google, que interage com o GSLB. Rastreando a carga de tráfego de todos os servidores front-end por região, o GSLB escolhe qual endereço IP de qual servidor retornar ao usuário.
O navegador se conecta ao servidor HTTP no endereço especificado. Este servidor (chamado Google Frontend ou GFE) é um servidor proxy "reverso" localizado na outra extremidade da conexão TCP do cliente (2). O GFE pesquisa o serviço necessário (por exemplo, pode ser um serviço de pesquisa, mapas ou - no nosso caso, o serviço Shakespeare). Acessando repetidamente o GSLB, o servidor encontra um servidor front-end Shakespeare disponível e o acessa por meio de uma RPC (chamada de procedimento remoto), transmitindo uma solicitação HTTP recebida do usuário (3).
O servidor Shakespeare analisa a solicitação HTTP e cria um "buffer de protocolo" (protobuf) contendo as palavras a serem encontradas. Agora, o servidor front-end de Shakespeare deve entrar em contato com o servidor back-end de Shakespeare: o primeiro entra em contato com o GSLB para obter o endereço BNS de uma instância adequada e descarregada da segunda (4). Em seguida, o servidor back-end de Shakespeare entra em contato com o servidor Bigtable para receber os dados solicitados (5).
O resultado é gravado no protobuf de resposta e retornado ao servidor de back-end de Shakespeare. O back-end passa o protobuf com o resultado do serviço para o servidor front-end de Shakespeare, que cria um documento HTML e o devolve como resposta ao usuário.
Toda essa cadeia de eventos acontece num piscar de olhos - em apenas algumas centenas de milissegundos! Como muitos componentes estão envolvidos, há muitos locais onde um erro em potencial pode ocorrer; em particular, uma falha no GSLB pode desorganizar todo o trabalho e levar ao colapso. Google, , ( ), , . ,
www.google.com , .
, - 100 (QPS). , 3470 QPS, 35 . , 37 , N + 2.
: 1430 QPS , 290 — , 1400 — 350 — . - , : , , . N + 2 , 17 , 16 — — . , , ( ), — N + 2 N + 1. : GSLB - , 20 % , . 2–3 .
- Bigtable, . - Bigtable, , , Bigtable . , Bigtable , . Bigtable , , .
, . , , .
»Mais informações sobre o livro podem ser encontradas no
site do editor»
Conteúdo»
TrechoCupom de 20% de desconto para Habrozavitel - Site Confiabilidade Engenharia