Recentemente, o VTB alterou alguns dos componentes de hardware e software do sistema de fluxo de trabalho. As mudanças foram significativas demais para continuar trabalhando sem testes de carga em grande escala: qualquer problema com o sistema de suporte a documentos (LMS) está repleto de grandes perdas.
Os especialistas da Intertrust testaram o VTB SDO em equipamentos da Huawei - um complexo de farm de servidores, rede de dados e armazenamento baseado em unidades de estado sólido. Para testes, criamos um ambiente que reproduzia cenários reais com a carga máxima possível. Resultados e conclusões - sob o corte.
Por que precisamos de um sistema de fluxo de trabalho em um banco e por que testá-lo
O LMS no VTB é um pacote de software complexo, no qual todos os principais processos de gerenciamento estão vinculados. O sistema fornece serviços gerais de documentação, interação eletrônica, análise. Uma circulação bem organizada de documentos acelera as decisões de gestão, torna transparente e controlado o procedimento para sua adoção, melhora a qualidade da gestão e melhora a competitividade do banco.
O LMS deve garantir uma implementação clara das decisões, de acordo com os regulamentos estabelecidos. Isso requer alto desempenho, tolerância a falhas e escala flexível. O sistema possui altos requisitos para controle de acesso, o volume de documentos processados simultaneamente e o número de usuários. Agora, existem 65 mil deles no VTB SDO, e esse número continua a crescer.
O sistema está em constante evolução: a arquitetura está mudando, as tecnologias desatualizadas estão sendo substituídas pelas modernas. E, recentemente, alguns dos componentes do sistema foram substituídos por independentes de importação, sem software proprietário. A nova arquitetura SDO baseada no software CompanyMedia e no complexo de hardware da Huawei lidará com o aumento da carga? Responda sem ambiguidade a essa pergunta, sem esperar por uma situação semelhante na realidade, isso só foi possível com a ajuda do teste de estresse.
Além de testar o novo produto de software quanto à resistência ao estresse, realizamos as seguintes tarefas:
- determinar os parâmetros exatos do dimensionamento horizontal e vertical dos servidores para o perfil de carga do banco;
- verifique os componentes quanto à tolerância a falhas em condições de alta carga;
- identificar o coeficiente de entropia da interação intercluster com escala horizontal;
- tente dimensionar solicitações de leitura ao usar o balanceador de plataforma;
- determinar o coeficiente de escala horizontal de todos os nós e componentes do sistema;
- determinar o máximo possível de parâmetros de hardware dos servidores para vários fins funcionais (escala vertical);
- estudar o perfil de carga da aplicação na infraestrutura técnica, aproximar os resultados para planejar o desenvolvimento do sistema de informação;
- Investigue o impacto da consolidação de dados de aplicativos em um único sistema de armazenamento de dados na otimização de recursos, melhorando a confiabilidade e o desempenho.
Metodologia e equipamento
O teste de carga de sistemas de gerenciamento eletrônico de documentos geralmente é realizado de acordo com cenários simplificados. Eles simulam a localização e abertura rápidas de cartões de documentos que não estão associados a outros arquivos e não têm um histórico de ciclo de vida. Nesse caso, como regra geral, ninguém leva em consideração os direitos de acesso e outros fatores que consomem recursos, característicos de condições reais.
Geralmente, esses testes divorciados são realizados por fornecedores de soluções. É compreensível: é importante que um fornecedor demonstre a um cliente em potencial alto desempenho e velocidade do sistema. Não é de surpreender que modelos de teste simplificados mostrem tempos de resposta recordes do sistema, mesmo que o número de usuários e documentos aumente significativamente.
Precisávamos reproduzir as condições operacionais reais. Portanto, no início, coletamos estatísticas para um mês: registramos a atividade do usuário, observamos o trabalho em segundo plano de todos os serviços. Os sistemas de monitoramento integrados no LMS tornaram-se uma grande ajuda nesse assunto. Os funcionários do banco ajudaram a corrigir os dados resultantes sobre os fluxos de documentos, enquanto fizemos os ajustes para o crescimento projetado nos fluxos.
O resultado foi uma metodologia de teste, com a ajuda da qual foi possível simular os processos que ocorrem no sistema, levando em consideração todas as cargas reais. Na bancada de testes, reproduzimos - individualmente e em várias combinações - as operações comerciais mais comuns, bem como as solicitações mais demoradas. Durante o teste de desempenho, todos os componentes foram submetidos a estresse. Foram realizadas operações para calcular os direitos de acesso do usuário aos objetos do sistema, abrir documentos com uma hierarquia ramificada complexa e um grande número de links, pesquisar no sistema e assim por diante.
Perfil de teste de carga:
- usuários registrados: 65 mil com um aumento de até 150 mil;
- frequência de logins de usuários (autenticações): 50 mil por hora;
- usuários trabalhando simultaneamente no sistema: 10 mil;
- documentos registrados: 10 milhões por ano;
- volume de anexos de arquivo: 1 TB por ano;
- processos de aprovação de documentos: 1,5 milhão por ano;
- vistos das partes no acordo: 7,5 milhões por ano;
- resoluções e instruções: 15 milhões por ano;
- relatórios de resoluções e instruções: 15 milhões por ano;
- tarefas do usuário: 18 milhões por ano.
Essas aplicações foram consolidadas em um único sistema de armazenamento Huawei OceanStor Dorado 6000 V3 com 117 unidades SSD de 3,6 TB cada, o volume utilizável total é superior a 300 TB. A energia da computação foi colocada no sistema de servidor modular do Huawei E9000 e os dados foram transmitidos pela rede com base em comutadores do nível do datacenter da série Huawei CE. Durante o teste, observamos 24 horas por dia todos os indicadores do sistema. Todos os resultados, incluindo dados históricos, foram registrados na forma de gráficos e tabelas para posterior análise.
Carregar servidores de infraestrutura de hardware de teste
Devido ao alto desempenho do sistema de armazenamento Huawei OceanStor Dorado 6000 V3, os atrasos na execução de qualquer solicitação de usuário raramente excederam 1 ms. Essa velocidade do subsistema de disco do aplicativo nos inspirou a futuras pesquisas. Decidimos, analisando dados históricos, determinar o efeito de vários tipos de cargas de trabalho na infraestrutura técnica. Os resultados obtidos nos permitem planejar com flexibilidade e precisão o desenvolvimento do sistema de acordo com os requisitos da plataforma de hardware.
Em termos de escala, verificamos:
- limite de escala vertical do servidor de aplicativos (CMJ) , recursos de criticidade: número de núcleos e frequência, quantidade de RAM;
- suporte para dimensionamento horizontal do servidor de aplicativos (CMJ) duplicando serviços funcionalmente idênticos e balanceando entre eles;
- limites de escala vertical e horizontal do servidor do cliente (Web-GUI) ;
- limites de escala vertical do armazenamento de arquivos (FS) , recursos de criticidade: largura de banda da rede, velocidade do disco;
- suporte para dimensionamento horizontal do armazenamento de arquivos (FS) devido ao sistema de arquivos distribuído - CEPH, GLUSTERFS;
- limites de escala vertical do banco de dados (PostgreSQL) , recursos de acordo com o grau de criticidade: capacidade de RAM, velocidade do disco, número de núcleos e frequência;
- suporte para escalonamento horizontal de banco de dados (PostgreSQL) : escalonamento da carga de leitura em servidores escravos, escalonamento da carga de gravação com o princípio de dividir em módulos funcionais;
- limites de escala vertical e horizontal do intermediário de mensagens (Apache Artemis) ;
- limites de escala vertical e horizontal do servidor de pesquisa (Apache Solr) .
Problemas e Soluções
Uma das principais tarefas foi identificar possíveis problemas com o desempenho do LMS. Durante o trabalho, os seguintes gargalos foram identificados e foram encontradas formas de resolvê-los.
Bloqueia o log síncrono. As operações de log na configuração padrão do WildFly são executadas de forma síncrona e afetam bastante o desempenho. Decidiu-se mudar para um criador de logs assíncrono e, ao mesmo tempo, gravar não em um disco, mas no sistema de agregação de logs ELK.
Inicialização de sessões desnecessárias ao trabalhar com um data warehouse. Cada encadeamento que recebeu dados do repositório inicializou duas vezes uma sessão para autenticação no modo SSO. Essa operação consome muitos recursos e aumenta bastante o tempo de execução da solicitação do usuário, além de reduzir a taxa de transferência geral do servidor.
Bloqueia ao trabalhar com objetos de cache do aplicativo. O aplicativo usou bloqueios reentrantLock bastante pesados (Java 7), o que afetou adversamente a velocidade de execução da consulta. O tipo de bloqueio foi alterado para stampedLock, o que reduziu significativamente o tempo gasto no trabalho com objetos de cache.
Depois disso, lançamos novamente o teste de carga para determinar o tempo médio das operações típicas no sistema LMS com armazenamento relacional no perfil do banco. Obtivemos os seguintes resultados:
- autorização do usuário no sistema - 400 ms;
- vendo o progresso em média - 2,5 s;
- criação de um cartão de registro e controle - 1,4 s;
- registro e registro do cartão de controle - 600 ms;
- criação de uma resolução - 1 p.
Conclusões
Além de identificar problemas, o teste de estresse confirmou algumas de nossas suposições.
- O sistema funciona muito melhor na família de sistemas operacionais Linux.
- Os princípios declarados de garantir a tolerância a falhas funcionam no nível de cada componente em um modo "quente".
- Um componente-chave - o serviço de lógica de negócios (aceitando solicitações do usuário) - possui "espelhamento" de escala horizontal e escala quase linear de taxa de transferência com um aumento no número de instâncias.
- Dimensionamento ideal do serviço de lógica de negócios para 1200 usuários simultâneos - 8 vCPU para o serviço e 1,5 vCPU para o DBMS.
- A consolidação dos dados do aplicativo em um único sistema de armazenamento aumenta significativamente a produtividade e a confiabilidade, aumenta a escalabilidade.
Teremos o maior prazer em responder às suas perguntas nos comentários - talvez você esteja interessado em aprender mais sobre alguns aspectos dos testes.