{"id":32632,"date":"2019-10-31T21:48:08","date_gmt":"2019-10-31T18:48:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo\/"},"modified":"2019-10-31T21:48:08","modified_gmt":"2019-10-31T18:48:08","slug":"ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","title":{"rendered":"Pas seulement le traitement : Comment nous avons fait de Kafka Streams une base de donn\u00e9es distribu\u00e9e, et ce qui en est sorti","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Salut, Habr !<\/p>\n

Nous rappelons qu'apr\u00e8s le livre sur Kafka<\/a><\/noindex> nous avons publi\u00e9 un ouvrage tout aussi int\u00e9ressant sur la biblioth\u00e8que Kafka Streams API<\/a><\/noindex>. <\/p>\n

\"Pas
\n
\nAlors que la communaut\u00e9 commence \u00e0 explorer les limites de cette puissante outil. R\u00e9cemment, un article est paru, dont nous souhaitons vous pr\u00e9senter la traduction. L'auteur partage son exp\u00e9rience sur la mani\u00e8re de transformer Kafka Streams en un stockage de donn\u00e9es distribu\u00e9. Bonne lecture !
\n<\/a><\/noindex>
\nLa biblioth\u00e8que Apache Kafka Streams<\/a><\/noindex> est utilis\u00e9e dans le monde entier dans les entreprises pour le traitement de flux distribu\u00e9 au-dessus d'Apache Kafka. Un des aspects souvent sous-estim\u00e9s de ce cadre est qu'il permet de conserver un \u00e9tat local g\u00e9n\u00e9r\u00e9 \u00e0 partir du traitement de flux.<\/p>\n

Dans cet article, je vais expliquer comment notre entreprise a pu tirer parti de cette fonctionnalit\u00e9 lors du d\u00e9veloppement d'un produit pour la s\u00e9curit\u00e9 des applications en cloud. Gr\u00e2ce \u00e0 Kafka Streams, nous avons cr\u00e9\u00e9 des microservices avec \u00e9tat partag\u00e9, chacun d'eux servant de source d'informations fiable sur l'\u00e9tat des objets dans le syst\u00e8me. Pour nous, c'est un pas en avant tant en termes de fiabilit\u00e9 que de facilit\u00e9 de support.<\/p>\n

Si vous \u00eates int\u00e9ress\u00e9 par une approche alternative, permettant d'utiliser une base de donn\u00e9es centrale pour g\u00e9rer l'\u00e9tat formel de vos objets \u2013 lisez, cela vaudra le d\u00e9tour\u2026 <\/p>\n

Pourquoi avons-nous jug\u00e9 qu'il \u00e9tait temps de changer nos m\u00e9thodes de travail avec l'\u00e9tat partag\u00e9 <\/b><\/p>\n

Nous devions maintenir l'\u00e9tat de divers objets, en nous appuyant sur les rapports des agents (par exemple : le site a-t-il \u00e9t\u00e9 attaqu\u00e9 ?). Avant notre passage \u00e0 Kafka Streams, nous comptions souvent sur une seule base de donn\u00e9es centrale (+ API de service) pour g\u00e9rer l'\u00e9tat. Cette approche a ses inconv\u00e9nients : dans des situations intensives en donn\u00e9es<\/a><\/noindex> le maintien de la coh\u00e9rence et de la synchronisation devient un v\u00e9ritable d\u00e9fi. La base de donn\u00e9es peut devenir un goulet d'\u00e9tranglement, ou se retrouver dans un \u00e9tat de concurrence<\/a><\/noindex> et souffrir de l'impr\u00e9visibilit\u00e9.<\/p>\n

\"Pas
\n
\nIllustration 1 : un sc\u00e9nario typique de s\u00e9paration d'\u00e9tat, rencontr\u00e9 avant le passage \u00e0
\nKafka et Kafka Streams : les agents communiquent leurs repr\u00e9sentations via l'API, l'\u00e9tat mis \u00e0 jour est calcul\u00e9 \u00e0 partir de la base de donn\u00e9es centrale. <\/i><\/p>\n

Faites connaissance avec Kafka Streams \u2013 il est d\u00e9sormais facile de cr\u00e9er des microservices avec un \u00e9tat partag\u00e9. <\/b><\/p>\n

Il y a environ un an, nous avons d\u00e9cid\u00e9 de revoir en profondeur nos sc\u00e9narios de travail avec l'\u00e9tat partag\u00e9 afin de r\u00e9soudre certains probl\u00e8mes. Nous avons imm\u00e9diatement d\u00e9cid\u00e9 d'essayer Kafka Streams - il est bien connu pour sa scalabilit\u00e9, sa haute disponibilit\u00e9 et sa r\u00e9silience, ainsi que pour la richesse de ses fonctionnalit\u00e9s de streaming (y compris les transformations avec conservation de l'\u00e9tat). C'\u00e9tait exactement ce dont nous avions besoin, sans parler de la maturit\u00e9 et de la fiabilit\u00e9 du syst\u00e8me de messagerie d\u00e9velopp\u00e9 autour de Kafka.<\/p>\n

Chacun des microservices que nous avons cr\u00e9\u00e9 avec conservation de l'\u00e9tat \u00e9tait bas\u00e9 sur une instance de Kafka Streams avec une topologie assez simple. Elle se composait de 1) une source 2) un processeur avec un stockage persistant de cl\u00e9s et de valeurs 3) un flux :<\/p>\n

\"Pas
\n
\nIllustration 2 : la topologie par d\u00e9faut de nos instances de streaming pour des microservices avec conservation de l'\u00e9tat. Notez qu'il y a \u00e9galement un stockage contenant des m\u00e9tadonn\u00e9es sur la planification. <\/i><\/p>\n

Avec cette nouvelle approche, les agents composent des messages envoy\u00e9s dans le topic source, tandis que les consommateurs - disons, le service d'avis par e-mail - re\u00e7oivent l'\u00e9tat partag\u00e9 calcul\u00e9 via le flux (topic de sortie).<\/p>\n

\"Pas
\n
\nIllustration 3 : un nouvel exemple de flux de t\u00e2ches pour un sc\u00e9nario avec des microservices partag\u00e9s : 1) un agent g\u00e9n\u00e8re un message qui entre dans le topic Kafka source ; 2) le microservice avec \u00e9tat partag\u00e9 (utilisant Kafka Streams) le traite et enregistre l'\u00e9tat calcul\u00e9 dans le topic Kafka de sortie ; ensuite 3) les consommateurs re\u00e7oivent le nouvel \u00e9tat.<\/i><\/p>\n

Eh bien, ce stockage int\u00e9gr\u00e9 de cl\u00e9s et de valeurs est vraiment tr\u00e8s utile !<\/b><\/p>\n

Comme mentionn\u00e9 pr\u00e9c\u00e9demment, notre topologie avec \u00e9tat partag\u00e9 contient un stockage de cl\u00e9s et de valeurs. Nous avons trouv\u00e9 plusieurs fa\u00e7ons de l'utiliser, et deux d'entre elles sont d\u00e9crites ci-dessous.<\/p>\n

Option #1 : utilisation du stockage de cl\u00e9s et de valeurs lors de calculs.<\/b><\/i><\/p>\n

Notre premier entrep\u00f4t de cl\u00e9s et de valeurs contenait des donn\u00e9es auxiliaires n\u00e9cessaires \u00e0 nos calculs. Par exemple, dans certains cas, l'\u00e9tat partag\u00e9 \u00e9tait d\u00e9termin\u00e9 selon le principe de la \u00ab majorit\u00e9 des voix \u00bb. Dans l'entrep\u00f4t, nous pouvions conserver tous les derniers rapports des agents concernant l'\u00e9tat d'un certain objet. Ensuite, en recevant un nouveau rapport d'un agent, nous pouvions le sauvegarder, extraire de l'entrep\u00f4t les rapports de tous les autres agents sur le m\u00eame objet et r\u00e9p\u00e9ter le calcul.
\nL'illustration 4 ci-dessous montre comment nous avons ouvert l'acc\u00e8s \u00e0 l'entrep\u00f4t de cl\u00e9s et de valeurs pour la m\u00e9thode de traitement du processeur, afin de pouvoir ensuite traiter un nouveau message.<\/p>\n

\"Pas
\n
\nIllustration 4 : ouverture de l'acc\u00e8s \u00e0 l'entrep\u00f4t de cl\u00e9s et de valeurs pour la m\u00e9thode de traitement du processeur (apr\u00e8s cela, dans chaque sc\u00e9nario travaillant avec un \u00e9tat partag\u00e9, il est n\u00e9cessaire d'impl\u00e9menter la m\u00e9thode doProcess<\/code>)<\/i><\/p>\n

Option #2 : cr\u00e9ation d'une API CRUD au-dessus de Kafka Streams<\/b><\/i><\/p>\n

Apr\u00e8s avoir configur\u00e9 notre flux de t\u00e2ches de base, nous avons essay\u00e9 d'\u00e9crire une API RESTful CRUD pour nos microservices avec un \u00e9tat partag\u00e9. Nous souhaitions pouvoir extraire l'\u00e9tat de certains ou de tous les objets, ainsi que d\u00e9finir ou supprimer l'\u00e9tat d'un objet (ce qui est utile pour le support c\u00f4t\u00e9 serveur).<\/p>\n

Pour supporter toutes les API de r\u00e9cup\u00e9ration d'\u00e9tat, chaque fois que nous devions recalculer l'\u00e9tat lors du traitement, nous le stockions durablement dans l'entrep\u00f4t de cl\u00e9s et de valeurs int\u00e9gr\u00e9. Dans ce cas, il est assez simple d'impl\u00e9menter une telle API \u00e0 l'aide d'une seule instance de Kafka Streams, comme montr\u00e9 dans le listing ci-dessous :<\/p>\n

\"Pas
\n
\nIllustration 5 : utilisation de l'entrep\u00f4t de cl\u00e9s et de valeurs int\u00e9gr\u00e9 pour obtenir l'\u00e9tat pr\u00e9-calcul\u00e9 d'un objet <\/i><\/p>\n

La mise \u00e0 jour de l'\u00e9tat d'un objet via l'API est \u00e9galement facile \u00e0 r\u00e9aliser. En principe, il suffit de cr\u00e9er un producteur Kafka, puis d'effectuer une \u00e9criture contenant le nouvel \u00e9tat. Cela garantit que tous les messages g\u00e9n\u00e9r\u00e9s via l'API seront trait\u00e9s exactement de la m\u00eame mani\u00e8re que ceux provenant d'autres producteurs (par exemple, des agents).<\/p>\n

\"Pas
\n
\nIllustration 6 : l'\u00e9tat d'un objet peut \u00eatre d\u00e9fini \u00e0 l'aide d'un producteur Kafka <\/i><\/p>\n

Une petite complication : Kafka a de nombreuses partitions<\/b><\/p>\n

Ensuite, nous souhaitions r\u00e9partir la charge li\u00e9e au traitement et am\u00e9liorer la disponibilit\u00e9 en fournissant un cluster de microservices avec un \u00e9tat partag\u00e9 pour chaque sc\u00e9nario. La configuration s'est av\u00e9r\u00e9e tr\u00e8s simple : apr\u00e8s avoir configur\u00e9 toutes les instances pour qu'elles fonctionnent avec le m\u00eame ID d'application (et avec les m\u00eames serveurs de d\u00e9marrage), presque tout le reste s'est fait automatiquement. Nous avons \u00e9galement d\u00e9fini que chaque topic source serait compos\u00e9 de plusieurs partitions, afin qu'\u00e0 chaque instance puisse \u00eatre attribu\u00e9 un sous-ensemble de ces partitions.<\/p>\n

Je mentionnerai \u00e9galement qu'il est courant ici de faire une sauvegarde de l'\u00e9tat, afin que, par exemple, en cas de restauration apr\u00e8s une panne, cette sauvegarde puisse \u00eatre transf\u00e9r\u00e9e vers une autre instance. Pour chaque stockage d'\u00e9tat dans Kafka Streams, un topic r\u00e9plicable avec un journal des modifications est cr\u00e9\u00e9 (dans lequel les mises \u00e0 jour locales sont suivies). Ainsi, Kafka pr\u00e9serve constamment le stockage d'\u00e9tat. Par cons\u00e9quent, en cas de d\u00e9faillance d'une instance, le stockage d'\u00e9tat de Kafka Streams peut \u00eatre rapidement restaur\u00e9 sur une autre instance, o\u00f9 les partitions correspondantes seront transf\u00e9r\u00e9es. Nos tests ont montr\u00e9 que cela se fait en quelques secondes, m\u00eame si des millions d'enregistrements se trouvent dans le stockage.<\/p>\n

Passer d'un microservice avec un \u00e9tat partag\u00e9 \u00e0 un cluster de microservices rend la mise en \u0153uvre de l'API Get State moins triviale. Dans cette nouvelle situation, le stockage d'\u00e9tat de chaque microservice ne contient qu'une partie du tableau global (les objets dont les cl\u00e9s correspondaient \u00e0 une partition sp\u00e9cifique). Il a donc fallu d\u00e9terminer sur quelle instance se trouvait l'\u00e9tat de l'objet dont nous avions besoin, et nous avons fait cela sur la base des m\u00e9tadonn\u00e9es des flux, comme indiqu\u00e9 ci-dessous :<\/p>\n

\"Pas
\n
\nIllustration 7 : Gr\u00e2ce aux m\u00e9tadonn\u00e9es des flux, nous d\u00e9terminons de quelle instance demander l'\u00e9tat de l'objet requis ; une approche similaire a \u00e9t\u00e9 appliqu\u00e9e avec l'API GET ALL.<\/i><\/p>\n

Principales conclusions<\/b><\/p>\n

Les stockages d'\u00e9tat dans Kafka Streams peuvent de fait servir de base de donn\u00e9es distribu\u00e9e, <\/p>\n