Federação de vários sites e várias regiões
Muitas soluções sofisticadas exigem que os mesmos fluxos de eventos sejam disponibilizados para consumo em vários locais ou exigem que os fluxos de eventos sejam coletados em vários locais e, em seguida, consolidados em um local específico para consumo. Também há a necessidade de enriquecer ou reduzir fluxos de eventos ou fazer conversões de formato de evento, também para dentro de uma única região e solução.
Praticamente, isso significa que sua solução manterá vários hubs de eventos, geralmente em diferentes regiões e namespaces de hubs de eventos, e, em seguida, replicará os eventos entre eles. Você também pode trocar eventos com origens e destinos como o Barramento de Serviço do Azure, Hub IOT do Azure ou Apache Kafka.
A manutenção de vários hubs de eventos ativos em diferentes regiões também permite que os clientes escolham e alternem entre eles se o seu conteúdo estiver sendo mesclado, o que torna o sistema geral mais resiliente contra problemas de disponibilidade regional.
Este capítulo "Federação" explica os padrões de Federação e como perceber esses padrões usando o Azure Stream Analytics sem servidor ou os tempos de execução do Azure Functions, com a opção de ter seu próprio código de transformação ou de enriquecimento bem no caminho do fluxo de eventos.
Padrões de federação
Há muitas motivações possíveis para o porquê de você querer mover eventos entre diferentes hubs de eventos ou outras origens e destinos, e enumeramos os padrões mais importantes nesta seção e também vinculamos a diretrizes mais detalhadas para o respectivo padrão.
- Resiliência contra eventos de disponibilidade regional
- Otimização de latência
- Validação, redução e enriquecimento
- Integração com serviços de análise
- Consolidação e normalização de fluxos de eventos
- Divisão e roteamento de fluxos de eventos
- Projeções de log
Resiliência contra eventos de disponibilidade regional
Embora a disponibilidade e a confiabilidade máximas sejam as principais prioridades operacionais dos hubs de eventos, há, no entanto, muitas maneiras pelas quais um produtor ou consumidor pode ser impedido de falar com seus Hubs de Eventos "primários" atribuídos devido a problemas de resolução de nome ou rede ou em que Hubs de Eventos podem realmente não responder temporariamente ou retornar erros.
Essas condições não são "desastrosas", de forma que você queira abandonar completamente a implantação regional, como é possível fazer em uma situação de recuperação de desastre, mas o cenário de negócios de alguns aplicativos já pode ser afetado por eventos de disponibilidade que duram não mais de alguns minutos ou até mesmo segundos.
Há dois padrões fundamentais para resolver esses cenários:
- O padrão de replicação é sobre replicar o conteúdo de Hubs de Eventos primários para Hubs de Eventos secundários, no qual os Hubs de Eventos primários geralmente são usados pelo aplicativo para produzir e consumir eventos, e os secundários servem como uma opção de fallback caso os Hubs de Eventos primários fiquem indisponíveis. Como a replicação é unidirecional, do primário para o secundário, uma alternância de produtores e consumidores de um primário não disponível para o secundário fará com que o primário antigo não receba mais novos eventos e, portanto, não será mais atual. Portanto, a replicação pura só é adequada para cenários de failover únicos. Depois que o failover tiver sido executado, o primário antigo será abandonado, e novos Hubs de Eventos secundários precisarão ser criados em uma região de destino diferente.
- O padrão de mesclagem estende o padrão de replicação executando uma mesclagem contínua do conteúdo de dois ou mais hubs de eventos. Cada evento produzido originalmente em um dos Hubs de Eventos incluídos no esquema é replicado para os outros hubs de eventos. À medida que os eventos são replicados, eles são anotados de forma a serem subsequentemente ignorados pelo processo de replicação do destino de replicação. Os resultados do uso do padrão de mesclagem são dois ou mais hubs de eventos que conterão o mesmo conjunto de eventos de maneira eventualmente consistente.
Em ambos os casos, o conteúdo dos hubs de eventos não será idêntico. Os eventos de qualquer produtor e agrupados pela mesma chave de partição aparecerão na mesma ordem relativa que foi enviada originalmente, mas a ordem absoluta dos eventos pode ser diferente. Isso é especialmente verdadeiro para cenários em que a contagem de partições de hubs de eventos de origem e de destino difere, o que é desejável para vários dos padrões estendidos descritos aqui. Um divisor ou roteador pode obter uma fatia de Hubs de Eventos muito maior com centenas de partições e afunilar para Hubs de Eventos menores com apenas algumas partições, mais adequadas para manipular o subconjunto com recursos de processamento limitado. Por outro lado, uma consolidação pode direcionar os dados de vários Hubs de Eventos menores para Hubs de Eventos único e maior com mais partições para lidar com as necessidades consolidadas de taxa de transferência e processamento.
O critério para manter eventos juntos é a chave de partição e não a ID da partição original. Considerações adicionais sobre a ordem relativa e como executar um failover de Hubs de Eventos para o próximo sem depender do mesmo escopo de deslocamentos de fluxo são discutidas na descrição do padrão de replicação.
Diretrizes:
Otimização de latência
Os fluxos de eventos são gravados uma vez por produtores, mas podem ser lidos várias vezes por consumidores de evento. Para cenários em que um fluxo de eventos em uma região é compartilhado por vários consumidores e precisa ser acessado repetidamente durante o processamento de análise que reside em uma região diferente ou com as demandas completas que poderiam deixar os consumidores simultâneos sem atendimento, pode ser benéfico colocar uma cópia do fluxo de eventos perto do processador de análise para reduzir a latência de ida e volta.
Os bons exemplos para quando a replicação deve ser preferida em vez do consumo de eventos remotamente entre regiões são especialmente aqueles em que as regiões estão extremamente distantes, por exemplo, Europa e Austrália sendo praticamente antípodas geograficamente falando, e latências de rede podem facilmente exceder 250 ms para qualquer viagem de ida e volta. Você não pode acelerar na velocidade da luz, mas pode reduzir o número de viagens de ida e volta de alta latência para interagir com os dados.
Diretrizes:
Validação, redução e enriquecimento
Os fluxos de eventos podem ser enviados para Hubs de Eventos por clientes externos à sua solução. Esses fluxos de eventos podem exigir que eventos enviados externamente sejam verificados quanto à conformidade com um determinado esquema e que eventos não compatíveis sejam descartados.
Em cenários em que os clientes são extremamente restritos por largura de banda, como é o caso em muitos cenários de "Internet das Coisas" com largura de banda limitada ou em que os eventos são originalmente enviados por redes não IP com tamanhos de pacotes restritos, os eventos talvez precisem ser enriquecidos com dados de referência para adicionar mais contexto a fim de que possam ser usados por processadores de eventos downstream.
Em outros casos, especialmente quando os fluxos estão sendo consolidados, a complexidade ou o tamanho total dos dados do evento talvez precise ser reduzido por meio da omissão de alguns detalhes.
Qualquer uma dessas operações pode ocorrer como parte dos fluxos de replicação, consolidação ou mesclagem.
Diretrizes:
Integração com serviços de análise
Vários dos serviços de análise nativa de nuvem do Azure, como Azure Stream Analytics ou Azure Synapse, funcionam melhor com dados transmitidos ou pré-em lote atendidos dos Hubs de Eventos do Azure, e os Hubs de Eventos do Azure também permitem a integração com vários pacotes de análise open-source, como Apache Samza, Apache Flink, Apache Spark e Apache Storm.
Se a sua solução usar principalmente o barramento de serviço ou a Grade de Eventos, você poderá tornar esses eventos facilmente acessíveis para esses sistemas de análise e também para arquivamento com a Captura de Hubs de Eventos, se você os direcionar para Hubs de Eventos. A Grade de Eventos pode fazer isso nativamente com sua integração de Hubs de Eventos. Para o Barramento de Serviço, siga as Diretrizes de replicação do barramento de serviço.
O Azure Stream Analytics integra-se diretamente aos hubs de eventos.
Diretrizes:
Consolidação e normalização de fluxos de eventos
As soluções globais são geralmente compostas por superfície regionais que são amplamente independentes, incluindo ter seus próprios recursos de análise, mas as perspectivas de análises globais e suprarregionais exigirão uma perspectiva integrada e daí haver uma consolidação central dos mesmos fluxos de eventos que são avaliados nos respectivos vestígios regionais para a perspectiva local.
A normalização é um tipo de cenário de consolidação, no qual dois ou mais fluxos de eventos de entrada carregam o mesmo tipo de evento, mas com estruturas diferentes ou codificações diferentes, e os eventos, em sua maioria, são transcodificados ou transformados antes que possam ser consumidos.
A normalização também pode incluir trabalho criptográfico, como descriptografar cargas criptografadas de ponta a ponta e criptografá-las novamente com chaves e algoritmos diferentes para o público do consumidor downstream.
Diretrizes:
Divisão e roteamento de fluxos de eventos
Os hubs de eventos do Azure são usados ocasionalmente em cenários de estilo "publicar-assinar", em que um torrent de entrada de eventos ingeridos ultrapassa a capacidade do Barramento de Serviço do Azure ou da Grade de Eventos do Azure, ambos com recursos de filtragem e de distribuição nativos de publicação e são preferidos para esse padrão.
Embora uma verdadeira funcionalidade de "publicação-assinatura" deixe para os assinantes escolherem os eventos que eles querem, o padrão de divisão faz com que o produtor mapeie eventos para partições por um modelo de distribuição predeterminado e os consumidores designados e, em seguida, efetuam pull exclusivamente da partição "deles". Com Hubs de Eventos armazenados em buffer o tráfego geral, o conteúdo de uma partição específica, que representa uma fração do volume de taxa de transferência original, pode então ser replicado em uma fila para consumo de consumidor confiável, transacional e concorrente.
Muitos cenários em que os Hubs de Eventos são usados principalmente para mover eventos dentro de um aplicativo dentro de uma região têm alguns casos em que a seleção de eventos, talvez apenas de uma única partição, também precisa ser disponibilizada em outro lugar. Esse cenário é semelhante ao cenário de divisão, mas pode usar um roteador escalonável que considera todas as mensagens que chegam em Hubs de Eventos e escolhe apenas algumas para roteamento subsequente e pode diferenciar destinos de roteamento por metadados de evento ou conteúdo.
Diretrizes:
Projeções de log
Em alguns cenários, você deseja ter acesso ao valor mais recente enviado para qualquer subfluxo de um evento e normalmente diferenciado pela chave de partição. No Apache Kafka, isso geralmente é obtido habilitando a "compactação de log" em um tópico, que descarta todos, menos o evento mais recente rotulado com qualquer chave exclusiva. A abordagem de compactação de log tem três desvantagens combinadas:
- A compactação requer uma reorganização contínua do log, que é uma operação excessivamente cara para um agente otimizado para cargas de trabalho somente de adição.
- A compactação é destrutiva e não permite uma perspectiva compactada e não compactada do mesmo fluxo.
- Um fluxo compactado ainda tem um modelo de acesso sequencial, o que significa que localizar o valor desejado no log requer a leitura de todo o log no pior caso, o que normalmente leva a otimizações que implementam o padrão exato apresentado aqui: projetar o conteúdo do log em um banco de dados ou cache.
Por fim, um log compactado é um armazenamento de valor-chave e, como tal, é a pior opção de implementação possível para tal armazenamento. É muito mais eficiente para pesquisas e consultas para criar e usar uma projeção permanente do log em um armazenamento de valor-chave adequado ou em algum outro banco de dados.
Como os eventos são imutáveis e a ordem é sempre preservada em um log, qualquer projeção de um log em um armazenamento de valor-chave sempre será idêntica ao mesmo intervalo de eventos, o que significa que uma projeção que você mantém atualizada sempre fornece uma exibição autoritativa e nunca há um bom motivo para reconstruí-la a partir do conteúdo do log uma vez compilado.
Diretrizes:
Tecnologias de aplicativo de replicação
A implementação dos padrões acima requer um ambiente de execução escalonável e confiável para as tarefas de replicação que você deseja configurar e executar. No Azure, os ambientes de tempo de execução mais adequados para essas tarefas são Azure Stream Analytics para tarefas de replicação de fluxo com estado e Azure Functions para tarefas de replicação sem estado.
Aplicativos de replicação com estado no Azure Stream Analytics
Para aplicativos de replicação com estado que precisam considerar relações entre eventos, criar eventos compostos, enriquecer eventos ou reduzir eventos, criar agregações de dados e transformar cargas de evento, o Azure Stream Analytics é a melhor opção de implementação.
No Azure Stream Analytics, você cria trabalhos que integram entradas e saídas e integram os dados das entradas por meio de consultas que produzem um resultado que é disponibilizado nas saídas.
As consultas têm como base a linguagem de consulta SQL e podem ser usadas para filtrar, classificar, agregar e associar dados de streaming com facilidade por um período de tempo. Também é possível estender essa linguagem SQL com UDFs (funções definidas pelo usuário) do JavaScript e do C#. Você pode ajustar com facilidade as opções de ordenação de eventos e a duração das janelas de tempo ao executar operações de agregação por meio de simples configurações e/ou constructos de linguagem.
Cada trabalho tem uma ou várias saídas para os dados transformados, e você pode controlar o que acontece em resposta às informações analisadas. Por exemplo, você pode:
- Enviar dados para serviços como Azure Functions, Filas ou Tópicos do Barramento de Serviço para disparar comunicações ou de fluxos de trabalho personalizados downstream.
- Enviar dados a um painel do Power BI para painéis em tempo real.
- Armazene dados em outros serviços de armazenamento do Azure (por exemplo, Azure Data Lake, Azure Synapse Analytics etc.) para treinar modelos de machine learning com base em pools indexados muito grandes de dados históricos.
- Armazenar projeções (também chamadas de "exibições materializadas") em bancos de dados (SQL Database, Azure Cosmos DB).
Aplicativos de replicação sem estado no Azure Functions
Para tarefas de replicação sem estado em que você deseja encaminhar eventos sem considerar seus payloads ou processá-los sem precisar considerar as relações de eventos (exceto sua ordem relativa), é possível usar o Azure Functions, que proporciona enorme flexibilidade.
Azure Functions tem gatilhos pré-construídos e escalonáveis e associações de saída para Hubs de Eventos do Azure, Hub IoT do Azure, Barramento de Serviço do Azure, Grade de Eventos do Azure e Armazenamento de Filas do Azure, bem como extensões personalizadas para RabbitMQ e Apache Kafka. A maioria dos gatilhos se adaptará dinamicamente às necessidades de produtividade, dimensionando o número de instâncias em execução simultânea para cima e para baixo com base nas métricas documentadas.
Para criar projeções de log, o Azure Functions dá suporte a associações de saída para Azure Cosmos DB e Armazenamento de Tabelas do Azure.
O Azure Functions pode ser executado em uma identidade gerenciada do Azure e, com isso, ele pode conter os valores de configuração para credenciais no armazenamento fortemente controlado por acesso dentro do Azure Key Vault.
O Azure Functions, além disso, permite que as tarefas de replicação se integrem diretamente a redes virtuais do Azure e pontos de extremidade de serviço para todos os serviços de mensagens do Azure, e ele é prontamente integrado ao Azure Monitor.
Com o planos de consumo do Azure Functions, os gatilhos pré-integrados podem até mesmo reduzir para zero enquanto nenhuma mensagem está disponível para replicação, o que significa que você não incorre em custos para manter a configuração pronta para escalar novamente; a principal desvantagem de usar o plano de consumo é que a latência para tarefas de replicação "ativadas" a partir desse estado é significativamente maior do que com os planos de hospedagem em que a infraestrutura é mantida em execução.
Ao contrário de tudo isso, os mecanismos de replicação mais comuns para mensagens e eventos, como o MirrorMaker do Apache Kafka, exigem que você forneça um ambiente de hospedagem e dimensione o mecanismo de replicação por conta própria. Isso inclui a configuração e a integração dos recursos de segurança e de rede e a viabilização do fluxo de dados de monitoramento e, em seguida, você ainda não tem a oportunidade de injetar tarefas de replicação personalizadas no fluxo.
Escolhendo entre Azure Functions e Azure Stream Analytics
Azure Stream Analytics (ASA) é a melhor opção sempre que você precisar processar a carga de seus eventos enquanto os replica. O ASA pode copiar eventos um por um ou criar agregações que condensam as informações de fluxos de eventos antes de encaminhá-las. Ele pode prontamente fazer com que você complemente os dados de referência mantidos no Armazenamento de Blobs do Azure ou no Banco de Dados SQL do Azure sem a necessidade de importar esses dados para um fluxo.
Com o ASA, você pode criar facilmente exibições persistentes e materializadas de fluxos em bancos de dados de hiperescala. É uma abordagem muito superior para o modelo de "compactação de log" ultrapassado do Apache Kafka e as projeções de tabela voláteis, do lado do cliente, dos fluxos do Kafka.
O ASA pode prontamente processar eventos com cargas codificadas nos formatos CSV, JSON e Apache Avro, e você pode conectar desserializadores personalizados para qualquer outro formato.
Para todas as tarefas de replicação em que você deseja copiar fluxos de eventos "no estado em que se encontram" e sem tocar nas cargas, ou se precisar implementar um roteador, executar o trabalho de criptografia, alterar a codificação de cargas ou, caso contrário, precisar de controle total sobre o conteúdo do fluxo de dados, o Azure Functions será a melhor opção.
Próximas etapas
Neste artigo, exploramos uma variedade de padrões de federação e explicamos a função de Azure Functions como o tempo de execução de replicação de evento e de mensagens no Azure.
Em seguida, talvez você queira ler como configurar um aplicativo replicador com Azure Stream Analytics ou Azure Functions e como replicar fluxos de eventos entre os hubs de eventos e vários outros sistemas de mensagens e eventos: