Plataforma de dados para cargas de trabalho de missão crítica no Azure

Em uma arquitetura de missão crítica, qualquer estado deve ser armazenado fora da computação, tanto quanto possível. A escolha da tecnologia baseia-se nas seguintes características arquitetónicas chave:

Características Considerações
Desempenho Quanta computação é necessária?
Latência Que impacto terá a distância entre o utilizador e o armazenamento de dados na latência? Qual é o nível desejado de consistência com a compensação na latência?
Capacidade de Resposta É necessário que o armazenamento de dados esteja sempre disponível?
Escalabilidade Qual é o esquema de particionamento?
Durabilidade Espera-se que os dados sejam duradouros? O que é a política de retenção?
Resiliência Em caso de falha, o armazenamento de dados pode fazer failover automaticamente? Que medidas estão em vigor para reduzir o tempo de failover?
Segurança Os dados são encriptados? O armazenamento de dados pode ser acessado pela rede pública?

Projete sua carga de trabalho de missão crítica com armazenamentos de dados apropriados. Considere o uso de dois tipos principais:

  • Base de dados

    Armazenamentos relacionados à carga de trabalho. Recomenda-se que todos os estados sejam armazenados globalmente em um banco de dados separado dos selos regionais. Crie redundância implantando o banco de dados entre regiões. Para cargas de trabalho de missão crítica, a sincronização de dados entre regiões deve ser a principal preocupação. Além disso, em caso de falha, as solicitações de gravação no banco de dados ainda devem ser funcionais.

    A replicação de dados em uma configuração ativa-ativa é altamente recomendada. O aplicativo deve ser capaz de se conectar instantaneamente com outra região. Todas as instâncias devem ser capazes de lidar com solicitações de leitura e gravação.

  • Agente de mensagens

    O único serviço com estado no carimbo regional é o agente de mensagens, que armazena solicitações por um curto período. O corretor atende à necessidade de buffering e mensagens confiáveis. As solicitações processadas são mantidas no banco de dados global.

Para outras considerações sobre dados, consulte Orientação de missão crítica em Estrutura bem arquitetada: considerações sobre plataforma de dados.

Base de Dados

Considere usar o Azure Cosmos DB para NoSQL para cargas de trabalho de missão crítica. Esta opção fornece os recursos essenciais necessários para projetos de missão crítica:

  • Gravação em várias regiões

    A gravação em várias regiões é habilitada com réplicas implantadas em todas as regiões em que um carimbo é implantado. Cada carimbo pode escrever localmente e o Azure Cosmos DB lida com a replicação de dados e a sincronização entre os carimbos. Esse recurso reduz significativamente a latência para usuários finais geograficamente distribuídos do aplicativo. As cargas de trabalho de missão crítica normalmente usam tecnologia que fornece recursos de gravação em várias regiões para fornecer o máximo de resiliência e disponibilidade.

    A redundância de zona também é habilitada em cada região replicada.

    Para obter mais informações sobre gravações de várias regiões, consulte Configurar gravações de várias regiões em seus aplicativos que usam o Azure Cosmos DB.

  • Gestão de conflitos

    Com a capacidade de executar gravações em várias regiões, surge a necessidade de adotar um modelo de gerenciamento de conflitos, pois gravações simultâneas podem introduzir conflitos de registro. Last Writer Wins é o modelo padrão e é usado para o design de missão crítica. O último escritor, conforme definido pelos carimbos de data/hora associados dos registros, ganha o conflito. O Azure Cosmos DB para NoSQL também permite que uma propriedade personalizada seja definida.

  • Otimização de consultas

    Uma recomendação geral de eficiência de consulta para contêineres de leitura pesada com um grande número de partições é adicionar um filtro de igualdade com o itemID identificado. Uma revisão aprofundada das recomendações de otimização de consultas pode ser encontrada em Resolução de problemas de consulta quando utiliza o Azure Cosmos DB.

  • Recurso de backup

    É recomendável usar o recurso de backup nativo do Azure Cosmos DB para proteção de dados. O recurso de backup do Azure Cosmos DB oferece suporte a backups online e restauração de dados sob demanda.

Nota

A maioria das cargas de trabalho não são puramente OLTP. Há uma procura crescente por relatórios em tempo real, como a execução de consultas no sistema operacional. Isso também é conhecido como HTAP (Hybrid Transactional and Analytical Processing). O Azure Cosmos DB suporta esta funcionalidade através do Mirroring in Fabric para o Cosmos DB.

Modelo de dados para a carga de trabalho

O modelo de dados deve ser projetado de modo que os recursos oferecidos pelos bancos de dados relacionais tradicionais não sejam necessários. Por exemplo, chaves estrangeiras, esquema estrito de linha/coluna, modos de exibição e outros.

A carga de trabalho tem estas características de acesso a dados:

  • Padrão de leitura:
    • Ponto lê - Obtenção de um único registo. O ID do item e a chave de partição são usados diretamente para otimização máxima (1 RU por solicitação).
    • Listar leituras - Obter itens de catálogo para exibição em uma lista. A FeedIterator com um limite no número de resultados é utilizado.
  • Padrão de escrita:
    • Pequenas operações de escrita - As solicitações normalmente inserem um ou alguns registos por transação.
  • Projetado para lidar com alto tráfego de usuários finais com a capacidade de escalar para lidar com a demanda de tráfego na ordem de milhões de usuários.
  • Pequena carga útil ou tamanho do conjunto de dados - geralmente em ordem de KB.
  • Tempo de resposta baixo (em ordem de milissegundos).
  • Baixa latência (em ordem de milissegundos).

Configuração

O Azure Cosmos DB está configurado da seguinte forma:

  • O nível de consistência é definido como a consistência de sessão padrão porque é o nível mais usado para uma única região e aplicativos distribuídos globalmente. A consistência mais fraca com uma taxa de transferência mais alta não é necessária devido à natureza assíncrona do processamento de gravação e não requer baixa latência na gravação do banco de dados.

    Nota

    O nível de consistência da sessão oferece uma compensação razoável para garantias de latência, disponibilidade e consistência para aplicativos de missão crítica. É importante entender que o nível de consistência forte não está disponível para bancos de dados de gravação de vários mestres.

  • A chave de partição é definida como /id para todas as coleções. Esta decisão é baseada no padrão de uso, que é principalmente "escrever novos documentos com GUID como o ID" e "ler uma ampla gama de documentos por IDs". Desde que o código do aplicativo mantenha sua exclusividade de ID, os novos dados são distribuídos uniformemente em partições pelo Azure Cosmos DB, permitindo uma escala infinita.

  • A política de indexação é configurada em coleções para otimizar consultas. Para otimizar o custo e o desempenho da RU, uma política de indexação personalizada é usada. Esta política indexa apenas as propriedades que são usadas em predicados de consulta. Por exemplo, o aplicativo não usa o campo de texto de comentário como um filtro em consultas. Foi excluído da política de indexação personalizada.

    O exemplo a seguir mostra as configurações de diretiva de indexação recomendadas usando o Terraform:

    indexing_policy {

  excluded_path {
    path = "/description/?"
  }

  excluded_path {
    path = "/comments/text/?"
  }

  included_path {
    path = "/*"
  }

}

Para obter informações sobre a conexão do aplicativo ao Azure Cosmos DB para cargas de trabalho de missão crítica, consulte Considerações sobre a plataforma de aplicativo para cargas de trabalho de missão crítica

Serviços de mensagens

Os sistemas de missão crítica geralmente utilizam serviços de mensagens para processamento de mensagens ou eventos. Esses serviços promovem acoplamentos flexíveis e atuam como um buffer que isola o sistema contra picos inesperados na demanda.

  • O Barramento de Serviço do Azure é recomendado para cargas de trabalho baseadas em mensagens ao lidar com mensagens de alto valor.
  • Os Hubs de Eventos do Azure são recomendados para sistemas baseados em eventos que processam grandes volumes de eventos ou telemetria.

As secções seguintes descrevem considerações de design e recomendações para Azure Service Bus premium e Azure Event Hubs numa arquitetura de missão crítica.

Lidar com a carga

O sistema de mensagens deve ser capaz de lidar com a taxa de transferência necessária (como em MB por segundo). Considere os seguintes fatores:

  • Os requisitos não funcionais (NFRs) do sistema devem especificar o tamanho médio da mensagem e o número máximo de mensagens/segundo que cada carimbo deve suportar. Esta informação pode ser utilizada para calcular o pico necessário de MB/segundo por carimbo.
  • O impacto de um failover deve ser considerado ao calcular o pico necessário de MB/segundo por carimbo.
  • Para o Barramento de Serviço do Azure, os NFRs devem especificar quaisquer recursos avançados do Barramento de Serviço, como sessões e mensagens de eliminação de duplicação. Essas características afetarão a taxa de transferência do Service Bus.
  • A taxa de transferência do Service Bus com os recursos necessários deve ser calculada por meio de testes como MB/segundo por Unidade de Mensagens (MU). Para obter mais informações sobre este tópico, consulte Camadas de mensagens premium e padrão do Service Bus.
  • A taxa de transferência dos Hubs de Eventos do Azure deve ser calculada por meio de testes como MB/segundo por unidade de taxa de transferência (TU) para a camada padrão ou unidade de processamento (PU) para a camada premium. Para obter mais informações sobre este tópico, consulte Dimensionamento com Event Hubs.
  • Os cálculos anteriores podem ser usados para validar que o serviço de mensagens consegue lidar com a carga necessária por carimbo e o número necessário de unidades de escala necessárias para cumprir essa carga.
  • A seção de operações discutirá o dimensionamento automático.

Todas as mensagens devem ser processadas

A camada premium do Barramento de Serviço do Azure é a solução recomendada para mensagens de alto valor cujo processamento deve ser garantido. Seguem-se os detalhes sobre este requisito quando utiliza o Azure Service Bus premium:

  • Para garantir que as mensagens sejam transferidas e aceitas corretamente pelo broker, os produtores de mensagens devem usar um dos clientes de API do Service Bus suportados. As APIs suportadas só retornarão com êxito de uma operação de envio se a mensagem persistir na fila/tópico.

  • Para garantir que as mensagens no barramento sejam processadas, você deve usar o modo de recebimento PeekLock. Este modo permite o processamento pelo menos uma vez. As etapas a seguir descrevem o processo:

    • O consumidor de mensagens recebe a mensagem para processar.
    • O consumidor recebe um bloqueio exclusivo da mensagem por um determinado período de tempo.
    • Se o consumidor processar a mensagem com êxito, ele enviará uma confirmação de volta ao corretor e a mensagem será removida da fila.
    • Se uma confirmação não for recebida pelo corretor no período de tempo atribuído, ou se o manipulador abandonar explicitamente a mensagem, o bloqueio exclusivo será liberado. A mensagem fica então disponível para outros consumidores processarem a mensagem.
    • Se uma mensagem não for processada com êxito um número configurável de vezes, ou se o manipulador encaminhar a mensagem para a fila de letras mortas .
      • Para garantir que as mensagens enviadas para a fila de mensagens mortas sejam atendidas, a fila de mensagens mortas deve ser monitorada e alertas devem ser definidos.
      • O sistema deve ter ferramentas para que os operadores possam inspecionar, corrigir e reenviar mensagens.

  • Como as mensagens podem ser processadas mais de uma vez, os manipuladores de mensagens devem ser idempotentes.

Processamento de mensagens idempotente

No RFC 7231, o protocolo de transferência de hipertexto afirma, "A ... método é considerado idempotente se o efeito pretendido no servidor de várias solicitações idênticas com esse método for o mesmo que o efeito para uma única solicitação desse tipo."

Uma técnica comum de tornar o tratamento de mensagens idempotente é verificar um armazenamento persistente, como um banco de dados, se a mensagem já foi processada. Se ele tiver sido processado, você não executaria a lógica para processá-lo novamente.

  • Pode haver situações em que o processamento da mensagem inclui operações de banco de dados, especificamente a inserção de novos registros com identificadores gerados por banco de dados. Novas mensagens podem ser emitidas para o corretor, que contém esses identificadores. Como não existem transações distribuídas que englobem tanto a base de dados como o corretor de mensagens, podem surgir complicações se o processo que executa o código falhar. Considere os seguintes exemplos:
    • O código que emite as mensagens pode ser executado antes que a transação do banco de dados seja confirmada, que é como muitos desenvolvedores trabalham usando o padrão Unidade de Trabalho. Essas mensagens podem escapar, se a falha ocorrer entre chamar o corretor e solicitar que a transação do banco de dados seja confirmada. À medida que a transação é revertida, essas IDs geradas pelo banco de dados também são desfeitas, o que as deixa disponíveis para outro código que possa estar a ser executado ao mesmo tempo. Isso pode fazer com que os destinatários das mensagens escapadas processem as entradas erradas do banco de dados, o que prejudica a consistência geral e a correção do seu sistema.
    • Se os desenvolvedores colocarem o código que emite a mensagem após a conclusão da transação do banco de dados, o processo ainda poderá falhar entre essas operações (transação confirmada - mensagem enviada). Quando isso acontecer, a mensagem passará por processamento novamente, mas desta vez a cláusula de proteção de idempotência verá que ela já foi processada (com base nos dados armazenados no banco de dados). A cláusula ignorará o código emissor da mensagem, acreditando que tudo foi feito com sucesso da última vez. Os sistemas a jusante, que esperavam receber notificações sobre o processo concluído, não recebem nada. Esta situação conduz, mais uma vez, a um estado global de incoerência.
  • A solução para os problemas descritos anteriormente envolve o uso do padrão Transactional Outbox, onde as mensagens de saída são armazenadas em separado, no mesmo armazenamento transacional que os dados do negócio. As mensagens são então transmitidas para o agente de mensagens, quando a mensagem inicial tiver sido processada com êxito.
  • Como muitos desenvolvedores não estão familiarizados com esses problemas ou suas soluções, a fim de garantir que essas técnicas sejam aplicadas de forma consistente em um sistema de missão crítica, sugerimos que você tenha a funcionalidade da caixa de saída e a interação com o agente de mensagens envolvidas em algum tipo de biblioteca. Todo o processamento de código e envio de mensagens transacionais significativas deve fazer uso dessa biblioteca, em vez de interagir diretamente com o agente de mensagens.

Alta disponibilidade e recuperação de desastres

O corretor de mensagens deve estar disponível para que os produtores enviem mensagens e os consumidores as recebam. Siga os seguintes passos para garantir uma elevada disponibilidade para o seu corretor de mensagens:

  • Para garantir a mais alta disponibilidade com o Service Bus, use a camada premium, que tem suporte para zonas de disponibilidade em regiões de suporte. Com zonas de disponibilidade, mensagens e metadados são replicados em três data centers diferentes na mesma região.
  • Use SDKs suportados do Service Bus ou dos Event Hubs para tentar automaticamente novamente erros de leitura ou escrita.
  • Considere os padrões de replicação ativa-ativa ou ativa-passiva para proteger-se contra desastres regionais.

Nota

A recuperação geográfica de desastres do Barramento de Serviço do Azure replica apenas os metadados entre regiões. Esse recurso não replica mensagens.

Monitorização

O sistema de mensagens funciona como um buffer entre os produtores de mensagens e os consumidores. Pode obter informações valiosas ao monitorizar os tipos de indicadores-chave num sistema crítico para a missão:

  • Limitação - A limitação indica que o sistema não tem os recursos necessários para processar a solicitação. Tanto o Service Bus quanto os Hubs de Eventos oferecem suporte ao monitoramento de solicitações controladas. Deve alertar para este indicador.
  • Profundidade da fila - Uma profundidade de fila crescente pode indicar que os processadores de mensagens não estão funcionando ou que não há processadores suficientes para lidar com a carga atual. A profundidade da fila pode ser usada para informar a lógica de dimensionamento automático dos gestores.
    • Para o Service Bus, a profundidade da fila é apresentada como contagem de mensagens
    • Para Event Hubs, os consumidores precisam calcular a profundidade da fila por partição e enviar a métrica para o software de monitorização. Para cada leitura, o consumidor obtém o número de sequência do evento atual e as propriedades do último evento enfileirado. O consumidor pode calcular a compensação.
  • Fila de mensagens mortas - As mensagens na fila de mensagens mortas representam mensagens que não puderam ser processadas. Essas mensagens geralmente exigem intervenção manual. Os alertas devem ser definidos na fila de mensagens mortas.
    • O Service Bus tem uma fila de mensagens mortas e uma métrica DeadLetteredMessages.
    • Para Hubs de Eventos, essa funcionalidade deve ser lógica personalizada incorporada ao consumidor.
  • Uso de CPU/Memória - CPU e memória devem ser monitoradas para garantir que o sistema de mensagens tenha recursos suficientes para processar a carga atual. Tanto o Service Bus Premium quanto o Event Hubs Premium expõem o uso da CPU e da memória.
    • As unidades de mensagens (MUs) são usadas no Service Bus para isolar recursos como CPU e memória para um namespace. CPU e memória acima de um limite podem indicar que não há MUs suficientes configuradas, enquanto ficar abaixo de outros limites pode indicar que há muitas MUs configuradas. Esses indicadores podem ser usados para dimensionar automaticamente MUs.
    • A camada premium dos Hubs de Eventos usa unidades de processamento (PUs) para isolar recursos, enquanto a camada padrão usa unidades de taxa de transferência (TUs). Essas camadas não exigem interação com CPU/Memória para aumentar automaticamente PUs ou TUs.

Avaliação de saúde

A integridade do sistema de mensagens deve ser considerada nas verificações de integridade de um aplicativo de missão crítica. Considere os seguintes fatores:

  • O sistema de mensagens funciona como um buffer entre os produtores de mensagens e os consumidores. O selo pode ser visto como saudável se os produtores forem capazes de enviar mensagens com sucesso para o corretor e se os consumidores forem capazes de processar com sucesso as mensagens do corretor.
  • A verificação de integridade deve garantir que as mensagens possam ser enviadas para o sistema de mensagens.

Próximos passos

Missão crítica: implantação e testes

  • Last updated on