Perguntas frequentes sobre o Amazon Managed Streaming for Apache Kafka

Basta seguir o guia de introdução do Amazon MSK para configurar, produzir e consumir um cluster a partir dele. Em resumo, é possível criar seu primeiro cluster em algumas etapas no Console de Gerenciamento da AWS ou com o uso dos AWS SDKs. Primeiro, no console do Amazon MSK, selecione uma região da AWS na qual o cluster do Amazon MSK será criado. Escolha um nome para seu cluster, a nuvem privada virtual (VPC) com a qual você deseja executar o cluster, e as sub-redes para cada zona de disponibilidade. Se você estiver criando um cluster provisionado, também será possível escolher um tipo de instância de agente e o número de agentes por zona de disponibilidade.

Os clusters provisionados contêm instâncias intermediárias e nós de metadados abstraídos. Os clusters sem servidores são um recurso em si mesmos que abstraem todos os recursos subjacentes.

No Apache Kafka, os agentes são os servidores individuais que compõem o cluster Apache Kafka. Eles são responsáveis por armazenar e replicar os dados publicados nos tópicos do Kafka, gerenciar as partições dentro desses tópicos, lidar com as solicitações do cliente (produzir e consumir mensagens) e fazer a coordenação mútua para manter o estado geral da implantação do Kafka. Os corretores são os principais componentes que possibilitam a arquitetura distribuída, escalável e tolerante a falhas do Kafka.

Para clusters provisionados, é possível escolher as instâncias EC2 T3.small ou instâncias dentro das famílias de instâncias M7g e M5 do EC2. Para clusters com tecnologia sem servidor, os agentes são abstraídos de forma completa. A MSK também oferece os tipos de agente Standard e Express.

Não, cada agente que você provisiona inclui o volume de armazenamento de inicialização gerenciado pelo serviço Amazon MSK.

Alguns recursos, como interfaces de rede elástica (ENIs), serão exibidos na sua conta do Amazon EC2. Outros recursos do Amazon MSK não serão exibidos na sua conta do Amazon EC2, pois são gerenciados pelo serviço Amazon MSK.

Para clusters provisionados, é necessário provisionar as instâncias do agente em cada cluster criado. Nos agentes Standard, o armazenamento será provisionado e, opcionalmente, o throughput de armazenamento provisionado será habilitado para volumes de armazenamento, que podem ser usados para escalar a E/S sem precisar provisionar agentes adicionais. Com os agentes Express, não é preciso provisionar ou gerenciar o armazenamento. Para todos os tipos de cluster, não é preciso provisionar nós de metadados, como os nós Apache ZooKeeper ou KRaft, pois esses recursos são incluídos sem custo adicional em cada cluster criado. Para clusters sem servidor, o cluster é criado apenas como um recurso.

O Amazon MSK usa a replicação líder-seguidor do Apache Kafka para replicar dados entre os agentes. O Amazon MSK facilita a implantação de clusters com replicação Multi-AZ. Com os agentes Standard, existe a opção de usar uma estratégia de replicação personalizada por tópico. Os agentes Express garantem mais disponibilidade sempre replicando os dados em três zonas de disponibilidade. Os agentes líderes e seguidores serão implantados e isolados com o uso do tipo de agente e a estratégia de replicação especificados. Por exemplo, se os agentes Standard forem selecionados com a estratégia de replicação de três agentes da zona de disponibilidade e com um agente por cluster da zona de disponibilidade, o Amazon MSK criará um cluster de três agentes (um agente em três zonas de disponibilidade de uma região) e, por padrão (a menos que você escolha substituir o fator de replicação do tópico), o fator de replicação do tópico também será três. Para saber mais sobre o que acontece durante o failover do cliente, consulte nossa documentação de failover do cliente.

Sim, o Amazon MSK permite criar configurações personalizadas e aplicá-las a clusters novos e existentes. Os agentes Express protegem a maior parte das configurações contra valores abaixo do ideal que podem afetar a disponibilidade e a durabilidade. Os agentes Express também oferecem uma experiência mais simples ao abstrair as configurações relacionadas ao armazenamento, já que o Amazon MSK gerencia totalmente a camada de armazenamento. Para obter mais informações sobre as configurações personalizadas, consulte a documentação da configuração.

Depois que seu cluster do Apache Kafka for criado, você poderá criar tópicos usando as APIs do Apache Kafka. Todas as ações e configurações de nível de partição e tópico são executadas com o uso de APIs do Apache Kafka. O seguinte comando é um exemplo de criação de um tópico usando APIs do Apache Kafka e os detalhes de configuração disponíveis para seu cluster:

<path-to-your-kafka-installation>/bin/kafka-topics.sh --create — bootstrap-server <BootstrapBrokerString> --replication-factor 3 --partitions 1 -- topic TopicName

O Amazon MSK oferece duas opções de implantação para clusters do Apache Kafka: Amazon MSK Provisioned e Amazon MSK Serverless. O MSK Provisioned oferece vários níveis de controle sobre seu cluster, ao mesmo tempo em que remove a maior parte da sobrecarga operacional decorrente do gerenciamento de clusters do Apache Kafka. Com o MSK Provisioned, você pode escalar o cluster em unidades de agentes. É possível escolher entre vários tipos de agentes, inclusive os agentes Standard e Express. Por outro lado, o MSK Serverless é um tipo de cluster que abstrai totalmente a escalabilidade e o gerenciamento de clusters. Com o MSK Serverless, é possível executar aplicações sem a necessidade de provisionar, configurar e otimizar clusters, e você paga pelo volume de dados que transmite e retém. O Amazon MSK também oferece várias opções para simplificar a conexão com seus clusters MSK. Essas opções incluem o Amazon MSK Connect, o Replicador do Amazon MSK e outras integrações nativas da AWS. Consulte as seções subsequentes para obter mais detalhes. 

O MSK Provisioned é uma opção de implantação de cluster MSK que permite configurar e escalar manualmente os clusters Apache Kafka. Assim, essa opção fornece níveis variados de controle sobre a infraestrutura que alimenta o ambiente Apache Kafka.

Com o MSK Provisioned, é possível escolher os tipos de instância, os volumes de armazenamento no tipo de agente padrão e o número de nós do agente que compõem os clusters Kafka. Também é possível escalar o cluster ao adicionar ou remover agentes conforme as necessidades de processamento de dados evoluam. Essa flexibilidade permite otimizar os clusters para suas necessidades específicas de workload, seja maximizando o throughput, a capacidade de retenção ou outras características de desempenho.

Além das opções de configuração da infraestrutura, o MSK Provisioned oferece segurança, monitoramento e benefícios operacionais de nível empresarial. Isso inclui atributos como atualizações da versão do Apache Kafka, segurança integrada por meio de criptografia e controle de acesso e integração com outros serviços da AWS para monitoramento, como o Amazon CloudWatch. O MSK Provisioned oferece dois tipos principais de agentes: Standard e Express.

Os agentes Standard oferecem máxima flexibilidade para configuração dos clusters, enquanto os agentes Express oferecem mais elasticidade, throughput, resiliência e facilidade de uso para execução de aplicações de streaming de alto desempenho. Consulte as subseções abaixo para obter mais detalhes sobre cada oferta. A tabela abaixo também destaca as principais comparações de atributos entre os agentes Standard e Express.

Sim, o Amazon MSK oferece suporte a instâncias AWS Graviton3 baseadas em instâncias M7g de tamanhos .large a .16xlarge para executar todas as workloads do Apache Kafka. As instâncias do Graviton vêm com os mesmos benefícios de disponibilidade e durabilidade do Amazon MSK, com custos até 24% mais baixos em comparação com as instâncias M5 correspondentes. As instâncias do Graviton oferecem um throughput por instância até 29% maior em comparação com as instâncias M5 do Amazon MSK, o que permite que os clientes executem clusters do MSK com menos agentes ou instâncias menores.

Os agentes Standard do MSK Provisioned oferecem a maior flexibilidade de configuração da performance do cluster. É possível escolher entre uma ampla variedade de configurações de cluster para obter as características de disponibilidade, durabilidade, throughput e latência necessárias para suas aplicações. Também é possível provisionar a capacidade de armazenamento e aumentá-la conforme e quando necessário. O Amazon MSK lida com a manutenção de hardware dos agentes Standard e dos recursos de armazenamento conectados para reparar automaticamente os problemas de hardware que possam surgir.

Os agentes Express para MSK Provisioned simplificam o gerenciamento do Apache Kafka, além de torná-lo mais econômico para uma execução em escala e mais elástico, com a baixa latência que você espera. Os agentes incluem armazenamento pré-pago que escala automaticamente e não exige dimensionamento, provisionamento ou monitoramento proativo. Dependendo do tamanho da instância selecionada, cada nó do agente pode fornecer até 3 vezes mais throughput por agente, aumentar a escala verticalmente até 20 vezes mais rápido e se recuperar 90% mais rápido em comparação com os agentes Apache Kafka padrão. Os agentes Express vêm pré-configurados com os padrões de melhores práticas Amazon MSK e impõem cotas de throughput do cliente para minimizar a disputa de recursos entre os clientes e as operações em segundo plano da Kafka.

• Não há necessidade de gerenciamento de armazenamento: os agentes Express eliminam a necessidade de provisionar ou gerenciar quaisquer recursos de armazenamento. Você obtém um armazenamento elástico, virtualmente ilimitado, pago conforme o uso e totalmente gerenciado. Para casos de uso com alto throughput, não é preciso considerar as interações entre instâncias de computação e volumes de armazenamento, bem como os gargalos de throughput associados. Esses recursos simplificam o gerenciamento de clusters e eliminam a sobrecarga operacional do gerenciamento de armazenamento.
• Escalabilidade mais rápida: os agentes Express permitem escalar o cluster e mover partições mais rapidamente do que nos agentes Standard. Esse recurso é fundamental quando é preciso aumentar a escala horizontalmente do cluster para lidar com futuros picos de carga ou reduzir a escala horizontalmente do cluster para reduzir custos. Consulte as seções sobre como expandir o cluster, remover agentes, reatribuir partições e configurar o Cruise Control do LinkedIn para rebalanceamento e obtenha mais detalhes sobre a maneira de escalar o cluster.
• Mais produtividade: os agentes Express oferecem até 3 vezes mais throughput por agente do que as agentes Standard. Por exemplo, é possível gravar dados com segurança em até 500 MBps com cada agente Express de tamanho m7g.16xlarge em comparação com 153,8 MBps no agente Standard equivalente (ambos os números pressupõem alocação de largura de banda suficiente para operações em segundo plano, como replicação e rebalanceamento).
• Configuração para alta resiliência: os agentes Express oferecem automaticamente várias práticas recomendadas pré-configuradas para melhorar a resiliência do cluster. Isso inclui barreiras de proteção em configurações críticas do Apache Kafka, cotas de throughput e reserva de capacidade para operações em segundo plano e reparos não planejados. Esses recursos tornam mais seguro e fácil executar aplicações Apache Kafka em grande escala. Consulte as seções sobre configurações do agente Express e a cota do agente Amazon MSK Express para obter mais detalhes.
• Não há necessidade de usar janelas de manutenção: não há janelas de manutenção para agentes Express. O Amazon MSK atualiza automaticamente o hardware do cluster de forma contínua. Consulte os agentes Amazon MSK Express para obter mais detalhes.

Os agentes Express fornecem mais throughput por agente, de forma que seja possível criar clusters com menos agentes para a mesma workload. Além disso, quando o cluster estiver em funcionamento, será possível monitorar o uso dos recursos de cluster e dimensionar a capacidade correta mais rapidamente do que com os agentes Standard. Portanto, é possível provisionar os recursos adequados para a capacidade necessária, escalar mais rapidamente e atender a quaisquer mudanças na demanda.

Os clusters com agentes Express funcionam com APIs e ferramentas do Apache Kafka que usam o cliente Apache Kafka padrão.

Os agentes Express vêm pré-configurados com os padrões de melhores práticas do Amazon MSK que otimizam a disponibilidade e a durabilidade. É possível personalizar algumas dessas configurações para ajustar ainda mais o desempenho de seus clusters. Leia mais detalhes sobre as configurações do agente Express no guia do desenvolvedor Amazon MSK.

Assim como para os agentes Standard, o Amazon MSK se integra ao AWS Key Management Service (AWS KMS) para oferecer criptografia transparente do lado do servidor ao armazenamento em agentes Express. Ao criar um cluster MSK com agentes Express, é possível especificar a chave do AWS KMS com a qual será usada pelo Amazon MSK para criptografar os dados em repouso. Se uma chave KMS não for especificada, o Amazon MSK criará uma chave gerenciada pela AWS que poderá ser usada em seu nome. O Amazon MSK também usa TLS para criptografar dados em trânsito para agentes Express, assim como faz com agentes Standard.

A maioria dos atributos e capacidades provisionados pelo MSK que funcionam em agentes Standard também funcionam com clusters que usam agentes Express. Algumas diferenças incluem: gerenciamento de armazenamento, disponibilidade do tipo de instância e versões compatíveis. A tabela que compara os agentes Standard e Express em MSK Provisioned destaca algumas semelhanças e diferenças importantes.

Sim, é possível migrar os dados do cluster Kafka para um cluster composto por agentes Express com o uso do MirrorMaker 2 ou Replicador do Amazon MSK que copia os dados e os metadados de seu cluster para um novo cluster. É possível saber mais detalhes sobre o uso do MirrorMaker 2 e MSK Replicator no guia do desenvolvedor Amazon MSK.

Os agentes Express aumentam a relação preço/desempenho, oferecem mais resiliência e menos sobrecarga operacional, sendo a escolha ideal para todas as workloads do Apache Kafka no MSK Provisioned. No entanto, é possível escolher os tipos de agentes Standard se quiser controlar mais as definições e as configurações de seus agentes. Com os agentes Standard, é possível personalizar um conjunto mais amplo de configurações do Kafka, inclusive com fator de replicação, tamanho de arquivos de log e políticas de eleição de líderes, o que oferece mais flexibilidade nas configurações do cluster.

MSK Serverless é um tipo de cluster do Amazon MSK que torna mais fácil a execução dos clusters do Apache Kafka sem a necessidade de gerenciar a capacidade de computacional e de armazenamento. Com o MSK Serverless, é possível executar aplicações sem a necessidade de provisionar, configurar e otimizar clusters, e você paga pelo volume de dados que transmite e retém. 

Sim, o MSK Serverless gerencia totalmente as partições, inclusive o monitoramento e a movimentação, para que sejam balanceadas até mesmo por meio de um cluster.

O MSK Serverless fornece até 200 MBps de capacidade de gravação e 400 MBps de capacidade de leitura por cluster. Além disso, para garantir disponibilidade de taxa de transferência suficiente para todas as partições em um cluster, o MSK Serverless aloca até 5 MBps de capacidade de gravação instantânea e 10 MBps de capacidade de leitura instantânea por partição. 

O MSK Serverless criptografa todo o tráfego em trânsito e todos os dados em repouso utilizando chaves gerenciadas por serviço emitidas por meio do AWS KMS. Os clientes se conectam ao MSK Serverless através de uma conexão privada usando AWS PrivateLink sem expor seu tráfego à internet pública. Além disso, o MSK Serverless oferece o controle de acesso do AWS Identity and Access Management (IAM), sendo possível gerenciar a autenticação do cliente e sua autorização para recursos Apache Kafka, tais como tópicos.

Quando um cluster é criado no MSK Serverless, as sub-redes de uma ou mais Amazon Virtual Private Clouds (Amazon VPCs) são fornecidas para que os clientes do cluster sejam hospedados. Os clientes hospedados em qualquer uma dessas VPCs poderão se conectar ao cluster do MSK Serverless com o uso de sua string de agentes de bootstrap.

Consulte a página de definição de preços do MSK para obter informações atualizadas sobre disponibilidade regional.

Atualmente, o MSK Serverless oferece suporte ao IAM (Identity Access Management) para autenticação e autorização do cliente. Os clientes podem assumir um perfil do IAM para autenticação e é possível reforçar o controle de acesso com o uso de uma política do IAM associada.

É possível usar quaisquer ferramentas compatíveis com o Apache Kafka para processar dados em seus tópicos de clusters do MSK Serverless. O MSK Serverless se integra com o Amazon Managed Service for Apache Flink para processamento de transmissões com estado e o AWS Lambda para processamento de eventos. Também é possível usar os conectores do coletor Apache Kafka Connect para enviar dados para qualquer destino desejado. 

Quando uma partição é criada, o MSK Serverless cria duas réplicas da partição e as coloca em diferentes zonas de disponibilidade. Além disso, o MSK Serverless detecta e recupera automaticamente recursos de backend que falharam em manter a alta disponibilidade.

Sim, é possível usar ferramentas de terceiros ou de código aberto, como o MirrorMaker2, compatível com o Apache Kafka, para replicar dados de clusters em um cluster do MSK. Confira este laboratório de migração do Amazon MSK para obter ajuda no planejamento da sua migração.

Sim, o Amazon MSK é compatível com as atualizações de versões Apache Kafka totalmente gerenciadas no local para clusters provisionados. Para saber mais detalhes sobre a atualização de versão do Apache Kafka e as práticas recomendadas de alta disponibilidade, consulte a documentação de atualizações de versão.

Todas as versões do Apache Kafka são compatíveis até atingirem a data de fim do suporte. Para obter mais detalhes sobre a política e as datas de fim do suporte, consulte nossa documentação de suporte para a versão.

Sim, o Amazon MSK sempre é executado em uma Amazon VPC gerenciado pelo serviço Amazon MSK. Os recursos do Amazon MSK estarão disponíveis para a sua própria Amazon VPC, sub-rede e grupo de segurança selecionados quando o cluster for configurado. Os endereços IP da sua VPC são anexados aos recursos do Amazon MSK por meio de interfaces de rede elásticas (ENIs), e todo o tráfego de rede permanece dentro da rede da AWS, não estando acessível à Internet por padrão.

Os agentes em seu cluster serão disponibilizados para clientes em seu VPC por meio de ENIs que aparecem em sua conta. Os grupos de segurança nas ENIs ditarão a origem e o tipo de tráfego de entrada e saída permitido em seus agentes.

Sim, o Amazon MSK oferece uma opção para se conectar com segurança aos agentes de clusters do Amazon MSK que executam o Apache Kafka 2.6.0 ou versões posteriores pela Internet. Ao habilitar o acesso público, clientes autorizados e externos a uma Amazon VPC privada podem transmitir dados criptografados para dentro e para fora de clusters específicos do Amazon MSK. Você pode habilitar o acesso público para clusters MSK após a criação de um cluster sem custo adicional, mas os custos padrão de transferência de dados da AWS para entrada e saída do cluster são aplicáveis. Para saber mais detalhes sobre a maneira de ativar o acesso público, consulte a documentação de acesso público.

Por padrão, a única maneira pela qual os dados podem ser produzidos e consumidos por meio de um cluster do Amazon MSK é mediante uma conexão privada entre seus clientes na sua VPC e o cluster do Amazon MSK. No entanto, se o acesso público ao cluster do MSK for ativado e se a conexão com o cluster MSK for feita com o uso da string pública de agentes de bootstrap, a conexão, embora autenticada, autorizada e criptografada, não será mais considerada privada. Recomendamos que você configure os grupos de segurança do cluster para ter regras TCP de entrada que permitam o acesso público a partir do seu endereço IP confiável e torne essas regras o mais restritivas possível se você ativar o acesso público.

É possível se conectar ao cluster do MSK por meio de qualquer conta VPC ou AWS diferente de seu cluster do MSK da Amazon VPC ao ativar a conectividade privada de várias VPCs para clusters do MSK que executam as versões 2.7.1. ou posteriores. Somente é possível ativar a conectividade privada após a criação do cluster para qualquer um dos esquemas de autenticação compatíveis (autenticação IAM, SASL/SCRAM e autenticação mTLS). É preciso configurar os clientes para que se conectem de forma privada ao cluster com o uso de conexões VPC gerenciadas pelo Amazon MSK que usam a tecnologia PrivateLink para permitir a conectividade privada. Para saber mais detalhes sobre a maneira de configurar a conectividade privada, consulte acesso por meio da documentação da AWS.

Sim, o Amazon MSK utiliza a criptografia do lado do servidor do Amazon Elastic Block Store (Amazon EBS) e as chaves do AWS KMS para criptografar volumes de armazenamento.

Sim. Por padrão, os novos clusters têm a criptografia em trânsito habilitada por meio de TLS para comunicação entre agentes. Para clusters provisionados, é possível desabilitar o uso da criptografia em trânsito quando um cluster for criado.

Sim. Por padrão, a criptografia em trânsito é definida como somente TLS para clusters criados pela AWS CLI ou pelo Console de Gerenciamento da AWS. A configuração adicional é necessária para que os clientes se comuniquem com clusters usando a criptografia de TLS. Para clusters provisionados, é possível alterar a configuração de criptografia padrão selecionando as configurações de TLS/texto simples ou de texto simples. Leia mais sobre a criptografia Amazon MSK.

Sim, os clusters MSK oferecem suporte à criptografia TLS em trânsito entre agentes Kafka e nós de metadados.

Para clusters sem servidor, é possível usar o IAM Access Control na autenticação e na autorização. Para clusters provisionados, existem as seguintes opções:

• IAM Access Control para Authn/Authz (recomendado)
• Autenticação por certificado TLS para AuthN e listas de controle de acesso para AuthZ
• SASL/SCRAM para AuthN e listas de controle de acesso para AuthZ

O Amazon MSK recomenda o uso do IAM Access Control. É o mais fácil de usar e, como o padrão é o acesso com privilégio mínimo, a opção mais segura.

Se estiver usando o IAM Access Control, o Amazon MSK usará as políticas gravadas e seu próprio autorizador para autorizar as ações. Se você estiver usando autenticação de certificado TLS ou o SASL/SCRAM, o Apache Kafka usará listas de controle de acesso (ACLs) para autorização. Para habilitar as ACLs, é necessário habilitar a autenticação de clientes com o uso de certificados TLS ou SASL/SCRAM.

Se estiver usando o IAM Access Control, o Amazon MSK autenticará e autorizará para você sem qualquer configuração adicional. Se a autenticação TLS estiver sendo usada, será possível utilizar o Dname de certificados TLS de clientes como entidade principal da ACL para autorizar as solicitações de clientes. Se você usa SASL/SCRAM, poderá utilizar o nome de usuário como principal da ACL para autorizar solicitações de clientes.

Você pode controlar as ações da API de serviço com o uso do IAM.

Sim, é possível habilitar o IAM Access Control para um cluster existente do Console de Gerenciamento da AWS ou com o uso da API UpdateSecurity.

Não, o IAM Access Control está disponível apenas para clusters do MSK.

Você pode anexar uma política de cluster ao seu cluster Amazon MSK para fornecer permissões de cliente Kafka entre contas e configurar a conectividade privada com seu cluster Amazon MSK. Ao usar a autenticação do cliente IAM, você também pode usar a política de cluster para a definição granular as permissões do plano de dados Kafka para o cliente conectado. Para obter mais detalhes sobre políticas de cluster, consulte a documentação da política de cluster.

É possível monitorar a performance de clusters com o uso do console do Amazon MSK, do console do Amazon CloudWatch ou por meio das métricas de JMX e host, usando o Open Monitoring com Prometheus, que é uma solução de monitoramento de código aberto.

O custo para monitorar um cluster com o uso do CloudWatch depende do nível de monitoramento e do tamanho do cluster do Apache Kafka. O CloudWatch cobra por métrica, mensalmente, e inclui um nível gratuito da AWS. Consulte a definição de preço do Amazon CloudWatch para obter mais informações. Para obter mais detalhes sobre o número de métricas expostas em cada nível de monitoramento, consulte a documentação de monitoramento do Amazon MSK.

Ferramentas projetadas para ler exportadores do Prometheus são compatíveis com o Open Monitoring, tais como: Datadog, Lenses, New Relic, Sumo Logic ou um servidor do Prometheus. Para obter detalhes sobre o Open Monitoring, consulte a documentação do Amazon MSK Open Monitoring.

Você pode usar qualquer monitoramento do lado do cliente compatível com a versão do Apache Kafka que está usando. 

Sim, é possível marcar clusters do Amazon MSK pela AWS CLI ou pelo Console de Gerenciamento da AWS.

As métricas de atraso do consumidor no nível do tópico estão disponíveis como parte do conjunto padrão de métricas que o Amazon MSK publica no CloudWatch para todos os clusters. Nenhuma configuração adicional é necessária para obter essas métricas.

As métricas de nível de tópico estão incluídas no conjunto padrão de métricas do Amazon MSK, que é gratuito. As métricas de nível de partição são cobradas de acordo com a definição de preço do Amazon CloudWatch.

É possível habilitar a entrega de log de agentes para clusters provisionados. É possível entregar logs de agentes para o Amazon CloudWatch Logs, Amazon Simple Storage Service (Amazon S3) e Amazon Data Firehose. O Firehose oferece suporte ao Amazon OpenSearch Service, entre outros destinos. Para saber como habilitar esse atributo, consulte a documentação sobre registro em log do Amazon MSK. Para conhecer a definição de preço, consulte as páginas de definição de preço do Amazon CloudWatch Logs e do Amazon Data Firehose.

O Amazon MSK fornece logs no nível INFO para todos os agentes em um cluster provisionado.

Sim, se o IAM Access Control for adotado, o uso de APIs de recursos do Apache Kafka será registrado no AWS CloudTrail.

Conforme o site https://zookeeper.apache.org: “o Apache ZooKeeper é um serviço centralizado que permite manter informações de configuração, realizar nomeações, fornecer sincronização distribuída e fornecer serviços de grupo. Todos esses tipos de serviços são usados de uma forma ou de outra por aplicações distribuídas,” incluindo o Apache Kafka.

Sim, o Amazon MSK usa o Apache ZooKeeper para gerenciar metadados. Além disso, a partir do Apache Kafka versão 3.7, é possível criar clusters no modo ZooKeeper ou no modo KRaft. Um cluster criado com o modo KRaft usa controladores KRaft para gerenciamento de metadados em vez dos nós do ZooKeeper.

O Apache KRaft é o protocolo de consenso que muda o gerenciamento de metadados em clusters Kafka de nós externos do Apache ZooKeeper para um grupo de controladores dentro do Kafka. Essa alteração permite que os metadados sejam armazenados e replicados como tópicos nos agentes do Kafka, resultando em uma propagação mais rápida dos metadados. Para saber mais detalhes, consulte nossa documentação do Apache KRaft.

Não é necessário fazer alterações na API para usar o modo KRaft no Amazon MSK. No entanto, se seus clientes ainda usarem a string de conexão --zookeeper, será necessário informá-los que a string de conexão --bootstrap-server deve ser usada para realizar a conexão com o cluster, bem como ações administrativas. O sinalizador --zookeeper foi descontinuado na versão 2.5 do Apache Kafka e foi removido a partir do Kafka 3.0. Portanto, recomendamos usar as versões recentes do cliente Apache Kafka e a string de conexão --bootstrap-server.

É preciso verificar se quaisquer ferramentas usadas são capazes de utilizar as APIs do Kafka Admin sem conexões com o ZooKeeper. Consulte nossa documentação atualizada sobre o uso do Cruise Control para clusters do modo KRaft. O Cruise Control também publicou as etapas a seguir para executar o Kafka sem uma conexão com o ZooKeeper.

O número de partições por agente é o mesmo nos clusters baseados em KRaft e ZooKeeper. No entanto, o KRaft permite que você hospede mais partições por cluster provisionando mais corretores em um cluster.

O AWS MSK se integra com os seguintes serviços da AWS:

• Amazon S3 com uso do Firehose, para fornecer dados ao Amazon S3 por meio do Amazon MSK sem uso de código
• Amazon VPC para isolamento e segurança de rede
• Amazon CloudWatch para métricas
• Amazon KMS para criptografia de volume de armazenamento
• IAM para autenticação e autorização do Apache Kafka e APIs
• AWS Lambda para fonte de eventos do Amazon MSK
• AWS IoT Core para fonte de eventos de IoT
• AWS Glue Schema Registry para controlar a evolução dos esquemas usados pelas aplicações do Apache Kafka
• AWS CloudTrail para logs de APIs da AWS
• AWS Certificate Manager para CAs privadas usadas na autenticação TLS de clientes
• AWS CloudFormation para descrever e provisionar clusters do Amazon MSK com o uso de código
• Amazon Managed Service for Apache Flink para aplicações do Apache Flink totalmente gerenciadas que processam dados de streaming
• Amazon Managed Service for Apache Flink Studio para streaming interativo de SQL no Apache Kafka
• AWS Secrets Manager para credenciais de clientes usadas na autenticação SASL/SCRAM

O Amazon MSK Serverless integra-se com os seguintes serviços da AWS:

• Amazon S3 com uso do Firehose para entregar dados do MSK ao Amazon S3 sem uso de código
• Amazon VPC para isolamento e segurança de rede
• Amazon CloudWatch para métricas
• IAM para autenticação e autorização do Apache Kafka e APIs
• AWS Glue Schema Registry para controlar a evolução dos esquemas usados pelas aplicações do Apache Kafka
• AWS CloudTrail para logs de APIs da AWS
• AWS PrivateLink para conectividade privada

O Replicador do Amazon MSK é um atributo do Amazon MSK que ajuda os clientes a replicarem dados de forma confiável em clusters do MSK em diferentes regiões da AWS (replicação entre regiões) ou dentro da mesma região da AWS (replicação na mesma região) sem escrever código ou gerenciar a infraestrutura. É possível usar a replicação entre regiões para criar aplicações de streaming multirregional altamente disponíveis e tolerantes a falhas para aumentar a resiliência. Você também pode usar a replicação entre regiões para fornecer acesso de baixa latência a consumidores em diferentes regiões geográficas. É possível usar a replicação na mesma região para distribuir dados de um cluster para vários clusters a fim de compartilhar dados com seus parceiros e equipes. Também é possível usar a replicação na mesma região para agregar dados de vários clusters em um para analytics.

Para configurar a replicação entre um par de clusters MSK de origem e destino, é preciso criar um replicador na região de destino. Para criar um replicador, especifique os detalhes que incluam o nome do recurso da Amazon (ARN) dos clusters MSK de origem e destino e um perfil do IAM com o qual o MSK Replicator poderá ser usado no acesso aos clusters. Você precisará criar o cluster MSK de destino, caso ele ainda não exista.

O MSK Replicator oferece suporte à replicação somente em clusters MSK. Há suporte para clusters MSK do tipo provisionado e sem servidor. Também é possível usar o MSK Replicator para migrar de provisionado para sem servidor ou vice-versa com outros clusters Kafka que não são compatíveis.

Sim, você pode especificar quais tópicos deseja replicar usando listas de permissão e negação ao criar o Replicador. 

Sim, o MSK Replicator replica automaticamente os metadados necessários do Kafka, como configuração de tópicos, ACLs e compensações de grupos de consumidores para que as aplicações consumidoras possam retomar o processamento sem problemas após o failover. Você pode optar por desativar uma ou mais dessas configurações se quiser apenas replicar os dados. Você também pode especificar quais grupos de consumidores deseja replicar usando listas de permissão ou negação ao criar o Replicador.

Não, o MSK Replicator implanta, provisiona e escala automaticamente a infraestrutura de replicação subjacente para oferecer suporte às mudanças em seu throughput de entrada.

Não, o MSK Replicator só oferece suporte à replicação entre clusters MSK na mesma conta da AWS.

É possível usar o Amazon CloudWatch na região de destino a fim de visualizar métricas para ReplicationLatency,
MessageLag e ReplicatorThroughput em um tópico e nível agregado em cada replicador, sem custo adicional. As métricas seriam visíveis em ReplicatorName no namespace “AWS/Kafka”. Também é possível ver as métricas “ReplicatorFailure, AuthError e ThrottleTime” para verificar se o replicador está tendo algum problema.

É possível usar o MSK Replicator para configurar topologias de cluster ativo-ativo ou ativo-passivo de forma a aumentar a resiliência da sua aplicação Kafka em todas as regiões. Em uma configuração ativa-ativa, os dois clusters MSK estão servindo ativamente leituras e gravações. Comparativamente, em uma configuração ativa-passiva, apenas um cluster MSK por vez está servindo ativamente dados de streaming, enquanto o outro cluster está em espera.

Sim. Ao criar um replicador diferente em cada par de clusters de origem e destino, é possível replicar dados de um cluster para vários clusters ou replicar dados de vários clusters para um.

O MSK Replicator usa o IAM Access Control para se conectar aos clusters de origem e de destino. É preciso ativar seus clusters MSK de origem e destino para que o IAM Access Control crie um replicador. Você pode continuar usando outros métodos de autenticação, incluindo SASL/SCRAM e mTLS, ao mesmo tempo para seus clientes, já que o Amazon MSK oferece suporte a vários métodos de autenticação simultaneamente.

O MSK Replicator replica os dados de forma assíncrona. A latência de replicação varia de acordo com muitos fatores, inclusive com a distância de rede entre as regiões de seus clusters MSK, a capacidade de throughput dos clusters de origem e de destino e o número de partições em seus clusters de origem e destino.

Não, o MSK Replicator cria novos tópicos no cluster de destino com um prefixo gerado automaticamente adicionado ao nome do tópico. Por exemplo, o MSK Replicator replicará dados em “tópico” do cluster de origem para um novo tópico no cluster de destino chamado “<sourceKafkaClusterAlias>.topic”. O MSK Replicator faz isso para distinguir tópicos que contêm dados replicados do cluster de origem de outros tópicos no cluster de destino e evitar que os dados sejam replicados circularmente entre os clusters. É possível encontrar o prefixo que será adicionado aos nomes dos tópicos no cluster de destino no campo “sourceKafkaClusterAlias” com o uso da API DescribeReplicator ou a página de detalhes do Replicator no console do Amazon MSK.

Sim. Por padrão, quando você cria um replicador, ele começa a replicar dados da ponta do fluxo (último deslocamento) no cluster de origem. Como alternativa, se quiser replicar dados existentes, você pode configurar um novo replicador para começar a replicar dados do primeiro deslocamento nas partições de tópicos do cluster de origem.

Como o MSK Replicator atua como consumidor do seu cluster de origem, é possível que a replicação faça com que outros consumidores sejam limitados ao seu cluster de origem. Isso depende da capacidade de leitura que você tem no cluster de origem e do throughput dos dados que você está replicando. Recomendamos provisionar a capacidade idêntica para seus clusters de origem e de destino e contabilizar o throughput de replicação enquanto a capacidade necessária é calculada. Você também pode definir cotas do Kafka para o replicador em seus clusters de origem e destino para controlar a capacidade que o replicador pode usar.

Sim, é possível especificar a escolha de codec de compressão ao criar o Replicator entre None, GZIP, Snappy, LZ4 e ZSTD.

Sim, é possível especificar a escolha de codec de compressão ao criar o Replicator entre None, GZIP, Snappy, LZ4 e ZSTD.

É possível aumentar a escala verticalmente de seu cluster provisionado com o uso do Console de Gerenciamento da AWS ou a AWS CLI. Também é possível criar uma política de ajuste de escala automático para armazenamento com o uso do Console de Gerenciamento da AWS ou com a criação de uma política da AWS Application Auto Scaling por meio da AWS CLI ou APIs. O armazenamento por camadas em agentes Standard viabiliza praticamente o armazenamento de dados ilimitados em seu cluster sem precisar adicionar agentes para armazenamento. Com os agentes Express, não é preciso provisionar ou gerenciar o armazenamento e você tem acesso a um armazenamento virtualmente ilimitado. Para clusters sem servidor, o armazenamento é escalonado de forma integral de acordo com o uso.

O Apache Kafka armazena dados em arquivos chamados segmentos de log. Conforme cada segmento é concluído, com base no tamanho configurado no cluster ou no nível do tópico, ele é copiado para o armazenamento de baixo custo. Os dados são mantidos em armazenamento otimizado para performance por um tempo ou tamanho de retenção especificados e, em seguida, são excluídos. Há uma configuração separada quanto ao limite de tempo e tamanho de armazenamento de baixo custo, que é maior que a do nível de armazenamento primário. Se os clientes solicitarem dados de segmentos armazenados no nível de baixo custo, o agente lerá e servirá os dados como se eles estivessem sendo servidos a partir do armazenamento primário.

Sim, é possível aumentar ou diminuir horizontalmente a escala do número de agentes para clusters provisionados do MSK.

Sim, é possível escolher entre escalar um tipo de agente menor ou maior em seus clusters provisionados do MSK.

Você pode usar o Cruise Control para reequilibrar automaticamente as partições para gerenciar a movimentação de E/S. Consulte a documentação do Cruise Control para obter mais informações. Como alternativa, é possível usar o arquivo Kafka Admin API kafka-reassign-partitions.sh para reatribuir partições entre os agentes. Para clusters sem servidor, o Amazon MSK reequilibra automaticamente as partições.

A definição de preço depende dos recursos criados. É possível saber mais detalhes acessando os preços do Amazon MSK.

Não, as transferências de dados no cluster estão incluídas no serviço sem custo adicional.

Para obter informações sobre as regiões nas quais o Amazon MSK está disponível, visite a tabela de regiões da AWS. 

Com os clusters provisionados, você pagará taxas de transferência de dados padrão AWS para dados transferidos dentro e fora de um cluster do MSK. Você receberá cobrança pela transferência de dados dentro do cluster em uma região, inclusive pela transferência de dados entre os agentes e a transferência de dados entre os agentes e os nós de gerenciamento de metadados.

Com clusters sem servidor, você pagará taxas padrão de cobrança de transferência de dados AWS por dados transferidos de ou para outra região e por dados transferidos para fora da Internet pública.

Não neste momento.

O Amazon MSK tem compatibilidade ou elegibilidade com os seguintes programas:

• Qualificado pela HIPAA

• PCI

• ISO

• SOC 1, 2 e 3

Para obter uma lista completa dos serviços e programas de conformidade da AWS, consulte serviços da AWS no escopo do programa de conformidade.

Nosso SLA do Amazon MSK garante uma porcentagem de tempo de atividade mensal de, no mínimo, 99,9% para o Amazon MSK (incluindo o MSK Serverless e o MSK Connect). 

Você poderá receber um crédito do SLA para o Amazon MSK nos termos do SLA do Amazon MSK se as implantações multi-AZ no Amazon MSK tiverem uma porcentagem de tempo de atividade mensal inferior a 99,9% durante qualquer ciclo de faturamento mensal.

Para obter detalhes completos sobre todos os termos e condições do SLA, além dos detalhes sobre o envio de uma declaração, consulte a página do SLA do Amazon MSK.