Il y a quelques problèmes dans la publication croisée en raison du dialecte de démarque dans le message d'origine. Surtout les diagrammes ne sont pas montrés qui existent dans le post d'origine. Veuillez donc vérifier l'original aussi si vous êtes intéressé. Je pense que l'original est plus compréhensible

Mise à niveau de HBase sur Event Sourcing et l'architecture CQRS en 3 semaines

TL;DR

Nous avons utilisé une stratégie de déploiement bleu-vert pour la mise à niveau de la version HBase en plus du système d'architecture Event Sourcing et CQRS.
L'approche de déploiement a plutôt bien fonctionné et n'a pris que trois semaines au total pour atteindre l'objectif du projet. Cette expérience était nouvelle et passionnante pour nous. Alors j'ai envie de le partager :)

À propos de la mise à jour de la base de données

Une mise à niveau de base de données est toujours gênante et chaque fois que vous faites face à de telles circonstances dans des scénarios de production, vous seriez super nerveux (je dirais 100 fois par rapport aux autres opérations de production auxquelles vous faites face) .

Ce sentiment est difficile à partager avec des personnes qui n'ont pas l'expérience ou l'exposition nécessaires à l'exploitation des environnements de base de données. Et je pense que 99,9 % des gens seraient d'accord si vous avez l'expérience et avez traversé des moments difficiles pour gérer les opérations liées à la base de données. C'est risqué et cela coûte cher, mais la mise à niveau elle-même ne signifie pas qu'elle apporte une nouvelle valeur au produit et bien qu'elle ne soit pas prioritaire dans de nombreux cas, à moins qu'il n'y ait une raison urgente.

En même temps, c'est un énorme risque caché si la base de données devient "intouchable" et comment traiter ce problème a été un sujet à travers, de nombreux développeurs et opérateurs ont été aux prises avec de telles situations

Approche de mise à niveau

En général, vous auriez deux choix.

mise à jour progressive

L'un est une mise à niveau progressive. Mise à niveau de la version de la base de données une par une de manière séquentielle.
J'ai trouvé une bonne explication ici. Veuillez lire ceci si vous n'êtes pas familier avec le mot.

Qu'entend-on par mise à niveau progressive dans le développement logiciel ?

Avantages
- Les données sont au même endroit. Vous n'avez donc pas besoin de réfléchir à la façon de synchroniser les données entre les différents clusters et de garantir que la synchronisation fonctionne parfaitement.
Inconvénients
- Une fois la mise à niveau terminée, il n'y a pas de moyen simple de revenir en arrière. Donc, si la mise à niveau déclenche un problème de performances d'une manière ou d'une autre, vous auriez de gros problèmes.
- La base de données de longue durée présente un état inattendu que vous ne pouvez pas reproduire dans l'environnement de test. Parfois, vous devez traiter le problème en ce qui concerne la production. Et cette possibilité vous rend vraiment nerveux.

déploiement bleu-vert

L'autre est un déploiement bleu-vert. Dans ce cas, vous devez provisionner le cluster de bases de données mis à niveau séparément et basculer l'application pour utiliser la nouvelle à un moment donné.
Veuillez consulter cet article de blog si vous n'êtes pas familier avec le mot "déploiement bleu-vert".

Déploiement BlueGreen

Je pense que cette approche est répandue dans le déploiement d'applications Web, mais si vous remplacez le mot "routeur" par "application" et "serveur Web" par "base de données", la même approche peut être appliquée à la mise à niveau de la base de données.

Avantages
- Vous ne touchez pas à la base de données de production en cours d'exécution lors de la mise à niveau. Cela vous facilite la vie par rapport à l'approche de mise à niveau progressive.
- Vous pouvez facilement revenir à l'ancien cluster en cas de problème inattendu. Et vous pouvez également répartir les requêtes progressivement afin de minimiser la portée en cas de problème (pour ce faire, comme dans "Inconvénients", vous devez cependant synchroniser les données du nouveau cluster à l'ancien cluster)
- En raison du facteur ci-dessus, vous pouvez raccourcir quelque peu le test de charge sur l'environnement de test et poursuivre le projet rapidement.
Inconvénients
- Vous devez vous assurer que les données sont synchronisées entre les deux clusters de bases de données. Non seulement de l'ancien cluster au nouveau cluster, mais également du nouveau cluster à l'ancien cluster si vous souhaitez avoir un moyen simple de revenir après la mise à niveau. Mais la réplication mutuelle des données est assez difficile dans de nombreux cas. Il peut être possible d'écrire sur deux clusters à chaque opération, mais vous devez vous préparer lorsqu'un seul cluster est arrêté et que l'opération sur ce cluster uniquement échoue. Cette manipulation serait vraiment compliquée.
- Vous devez avoir des serveurs de taille double lors de l'exécution des deux clusters. Cela coûtera de l'argent et peut être difficile si votre système n'est pas sur une infrastructure cloud.

Notre approche

Fondamentalement, notre approche est un déploiement bleu-vert. Et parce que nous avons Kafka en tête en tant que bus d'approvisionnement d'événements, il était beaucoup plus facile de gérer le problème de synchronisation des données dans les "Cons" énumérés ci-dessus.

Architecture actuelle

Tout d'abord, permettez-moi de présenter l'architecture de base. Au fait, nous appelons l'ensemble du sous-système de messages de chat "Falcon". C'est pourquoi l'icône du faucon est dans le diagramme.

lorsqu'un utilisateur final publie un message de chat, write-api place les données du message dans Kafka
read-model-updater ("rmu" en abrégé) récupère les données de Kafka, les convertit en read-model et les place dans HBase
lorsqu'un utilisateur final lit des messages de chat, read-api extrait les données de message de HBase

Je n'explique pas pourquoi nous avons choisi CQRS dans cet article. Veuillez donc consulter les diapositives ci-dessous si vous souhaitez en savoir plus ou si vous n'êtes pas familier avec le concept de CQRS.
Kafka Summit SF 2017 - Services de messagerie mondiaux évolutifs et résilients avec Kafka et Kafka Streams
Services de messagerie mondiaux évolutifs et résilients par CQRS et Event Sourcing utilisant Akka, Kafka Streams et HBase

Flux de mise à niveau de la base de données

Maintenant, je vais vous expliquer comment nous avons fait la mise à jour de la base de données sur cette architecture

Étape 1 : Préparez de nouveaux clusters et effectuez une restauration initiale à partir de la sauvegarde.

Étape 2 : Préparez un autre consommateur (rmu2 dans ce diagramme) pour synchroniser les données de Kafka avec le nouveau cluster de bases de données. Vous rejouerez les anciens événements Kafka à partir d'avant la restauration initiale. Assurez-vous d'implémenter l'idempotence sur votre consommateur. Je veux dire, le système doit fonctionner correctement même si le même événement est consommé plus d'une fois.

Étape 3 : Lorsque le nouveau consommateur (rmu2) a rattrapé les derniers messages Kafka, préparez une autre API de lecture en extrayant les données du nouveau cluster de base de données. Et envoyez progressivement les requêtes à la nouvelle read-api.

Il y aurait une différence d'état entre l'ancien cluster et le nouveau cluster même si la synchronisation des données est terminée en quelques millisecondes. Nous avons eu un petit problème en raison de cette différence, vous devez donc confirmer et exécuter une vérification d'évaluation afin de voir quel type de problème peut être déclenché par la différence entre les clusters et votre logique d'application au préalable. Ou si vous avez de bonnes couches devant read-api pour distribuer la demande en fonction de l'attribut utilisateur ou quelque chose (par exemple, routage via Nginx ou Envoy comme proxy), vous pouvez simplement définir la règle appropriée et la différence peut être gérée efficacement et ce ne sera pas un problème.

Et dans la rétrospective de ce projet, nous avons remarqué que si vous pouvez refléter les requêtes d'une API existante vers une nouvelle API, vous pouvez effectuer les tests de charge en utilisant le trafic de production sans affecter les utilisateurs finaux.

Étape 4 : Passez à la nouvelle read-api à 100 % et arrêtez les anciens clusters et applications lorsque vous êtes sûr que tout fonctionne parfaitement.

Pourquoi je pense que cette approche est meilleure

Permettez-moi d'expliquer la différence avec l'approche bleu-vert normale. Un problème dans le bleu-vert normal est que vous devez vous assurer que les données sont synchronisées sur les deux clusters, idéalement non seulement avant la mise à niveau, mais également après la mise à niveau. Dans cette approche, au lieu d'utiliser la fonctionnalité de réplication fournie par la base de données, les mises à jour de la base de données sont appliquées séparément via l'application que nous écrivons et préparons. Cette approche nous apporte beaucoup de mérites.

Tout d'abord, comme ils fonctionnent séparément, vous n'avez pas à vous soucier de la synchronisation des données à chaque phase. En particulier, vous aurez besoin d'efforts supplémentaires (et assez difficiles dans la plupart des cas) pour synchroniser les données du nouveau cluster vers l'ancien si vous souhaitez avoir un moyen simple de revenir en arrière après la mise à niveau. Mais dans cette approche, ils travaillent simplement de manière indépendante. Vous pouvez donc simplement revenir aux anciens au cas où un problème inattendu surviendrait après la mise à niveau.

Deuxièmement, vous n'avez pas à vous soucier de la compatibilité des versions entre les anciens clusters et les nouveaux clusters. Si vous utilisez la fonctionnalité de synchronisation des données de cluster fournie par la base de données, des problèmes de restriction de version et de compatibilité peuvent survenir dans certains cas extrêmes. Mais dans cette approche, tout ce que vous avez à faire est de préparer une application indépendante qui place les données dans chaque base de données. Je pense que c'est le problème que vous pouvez résoudre beaucoup plus facilement dans la plupart des cas. Et en théorie, non seulement mettre à jour la version de la base de données, mais vous pouvez également basculer le nouveau cluster vers un autre complètement différent (par exemple, DynamoDB) en utilisant la même approche. Dans ce cas, vous ne pouvez pas utiliser les données de sauvegarde pour la configuration initiale et devez préparer le programme initial de migration des données. Cela prendra du temps, mais je pense que c'est la question raisonnable à traiter.

Conclusion

Les sujets CQRS et event sourcing sont souvent abordés dans l'architecture logicielle. D'un point de vue opérationnel, le fait d'avoir une couche supplémentaire en tant que bus d'événements augmente la complexité de l'infrastructure et les coûts d'exploitation. Honnêtement, je n'aimais pas tellement cette approche de ce point de vue auparavant. Mais nous avons remarqué que cela change également la façon dont nous exploitons l'infrastructure et nous apporte la tranquillité dans le fonctionnement de la base de données. Et oui, je suis un grand fan du CQRS et de l'approvisionnement en événements maintenant :)

Prochain défi

Vous vous demandez peut-être ce que nous mettrons à niveau Kafka (bus de sourcing d'événements) ? Oui, ce sera notre prochain défi. J'espère qu'il existe une meilleure approche que la mise à niveau progressive normale et le déploiement bleu-vert. La vie d'ingénieur continue !