Récemment, VTB a modifié certains composants matériels et logiciels du système de workflow. Les changements étaient trop importants pour continuer à fonctionner sans test de charge à grande échelle: tout problème avec le système de support de documents (LMS) est lourd de pertes.
Les spécialistes d'Intertrust ont testé VTB SDO sur les équipements Huawei - un complexe de batterie de serveurs, de réseau de données et de stockage basé sur des disques SSD. Pour les tests, nous avons créé un environnement qui reproduit des scénarios réels avec la charge maximale possible. Résultats et conclusions - sous la coupe.
Pourquoi avons-nous besoin d'un système de workflow dans une banque et pourquoi le tester
LMS dans VTB est un progiciel complexe sur lequel tous les processus de gestion clés sont liés. Le système fournit des services de documentation générale, d'interaction électronique et d'analyse. Une circulation bien organisée des documents accélère les décisions de gestion, rend la procédure d'adoption transparente et contrôlée, améliore la qualité de la gestion et renforce la compétitivité de la banque.
Le LMS devrait assurer une mise en œuvre claire des décisions conformément aux réglementations établies. Cela nécessite des performances élevées, une tolérance aux pannes, une mise à l'échelle flexible. Le système a des exigences élevées en matière de contrôle d'accès, de volume de documents traités simultanément et de nombre d'utilisateurs. Maintenant, il y en a 65 000 dans VTB SDO, et ce nombre continue de croître.
Le système évolue constamment: l'architecture change, les technologies obsolètes sont remplacées par des technologies modernes. Et récemment, certains composants du système ont été remplacés par des composants indépendants de l'importation, sans logiciel propriétaire. La nouvelle architecture SDO basée sur le logiciel CompanyMedia et le complexe matériel Huawei supportera-t-elle l'augmentation de la charge? Répondre sans ambiguïté à cette question, sans attendre une situation similaire dans la réalité, cela n'a été possible qu'avec l'aide de tests de résistance.
En plus de tester le nouveau produit logiciel pour la résistance au stress, nous avons eu les tâches suivantes:
- déterminer les paramètres exacts de dimensionnement horizontal et vertical des serveurs pour le profil de charge de la banque;
- vérifier la tolérance de panne des composants dans des conditions de charge élevée;
- pour identifier le coefficient d'entropie de l'interaction intercluster avec mise à l'échelle horizontale;
- essayez de mettre à l'échelle les demandes de lecture lorsque vous utilisez l'équilibreur de plateforme;
- déterminer le coefficient de mise à l'échelle horizontale de tous les nœuds et composants du système;
- déterminer les paramètres matériels maximaux possibles des serveurs à diverses fins fonctionnelles (mise à l'échelle verticale);
- d'étudier le profil de charge de l'application sur l'infrastructure technique, d'approximer les résultats pour planifier le développement du système d'information;
- Étudiez l'impact de la consolidation des données d'application sur un seul système de stockage de données sur l'optimisation des ressources, l'amélioration de la fiabilité et des performances.
Méthodologie et équipement
Les tests de charge des systèmes de gestion électronique de documents sont souvent effectués selon des scénarios simplifiés. Ils simulent la recherche et l'ouverture rapides de fiches de documents qui ne sont pas associées à d'autres fichiers et n'ont pas d'historique de cycle de vie. Dans ce cas, en règle générale, personne ne prend en compte les droits d'accès et les autres facteurs consommateurs de ressources caractéristiques des conditions réelles.
Souvent, ces tests divorcés sont effectués par des fournisseurs de solutions. C'est compréhensible: il est important pour un fournisseur de démontrer à un client potentiel les hautes performances et la vitesse du système. Il n'est pas surprenant que les modèles de test simplifiés affichent des temps de réponse record du système, même si le nombre d'utilisateurs et de documents augmente considérablement.
Nous devions reproduire les conditions réelles de fonctionnement. Par conséquent, au début, nous avons collecté des statistiques pendant un mois: nous avons enregistré l'activité des utilisateurs, regardé le travail de fond de tous les services. Les systèmes de surveillance intégrés dans le LMS sont devenus d'une grande aide à cet égard. Les employés de la banque ont aidé à corriger les données résultantes sur les flux de documents, tandis que nous avons ajusté la croissance projetée des flux.
Le résultat a été une méthodologie de test, à l'aide de laquelle il a été possible de simuler les processus se produisant dans le système, en tenant compte de toutes les charges réelles. Au banc d'essai, nous avons reproduit - individuellement et dans diverses combinaisons - les opérations commerciales les plus courantes, ainsi que les demandes les plus longues. Lors des tests de performance, tous les composants ont été soumis à des contraintes. Des opérations ont été effectuées pour calculer les droits d'accès des utilisateurs aux objets système, ouvrir des documents avec une hiérarchie ramifiée complexe et un grand nombre de liens, rechercher le système, etc.
Profil de test de charge:
- utilisateurs enregistrés: 65 000 avec une augmentation jusqu'à 150 000;
- fréquence des connexions des utilisateurs (authentifications): 50 000 par heure;
- utilisateurs travaillant simultanément dans le système: 10 000;
- documents enregistrés: 10 millions par an;
- volume de pièces jointes: 1 To par an;
- processus d'approbation des documents: 1,5 million par an;
- visas des parties à l'accord: 7,5 millions par an;
- résolutions et instructions: 15 millions par an;
- rapports sur les résolutions et instructions: 15 millions par an;
- tâches utilisateur: 18 millions par an.
Ces applications ont été consolidées sur un seul système de stockage Huawei OceanStor Dorado 6000 V3 avec 117 disques SSD de 3,6 To chacun, le volume total utilisable est supérieur à 300 To. La puissance de calcul a été placée sur le système de serveur modulaire de Huawei E9000, et les données ont été transmises sur le réseau en fonction des commutateurs du niveau du centre de données de la série Huawei CE. Pendant le test, nous avons observé 24 heures sur 24 tous les indicateurs du système. Tous les résultats, y compris les données historiques, ont été enregistrés sous forme de graphiques et de tableaux pour une analyse ultérieure.
Serveurs d'infrastructure matérielle de test de charge
En raison des performances élevées du système de stockage Huawei OceanStor Dorado 6000 V3, les retards lors de l'exécution des demandes des utilisateurs dépassent rarement 1 ms. Cette vitesse du sous-système de disque de l’application nous a incités à poursuivre nos recherches. Nous avons décidé, en analysant les données historiques, de déterminer l'effet de différents types de charges de travail sur l'infrastructure technique. Les résultats obtenus nous permettent de planifier de manière flexible et précise le développement du système conformément aux exigences de la plate-forme matérielle.
En termes de mise à l'échelle, nous avons vérifié:
- limite de mise à l'échelle verticale du serveur d'applications (CMJ) , ressources de criticité: nombre de cœurs et fréquence, quantité de RAM;
- prise en charge de la mise à l'échelle horizontale du serveur d'applications (CMJ) en dupliquant des services fonctionnellement identiques et en les équilibrant entre eux;
- limites de la mise à l'échelle verticale et horizontale du serveur client (Web-GUI) ;
- limites de la mise à l'échelle verticale du stockage de fichiers (FS) , ressources de criticité: bande passante réseau, vitesse du disque;
- prise en charge de la mise à l'échelle horizontale du stockage de fichiers (FS) en raison du système de fichiers distribué - CEPH, GLUSTERFS;
- limites de la mise à l'échelle verticale de la base de données (PostgreSQL) , ressources selon le degré de criticité: capacité RAM, vitesse du disque, nombre de cœurs et fréquence;
- prise en charge de la mise à l'échelle horizontale de la base de données (PostgreSQL) : mise à l'échelle de la charge de lecture sur les serveurs esclaves, mise à l'échelle de la charge d'écriture sur le principe de la division en modules fonctionnels;
- limites de la mise à l'échelle verticale et horizontale du courtier de messages (Apache Artemis) ;
- limites de la mise à l'échelle verticale et horizontale du serveur de recherche (Apache Solr) .
Problèmes et solutions
L'une des principales tâches consistait à identifier d'éventuels problèmes de performances du LMS. Au cours des travaux, les goulots d'étranglement suivants ont été identifiés et des moyens de les résoudre ont été trouvés.
Verrouille la journalisation synchrone. Les opérations de journalisation dans la configuration WildFly standard sont effectuées de manière synchrone et affectent considérablement les performances. Il a été décidé de passer à un enregistreur asynchrone et d'écrire en même temps non pas sur un disque, mais sur le système d'agrégation de journaux ELK.
Initialisation de sessions inutiles lors de l'utilisation d'un entrepôt de données. Chaque thread qui a reçu des données du référentiel a initialisé deux fois une session pour l'authentification en mode SSO. Cette opération est gourmande en ressources et augmente considérablement le temps d'exécution de la demande de l'utilisateur, et réduit également le débit global du serveur.
Se verrouille lorsque vous travaillez avec des objets de cache d'application. L'application a utilisé des verrous reentrantLock assez lourds (Java 7), ce qui a nui à la vitesse d'exécution des requêtes. Le type de verrou a été remplacé par stampedLock, ce qui a considérablement réduit le temps passé à travailler avec les objets de cache.
Après cela, nous avons de nouveau lancé des tests de charge pour déterminer la durée moyenne des opérations typiques dans le système LMS avec stockage relationnel sur le profil de la banque. Nous avons obtenu les résultats suivants:
- autorisation de l'utilisateur dans le système - 400 ms;
- visualiser la progression en moyenne - 2,5 s;
- création d'une carte d'enregistrement et de contrôle - 1,4 s;
- enregistrement et enregistrement de la carte de contrôle - 600 ms;
- création d'une résolution - 1 p.
Conclusions
En plus d'identifier les problèmes, les tests de résistance ont confirmé certaines de nos hypothèses.
- Le système fonctionne beaucoup mieux sur la famille Linux d'OS.
- Les principes déclarés d'assurer la tolérance aux pannes fonctionnent au niveau de chaque composant en mode «chaud».
- Un composant clé - le service de logique métier (acceptation des demandes des utilisateurs) - a une mise à l'échelle horizontale «miroir» et une mise à l'échelle presque linéaire du débit avec une augmentation du nombre d'instances.
- Dimensionnement optimal du service de logique métier pour 1 200 utilisateurs simultanés - 8 vCPU pour le service et 1,5 vCPU pour le SGBD.
- La consolidation des données d'application sur un seul système de stockage augmente considérablement la productivité et la fiabilité, augmente l'évolutivité.
Nous serons heureux de répondre à vos questions dans les commentaires - peut-être souhaitez-vous en savoir plus sur certains aspects des tests.