Ao servir modelos de aprendizado de máquina, o latência entre solicitar uma previsão e receber uma resposta é uma das métricas mais críticas para o usuário ultimate. A latência inclui o tempo que uma solicitação leva para chegar ao endpoint, ser processada pelo modelo e depois retornar ao usuário. Servir modelos para usuários baseados em uma região diferente pode aumentar significativamente os tempos de solicitação e resposta. Think about uma empresa com uma base de clientes multirregional que hospeda e atende um modelo em uma região diferente daquela onde seus clientes estão baseados. Esta dispersão geográfica incorre em custos de saída mais elevados quando os dados são movidos do armazenamento em nuvem e é menos segura em comparação com uma ligação peering entre duas redes virtuais.
Para ilustrar o impacto da latência entre regiões, uma solicitação da Europa para um endpoint de modelo implantado nos EUA pode adicionar 100-150 milissegundos de latência de rede. Por outro lado, uma solicitação baseada nos EUA pode adicionar apenas 50 milissegundos, com base nas informações extraídas deste Estatísticas de latência de ida e volta da rede Azure weblog.
Essa diferença pode impactar significativamente a experiência do usuário em aplicativos sensíveis à latência. Além disso, uma simples chamada de API geralmente envolve processos de rede adicionais — como chamadas para um banco de dados, serviços de autenticação ou outros microsserviços — que podem aumentar ainda mais a latência whole em 3 a 5 vezes. A implantação de modelos em diversas regiões garante que os usuários sejam atendidos a partir de endpoints mais próximos, reduzindo a latência e fornecendo respostas mais rápidas e confiáveis em todo o mundo.
Neste weblog, uma colaboração com Aimpoint Digitalexploramos como o Databricks oferece suporte à veiculação de modelos multirregionais com Compartilhamento Delta para ajudar a diminuir a latência em casos de uso de IA em tempo actual.
Abordagem
Para o serviço de modelo multirregional, os espaços de trabalho do Databricks em diferentes regiões são conectados usando o Delta Sharing para replicação perfeita de dados e objetos de IA da região primária para a região de réplica. O Delta Sharing oferece três métodos para compartilhar dados: o protocolo de compartilhamento Databricks-to-Databricks, o protocolo de compartilhamento aberto e implementações gerenciadas pelo cliente usando o servidor Delta Sharing de código aberto. Neste weblog, nos concentramos na primeira opção: compartilhamento de Databricks para Databricks. Este método permite o compartilhamento seguro de dados e ativos de IA entre dois espaços de trabalho do Databricks habilitados para o Unity Catalog, tornando-o perfect para compartilhar modelos entre regiões.
Na região primária, a equipe de ciência de dados pode desenvolver, testar e promover continuamente novos modelos ou versões atualizadas de modelos existentes, garantindo que atendam a padrões específicos de desempenho e qualidade. Com o Delta Sharing e o peering de VPC implementados, o modelo pode ser compartilhado com segurança entre regiões sem expor os dados ou modelos à Web pública. Esta configuração permite que outras regiões tenham acesso somente leitura, permitindo-lhes usar os modelos para inferência em lote ou implantar pontos finais regionais. O resultado é uma implantação de modelo multirregional que reduz a latência, proporcionando respostas mais rápidas aos usuários, independentemente de onde eles estejam localizados.
A arquitetura de referência acima ilustra que quando uma versão de modelo é registrada em um catálogo compartilhado na região principal (Região 1), ela é automaticamente compartilhada em segundos para uma região externa (Região 2) usando o Compartilhamento Delta por meio de peering de VPC.
Depois que os artefatos do modelo forem compartilhados entre regiões, o Pacote de ativos do Databricks (DAB) permite uma implantação contínua e consistente do fluxo de trabalho de implantação. Ele pode ser integrado a ferramentas CI/CD existentes, como GitHub Actions, Jenkins ou Azure DevOps, permitindo que o processo de implantação seja reproduzido sem esforço e em paralelo com um comando simples, garantindo consistência independentemente da região.
O exemplo de fluxo de trabalho de implantação acima consiste em três etapas:
- O endpoint de serviço de modelo é atualizado para a versão de modelo mais recente no catálogo compartilhado.
- O endpoint de atendimento do modelo é avaliado usando vários cenários de teste, como verificações de integridade, testes de carga e outros casos extremos predefinidos. O teste A/B é outra opção viável no Databricks, onde os endpoints podem ser configurados para hospedar múltiplas variantes de modelo. Nesta abordagem, uma proporção do tráfego é encaminhada para o modelo desafiador (modelo B) e uma proporção do tráfego é enviada para o modelo campeão (modelo A). Confira tráfego_config para mais informações. Na produção, os resultados dos dois modelos são comparados e é tomada uma decisão sobre qual modelo utilizar na produção.
- Se o endpoint de atendimento do modelo falhar nos testes, ele será revertido para a versão anterior do modelo no catálogo compartilhado.
O fluxo de trabalho de implantação descrito acima é para fins ilustrativos. As tarefas do fluxo de trabalho de implantação do modelo podem variar com base no caso de uso específico do machine studying. No restante desta postagem, discutiremos os recursos do Databricks que permitem a veiculação de modelos multirregionais.
Pontos finais de atendimento do modelo Databricks
Blocos de dados Exibição de modelo fornece endpoints de modelo altamente disponíveis e de baixa latência para oferecer suporte a aplicativos de missão crítica e de alto desempenho. Os endpoints são apoiados por computação sem servidor, que aumenta e diminui automaticamente com base na carga de trabalho. Os pontos finais do Databricks Mannequin Serving também são altamente resilientes a falhas ao atualizar para uma versão de modelo mais recente. Se a atualização para uma versão de modelo mais recente falhar, o endpoint continuará processando solicitações de tráfego em tempo actual, revertendo automaticamente para a versão de modelo anterior.
Compartilhamento Delta
Um dos principais benefícios do Delta Sharing é a sua capacidade de manter uma única fonte de verdade, mesmo quando acessada por vários ambientes em diferentes regiões. Por exemplo, pipelines de desenvolvimento em vários ambientes podem acessar tabelas somente leitura do armazenamento central de dados, garantindo consistência e evitando redundância.
Vantagens adicionais incluem governança centralizada, a capacidade de compartilhar dados em tempo actual sem replicação e liberdade de dependência de fornecedor, graças ao protocolo aberto do Delta Sharing. Essa arquitetura também oferece suporte a casos de uso avançados, como salas limpas de dados e integração com o Mercado de blocos de dados.
Peering de VPC da AWS
Peering de VPC da AWS é um recurso de rede essential que facilita a conectividade segura e eficiente entre nuvens privadas virtuais (VPCs). Uma VPC é uma rede digital dedicada a uma conta AWS, que fornece isolamento e controle sobre o ambiente de rede. Quando um usuário estabelece uma conexão de peering de VPC, ele pode rotear o tráfego entre duas VPCs usando endereços IP privados, possibilitando que instâncias em qualquer uma das VPCs se comuniquem como se estivessem na mesma rede.
Ao implantar espaços de trabalho do Databricks em várias regiões, o AWS VPC Peering desempenha um papel elementary. Ao conectar os VPCs dos espaços de trabalho do Databricks em diferentes regiões, o VPC Peering garante que o compartilhamento e a comunicação de dados ocorram inteiramente dentro de redes privadas. Esta configuração aumenta significativamente a segurança, evitando a exposição à Web pública e reduzindo os custos de saída associados à transferência de dados pela Web. Em resumo, o AWS VPC Peering não trata apenas de conectar redes; trata-se de otimizar a segurança e a economia em implantações multirregionais do Databricks
Pacotes de ativos do Databricks
UM Pacote de ativos do Databricks (DAB) é uma estrutura semelhante a um projeto que usa uma abordagem de infraestrutura como código para ajudar a gerenciar casos de uso complicados de aprendizado de máquina em Databricks. No caso de um modelo multirregional que atende o DAB é essential para orquestrar a implantação do modelo no modelo Databricks que atende pontos de extremidade por meio de fluxos de trabalho do Databricks entre regiões. Ao simplesmente especificar o espaço de trabalho Databricks de cada região em databricks.yml do DAB, a implantação de código (notebooks python) e recursos (trabalhos, pipelines, modelos DS) são simplificados em diferentes regiões. Além disso, os DABs oferecem flexibilidade ao permitir atualizações incrementais e escalabilidade, garantindo que as implantações permaneçam consistentes e gerenciáveis mesmo à medida que o número de regiões ou endpoints do modelo aumenta.
Próximas etapas
- Mostre como diferentes estratégias de implantação (teste A/B, implantação Canary, and so forth.) podem ser implementadas em DABs como parte da implantação multirregional.
- Use métricas de desempenho antes e depois para mostrar como a latência foi reduzida usando essa abordagem.
- Use uma PoC para comparar a satisfação do usuário com uma abordagem multirregional versus uma abordagem de região única.
- Certifique-se de que o compartilhamento de dados multirregional e o fornecimento de modelos estejam em conformidade com as leis regionais de proteção de dados (por exemplo, GDPR na Europa). Avalie se quaisquer considerações legais afetam o native onde os dados e modelos podem ser hospedados.
Aimpoint Digital é uma empresa de análise líder de mercado, na vanguarda da solução dos mais complexos desafios comerciais e econômicos por meio de dados e tecnologia analítica. Da integração de análises de autoatendimento à implementação de IA em escala e à modernização de ambientes de infraestrutura de dados, a Aimpoint Digital opera em domínios transformadores para melhorar o desempenho das organizações. Saiba mais acessando: https://www.aimpointdigital.com/