{"id":39302,"date":"2019-10-31T22:29:40","date_gmt":"2019-10-31T19:29:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh\/"},"modified":"2019-10-31T22:29:40","modified_gmt":"2019-10-31T19:29:40","slug":"kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh","title":{"rendered":"Como a AWS 'prepara' seus servi\u00e7os el\u00e1sticos. Escalabilidade de servidores e bancos de dados","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

As nuvens s\u00e3o como uma caixa m\u00e1gica \u2014 voc\u00ea define o que precisa e os recursos simplesmente aparecem do nada. M\u00e1quinas virtuais, bancos de dados, redes \u2014 tudo isso pertence apenas a voc\u00ea. Existem outros inquilinos na nuvem, mas em seu pr\u00f3prio universo, voc\u00ea \u00e9 o governante absoluto. Voc\u00ea tem certeza de que sempre receber\u00e1 os recursos necess\u00e1rios, n\u00e3o precisa considerar ningu\u00e9m e define sozinho como ser\u00e1 a rede. Como funciona essa m\u00e1gica que faz a nuvem alocar recursos de forma el\u00e1stica e isolar completamente os inquilinos uns dos outros?<\/p>\n

\"Como
\n
\nA nuvem AWS \u00e9 um sistema mega-super complexo que vem evoluindo desde 2006. Parte dessa evolu\u00e7\u00e3o foi testemunhada Vasily Pantyukhin<\/strong> \u2014 por Vasily, arquiteto da Amazon Web Services. Como arquiteto, ele v\u00ea n\u00e3o apenas o resultado final, mas tamb\u00e9m as complexidades que a AWS enfrenta. Quanto mais se entende como o sistema funciona, mais confian\u00e7a se tem. Portanto, Vasily compartilhar\u00e1 os segredos dos servi\u00e7os de nuvem da AWS. Abaixo, explicamos a estrutura dos servidores f\u00edsicos da AWS, a escalabilidade el\u00e1stica de bancos de dados, o banco de dados customizado da Amazon e m\u00e9todos para melhorar o desempenho das m\u00e1quinas virtuais, ao mesmo tempo que reduz seus custos. Conhecer as abordagens arquitet\u00f4nicas da Amazon ajudar\u00e1 a usar os servi\u00e7os da AWS de forma mais eficaz e, possivelmente, fornecer\u00e1 novas ideias para a constru\u00e7\u00e3o de suas pr\u00f3prias solu\u00e7\u00f5es.
\n<\/a><\/noindex>
\nSobre o palestrante: Vasily Pantyukhin (Hen<\/a><\/noindex>) come\u00e7ou como administrador Unix em empresas .ru, trabalhou por 6 anos com grandes equipamentos da Sun Microsystems e pregou a centralidade de dados no mundo por 11 anos na EMC. Evoluiu naturalmente para nuvens privadas e, em 2017, entrou no mercado de nuvens p\u00fablicas. Agora, ele oferece conselhos t\u00e9cnicos para viver e desenvolver na nuvem AWS.<\/p>\n

Aviso: tudo que segue \u00e9 uma opini\u00e3o pessoal de Vasily e pode n\u00e3o refletir a posi\u00e7\u00e3o da Amazon Web Services. A grava\u00e7\u00e3o em v\u00eddeo<\/a><\/noindex> da palestra, na qual este artigo foi baseado, est\u00e1 dispon\u00edvel em nosso canal no YouTube.<\/i><\/p>\n

Por que estou falando sobre a estrutura da Amazon<\/h2>\n

\nMeu primeiro carro tinha 'c\u00e2mbio manual' \u2014 com transmiss\u00e3o manual. Era incr\u00edvel por causa da sensa\u00e7\u00e3o de que eu podia controlar o carro e tinha total dom\u00ednio sobre ele. Tamb\u00e9m gostava de saber, pelo menos de forma aproximada, como ele funcionava. Naturalmente, eu tinha uma vis\u00e3o bastante primitiva do funcionamento da caixa de c\u00e2mbio \u2014 mais ou menos como uma caixa de marchas de bicicleta.<\/p>\n

\"Como
\n
\nTudo foi incr\u00edvel, exceto por uma coisa \u2014 ficar preso no tr\u00e2nsito. Parece que voc\u00ea est\u00e1 sentado e n\u00e3o fazendo nada, mas est\u00e1 constantemente trocando as marchas, pisando na embreagem, no acelerador, no freio \u2014 isso realmente cansa. O problema do tr\u00e2nsito foi parcialmente resolvido quando nossa fam\u00edlia adquiriu um carro autom\u00e1tico. Ao volante, passei a ter tempo para pensar em algo, ouvir um audiolivro.<\/p>\n

Al\u00e9m disso, surgiu um enigma na minha vida, porque eu realmente parei de entender como meu carro funciona. Um carro moderno \u00e9 um dispositivo complexo. Ele se adapta simultaneamente a dezenas de par\u00e2metros diferentes: acelera\u00e7\u00e3o, frenagem, estilo de condu\u00e7\u00e3o, qualidade da estrada. Eu j\u00e1 n\u00e3o entendo como isso funciona.<\/p>\n

Quando comecei a trabalhar com a nuvem da Amazon, isso tamb\u00e9m era um mist\u00e9rio para mim. S\u00f3 que esse mist\u00e9rio \u00e9 muito mais complexo, porque em um carro h\u00e1 um motorista, enquanto na AWS h\u00e1 milh\u00f5es. Todos os usu\u00e1rios dirigem ao mesmo tempo, acelerando e freando. \u00c9 incr\u00edvel que eles consigam ir para onde desejam \u2014 para mim, isso \u00e9 um milagre! O sistema se adapta automaticamente, escalona e se ajusta elasticamente a cada usu\u00e1rio, de forma que ele sente que \u00e9 o \u00fanico neste universo.<\/p>\n

A magia um pouco se dissipou quando, mais tarde, comecei a trabalhar como arquiteto na Amazon. Eu vi com quais problemas enfrentamos, como os resolvemos e como desenvolvemos os servi\u00e7os. Com a crescente compreens\u00e3o do funcionamento do sistema, a confian\u00e7a no servi\u00e7o aumenta. Por isso, quero compartilhar meu entendimento sobre o que acontece por tr\u00e1s do AWS cloud.<\/p>\n

Sobre o que vamos falar<\/h2>\n

\nEscolhi uma abordagem diversificada \u2014 selecionei 4 servi\u00e7os interessantes sobre os quais vale a pena falar.<\/p>\n

Otimiza\u00e7\u00e3o de servidores<\/strong>. Nuvens ef\u00eameras com uma manifesta\u00e7\u00e3o f\u00edsica: data centers f\u00edsicos, onde est\u00e3o os servidores f\u00edsicos que zumbem, esquentam e piscam as luzes.<\/p>\n

Fun\u00e7\u00f5es sem servidor <\/strong>(Lambda) \u2014 provavelmente, o servi\u00e7o mais escal\u00e1vel na nuvem.<\/p>\n

Escalonamento de banco de dados<\/strong>. Vou falar sobre como constru\u00edmos nossos pr\u00f3prios bancos de dados escal\u00e1veis.<\/p>\n

Escalonamento de rede<\/strong>. A \u00faltima parte, na qual revelarei a estrutura da nossa rede. \u00c9 uma coisa maravilhosa \u2014 cada usu\u00e1rio da nuvem acha que est\u00e1 sozinho na nuvem e n\u00e3o v\u00ea outros inquilinos.<\/p>\n

Nota. Neste artigo, vamos falar sobre a otimiza\u00e7\u00e3o de servidores e escalonamento de bancos de dados. O escalonamento da rede ser\u00e1 abordado no pr\u00f3ximo artigo. E onde est\u00e3o as fun\u00e7\u00f5es serverless? Elas foram objeto de uma an\u00e1lise separada \u00abPequeno, mas poderoso. Unboxing da microvirtualiza\u00e7\u00e3o Firecracker<\/a><\/noindex>\u00bb. Esta an\u00e1lise apresenta v\u00e1rias maneiras diferentes de escalonamento e detalha a solu\u00e7\u00e3o Firecracker \u2014 a simbiose das melhores caracter\u00edsticas de m\u00e1quinas virtuais e cont\u00eaineres.<\/i><\/p><\/blockquote>\n

<\/p>\n

Servidores<\/h2>\n

\nA nuvem \u00e9 ef\u00eamera. Mas essa efemeridade tem uma manifesta\u00e7\u00e3o f\u00edsica \u2014 servidores. Sua arquitetura originalmente era cl\u00e1ssica. Chipset x86 padr\u00e3o, placas de rede, Linux, hipervisor Xen, sobre o qual as m\u00e1quinas virtuais eram executadas.<\/p>\n

\"Como
\n
\nEm 2012, essa arquitetura cumpria suas fun\u00e7\u00f5es. O Xen \u00e9 um \u00f3timo hipervisor, mas tem uma grande desvantagem. Ele apresenta custos elevados de sobrecarga na emula\u00e7\u00e3o de dispositivos<\/strong>. Com o surgimento de novas placas de rede mais r\u00e1pidas ou discos SSD, esses custos tornam-se excessivos. Como lidar com esse problema? Decidiu-se atuar em duas frentes \u2014 otimizar tanto o hardware quanto o hipervisor<\/strong>. A tarefa \u00e9 bastante desafiadora.<\/p>\n

Otimiza\u00e7\u00e3o do hardware e do hipervisor<\/h3>\n

\nN\u00e3o se consegue fazer tudo de uma vez e com excel\u00eancia. O que significa \u00abexcelente\u00bb tamb\u00e9m n\u00e3o estava claro inicialmente.<\/p>\n

Decidiu-se aplicar uma abordagem evolutiva \u2014 alterar um elemento importante da arquitetura e lan\u00e7\u00e1-lo em produ\u00e7\u00e3o.<\/p><\/blockquote>\n

Enfrentamos todos os desafios, ouvimos reclama\u00e7\u00f5es e sugest\u00f5es. Depois, alteramos outro componente. Assim, com pequenos incrementos, transformamos toda a arquitetura baseada no feedback dos usu\u00e1rios e da equipe de suporte.<\/p>\n

As transforma\u00e7\u00f5es come\u00e7aram em 2013, pelo mais dif\u00edcil \u2014 a rede. No C3<\/strong> as inst\u00e2ncias foram adicionadas a um cart\u00e3o Network Accelerator especial em conjunto com o cart\u00e3o de rede padr\u00e3o. Ele era conectado literalmente com um cabo loopback curto no painel frontal. N\u00e3o era bonito, mas na nuvem n\u00e3o era vis\u00edvel. No entanto, a intera\u00e7\u00e3o direta com o hardware melhorou significativamente o jitter e a largura de banda da rede.<\/p>\n

Ap\u00f3s isso, decidimos melhorar o acesso ao armazenamento em bloco EBS \u2014 Elastic Block Storage. \u00c9 uma combina\u00e7\u00e3o de rede e armazenamento. A dificuldade \u00e9 que, enquanto j\u00e1 existiam cart\u00f5es Network Accelerator no mercado, n\u00e3o havia a possibilidade de simplesmente comprar hardware Storage Accelerator. Portanto, nos dirigimos \u00e0 startup Annapurna Labs<\/strong>, que desenvolveu para n\u00f3s chips ASIC especiais. Eles permitiram conectar volumes EBS remotos como dispositivos NVMe.<\/p>\n

Nas inst\u00e2ncias C4<\/strong> resolvemos duas quest\u00f5es. A primeira \u2014 fizemos uma prepara\u00e7\u00e3o para o futuro com uma tecnologia promissora, mas nova naquela \u00e9poca, a NVMe. A segunda \u2014 aliviamos significativamente a carga do processador central transferindo o processamento de solicita\u00e7\u00f5es para o EBS para um novo chip. A opera\u00e7\u00e3o foi bem-sucedida, por isso agora a Annapurna Labs \u00e9 parte da Amazon.<\/p>\n

Em novembro de 2017, percebemos que era hora de trocar o hipervisor.<\/p>\n

O novo hipervisor foi desenvolvido com base em m\u00f3dulos aprimorados do n\u00facleo KVM.<\/p><\/blockquote>\n

Isso permitiu reduzir drasticamente as sobrecargas de emula\u00e7\u00e3o de dispositivos e trabalhar diretamente com os novos ASIC. As inst\u00e2ncias C5<\/strong> foram as primeiras m\u00e1quinas virtuais a implementar o novo hipervisor. N\u00f3s o chamamos de Nitro<\/strong>.<\/p>\n

\"ComoA evolu\u00e7\u00e3o das inst\u00e2ncias na linha do tempo.<\/em><\/p>\n

Todos os novos tipos de m\u00e1quinas virtuais que surgiram desde novembro de 2017 operam nesse hipervisor. As inst\u00e2ncias Bare Metal n\u00e3o t\u00eam hipervisor<\/strong>, mas tamb\u00e9m s\u00e3o chamadas de Nitro, pois utilizam placas Nitro especializadas.<\/p>\n

Nos dois anos seguintes, o n\u00famero de tipos de inst\u00e2ncias Nitro ultrapassou duas dezenas: A1, C5, M5, T3 e outras.<\/p>\n

\"Como
\nTipos de inst\u00e2ncias.<\/em><\/p>\n

Como s\u00e3o as modernas m\u00e1quinas Nitro.<\/h3>\n

\nElas possuem tr\u00eas componentes principais: o hipervisor Nitro (mencionado acima), um chip de seguran\u00e7a e as placas Nitro.<\/p>\n

O chip de seguran\u00e7a<\/strong> est\u00e1 integrado diretamente na placa-m\u00e3e. Ele controla v\u00e1rias fun\u00e7\u00f5es importantes, como o controle de inicializa\u00e7\u00e3o do sistema operacional host.<\/p>\n

As placas Nitro<\/strong> s\u00e3o de quatro tipos. Todas foram desenvolvidas pela Annapurna Labs e baseiam-se em ASICs comuns. Parte de seu firmware tamb\u00e9m \u00e9 comum.<\/p>\n

\"Como
\nQuatro tipos de placas Nitro.<\/em><\/p>\n

Uma das placas \u00e9 destinada ao funcionamento com a rede<\/strong>VPC<\/strong>. Ela \u00e9 vis\u00edvel nas m\u00e1quinas virtuais como uma placa de rede ENA \u2014 Elastic Network Adaptor<\/strong>. Ela tamb\u00e9m encapsula o tr\u00e1fego ao transmiti-lo pela rede f\u00edsica (sobre isso falaremos na segunda parte do artigo), controla o firewall Security Groups, \u00e9 respons\u00e1vel pelo roteamento e outras fun\u00e7\u00f5es de rede.<\/p>\n

Placas separadas trabalham com armazenamento em bloco EBS<\/strong> e discos integrados ao servidor. Para a m\u00e1quina virtual hospedeira, elas se apresentam como adaptadores NVMe<\/strong>. Elas tamb\u00e9m s\u00e3o respons\u00e1veis pela criptografia de dados e monitoramento de discos.<\/p>\n

O sistema de placas Nitro, do hipervisor e do chip de seguran\u00e7a \u00e9 integrado a uma rede SDN ou Software Defined Network<\/strong>. A gest\u00e3o dessa rede (Control Plane) \u00e9 responsabilidade controlador de mapa<\/strong>.<\/p>\n

Claro, continuamos desenvolvendo novos ASIC. Por exemplo, no final de 2018, lan\u00e7amos o chip Inferentia, que possibilita um trabalho mais eficiente em tarefas de aprendizado de m\u00e1quina.<\/p>\n

\"Como
\nProcessador de Aprendizado de M\u00e1quina Inferentia.<\/em><\/p>\n

Banco de dados escal\u00e1vel<\/h2>\n

\nUm banco de dados tradicional possui uma estrutura em camadas. Simplificando bastante, os seguintes n\u00edveis podem ser destacados.<\/p>\n