Tutorial: Criando um aplicativo de Renderização Remota do Azure pronto para comercial

  • Artigo

Neste tutorial, ficará a saber mais sobre:

  • Gestão de sessões para aplicações comerciais
  • Sessões de acompanhamento para faturação
  • Otimizando a experiência do usuário em torno do tempo de carregamento da sessão
  • Considerações sobre latência de rede

Pré-requisitos

  • Este tutorial baseia-se no Tutorial: Protegendo a renderização remota do Azure e o armazenamento de modelos.

Introdução à Prontidão Comercial

A Renderização Remota do Azure expande o que é possível com a realidade mista. Depois que os conceitos básicos são integrados à sua solução, há uma série de considerações adicionais para garantir que sua solução seja segura, escalável e pronta para fornecer valor.

Este módulo apresenta alguns recursos adicionais que você pode precisar considerar para sua aplicação comercial.

Para obter uma ampla visão geral das práticas recomendadas de arquitetura em todo o sistema, visite:

Análise

A integração de ferramentas de análise pode ajudar a gerenciar, rastrear e melhorar sua solução.

Para obter uma lista abrangente dos recursos de análise disponíveis para você, visite:

Rastreando o uso para faturamento

Controlar o consumo da Renderização Remota do Azure por várias equipes internas ou clientes externos torna-se uma consideração importante, especialmente em situações multilocatário.

Para conseguir isso, o Azure oferece um serviço chamado marcação de recursos, que associa o consumo do serviço de Renderização Remota do Azure a cada cliente.

Para obter mais informações sobre nomeação e marcação de recursos, um bom lugar para começar é:

Diagnóstico

Ferramentas poderosas, como o Rastreamento de Eventos para Windows (ETW) e o Log de Rastreamento de Eventos (ETL), facilitam a geração de eventos de rastreamento em seu aplicativo e podem ajudar a diagnosticar a rede, a ingestão de conteúdo, a sessão, o aplicativo e outros problemas que podem surgir em uma implantação de solução comercial.

Para obter mais informações, visite:

Análise de utilização

O Azure Application Insights ajuda você a entender como as pessoas usam seu aplicativo de Renderização Remota do Azure. Sempre que atualizar a sua aplicação, pode avaliar o seu funcionamento para os utilizadores e melhorar a sua solução em conformidade. Com esse conhecimento, você pode tomar decisões orientadas por dados sobre seus próximos ciclos de desenvolvimento.

Para obter mais informações, visite:

Estratégias de tempo de arranque rápido

Seu caso de uso pode exigir inicialização rápida desde a inicialização do aplicativo até a visualização do modelo 3D. Por exemplo, durante uma reunião importante onde é fundamental ter tudo pronto e funcionando com antecedência. Outro exemplo é durante uma revisão de modelo CAD 3D, onde a iteração rápida do projeto entre um aplicativo CAD e a realidade mista é a chave para a eficiência.

A Renderização Remota do Azure requer modelos 3D pré-processados, e o Azure atualmente leva vários minutos para criar uma sessão e carregar um modelo para renderização. Tornar este processo o mais simples e rápido possível requer a preparação dos dados do modelo 3D e da sessão ARR com antecedência.

As sugestões compartilhadas aqui não fazem parte atualmente da Renderização Remota do Azure padrão, mas você pode implementá-las por conta própria para tempos de inicialização mais rápidos.

Iniciar cedo

Para reduzir o tempo de inicialização, a solução mais simples é mover a criação e inicialização da sessão o mais cedo possível no fluxo de trabalho do usuário. Uma estratégia é inicializar a sessão assim que se souber que uma sessão ARR será necessária. Isso geralmente ocorre quando o usuário começa a carregar um modelo 3D no Armazenamento de Blobs do Azure para usar com a Renderização Remota do Azure. Nesse caso, a criação e a inicialização da sessão podem ser iniciadas ao mesmo tempo que o carregamento do modelo 3D, de modo que ambos os fluxos de trabalho sejam executados em paralelo.

Esse processo pode ser simplificado ainda mais, garantindo que os contêineres de entrada e saída do Armazenamento de Blobs do Azure escolhidos estejam no mesmo data center regional que a sessão de Renderização Remota do Azure.

Agendamento

Se você souber que tem uma necessidade futura de Renderização Remota do Azure, poderá agendar uma data e hora específicas para iniciar a sessão de Renderização Remota do Azure.

Esta opção pode ser oferecida através de um portal web onde as pessoas podem carregar um modelo 3D e agendar um horário para visualizá-lo no futuro. Este também seria um bom lugar para pedir outras preferências, como renderização Standard ou Premium. A renderização premium pode ser adequada se houver um desejo de mostrar uma combinação de ativos em que o tamanho ideal seja mais difícil de determinar automaticamente ou uma necessidade de garantir que a região do Azure tenha VMs disponíveis naquele momento especificado.

Pool de sessões

Nas situações mais exigentes, outra opção é o pool de sessões, onde uma ou mais sessões são criadas e inicializadas o tempo todo. Isso cria um pool de sessões para uso imediato por um usuário solicitante. A desvantagem dessa abordagem é que, uma vez que a VM é inicializada, a cobrança pelo serviço é iniciada. Pode não ser econômico manter um pool de sessões em execução o tempo todo, mas com base em análises, pode ser possível prever picos de carga ou pode ser combinado com a estratégia de agendamento acima para prever quando as sessões serão necessárias e aumentar e diminuir o pool de sessões de acordo.

Essa estratégia também ajuda a otimizar a escolha entre sessões Standard e Premium de uma forma mais dinâmica, porque seria muito mais rápido alternar entre os dois tipos dentro de uma única sessão de usuário, como no caso em que um modelo de complexidade Premium é visto primeiro, seguido por um que pode funcionar dentro do Standard. Se essas sessões de usuário forem bastante longas, pode haver economias de custos significativas.

Para saber mais sobre as sessões de Renderização Remota do Azure, confira:

Estratégias de roteamento de tamanho de servidor padrão vs. Premium

Precisar selecionar se deseja criar um tamanho de servidor Standard ou Premium representa um desafio ao projetar sua experiência de usuário e sistema de ponta a ponta. Embora usar apenas sessões Premium seja uma opção, as sessões Standard usam muito menos recursos de computação do Azure e são menos dispendiosas do que as Premium. Isso fornece uma forte motivação para usar sessões Standard sempre que possível e usar Premium apenasquando necessário.

Aqui partilhamos várias opções, do menos ao mais abrangente, para abordar o desejo de gerir as escolhas de sessão.

Use apenas Standard ou Premium

Se você tem certeza de que suas necessidades sempre ficarão abaixo do limite entre Standard e Premium, isso simplifica consideravelmente sua decisão. Basta usar o Standard. Tenha em mente, no entanto, que o impacto na experiência do usuário é significativo se a complexidade total da soma dos ativos carregados for rejeitada como muito complexa para uma sessão Standard .

Da mesma forma, se você espera que uma grande parte dos usos exceda o limite entre Standard e Premium, ou o custo não é um fator chave em seu caso de uso, então sempre escolher Premium também é uma opção para mantê-lo simples.

Pergunte ao utilizador

Se você deseja oferecer suporte a Standard e Premium, a maneira mais fácil de determinar qual tipo de sessão instanciar é perguntar ao usuário quando ele seleciona ativos 3D para visualizar. O desafio com essa abordagem é que ela exige que o usuário entenda a complexidade do ativo 3D ou até mesmo vários ativos que serão visualizados. Normalmente, isso não é recomendado por esse motivo. Se o usuário selecionar errado e escolher Padrão, a experiência do usuário resultante pode ser comprometida em um momento inoportuno.

Analise o modelo 3D

Outra abordagem relativamente simples é analisar a complexidade dos ativos 3D selecionados. Se a complexidade do modelo estiver abaixo do limite para Standard, inicie uma sessão Standard e, caso contrário, inicie uma sessão Premium. Aqui, o desafio é que uma única sessão pode, em última análise, ser usada para visualizar vários modelos, alguns dos quais podem exceder o limite de complexidade de uma sessão padrão, resultando na incapacidade de usar perfeitamente a mesma sessão para uma sequência de diferentes ativos 3D.

Comutação automática

A comutação automática entre sessões Standard e Premium pode fazer muito sentido em um design de sistema que também inclui pool de sessões. Esta estratégia permite uma maior otimização da utilização de recursos. À medida que o usuário carrega modelos para visualização, a complexidade é determinada e o tamanho correto da sessão é solicitado ao serviço de pool de sessões.

Trabalhar com redes

Diagnóstico

A Renderização Remota do Azure requer uma conexão rápida com a Internet com baixa latência. A qualidade da rede do utilizador pode ter um impacto significativo na qualidade da experiência. Dado que é provável que seus clientes tenham configurações de rede diferentes e apenas ocasionalmente baixa latência de rede, as ferramentas de diagnóstico são fundamentais.

Para garantir que você possa oferecer uma experiência de alta qualidade consistente, recomendamos que você integre ferramentas de análise do lado do servidor e do lado do cliente em seus aplicativos de Renderização Remota do Azure. Ao fazê-lo, fornece-lhe as informações de que necessita para diagnosticar e mitigar quaisquer problemas de rede que os seus clientes possam estar a enfrentar.

Configurações de rede do cliente

Um dos maiores desafios no desenvolvimento de soluções de colaboração robustas que são implantadas em uma ampla variedade de ambientes corporativos é estar preparado para as diferentes configurações de topologia de rede e firewall corporativo que seus clientes podem usar.

Muitas empresas bloqueiam todo o tráfego peer-to-peer dentro de uma LAN. Isso torna difícil aproveitar a simplicidade e a experiência do usuário simplificada da descoberta automática de LAN para estabelecer uma sessão compartilhada local entre todas as instâncias descobertas do seu aplicativo de realidade mista.

Outros potenciais pontos de falha são roteadores configurados para limitar intencionalmente a largura de banda e firewalls que bloqueiam a maioria das portas TCP/IP.

Sempre que você estiver planejando usar a Renderização Remota do Azure em uma rede desconhecida, recomendamos o seguinte:

  • Forneça uma lista de verificação pré-reunião para avaliar a prontidão da rede.
  • Certifique-se de que o data center regional apropriado possa atender à solicitação.
  • Permita bastante tempo para diagnosticar quaisquer problemas.
  • Traga um hotspot móvel com um plano de dados de alta largura de banda como backup.

Largura de banda de ponta a ponta

É importante avaliar os recursos de largura de banda para cada trecho da rede que podem existir entre a VM de Renderização Remota do Azure e o cliente final. Lembre-se de que o segmento de rede do data center do Azure para o ISP do cliente pode ser mais um fator limitante do que do ISP para o cliente. O teste de velocidade de download de blob pode ser usado para ajudar a diagnosticar esses problemas.

Concorrência de largura de banda

Ao projetar seu aplicativo de realidade mista, lembre-se de que diferentes recursos do aplicativo podem competir com a Renderização Remota do Azure pela largura de banda. O exemplo imprevisto mais provável é quando muitos participantes em uma única sala esperam usar simultaneamente o ARR para visualizar um ativo 3D. Cada etapa do fluxo de dados da rede precisará ter capacidade para transportar a soma total de todos os fluxos de dados ARR combinados.

Outros exemplos incluem vídeo transmitido, uploads simultâneos em segundo plano de outros conteúdos relacionados e bate-papo por voz, particularmente quando há muitos participantes e o sistema está usando uma abordagem distribuída ponto a ponto, em oposição a um servidor de mistura de áudio na abordagem intermediária.

Para obter mais informações sobre análise de rede, consulte:

Considerações sobre colaboração

Alguns dos usos mais valiosos da Renderização Remota do Azure envolvem a colaboração entre vários participantes que visualizam a mesma experiência 3D ao mesmo tempo. Nessas sessões compartilhadas, é importante reconhecer que cada participante precisará de uma sessão exclusiva de Renderização Remota do Azure, independentemente de estarem localizados no mesmo local na mesma rede ou não.

Isso é verdade porque cada participante está realmente vendo a mesma experiência de diferentes pontos de vista, o que requer que os mesmos ativos 3D sejam renderizados de cada uma dessas perspetivas simultaneamente.

Várias sessões de renderização remota do Azure

Se você pretende dar suporte a experiências compartilhadas com a Renderização Remota do Azure, os sistemas criados para criar e gerenciar sessões ARR precisarão estar preparados para iniciar várias sessões. Essas sessões podem precisar ser inicializadas em diferentes data centers do Azure se os participantes estiverem geograficamente dispersos.

Seu sistema também deve gerenciar a possibilidade de que um ou mais participantes estejam em uma região geográfica que atualmente não é suportada pela Renderização Remota do Azure ou atualmente não tem instâncias de VM de Renderização Remota do Azure disponíveis.

Esse gerenciamento de várias sessões simultâneas pode ser ainda mais simplificado quando combinado com o pool de sessões e outras estratégias discutidas neste documento.

Considerações sobre o Armazenamento de Blobs do Azure

Todas as sessões ARR simultâneas podem fazer referência ao mesmo URI SAS para que o modelo convertido seja visualizado. Isso torna possível carregar e converter os ativos 3D desejados uma vez e, em seguida, compartilhá-los em todas as sessões. Isso é especialmente verdadeiro quando os participantes estão colocalizados e usando o mesmo data center onde não há preocupações de desempenho relacionadas ao Armazenamento de Blobs do Azure estar localizado em um data center diferente do servidor de Renderização Remota do Azure e do usuário.

Se os ativos 3D normalmente são carregados para uma única sessão de exibição e, em seguida, descartados, como em uma sessão de revisão de design, a região geográfica do Armazenamento de Blobs do Azure em relação ao servidor de Renderização Remota do Azure também é menos crítica.

No entanto, para ativos 3D que serão usados repetidamente, como em um caso de uso de treinamento, recomendamos manter ativos 3D prontos para uso no armazenamento de blob em cada data center regional onde você planeja usar a Renderização Remota do Azure. Isso pode ser automatizado usando a Redundância de Armazenamento do Azure. A CDN também é frequentemente usada para essa finalidade, mas isso ainda não é uma opção para a Renderização Remota do Azure.

Para mais informações:

Gerenciando o acesso ao modelo

Aproveitar totalmente a Renderização Remota do Azure requer uma consideração cuidadosa da infraestrutura de ponta a ponta para gerenciar modelos 3D.

Uma vantagem de usar a Renderização Remota do Azure é que grandes ativos 3D nunca precisam ser transmitidos diretamente para o dispositivo de realidade mista antes de serem exibidos. Além disso, depois que um ativo 3D for carregado e convertido para uso com a Renderização Remota do Azure, qualquer número de usuários poderá compartilhar essa única instância do modelo 3D.

Considerações para o acesso ao modelo 3D

Aqui estão algumas considerações importantes ao decidir sobre sua estratégia de acesso ao modelo.

Com base no caso de uso previsto, determine o melhor local ou combinação de locais para permitir que um usuário selecione os ativos 3D para visualização. Algumas opções comuns são:

  • Diretamente dentro da experiência de realidade mista
  • Através de um portal Web complementar
  • Em um aplicativo complementar para desktop ou móvel

Se o seu caso de uso tiver padrões de uso em que o mesmo ativo 3D pode ser carregado várias vezes, o back-end rastreará quais modelos já foram convertidos para uso com ARR, de modo que um modelo seja pré-processado apenas uma vez para várias seleções futuras. Um exemplo de revisão de projeto seria quando uma equipe tem acesso a um ativo 3D original comum. Espera-se que cada membro da equipe revise o modelo usando ARR em algum momento de seu fluxo de trabalho. Apenas a primeira visualização acionaria a etapa de pré-processamento. As visualizações subsequentes procurariam o arquivo pós-processado associado no contêiner de saída SAS.

Dependendo do caso de uso, você provavelmente desejará determinar e potencialmente persistir o tamanho correto do servidor de Renderização Remota do Azure, Standard ou Premium, para cada ativo 3D ou grupo de ativos que serão exibidos juntos na mesma sessão.

Lista de seleção de modelos no dispositivo

Em muitos casos de uso, como um treinamento, orientação de tarefas ou aplicativo de marketing, o conjunto de ativos 3D a serem comumente exibidos na Renderização Remota do Azure pode ser bastante estático. Nessas situações, um conjunto curado de ativos 3D pode ser pré-convertido e disponibilizado por meio de um banco de dados que contém as informações necessárias para preencher uma lista de seleção de ativos curados. Esses dados podem ser recuperados do aplicativo de realidade mista para preencher um menu de seleção.

Isso pode ser levado um passo adiante, oferecendo também uma maneira de carregar ativos 3D privados, exclusivos para cada indivíduo ou grupo. Essa lista de ativos privados poderia então ser combinada com a lista de ativos comuns e selecionados na experiência do usuário para selecionar ativos 3D para visualização.

Acesso ao OneDrive no dispositivo

Dado que um seletor de arquivos do OneDrive é incorporado nativamente nos dispositivos de realidade mista da Microsoft, selecionar ativos 3D no dispositivo a partir do OneDrive é atraente, especialmente para casos de uso em que é comum carregar modelos 3D diferentes ou modificados. Nesse cenário, o usuário selecionaria um ou mais ativos 3D por meio do seletor de arquivos do OneDrive em seu aplicativo de realidade mista. Os ativos 3D seriam então migrados para um contêiner de entrada SAS, convertidos em um contêiner de saída SAS e anexados à sessão ARR. Idealmente, o aplicativo de realidade mista invocaria um processo baseado em nuvem para executar essas etapas, em vez de mover todos os bits do OneDrive para o dispositivo e voltar para o Armazenamento de Blobs do Azure.

Essa abordagem pode ser levada um passo adiante, persistindo uma associação entre ativos 3D que foram visualizados anteriormente, de modo que, quando o mesmo modelo é escolhido novamente no OneDrive, o aplicativo pode ignorar o processo de conversão e carregar diretamente o ativo 3D convertido associado por meio de seu URI SAS.

Para mais informações:

Acesso direto ao CAD

Um caso de uso atraente para realidade mista é a revisão de projetos de trabalhos CAD em andamento. Nesse cenário, o tempo de carregamento mais rápido da área de trabalho para a realidade mista é fundamental. Uma solução ideal poderia envolver o desenvolvimento de plugins para aplicações CAD específicas. Esses plug-ins gerenciariam diretamente todos os aspetos do processo de carga, conversão e visualização:

  • Forneça uma experiência do usuário para:
    • Emparelhe a aplicação CAD com um dispositivo de realidade mista específico (uma vez).
    • Solicite que a geometria selecionada seja visualizada nesse dispositivo de realidade mista.
  • Se ainda não estiver em execução, gire a sessão de Renderização Remota do Azure para que ela possa ser processada em paralelo ao carregar e converter o arquivo CAD
  • Normalizar dados de geometria CAD para um dos formatos suportados pela Renderização Remota do Azure
  • Transmitir os dados normalizados diretamente para o contêiner de entrada do Armazenamento de Blobs do Azure
  • Iniciar o processo de conversão do modelo
  • Vincular o URI SAS do contêiner de saída do modelo à sessão de Renderização Remota do Azure
  • Notifique o aplicativo de realidade mista emparelhado de que o modelo está disponível e pronto para visualização e forneça o URI SAS do contêiner de saída para que o aplicativo possa anexá-lo à sessão.

Uma abordagem muito mais simples, mas um pouco menos simplificada, poderia automatizar o processo de salvar o modelo 3D em um disco rígido local e, em seguida, iniciar um processo para transmitir o arquivo salvo para o contêiner de entrada SAS.

Azure Marketplace

Muitos clientes corporativos exigem que seu Azure Stack possa ser implantado em suas próprias contas e credenciais do Azure por motivos de segurança. Para tornar isso possível, convém considerar empacotar seu aplicativo gerenciado do Azure para que ele possa ser publicado no Azure Marketplace como uma Oferta de Aplicativo do Azure.

Para mais informações:

Segurança

É fundamental criar sua solução completa de Renderização Remota do Azure para segurança desde o início. Há muitos aspetos de segurança a serem considerados no design de sua solução de ponta a ponta, incluindo:

  • Estratégias de autenticação
  • Gerenciamento de acesso – grupos, políticas e permissões
  • Arquitetura multi-inquilino
  • Encriptação de transferência e armazenamento de dados
  • Tokens de uso temporário
  • Ataques distribuídos de negação de serviço (DDoS)
  • Deteção de ameaças
  • VPNs e redes seguras
  • Firewalls
  • Gestão de certificados e chaves secretas
  • Vulnerabilidade e explorações de aplicativos

Para autenticação, é aconselhável mover o máximo possível da autenticação ARR e do gerenciamento de sessão para um Serviço Web do Azure. Isso resultará em uma solução mais bem gerenciada e mais segura.

Para mais informações: