Estamos criando o melhor sistema de detecção de empréstimos na Rússia e nos países vizinhos. Em um mundo ideal, lidaríamos apenas com o design e o desenvolvimento do sistema. Mas, infelizmente, o Anti-plágio não funciona no vácuo e, para que nossos usuários usem nossos desenvolvimentos de maneira conveniente e confortável, também precisamos desenvolver o ambiente em torno de nosso serviço. Nosso software ainda não funciona sem ferro de passar, os usuários precisam fornecer suporte técnico, é necessário receber pagamento dos usuários sem violar a lei etc. Em suma, a rotina é suficiente.

Este artigo é o primeiro de uma série de dramas de produção sobre como melhoramos nosso serviço com a terceirização. Compartilhamos problemas e conclusões reais.

Nuvens, cavalos de cabelos loiros ...

^{(de algum lugar da Internet, vi pela primeira vez aqui .)}

A carga no nosso sistema é muito desigual: em primeiro lugar, durante o dia, a carga muda 5 vezes. Em segundo lugar, há uma sazonalidade pronunciada. O máximo diário de verificações após o final da sessão de verão é reduzido em 10 vezes! A sessão de inverno não é tão brilhante, mas também não é um presente. Além disso, cada sessão de verão subsequente é mais pesada (em termos de número de verificações) e mais difícil (novas tecnologias e funcionalidade de pesquisa) da anterior. Portanto, por um lado, quero ter um bom suprimento de recursos, por outro lado, não pagamos muito durante um declínio na atividade. Em uma sessão, você pode implantar mais servidores e, no verão, reduzir a quantidade de recursos consumidos. Obviamente, esse é apenas o caso dos provedores de nuvem. Neste artigo, falarei sobre vários aspectos da interação com vários provedores de nuvem (AWS, IT Grad, MCS, YC). Se alguém parecer que isso é um grito da alma, ele não ficará muito enganado. Então vamos lá!

Aws

Começamos a usar os recursos da nuvem em fevereiro de 2013, quando alugamos nosso primeiro servidor na AWS. De fato, a Amazon é a primeira e mais antiga experiência Anti-Plágio com as nuvens. Em seguida, começamos com uma máquina e agora nosso orçamento na AWS é uma ordem de magnitude maior que o orçamento para todas as nuvens russas. O primeiro amor, como você sabe, nunca é esquecido. Todos os problemas e oportunidades com outras nuvens neste artigo foram considerados com base na experiência do uso da AWS.

É verdade que também havia uma mosca na pomada nas relações com a Amazônia. A seguir, apresentamos os recursos ou inconvenientes que temos com a Amazon:

1. Você não pode acessar o console de uma máquina virtual através de um navegador. E às vezes aqui é realmente necessário! Uma vez que excluímos por engano a interface de rede, o acesso foi perdido em uma das máquinas. Por sorte, alguém já havia encontrado esse problema. Em meia hora, encontramos e aplicamos a solução com sucesso. Através do console, essa operação pode ser feita em um minuto.
2. Os custos são em dólares e ganhamos em rublos. Assim, a lucratividade depende do dólar.
3. Não há data center na Rússia, o mais próximo quando começamos era na Irlanda. Isso significa um grande ping e algumas restrições no armazenamento de dados que surgem devido aos requisitos da lei russa.
4. Roskomnadzor bloqueia regularmente os endereços da AWS. Atualmente, há disponibilidade de servidor diferente na AWS em sites diferentes. Por motivos desconhecidos, a conexão com a máquina pode cair. Normalmente, alterar o endereço IP, a VPN e o proxy ajuda.
5. A Amazon é significativamente mais cara que as nuvens russas. É verdade que você pode reduzir o custo através de um programa de backup flexível e do uso de instâncias spot . E estamos usando ativamente os dois. Infelizmente, ainda não vimos essa funcionalidade nas nuvens domésticas (atualização: a YC anunciou “VMs interrompidas” no boletim de notícias de 18 de fevereiro, estamos aguardando detalhes).
6. O problema com mensagens insuficientemente informativas. Durante a transição da 3ª geração de máquinas para a 4 ou 5, o hardware virtual mudou seriamente, em particular, o método de conexão de unidades, e as máquinas simplesmente não foram iniciadas após a alteração do tipo. A interface de gerenciamento da instância retornou uma mensagem concisa: capacidade insuficiente. Havia limites suficientes para criar os tipos necessários de máquinas com uma margem e, por cerca de seis meses, torturamos sem sucesso o suporte técnico gratuito às custas da alteração dos limites. Não ajudou. Como resultado, eles mesmos pesquisaram a solução - uma recreação banal das máquinas ajuda.
7. Algumas vezes apagamos os SSDs em falhas: os discos simplesmente desapareceram do sistema junto com todos os dados. Dado que estes eram discos efêmeros , ou seja, os dados são perdidos quando a máquina para, não armazenamos algo insubstituível neles.

Em princípio, era possível conviver com essas deficiências. No entanto, exatamente no momento em que a Amazon finalmente percebeu o mercado russo, nossa conta não se tornou muito conveniente para o pagamento com cartão. Felizmente, a Amazon rapidamente corrigiu a situação e nos forneceu um gerente de contas que nos ajudou a deixar de pagar através de um cartão para um contrato direto, pagar uma fatura e elaborar vários tipos de acordos. Em geral, ele vem regularmente à Rússia e, quando chega até nós, fala sobre oportunidades para otimizar a infraestrutura e o pagamento. Às vezes, ele traz com ele um arquiteto de soluções, com o qual ele pode discutir a arquitetura atual de nossa solução, falar sobre “lista de desejos” e problemas e obter várias soluções, não apenas através dos serviços da AWS. Os funcionários da Amazon declaram que seu objetivo não é fornecer mais serviços, mas garantir que os serviços adquiridos beneficiem os negócios. Parece que isso é realmente verdade. O número de serviços, a velocidade de seu desenvolvimento e a profundidade da integração mútua são impressionantes. A AWS tem tudo para organizar o processo de desenvolvimento e a operação de sistemas altamente carregados de qualquer escala. Até agora, apenas um problema global é caro!

IT Grad 2016

Em 2015, decidimos que era hora de abandonar completamente nosso próprio ferro. Eu queria colocar os problemas na confiabilidade do equipamento especificamente em outros e me concentrar mais na melhoria dos processos de nosso próprio desenvolvimento. De acordo com nossas previsões, em 2016 teríamos o suficiente do equipamento que possuímos no momento e gostaríamos de ter uma reserva para todos os eventos de incêndio. Abordamos minuciosamente a escolha do fornecedor: preparamos um teste de carga e um questionário com perguntas importantes para nós e escolhemos meticulosamente cinco fornecedores: ActiveCloud, Cloud4Y, CloudOne, IT Grad, Softline.

Como resultado, optamos pelas nuvens de TI Grad. Suas vantagens:

1. Posição de vida ativa, respostas às nossas perguntas foram dadas rapidamente, era fácil de se comunicar.
2. A presença de unidades SSD rápidas, até 30 IOPS por GB. O número de operações de leitura aleatória é um indicador muito importante para nós, pois valores altos nos permitem colocar nossos módulos de digitalização na nuvem.
3. Plataforma VCloud com a capacidade de controlar máquinas e a presença de um console para cada máquina.
4. A capacidade de aumentar os recursos de uma máquina virtual sem reiniciar.
5. Faturamento flexível - o pagamento é feito pelos recursos que estavam em uso no dia no meio do período do relatório (nos dias 14 a 15 de cada mês). Além disso, existe uma opção "Pague conforme o uso", no entanto, é mais cara e o cálculo da quantidade de recursos consumidos é feito pela carga média de CPU e RAM a cada 2 horas.

Em 2016, nos mudamos para o IT Grad. Aqui está o que aconteceu nos três anos incompletos de nossa vida juntos:

1. Uma vez tivemos um problema. Exatamente às 21:00, começou uma queda drástica no desempenho. O número de verificações que o sistema poderia fazer caiu de 150 para 20-30 por minuto, enquanto depois de algumas horas tudo foi restaurado e resolvido a uma velocidade de 600 verificações por minuto. Pesquisamos uma semana em casa, verificamos usuários, pegamos bots e DDoS, mas não encontramos nada. Voltamos ao suporte da IT-Grad e descobrimos que "ah, e estamos fazendo backups aqui". Como resultado, eles nos esmagaram com uma fonte de problemas para diferentes sistemas de disco e configuraram o trabalho.
2. Normalmente (recursos de uso do produto), durante uma sessão, nosso tráfego excede 100 megabits por segundo. A propósito, esse valor geralmente é definido por padrão para o canal não reservado em muitos provedores de nuvem. Quando cruzamos essa fronteira, surgiram vários problemas: o Edge interno não conseguia lidar com a VPN entre o ponto de entrada localizado em nossos equipamentos e a máquina virtual do servidor da Web localizado na nuvem. Como esperado, eles se voltaram para o suporte, onde nos foi oferecido o aumento de recursos no Edge. Ok, sem dúvida, substituímos sua configuração de pequena para grande e também expandimos o canal para o tamanho do nosso pico de tráfego com uma margem. Não ajudou. Em geral, não conseguimos encontrar a solução ideal, tive que reduzir o volume de tráfego movendo parte da produção para outros sites.
3. Às vezes, a conexão VPN ao site IT Grad é interrompida por 1-2 minutos. Para a pergunta de por que isso acontece, nem nós nem o suporte técnico podemos encontrar a resposta. Até agora eu tenho que conviver com esse problema.
4. O mecanismo para redimensionar recursos funciona mal, tanto em tempo real quanto no estado desligado. Parece-me, no entanto, que isso é um problema com o fornecedor da plataforma (VMware). No entanto, já descobrimos o fato de que, para aplicar todas as extensões de maneira confiável, era necessário reiniciar a máquina convidada (Windows Server 2012 R2). Após o redimensionamento, a própria máquina não inicializou várias vezes. O suporte solucionou esse problema das 2 às 4 da manhã durante a sessão - nossa própria estação. Estava quente mesmo à noite!
5. Em 2016, tínhamos um monólito enorme, como o Everest, que exigia muitos recursos. Tantos que às vezes precisávamos exceder o tamanho máximo de máquinas convidadas recomendado para um determinado host. O suporte persistentemente nos pediu para reduzir o tamanho das máquinas virtuais para pelo menos metade do tamanho do host. Devemos prestar homenagem ao IT Grad - nos foi oferecido o uso de um hardware separado, com a capacidade de usá-lo inteiramente, por um pouco mais de dinheiro, e a flexibilidade da nuvem foi perdida.
6. O faturamento uma vez por mês para medir a quantidade de recursos consumidos foi um truque para nós duas vezes. No início, perguntamos diretamente sobre a oportunidade de reduzir recursos entre 14 e 15 de um mês para pagar menos. Nós fomos respondidos diretamente que é assim que funciona. A primeira vez que isso nos atingiu dolorosamente durante a transferência de uma parte da venda para a nossa nuvem. O fator humano funcionou - eles tentaram terminar tudo rapidamente até o dia 14 e, em seguida, anotaram notavelmente. Na segunda vez, aproveitamos essa oportunidade após quase três anos de cooperação, após o qual fomos cobrados em média no 5º, 15º e 20º dia. Então, o fator humano funcionou para eles - depois da ligação, eles cometeram um erro a seu favor (o recálculo foi feito manualmente), pediu desculpas, deu um desconto.
7. O desempenho de discos e máquinas como um todo atendeu às características declaradas. No entanto, várias vezes não conseguimos entender por que tudo estava funcionando tão lentamente, até a interface desacelerou sem piedade. O suporte garantiu que tudo estava em ordem e que eles não tiveram problemas com o equipamento. O que aconteceu lá - nosso servidor naquele momento migrou para um host vizinho ou alguém fez backup do subsistema de disco - continua sendo um mistério para nós.
8. Os discos podem ser alternados entre máquinas de forma independente apenas por meio de suporte. No início do uso, era impossível ter discos de tipos diferentes na máquina; era necessário sair (iSCSI, Samba e NFS). Depois de algum tempo, o uso de diferentes tipos de discos em uma máquina tornou-se possível primeiro pelo suporte e depois por conta própria (aparentemente feito no vCloudDirector). A propósito, a atualização do sistema de gerenciamento de virtualização ocorre regularmente. Recebemos uma carta 1-2 vezes por mês, informando que por uma hora ou duas o sistema de controle de máquina virtual realiza trabalhos técnicos e ficará indisponível por algum tempo, as próprias máquinas continuam a trabalhar nesse momento.
9. Em 16 de fevereiro de 2018, uma parte de nossas vendas localizadas em IT Grad residia devido a problemas de fornecimento de energia do data center em que o equipamento estava localizado. Nós aprendemos sobre o incidente de fato; não conseguimos entrar em contato com o suporte técnico. Eu tive que ligar para o nosso gerente de contas, ele imediatamente disse em um minuto o que e como, e desconectou, aparentemente dizendo o resto. Do agradável - estávamos deitados ao lado de VKontakte.

Depois de passar algum tempo em uma casa alugada e confrontado com tudo isso, em 2017, decidimos que era bom visitar, mas melhor em casa, e começamos a criar uma nuvem com discos NVMe rápidos e a capacidade de controlar tudo completamente. Assim que foi feito: eles transferiram as vendas para sua nuvem de clientes corporativos e módulos de pesquisa (no total, mais de 90% da carga), deixando monitoramento, estatísticas e clientes particulares no IT Grad. Em 2018, todos calcularam novamente e descobriu-se que era mais lucrativo dividir a produção: manter parte da nuvem alugada e parte própria. O que veio disso - contamos mais.

Soluções de nuvem de correio

Honestamente, eu queria, como na AWS, mas na Rússia. Portanto, começamos a olhar para as nuvens com conjuntos de serviços semelhantes (a quem estou enganando, pelo menos com o análogo de EC2 e S3). A pesquisa teve vida curta - encontramos a "Amazônia Russa" na pessoa do MCS . Uma grande empresa com uma ampla gama de serviços diversos, por todas as indicações, eles devem ser capazes de preparar as nuvens!

O começo do conhecido foi maravilhoso. Um gerente de contas veio ao nosso escritório, contou tudo em detalhes, descreveu as oportunidades e os planos atuais para o futuro próximo. A saída foi uma imagem maravilhosa: preços baixos para recursos de computação, existe um armazenamento de objetos e uma saída antecipada para a produção de banco de dados (semelhante ao RDS). Também recebemos um sólido limite de caixa para testes (ainda mais do que o Azure oferece).

Naquela época, já tínhamos a parte de IaC pronta para implantar todas as máquinas por terraform. O MCS tinha abertura aberta e era bem suportado! A propósito, o suporte técnico é realizado por meio de um canal de telegrama - comunicação "ao vivo" e é claro que eles querem ajudar. Existe um sistema de tickets, mas ainda não o usamos. SLA de Suporte Técnico refere-se a solicitações criadas no sistema de tickets.

Em dezembro de 2018, tínhamos escrito scripts de implantação de infraestrutura via terraform. Está na hora de mudar. Para começar, decidimos transferir o sistema com clientes particulares, que passaram todo esse tempo com equipamentos no IT Grad. Então tudo é como em um filme:

7 (), 18:00 . , .
10 (), 10:00 – .
12 () – .
10:00 terraform. , , .
12:00 ansible'. . !
15:30 . 30 , 16:30.
15:45 . .
15:55 . : , .
16:20 , . , . , - .
17:30 , , .
18:00 . 1,5 .


O problema identificado com diferentes formatos com uma nova tentativa não deveria ter aparecido, mas o encontramos e, por via das dúvidas, o corrigimos.

17 (), .
15:30 . , .
16:00 . .
16:30 , 100%. -? !
17:00 , , , , iotop, top, ProcessExplorer, PerformanceMonitor. .
21:45 , , , 2000 .
22:00 , .


O antigo produto da IT Grad atendeu facilmente à demanda adiada por verificações de usuários, sem problemas.

No dia seguinte (18 de dezembro), percebemos o seguinte:

1. Não sabíamos o que especificamente desacelerava o sistema. Antes do friso, praticamente não havia carga em lugar algum. Sim, ainda temos chamadas de bloqueio profundo dentro do sistema e provavelmente há um bloqueio em algum lugar, mas onde exatamente, não conseguimos, foi necessário investigar mais.
2. Nosso teste de carga atual não corresponde ao perfil de carga do prod. Foi incrível porque Graças a esse teste, nos preparamos para a última sessão, identificamos e eliminamos um grande número de gargalos. Mas essa é a realidade - é necessário refazer o teste com base na experiência adquirida.
3. Produzido em IT Grade com recursos comparáveis ​​de CPU e RAM, pode lidar facilmente com o dobro da carga.

Então, construímos rapidamente um teste que alcança o mesmo resultado que vimos em primeira mão. Fomos ao suporte do MCS para descobrir se estamos consumindo algum limite de CPU, mas em geral é nosso completamente ou não, e está tudo bem com a rede. Eles ainda não responderam à segunda pergunta, encontraram algo na terceira e nos recomendaram fazer alterações nos sistemas com vários núcleos. Em geral, desenvolvemos uma atividade vibrante, o fim do ano está próximo e todos querem sair para as férias com um sentimento de realização.

Aqui está o que acabamos trabalhando no MCS:

1. Mesmo no estágio de seleção, recebemos uma tabela com as características de hardware virtual e SLA por disco. Uma das vantagens foi que eles prometeram 50 IOPS / GB (IT Grad: 30 IOPS / GB) para o SSD. O contrato acabou sendo diferente: “lendo: 5000 IOPS, escrevendo: 2000 IOPS” e perdemos isso, não esperávamos isso. As mesas são idênticas, a diferença está em apenas um lugar! A propósito, não vimos as dependências de desempenho no tamanho do disco. Quando testamos, descobriu-se que, com uma unidade maior, a velocidade diminui. O segredo desses indicadores pequenos é que o MCS possui ceph geodistribuído, o que significa que até que o nó remoto diga que os dados foram gravados, o cliente não será informado de que a gravação está concluída. A propósito, ninguém parece ter essa confiabilidade "pronta para uso" entre os provedores com quem conversamos. Mas, para nós, essa confiabilidade apenas coloca paus nas rodas! Se algo acontecer, precisamos mudar rapidamente para outro controlador de domínio quando surgirem problemas e, portanto, teremos nossa própria replicação assíncrona. Temos DRP e estamos preparados para a perda de uma pequena quantidade de dados em caso de acidente. Devemos prestar homenagem ao MCS, eles aceleraram o comissionamento de uma matriz SSD local, cujo desempenho foi muito maior.
2. Quanto aos parâmetros das máquinas, eles não são arbitrários. Há um certo conjunto de CPU-RAM- {SSD / HDD} (quase como na AWS) e outros tipos de máquinas podem ser criados apenas através do suporte. Todo o processo leva cerca de 2 horas, não há limite para o número de tipos, o principal é que o número de núcleos não deve ser superior a metade dos hypervisor ~ 40-48 processadores. Durante a criação da máquina, você pode adicionar discos e alterná-los entre máquinas.
3. Depois de ligar o SSD local, a alteração dos parâmetros da máquina impossibilitou a inicialização. Eles só poderiam ser lançados através do suporte. Em algum lugar em um mês, eles resolveram o problema.
4. Pela primeira vez, confrontado com o suporte técnico por telegrama. Em geral, é conveniente, especialmente no início, quando há muitas perguntas e há uma moagem no serviço. Porém, quanto mais longe, mais difíceis são as perguntas e a velocidade da resposta e do conteúdo da informação diminui lentamente. Até o final do ano, quando, é claro, os prazos de todos estavam cumpridos, a baixa velocidade das respostas me enfureceu terrivelmente. Em algum momento, eles até perguntaram sobre os SLAs. Foi aí que entendeu que o SLA está no sistema de tickets e não no telegrama! Em 19 de fevereiro, várias perguntas não respondidas, feitas em 24 de dezembro, estão neste canal ...
5. O suporte técnico através do sistema de tickets não leva em consideração que estamos conectados e requer uma notificação adicional do número do contrato. Em resposta, ele envia uma carta "entraremos em contato com você", mas não indica o número ou o status do ticket.

Enquanto trabalhava com o MCS, outra nuvem começou a parecer em paralelo.

Mais uma nuvem (Yandex Cloud)

O primeiro dos outros foi Yandex. No final de 2018, eles tinham apenas máquinas virtuais e armazenamento de objetos, seu próprio shell de sistema de virtualização, API aberta. O plugin terraform estava em alfa e foi aceito pela HashiCorp. O suporte, como sempre, é via telegrama, mas é menos ativo do que no MCS. O limite de dinheiro do teste é pequeno o suficiente e não nos permitiu realizar testes normais. Eu tive que concluir rapidamente um contrato (3 dias úteis) e pagar pelos testes. De acordo com os resultados do teste, obtivemos o mesmo que no MCS. Começou a nos parecer que havia dois problemas: todo mundo tem drives muito lentos e temos um teste muito severo.

Graduado em TI 2019

Em geral, estabelecemos um prazo para a mudança já em 22 de dezembro, para que houvesse mais uma semana para identificar e resolver os problemas ocultos de uma nova residência. Tendo perdido a esperança de passar para o prazo final e um pouco cansado da abundância de novas informações na pessoa do MCS e da YC, decidimos que o IT Grad não é tão ruim assim. Nós até nos sentimos um pouco nostálgicos e pensamos que tudo que é novo é antigo e bem estabelecido. Já na IT Grad, definitivamente trabalharemos bem - há um precedente. Além disso, o IT Grad aumentou: havia um data center em Moscou, Nível III, tempo de atividade no momento em que ainda possui 100% (nunca falha) e o equipamento interno é Intel Xeon Scalable de 4 soquetes (até 42 núcleos x 3 Xeon Gold 6154 de GHz). Que diabos não está brincando, vamos dar uma segunda chance!

28 (), 18:10 - vDC , , .
29 ( ), 17:04 , . .iso , . , . , . , .
30 (), 22:00 , .iso, . , - .
31 (), 3:15 Edge vDC vDC. , . .

, .

2 (), 15:30 .
2 (), 21:50 , Guest OS Customization .
3 (), 18:05 !

1. Agora, na preparação do artigo, eles descobriram que o horário exato das solicitações e respostas não se reflete no sistema de tickets. Em vez disso, diz "cerca de 2 meses atrás", a hora exata é mostrada apenas em uma dica de ferramenta. Por correio, também é difícil restaurar a sequência de eventos. As mensagens enviadas pelo correio são lógicas não óbvias e não contêm uma descrição da ação. Os tickets são criados no sistema após algum tempo em nome de um funcionário do suporte técnico da IT Grad.
2. Após uma análise mais detalhada do equipamento após as férias, vimos o Xeon v2 lá. Não foi nisso que concordamos. Ok, decidimos esta pergunta com o gerente da conta. Houve algumas dificuldades devido ao fato de que, no novo ano de 2019, o IT Grad foi incluído no MTS e logo após as férias houve uma pequena bagunça. Do vDC em novos equipamentos no Moscow DC não era visível o vDC criado antes do ano novo. Somente através da Internet aberta, o suporte técnico nos agradou que a velocidade de movimentação não excede 1 TB / dia. E nós já carregamos 7 TB de dados! Como resultado, eles criaram um aplicativo para mudar na quinta-feira à noite. Um dia depois, na sexta-feira à noite, perguntei como você está e quando eles planejam começar (espere quase uma semana!)? Um dia depois, no sábado à noite, fomos informados de que todos os carros haviam se mudado. Não gostei daqueles 2,5 dias em que não havia informações sobre o andamento do trabalho e que as estimativas em andamento eram muito pessimistas.
3. Em setembro de 2018, quando começamos a implementar o IaC, percebemos que o terraform funciona muito mal com o vCloudDirector (atual: no momento da redação, aprendemos que o VMware vCloud Director Provider 2.0 apareceu , mas ainda não o testamos). No início, não conseguimos nem criar uma máquina devido ao fato de que o vCloud nos informou de um erro no espírito de "algo deu errado, você tem um erro de 512 caracteres 136 linhas (a linha era mais curta!) Xml da configuração da máquina". Pedimos apoio. A pergunta foi redirecionada para os engenheiros; no final, fomos informados de que o terraform não é suportado - resolva você mesmo. De qualquer forma, descobrimos que o culpado era o empacotador, com o qual coletamos a imagem da máquina, ele não conseguia lidar com o formato de configuração proprietário do VMware. O Terraform é muito ruim com o vCloudDirector, tudo é encadeado lentamente e o conector foi abandonado por um longo tempo e não se desenvolve. Ninguém nos daria acesso ao vSphere. Se você permanecer no VMware, precisará ver sua automação através da API.

Organizamos uma bancada de testes em um novo local. O resultado foi incrível - o teste falhou, os sintomas são os mesmos do MCS. Provavelmente, no momento atual, no auge da batalha pela sessão, algumas configurações do sistema operacional foram alteradas que impedem o congelamento do sistema, mas que agora não podem ser restauradas. Para impedir que isso aconteça novamente, estamos apresentando o IaC. Realizamos mais 2 testes: criamos novas máquinas a partir de imagens limpas dos sistemas operacionais da venda atual - falha; nas máquinas de produção existentes - sucesso. Assim, foi confirmado que fizemos alguns ajustes no sistema operacional ou no banco de dados, mas não nos lembramos de qual deles. Nesse ponto, a solução do nosso desenvolvimento chegou a tempo: os frisos param quando sessões confiáveis ​​são desativadas no WCF.

Realizamos um teste de carga com as configurações recomendadas pelos desenvolvedores em paralelo no MCS (2 GHz, Xeon v4) e IT Grad (3 GHz, Xeon v2) - o número de núcleos e a memória é o mesmo. No MCS, o teste passou mais rápido (um quarto) e mais suave (no IT Grad, o teste foi instável, depois mais rápido e depois mais lento).

Comparação de desempenho de disco

Estávamos mais preocupados com o desempenho de discos para bancos de dados e índices, motivo pelo qual testamos principalmente SSDs. Não julgue estritamente pelos testes, quando precisávamos entender o desempenho das nuvens, no habr.com ainda não havia vários testes de discos, processadores, memória ( uma vez , dois ) provedores de nuvem. O tempo era limitado e precisávamos comparar rapidamente o desempenho para ter uma idéia da diferença de desempenho. Portanto, o requisito para o teste era um - ele pode ser repetido rapidamente em qualquer local. Usamos as máquinas o mais próximo possível dos parâmetros já implantados, fio - para testar o desempenho dos discos e pgbench - para avaliar o desempenho do banco de dados nesse disco. Como padrão, fizemos medições da produção atual - MARS (porque nosso equipamento tem o nome dos heróis da série animada sobre ratos de rocha de Marte ).

Normalmente, o desempenho do disco depende do tamanho. Observamos esse comportamento na cidade de TI e na AWS, mas no MCS não vimos essa dependência, ela também não existe no SLA e os testes deram um resultado paradoxal (e possivelmente impreciso) - o desempenho diminui com o aumento do disco.

Contamos as opções para discos HDD e SSD, bem como tps (transações por segundo) para o banco de dados postgres em discos SSD. Existem dois tipos de discos no MCS: SSDs e HDDs regulares com distribuição geográfica distribuída e SSDs locais (apenas em um DC) (seu desempenho é mostrado entre colchetes). Também em janeiro de 2019, na correspondência do MCS, lemos que eles aumentaram o desempenho do disco em 20%, o resultado do teste também está na tabela (MCS 2019). Em fevereiro, outra aceleração foi relatada, mas não realizamos testes aqui.

Resultados:

Metodologia de teste

iops foi calculado como a média de 4 execuções de fio:
/root/fio-2.0.9/fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

tps , como uma média de 3 execuções pgbench:
pgbench -c 10 -j 2 -t 10000 example

Descrição dos stands

Marte

Xeon v4, 2 GHz ; HDD: ceph, 3 nós de 9x 2Tb ST2000NX0253, réplica 2; SSD: ceph, 3 nós em 2 TB NVMe Intel DC P4600, réplica 2

CPU : 4, RAM : 8GB, HDD : 32GB, SSD : 150GB; A produção paralela está girando.

Graduado em TI

Xeon v4 / v2, 2 GHz ; HDD : 0,1 IOPS / GB ; SSD: 30 IOPS / GB

CPU : 4, RAM : 4GB, HDD : 250GB, SSD : 200GB

Mcs

Xeon v4; HDD: r / w: 1500/1000 IOPS; SSD: r / w: 5000/2000 IOPS

Para testar HDD: CPU : 2, RAM : 4GB, HDD : 50GB

Para testar SSD, TPS : CPU : 8, RAM : 16GB, SSD : 600GB

Y

Xeon v4, 2GHz

CPU : 8, RAM : 8GB, HDD : 20GB, SSD : 50GB

Comparação das estimativas de TCO para o ano

Contamos com o TCO para quatro opções. Os valores relativos são mostrados na tabela abaixo. Devo dizer que este é um cálculo para o nosso caso específico e tudo pode ser diferente para você.

Fizemos o cálculo da seguinte maneira. O ano foi dividido em duas partes: sessões (com maior carga de trabalho) e o resto do tempo. Para cada parte, foi calculada a quantidade necessária de recursos de CPU e RAM. O volume de disco necessário, devido ao constante crescimento do serviço, cresce apenas com o tempo, portanto, levamos a média entre o início e o final do ano para avaliação.

Houve pouca dificuldade em avaliar com a AWS, pois não há custo direto para o kernel e gigabytes de memória. Pegamos três máquinas mínimas c5.large, r5.large e m5.large e calculamos seu custo aos preços do MCS (alterando proporcionalmente o custo do núcleo da CPU, pois o MCS tem uma frequência de 2 GHz). Aconteceu assim: em média, o custo de instâncias simples da AWS é 2,5-2,8 vezes maior que o custo do MCS. A AWS publica preços sem IVA. Portanto, para o custo da AWS, adicionamos 20%, a taxa média anual do dólar é de 70 rublos. Os discos são considerados simplesmente pelos preços do EBS (usamos diferentes tipos de gp2, sc1, st1). Em alguns lugares, precisamos de unidades NVMe de instâncias da família i3. O preço por gigabyte é calculado de maneira muito simples: a diferença de custo entre o i3 e um processador análogo e a instância de memória da família r4, dividida pela quantidade de NVMe. Acontece 3,1 rublos por gigabyte em 30 dias.

Mesmo na conversa sobre orçamentos, gostaria de observar a diferença no custo de uma licença do Windows para um núcleo por mês para todos os provedores de nuvem. Na AWS, a diferença entre o custo das instâncias do Linux OnDemand e do Windows OnDemand dividido pelo número de núcleos é uma constante de cerca de 2.800 rublos por mês. No YC, a licença do Windows para o kernel é 3 vezes mais barata, cerca de 900 rublos por mês, e no MCS, quase 9 (!) Vezes mais barata, cerca de 300 rublos por mês. Ainda estamos muito dependentes do Windows: agora, graças ao núcleo .net, estamos começando a criar uma plataforma cruzada contra o plágio, inclusive para reduzir o custo de manutenção.

O custo agregado da YC também inclui o custo do tráfego.

Conclusões

Através das nuvens

AWS Eles dizem que na Rússia existem 4 bons provedores de nuvem: AWS, GCP, Azure e DO, e todos eles não estão na Rússia.
Prós: ótimo serviço, equipamentos modernos de alta qualidade, boas configurações no EC2, um grande número de serviços.
Contras: caro (mais riscos de taxa de câmbio) e não na Rússia (ILV, o grande firewall russo no horizonte). Eu realmente quero que nossas nuvens sigam este exemplo a seguir.
Recursos: O suporte técnico gratuito pode resolver um mínimo de problemas, mas, para ser sincero, entramos em contato apenas para expandir os limites de uso. Pago, a propósito, custa cerca de 10% da conta.

Graduado em TI . Bom serviço para a nuvem corporativa. Existem análogos de EC2 e S3 baseados no Swift.
Prós: bom desempenho (CPU 1-2-3 GHz, SSD, HDD), equipamento novo (em um dos DCs) entre nuvens domésticas, configurações arbitrárias da máquina.
Contras: cobrança incompreensível, VMware (interface flash mal automatizada), um pouco de caos e goivagem no suporte técnico.
Recursos: aprimorados mais no uso corporativo (depois de configurados, depois em mudanças raras) do que em um sistema público altamente carregado (atualizações frequentes, alterações constantes). Desde 2019, os negócios de IaaS são vendidos junto com pessoas e equipamentos na MTS, agora tudo pode mudar em qualquer direção. Comunicação através do sistema de tickets e telefone, gostaria de uma reação mais rápida e uma mensagem dos prazos previstos.

MCS . Existem análogos dos serviços EC2 (existem GPUs), S3, ECS, RDS, EMR, serviços próprios: Machine Learning, Recuperação de desastres na nuvem, Backup na nuvem
Prós: barato, desenvolvendo ativamente, existem GPUs (Tesla V100 e Grid K2).
Contras: drives lentos, húmido e mau karma da empresa-mãe.
Recursos: o suporte técnico no início é útil, um grande número de funcionários liga, ajuda é sentida, mas há um declínio notável na atividade (eles não responderam nada desde 24 de dezembro, estou até preocupado com os caras).

YC . Temos muito pouca experiência em trabalhar com esse provedor, é difícil dizer algo específico. Existem análogos de EC2, S3, RDS, DS, SQS (alfa), ELB (alfa), seus serviços exclusivos: SpeechKit, Translate.
Prós: as unidades são mais rápidas que o MCS.
Contras: o provedor de terraformação é úmido; o software do shell de virtualização com API aberta não é muito grande para a comunidade, o que significa que, até o momento, você pode confiar apenas nos pontos fortes da equipe do YC no desenvolvimento do provedor para terraform.
Características: pagar pelo tráfego.

Lições aprendidas

1. Percebemos que os testes de estresse são moralmente obsoletos. Eles atualizaram o teste, encontraram novos gargalos, os corrigiram e melhoraram o produto. Lembramos que o teste de carga deve ser adequado e deve haver configurações nas quais ele definitivamente não passa, para que você possa ver o limite de sua aplicabilidade.
2. Apesar da crença generalizada de que o software não está sendo otimizado no momento e que todos os gargalos estão sendo inundados com recursos, tivemos que descobrir e otimizar nosso sistema. Acabou melhor do que era, a nova versão do Anti-Plágio requer menos recursos e funciona mais rápido. Já descrevi vários outros lugares onde você pode reduzir o consumo de recursos.
3. Fizemos a IaC, implantamos e atualizamos através do ansible, aprendemos a passar de nuvem em nuvem (com replicação preliminar de dados) em quase 10 a 15 minutos. Se os dados são copiados e a replicação regular é configurada, aqui está o Plano de Recuperação de Desastres: movendo-se em meia hora com perda de dados nos últimos 15 minutos.

O que queremos das nuvens

1. Respostas rápidas do suporte técnico. Infelizmente, não podemos usá-lo como na AWS, até agora - há muito pouca informação disponível.
2. Suporte para automação da implantação da infraestrutura por meio de fundos gratuitos (terraform).
3. Previsibilidade no desempenho. Isso se aplica a cobrança, desempenho da CPU, RAM e discos.
4. A presença de análogos funcionais EC2, S3, RDS agora. Num futuro próximo, precisamos de suporte para cálculos de k8s e GPU (já o usamos na AWS).

Além de mudar para as nuvens, nos últimos meses, conseguimos tocar o ancinho em outras áreas. Como foi - contaremos um pouco mais tarde.