As nuvens são como uma caixa mágica: você pergunta o que precisa e os recursos simplesmente aparecem do nada. Máquinas virtuais, bancos de dados, rede - tudo isso pertence apenas a você. Existem outros inquilinos da nuvem, mas no seu Universo você é o único governante. Você tem certeza de que sempre receberá os recursos necessários, não leva ninguém em consideração e determina de forma independente como será a rede. Como funciona essa mágica que faz com que a nuvem aloque recursos de forma elástica e isole completamente os locatários uns dos outros?
A nuvem AWS é um sistema mega-supercomplexo que vem evoluindo evolutivamente desde 2006. Parte deste desenvolvimento ocorreu Vasily Pantyukhin - Arquiteto de Amazon Web Services. Como arquiteto, ele tem uma visão interna não apenas do resultado final, mas também dos desafios que a AWS supera. Quanto maior a compreensão de como o sistema funciona, maior será a confiança. Portanto, Vasily compartilhará os segredos dos serviços em nuvem AWS. Abaixo está o design de servidores físicos AWS, escalabilidade elástica de banco de dados, um banco de dados Amazon personalizado e métodos para aumentar o desempenho de máquinas virtuais e, ao mesmo tempo, reduzir seu preço. O conhecimento das abordagens arquitetônicas da Amazon ajudará você a usar os serviços da AWS de maneira mais eficaz e poderá fornecer novas ideias para criar suas próprias soluções.
Sobre o palestrante: Vasily Pantyukhin () começou como administrador Unix em empresas .ru, trabalhou em grandes hardwares da Sun Microsystem por 6 anos e pregou um mundo centrado em dados na EMC por 11 anos. Naturalmente evoluiu para nuvens privadas e, em 2017, mudou para nuvens públicas. Agora ele fornece consultoria técnica para ajudar a viver e desenvolver na nuvem AWS.
Isenção de responsabilidade: tudo abaixo é a opinião pessoal de Vasily e pode não coincidir com a posição da Amazon Web Services. O relatório em que se baseia o artigo está disponível em nosso canal no YouTube.
Por que estou falando sobre o dispositivo Amazon?
Meu primeiro carro tinha transmissão manual. Foi ótimo pela sensação de poder dirigir o carro e ter controle total sobre ele. Também gostei de ter entendido pelo menos aproximadamente o princípio de seu funcionamento. Naturalmente, imaginei que a estrutura da caixa fosse bastante primitiva - algo como a caixa de câmbio de uma bicicleta.
Tudo estava ótimo, exceto por uma coisa: preso em engarrafamentos. Parece que você está sentado e não faz nada, mas está constantemente mudando de marcha, pisando na embreagem, no acelerador, no freio - isso realmente te deixa cansado. O problema do engarrafamento foi parcialmente resolvido quando a família adquiriu um carro automático. Enquanto dirigia, tive tempo para pensar em algo e ouvir um audiolivro.
Outro mistério apareceu na minha vida, porque parei completamente de entender como funciona meu carro. Um carro moderno é um dispositivo complexo. O carro se adapta simultaneamente a dezenas de parâmetros diferentes: pisar no acelerador, freio, estilo de direção, qualidade da estrada. Não entendo mais como isso funciona.
Quando comecei a trabalhar na nuvem da Amazon, isso também era um mistério para mim. Só que esse mistério é uma ordem de grandeza maior, porque há um motorista no carro e na AWS existem milhões deles. Todos os usuários dirigem, pisam no acelerador e freiam simultaneamente. É incrível que eles vão aonde querem - é um milagre para mim! O sistema se adapta, dimensiona e ajusta-se elasticamente a cada usuário automaticamente para que lhe pareça que está sozinho neste Universo.
A magia desapareceu um pouco quando mais tarde comecei a trabalhar como arquiteto na Amazon. Vi quais problemas enfrentamos, como os resolvemos e como desenvolvemos serviços. Com a crescente compreensão de como o sistema funciona, surge mais confiança no serviço. Então, quero compartilhar uma imagem do que está por trás da nuvem AWS.
Sobre o que deveríamos falar
Optei por uma abordagem diversificada - selecionei 4 serviços interessantes que valem a pena falar.
Otimização do servidor. Nuvens efêmeras com corpo físico: data centers físicos onde existem servidores físicos que zumbem, aquecem e piscam com luzes.
Funções sem servidor (Lambda) é provavelmente o serviço mais escalonável na nuvem.
Dimensionamento de banco de dados. Vou falar sobre como construímos nossos próprios bancos de dados escalonáveis.
Dimensionamento de rede. A última parte em que abrirei o dispositivo da nossa rede. Isso é maravilhoso - todo usuário da nuvem acredita que está sozinho na nuvem e não vê os outros inquilinos.
Observação. Este artigo discutirá a otimização do servidor e o dimensionamento do banco de dados. Consideraremos o dimensionamento da rede no próximo artigo. Onde estão as funções sem servidor? Uma transcrição separada foi publicada sobre eles “" Ele fala sobre vários métodos de dimensionamento diferentes e discute detalhadamente a solução Firecracker - uma simbiose das melhores qualidades de uma máquina virtual e contêineres.
Servidores
A nuvem é efêmera. Mas essa efemeridade ainda tem uma concretização física – servidores. Inicialmente, sua arquitetura era clássica. Chipset x86 padrão, placas de rede, Linux, hipervisor Xen nos quais as máquinas virtuais foram executadas.
Em 2012, esta arquitetura lidou muito bem com suas tarefas. O Xen é um ótimo hipervisor, mas tem uma grande desvantagem. Ele tem o suficiente alta sobrecarga para emulação de dispositivo. À medida que novas placas de rede ou unidades SSD mais rápidas são disponibilizadas, essa sobrecarga se torna muito alta. Como lidar com esse problema? Decidimos trabalhar em duas frentes ao mesmo tempo - otimizar hardware e hipervisor. A tarefa é muito séria.
Otimizando hardware e hipervisor
Fazer tudo de uma vez e bem não vai funcionar. O que era “bom” também não estava claro inicialmente.
Decidimos adotar uma abordagem evolutiva – alteramos um elemento importante da arquitetura e o colocamos em produção.
Pisamos em cada ancinho, ouvimos reclamações e sugestões. Então mudamos outro componente. Assim, em pequenos incrementos, mudamos radicalmente toda a arquitetura com base no feedback dos usuários e do suporte.
A transformação começou em 2013 com o que há de mais complexo: a rede. EM S3 Em alguns casos, uma placa especial Network Accelerator foi adicionada à placa de rede padrão. Ele foi conectado literalmente com um cabo curto de loopback no painel frontal. Não é bonito, mas não é visível na nuvem. Mas a interação direta com o hardware melhorou fundamentalmente o jitter e o rendimento da rede.
Em seguida decidimos melhorar o acesso ao armazenamento de dados em bloco EBS - Elastic Block Storage. É uma combinação de rede e armazenamento. A dificuldade é que, embora existissem placas Network Accelerator no mercado, não havia opção de simplesmente comprar hardware Storage Accelerator. Então recorremos a uma startup Laboratórios Annapurna, que desenvolveu chips ASIC especiais para nós. Eles permitiram que volumes EBS remotos fossem montados como dispositivos NVMe.
Em casos C4 resolvemos dois problemas. A primeira é que implementamos uma base para o futuro da tecnologia NVMe promissora, mas nova na época. Em segundo lugar, descarregamos significativamente o processador central, transferindo o processamento de solicitações do EBS para um novo cartão. Acabou bem, então agora o Annapurna Labs faz parte da Amazon.
Em novembro de 2017, percebemos que era hora de mudar o próprio hipervisor.
O novo hipervisor foi desenvolvido com base em módulos modificados do kernel KVM.
Tornou possível reduzir fundamentalmente a sobrecarga de emulação de dispositivos e trabalhar diretamente com novos ASICs. Instâncias S5 foram as primeiras máquinas virtuais com um novo hipervisor em execução. Nós o nomeamos Nitro.
Evolução das instâncias na linha do tempo.
Todos os novos tipos de máquinas virtuais que surgiram desde novembro de 2017 são executados neste hipervisor. As instâncias Bare Metal não têm um hipervisor, mas também são chamados de Nitro, pois utilizam placas Nitro especializadas.
Nos dois anos seguintes, o número de tipos de instâncias Nitro ultrapassou algumas dúzias: A1, C5, M5, T3 e outros.
Tipos de instância.
Como funcionam as máquinas Nitro modernas
Eles possuem três componentes principais: o hipervisor Nitro (discutido acima), o chip de segurança e as placas Nitro.
Chip de segurança integrado diretamente na placa-mãe. Ele controla muitas funções importantes, como controlar o carregamento do sistema operacional host.
Cartões nitro - Existem quatro tipos deles. Todos eles são desenvolvidos pelo Annapurna Labs e são baseados em ASICs comuns. Alguns de seus firmwares também são comuns.
Quatro tipos de cartas Nitro.
Um dos cartões foi projetado para funcionar com redeVPC. Isto é o que fica visível nas máquinas virtuais como uma placa de rede ENA - Adaptador de Rede Elástica. Ele também encapsula o tráfego ao transmiti-lo através de uma rede física (falaremos sobre isso na segunda parte do artigo), controla o firewall dos Grupos de Segurança e é responsável pelo roteamento e outras coisas da rede.
Alguns cartões funcionam com armazenamento em bloco EBS e discos integrados ao servidor. Eles aparecem para a máquina virtual convidada como Adaptadores NVMe. Eles também são responsáveis pela criptografia de dados e monitoramento de disco.
O sistema de cartões Nitro, hipervisor e chip de segurança é integrado a uma rede SDN ou Rede Definida por Software. Responsável por gerenciar esta rede (Control Plane) placa controladora.
Claro, continuamos a desenvolver novos ASICs. Por exemplo, no final de 2018 lançaram o chip Inferentia, que permite trabalhar de forma mais eficiente com tarefas de aprendizado de máquina.
Chip do processador de aprendizado de máquina Inferentia.
Banco de dados escalável
Um banco de dados tradicional possui uma estrutura em camadas. Para simplificar bastante, os seguintes níveis são diferenciados.
- SQL - os despachantes do cliente e da solicitação trabalham nisso.
- Disposições transações - está tudo claro aqui, ACID e tudo mais.
- cache, que é fornecido por buffer pools.
- Exploração madeireira — fornece trabalho com redo logs. No MySQL eles são chamados de Bin Logs, no PosgreSQL - Write Ahead Logs (WAL).
- Armazenamento – gravação direta em disco.
Estrutura de banco de dados em camadas.
Existem diferentes maneiras de dimensionar bancos de dados: sharding, arquitetura Shared Nothing, discos compartilhados.
No entanto, todos esses métodos mantêm a mesma estrutura de banco de dados monolítica. Isso limita significativamente o dimensionamento. Para resolver este problema, desenvolvemos nosso próprio banco de dados - Aurora Amazônica. É compatível com MySQL e PostgreSQL.
Aurora Amazônica
A ideia arquitetônica principal é separar os níveis de armazenamento e registro do banco de dados principal.
Olhando para o futuro, direi que também tornamos o nível de cache independente. A arquitetura deixa de ser um monólito e ganhamos graus adicionais de liberdade no dimensionamento de blocos individuais.
Os níveis de registro e armazenamento são separados do banco de dados.
Um SGBD tradicional grava dados em um sistema de armazenamento na forma de blocos. Na Amazon Aurora, criamos armazenamento inteligente que fala idiomas refazer logs. Internamente, o armazenamento transforma logs em blocos de dados, monitora sua integridade e faz backup automaticamente.
Essa abordagem permite que você implemente coisas interessantes como clonagem. Funciona fundamentalmente de forma 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.
A camada de armazenamento é implementada como um sistema distribuído. Consiste em um grande número de servidores físicos. Cada redo log é processado e salvo simultaneamente seis nós. Isso garante proteção de dados e balanceamento de carga.
O escalonamento de leitura pode ser alcançado usando réplicas apropriadas. O armazenamento distribuído elimina a necessidade de sincronização entre a instância principal do banco de dados, por meio da qual escrevemos os dados, e as demais réplicas. É garantido que os dados atualizados estarão disponíveis para todas as réplicas.
O único problema é armazenar dados antigos em réplicas de leitura. Mas esse problema está sendo resolvido transferência de todos os redo logs para réplicas na rede interna. Se o log estiver no cache, ele será marcado como incorreto e substituído. Se não estiver no cache, será simplesmente descartado.
Nós resolvemos o armazenamento.
Como escalar camadas de DBMS
Aqui, o dimensionamento horizontal é muito mais difícil. Então vamos seguir o caminho mais conhecido escala vertical clássica.
Vamos supor que temos uma aplicação que se comunica com o SGBD através de um nó mestre.
Ao escalar verticalmente, alocamos um novo nó que terá mais processadores e memória.
Em seguida, trocamos o aplicativo do nó mestre antigo para o novo. Surgem problemas.
- Isso exigirá um tempo de inatividade significativo do aplicativo.
- O novo nó mestre terá cache frio. O desempenho do banco de dados será máximo somente após o aquecimento do cache.
Como melhorar a situação? Configure um proxy entre o aplicativo e o nó mestre.
O que isso nos dará? Agora todos os aplicativos não precisam ser redirecionados manualmente para o novo nó. A troca pode ser feita sob um proxy e é fundamentalmente mais rápida.
Parece que o problema foi resolvido. Mas não, ainda sofremos com a necessidade de aquecer a cache. Além disso, surgiu um novo problema - agora o proxy é um potencial ponto de falha.
Solução final com Amazon Aurora sem servidor
Como resolvemos esses problemas?
Deixou um proxy. Esta não é uma instância separada, mas toda uma frota distribuída de proxies por meio dos quais os aplicativos se conectam ao banco de dados. Em caso de falha, qualquer um dos nós pode ser substituído quase instantaneamente.
Adicionado um conjunto de nós quentes de vários tamanhos. Portanto, caso seja necessário alocar um novo nó de tamanho maior ou menor, ele fica imediatamente disponível. Não há necessidade de esperar que carregue.
Todo o processo de dimensionamento é controlado por um sistema de monitoramento especial. O monitoramento monitora constantemente o estado do nó mestre atual. Se detectar, por exemplo, que a carga do processador atingiu um valor crítico, ele notifica o pool de instâncias quentes sobre a necessidade de alocar um novo nó.
Proxies distribuídos, instâncias quentes e monitoramento.
Um nó com a potência necessária está disponível. Os buffer pools são copiados para ele e o sistema começa a aguardar um momento seguro para alternar.
Normalmente, o momento de mudar chega rapidamente. Em seguida, a comunicação entre o proxy e o antigo nó mestre é suspensa e todas as sessões são comutadas para o novo nó.
Trabalhar com o banco de dados é retomado.
O gráfico mostra que a suspensão é realmente muito curta. O gráfico azul mostra a carga e as etapas vermelhas mostram os momentos de escala. As quedas de curto prazo no gráfico azul são precisamente esse pequeno atraso.
Aliás, o Amazon Aurora permite economizar totalmente e desligar o banco de dados quando ele não estiver em uso, por exemplo, nos finais de semana. Após parar a carga, o DB reduz gradativamente sua potência e desliga por algum tempo. Quando a carga retornar, ela subirá suavemente novamente.
Na próxima parte da história sobre o dispositivo Amazon, falaremos sobre escalonamento de rede. Se inscrever e fique ligado para não perder o artigo.
На Vasily Pantyukhin fará um relatório “" Quais padrões de design para sistemas distribuídos são usados pelos desenvolvedores da Amazon, quais são as razões para falhas de serviço, o que é arquitetura baseada em células, trabalho constante, Shuffle Sharding - será interessante. Menos de um mês até a conferência - . Aumento de preço final em 24 de outubro.
Fonte: habr.com