A evolução dos aplicativos HighLoad no exemplo de um portal regional de serviços públicos

“Amanhã é dia 20, o que significa que haverá uma tempestade novamente. É impossível pará-lo, apenas para nos preparar e torcer para que desta vez isso exploda, que um milagre aconteça e que nossa balsa do lago conquiste o oceano . ” Tais pensamentos dominaram a equipe envolvida no apoio ao portal de serviços municipais há vários anos. Como entramos nessa situação e como encontramos uma saída dela será descrito abaixo.

Como tudo começou

Na distante década de 1990, o setor de habitação e serviços públicos experimentou um boom em desenvolvimento, novas tecnologias foram introduzidas, sistemas de informação automatizados e novos equipamentos foram adquiridos. Mas algo permaneceu por um longo tempo praticamente inalterado, a saber, pagamentos pelo apartamento. Sim, esses mesmos recibos de um apartamento, transformados em documentos de pagamento, adquiridos códigos de barras, uma descriptografia detalhada, permaneceram como pedaços de papel. O esquema típico de trabalho do centro de assentamento da empresa de habitação e serviços comunitários ou empresa fornecedora de recursos era o seguinte:



Gradualmente, a Internet do modem foi substituída pelo acesso à banda larga, surgiu o pensamento - por que não receber documentos de pagamento on-line em formato eletrônico? Ao mesmo tempo, o setor de habitação e serviços comunais tremia de forma organizacional, os serviços de habitação e comunais do MPP (empresa municipal de produção de moradias e serviços comunitários) foram substituídos por empresas unitárias municipais (empresas municipais), DEZs (diretorias de um único cliente). Como resultado de todas as transformações, os departamentos de TI das empresas de habitação e serviços comunitários foram alienados e vários centros de assentamento nasceram em sua base. A essência dos centros de assentamento era, de fato, o cálculo do aluguel e suporte de informações da população.

Estágio de crescimento, 00s

Foi então que nasceram os primeiros portais de informação que forneceram à população serviços eletrônicos. O número de primeiros usuários foi medido em dezenas, nem todos confiaram em documentos de pagamento eletrônico, outros não ouviram falar de inovações, os aplicativos móveis no campo dos serviços públicos eram raros. O trabalho dos portais de informação não era muito diferente do trabalho de sistemas de informação familiares e, é claro, nunca foi uma arquitetura de alta carga.



Anos se passaram, os portais melhoraram, houve oportunidades para fazer leituras de dispositivos de medição, gerar certificados, etc. Foi nessa época que as primeiras “nuvens” apareceram no horizonte, mais e mais usuários começaram a se registrar em portais e solicitar dados. Ao longe, a primeira onda de cargas se aproximando apareceu.

A equipe (doravante denominada Equipe 1) adotou as seguintes medidas de otimização:

• Redimensionando um documento de pagamento em PDF de 0,5 MB para 0,2 MB
• Criando uma fila para a formação de documentos de pagamento
• Armazenamento de documentos de pagamento gerados para solicitação repetida
• Criando uma réplica do banco de dados principal, apenas para as necessidades do portal

Por vários anos, a situação pareceu estável, o número de usuários de portais individuais foi medido aos milhares, ainda não chegou à tempestade, mas abalou significativamente, a descentralização dos centros de compensação nas mãos dos desenvolvedores.

Fase do salto grande

Um novo marco na história foi o desenvolvimento de um portal de serviços municipais em nível regional. A inclusão de um único ponto de entrada para qualquer morador da república foi uma ideia tentadora; além disso, isso aumentaria a classificação do site estadual para o nível dos melhores sites comerciais ou bancários, onde cada morador da região receberia muitos tipos diferentes de serviços. Um dos mais populares poderia ser o pagamento de serviços habitacionais e comunitários e a inclusão de medições.

Assim, o próximo passo foi a separação das informações operacionais dos centros de liquidação das informações exibidas no documento de pagamento. Para isso, foi desenvolvido um formato simples de transferência de dados e um banco de dados para armazenamento de informações, e foi realizado o cálculo do espaço necessário para armazenamento por 5 anos de operação.

Principais decisões tomadas nesta fase:

• Departamento de informações parte do banco de dados operacional;
• Desenvolvimento de um banco de dados para armazenar este formato;
• Combinar os dados dos centros de liquidação das regiões em um único banco de dados;
• Integração com processos do portal, desenvolvimento de serviços.

Nesse estágio, a solução passou de uma infraestrutura completa para uma infraestrutura, pois o portal fornecia aos usuários uma única interface. O portal tinha uma equipe própria, que o desenvolveu independentemente da solução atual dos centros de assentamento. Em nossa história, a segunda equipe aparece (a seguir denominada Equipe 2) e um novo fornecedor. Como veremos mais adiante, isso afetou significativamente o desenvolvimento e a resolução de problemas. A essência da solução de design era a seguinte:



Ao projetar o banco de dados, um mapeamento simples do formato para o banco de dados foi aceito, o PostgreSQL 9.3 foi selecionado como DBMS (na época era uma versão muito atual). O formato consistia em 9 arquivos simples, cada um dos quais foi carregado pelo comando COPY (lemos - muito rapidamente) nas muitas tabelas de um centro de liquidação específico (cada centro de liquidação tinha seu próprio número de registro) do banco de dados do portal. Em alguns centros de liquidação, o número de registros necessários para a formação de documentos de pagamento chegou a 1.000.000.Em um ano, esse valor foi de 12.000.000, em 5 anos -60.000.000.O número de solicitações para esse banco de dados aumentou para a soma de todos os usuários dos portais distritais e pode compõem dezenas de milhares. Havia algo em que pensar.

Não tendo essa experiência, a Equipe 1 executou as seguintes etapas para reduzir a carga potencial:

• As tabelas foram divididas por centros de assentamento e meses de particionamento;
• O processo de carregamento de dados é espaçado no tempo para diferentes centros de cobrança.

Desafios de crescimento rápido demais

O portal foi lançado e os planos elaborados foram confrontados com a realidade:

• O número de usuários excedeu a estimativa muito rapidamente.
• As consultas foram para a tabela mestre, mas o DBMS ainda pesquisou todas as tabelas
• Carga falsa no servidor de banco de dados. Nesse servidor, havia outros bancos de dados incomparavelmente grandes, cujas informações vinham em momentos aleatórios, carregando todos os recursos disponíveis.
• O serviço de formação de um documento de pagamento foi desacelerado devido à implementação ineficiente
• A carga dos usuários não foi distribuída uniformemente ao longo do mês, mas concentrada em dois períodos:
  
  

Este momento é descrito no início do post. Foi difícil diagnosticar o problema, porque os problemas pareciam estar em todos os lugares ao mesmo tempo. A equipe 1 e a equipe 2, igualmente amadas por sua liderança, tomaram medidas para sair da situação, mas praticamente não havia comunicação entre si:



A equipe 2 , ao que parecia, deu um passo lógico e útil: a formação de um documento de pagamento começou a ser solicitada imediatamente após o usuário entrar no sistema, na expectativa de que, enquanto chegasse às páginas das páginas, o PA já estivesse formado, e o documento finalizado pudesse ser retirado rapidamente.

Nesse momento, a equipe 1 resolvia heroicamente um problema por mês todos os meses, convencendo cada vez mais o cliente de que estava ali a raiz do problema:

• SQL otimizado (recebeu um aumento de desempenho às vezes);
• Separou o servidor de banco de dados para o portal do restante dos bancos de dados;
• Realizamos a formação de um documento de pagamento em um aplicativo separado e também o otimizamos;
• Revisamos o recurso para a tabela principal, alteramos a versão do PostgreSQL;
• Mais uma vez, revisamos a apelação (agora apenas uma partição específica foi solicitada da tabela mestre - mesmo aceleração às vezes).

Os esforços heróicos das equipes levaram a sucessos locais (por 2-3 meses, parecia que o problema estava resolvido). Mas a realidade levantou novas notas introdutórias o tempo todo:

• O banco de dados já contém vários anos e cresceu mais de 1 TB;
• O número de usuários já era centenas de milhares.

Enquanto a luta estava em andamento, a Equipe 2 montou um teste de serviço automático, para que qualquer problema de desempenho fosse conhecido em questão de minutos e o problema aumentasse para os mais altos níveis de controle automaticamente por email.

No momento, no Time 1 :

• O tempo de arquivamento do banco de dados começou a exceder os limites permitidos (o serviço ficou indisponível);
• Uma chamada para o serviço afetou imediatamente muitos meses, respectivamente, gerou muitos pedidos;
• O DBMS se tornou pior no preenchimento de consultas devido a um aumento no número de tabelas (partições);
• Os usuários que desejavam apenas fazer leituras de instrumentos ainda solicitavam a formação de documentos de pagamento (lembre-se da decisão da Equipe 2).

Tornou-se claro que, do ponto de vista técnico, a solução havia atingido seu limite e era hora de começar a analisar o comportamento do usuário para otimizar processos ou alterar radicalmente as tecnologias.

Como resultado da análise (aqui está o tópico para um artigo separado), foram executadas as seguintes ações:

• Os dados foram cortados até os últimos 3 anos, pois não houve ligações no período anterior; desde então, o período antigo é cortado anualmente;
• Reduzimos o apelo à tabela principal para nos referirmos diretamente a uma partição específica (reduzimos a carga no DBMS).

Presente

Agora, o sistema é bastante estável, se encaixa dentro do prazo regulamentar e dos requisitos de características não funcionais, mas as nuvens voltaram a aparecer no horizonte:

• Um aumento adicional no número de usuários;
• Crescimento do número de domicílios atendidos;
• Aumentar a complexidade dos serviços prestados;
• Maior granularidade de dados disponíveis para os usuários.

Portanto, é elaborado um plano e está sendo elaborada a implementação das seguintes medidas:

• Análise do comportamento do usuário: quantos deles realmente estão visualizando o documento de pagamento e quantos simplesmente pagam o valor, como por um telefone celular;
• Formação preliminar de documentos de pagamento para os usuários que geralmente visualizam documentos de pagamento no momento de menor carga;
• Transição para tecnologias alternativas (sim, muitos dos que chegaram a esse ponto têm soluções muito mais avançadas que resolveram todos os problemas inicialmente, nos recursos de um telefone celular).

Parece que isso pode colocar um grande ponto otimista. Tudo bem feito: quem fez e quem teria feito melhor imediatamente. Mas amanhã haverá novos projetos Highload, novos problemas desconhecidos. Como se preparar para eles agora, o que pode ser previsto quando ainda não há dados?

Uma abordagem sistemática para resolver problemas

Podemos transformar a experiência em uma metodologia para abordar problemas em projetos Highload? Curiosamente, a resposta é SIM, tudo já foi inventado para nós e está dentro da estrutura da Teoria da restrição TOC . Apenas 5 etapas simples:

1. Encontre as limitações do sistema.
2. Decida como aproveitar ao máximo as limitações do sistema.
3. Subordine tudo o mais a esta decisão.
4. Expanda as restrições do sistema.
5. ATENÇÃO! Se a restrição foi removida nas 4 etapas anteriores, retorne à etapa 1, mas não permita que a inércia cause uma restrição no sistema.

A descrição dessa teoria e a essência das etapas estão bastante bem descritas na literatura no final do artigo, mas vou escrever minha visão no contexto do processo atual:

1. Restrição: hora da formação do documento de pagamento.
2. Solução: gere todos os documentos de pagamento antecipadamente ao baixar dados.
3. Subordinado à decisão: ao entrar em contato com o usuário, emita um documento finalizado.
4. Estenda a restrição: otimize o tempo para a formação do documento de pagamento.
5. Abandone o sistema de pré-formação para TODAS as famílias, defina uma nova restrição.

Essa abordagem reduziria o tempo de solução em vários anos, com custos mínimos de mão de obra para os programadores. O post indica longe de todos os problemas que surgiram e não há alguns detalhes das soluções, uma vez que não são tão significativos na abordagem proposta.

O que ler sobre o tópico:

1. O objetivo. Processo de Melhoria Contínua ”, Eliyahu Goldratt
2. “Teoria das restrições. Abordagens básicas, ferramentas e soluções ” , Dmitry Egorov
3. “Teoria das restrições de Goldratt. Uma abordagem de sistemas para melhoria contínua ”, William Detmer