A história da economia industrial é a história do consumo de um recurso limitado. No caso da eletricidade, houve um pico acentuado da noite e, portanto, os proprietários das usinas fizeram lobby com o transporte urbano moderno e criaram do zero, de fato, a indústria de eletrônicos de consumo. Ou seja, eles mudaram o modo de vida de milhões, para que as usinas sejam carregadas de maneira mais uniforme.
Os recursos de computação têm uma história semelhante. Raramente alguém os usa de maneira totalmente eficaz. Vamos falar sobre exploração e um pouco sobre a próxima geração de programação para ambientes em que é muito flexível o compartilhamento de recursos.
Consumo sazonal
O consumo sazonal de um cliente sazonal parece ter 11 meses de calma e um mês de carga tripla dupla. Todo mundo conhece o seu pico. O varejo congela todas as atividades até dezembro e as vendas de ano novo, obtém máquinas virtuais. Todo mundo ainda tem sua própria temporada de descontos e grandes vendas - para alguém em 1º de setembro, para presentes em 8 de março e assim por diante. Todos os serviços B2C têm atividade sazonal compreensível apenas com horário comercial, por exemplo, com bancos na Internet. Nós da Technoserv Cloud não planejamos trabalhos de manutenção para esses períodos.
Os geólogos chegam em casa da expedição e começam a contar seus fósseis na nuvem. Nas grandes empresas, os relatórios até o final do período são coletados de vários subsistemas - em algum lugar eficiente e em algum lugar com um rangido, quase ao ponto do impacto. O aprendizado de máquina e a análise fornecem cargas muito grandes, mas eles não fazem isso permanentemente.
Os picos de verão são uma indústria turística, mas não têm saltos significativos, mas há DDoS na temporada, geralmente quando as pessoas vão comprar ingressos para as férias de maio.
Consumo normal
Nosso cliente médio em nossa nuvem consome recursos por "serra diária": de manhã, no início do dia útil, o aumento começa, no almoço, um pequeno declínio, à noite, um decréscimo de 2-3 vezes. À noite, são executadas tarefas do sistema - backups, dados excedentes em análises, inventário de varejo e cálculos de inventário de logística, previsões de vendas. O Financeiro possui diferentes históricos de crédito e outro cache. Não há ABSs na nuvem, eles, as operadoras de telefonia móvel e empresas como ferrovias limpam à noite, ou seja, o saldo diário de todas as operações é reduzido. Isso, relativamente falando, não é entrar à noite, mas coletar transações semelhantes em pacotes e compensar-se durante o período.
Em geral, um escritório comum "serra". Os administradores mais avançados já prescrevem escala, mas até agora vemos apenas exemplos isolados.
Em um caso simples, é assim: crie outra máquina virtual às 11h, coloque-a com serviços no balanceador, imigre suavemente às 19h e pague. Ou seja, o pagamento é apenas um terço do dia e, nos horários de pico, a disponibilidade é a mesma do aluguel permanente de uma máquina virtual adicional.
Isso ocorre porque temos discretização de relógio Nossos clientes geralmente estão interessados em outra variação desse script - o dimensionamento automático. Quando o consumo de recursos aumenta para 80%, outra máquina aumenta. Caindo até um certo limite - o carro desliga. No contrato financeiro, temos o pagamento conforme o uso, ou seja, pós-pagamento pelos recursos realmente consumidos, quantização das VMs por hora. No console, você pode elevar vários carros você mesmo. O administrador entra e faz isso com as mãos sob cargas (por exemplo, na Black Friday, quando a carga no site aumenta) ou ele escreve um script que inicia e extingue a VM. Há uma empresa, desenvolvedores, condicionalmente, de aplicativos bancários - eles precisam de dimensionamento automático para testes e picos de moagem do banco de dados. Eles possuem uma arquitetura muito adequada para automação e, com eles, testamos um sistema totalmente automático quando a própria nuvem aloca a quantidade certa de VM. Ou seja, como, por si só - através de um servidor vitnes separado (uma VM dedicada ou uma máquina externa), que pode gerenciar a carga, a distribuição de aplicativos e o balanceamento por meio da API. Eles obtêm o escalonamento automático primeiro, ajudam a priorizar corretamente. E, ao mesmo tempo, eles trabalham como testadores para nós, de fato. O produto foi escrito de forma muito barata, de acordo com as necessidades deles: não temos um serviço na nuvem como um serviço de plug-in, mas estamos experimentando. Até agora, tudo é manual, além deste alfa: temos todos os relatórios e conversas detalhadas do tecnólogo do produto com seus desenvolvedores para o trabalho. Assim, nasce um produto que será necessário para todas essas equipes.
Recursos de arquitetura de software
Por que existem poucos administradores de escalonamento automático, embora isso seja mais rentável? Como para dimensionar corretamente a carga na nuvem, você deve ter uma arquitetura de aplicativo e banco de dados preparada. Se um aplicativo como um front da Web geralmente é escalonado facilmente, a gravação no banco de dados já é uma questão mais interessante. Nem todos os aplicativos são simplesmente divididos em front-back ou microsserviços para distribuí-los em máquinas diferentes.
Aqueles que o têm - aqueles, é claro, salvam. E eles obtêm uma vantagem pela estabilidade, sobre a qual escrevemos aqui em um post sobre
erros comuns de arquitetura .
Naturalmente, você precisa reescrever o software para isso. O que nem sempre é possível rapidamente e nem sempre é possível em princípio.
Mas a próxima geração da história da nuvem parece ainda mais interessante.
Virtualização de contêiner
A próxima geração é de contêineres. Agora parece um tipo de máquinas virtuais leves com microsserviços que aumentam durante o manuseio e são descarregadas da RAM na ausência de atividade. Ou seja, eles aparecem e são substituídos como aplicativos na RAM e na troca de sistemas operacionais modernos - à medida que são usados. Parece simples, e muitos dos principais players já reescreveram sua arquitetura especificamente para contêineres.
Ou seja, essas nem são VMs separadas, mas simplesmente processam nelas, algo como aplicativos Citrix Xen. Ou as boas e antigas VMs no shell do contêiner - ou seja, as mesmas máquinas com dimensionamento automático profundo.
Mas este é apenas o primeiro passo. O fato é que, ainda mais interessante, é a conteinerização de funções. Isso ainda é uma fantasia dos arquitetos, mas se você escrever o código imediatamente no sistema de contêineres pop-up, poderá envolvê-lo em todas as funções. Existe entrada, saída e existe uma "caixa preta" - o próprio contêiner. A função é chamada no código - o contêiner "apareceu", funcionou e voltou a aguardar a próxima chamada.
O código, é claro, terá que refatorar e otimizar novamente o todo. Mas vale a pena, e este é um dos possíveis ramos do futuro. De acordo com nossa avaliação, é verdade que é muito distante - três anos pelo menos até as primeiras implementações dos gigantes e 15 anos antes do uso industrial na Rússia.
Enquanto isso, os contêineres - infelizmente, um produto para geeks, porque eles não funcionam muito bem. E não há pedidos para eles na Rússia, mas há pedidos para dimensionamento automático. E nem um único novo contrato é assinado sem pagamento conforme o uso.