O gerenciamento de infraestruturas complexas em sistemas distribuídos como o Kafka requer mais do que intervenção manual; requer uma abordagem escalonável e automatizada.
De acordo com o Relatório de streaming de dados de 2023 da Confluent, 74% dos líderes de TI citam o uso inconsistente de métodos e padrões de integração como obstáculos e desafios para o avanço do streaming de dados.
À medida que as implantações crescem em tamanho e complexidade, acompanhar configurações, atualizações e dependências torna-se uma tarefa difícil para as equipes de plataforma. Ao mesmo tempo, identificar a propriedade, descobrir os recursos existentes e o compartilhamento de dados entre equipes tornam-se desafios para as equipes de desenvolvimento.
GitOps e Infraestrutura como Código (IaC) são práticas fundamentais no DevOps e nos espaços nativos da nuvem. Essas práticas podem ser aproveitadas no Kafka para trazer consistência, padronização e agilidade nos negócios.
No contexto de Kafka, GitOps está relacionado a:
A automação desses processos permite que os desenvolvedores implementem mudanças rápidas, introduzem práticas recomendadas de governança e aliviam a carga das equipes de plataforma responsáveis pelas operações do Kafka.
Inicialmente, ter um número limitado de projetos Kafka com escopos focados mantém as solicitações gerenciáveis para as equipes de operações e de plataforma. Essas equipes normalmente lidam com solicitações de recursos Kafka (por exemplo, criação de tópicos, configuração, modificação de partição, registro de esquema) e solicitações de acesso por meio de tickets do Jira e provisionamento manual de recursos.
No entanto, à medida que a adoção aumenta, o fluxo de solicitações aumenta, a complexidade da infraestrutura do Kafka aumenta e a equipe geralmente precisa crescer para apoiá-la. O método rapidamente se torna complicado e ineficiente. Mudanças ad hoc também aumentam o risco de erros humanos, inconsistências e configurações incorretas. Por exemplo, um simples erro de digitação em uma entrada da lista de controle de acesso (ACL) pode facilmente levar a falhas ou a consumidores não autorizados.
O processo manual carece de controle de versão, rastreabilidade e transparência.
Sem o GitOps, você corre o risco de ter uma grande confusão de nomes de tópicos, um número absurdo de partições e nenhuma estratégia uniforme para gerenciar configurações de corretor, produtor/consumidor e segurança.
Para dimensionar a adoção além de uma massa crítica de equipes, recursos e projetos, a automação é essencial. Caso contrário, como você espera gerenciar mais de 100 certificados Transport Layer Security (TLS), 3.500 esquemas Avro, 1.000 tópicos e 5.000 ACLs? A lista continua!
Tópicos, assuntos, configurações de conexão e configurações de segurança podem ser numerosos e variados. Se não for gerenciada adequadamente, a multiplicidade de configurações pode levar à degradação do desempenho e a problemas de confiabilidade.
O GitOps permite que as configurações do Kafka sejam armazenadas em repositórios como arquivos YAML ou JSON. O exemplo abaixo demonstra como fazer GitOps usando recursos do Conductor.
Armazenar configurações de recursos como código permite que alterações no estado desejado de sua infraestrutura Kafka sejam gerenciadas por meio de solicitações pull. Esta prática baseia-se em três princípios fundamentais: revisão, aprovação e trilhas de auditoria.
Isso resulta em uma abordagem mais transparente globalmente com artefatos autodocumentados e uma compreensão coletiva da configuração da infraestrutura Kafka. Isso incentiva a comunicação e o compartilhamento de conhecimento entre as equipes.
Mas de que adianta uma abordagem IaC sem controle sobre as configurações? Você deseja evitar um cenário de Velho Oeste, e é aí que entra em ação a aplicação automatizada de políticas em seu pipeline de CI/CD.
Como administrador da plataforma, você desejará restringir globalmente configurações caras do Kafka. Por exemplo:
Exemplo de representação de código de políticas de tópico Kafka em Condutor:
Qualquer variação de uma política de configuração de recursos pode ser armazenada como IaC, permitindo que seja orquestrada como verificações em fluxos de trabalho de CI/CD. Isso permite o provisionamento automatizado de recursos do Kafka sem comprometer os riscos associados às diversas configurações do Kafka.
Por definição, introduz uma camada de governança abrangente. O processo minimiza erros de implantação, reduz a intervenção manual e introduz uma estrutura segura para usar o Kafka em escala.
A utilização do IaC permite que as equipes da plataforma atribuam aos proprietários de domínio a responsabilidade pelo gerenciamento de suas configurações Kafka. Isso ajuda a remover algumas dependências das equipes da plataforma, que raramente têm o contexto de negócios relevante por trás de configurações específicas do Kafka.
“Você realmente precisa de tantas partições?” soa familiar? Ao capacitar os proprietários de domínios, as equipes da plataforma podem se concentrar em fornecer ferramentas, estruturas e fluxos de trabalho para apoiar a implementação de IaC.
Esta mudança de responsabilidades promove uma cultura de responsabilização e apropriação, que é fundamental para a expansão. Pergunte a si mesmo: quanto tempo você esperou pela criação do seu último tópico? Se a resposta for mais do que algumas horas, provavelmente você está enfrentando um gargalo.
A utilização de uma abordagem IaC levanta questões sobre como uma empresa deve operar. Qual você deve implementar?
A escolha certa depende de como a empresa está estruturada e do compromisso desejado entre agilidade e requisitos de governança.
Talvez a melhor solução seja considerar uma abordagem híbrida, em que as configurações menos críticas sejam gerenciadas pelas equipes e as mais críticas sejam gerenciadas centralmente para garantir consistência e conformidade.
No ecossistema Kafka, é necessário olhar além das configurações de recursos para entender onde existem desafios e complexidades adicionais. Os aplicativos de streaming estão diretamente conectados ao Kafka, e seu comportamento e configuração normalmente não são regidos pelos princípios do GitOps.
Você sabia que existem mais de 100 definições de configuração de cliente no Kafka? Sem o conhecimento do Kafka, muitos tendem a usar as configurações padrão de seu cliente Kafka. Isso não deveria ser um problema, certo? Talvez não no início, mas à medida que você escala, você precisa levar em consideração o impacto que esses padrões terão na sua rede, no disco, na qualidade do serviço e nos custos.
Se você não estiver familiarizado com as configurações do cliente Kafka como as seguintes, consulte o Kafka Options Explorer para obter uma lista completa.
|
acks=todos lote.tamanho=16384 permanecer.EM=0 buscar.min.bytes=1024 compressão.tipo=lz4 |
Embora alguns dos itens acima mostrem configurações padrão (por exemplo, batch.size e linger.ms), usar um tipo de compactação não é uma configuração padrão do cliente Kafka. No entanto, pode ser usado para melhorar o desempenho, reduzir a carga da rede e economizar nos custos de armazenamento. Da mesma forma, usando um acks valor de all não é o padrão, mas é recomendado nos casos em que são necessárias confiabilidade e durabilidade máximas.
Em última análise, as configurações do cliente Kafka são um campo minado e é uma grande demanda para os desenvolvedores estarem atentos às complexidades e consequências de cada configuração. No entanto, o impacto de uma configuração mal informada pode ter um impacto grave em toda a sua plataforma Kafka e nas aplicações subjacentes.
Com um pouco de automação, é possível evitar erros nas configurações do cliente.
Esta é uma política sobre configurações de cliente a ser aplicada usando:
compression formato para conservar o armazenamento e reduzir a largura de banda da rede.acks (agradecimentos) é igual -1 para o mais alto nível de durabilidade e confiabilidade.Essas políticas permitem que as equipes operem de forma autônoma, mas mantenham o controle abrangente sobre as configurações de produtor/consumidor Kafka em nível global.
Conforme destacado anteriormente, os aplicativos estão diretamente conectados ao Kafka e suas configurações normalmente não são governadas pelo GitOps. Uma maneira de resolver esse problema arquitetonicamente é por meio de um proxy Kafka.
O proxy atua como intermediário para lidar com solicitações Kafka antes de encaminhá-las para o corretor Kafka. Isso pode incluir a avaliação da solicitação em relação às políticas de configuração do cliente e até mesmo a manipulação da solicitação (por exemplo, criptografia em nível de campo) antes de enviá-la ao intermediário.
A abordagem de proxy centraliza a validação da configuração, o que traz consistência e conformidade entre os clientes sem a necessidade de alterar cada aplicativo cliente. Isso reduz o risco de um cliente mal informado causar problemas para outros e a sobrecarga de manutenção para manter as bibliotecas do cliente atualizadas.
À medida que a adoção do Kafka aumenta, novos aplicativos trarão novos requisitos, equipes e complexidades. A utilização de uma abordagem GitOps para gerenciar recursos, configurações e regras do cliente Kafka coloca ênfase na automação, rastreabilidade e colaboração em seu desenvolvimento Kafka.
Se você está ampliando a adoção do Kafka e precisa de uma estrutura que traga consistência, padronização e agilidade de negócios, entre em contato e agende uma demonstração do Conductor.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
