Qu'est-ce qu'un système d'information très chargé comme un immense hypermarché? Et si 150 millions de personnes venaient à l'hypermarché en même temps pour faire du shopping? Pour quoi punir la tête d'un hypermarché, et pourquoi pas? Pourquoi le temps de chargement des documents la nuit est-il beaucoup moins long que le jour? Pourquoi le temps de chargement d'un seul document ne signifie-t-il vraiment rien?

Les systèmes d'information très chargés ont leurs propres caractéristiques, qui ne sont pas évidentes pour de nombreuses organisations de fournisseurs. Nous vous expliquerons comment le chargement en masse des documents (et autres données) est organisé et examinerons en détail cette question incompréhensible pour beaucoup.

Source

Lors du développement de systèmes d'information (SI) volumineux et très chargés, des tâches de chargement de masse des données surviennent. Le type de données n'a pas d'importance et dépend de votre domaine. Cela peut être des paiements, des factures, des relevés de capteurs, des projets d'approvisionnement, etc. La création et le développement de SIG (systèmes d'information de l'État) sont réglementés par la loi et il peut facilement arriver que la loi oblige les organisations à télécharger des millions de documents dans le système une seule fois ou, plus intéressant encore, à télécharger des millions de documents sur une base périodique, par exemple mensuelle.

Dans nos projets (un peu sur le travail de LANIT peut être lu ici et ici ), nous rencontrons périodiquement de telles tâches et avons développé toutes les solutions nécessaires. Cependant, les spécificités des solutions présentent certaines caractéristiques qui, comme il s'est avéré, ne sont pas évidentes pour de nombreuses organisations de fournisseurs. À notre grande surprise, nous avons reçu de telles demandes et même des plaintes:

• «Nous avons envoyé un document à télécharger, et cela a pris jusqu'à 10 secondes. Par conséquent, si notre organisation doit télécharger 100 000 documents, cela nous prendra 100 000 * 10/3600 = 277 heures! »
• "Nous chargeons, chargeons des documents, mais rien n'est chargé dans le système."

Le fait que le chargement d'un document dans un système d'information puisse prendre 10 secondes ne dit rien sur le système en lui-même. Cet indicateur n'a pas beaucoup de sens si nous parlons de systèmes de mise en file d'attente. Ensuite, nous vous expliquerons comment le chargement en masse des documents (et d'autres données) est organisé et examinerons en détail cette question qui n'est pas claire pour beaucoup.

Quant aux erreurs de chargement, tout n'est pas évident non plus: il y a de nombreuses raisons pour lesquelles les données ne sont pas chargées dans le système. Les problèmes peuvent être du côté des fournisseurs d'informations et du côté de l'IP. Ci-dessous, nous analyserons différentes situations et verrons des statistiques.

Hypermarché chinois

Par exemple, dans une province chinoise éloignée, où vivent environ 150 millions de personnes, il n'y a qu'un seul grand hypermarché ouvert 24h / 24 où la population va acheter du riz une fois par mois. Les résidents peuvent venir chercher du riz n'importe quel jour du mois. Il y a beaucoup de riz, il y a beaucoup de place dans la salle des marchés. Le principal goulot d'étranglement est le paiement des achats à la caisse, car cette opération est obligatoire (vous ne pouvez pas ignorer les acheteurs sans paiement), cela prend du temps et l'utilisation d'un équipement spécial - des caisses. Il serait préférable pour l'hypermarché que les gens se mettent d'accord entre eux et viennent faire leurs courses de manière égale (nuit et jour), auquel cas l'utilisation des caisses serait aussi efficace que possible.

Cependant, comme par hasard, les acheteurs ne se dirigent pas vers l'hypermarché. Premièrement, ils ne veulent pas vraiment faire du shopping la nuit. Deuxièmement, elles sont parfois illimitées: soit il n'y a personne, alors plusieurs millions de personnes viennent en même temps.

Source Le plus grand centre commercial du monde, le New Century Global Center à Chengdu en Chine. Il a 18 étages et une superficie de 1 700 000 m².

Que faire dans un supermarché? Le Parti communiste chinois s'est donné pour mission de servir tous les Chinois, et c'est tout. Chaque chinois non servi est un inconvénient pour le karma du directeur de supermarché. S'il y a trop de Chinois mécontents, ne lui démolissez pas la tête! Dans le même temps, bien sûr, le gestionnaire ne peut pas livrer 150 millions de caisses. Si soudainement, dans un an, le contrôleur rusé apportera un rapport selon lequel le box-office est utilisé à 1%, le malheureux réalisateur sera confronté à un sort peu enviable. Si un acheteur ordinaire attend trop longtemps (plus d'une minute), alors il sortira de l'hypermarché et écrira une déclaration au camarade Mao lui-même avec les cris de "cinq cent quatre tricheur Gatevanau tameaut Khan à vous tous".

Après avoir surveillé l'océan comment cela fonctionne, notre ami a présenté un système avancé de gestion des files d'attente. Maintenant, tout fonctionne comme ça. Ayant pris un paquet de riz, l'acheteur se rend au terminal pour recevoir un numéro dans la file d'attente. Le temps d'attente en ligne dépend du nombre de caisses. Expérimentalement, le directeur compagnon a découvert combien de caisses devraient être pour que les acheteurs, d'une part, ne restent pas en ligne trop longtemps, et d'autre part, le coefficient d'utilisation des caisses n'est pas trop bas.

Source

Tout le monde est content. Le système de billetterie est très simple et toujours rapide. Le nombre de caisses enregistreuses est choisi de telle sorte que:

• le taux d'utilisation des caisses enregistreuses a permis au confrère directeur de vivre heureux pour toujours;
• la longueur de la file d'attente était petite et les Chinois y passaient peu de temps (95 centile du temps d'attente <une valeur raisonnable, par exemple, 5 minutes);
• même si, en raison des circonstances, de nombreux acheteurs venaient au magasin en même temps, le temps d'attente sera prolongé, mais ils seront servis jusqu'à 23h00 le soir afin qu'ils puissent rentrer chez eux et regarder le communiqué avant le coucher.

À peu près le même devrait être organisé IP en termes de réception de masse des documents. Par exemple, nous devons assurer chaque mois le chargement d'un total d'au moins 150 millions de documents de 100 000 fournisseurs. Pour que la qualité des données téléchargées soit élevée, il est nécessaire de vérifier toutes les données avant le téléchargement. Des données incorrectes sont supprimées. Et les bons devraient être présentés sous une forme structurée dans le stockage du système afin qu'ils puissent être analysés et utilisés à l'avenir.

La nécessité de vérifier les données avant le téléchargement conduit au fait que vous devez effectuer un certain nombre de «contrôles», allant du formatage à la fin par des contrôles complexes (par exemple, un contrôle commercial est parfois nécessaire, prouvant que l'organisation a une base pour télécharger les objets transférés).

Nous ne pouvons généralement pas sacrifier la qualité des contrôles. Nous pensons que les développeurs ont déjà optimisé tous les algorithmes et qu'une optimisation supplémentaire prend trop de temps ou complique la maintenance et le développement du système. Sur nos projets, le temps de traitement d'une demande contenant de un à cinq cents documents (paiement, facture, contrat, projet d'approvisionnement, etc.) est en moyenne de quelques secondes sur le backend (voir l'exemple de la figure 1). Ce temps n'est pas constant, mais varie dans certaines limites, car dans un système complexe, il y a toujours beaucoup de facteurs différents qui peuvent affecter le traitement d'un colis.

Figure 1. Chronologie type du traitement des packages de documents. Le temps moyen dans la région de trois secondes.

Même si pour votre SI les dates de téléchargement sont réglementées par la loi, alors pour les fournisseurs de documents, en règle générale, il n'y a pas de calendrier de téléchargement clair. Il existe certains modèles pour différents types de documents, par exemple, les factures peuvent être émises au début du mois, les pics de chargement d'autres données peuvent être déterminés par les termes des documents normatifs ou peuvent être associés à la fin de l'année, etc.

Par conséquent, dans la pratique, à un moment donné, l'intensité du chargement des documents peut être très différente - il est presque impossible de le prévoir avec précision. Il peut arriver que les 150 millions de documents de bons fournisseurs décident de les télécharger simultanément dans le système. Et ce n'est pas du tout la même chose, comme s'ils les téléchargeaient strictement selon un calendrier de 5 millions par jour.

Figure 2. Exemple de répartition du nombre de documents téléchargés par jour au cours des six derniers mois.

La figure 2 montre que le nombre de documents chargés par jour varie considérablement. Il est clair qu'en moyenne, 4 à 5 millions de documents sont téléchargés par jour. Dans le même temps, certains jours, plus de 10 millions de documents ont été envoyés au système. Le nombre maximal de documents téléchargés par jour est supérieur à 17 millions.

Si nous regardons la dynamique horaire du chargement des documents, nous verrons des fluctuations encore plus importantes du trafic. À certaines heures, 50 000 documents sont chargés dans le SI et à certaines heures, le nombre de documents chargés dépasse 1 million. Plus l'intervalle est court, plus la répartition de la charge est importante.

De toute évidence, deux, trois et dix millions de documents peuvent entrer simultanément dans le système. Par conséquent, lors de la conception de mécanismes de chargement en masse, nous utilisons la mise en mémoire tampon des requêtes à l'aide de files d'attente. Toute demande de l'utilisateur est d'abord stockée dans la file d'attente. Ainsi, nous pouvons recevoir des demandes de réception de documents à très haute intensité dans le système, car l'opération de réception d'une demande est très simple. Mais la validation et le chargement du document sont déjà effectués par des "processeurs" spéciaux, dont le montant est ajusté en fonction des capacités disponibles. Plus il y a de fer, plus il y a de "processeurs", plus le système peut traiter de requêtes en même temps.

La puissance du complexe matériel-logiciel IP est déterminée par la bande passante requise et les coûts matériels. Nous devons trouver un équilibre afin que nous (le client) soyons satisfaits de l'utilisation du fer pendant les périodes de faible charge, et en même temps, pendant les périodes de pointe, la file d'attente de données pour le chargement n'augmente pas trop. Étant donné que la nuit, nous obtenons le plus souvent une diminution naturelle de la charge, nous pouvons utiliser une directive - toutes les données doivent être téléchargées le même jour ou la nuit. S'il arrive de plus en plus souvent que les données n'aient pas le temps de se charger pendant la nuit, alors c'est un signal pour augmenter le débit en ajoutant du fer.

Figure 3. Exemple de planification pour modifier la longueur d'une file d'attente pour le chargement de paquets de données.

La figure 3 présente des statistiques sur la longueur de la file d'attente pour le téléchargement des paquets de données. Il faut faire attention que dans la journée nous avons une bosse caractéristique, et la nuit la file d'attente est réinitialisée.

Étant donné que le temps de chargement du paquet de données est la somme du temps d'attente dans la file d'attente et du temps de traitement du paquet de données sur le backend, le temps de chargement la nuit est bien inférieur à celui de la journée (voir figure 4).

Figure 4. Temps de téléchargement des paquets de données. La moyenne pour la période était de 11,92 minutes. Le temps de démarrage comprend le temps de file d'attente et le temps de traitement du backend.

Nous pouvons conclure: si le fournisseur envoie un paquet de données la nuit, le temps de téléchargement sera minimal. D'un autre côté, si les capacités des CI sont sélectionnées de manière à traiter la quantité attendue de données le même jour ou au maximum par nuit, il n'est pas logique que le fournisseur continue de charger les données - il vous suffit d'envoyer la totalité du volume de documents et il sera traité le plus rapidement possible.

Comment nourrir un village entier

Revenons à nos revendications. «Nous avons envoyé un document à télécharger, et cela a pris jusqu'à 10 secondes. Par conséquent, si notre organisation a besoin de télécharger 100 000 documents, cela nous prendra 100 000 * 10/3600 = 277 heures! »

Chaque client arrivant dans un hypermarché à des heures différentes peut être servi à des heures différentes. Cela dépendra du nombre de clients qui sont venus au magasin. La nuit, les caisses sont susceptibles d'être vides et l'acheteur sera servi immédiatement. Et aux heures de pointe, vous pouvez faire la queue pendant plusieurs heures.

Source

Que faire si vous avez besoin d'acheter du riz dans un village de 100 000 habitants? Cela n'a aucun sens d'envoyer chaque villageois à l'hypermarché l'un après l'autre (le suivant ne sort qu'après le retour du précédent). De toute évidence, dans ce cas, l'achat de riz pour l'ensemble du village s'étalera sur plusieurs heures ou une journée, car vous devez faire la queue 100 000 fois de suite. D'un autre côté, si tous les villageois viennent à l'hypermarché en même temps, font la queue tous ensemble, alors ils feront la queue en même temps. En fait, ils ne font la queue qu'une seule fois. Leur temps d'attente en ligne dépendra également de manière significative du nombre de caisses.

En d'autres termes, le temps de chargement d'une grande quantité de données est affecté par la charge actuelle sur le système (le nombre de paquets dans la file d'attente) et le débit du système (l'intensité avec laquelle ces paquets sont traités). Un indicateur tel que le temps de chargement d'un colis individuel est en soi insuffisant et conduit à des conclusions erronées.

Pour charger une grande quantité de données dans le SI, vous n'avez pas besoin d'envoyer les demandes séquentiellement, en attendant que la précédente soit traitée. Il est nécessaire d'envoyer toutes les demandes au SI à la fois, elles seront mises en file d'attente et traitées par des «processeurs» spéciaux avec une intensité en fonction des capacités et capacités disponibles. De toute évidence, généralement la bande passante de l'IP dépasse considérablement les besoins de chaque fournisseur de données particulier.

Par conséquent, les méthodes synchrones ne conviennent pas au chargement en masse - il s'agit d'un contre-modèle.

Pourquoi pouvez-vous punir un collègue réalisateur

Qu'est-ce qui inquiète le plus un collègue réalisateur dans cette histoire? Pour quoi peuvent-ils le punir?

Le client peut se voir refuser le service - c'est toujours désagréable. Mais il existe de nombreuses raisons pour lesquelles cela peut se produire, et elles ont une nature différente. Faisons la liste.

1. Si le système d'émission de file d'attente ne fonctionne pas, c'est très mauvais. C'est tellement mauvais que le lendemain, de telles situations sont réglées dans le bureau du camarade Mao.

2. Si la ligne dans l'hypermarché augmente et que les clients commencent à s'y accrocher pendant longtemps, cela est suspect, mais pas nécessairement mauvais tout de suite. Cela doit être surveillé, mais il y a deux situations:

• la file d'attente s'allonge du fait que trop de Chinois sont venus en même temps, par exemple à cause de la rumeur sur les augmentations de prix;
• la file d'attente augmente en raison du fait que, pour une raison quelconque, de nombreux guichets ont éclaté. Cette situation est déjà mauvaise, elle sera comprise lors d'une réunion de planification et pourra conduire à des réprimandes.

3. Si un Chinois en particulier ne peut pas acheter de riz, cela peut également être dû à diverses raisons:

• si les Chinois ont oublié de prendre l'argent, ce n'est pas la faute du collègue réalisateur;
• si à la caisse quelque chose s'est cassé ou que le caissier a grondé les chinois, alors c'est déjà un problème d'hypermarché. Si la proportion de ces incidents augmente à un certain niveau, cela deviendra un gros problème.

Il est clair que pour tout IP, une caractéristique importante des mécanismes de chargement en masse est le pourcentage de déni de service. Il est nécessaire de distinguer entre déni de service pour des raisons techniques liées au fonctionnement du SI (panne d'équipement, erreur système, etc.) et pannes pour des raisons liées à des problèmes du côté du fournisseur (format de paquet de données incorrect, données incorrectes du point de vue de l'entreprise) commandes, etc.).

Les situations peuvent être différentes. Mais si la propriété intellectuelle a été développée en tenant compte des principes ci-dessus et qu'il existe un processus de surveillance continue et d'élimination des erreurs techniques, la situation se stabilisera tôt ou tard. Sur un système qui fonctionne bien, les statistiques sur les téléchargements de packages ressemblent au tableau 1.

	Nombre de demandes de téléchargement, pcs	Part%
Packages téléchargés avec succès	125 977 459	79,94%
Colis qui n'ont pas été entièrement ou partiellement chargés en raison de problèmes du côté du fournisseur (FLC, contrôle de gestion)	29 936 543	19%
Packages qui n'ont pas été téléchargés en raison d'un problème côté IP	38 805	0,02%
Packages en double	1,638,886	1,04%
Total	156 812 782	100%

Tableau 1. Statistiques de téléchargement pour juillet 2018

Le tableau montre que la plupart des packages se chargent correctement. De plus, une forte proportion d'erreurs du côté du fournisseur d'informations. Cela peut être dû au grand nombre de fournisseurs et à leur degré variable de préparation à l'échange d'informations. Les fournisseurs peuvent avoir des données de mauvaise qualité, ils peuvent avoir des problèmes avec les systèmes d'information. Certaines données peuvent ne pas être disponibles sous forme structurée électronique et leur réception prend du temps.

Malheureusement, des erreurs IP peuvent survenir, surtout si son développement rapide est en cours. Il est important de lancer le processus de surveillance des erreurs en milieu industriel et une analyse des causes de leur occurrence. Nous utilisons un système de surveillance développé pour les mécanismes d'intégration dans nos projets LANIT, et si nous constatons que le nombre d'erreurs commence à augmenter, nous déterminons leur source et essayons de prendre des mesures correctives rapidement.

Conclusion

Pour conclure, je voudrais répéter à nouveau les principaux points.

1. Dans le développement et le développement de la propriété intellectuelle d'État ou d'entreprise, des tâches de chargement de masse des données se posent. En règle générale, le flux des demandes de téléchargement vers le SI est aléatoire. Cela signifie que nous connaissons approximativement la distribution, mais à tout moment, très peu et beaucoup de demandes peuvent arriver.
2. Les mécanismes de réception des données pour le chargement en masse doivent être créés à l'aide de files d'attente. Le point est impossible d'une autre manière. Sinon, nous devons permettre la perte de données si une énorme quantité de données vient à être téléchargée, ou si nous devons utiliser très, beaucoup de fer, qui resterait inactif 99% du temps.
3. Le temps de chargement des données se compose du temps d'attente dans la file d'attente et du temps de traitement des données. Le temps de traitement des paquets de données sur le backend avec des processus de conception et de développement adéquats est de quelques secondes ou millisecondes. Le délai d'attente de la file d'attente (minutes) dépend du nombre de gestionnaires utilisés par le système. Le nombre de processeurs est déterminé par la puissance du complexe matériel-logiciel. Plus de fer - plus de gestionnaires, plus vite la file d'attente. Et vice versa.
4. Les services synchrones ne sont pas applicables aux téléchargements en masse, ils ne sont donc pas recommandés.
5. Si vous êtes un fournisseur et que vous devez télécharger un grand nombre de données, envoyez-les toutes immédiatement à l'adresse IP. En aucun cas, vous ne devez envoyer les données séquentiellement les unes après les autres (le paquet suivant n'est pas envoyé tant que le précédent n'est pas téléchargé).