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 orientações específicas sobre as alterações recomendadas necessárias para gerenciar uma carga de trabalho como uma operação de missão crítica.
Essa arquitetura está alinhada com a Estrutura de Adoção de Nuvem para práticas recomendadas e orientações do Azure e as recomendações para cargas de trabalho de missão crítica.
Criar uma arquitetura de missão crítica
Na arquitetura de linha de base, a Contoso opera um medalhão lakehouse que suporta suas 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 medallion lakehouse que suporta suas necessidades de dados analíticos corporativos e permite que os usuários corporativos usem um modelo de domínio. À medida que a Contoso continua sua expansão global, o departamento financeiro usou o Azure Machine Learning para criar um modelo de fraude de negócios. Este modelo precisa agora de mais aperfeiçoamento para funcionar como um serviço operacional de missão crítica.
Requisitos chave
Há vários requisitos principais para fornecer uma solução analítica avançada de missão crítica usando o Data Factory:
O modelo de aprendizado de máquina deve ser projetado como um serviço operacional de missão crítica que esteja disponível globalmente para os vários sistemas operacionais de negócios.
Os resultados do modelo de aprendizado de máquina e as métricas de desempenho devem estar disponíveis para retreinamento e auditoria.
As trilhas de auditoria do modelo de aprendizado de máquina devem ser mantidas por 10 anos.
O modelo de aprendizado de máquina atualmente tem como alvo os EUA, Europa e América do Sul, com planos de expansão para a Ásia no futuro. A solução deve cumprir os 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 aprendizado de máquina 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 aprendizado de máquina deve ser reduzido quando não estiver em uso.
Principais decisões de design
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 aprendizado de máquina 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 servido por meio de uma API usando uma arquitetura de unidade de escala nas regiões do Azure dos EUA, Europa e América do Sul. Apenas regiões emparelhadas que têm zonas de disponibilidade estão no escopo, o que suporta requisitos de redundância.
Devido à simplicidade de um único serviço de API, recomendamos que você use o recurso aplicativo Web para contêineres para hospedar o aplicativo. Este recurso proporciona simplicidade. Você também pode usar o Serviço Kubernetes do Azure (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 de missão crítica.
Para fazer a conteinerização, você precisa:
Um front-end de API para servir 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 inicialmente armazenadas em um espaço de trabalho do Log Analytics 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 espaço de trabalho do Log Analytics 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 armazenamento de dados para habilitar a execução de consultas entre plataformas e visualizar dados no Azure Data Explorer e no Microsoft Sentinel. Essa abordagem fornece uma solução econômica para atender aos requisitos de armazenamento de longo prazo, mantendo a opcionalidade do suporte. Se não houver nenhum requisito para manter dados excessivos, você deve considerar excluí-los.
Arquitetura
Fluxo de Trabalho
O fluxo de trabalho a seguir corresponde ao diagrama anterior:
O modelo de machine learning é desenvolvido na plataforma de dados. Esta alteração de design requer as seguintes atualizações para a 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 aprendizado de máquina.
O recurso aplicativo Web para contêineres permite a integração contínua e as atividades de implantação contínua necessárias para fornecer as saídas do modelo de aprendizado de máquina 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 saída e desempenho do modelo a partir da implementação de missão crítica.
A estrutura de diretórios da camada bronze do data lake (ou a camada bruta) armazena a saída do modelo e as métricas de desempenho usando a camada de arquivamento para atender ao 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 aprendizado de máquina é implantado como uma carga de trabalho dedicada de missão crítica dentro de sua própria assinatura definida. Essa abordagem garante que o modelo evite quaisquer limites de componentes ou limites de serviço que a plataforma possa impor.
Um conjunto de recursos compartilhados abrange toda a solução e, portanto, é definido como global:
O Registro de Contêiner permite a distribuição da versão atual do modelo de aprendizado de máquina 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.
Um recurso de monitoramento usa o Log Analytics e o Armazenamento Azure Data Lake.
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 aprendizado de máquina, pode haver requisitos regionais de conformidade de dados que exijam que o modelo de aprendizado de máquina cumpra as regulamentações 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 resto da solução.
A unidade de escala da solução tem os seguintes componentes:
O recurso aplicativo Web para contêineres hospeda o modelo de aprendizado de máquina e serve suas saídas. Como o componente de serviço principal nesta solução, você deve considerar os limites de escala para o aplicativo Web para contêineres como as principais restrições. Se esses limites não suportarem os requisitos das 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 Azure Private Link.
O Data Lake Storage fornece armazenamento de dados, que é protegido através do Private Link.
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 saltar hosts sem exigir um endereço IP público.
As Máquinas Virtuais do Azure atuam como um host de salto para a solução, o que permite uma melhor postura de segurança.
Os agentes de compilação auto-hospedados fornecem escala e desempenho para dar suporte a implantações de soluções.
Design de rede
Transfira um ficheiro do Visio desta arquitetura.
Você deve usar um firewall de próxima 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 tempo de execução de integração auto-hospedado (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 aterrissagem de recursos 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 aprendizado de máquina não suporta contas de armazenamento padrão porque elas estão protegidas por trás de uma rede virtual. Primeiro, crie uma conta de armazenamento para rotulagem de dados assistida por aprendizado de máquina. Em seguida, aplique a etiquetagem e proteja-a 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. Este processo traz efetivamente o serviço para a sua rede virtual. Esta funcionalidade torna o serviço acessível apenas a partir da sua rede virtual ou redes ligadas, o que garante uma ligação mais segura e privada. Os endpoints privados usam o Private Link, que protege a conexão com a solução de plataforma como serviço (PaaS). Se sua carga de trabalho usa recursos que não oferecem 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 de missão crítica sempre que possível.
Para obter mais informações, consulte Rede e conectividade.
Importante
Determine se seu 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 de missão crítica. 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.
Alternativas
Você pode usar o AKS para hospedar os contêineres. Para este 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 nova ou existente.
Você pode usar o Gerenciador de Tráfego do Azure como uma alternativa de balanceamento de carga. O Azure Front Door é preferido para este 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 de seu processamento de dados, considere usar o Azure Cosmos DB.
Considerações
Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Estrutura bem arquitetada.
Fiabilidade
A confiabilidade garante que seu aplicativo possa atender aos 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, esta arquitetura:
Alinha-se com a arquitetura de linha de base de missão crítica.
Segue as orientações das considerações de projeto de confiabilidade de missão crítica.
Implanta um modelo de integridade inicial para a solução para maximizar a confiabilidade.
Segurança
A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. 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, esta arquitetura:
Segue as orientações das considerações de design de segurança de missão crítica.
Implementa as diretrizes de segurança da arquitetura de referência de missão crítica.
Otimização de custos
A otimização de custos consiste em procurar formas 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 a implementação de controles importante. Alguns controlos incluem:
Alinhando a seleção de SKU do componente aos limites da unidade de escala da solução para evitar o provisionamento excessivo.
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 camadas de compromisso do Log Analytics.
Alertas de custos e orçamento através do Microsoft Cost Management.
Excelência operacional
A excelência operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na 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, esta 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 pontual na Observabilidade.
Implementa as diretrizes 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 implantações regionais para levar em conta os serviços em constante evolução no Azure.
Eficiência de desempenho
Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Lista de verificação de revisão de projeto para eficiência de desempenho.
Em comparação com a arquitetura de linha de base, esta arquitetura:
Segue as orientações das considerações de projeto de eficiência de desempenho de missão crítica.
Conclui uma avaliação bem arquitetada para cargas de trabalho de missão crítica para fornecer uma linha de base de prontidão para a solução. Reveja regularmente esta avaliação como parte de um ciclo proativo de medição e gestão.
Antipadrões
A abordagem da lista de compras: as partes interessadas do negócio geralmente são apresentadas a 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. Esta abordagem permite que as partes interessadas tomem decisões informadas e pivotem, se necessário.
Não desafiando os requisitos: projetos de missão crítica podem ser caros e complexos de implementar e manter. As partes interessadas do negócio devem ser questionadas sobre seus 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 à degradação do desempenho, desvio na precisão do modelo e vulnerabilidades aos padrões de dados emergentes. Em última análise, a negligência compromete a fiabilidade e a eficácia do modelo no cumprimento do fim a que se destina.