Neste artigo, discutiremos as considerações de arquitetura do Azure relacionadas à análise e à implementação de controles de ISRM (gerenciamento de riscos de segurança da informação) para a classificação comum de camadas de alto risco.
Arquitetura
A arquitetura é mostrada neste diagrama e segue o princípio de zonas de destino em escala empresarial, especificamente a arquitetura de referência de IA e de análise em escala empresarial.
Baixe um Arquivo Visio dessa arquitetura.
Workflow
A arquitetura consiste no fluxo de trabalho descrito nas seções a seguir. Cada componente da arquitetura tem um número correspondente no diagrama. Descrevemos o objetivo principal do componente, como ele se encaixa na arquitetura e outras considerações importantes que você deva levar em conta ao adotá-la:
- Assinatura da plataforma: principais assinaturas do Azure que fornecem gerenciamento, conectividade e identidade por meio do Microsoft Entra ID. Elas não são descritas aqui com mais detalhes e espera-se que estejam prontas e disponíveis como parte da configuração principal em escala empresarial.
Gerenciamento de dados
- Zona de gerenciamento de dados: a zona de gerenciamento de dados é responsável pela governança de dados em toda a plataforma, aplica proteções para fornecer mais flexibilidade de downstream nas zonas de destino de dados. Conta com assinatura própria e hospeda serviços centralizados, como catalogação de dados, monitoramento, auditorias e assim por diante. Este ambiente é altamente controlado e sujeito a auditorias rigorosas. Todos os tipos de classificação de dados são armazenados no catálogo de dados central (Azure Purview). Dependendo dos metadados, diferentes políticas e padrões de acesso são aplicados. Há somente uma assinatura de zona de gerenciamento de dados para o locatário. A zona de gerenciamento de dados é emparelhada (por meio do emparelhamento VNET) com todas as outras zonas de destino de dados. Os pontos de extremidade privados são usados sempre que possível para garantir que os serviços implantados não sejam acessíveis pela Internet pública.
- Grupo de recursos de rede: redes virtuais do Azure, grupos de segurança de rede e todos os outros recursos relacionados à rede necessários para a zona de gerenciamento de dados são provisionados no grupo de recursos de rede.
- Grupo de recursos de implantação: um grupo de recursos de implantação hospeda os agentes de CI/CD privados do Azure DevOps (máquinas virtuais) necessários para a zona de gerenciamento de dados e um Key Vault para armazenar quaisquer segredos relacionados à implantação.
- Grupo de recursos de governança de dados: o Azure Purview é usado como uma solução de governança e de catálogo de dados para aplicar as proteções necessárias para que os conjuntos de dados sigam os requisitos e os regulamentos de dados impostos pela lei ou por outras entidades. Ele é hospedado centralmente nesse grupo de recursos com uma instância do Key Vault para armazenar segredos.
- Ativos centralizados: os ativos centralizados hospedam ativos importantes e valiosos que são essenciais para a plataforma, como os seguintes:
- Registros de Contêiner do Azure que hospedam imagens de base usadas em produtos de dados baseados no Azure Machine Learning (imagens verificadas anteriormente e livres de vulnerabilidades)
- Modelos de Machine Learning/IA que são publicados e disponibilizados aos consumidores na plataforma (para implantação em uma ou mais zonas de destino de dados, se necessário).
- Serviços adicionais: quaisquer outros serviços que devam ser centralizados podem ser hospedados em um desses grupos de recursos, que podem incluir instâncias centralizadas de Gerenciamento de API do Azure, softwares de terceiros e assim por diante.
- Grupo de recursos de visualização de dados: esse grupo de recursos hospeda soluções de visualização de dados compartilhadas nas zonas de destino de dados. As soluções podem consistir no Power BI, no Tableau ou em qualquer outra solução de visualização.
- Governança e controles de infraestrutura adicionais: o Microsoft Defender para Nuvem e o Azure Monitor são usados como soluções de monitoramento e de segurança de linha de base.
Zonas de destino de dados
Zona de destino de dados 001: uma zona de destino de dados é uma assinatura que representa uma unidade de escala dentro da plataforma de dados. As zonas de destino de dados são implantadas com base na arquitetura principal de zona de destino de dados (blueprint), incluindo todos os principais recursos para hospedar uma plataforma de análises e IA. Pode haver uma ou diversas zonas de destino de dados no ambiente. O Azure Policy é aplicado para manter a segurança do acesso e das configurações de diversos serviços do Azure. A zona de destino de dados é emparelhada (por meio do emparelhamento VNET) com todas as outras zonas de gerenciamento e de destino de dados. Os pontos de extremidade privados são usados sempre que possível para garantir que os serviços implantados não sejam acessíveis pela Internet pública.
Grupo de recursos de rede: as Redes Virtuais do Azure, grupos de segurança de rede e todos os outros recursos relacionados à rede necessários para a zona de destino de dados são provisionados nesse grupo de recursos.
Grupo de recursos de implantação: um grupo de recursos de implantação hospeda os agentes de CI/CD privados do Azure DevOps (máquinas virtuais) necessários para a zona de destino de dados e um Key Vault para armazenar quaisquer segredos relacionados à implantação.
Grupo de recursos de armazenamento de dados: um grupo de recursos de armazenamento de dados contém as principais contas de armazenamento de dados para essa zona de destino de dados, implantada como Azure Data Lake Storage Gen2, com o namespace hierárquico. Elas são distribuídas em três áreas principais:
- Bruto: onde os dados são ingeridos da fonte de dados no estado original
- Organizado e Enriquecido: ocorre a limpeza, a validação e a agregação dos dados
- Espaço de trabalho: produtos de dados específicos podem armazenar seus conjuntos de dados ou as saídas dos modelos de Machine Learning e assim por diante
As setas nos diagramas mostram o fluxo de dados esperado, que vai dos dados brutos para os dados organizados e enriquecidos (confiáveis) e, em seguida, para o espaço de trabalho para exploração, análise e fornecimento de valor extra do produto de dados.
Grupo de recursos de integração de dados: o grupo de recursos de integração de dados hospeda um Azure Data Factory que compartilha a conectividade com o SHIR (runtime de integração auto-hospedada) local. Seu principal objetivo é estabelecer a conectividade. Outras instâncias do Data Factory o reutilizam para que essa conectividade seja mantida somente em um local. Ele também hospeda o runtime de integração auto-hospedada para que o serviço Azure Purview possa acessar as fontes de dados nessa zona de destino de dados, para fins de verificação.
Grupo de recursos de gerenciamento de metadados: o grupo de recursos de gerenciamento de metadados hospeda metadados para o Azure Databricks (o metastore do Hive) e os pipelines de ingestão e processamento do Azure Data Factory. Também hospeda um Key Vault para armazenar segredos de acesso a esses dados. O Banco de Dados SQL do Azure é usado para hospedar os metadados.
Grupo de recursos de ingestão de dados: o grupo de recursos de ingestão de dados hospeda uma instância do Azure Data Factory em que estão implantados todos os pipelines de ingestão de dados específicos para um domínio de dados. O Azure Databricks é usado como um mecanismo de processamento para carregar e transformar os dados e armazená-los nas contas do data lake.
Grupo de recursos de análise: o grupo de recursos de análise inclui dois serviços compartilhados para análise e exploração de dados adicionais: Azure Synapse e Azure Databricks. Ambos fornecem computação e escala extensas para fins de análise e exploração de dados em massa.
Grupo de recursos de produto de dados: o grupo de recursos de produto de dados é um blueprint para um produto de dados, com um grupo de recursos que contém recursos básicos do Azure que podem ser necessários para um produto de dados. A implantação deve ser configurável por meio de um pipeline do Azure DevOps baseado nas necessidades específicas do negócio. Os principais serviços do Azure implantados aqui são os seguintes:
- Espaço de trabalho do Azure Machine Learning como base para qualquer projeto de aprendizado de máquina empresarial com serviços relacionados, como o Key Vault (para armazenar segredos)
- Application Insights (para o monitoramento de modelos)
- Armazenamento do Azure (para o armazenamento de conjuntos de dados)
- Um Registro de Contêiner do Azure para armazenar imagens de modelo durante o desenvolvimento
Os Serviços Cognitivos são implantados como um pacote para fornecer acesso de API a diversos serviços com suporte de IA, e a instância de computação do Azure Machine Learning e os clusters de computação são usados para fins de desenvolvimento, criação de modelos e testes. O Azure Data Factory é usado para orquestrar a pontuação em lote dos modelos, se necessário. O Serviço de Aplicativo do Azure e o Azure Cosmos DB fornecem uma camada extra para a implantação do produto de dados, em que uma API ou um aplicativo personalizado pode ser hospedado com o próprio armazenamento de dados interno.
Os setores regulamentados geralmente têm restrições de acesso a dados rígidas e só permitem a hospedagem dos dados de produção no ambiente de produção. Por isso, o ciclo de vida de desenvolvimento de produtos de dados ocorre apenas na zona de destino de dados de produção e um ambiente separado, ou grupo de recursos, é provisionado para fins de desenvolvimento, teste e implantação.
Produtos de dados adicionais: esses grupos de recursos hospedam outros produtos de dados, pois uma zona de destino de dados pode hospedar um ou mais produtos de dados.
Grupo de recursos de computação compartilhada: qualquer computação compartilhada necessária para hospedar e implantar produtos de dados é provisionada nesse grupo de recursos. Um cluster do Serviço de Kubernetes do Azure é um exemplo.
Governança e controles de infraestrutura adicionais: o Microsoft Defender para Nuvem e o Azure Monitor são usados como soluções de monitoramento e de segurança de linha de base.
Zonas de destino de dados 002: essa zona de destino é um espaço reservado para assinaturas extras do Azure que podem ser usadas para hospedar novas zonas de destino de dados. Elas são baseadas em critérios mencionados anteriormente, como requisitos de residência de dados ou uma unidade de negócios diferente que tenha a própria equipe multifuncional e um conjunto de casos de uso a serem entregues.
Componentes
- Microsoft Entra ID
- Azure Purview
- Rede Virtual do Azure
- Azure DevOps
- Registro de Contêiner do Azure
- Azure Machine Learning
- Microsoft Defender para Nuvem
- Azure Monitor
- Azure Policy
- Armazenamento do Azure Data Lake
- Azure Data Factory
- Banco de Dados SQL do Azure
- Azure Databricks
- Azure Synapse Analytics
- Serviço de Kubernetes do Azure
Alternativas
Em organizações distribuídas, os grupos empresariais operam de forma independente e com alto grau de autonomia. Devido a isso, eles podem considerar um design de solução alternativo, com o isolamento total dos casos de uso nas zonas de destino do Azure, compartilhando um conjunto mínimo de serviços comuns. Embora esse design permita um início rápido, ele exige um alto esforço das organizações de TI e ISRM, pois o design de casos de uso individuais pode divergir rapidamente dos designs do blueprint. Além disso, ele exige auditorias e processos de ISRM independentes para cada um dos produtos de IA e Machine Learning hospedados no Azure.
Detalhes do cenário
O dimensionamento de iniciativas de IA e de aprendizado de máquina em ambientes regulamentados apresenta desafios significativos às organizações, independentemente de sua maturidade digital e de seu tamanho. Neste artigo, discutiremos as principais decisões arquitetônicas a serem consideradas ao adotar os serviços de engenharia de dados e de aprendizado de máquina do Azure em setores regulamentados. Essas decisões são baseadas no que foi aprendido com uma implementação recente em uma empresa global de ciências da vida e saúde da Fortune 500.
A arquitetura aqui apresentada segue o design de arquitetura de referência de IA e de análise em escala empresarial e foi uma de suas primeiras implementações.
Se você organiza projetos de ciência de dados e desenvolve de modelos de machine learning em ambientes de ciências da vida e saúde, em quase todos os casos, precisa de acesso a fontes de dados de HBI (alto impacto nos negócios). Por exemplo, essas fontes podem consistir em informações de protocolos de ensaios clínicos sem dados de pacientes, fórmulas químicas de moléculas ou segredos de processos de fabricação.
Em setores regulamentados, os sistemas de TI são classificados com base na classificação das fontes de dados que eles acessam. Os ambientes de IA e de aprendizado de máquina executados no Azure são classificados como HBI e precisam estar em conformidade com um amplo conjunto de políticas e controles de ISRM.
Princípios de design
Essa arquitetura é baseada nos seguintes princípios:
- A escala empresarial é uma abordagem arquitetônica e uma implementação de referência alinhada com o roteiro do Azure e parte do CAF (Cloud Adoption Framework) da Microsoft. Ela permite a construção e a operacionalização eficazes de zonas de destino no Azure em escala. O nome zona de destino é usado como um limite no qual aplicativos novos ou migrados chegam ao Azure. Nesse cenário, também se refere a partes da plataforma de dados que são usadas para hospedar os dados e os modelos de Machine Learning e IA.
- As arquiteturas de plataforma de dados monolíticas tradicionais têm uma limitação inerente que atrasa a entrega de recursos e valores. A arquitetura descrita aqui permite que as organizações dimensionem seu patrimônio de dados e resolvam os desafios de um data lake monolítico centralizado através de uma abordagem descentralizada com separação de propriedade (malha de dados). A abordagem permite que as organizações façam o dimensionamento para milhares de pipelines de ingestão e produtos de dados, mantendo a plataforma de dados segura e sustentável por meio do desacoplamento da plataforma de dados principal e dos serviços de gerenciamento de dados (implantados em uma zona de destino separada chamada "zona de gerenciamento de dados") de domínios de dados e produtos de dados (implantados em uma ou mais zonas de destino de dados).
- As assinaturas são usadas como unidades de gerenciamento e têm a escala alinhada às necessidades e prioridades do negócio. A colocação em escala é feita fornecendo novas assinaturas (zonas de destino de dados) a unidades de negócios com base em critérios como diferentes partes interessadas de negócios, diferentes objetivos e requisitos de negócios e requisitos de residência de dados (em que os dados precisam estar em uma região geográfica específica).
- O Azure Policy é usado para fornecer proteções e garantir a conformidade contínua no cenário de TI da empresa.
- Um plano único de controle e gerenciamento (por meio do portal do Azure) fornece uma experiência consistente em todos os recursos do Azure e canais de provisionamento sujeitos ao acesso baseado em função e a controles orientados por políticas. Os serviços e recursos da plataforma nativa do Azure são usados sempre que possível.
- Equipes multifuncionais se apropriam do design, do desenvolvimento e das operações para reduzir o tempo de lançamento no mercado e o tempo até obter agilidade na plataforma. Princípios fundamentais como DevOps, IaC (Infraestrutura como Código) e designs resilientes são usados para evitar erros humanos e pontos únicos de falha.
- Especialistas no assunto de domínios e fontes de dados podem usar domínios de dados para extrair ativos de dados de ambientes do Azure, de terceiros ou locais. Um domínio de dados é um grupo de recursos em uma zona de destino de dados que equipes multifuncionais podem usar para uma ingestão de dados personalizada. Pode haver um ou mais domínios de dados em uma zona de destino de dados. Os domínios de dados podem ser exibidos de maneira semelhante aos domínios no Domain-Driven Design, onde eles fornecem um limite de contexto e são autossuficientes e isolados. Um exemplo de domínio de dados seriam os dados de ensaios clínicos ou da cadeia de suprimentos.
Possíveis casos de uso
As considerações arquitetônicas discutidas neste artigo têm sua origem nos setores de ciências da vida e saúde. No entanto, também são relevantes para organizações em outros setores regulamentados, como os seguintes:
- Serviços financeiros
- Provedores de saúde
- Óleo e gás
A implementação da arquitetura de referência de IA e de análise em escala empresarial em ambientes regulamentados segue padrões de design semelhantes.
Considerações
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, confira Microsoft Azure Well-Architected Framework.
Nesta seção, discutiremos as lições aprendidas com a implementação da arquitetura descrita anteriormente em um ambiente regulamentado de ciências da vida e saúde. Também abordaremos considerações de design de alto nível para atender a controles e políticas de ISRM comuns.
Segurança
A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.
Ambientes
Em ambientes regulamentados, os sistemas de TI classificados como HBI precisam ter diversos ambientes segregados, como desenvolvimento, qualidade e produção, ou similares. O acesso a fontes de dados protegidas só é autorizado em ambientes certificados para produção.
Como o desenvolvimento de IA e de machine learning necessita de acesso a conjuntos de dados confidenciais, os diferentes estágios do processo de operações de machine learning, como criação de modelo, treinamento e inferência (ou similares), ocorrem na produção. Ambientes de desenvolvimento e de qualidade normalmente são restritos ao tipo de trabalho de infraestrutura, operações e engenharia de dados, a fim de garantir aprimoramentos contínuos à medida que novos serviços e recursos do Azure são disponibilizados.
As atividades de desenvolvimento de IA e de ciência de dados devem ser realizadas em ambientes de produção, com exceção da área restrita ou de um trabalho exploratório inicial.
Criptografia
Os sistemas de TI que acessam, armazenam e processam dados empresariais confidenciais devem implementar requisitos específicos com relação ao gerenciamento de chaves de criptografia, como políticas FIPS 140-2 de nível 2 ou 3, com a integração de CMKs (chaves gerenciadas pelo cliente). Os dados protegidos devem sempre ser criptografados em repouso e em trânsito com protocolos TLS 1.2 ou superior.
Durante o design de arquitetura, é necessária uma análise cuidadosa do suporte e da integração dos serviços do Azure com a infraestrutura de CMK de uma organização. Quaisquer exceções à criptografia de dados devem ser documentadas. O suporte a fornecedores de HSMs (módulos de segurança de hardware) é sempre expandido e informações adicionais podem ser encontradas em Módulo de segurança de hardware gerenciado do Azure Key Vault.
Design de rede e ring-fencing
Os ambientes de Machine Learning e IA devem ter ring-fencing em vigor, com segmentação de rede e controles de acesso à rede implementados. A comunicação de rede entre os componentes da arquitetura é limitada aos fluxos de dados necessários e à infraestrutura subjacente para funcionar em uma abordagem de lista de permissões. Devem ser aplicadas análises baseadas em assinatura e em comportamento.
Aplique controles de acesso à rede a diversas camadas da arquitetura, incluindo Firewalls do Azure, inspecionando a conectividade de rede de entrada e de saída, os grupos de segurança de rede e o acesso ao ponto de extremidade do aplicativo Web protegido com WAF (firewall de aplicativo Web).
Gerenciamento de autorização
Os ambientes de IA e de aprendizado de máquina executados no Azure devem ser integrados ao sistema de provisionamento de conta principal de uma organização, onde as solicitações de concessão de acesso a aplicativos de negócios críticos são enviadas, aprovadas e auditadas.
Espera-se que os sistemas de provisionamento de contas se conectem ao Active Directory de uma organização e ao Microsoft Entra ID para que as funções de autorização de negócios sejam mapeadas para os grupos de segurança correspondentes do Active Directory e do Microsoft Entra ID.
Os ambientes de IA e machine learning seguem um modelo de controle de acesso baseado em funções. As autorizações de controle de nível de acesso garantem que os usuários só possam executar as tarefas e ações de acordo com suas funções de trabalho e aos seus requisitos de negócios. Espera-se que os casos de uso de aprendizado de máquina sejam altamente segregados, pois os cientistas de dados que trabalham em um caso de uso específico só podem acessar a parte dos recursos relacionada a esse caso de uso, seguindo um princípio de privilégio mínimo. Esses recursos podem incluir o seguinte:
- Contas de armazenamento
- Workspaces do Azure Machine Learning
- Instâncias de computação
O controle de acesso baseado em função usa grupos de segurança no Microsoft Entra ID.
Autenticação multifator
A autenticação multifator deve estar em vigor e implementada para o acesso a todos os ambientes executados no Azure e classificados como de alto impacto nos negócios. A autenticação multifator pode ser imposta usando os serviços de autenticação multifator do Microsoft Entra. Os pontos de extremidade de aplicativos (incluindo o Azure DevOps, o Portal de Gerenciamento do Azure, o Azure Machine Learning, o Azure Databricks e o Azure Kubernetes Services) devem ser configurados nas políticas de controle de acesso de autenticação multifator.
A autenticação multifator deve ser aplicada a todos os usuários, incluindo gerentes de serviço, engenheiros de dados e cientistas de dados do Azure.
Excelência operacional
A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, confira Visão geral do pilar de excelência operacional.
Log e monitoramento
Todos os serviços do Azure devem ingerir os próprios eventos de segurança na plataforma do SOC (Centro de Operações de Segurança) de uma organização e os seguintes eventos de segurança devem ser registrados:
- Tentativas de autenticação bem-sucedidas e com falha
- Acesso a dados confidenciais
- Alterações na política de segurança
- Alterações em grupos de usuários administradores, usuários ou funções
- Transferências de dados confidenciais para locais externos, se aplicável
- Ativação e desativação de sistemas de proteção, como controles de acesso baseado em atributos (ABAC)
- Acesso atualizado aos logs e interrupção do registro em log
Os logs de segurança do Azure podem ser ingeridos no SOC por meio de diferentes padrões:
- Um workspace central do Azure Log Analytics
- Um hub de eventos conectado a sistemas de plataforma SOC, como o Splunk
- Uma VM do Windows e outros recursos de computação implantados com agentes do SOC
DevOps
Em ambientes regulamentados, os sistemas de TI devem seguir processos de controle de qualidade rigorosos no estilo cascata, com aprovações formais (ou portas) entre as fases do processo, (como especificações de requisitos do usuário, especificações funcionais, design e especificações de teste, ou similares), com documentação de apoio extensa e dispendiosa.
Os ambientes do Azure e o desenvolvimento de ciência de dados seguem processos iterativos baseados em uma cultura de DevOps. É necessário um esforço significativo ao escalar as iniciativas de IA e machine learning, comunicando os pilares de uma organização de DevOps e criando um mapeamento automatizado de rastreabilidade completa entre épicos, recursos, histórias de usuários, planos de teste e pipelines de CI/CD do Azure DevOps, além das evidências e entidades de controle de qualidade necessárias.
Eficiência de desempenho
A eficiência do desempenho é a capacidade de dimensionar sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Para saber mais, confira Visão geral do pilar de eficiência de desempenho.
Para dimensionar a IA e o aprendizado de máquina em ambientes regulamentados e impulsionar a rápida adoção nas áreas de negócios da organização, recomendamos criar e implementar uma estrutura de adoção para medir, monitorar e avaliar o valor criado pelos serviços do Azure. Com base em nosso exemplo do setor de ciências da vida e saúde, as seguintes alavancas de valor comercial e KPIs (indicadores-chave de desempenho) foram avaliados:
Escalabilidade: para garantir que a arquitetura do Azure possa ser dimensionada de acordo com os requisitos de negócios, independentemente do ponto de escala, são sugeridos os seguintes KPIs:
- Número de instâncias de computação e uso de armazenamento total e de memória
- Número de experimentos executados
- Número de modelos implantados
Aceleração do desenvolvimento de IA: para acelerar o desenvolvimento de soluções de IA e machine learning, são sugeridos os seguintes KPIs:
- Número de diferentes unidades de negócios que consomem os serviços de IA e machine learning do Azure
- Número de usuários integrados por categoria, por exemplo, engenheiros de dados, cientistas de dados, cientistas de dados cidadãos e usuários de negócios
- Número de experimentos executados
- Tempo entre a integração de usuários e o uso ativo
- Tempo de provisionamento de serviços: desde a solicitação de alteração de configuração até a conclusão do provisionamento do serviço
Conformidade: para garantir a conformidade contínua das soluções de IA e machine learning implantadas, são sugeridos os seguintes KPIs:
- Conformidade geral com os controles de ISRM aplicáveis
- Número de avisos de vulnerabilidade de segurança
- Número de incidentes de segurança no último período
Experiência do usuário: para garantir a disponibilização de experiências de usuário consistentes e de alta qualidade, são sugeridos os seguintes KPIs:
- Número de solicitações de suporte técnico do usuário
- Net Promoter Score (NPS)
Bases seguras: para garantir que bases seguras e protegidas estejam em vigor, são sugeridos os seguintes KPIs:
- Tempo de atividade de serviços críticos
- Número de incidentes relatados com relação à disponibilidade de desempenho
Otimização de custo
A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.
O gerenciamento de custos é uma parte importante do design na implementação de plataformas de IA e machine learning escaláveis, pois os custos operacionais não seguem padrões simples e previsíveis. O custo é impulsionado principalmente pelo número e o tamanho dos experimentos de IA e machine learning sendo executados na plataforma e, mais especificamente, pelo número e pelos SKUs dos recursos de computação usados no treinamento e na inferência de modelos.
Veja algumas práticas que recomendamos:
- Atribuia a cada caso de uso e produto de IA e machine learning seu próprio orçamento de serviços do Azure, o que contribui para uma boa prática de gerenciamento de custos.
- Estabelecer um modelo de custo transparente para serviços de plataforma compartilhados.
- Use tags de forma consistente para associar recursos de caso de uso e produtos aos centros de custo.
- Use o Assistente do Azure e o Azure Budget para entender onde os recursos não estão sendo usados da maneira mais otimizada e revise as configurações regularmente.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- Eran Sagi | Arquiteto de soluções de IA
Próximas etapas
Saiba como treinar e implantar modelos e gerenciar o ciclo de vida de machine learning com o Azure Machine Learning. Tutoriais, exemplos de código, referências de API, entre outros tópicos, estão disponíveis aqui:
Saiba como implementar uma zona de destino de escala empresarial para análises de dados e IA no Azure:
Documentação do produto:
Recursos relacionados
Artigos de visão geral do Centro de Arquitetura do Azure: