Este artigo descreve como fornecer uma solução analítica avançada de missão crítica com o Azure Data Factory. Essa arquitetura é uma extensão da arquitetura de linha de base e da arquitetura corporativa reforçada. Este artigo fornece diretrizes específicas sobre as alterações recomendadas necessárias para gerenciar uma carga de trabalho como uma operação crítica.
Essa arquitetura se alinha com as práticas recomendadas e diretrizes do Cloud Adoption Framework para Azure e as recomendações para cargas de trabalho críticas.
Na arquitetura de linha de base, a Contoso opera um medallion lakehouse que dá suporte às primeiras cargas de trabalho de dados para o departamento financeiro. A Contoso fortalece e estende esse sistema para dar suporte às necessidades de dados analíticos da empresa. Essa estratégia fornece recursos de ciência de dados e funcionalidade de autoatendimento.
Na arquitetura corporativa reforçada, a Contoso implementou uma arquitetura de medallion lakehouse que dá suporte às necessidades de dados analíticos corporativos e permite que os usuários corporativos usem um modelo de domínio. Conforme a Contoso continua sua expansão global, o departamento financeiro usou o Azure Machine Learning para criar um modelo de fraude de negócios. Esse modelo agora precisa de mais refinamento para funcionar como um serviço operacional de missão crítica.
Há vários requisitos importantes para fornecer uma solução analítica avançada de missão crítica usando o Data Factory:
O modelo de machine learning deve ser projetado como um serviço operacional de missão crítica que está disponível globalmente para os vários sistemas operacionais de negócios.
Os resultados do modelo de machine learning e as métricas de desempenho devem estar disponíveis para retreinamento e auditoria.
As trilhas de auditoria do modelo de machine learning devem ser mantidas por 10 anos.
O modelo de machine learning atualmente tem como alvo os EUA, a Europa e a América do Sul, com planos de expansão para a Ásia no futuro. A solução deve aderir aos requisitos de conformidade de dados, como o Regulamento Geral de Proteção de Dados para países ou regiões europeias.
Espera-se que o modelo de machine learning ofereça suporte a até 1.000 usuários simultâneos em qualquer região durante o horário comercial de pico. Para minimizar os custos, o processamento de machine learning deve ser reduzido quando não estiver em uso.
Um requisito não justifica o custo e a complexidade de redesenhar a plataforma para atender às especificações de missão crítica. Em vez disso, o modelo de machine learning deve ser conteinerizado e, em seguida, implantado em uma solução de missão crítica. Essa abordagem minimiza o custo e a complexidade isolando o serviço modelo e aderindo à orientação de missão crítica. Esse design requer que o modelo seja desenvolvido na plataforma e, em seguida, conteinerizado para implantação.
Depois que o modelo é conteinerizado, ele pode ser atendido por meio de uma API usando uma arquitetura de unidade de escala nas regiões do Azure dos EUA, da Europa e da América do Sul. Somente regiões emparelhadas que têm zonas de disponibilidade estão no escopo, o que dá suporte a requisitos de redundância.
Devido à simplicidade de um único serviço de API, recomendamos que você use o recurso de aplicativo Web para contêineres para hospedar o aplicativo. Esse recurso fornece simplicidade. Você também pode usar o Serviço Azure Kubernetes (AKS), que fornece mais controle, mas aumenta a complexidade.
O modelo é implantado por meio de uma estrutura MLOps. O Data Factory é usado para mover dados para dentro e para fora da implementação crítica.
Para fazer a conteinerização, você precisa:
Um front-end de API para veicular os resultados do modelo.
Para descarregar métricas de auditoria e desempenho para uma conta de armazenamento, que pode ser transferida de volta para a plataforma principal por meio do Data Factory usando um trabalho agendado.
Pipelines de implantação e reversão, que permitem que cada implantação regional seja sincronizada com a versão atual correta do modelo.
Modelagem de integridade do serviço para medir e gerenciar a integridade geral de uma carga de trabalho.
As trilhas de auditoria podem ser armazenadas inicialmente em um workspace de análise de logs para análise em tempo real e suporte operacional. Após 30 dias ou 90 dias se estiver usando o Microsoft Sentinel, as trilhas de auditoria podem ser transferidas automaticamente para o Azure Data Explorer para retenção de longo prazo. Essa abordagem permite consultas interativas de até dois anos no workspace de análise de logs e a capacidade de manter dados mais antigos e usados com pouca frequência a um custo reduzido por até 12 anos. Use o Azure Data Explorer para o armazenamento de dados para executar consultas multiplataformas, e visualize dados no Azure Data Explorer e no Microsoft Azure Sentinel. Essa abordagem fornece uma solução econômica para satisfazer os requisitos de armazenamento de longo prazo, mantendo a opcionalidade do suporte. Se não houver necessidade de manter dados excessivos, considere excluí-los.
O fluxo de dados a seguir corresponde ao diagrama anterior:
O modelo de machine learning é desenvolvido na plataforma de dados. Essa alteração de design requer as seguintes atualizações na arquitetura:
O Registro de Contêiner do Azure permite a compilação, o armazenamento e o gerenciamento de imagens e artefatos de contêiner do Docker em um registro privado que dá suporte à implantação do modelo de machine learning.
O recurso de aplicativo Web para contêineres permite as atividades de integração e implantação contínuas necessárias para fornecer as saídas do modelo de machine learning como um serviço de API.
O Data Factory permite a migração de todos os dados exigidos pelo modelo para execução e permite a ingestão de métricas de desempenho e saída do modelo da implementação crítica.
A estrutura de diretório da camada de bronze do data lake (ou da camada bruta) armazena a saída do modelo e as métricas de desempenho usando a camada de arquivos para satisfazer o requisito de retenção de dados.
O Azure DevOps orquestra a implantação da base de código do modelo e a criação e desativação de implantações regionais para todos os serviços de suporte.
O modelo de machine learning é implantado como uma carga de trabalho crítica dedicada em sua própria assinatura definida. Essa abordagem garante que o modelo evite quaisquer limites de componente ou limite de serviço que a plataforma possa impor.
Um conjunto de recursos compartilhados abrange toda a solução e, portanto, são definidos como globais:
O Registro de Contêiner permite a distribuição da versão atual do modelo de machine learning entre as implantações regionais.
O Azure Front Door fornece serviços de balanceamento de carga para distribuir o tráfego entre implantações regionais.
Uma funcionalidade de monitoramento usa o Log Analytics e o Azure Data Lake Storage.
O carimbo de implantação regional é um conjunto de componentes de solução que você pode implantar em qualquer região de destino. Essa abordagem fornece escala, resiliência de serviço e serviço específico regional.
Dependendo da natureza do modelo de machine learning, pode haver requisitos regionais de conformidade de dados que exigem que o modelo de machine learning cumpra os regulamentos de soberania. Este design suporta esses requisitos.
Cada implantação regional vem com sua própria pilha de monitoramento e armazenamento, que fornece isolamento do restante da solução.
A unidade de escala da solução tem os seguintes componentes:
O recurso de aplicativo Web para contêineres hospeda o modelo de machine learning e veicula as saídas. Como o componente de serviço principal nesta solução, você deve considerar os limites de escala do aplicativo Web para contêineres como as principais restrições. Se esses limites não derem suporte aos requisitos de soluções, considere usar o AKS.
O Azure Key Vault impõe controles apropriados sobre segredos, certificados e chaves no escopo regional, protegidos por meio do Link Privado do Azure.
O Data Lake Storage fornece armazenamento de dados, que é protegido por meio do Link Privado.
O DNS do Azure fornece resolução de nomes que permite a resiliência do serviço e simplifica o balanceamento de carga em toda a solução.
Para facilitar o suporte e a solução de problemas da solução, os seguintes componentes também estão incluídos:
O Azure Bastion fornece uma conexão segura para jump hosts sem exigir um endereço IP público.
As Máquinas Virtuais do Azure atuam como um jump host para a solução, o que permite uma melhor postura de segurança.
Os agentes de build auto-hospedados fornecem escala e desempenho para dar suporte a implantações de solução.
Baixe um Arquivo Visio dessa arquitetura.
Você deve usar um firewall de última geração, como o Firewall do Azure, para proteger a conectividade de rede entre sua infraestrutura local e sua rede virtual do Azure.
Você pode implantar um runtime de integração auto-hospedada (SHIR) em uma máquina virtual (VM) em seu ambiente local ou no Azure. Considere implantar a VM no Azure como parte da zona de destino do recurso de suporte compartilhado para simplificar a governança e a segurança. Você pode usar o SHIR para se conectar com segurança a fontes de dados locais e executar tarefas de integração de dados no Data Factory.
A rotulagem de dados assistida por machine learning não dá suporte a contas de armazenamento padrão porque elas são protegidas por trás de uma rede virtual. Primeiro, crie uma conta de armazenamento para rotulagem de dados assistida por machine learning. Em seguida, aplique o rótulo e proteja-o atrás da rede virtual.
Os pontos de extremidade privados fornecem um endereço IP privado da sua rede virtual para um serviço do Azure. Esse processo coloca efetivamente o serviço na rede virtual. Essa funcionalidade torna o serviço acessível apenas de sua rede virtual ou de redes conectadas, o que garante uma conexão mais segura e privada. Os pontos de extremidade privados usam o Link Privado, que protege a conexão com a solução de plataforma como serviço (PaaS). Se sua carga de trabalho usar recursos que não dão suporte a pontos de extremidade privados, você poderá usar pontos de extremidade de serviço. Recomendamos que você use pontos de extremidade privados para cargas de trabalho críticas sempre que possível.
Para obter mais informações, confira Rede e conectividade.
Importante
Determine se o caso de uso está operacional, como este cenário, ou se está relacionado à plataforma de dados. Se o seu caso de uso incluir a plataforma de dados, como ciência de dados ou análise, ele pode não se qualificar como crítico. As cargas de trabalho de missão crítica exigem recursos substanciais e só devem ser definidas como tal se justificarem o investimento em recursos.
Você pode usar o AKS para hospedar os contêineres. Para esse caso de uso, a carga de gerenciamento necessária para o AKS o torna uma opção menos ideal.
Você pode usar os Aplicativos de Contêiner do Azure em vez do recurso de aplicativos Web para contêineres. Atualmente, não há suporte para pontos de extremidade privados para Aplicativos de Contêiner, mas o serviço pode ser integrado a uma rede virtual existente ou nova.
Você pode usar o Gerenciador de Tráfego do Azure como uma alternativa de balanceamento de carga. O Azure Front Door é preferencial para esse cenário devido à funcionalidade extra disponível e a um desempenho de failover mais rápido.
Se o modelo exigir recursos de leitura e gravação como parte do processamento de dados, considere usar o Azure Cosmos DB.
Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.
A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.
Em comparação com a arquitetura de linha de base, essa arquitetura:
Alinha-se com a arquitetura de linha de base de missão crítica.
Segue as diretrizes das considerações de design de confiabilidade de missão crítica.
Implanta um modelo de integridade inicial para a solução para maximizar a confiabilidade.
A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.
Em comparação com a arquitetura de linha de base, essa arquitetura:
Segue as diretrizes das considerações de design de segurança de missão crítica.
Implementa as diretrizes de segurança da arquitetura de referência crítica.
A Otimização de Custos trata-se de procurar maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.
Projetos de missão crítica são caros, o que torna importante a implementação de controles. Alguns controles incluem:
Alinhar a seleção de SKU do componente aos limites da unidade de escala da solução para evitar o superprovisionamento.
Benefícios de economia de despesas operacionais disponíveis e práticos, como reservas do Azure para cargas de trabalho estáveis, planos de economia para cargas de trabalho dinâmicas e níveis de compromisso de análise de logs.
Alertas de custo e orçamento por meio do Gerenciamento de Custos da Microsoft.
A Excelência Operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução em produção. Para obter mais informações, consulte Lista de verificação de revisão de design para Excelência Operacional.
Em comparação com a arquitetura de linha de base, essa arquitetura:
Segue as orientações das considerações de design de excelência operacional de missão crítica.
Separa os recursos de monitoramento global e regional para evitar uma falha de ponto único na observabilidade.
Implementa a orientação de implantação e teste e os procedimentos operacionais da arquitetura de referência de missão crítica.
Alinha a solução com roteiros de engenharia do Azure e distribuições regionais para levar em conta os serviços em constante evolução no Azure.
A Eficiência de Desempenho é a capacidade da carga de trabalho de atender às demandas colocadas nele pelos usuários de maneira eficiente. Para obter mais informações, consulte Lista de verificação de revisão de design para eficiência de desempenho.
Em comparação com a arquitetura de linha de base, essa arquitetura:
Segue as diretrizes das considerações de design de eficiência de desempenho crítico.
Conclui uma avaliação do Well-Architected para cargas de trabalho críticas para fornecer uma linha de base de prontidão para a solução. Revise regularmente essa avaliação como parte de um ciclo proativo de medição e gerenciamento.
A abordagem da lista de compras: as partes interessadas da empresa geralmente recebem uma lista de compras de recursos e níveis de serviço, sem o contexto de custo ou complexidade. É importante garantir que qualquer solução seja baseada em requisitos validados e que o design da solução seja suportado por modelagem financeira com opções. Essa abordagem permite que as partes interessadas tomem decisões informadas e mudem, se necessário.
Não desafiar os requisitos: projetos de missão crítica podem ser caros e complexos de implementar e manter. As partes interessadas da empresa devem ser questionadas sobre os requisitos para garantir que a "missão crítica" seja realmente necessária.
Implantar e esquecer: o modelo é implantado sem monitoramento contínuo, atualizações ou mecanismos de suporte em vigor. Depois que o modelo é implantado, ele requer pouca ou nenhuma manutenção contínua e é deixado para operar isoladamente. Essa negligência pode levar a degradação do desempenho, descompasso na precisão do modelo e vulnerabilidades a padrões de dados emergentes. Em última análise, a negligência prejudica a confiabilidade e a eficácia do modelo em servir ao propósito pretendido.