O que é um sistema de informações altamente carregado como um enorme hipermercado? E se 150 milhões de pessoas vierem ao hipermercado ao mesmo tempo para fazer compras? Por que você pode punir o chefe de um hipermercado e por que não? Por que o tempo de carregamento do documento durante a noite é muito menor do que durante o dia? Por que o tempo de carregamento de um único documento realmente não significa nada?

Os sistemas de informações altamente carregados têm características próprias, o que não é óbvio para muitas organizações fornecedoras. Informaremos como o carregamento em massa de documentos (e outros dados) é organizado e consideraremos em detalhes essa pergunta incompreensível para muitos.

Fonte

Ao desenvolver sistemas de informação grandes e altamente carregados (IS), surgem tarefas de carregamento de dados em massa. O tipo de dados não importa e depende da sua área de assunto. Podem ser pagamentos, faturas, leituras de sensores, projetos de compras, etc. A criação e o desenvolvimento de SIG (sistemas de informação do estado) são regulados por lei e pode facilmente acontecer que a lei exija que as organizações enviem milhões de documentos para o sistema uma vez ou, mais interessante, enviem milhões de documentos periodicamente, por exemplo, mensalmente.

Em nossos projetos (um pouco sobre o trabalho da LANIT pode ser lido aqui e aqui ), periodicamente encontramos essas tarefas e desenvolvemos todas as soluções necessárias. No entanto, as especificidades das soluções têm alguns recursos que, como se viu, não são óbvios para muitas organizações fornecedoras. Para nossa surpresa, recebemos tais solicitações e até reclamações:

• “Enviamos um documento para download e demorou 10 segundos. Portanto, se nossa organização precisar carregar 100 mil documentos, levará 100.000 * 10/3600 = 277 horas para nós! ”
• "Carregamos, carregamos documentos, mas nada é carregado no sistema."

O fato de carregar um documento em um sistema de informação pode levar 10 segundos não diz nada sobre o sistema por si só. Este indicador não faz muito sentido se estamos falando de sistemas de filas. Em seguida, mostraremos como o carregamento em massa de documentos (e outros dados) é organizado e consideraremos em detalhes essa questão que não é clara para muitos.

Quanto aos erros de carregamento, nem tudo é óbvio: existem muitas razões pelas quais os dados não são carregados no sistema. Os problemas podem estar do lado dos provedores de informações e do IP. Abaixo, analisaremos diferentes situações e veremos as estatísticas.

Hipermercado chinês

Por exemplo, em uma província chinesa distante, onde vivem cerca de 150 milhões de pessoas, existe apenas um grande supermercado 24 horas onde as pessoas vão comprar arroz uma vez por mês. Os residentes podem vir buscar arroz em qualquer dia do mês. Há muito arroz, muito espaço no pregão. O principal gargalo é o pagamento das compras no caixa, uma vez que essa operação é obrigatória (você não pode ignorar os compradores sem pagamento), leva tempo e o uso de equipamentos especiais - caixas de dinheiro. Seria melhor para o hipermercado que as pessoas, de alguma forma, concordassem entre si e viessem às compras uniformemente (noite e dia); nesse caso, o uso de mesas de caixa seria o mais eficiente possível.

No entanto, por sorte, os compradores não vão para o hipermercado. Em primeiro lugar, eles de alguma forma não querem realmente fazer compras à noite. Em segundo lugar, às vezes são ilimitadas: ou não há ninguém, então vários milhões de pessoas chegam ao mesmo tempo.

Fonte O maior shopping center do mundo, o New Century Global Center, em Chengdu, na China. Possui 18 andares e uma área de 1.700.000 m².

O que fazer em um supermercado? O Partido Comunista Chinês estabeleceu a tarefa de servir todos os chineses, e é isso. Todo chinês não atendido é um sinal de menos para o carma do gerente do supermercado. Se houver muitos chineses insatisfeitos, não destrua a cabeça dele! Ao mesmo tempo, é claro, o gerente não pode entregar 150 milhões de mesas de dinheiro. Se de repente, em um ano, o controlador astuto apresentar um relatório de que as bilheterias são usadas a 1%, então o infeliz diretor enfrentará um destino invejável. Se um comprador comum espera demais (mais de um minuto), ele sai do hipermercado e escreve um comunicado ao camarada Mao, gritando "a quinhentos e quatro trapaceiros Gatevanau adora Khan a todos".

Depois de observar o oceano como ele funciona, nosso amigo introduziu um sistema avançado de gerenciamento de filas. Agora tudo funciona assim. Depois de levar um pacote de arroz, o comprador vai ao terminal para receber um número na fila. O tempo de espera na fila depende do número de mesas de dinheiro. Experimentalmente, o diretor associado descobriu quantas mesas de caixa deveriam ser para que os compradores, por um lado, não ficassem na fila por muito tempo e, por outro lado, o coeficiente de uso das mesas de caixa não fosse muito baixo.

Fonte

Todo mundo está feliz. O sistema de bilhética é muito simples e sempre rápido. O número de caixas registradoras é selecionado para que:

• a taxa de utilização das caixas registradoras permitiu ao colega diretor viver feliz para sempre;
• a duração da fila era pequena e os chineses passaram pouco tempo nela ( percentil 95 do tempo de espera <um valor razoável, por exemplo, 5 minutos);
• mesmo que, devido às circunstâncias, muitos compradores venham à loja ao mesmo tempo, o tempo de espera será prorrogado, mas eles serão servidos até às 23:00 da noite para que possam voltar para casa e assistir ao boletim de notícias antes de dormir.

Sobre o mesmo deve ser organizado IP em termos de recepção em massa de documentos. Por exemplo, devemos garantir a cada mês o carregamento de um total de pelo menos 150 milhões de documentos de 100 mil fornecedores. Para que a qualidade dos dados baixados seja alta, é necessário verificar todos os dados antes de fazer o download. Dados incorretos são descartados. E os corretos devem ser dispostos de forma estruturada no armazenamento do sistema para que possam ser analisados ​​e usados ​​no futuro.

A necessidade de verificar os dados antes do download leva ao fato de que você precisa executar vários "controles", variando de formatados e terminando com complexos (por exemplo, às vezes é necessário controle de negócios, provando que a organização tem uma base para o download de objetos transferidos).

Normalmente, não podemos sacrificar a qualidade dos cheques. Acreditamos que os desenvolvedores já tenham otimizado todos os algoritmos e que a otimização adicional consome muito tempo ou complica a manutenção e o desenvolvimento do sistema. Em nossos projetos, o tempo de processamento de uma solicitação contendo de quinhentos a quinhentos documentos (pagamento, fatura, contrato, projeto de compras etc.), em média, é de alguns segundos no back-end (veja o exemplo na Figura 1). Esse tempo não é constante, mas varia dentro de certos limites, pois em um sistema complexo sempre existem muitos fatores diferentes que podem afetar o processamento de um pacote.

Figura 1. Uma linha do tempo típica para processar pacotes de documentos. O tempo médio na região de três segundos.

Mesmo que para o seu IS as datas de download sejam regulamentadas por lei, para os fornecedores de documentos, como regra, não há uma programação clara de download. Existem certos modelos para diferentes tipos de documentos, por exemplo, faturas podem ser emitidas no início do mês, picos no carregamento de outros dados podem ser determinados pelos termos dos documentos normativos ou podem estar associados ao final do ano etc.

Portanto, na prática, a qualquer momento, a intensidade do carregamento de documentos pode ser muito diferente - é quase impossível prever com precisão. Pode acontecer que todos os 150 milhões de documentos de bons fornecedores decidam fazer upload no sistema ao mesmo tempo. E isso não é a mesma coisa, como se eles fossem baixados estritamente de acordo com uma programação de 5 milhões por dia.

Figura 2. Um exemplo da distribuição do número de documentos baixados por dia nos últimos seis meses.

A Figura 2 mostra que o número de documentos carregados por dia varia muito. É claro que, em média, cerca de 4-5 milhões de documentos são baixados por dia. Ao mesmo tempo, alguns dias mais de 10 milhões de documentos foram enviados ao sistema. O número máximo de documentos carregados por dia é superior a 17 milhões.

Se observarmos a dinâmica horária do carregamento de documentos, veremos flutuações ainda maiores no tráfego. Em algumas horas, 50 mil documentos são carregados no IS e, em algumas horas, o número de documentos carregados excede 1 milhão.Quanto menor o intervalo que tomamos, maior a dispersão na carga que vemos.

Obviamente, dois, três e dez milhões de documentos podem entrar simultaneamente no sistema. Portanto, ao projetar mecanismos de carregamento em massa, usamos o buffer de consulta usando filas. Qualquer solicitação do usuário é armazenada primeiro na fila. Assim, podemos receber pedidos de recebimento de documentos com intensidade muito alta no sistema, porque a operação de recebimento de um pedido é muito simples. Mas a validação e o carregamento do documento já são feitos por "processadores" especiais, cuja quantidade é ajustada dependendo das capacidades disponíveis. Quanto mais ferro, mais "processadores", mais solicitações o sistema pode processar ao mesmo tempo.

O poder do complexo de hardware e software IP é determinado pela largura de banda e pelos custos de hardware necessários. Precisamos encontrar um equilíbrio para que nós (o cliente) fiquemos satisfeitos com a utilização do ferro durante períodos de baixa carga e, ao mesmo tempo, durante períodos de pico, a fila de dados para carregamento não cresça demais. Considerando que à noite, na maioria das vezes, obtemos uma diminuição natural da carga, podemos usar uma diretriz - todos os dados devem ser baixados no mesmo dia ou durante a noite. Se, cada vez mais, acontece que os dados não têm tempo para carregar durante a noite, esse é um sinal para aumentar a taxa de transferência adicionando ferro.

Figura 3. Um exemplo de um planejamento para alterar o comprimento de uma fila para carregar pacotes de dados.

A Figura 3 mostra estatísticas sobre o comprimento da fila para baixar pacotes de dados. É necessário prestar atenção para que durante o dia tenhamos uma corcunda característica e à noite a fila seja reiniciada.

Como o tempo de carregamento do pacote de dados é a soma do tempo de espera na fila e do tempo de processamento do pacote de dados no back-end, o tempo de carregamento à noite é muito menor do que durante o dia (veja a Figura 4).

Figura 4. Tempo de download para pacotes de dados. A média para o período foi de 11,92 minutos. O tempo de inicialização inclui o tempo da fila e o tempo de processamento de back-end.

Podemos concluir: se o fornecedor enviar um pacote de dados à noite, o tempo de download será mínimo. Por outro lado, se as capacidades dos CIs forem selecionadas de maneira a processar a quantidade esperada de dados no mesmo dia ou no máximo por noite, não faz sentido para o fornecedor continuar carregando os dados - basta enviar toda a quantidade de documentos e eles serão processados ​​o mais rápido possível.

Como alimentar uma vila inteira

Vamos voltar às nossas reivindicações. “Enviamos um documento para download e demorou 10 segundos. Portanto, se nossa organização precisar carregar 100 mil documentos, levará 100.000 * 10/3600 = 277 horas para nós! ”

Cada cliente que chega a um hipermercado em horários diferentes pode ser atendido em horários diferentes. Depende de quantos clientes vieram à loja. À noite, as mesas de dinheiro provavelmente estarão vazias e o comprador será atendido imediatamente. E na hora do rush, você pode ficar na fila por várias horas.

Fonte

O que fazer se você precisar comprar arroz em uma vila de 100 mil habitantes? Não faz sentido enviar cada morador para o hipermercado um após o outro (o próximo sai apenas após o retorno do anterior). Obviamente, neste caso, a compra de arroz para toda a vila se estenderá por muitas horas ou um dia, pois é preciso ficar na fila 100 mil vezes seguidas. Por outro lado, se todos os moradores chegarem ao hipermercado de uma só vez, enfileirarem-se juntos, eles ficarão na fila ao mesmo tempo. De fato, eles ficam na fila apenas uma vez. O tempo de espera na fila também dependerá significativamente do número de mesas de dinheiro.

Em outras palavras, o tempo de carregamento de uma grande quantidade de dados é afetado pela carga atual no sistema (o número de pacotes na fila) e pela taxa de transferência do sistema (a intensidade com que esses pacotes são processados). Um indicador como o tempo de carregamento de uma embalagem individual é insuficiente e leva a conclusões errôneas.

Para carregar uma grande quantidade de dados no IS, você não precisa enviar solicitações sequencialmente, aguardando o processamento da anterior. É necessário enviar todas as solicitações ao IS de uma só vez, elas serão enfileiradas e processadas por "processadores" especiais com uma intensidade dependendo das capacidades e capacidades disponíveis. Obviamente, geralmente a largura de banda do IP excede significativamente as necessidades de cada provedor de dados específico.

Como resultado, métodos síncronos não são adequados para carregamento em massa - este é um antipadrão.

Por que você pode punir um colega diretor?

O que mais preocupa um colega diretor nesta história? Por que eles podem puni-lo?

O serviço pode ser negado ao cliente - isso é sempre desagradável. Mas há muitas razões pelas quais isso pode acontecer e elas têm uma natureza diferente. Vamos listar.

1. Se o sistema de emissão da fila não funcionar, isso é muito ruim. É tão ruim que no dia seguinte essas situações sejam resolvidas no escritório do camarada Mao.

2. Se a fila no hipermercado aumentar e os clientes começarem a ficar lá por um longo tempo, isso é suspeito, mas não necessariamente ruim imediatamente. Isso deve ser monitorado, mas há duas situações:

• a fila está crescendo devido ao fato de muitos chineses terem chegado ao mesmo tempo, por exemplo, devido ao boato sobre aumentos de preços;
• a fila está crescendo devido ao fato de que, por algum motivo, muitas bilheterias quebraram. Essa situação já é ruim, será entendida em uma reunião de planejamento e poderá levar a repreensões.

3. Se um determinado chinês não pode comprar arroz, isso também pode ser por várias razões:

• se os chineses se esqueceram de receber o dinheiro, isso não é culpa do colega diretor;
• se no caixa algo quebrou ou o caixa repreendeu os chineses, isso já é um problema de hipermercado. Se a proporção de tais incidentes aumentar para um determinado nível, isso se tornará um grande problema.

É claro que, para qualquer IP, uma característica importante dos mecanismos de carregamento em massa é a porcentagem de negação de serviço. É necessário distinguir entre negação de serviço por motivos técnicos relacionados à operação do SI (falha do equipamento, erro do sistema etc.) e falhas por motivos relacionados a problemas do lado do fornecedor (formato de pacote de dados incorreto, dados incorretos do ponto de vista comercial) controles etc.).

As situações podem ser diferentes. Porém, se o IP foi desenvolvido levando em consideração os princípios acima e houver um processo de monitoramento e eliminação contínuos de erros técnicos, mais cedo ou mais tarde a situação se estabilizará. Em um sistema que funciona bem, as estatísticas sobre downloads de pacotes são semelhantes à tabela 1.

	Número de solicitações de download, peças	Compartilhar%
Pacotes totalmente carregados com sucesso	125 977 459	79,94%
Pacotes que não foram total ou parcialmente carregados devido a problemas do lado do fornecedor (FLC, controle de negócios)	29 936 543	19%
Pacotes que não foram baixados devido a um problema no lado do IP	38 805	0,02%
Pacotes duplicados	1.638.886	1,04%
Total	156 812 782	100%

Tabela 1. Estatísticas de download de julho de 2018

A tabela mostra que a maioria dos pacotes é carregada com sucesso. Além disso, uma alta proporção de erros do lado do provedor de informações. Isso pode dever-se ao grande número de fornecedores e aos vários graus de prontidão para troca de informações. Os fornecedores podem ter dados de baixa qualidade, podem ter problemas com os sistemas de informação. Alguns dados podem não estar disponíveis em formato estruturado eletrônico e levam tempo para serem recebidos.

Infelizmente, podem ocorrer erros de IP, especialmente se seu rápido desenvolvimento estiver em andamento. É importante que seja iniciado o processo de monitoramento de erros no ambiente industrial e uma análise das causas de sua ocorrência. Utilizamos um sistema de monitoramento desenvolvido para mecanismos de integração em nossos projetos LANIT e, se percebermos que o número de erros começa a aumentar, determinamos sua origem e tentamos executar ações corretivas rapidamente.

Conclusão

Em conclusão, gostaria de repetir os pontos principais novamente.

1. No desenvolvimento e desenvolvimento de IP estatal ou corporativo, surgem tarefas de carregamento de dados em massa. O fluxo de solicitações de download para o IS, como regra, é aleatório. Isso significa que sabemos aproximadamente a distribuição, mas a qualquer momento, poucas e muitas solicitações podem surgir.
2. Os mecanismos para recebimento de dados para carregamento em massa devem ser criados usando filas. O ponto é impossível de outra maneira. Caso contrário, devemos permitir a perda de dados se uma grande quantidade de dados for baixada, ou precisarmos usar muito, muito ferro, que permaneceria inativo 99% do tempo.
3. O tempo de carregamento de dados consiste no tempo de espera na fila e no tempo de processamento de dados. O tempo de processamento de pacotes de dados no back-end com processos adequados de design e desenvolvimento é de segundos ou milissegundos. O tempo limite da fila (minutos) depende do número de manipuladores usados ​​pelo sistema. O número de processadores é determinado pelo poder do complexo de hardware e software. Mais ferro - mais manipuladores, mais rápida a fila. E vice-versa.
4. Os serviços síncronos não são aplicáveis ​​a downloads em massa, portanto, não são recomendados.
5. Se você é um fornecedor e precisa enviar muitos dados, envie todos eles para o IP imediatamente. Em nenhum caso você deve enviar dados sequencialmente um após o outro (o próximo pacote não é enviado até que o anterior seja baixado).