Note de l'éditeur：Cet article détaille Milvus 2.0 Flux de travail du système d'assurance de la qualité、Détails de la mise en œuvre,Et des solutions d'optimisation pour améliorer l'efficacité.

• Introduction générale à l'assurance de la qualité

  • Préoccupations concernant le contenu des tests

  • Comment l'équipe de développement et l'équipe d'assurance de la qualité travaillent ensemble

  • Issue Processus de gestion pour

  • Normes de publication

• Introduction au module d'essai

  • Présentation générale

  • Tests unitaires

  • Essais fonctionnels

  • Tests de déploiement

  • Test de fiabilité

  • Essais de stabilité et de performance

• Méthodes et outils d'amélioration de l'efficacité

  • Github Action

  • Essais de performance

Introduction générale à l'assurance de la qualité

Les dessins architecturaux sont tout aussi importants pour l'assurance de la qualité,Seule une connaissance suffisante de l'objet testé,Pour élaborer un protocole d'essai plus rationnel et plus efficace.Milvus 2.0 C'est un nuage indigène、Architecture distribuée,L'entrée principale passe par SDK Entrée,Il y a beaucoup de logique hiérarchique à l'intérieur.Donc pour l'utilisateur,SDK Cette extrémité est très préoccupante,C'est exact. Milvus Au moment du test,D'abord, ça va être SDK Test de fonctionnement à cette extrémité,Et à travers SDK Pour découvrir Milvus Problèmes internes possibles.En même temps Milvus C'est aussi une base de données.,Par conséquent, les différents tests du système sur la base de données impliquent également.

Cloud Native、Architecture distribuée,Les avantages des tests,Il y a aussi des défis à relever.L'avantage, c'est que, Contrairement aux opérations traditionnelles de déploiement local ,In k8s Le déploiement et l'exploitation au sein d'un Cluster garantissent, dans la mesure du possible, un environnement cohérent pour le développement et les essais du logiciel. . Le défi est que les systèmes distribués deviennent complexes , Plus d'incertitude a été introduite , Augmentation de la charge de travail et de la difficulté des tests . Par exemple, l'augmentation du nombre de services après la microservice 、 La machine aura plus de noeuds , Plus d'étapes intermédiaires , Plus la probabilité d'erreur est élevée , Chaque situation doit être prise en considération lors des essais .

Préoccupations concernant le contenu des tests

Selon la nature du produit 、Besoins des utilisateurs,Milvus Le contenu et la priorité des tests sont présentés dans la figure ci - dessous .

D'abord dans la fonction （Function）Allez., Se demander si l'interface répond aux attentes de la conception .

Deuxièmement, le déploiement （Deployment）Allez.,Attention standalone Ou cluster Si le redémarrage et la mise à jour peuvent réussir en mode .

Troisièmement, la performance （Performance）Allez., Parce qu'il s'agit d'une base de données d'analyse en temps réel qui intègre des lots de flux , Donc plus de vitesse , Se concentre davantage sur l'insertion 、Créer un index、Performance de la requête.

Quatrièmement, la stabilité （Stability）Allez.,Attention Milvus Temps de fonctionnement normal sous charge normale , L'objectif visé est 5 - 10Oh, mon Dieu..

Cinquièmement, la fiabilité （Reliability）Allez., Attention quand une erreur se produit Milvus Performance, Et si l'élimination des erreurs fonctionne .

Sixièmement, le problème de configuration （Configuration）, Vous devez vérifier que chaque élément de configuration ouvert fonctionne correctement , Les modifications entrent - elles en vigueur? .

Enfin, la compatibilité （Compatibility）, Principalement dans la configuration matérielle et logicielle .

Comme le montre la figure, La fonctionnalité et le déploiement sont au plus haut niveau ,Performance、Stabilité、 Fiabilité au deuxième niveau , Enfin, placez la configuration et la compatibilité en troisième position .Mais, L'importance de cette hiérarchie est également relative .

Comment l'équipe de développement et l'équipe d'assurance de la qualité travaillent ensemble

L'utilisateur moyen considère que les tâches d'assurance de la qualité ne sont assignées qu'à l'équipe d'assurance de la qualité. , Mais pendant le développement du logiciel , La qualité exige un travail d'équipe multipartite pour être garantie .

Les premières étapes sont le développement de la documentation de conception , L'équipe d'assurance de la qualité rédige un plan d'essai basé sur la documentation de conception . Les deux documents doivent être mis à l'essai et développés conjointement pour réduire les erreurs de compréhension. . Les objectifs de cette version seront établis avant la publication ,Y compris les performances、Stabilité、bug .Dans quelle mesure les nombres doivent converger, etc .Pendant le développement, Développement axé sur la mise en oeuvre des fonctions de codage , Une fois la fonction terminée, l'équipe d'assurance de la qualité effectuera des essais et des vérifications. . Ces deux étapes tournent beaucoup de fois , L'équipe d'assurance de la qualité et l'équipe de développement doivent maintenir la synchronisation quotidienne de l'information .En outre, En plus de la vérification du développement de ses propres fonctions , Les produits open source reçoivent également beaucoup de questions de la communauté , Il sera également résolu en fonction des priorités .

Dans la phase finale, Si le produit satisfait aux critères de libération , L'équipe sélectionne un noeud temporel , Publier un nouveau miroir . Vous devez préparer un release tag Et release note, Suivez les fonctionnalités de cette version , Ce qui a été réparé issue, L'équipe d'assurance de la qualité publiera également un rapport d'essai pour cette version. .

Issue Processus de gestion pour

L'équipe d'assurance de la qualité se concentre davantage sur le développement de produits issue.Issue En plus des membres de l'équipe d'assurance de la qualité , Et un grand nombre d'utilisateurs externes , Il est donc nécessaire de normaliser chaque issue Informations à remplir pour .Chaque issue Il y a un modèle , Demande d'information à l'auteur , Par exemple, la version actuellement utilisée , Informations sur la configuration de la machine , Et quelles sont vos attentes? ？ Quel est le résultat réel du retour ？ Comment reproduire ça? issue, Ensuite, l'équipe qualité et l'équipe de développement continueront à suivre .

Créer ceci issue Après,D'abord. assign Au Chef de l'équipe d'assurance de la qualité , Et ensuite le responsable va faire quelque chose issue Effectuer un certain flux d'état .Si issue Bien établi et avec suffisamment d'informations , Il y a plusieurs états à suivre ,Par exemple:： Est - ce résolu ; Si elle peut être reproduite ; Dupliquer avec ; Taille de la probabilité d'occurrence ; Taille de la priorité . Si un défaut est identifié , L'équipe de développement soumettra PR, C'est lié à ça issue,Modifier. Après validation ,C'est issue Sera fermé, Si le problème persiste plus tard ,C'est bon. reopen.En outre,Pour améliorer issue Efficacité de la gestion, Des étiquettes et des robots seront également introduits ,Pour issue Flux de classification et d'état .

Normes de publication

La question de savoir si la version actuelle peut être publiée se rapporte principalement à la question de savoir si la version actuelle peut répondre aux exigences prévues. . Par exemple, l'image ci - dessus est une situation générale ,RC6 À RC7,RC8 Et GA La norme. Au fur et à mesure que la version avance ,C'est exact. Milvus La qualité de ：

• De l'original 50M L'ordre de grandeur de, évoluer progressivement vers 1B L'ordre de grandeur de
• Dans l'exécution stable des tâches , Passer d'une tâche unique à une tâche mixte , La durée passe progressivement de l'heure au jour
• Pour le Code, Et augmente progressivement sa couverture de code
• ……
• En outre, Au fur et à mesure que les versions changent , D'autres tests seront ajoutés .Par exemple, dans RC7 Quand, Il est proposé d'avoir un terme de compatibilité , Compatibilité lors de la mise à jour ;In GA Quand, Introduire plus de tests sur l'ingénierie chaotique

Introduction au module d'essai

La deuxième partie donne des détails sur chaque module d'essai. .

Présentation générale

L'industrie a écrit le Code, c'est écrire bug Le drame de,Comme le montre l'image ci - dessous,85%De bug C'est par coding Introduction de la phase .

Du point de vue des tests, Le Code est écrit dans le processus de publication , Vous pouvez passer à travers Unit Test / Functional Test / System Test Pour découvrir bug; Mais avec le temps ,Réparation bug Le coût de , Il a donc tendance à être découvert tôt et réparé tôt .Mais, Chaque étape du test a son propre accent , Il n'est pas possible de découvrir tous les bug.

L'étape du développement, de l'écriture du Code à la fusion du Code à la branche principale, se déroule à partir de UT、code coverage Et code review Pour assurer la qualité du Code , Cela se reflète également dans CI Moyenne .Avant de soumettre PR Au cours du processus de fusion de code , Nécessite un contrôle de code statique 、Tests unitaires、 Critères de couverture des codes et reviewer Vérification du Code pour .

Lors de la fusion du Code , Il faut aussi réussir le test d'intégration .Pour garantir CI Ce ne sera pas long. , Dans ce test d'intégration, ,Opération principale L0 Et L1 Ces case. Après avoir réussi toutes les inspections ,On y est presque. milvusdb/milvus-dev  Publier ceci dans l'entrepôt PR Miroir construit. Après la publication du miroir , Des tâches programmées sont définies pour effectuer les différents tests mentionnés précédemment sur le dernier miroir ： Test complet de la fonction originale , Essais fonctionnels de nouvelles fonctionnalités ,Tests de déploiement,Essais de performance,Essais de stabilité, Tests de chaos, etc .

Tests unitaires

Les tests unitaires peuvent détecter la présence de logiciels dès que possible bug, Il est également possible de fournir des critères de validation pour le remaniement du Code .In Milvus De PR Parmi les critères d'admission , Test unitaire avec Code défini 80% Objectif de couverture.

https://app.codecov.io/gh/milvus-io/milvus/

Essais fonctionnels

C'est exact. Milvus Essai de fonctionnement,Principalement par pymilvus C'est SDK Comme point d'entrée.

Les tests fonctionnels portent principalement sur la capacité de l'interface à fonctionner comme prévu .

• Lors de l'entrée des paramètres normaux ou du fonctionnement normal ,SDK Si les résultats attendus peuvent être retournés
• Lorsque le paramètre ou l'opération est anormal ,SDK Oui Non handle Ces erreurs. , Peut également renvoyer des messages d'erreur raisonnables

La figure ci - dessous montre le cadre actuel de tests fonctionnels , Dans l'ensemble, il s'agit d'un cadre d'essai fondé sur le courant dominant actuel pytest,Et oui. pymilvus Un Encapsulation a été effectué, .La capacité d'essai automatique de l'interface est fournie .

Utiliser le cadre d'essai ci - dessus , Pas directement. pymilvus Interface Native, C'est parce que certaines méthodes communes doivent être extraites pendant le test. , Réutiliser certaines fonctions communes . Et en même temps check Module, Il est plus facile de vérifier certaines valeurs attendues et réelles .

En cours tests/python_client/testcases  Il y a déjà des cas de tests fonctionnels dans le répertoire 2700+,Essentiellement couvert pymilvus Toutes les interfaces pour, Et contient des cas d'utilisation positive et négative . Essais fonctionnels en tant que Milvus Garantie fonctionnelle de base , Grâce à l'automatisation et à l'intégration continue , Contrôle strict de chaque soumission PR Qualité.

Tests de déploiement

Test de déploiement ,Soutien Milvus Les formes de déploiement sont standalone Et cluster , Les moyens de déploiement sont les suivants: docker Ou helm.Une fois le déploiement terminé, Doit être exécuté sur le système restart Et upgrade Fonctionnement.

Redémarrer le test, Il s'agit principalement de vérifier la persistance des données , C'est - à - dire si les données avant le redémarrage peuvent continuer à être utilisées après le redémarrage ;Test de mise à niveau, Principalement pour vérifier la compatibilité des données , Prévenir l'introduction involontaire de formats de données incompatibles .

Les tests de redémarrage et de mise à niveau peuvent être unifiés dans le processus de test suivant: ：

Si le test de redémarrage , Les deux déploiements utilisent le même miroir ; S'il s'agit d'un test de mise à niveau , Le premier déploiement utilise une version plus ancienne du miroir , Le deuxième déploiement utilise une nouvelle version du miroir . Lors du deuxième déploiement , Redémarrer ou mettre à jour , Conserver les données d'essai après le premier déploiement （ Volumes Dossier ou PVC ）.In Run first test À cette étape,Plusieurs collection,Et pour chaque collection Effectuer une opération différente, Mettez - le dans un état différent ,Par exemple：

• create collection
• create collection --> insert data
• create collection --> insert data -->load
• create collection --> insert data -->flush
• create collection --> insert data -->flush -->load
• create collection --> insert data -->flush --> create index
• create collection --> insert data -->flush --> create index --> load
• ......

In Run second test  Deux types de validation sont effectués à cette étape ：

• Créé précédemment collection Diverses fonctions sont encore disponibles
• Peut créer un nouveau collection, Les mêmes fonctions sont toujours disponibles

Test de fiabilité

Actuellement pour Cloud native , Fiabilité des produits distribués , La plupart des entreprises testent par des méthodes d'ingénierie chaotique . L'ingénierie du chaos vise à étouffer les défauts dans les lambeaux ,C'est - à - dire les reconnaître avant qu'ils ne causent une interruption.Par défaut de fabrication actif,Tester le comportement du système sous diverses pressions,Identifier et corriger les problèmes,Éviter les conséquences graves.

En cours chaos test Heure,J'ai choisi. Chaos Mesh Comme outil d'injection de défaut .Chaos Mesh - Oui. PingCAP La société teste TiDB La fiabilité du processus d'éclosion , Idéal pour le test de fiabilité de la base de données distribuée Native Cloud .

Dans le type de défaut , Les types de défauts suivants sont réalisés ：

• D'abord, pod kill, La portée de l'essai est pour tous les composants , Simuler les temps d'arrêt des noeuds
• Deuxièmement, pod failure, Principalement axé sur work node Dans le cas de plusieurs copies de ,Il y a un pod Je ne peux pas travailler., Le système fonctionne encore
• Le troisième est memory stress , Accent sur la mémoire et CPU Pression, Principalement injecté dans work node Node of
• Le dernier. network partition ,C'est - à - dire: pod Avec pod Une communication isolée entre .Milvus Est une séparation de calcul de stockage , .Architecture à plusieurs niveaux avec séparation des noeuds de travail et de coordination , Il y a beaucoup de communication entre les différents composants ,Besoin de passer network partition Tester leur interdépendance

En construisant un cadre , Mise en œuvre plus automatisée Chaos Test.

Processus：

• Configuration de déploiement en lecture ,Initialiser un Milvus Cluster
• État du cluster ready Après, D'abord un e2e Tests,Validation Milvus Fonctions disponibles pour
• Exécution hello_milvus.py, Utilisé principalement pour vérifier la persistance des données , Crée un hello_milvus De collection,Effectuer l'insertion des données,flush,create index,load,search,query.Attention!,Non. collection release Et drop
• Créer un objet de surveillance , L'objet est principalement ouvert 6 Threads, Mise en œuvre séparée et continue create,insert,flush,index,search,query Fonctionnement

checkers = {
    Op.create: CreateChecker(),
    Op.insert: InsertFlushChecker(),
    Op.flush: InsertFlushChecker(flush=True),
    Op.index: IndexChecker(),
    Op.search: SearchChecker(),
    Op.query: QueryChecker()
}

• Première assertion avant injection de défaut ： Toutes les opérations devraient réussir
• Défaut de remplissage： Résoudre les défauts de définition yaml Documentation,Adoption Chaos Mesh,Vers Milvus Défaut d’injection dans le système ,Par exemple, query node Chaque 5s Par kill Une fois.
• Deuxième assertion pendant l'injection de défaut ： Juger de la période de défaillance Milvus Si les résultats des différentes opérations effectuées sont conformes aux attentes
• Supprimer la faute ：Adoption Chaos Mesh Supprimer les défauts précédemment injectés
• Suppression des défauts ,Milvus Après la restauration du service （Tous les pod Tous ready ）, Faire une troisième affirmation ： Toutes les opérations devraient réussir
• Exécuter un e2e Tests,Validation Milvus Fonctions disponibles pour, Parce que la troisième affirmation , Certaines opérations sont effectuées chaos Bloqué pendant l’injection , Même après l'élimination de la faute , Toujours bloqué , Il en résulte que la troisième affirmation n'a pas été aussi réussie que prévu . Cette étape est donc ajoutée pour appuyer le jugement de la troisième affirmation , Et pour l'instant, e2e Test as Milus Critères de récupération
• Exécution hello_milvus.py, Créé avant le chargement collection,Et à collection Effectuer une série d'opérations, Déterminer les données avant la défaillance après la récupération de la défaillance , Toujours disponible
• Collecte des journaux

Essais de stabilité et de performance

Essais de stabilité

Objet des essais de stabilité ：

• Milvus Peut être soumis à une charge de pression normale , Durée de fonctionnement en douceur
• Pendant le fonctionnement, Les ressources utilisées par le système sont demeurées stables ,Milvus Le service est normal

Considérez principalement deux scénarios de chargement ：

• Lecture intensive ：search Demande 90%,insert Demande 5%, Autres 5%. Ce scénario est principalement hors ligne ,Après l'importation des données, Pas de mise à jour , Fournit principalement des services de recherche
• Écrire intensément ： insert Demande 50%,search Demande 40%,Autres 10%. Ce scénario est principalement en ligne , Besoin d'un service pour insérer une requête en même temps

Points de contrôle：

• Lissage de l'utilisation de la mémoire
• CPU Lissage de l'utilisation
• IO Délai lisse
• Milvus De pod L'état est normal.
• Milvus Temps de réponse du Service lisse

Essais de performance

Objet des essais de performance：

• C'est exact. Milvus Toutes les interfaces pour la cartographie des performances
• Comparaison des performances, Trouver la meilleure configuration de paramètre pour l'interface
• Comme référence de performance , Empêcher la dégradation des performances dans les versions ultérieures
• Trouver les goulets d'étranglement de performance , Fournir une référence pour le réglage des performances

Scénarios de performance considérés principalement ：

• Performance d'insertion des données
  • Indicateurs de performance：Débit
  • Variables： Nombre de vecteurs insérés par lot ,......
• Performance de construction de l'index
  • Indicateurs de performance： Temps de construction de l'index
  • Variables：Type d'index,index node Nombre,......
• Performance de la requête vectorielle
  • Indicateurs de performance：Temps de réponse, Vecteurs de requête par seconde ,Demandes par seconde,Taux de rappel
  • Variables：nq,topK, Taille de l'ensemble de données ,Type d'ensemble de données,Type d'index,query node Nombre,Mode de déploiement,......
• ......

Cadre et processus d'essai

• Résoudre et mettre à jour la configuration ,Définir les indicateurs
  • server-configmap Ce qui correspond Milvus Configuration autonome ou groupée
  • client-configmap Correspond à la configuration du cas d'essai
• Configurer le serveur et le client
• Préparation des données
• Interaction des demandes entre le client et le serveur
• Rapport et présentation des données de l'indicateur

Méthodes et outils d'amélioration de l'efficacité

D'après ce qui précède, De nombreuses étapes du processus d'essai sont les mêmes ,Principalement des modifications Milvus server Configuration du terminal,client Configuration du terminal, Paramètres entrants de l'interface . Sous configuration multiple , Combinaison par permutation , De nombreuses expériences sont nécessaires pour couvrir une variété de scénarios d'essai , Donc le Code est réutilisé 、 Réutilisation des processus 、 L'efficacité des tests est une question très importante .

• Une méthode originale api_request Emballage décoratif pour , Configuré pour ressembler à un API gateway, Pour recevoir tous API Demande,Envoyé à Milvus Puis recevoir la réponse uniformément ,Retour à client. Il est plus facile de saisir des informations de log , Comme les paramètres passés 、Résultats retournés. Les résultats retournés en même temps peuvent être obtenus par checker Module à vérifier , Faciliter la définition de toutes les méthodes d'inspection dans le même checker Module
• Définir les paramètres par défaut, Encapsuler plusieurs étapes d'initialisation nécessaires en une seule fonction , Les fonctions qui nécessitent une grande quantité de code peuvent être implémentées par une interface . Ce réglage permet de réduire les codes redondants , Rendre chaque cas d'essai plus simple et plus clair
• Chaque cas d'essai est unique à l'Association collection Effectuer des tests, L'isolement des données entre les cas d'essai est garanti . Au début de l'exécution de chaque cas d'essai ,Créer un nouveau collection Pour tester, Après l'essai, le collection
• Parce que chaque cas d'essai est indépendant les uns des autres ,Lors de l'exécution du cas d'essai,Peut passer pytest Plug - in pour pytest -xdist Exécution simultanée,Amélioration de l'efficacité de la mise en œuvre

Github Action

GitHub Action Les avantages de：

• Avec GitHub Intégration profonde,Original CI/CD Outils
• Environnement machine configuré uniformément , Il est également pré - chargé avec de nombreux outils de développement de logiciels communs
• Prise en charge de plusieurs systèmes d'exploitation et versions ：Ubuntu, Mac Et Windows-server
• Riche marché de plug - ins , Offre une large gamme de fonctions de déballage et de prêt à l'emploi
• Adoption matrxi Pour organiser et combiner, Réutiliser le même ensemble de processus d'essai ,Prise en charge de la concurrence job,Pour améliorer l'efficacité

Les essais de déploiement et de fiabilité nécessitent un environnement isolé et indépendant ,Parfait pour GitHub Action Effectuer des essais à petite échelle sur . Fonctionnement quotidien programmé ,Testez le dernier master Miroir, Fonction d'inspection de routine .

Outils d'essai de performance

• Argo workflow：En créant workflow,Calendrier des tâches de mise en œuvre, Relier les processus en série . Comme vous pouvez le voir à droite ,Adoption Argo Plusieurs tâches peuvent être exécutées simultanément
• Kubernetes Dashboard：Visualisation server-configmap Et client-configmap
• NAS： Montage commun ann-benchmark Ensemble de données
• InfluxDB Et MongoDB: Enregistrer les résultats des indicateurs de performance
• Grafana： Surveillance des indicateurs de ressources côté serveur , Surveillance des indicateurs de rendement des clients
• Redash: Présentation du diagramme de performance

Veuillez estampiller l'explication vidéo complète ：

Deep dive#7 Milvus 2.0 Détails du système d'assurance de la qualité _Bip, bip, bip_bilibili

Si vous utilisez ,C'est exact. Milvus Toute amélioration ou suggestion ,Bienvenue à GitHub Ou toutes sortes de canaux officiels pour rester en contact avec nous ～

Zilliz Vision de la redéfinition de la science des données,Dédié à la création d'une entreprise mondiale leader dans l'innovation technologique Open Source,Et débloquer la valeur cachée des données non structurées pour les entreprises grâce à des solutions open source et Native Cloud.

Zilliz Construit Milvus Base de données vectorielle,Pour accélérer le développement de la plate - forme de données de la prochaine génération.Milvus La base de données est LF AI & Data Programme de graduation de la Fondation,Capacité de gérer un grand nombre d'ensembles de données non structurés,Trouvé dans un nouveau médicament、Système recommandé、Les robots de chat sont largement utilisés.