Couchbase sur Telecom

La transformation numérique est une tendance mondiale pour les grandes entreprises et est vitale pour adapter une entreprise aux besoins des clients modernes. En plus des problèmes habituels de centralisation des systèmes pour les grandes entreprises et de combinaison des systèmes de facturation et des bases de données des abonnés, s'ajoutent des exigences de haute disponibilité et un mode de fonctionnement en temps réel auxquels les clients sont déjà habitués par les leaders de l'industrie (Google, Amazon, Netflix).

Les nouveaux défis nécessitent de nouvelles technologies et approches qui sont nécessaires pour réduire le temps pour introduire des fonctions pratiques pour le client, des offres commerciales personnalisées, une réponse rapide aux offres des concurrents, ainsi que le contrôle des coûts pour les systèmes, l'infrastructure informatique, les centres de données et le personnel qualifié. Ces tendances sont également un gros inconvénient: la complexité de l'architecture et des bases de données transactionnelles gonflées qui ne peuvent pas faire face au flux et au traitement de l'information. Les technologies de la génération précédente ont un plafond d'échelle verticale. Par exemple, une instance Oracle DBMS s'exécute à la limite du serveur le plus puissant sur les processeurs x86 avec une charge d'un milliard de transactions par jour.

Afin de résister à une charge similaire à laquelle l'industrie Internet est confrontée depuis longtemps, une nouvelle pile de technologies est utilisée, comme les caches en mémoire et les bases de données NoSQL. Ainsi, Apple utilise Cassandra, Sberbank - Ignite (GridGain), dans MegaFon nous utilisons Couchbase et Tarantool.

MegaFon utilise différents modèles architecturaux pour le SGBD en mémoire:

1. Cache simple, mis à jour dans les délais ou par événement à partir de la base de données et des applications
2. Toutes les modifications de la base de données sont effectuées via le cache (script d'écriture), par exemple, la connexion d'un client Oracle à DCP Couchbase

Pour l'un de nos systèmes de décision pour la durée de vie de l'abonné, nous utilisons le premier modèle, car une seule application sur la totalité des données prend une décision et l'envoie à tous les systèmes, y compris la base de données Oracle. L'un des cas les plus brillants d'utilisation du cycle de vie d'un abonné est le verrouillage et le déverrouillage sur un solde négatif. Après tout, tous les abonnés des opérateurs mobiles après avoir réapprovisionné le solde veulent être immédiatement en contact et passer des appels. Grâce à une application séparée et à Couchbase, nous avons pu réduire le temps de sortie de la serrure de 90 secondes à 30 et ce n'est pas la limite. Seul l'enregistrement sur le changement de statut de l'abonné sera enregistré dans la base de données principale (Fig.1)

Grâce à l'utilisation des nouvelles technologies, nous avons pu 3 fois réduire le temps de sortie du verrou financier. Mais pour obtenir les résultats actuels, nous avons parcouru un long chemin dans la transformation architecturale du circuit de facturation et dans le choix de la base de données NoSQL.

Pourquoi avons-nous choisi Couchbase? Il y a plusieurs raisons à cela.

Exigence de performance

1. Traitement jusqu'à 200 000 demandes par seconde.
2. Le temps de réponse moyen (50%) peut atteindre 5 ms (dans un seul centre de données).
3. Le temps de réponse maximal (99%) peut atteindre 15 ms (dans un centre de données).
4. Performance d'insertion maximale 500 Mo / sec
5. Nombre maximum d'opérations d'insertion 100 000 / s
6. Nombre maximal d'opérations de modification (mises à jour de documents) 100 000 / s
7. Performances maximales des modifications (mises à jour des documents) 500 Mo / sec
8. Nombre maximal d'opérations de lecture 100 000 / s
9. Vitesse de lecture maximale 500 Mo / sec

Recherche de clés haute performance et accès aux données

Au cœur de Couchbase se trouve Distributed Key Vault (KV). Le référentiel KV est une approche de gestion des données extrêmement simple qui stocke un identifiant unique (clé) ainsi qu'une information arbitraire. Le référentiel KV lui-même peut accepter toutes les données, que ce soit un blob binaire ou un document JSON. En raison de la simplicité de l'implémentation KV, l'accès aux données est assuré avec un minimum de retard. Comme notre expérience le montre, la latence du réseau est plus souvent 2-3 fois plus élevée que la fourniture de données clés du côté Couchbase.

Schéma de stockage dynamique ( JSON)

Les documents sont stockés sur le serveur Couchbase au format JSON. Le format prend en charge les types de données de base, tels que les nombres, les chaînes et les types complexes, ainsi que les dictionnaires et les tableaux intégrés.

Le schéma de données dans Couchbase est une construction logique définie par l'application et le développeur. En raison de sa flexibilité et de la possibilité d'utiliser plusieurs options, nous pouvons utiliser une balise dans le document, par exemple, avec des informations de version. Cela permet à l'application de déterminer dans quel mode le document doit être traité, ainsi que d'assurer une migration en douceur de la base de données vers le nouveau schéma de données.

Haute disponibilité

L'un des paramètres constitutifs d'un système d'information est sa disponibilité. Couchbase offre une haute disponibilité des données avec de nombreuses fonctionnalités différentes. L'un d'eux est la réplication de données (la distribution de plusieurs copies de données sur différents serveurs de cluster), qui vous permet de fournir un service lors de la maintenance de routine ou de la panne de certains serveurs.

La deuxième fonctionnalité importante pour la haute disponibilité est le DCP (Database Change Protocol) interne. Il fournit un transfert de changement à grande vitesse vers toutes les copies de données, les index secondaires (GSI), la réplication inter-cluster (XDCR) et les consommateurs externes.

Réplication bidirectionnelle

La bonne pratique dans les entreprises consiste à utiliser la redondance pour tous les processus et équipements commerciaux. Idéalement, il s'agit d'une sauvegarde en mode actif-actif, lorsque la commutation entre les nœuds problématiques se produit automatiquement. La réplication bidirectionnelle dans Couchbase active le mode AA. Mais tester la réplication a montré qu'elle n'est efficace que dans les centres de données à proximité. Avec un espacement de plus de 100 km, des conflits apparaissent. Couchbase dispose de mécanismes de résolution des conflits: basés sur l'horodatage et le numéro de séquence. Cependant, en raison du retard sur le réseau, des données obsolètes pénètrent dans la base de données. Nous avons abandonné l'utilisation de la réplication bidirectionnelle (cohérence inter-cluster). Toutes les modifications sont effectuées sur un seul cluster. La disponibilité des données en mode lecture est fournie dans tous les centres de données (AA).

Mise à l'échelle horizontale

Une des caractéristiques importantes de la plupart des bases de données NoSQL est la mise à l'échelle horizontale (Fig. 3). La principale différence de Couchbase est la prise en charge de la mise à l'échelle multidimensionnelle, lorsque nous, dans le cluster, pouvons uniquement augmenter les performances du service souhaité. Par exemple, le jeu Pokemon GO utilise une architecture divisée. Au début du projet, 5 serveurs avec services combinés ont été utilisés. Après avoir augmenté la charge, ils ont utilisé une architecture diversifiée: 5 serveurs de données et 55 serveurs pour le traitement des requêtes et des index. L'un des inconvénients de la mise à l'échelle avec Couchbase est que l'orchestrateur a des problèmes lorsqu'il y a plus de 50 nœuds de date dans le cluster.

Figure 3 MDS

Exigences SI

Les exigences de sécurité de l'information ont influencé notre choix dans une moindre mesure, mais leur présence dans le système a fait un argument supplémentaire en faveur de l'une ou l'autre base de données. Le cache pouvant contenir des données personnelles, nous devons impérativement suivre les exigences du régulateur. Il vaut la peine de décider: allons-nous utiliser du matériel supplémentaire ou pouvons-nous le fournir avec la base de données elle-même?!

Dans la version entreprise, Couchbase prend en charge le chiffrement du trafic, le chiffrement des données et l'accès personnalisé. Cela permet d'économiser de l'argent sur des équipements tels que Cisco ASA.

Mise à niveau facile

L'une des principales forces de Couchbase est son mécanisme de mise à jour transparent et la prise en charge des anciennes versions de l'API. Pendant la mise à niveau du cluster, il fonctionne en mode de compatibilité. Les nouveaux mécanismes ne fonctionneront qu'après une mise à niveau complète du cluster. Les effets sur les applications en cours d'exécution sont minimes en raison de la prise en charge de l'ancienne API.

PS: la mise à niveau / rétrogradation est autorisée uniquement sur les versions principales voisines

Fonctionnalité supplémentaire

Distribution logique

Une autre caractéristique intéressante est la combinaison de serveurs dans un cluster en groupes logiques, avec des répliques attachées à eux. Cela vous permet de distribuer des copies complètes des répliques du même cluster à différents autogates. Cela permet à l'un des concessionnaires automobiles de ne pas avoir une copie complète des données dans le deuxième

Sauvegarde et restauration

Couchbase contient des outils de sauvegarde et de récupération prêts à l'emploi. Le processus de sauvegarde peut fonctionner en trois modes: complet, différentiel et cumulatif. Cela permet dans certains cas d'économiser de l'espace disque et des ressources processeur.

Couchbase vs mongo

Il est difficile de répondre à la question du choix de bases de données NoSQL alternatives, et souvent, le meilleur Unix est celui que votre administrateur connaît. Essayons de formuler pourquoi nous avons préféré Couchbase, et pas une autre plate-forme très populaire - MongoDB.

Il est assez difficile de comparer deux projets différents avec une architecture et des fonctionnalités différentes. L'un des paramètres auxquels nous avons prêté attention est la facilité de maintenance et la possibilité de reconfigurer rapidement le système pour répondre aux besoins de l'entreprise.

Tableau 1 Comparaison

Tableau 2 Comparaison de réplication

Dans l'ensemble, Couchbase est plus flexible et plus simple dans les paramètres requis pour nos tâches et l'architecture hybride en évolution rapide.

Expérience d'exploitation

Pour commencer, nous aimerions donner les numéros avec lesquels le système et le cluster fonctionnent maintenant sur Couchbase.

1. Plus de 80 millions d'abonnés [i]
2. 380 millions de documents d'information client JSON
3. Disque dur de 3,5 To (nous utilisons memcached, les informations sur le disque sont stockées pour un démarrage rapide)
4. 3 To de RAM
5. 50000 opérations par seconde (Fig.5)
6. 50 microservices qui traitent l'intégralité du flux de messages

Les premiers jalons de la transformation, nous avons commencé avec la troisième version de Couchbase. Au premier stade, au début du projet, toutes les applications fonctionnaient de manière stable. Mais lorsque nous avons traduit une logique supplémentaire en un nouveau mécanisme, nous avons été confrontés au fait que le mécanisme View a commencé à fonctionner de manière imprévisible. C'est-à-dire à un moment donné, le processus se bloque et ces vues d'un tel nœud ont cessé de revenir. Dans le même temps, l'accès aux données et leur traitement n'ont pas été interrompus. Le problème a été résolu assez facilement - en redémarrant le nœud, ce qui a généralement réduit la disponibilité du service. Au cours de la communication avec le support technique de Couchbase, on nous a proposé une commande non documentée qui redémarre uniquement le processus d'affichage

curl -s --data 'cb_couch_sup: restart_couch ().' -u Administrateur: passez http://127.0.0.1:8091/diag/eval [ii]

La commande n'est valide que dans les versions 3.x.

curl -s --data 'couch_server_sup: restart_core_server ().' -u Administrateur: Administrateur http://127.0.0.1:8091/diag/eval

La commande n'est valide que dans les versions 4.x.

Un autre problème de la troisième version était le mécanisme de compression des données (compactage). Il a dû être démarré manuellement en fonction des mesures de surveillance déclenchées. Les deux problèmes ont maintenu la tension non seulement pendant le quart de travail, mais aussi chez les ingénieurs fonctionnels.

À cet égard, nous avons décidé de migrer vers la quatrième version. La migration avec un impact minimal sur le service a pris environ deux semaines. Le processus de mise à jour lui-même ne nécessite pas d'actions et de contrôle complexes, mais lors de l'ajout ou de la suppression d'un nœud, un rééquilibrage est lancé, ce qui prend au moins deux heures. Dans le processus, nous avons trouvé un moyen d'accélérer le processus de mise à jour via un serveur tampon: dans ce cas, il ne démarre pas un processus de rééquilibrage propre, mais le transfert de données d'un nœud à un autre. Cela a réduit le processus de mise à jour à 30 minutes.

Lors de la mise à jour d'un cluster industriel, les nuances suivantes doivent être prises en compte: travailler en mode compatibilité, lorsque le cluster fonctionne en mode de la plus jeune version du logiciel. Du côté positif, le processus de mise à niveau se déroule sans heurts et sans douleur, mais néanmoins, vous ne pourrez pas utiliser de nouvelles fonctions, telles que le nouveau mécanisme de compression, N1QL, tant que le cluster entier ne sera pas entièrement mis à jour.

Après la mise à jour, nous avons réussi à résoudre un seul problème: la compression. Cela a commencé à fonctionner correctement. Avec le mécanisme View, le problème persiste, même s'il est répété beaucoup moins fréquemment. Il n'a été possible de le corriger que par les forces des développeurs de Couchbase dans la version 4.6.4.

Dans le cadre de la résolution des problèmes de support technique, il est devenu clair que le mécanisme d'affichage ne sera plus mis à jour. Cela a été fait sur la base du fait que la plupart des clients Couchbase n'utilisent pas les vues aux fins pour lesquelles ils ont été créés, et Couchbase a créé un nouveau mécanisme N1QL. Il est exécuté par un service distinct et ne dépend plus des nœuds de données (Fig. 7)

Nous avons fermé tous les problèmes critiques avec la version 4.6.4. Mais en raison de l'augmentation du volume de données, ils ont décidé de migrer vers la cinquième version, où ils ont ajouté une nouvelle base de données pour les index et sur nos données, la quantité de mémoire et de disques a diminué une fois et demie. Mais, malheureusement, nous n'avons pas observé de diminution de la quantité de données sur les nœuds de données.

Conclusions

En général, Couchbase s'est avéré être un système mature qui détient une charge élevée, même dans des cas non spécifiques (Viber - utilisé comme base de données). Au sein de l'architecture hybride MegaFon, le cluster peut être facilement adapté à tout usage sans interruption de l'équipement et sans reconfiguration sérieuse du serveur, ce qui permet généralement à l'entreprise de réduire les coûts de personnel et de rendre le service pour l'abonné aussi pratique que possible.

PAO MegaFon

Kovalchuk Egor 2018

[i] Le système traite non seulement les abonnés, mais aussi les appareils avec cartes SIM intégrées, modems, etc.

[ii] Consulter un spécialiste avant utilisation