{"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\/pt\/blog\/administrirovanie\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","title":{"rendered":"N\u00e3o apenas processamento: Como transformamos Kafka Streams em um banco de dados distribu\u00eddo e o que aconteceu com isso","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ol\u00e1, Habr!<\/p>\n

Lembramos que, ap\u00f3s o livro sobre Kafka<\/a><\/noindex> lan\u00e7amos um trabalho igualmente interessante sobre a biblioteca Kafka Streams API<\/a><\/noindex>. <\/p>\n

\"N\u00e3o
\n
\nEnquanto a comunidade apenas come\u00e7a a explorar os limites das capacidades desta poderosa ferramenta. Recentemente, foi publicado um artigo que gostar\u00edamos de apresent\u00e1-lo. A partir de sua pr\u00f3pria experi\u00eancia, o autor conta como fazer do Kafka Streams um armazenamento de dados distribu\u00eddo. Boa leitura!
\n<\/a><\/noindex>
\nA biblioteca Apache Kafka Streams<\/a><\/noindex> \u00e9 utilizada em todo o mundo no setor de empresas para processamento de fluxo distribu\u00eddo sobre o Apache Kafka. Um dos aspectos subestimados deste framework \u00e9 que ele permite manter um estado local, gerado a partir do processamento de fluxo.<\/p>\n

Neste artigo, contarei como a nossa empresa conseguiu utilizar essa capacidade de maneira vantajosa no desenvolvimento de um produto para seguran\u00e7a de aplica\u00e7\u00f5es em nuvem. Com o Kafka Streams, criamos microsservi\u00e7os com estado compartilhado, cada um dos quais serve como uma fonte resistente a falhas e altamente dispon\u00edvel de informa\u00e7\u00f5es confi\u00e1veis sobre o estado dos objetos no sistema. Para n\u00f3s, isso representa um avan\u00e7o tanto em termos de confiabilidade quanto em termos de facilidade de suporte.<\/p>\n

Se voc\u00ea est\u00e1 interessado em uma abordagem alternativa que permita usar um \u00fanico banco de dados central para manter o estado formal de seus objetos \u2013 leia, ser\u00e1 interessante... <\/p>\n

Por que decidimos que era hora de mudar nossas abordagens em rela\u00e7\u00e3o ao trabalho com estado compartilhado <\/b><\/p>\n

Precis\u00e1vamos manter o estado de v\u00e1rios objetos, baseando-nos em relat\u00f3rios de agentes (por exemplo: o site foi atacado?). Antes da transi\u00e7\u00e3o para o Kafka Streams, costum\u00e1vamos depender de um \u00fanico banco de dados central (+ API de servi\u00e7o) para gerenciar o estado. Essa abordagem tem suas desvantagens: em situa\u00e7\u00f5es intensivas em dados<\/a><\/noindex> a manuten\u00e7\u00e3o da consist\u00eancia e sincroniza\u00e7\u00e3o se torna um verdadeiro desafio. O banco de dados pode se tornar um gargalo, ou acabar em um estado de corrida<\/a><\/noindex> e sofrer de imprevisibilidade.<\/p>\n

\"N\u00e3o
\n
\nIlustra\u00e7\u00e3o 1: um cen\u00e1rio t\u00edpico de divis\u00e3o de estado, encontrado antes da transi\u00e7\u00e3o para
\nKafka e Kafka Streams: os agentes comunicam suas representa\u00e7\u00f5es atrav\u00e9s da API, o estado atualizado \u00e9 calculado atrav\u00e9s do banco de dados central <\/i><\/p>\n

Conhe\u00e7a o Kafka Streams \u2013 agora \u00e9 f\u00e1cil criar microsservi\u00e7os com estado compartilhado <\/b><\/p>\n

Cerca de um ano atr\u00e1s, decidimos revisar nossos cen\u00e1rios de trabalho com estado compartilhado para resolver alguns problemas. Imediatamente decidimos experimentar o Kafka Streams \u2013 \u00e9 bem conhecido o qu\u00e3o escal\u00e1vel, dispon\u00edvel e resistente a falhas ele \u00e9, al\u00e9m do rico conjunto de funcionalidades de streaming (transforma\u00e7\u00f5es, incluindo aquelas com estado preservado). Era exatamente o que precis\u00e1vamos, sem mencionar o qu\u00e3o madura e confi\u00e1vel a sistema de troca de mensagens se tornou no Kafka.<\/p>\n

Cada um dos microservi\u00e7os que criamos com estado preservado foi constru\u00eddo com base em uma inst\u00e2ncia do Kafka Streams com uma topologia bastante simples. Ela consistia em 1) uma fonte 2) um processador com armazenamento persistente de chaves e valores 3) um fluxo:<\/p>\n

\"N\u00e3o
\n
\nIlustra\u00e7\u00e3o 2: a topologia padr\u00e3o de nossas inst\u00e2ncias de streaming para microservi\u00e7os com estado preservado. Observe que tamb\u00e9m h\u00e1 um armazenamento aqui, onde est\u00e3o os metadados sobre o planejamento. <\/i><\/p>\n

Com essa nova abordagem, os agentes comp\u00f5em mensagens que s\u00e3o enviadas ao t\u00f3pico de origem, e os consumidores \u2013 digamos, o servi\u00e7o de notifica\u00e7\u00f5es por e-mail \u2013 recebem o estado compartilhado calculado atrav\u00e9s do fluxo (t\u00f3pico de sa\u00edda).<\/p>\n

\"N\u00e3o
\n
\nIlustra\u00e7\u00e3o 3: um novo exemplo do fluxo de tarefas para o cen\u00e1rio com microservi\u00e7os compartilhados: 1) um agente gera uma mensagem que chega ao t\u00f3pico de origem do Kafka; 2) o microservi\u00e7o com estado compartilhado (usando Kafka Streams) processa ela e grava o estado calculado no t\u00f3pico final do Kafka; ap\u00f3s isso, 3) os consumidores recebem o novo estado.<\/i><\/p>\n

Ei, esse armazenamento interno de chaves e valores realmente \u00e9 muito \u00fatil!<\/b><\/p>\n

Como mencionado acima, nossa topologia com estado compartilhado cont\u00e9m um armazenamento de chaves e valores. Encontramos v\u00e1rias op\u00e7\u00f5es para sua utiliza\u00e7\u00e3o, e duas delas est\u00e3o descritas abaixo.<\/p>\n

Op\u00e7\u00e3o #1: uso do armazenamento de chaves e valores em c\u00e1lculos.<\/b><\/i><\/p>\n

O nosso primeiro armazenamento de chave-valor continha dados auxiliares necess\u00e1rios para nossos c\u00e1lculos. Por exemplo, em alguns casos, o estado compartilhado era determinado pelo princ\u00edpio da \"maioria dos votos\". No armazenamento, pod\u00edamos manter todos os relat\u00f3rios mais recentes dos agentes sobre o estado de um determinado objeto. Assim, ao receber um novo relat\u00f3rio de um dos agentes, pod\u00edamos salv\u00e1-lo, extrair do armazenamento os relat\u00f3rios de todos os outros agentes sobre o mesmo objeto e repetir os c\u00e1lculos.
\nAbaixo, na Ilustra\u00e7\u00e3o 4, mostramos como abrimos o acesso ao armazenamento de chave-valor para o m\u00e9todo processador, permitindo assim que uma nova mensagem pudesse ser processada.<\/p>\n

\"N\u00e3o
\n
\nIlustra\u00e7\u00e3o 4: abrindo acesso ao armazenamento de chave-valor para o m\u00e9todo processador (depois disso, em cada cen\u00e1rio que lida com estado compartilhado, \u00e9 necess\u00e1rio implementar o m\u00e9todo doProcess<\/code>)<\/i><\/p>\n

Op\u00e7\u00e3o #2: cria\u00e7\u00e3o de uma API CRUD sobre Kafka Streams<\/b><\/i><\/p>\n

Ap\u00f3s configurar nosso fluxo b\u00e1sico de tarefas, come\u00e7amos a tentar escrever uma API RESTful CRUD para nossos microsservi\u00e7os que lidam com estado compartilhado. Quer\u00edamos que fosse poss\u00edvel extrair o estado de alguns ou todos os objetos, al\u00e9m de definir ou remover o estado de um objeto (isso \u00e9 \u00fatil para a manuten\u00e7\u00e3o do backend).<\/p>\n

Para suportar toda a API Get State, sempre que precis\u00e1vamos recomputar o estado durante o processamento, armazen\u00e1vamos temporariamente no armazenamento integrado de chave-valor. Nesse caso, \u00e9 bastante simples implementar essa API usando uma \u00fanica inst\u00e2ncia do Kafka Streams, como mostrado no listagem abaixo:<\/p>\n

\"N\u00e3o
\n
\nIlustra\u00e7\u00e3o 5: utilizando o armazenamento integrado de chave-valor para obter o estado pr\u00e9-computado de um objeto <\/i><\/p>\n

A atualiza\u00e7\u00e3o do estado do objeto atrav\u00e9s da API tamb\u00e9m n\u00e3o \u00e9 dif\u00edcil de implementar. Basicamente, para isso, \u00e9 necess\u00e1rio apenas criar um produtor Kafka e, com ele, fazer uma grava\u00e7\u00e3o que contenha o novo estado. Isso garante que todas as mensagens geradas atrav\u00e9s da API sejam processadas exatamente da mesma forma que aquelas provenientes de outros produtores (por exemplo, agentes).<\/p>\n

\"N\u00e3o
\n
\nIlustra\u00e7\u00e3o 6: o estado do objeto pode ser definido com um produtor Kafka <\/i><\/p>\n

Um pequeno complicador: o Kafka possui v\u00e1rias parti\u00e7\u00f5es<\/b><\/p>\n

Continuando, quer\u00edamos distribuir a carga relacionada ao processamento e melhorar a disponibilidade, fornecendo para cada cen\u00e1rio um cluster de microsservi\u00e7os com estado compartilhado. A configura\u00e7\u00e3o foi extremamente simples: depois que configuramos todas as inst\u00e2ncias para que funcionassem com o mesmo ID de aplicativo (e com os mesmos servidores de inicializa\u00e7\u00e3o), praticamente todo o resto ocorreu automaticamente. Tamb\u00e9m especificamos que cada t\u00f3pico de origem consistiria em v\u00e1rias parti\u00e7\u00f5es, para que cada inst\u00e2ncia pudesse ser atribu\u00edda a um subconjunto dessas parti\u00e7\u00f5es.<\/p>\n

Tamb\u00e9m gostaria de mencionar que, aqui, \u00e9 comum fazer backup do armazenamento de estados, para que, por exemplo, em caso de recupera\u00e7\u00e3o de falhas, esse backup possa ser transferido para outra inst\u00e2ncia. Para cada armazenamento de estados no Kafka Streams, \u00e9 criado um t\u00f3pico replic\u00e1vel com um log de altera\u00e7\u00f5es (onde as atualiza\u00e7\u00f5es locais s\u00e3o rastreadas). Assim, o Kafka constantemente protege o armazenamento dos estados. Portanto, em caso de falha de alguma inst\u00e2ncia do Kafka Streams, o armazenamento de estados pode ser rapidamente restaurado em outra inst\u00e2ncia, para onde as parti\u00e7\u00f5es correspondentes ser\u00e3o transferidas. Nossos testes mostraram que isso \u00e9 feito em quest\u00e3o de segundos, mesmo que existam milh\u00f5es de registros no armazenamento.<\/p>\n

Ao passar de um microsservi\u00e7o com estado compartilhado para um cluster de microsservi\u00e7os, n\u00e3o \u00e9 trivial implementar a API Get State. Na nova situa\u00e7\u00e3o, o armazenamento de estados de cada microsservi\u00e7o cont\u00e9m apenas uma parte do todo (os objetos cujas chaves foram mapeadas para uma parti\u00e7\u00e3o espec\u00edfica). Precis\u00e1vamos determinar em qual inst\u00e2ncia estava o estado do objeto que precis\u00e1vamos, e fizemos isso com base nos metadados dos fluxos, conforme mostrado abaixo:<\/p>\n

\"N\u00e3o
\n
\nIlustra\u00e7\u00e3o 7: usando metadados de fluxos, determinamos de qual inst\u00e2ncia solicitar o estado do objeto desejado; essa abordagem foi aplicada com a GET ALL API.<\/i><\/p>\n

Principais Conclus\u00f5es<\/b><\/p>\n

Os armazenamentos de estados no Kafka Streams podem, de fato, servir como um banco de dados distribu\u00eddo. <\/p>\n