As nuvens são como uma caixa mágica - você pergunta o que precisa e os recursos aparecem do nada. Máquinas virtuais, bancos de dados, uma rede - tudo isso pertence apenas a você. Existem outros inquilinos da nuvem, mas em seu universo você é o único governante. Você tem certeza de que sempre receberá os recursos necessários, não conta com ninguém e determina independentemente qual será a rede. Como é essa mágica que faz a nuvem alocar recursos elasticamente e isolar completamente os inquilinos um do outro?
O AWS Cloud é um sistema mega sofisticado que evolui desde 2006. Parte desse desenvolvimento foi encontrada por
Vasily Pantyukhin , arquiteta do Amazon Web Services. Como arquiteto, ele vê de dentro não apenas o resultado final, mas também os desafios que a AWS supera. Quanto mais compreensão do sistema, mais confiança. Portanto, Vasily compartilhará os segredos dos serviços em nuvem da AWS. Sob o corte está o dispositivo para servidores físicos da AWS, escalabilidade flexível do banco de dados, um banco de dados personalizado da Amazon e métodos para melhorar o desempenho das máquinas virtuais e reduzir seu preço. O conhecimento das abordagens arquitetônicas da Amazon ajudará você a usar melhor os serviços da AWS e poderá fornecer novas idéias para criar suas próprias soluções.
Sobre o palestrante: Vasily Pantyukhin ( Hen ) começou como administradora do Unix in.ru, passou 6 anos trabalhando em grandes glândulas da Sun Microsystem e, por 11 anos, pregou a centralidade de dados do mundo na EMC. Evoluiu naturalmente para nuvens privadas e, em 2017, se transformou em nuvens públicas. Agora, com dicas técnicas, ele ajuda a viver e se desenvolver na nuvem da AWS.
Isenção de responsabilidade: tudo abaixo é da opinião pessoal de Vasily e pode não coincidir com a posição da Amazon Web Services. Um vídeo do relatório com base no qual o artigo foi criado está disponível em nosso canal do YouTube.Por que estou falando de um dispositivo Amazon
Meu primeiro carro foi com uma "alça" - em uma caixa de câmbio manual. Foi ótimo devido à sensação de que eu podia controlar a máquina e controlá-la completamente. Também gostei de entender pelo menos o princípio do trabalho dela. Naturalmente, imaginei o dispositivo da caixa bastante primitivo - mais ou menos como uma caixa de câmbio em uma bicicleta.
Tudo foi maravilhoso, exceto por uma coisa - parado em engarrafamentos. Parece que você está sentado e não está fazendo nada, mas muda constantemente de marcha, pressiona a embreagem, acelera, freia - você realmente se cansa disso. O problema dos engarrafamentos foi parcialmente resolvido quando uma máquina apareceu na máquina na família. Ao volante, havia tempo para pensar em algo, ouvir um audiolivro.
Um mistério apareceu em minha vida, porque geralmente deixava de entender como meu carro funciona. Um carro moderno é um dispositivo complexo. O carro se adapta simultaneamente a dezenas de parâmetros diferentes: pressionando o acelerador, freio, estilo de direção e qualidade da estrada. Não entendo mais como isso funciona.
Quando comecei a fazer o Amazon Cloud, isso também foi um mistério para mim. Somente esse segredo é uma ordem de magnitude maior, porque há um motorista no carro e há milhões na AWS. Todos os usuários dirigem simultaneamente, pressionam o acelerador e o freio. É incrível que eles vão aonde querem - para mim é um milagre! O sistema se adapta automaticamente, dimensiona e se ajusta de maneira flexível a cada usuário, para que pareça que ele está sozinho neste universo.
A mágica se dissipou um pouco quando, mais tarde, fui trabalhar como arquiteto na Amazon. Vi quais problemas estamos enfrentando, como os resolvemos, como desenvolvemos serviços. Com um aumento no entendimento do sistema, há mais confiança no serviço. Então, quero compartilhar uma imagem do que está por trás da nuvem da AWS.
Sobre o que falaremos
Eu escolhi uma abordagem diversificada - selecionei 4 serviços interessantes que merecem ser discutidos.
Otimização do servidor . Nuvens efêmeras com uma incorporação física: data centers físicos, onde existem servidores físicos que estão vibrando, aquecendo e piscando lâmpadas.
As funções sem servidor (Lambda) são provavelmente o serviço mais escalável na nuvem.
Escala de banco de dados . Falarei sobre como criamos nossos próprios bancos de dados escaláveis.
Escala de rede . A última parte em que vou abrir o dispositivo da nossa rede. Isso é uma coisa maravilhosa - cada usuário da nuvem acredita que está sozinho na nuvem e não vê outros inquilinos.
Nota Este artigo se concentrará na otimização do servidor e no dimensionamento do banco de dados. O dimensionamento da rede será discutido no próximo artigo. Onde estão as funções sem servidor? Uma transcrição separada saiu sobre eles: “ Mal, sim, ousada. Anboxing de microvirtuais do Firecracker . " Ele fala sobre várias maneiras diferentes de dimensionar, e a solução Firecracker é analisada em detalhes - uma simbiose das melhores qualidades de uma máquina virtual e contêineres.
Servidores
A nuvem é efêmera. Mas essa efemeridade ainda tem uma personificação física - servidores. Inicialmente, sua arquitetura era clássica. Chipset x86 padrão, placas de rede, Linux, hipervisor Xen, que executa máquinas virtuais.
Em 2012, essa arquitetura fez seu trabalho bem. Xen é um ótimo hipervisor, mas com uma grande falha. Ele tem uma
sobrecarga bastante
alta para emular dispositivos . Com o advento de novas placas de rede ou SSDs mais rápidos, essas sobrecargas se tornam muito altas. Como lidar com este problema? Decidimos trabalhar em duas frentes ao mesmo tempo - para
otimizar o hardware e o hipervisor . A tarefa é muito séria.
Otimização de ferro e hipervisor
Fazer tudo de uma vez e bem não funcionará. O que é "bom" era inicialmente incompreensível.
Decidimos aplicar uma abordagem evolutiva - mudamos um elemento importante da arquitetura e o lançamos em produção.
Nós pisamos em todos os ancinhos, ouvimos reclamações e sugestões. Então nós mudamos outro componente. Assim, em pequenos incrementos, alteramos radicalmente toda a arquitetura com base no feedback e no suporte do usuário.
A transformação começou em 2013 com a coisa mais difícil - a rede. Nas instâncias
C3 , uma placa especial do Network Accelerator foi adicionada à placa de rede padrão. Ele foi conectado com um cabo de loopback literalmente curto no painel frontal. Feio, mas não visível na nuvem. Mas a interação direta com o hardware melhorou fundamentalmente a instabilidade e a largura de banda da rede.
Decidimos focar na melhoria do acesso ao armazenamento em bloco do EBS - Elastic Block Storage. Essa é uma combinação de rede e armazenamento. A dificuldade é que, se as placas do Network Accelerator existiam no mercado, não havia como comprar apenas o hardware do Storage Accelerator. Portanto, nos voltamos para a startup
Annapurna Labs , que desenvolveu chips ASIC especiais para nós. Eles permitiram conectar volumes EBS remotos como dispositivos NVMe.
Nos casos
C4 , resolvemos dois problemas. Primeiro, implementamos as bases para o futuro com a tecnologia NVMe promissora, mas nova na época. O segundo - descarregou significativamente o processador central, transferindo o processamento de solicitações para o EBS para um novo cartão. Acabou bem, agora o Annapurna Labs faz parte da Amazon.
Em novembro de 2017, percebemos que era hora de mudar o hypervisor em si.
O novo hypervisor foi desenvolvido com base nos módulos do kernel KVM modificados.
Isso permitiu reduzir fundamentalmente os custos indiretos da emulação de dispositivos e trabalhar diretamente com os novos ASICs.
As instâncias
C5 foram as primeiras máquinas virtuais sob as quais um novo hipervisor está sendo executado. Nós chamamos de
Nitro .
A evolução das instâncias na linha do tempo.Todos os novos tipos de máquinas virtuais que apareceram desde novembro de 2017 funcionam neste hipervisor.
As instâncias do Iron Bare Metal não têm um hypervisor , mas também são chamadas de Nitro, pois usam placas Nitro especializadas.
Nos dois anos seguintes, o número de tipos de instâncias do Nitro excedeu algumas dúzias: A1, C5, M5, T3 e outras.
Tipos de instâncias.Como funcionam os carros nitro modernos
Eles têm três componentes principais: um hipervisor Nitro (discutido acima), um chip de segurança e placas Nitro.
O chip de segurança é integrado diretamente na placa-mãe. Ele controla muitas funções importantes, por exemplo, controlando o carregamento do SO host.
Cartões Nitro - existem quatro tipos deles. Todos são desenvolvidos pela Annapurna Labs e são baseados em ASICs comuns. Parte de seu firmware também é comum.
Quatro tipos de cartões nitro.Uma das placas foi projetada para funcionar com
uma rede VPC . É ela quem é visível nas
máquinas virtuais como uma placa de rede
ENA - Elastic Network Adapter . Ele também encapsula o tráfego quando é transmitido pela rede física (falaremos sobre isso na segunda parte do artigo), controla o firewall dos Grupos de Segurança, é responsável pelo roteamento e outras coisas da rede.
Placas separadas funcionam com armazenamento em bloco do
EBS e discos incorporados ao servidor. Eles são apresentados às máquinas virtuais convidadas como
adaptadores NVMe . Eles também são responsáveis pela criptografia de dados e monitoramento de disco.
O sistema de cartões Nitro, um hipervisor e um chip de segurança são integrados a uma SDN ou
rede definida por software . O
cartão de controle é responsável pelo gerenciamento desta rede (plano de controle).
Obviamente, continuamos a desenvolver novos ASICs. Por exemplo, no final de 2018, eles lançaram o chip Inferentia, que permite um trabalho mais eficiente com tarefas de aprendizado de máquina.
Chip de processador de aprendizado de máquina Inferentia.Banco de dados escalável
O banco de dados tradicional possui uma estrutura em camadas. Se bastante simplificado, os seguintes níveis são diferenciados.
- SQL - despachantes de clientes e consultas trabalham nele.
- Protegendo transações - tudo está claro aqui, ACID e tudo isso.
- Armazenamento em cache fornecido por buffer pools.
- Log - fornece trabalho com refazer logs. No MySQL, eles são chamados Bin Logs; no PosgreSQL, são chamados Write Ahead Logs (WAL).
- Armazenamento - escreva diretamente no disco.
Estrutura de banco de dados em camadas.Existem diferentes maneiras de dimensionar bancos de dados: sharding, arquitetura Shared Nothing, unidades compartilhadas.
No entanto, todos esses métodos mantêm a mesma estrutura de banco de dados monolítico. Isso limita significativamente a escala. Para resolver esse problema, desenvolvemos nosso próprio banco de dados - o
Amazon Aurora . É compatível com MySQL e PostgreSQL.
Aurora aurora
A principal idéia arquitetônica é dividir os níveis de armazenamento e log do banco de dados principal.
Olhando para o futuro, direi que também tornamos o nível do cache independente. A arquitetura deixa de ser um monólito e obtemos graus adicionais de liberdade na escala de blocos individuais.
Os níveis de log e armazenamento são separados do banco de dados.Um DBMS tradicional grava dados no sistema de armazenamento na forma de blocos. No Amazon Aurora, criamos um repositório "inteligente" que pode falar o idioma dos
redo-logs . No interior, o repositório transforma logs em blocos de dados, monitora sua integridade e faz backups automaticamente.
Essa abordagem permite implementar coisas interessantes como a
clonagem . Funciona fundamentalmente de maneira mais rápida e econômica devido ao fato de não exigir a criação de uma cópia completa de todos os dados.
O nível de armazenamento é implementado como um sistema distribuído. Consiste em um número muito grande de servidores físicos. Cada redo-log é processado e armazenado simultaneamente por
seis nós . Isso fornece proteção de dados e balanceamento de carga.
A escala de leitura pode ser obtida usando réplicas apropriadas. O armazenamento distribuído elimina a necessidade de sincronização entre a instância principal do banco de dados através da qual gravamos dados e outras réplicas. É garantido que os dados atuais estejam disponíveis para todas as réplicas.
O único problema é o armazenamento em cache de dados antigos em réplicas de leitura. Mas esse problema é resolvido através da
transferência de todos os redo logs para réplicas na rede interna. Se o log estiver no cache, ele será marcado como inválido e será substituído. Se não estiver no cache, será simplesmente descartado.
Nós descobrimos o armazenamento.
Como escalar níveis de DBMS
Aqui a escala horizontal é muito mais difícil de fazer. Portanto, vamos seguir o caminho mais comum da
escala vertical clássica .
Suponha que tenhamos um aplicativo que se comunique com um DBMS através de um nó principal.
Com a escala vertical, selecionamos um novo nó que terá mais processadores e memória.
Em seguida, alterne o aplicativo do nó principal antigo para o novo. Há problemas
- Isso exigirá um tempo de inatividade perceptível do aplicativo.
- O novo nó mestre terá um cache frio. O desempenho do banco de dados será máximo somente após o aquecimento do cache.
Como melhorar a situação? Coloque um proxy entre o aplicativo e o nó principal.
O que isso nos dará? Agora, todos os aplicativos não precisam ser redirecionados manualmente para um novo nó. A troca pode ser feita sob um proxy e, ao mesmo tempo, fundamentalmente mais rápido.
O problema parece estar resolvido. Mas não, ainda sofremos a necessidade de aquecer o cache. Além disso, um novo problema apareceu - agora o proxy é um ponto potencial de falha.
Solução final com o Amazon Aurora Serverless
Como resolvemos esses problemas?
Deixou um proxy . Esta não é uma instância separada, mas toda uma frota distribuída de proxies através dos quais os aplicativos se conectam ao banco de dados. No caso de uma falha, qualquer um dos nós pode ser substituído quase instantaneamente.
Adicionamos um conjunto de nós quentes de vários tamanhos . Portanto, se for necessário alocar um novo nó de tamanho maior ou menor, ele estará disponível imediatamente. Não é necessário esperar o carregamento.
Todo o processo de dimensionamento é controlado por um sistema de monitoramento especial. O monitoramento monitora constantemente o status do nó principal atual. Se detectar, por exemplo, que a carga do processador atingiu um valor crítico, notifica o conjunto de instâncias quentes da necessidade de alocar um novo nó.
Proxies distribuídos, instâncias quentes e monitoramento.Um nó da energia necessária está disponível. Os pools de buffers são copiados para ele e o sistema começa a aguardar um momento seguro para alternar.
Geralmente, o momento da troca chega rápido o suficiente. Em seguida, a comunicação entre o proxy e o nó principal antigo é suspensa, todas as sessões mudam para o novo nó.
O trabalho com o banco de dados é retomado.
O gráfico mostra que a suspensão é realmente muito curta. No gráfico azul, a carga e nos degraus vermelhos - os momentos da escala. As quedas de curto prazo no gráfico azul são exatamente esse pequeno atraso.
A propósito, o Amazon Aurora permite salvar e desativar completamente o banco de dados quando não estiver em uso, por exemplo, no fim de semana. Depois de parar a carga, o banco de dados diminui gradualmente sua energia e desliga por um tempo. Quando a carga retornar, ela subirá novamente suavemente.
Na próxima parte da conversa sobre o dispositivo Amazon, falaremos sobre o dimensionamento da rede. Assine a newsletter e fique atento para não perder o artigo.
No HighLoad ++, Vasily Pantyukhin fará uma apresentação “ Houston, temos um problema. Projeto de sistemas com falha, padrões de desenvolvimento de serviços internos na nuvem da Amazon . ” O que os desenvolvedores de design da Amazon usam padrões de design de sistema distribuído, quais são as razões para falhas de serviço, o que é arquitetura baseada em célula, trabalho constante e fragmentação de shuffle - será interessante. Menos de um mês antes da conferência - reserve seus ingressos . 24 de outubro, o aumento do preço final.