Otimizar o desempenho de rede
O desempenho da rede pode ter um impacto significativo sobre a experiência do usuário. Em arquiteturas complexas com vários serviços diferentes, minimizar a latência em cada salto de rede pode afetar o desempenho geral. Nesta unidade, você aprenderá sobre a importância da latência da rede e como reduzi-la na sua arquitetura. Também discutimos estratégias para minimizar a latência da rede entre os recursos do Azure e entre os usuários e o Azure.
A importância da latência de rede
A latência é uma medida de atraso. A latência da rede é o tempo que os dados levam para viajar de uma origem para um destino em uma rede. O tempo necessário para que os dados saiam da origem e cheguem a um destino e para que o destino responda normalmente é conhecido como um atraso de ida e volta.
Em um ambiente de datacenter tradicional, a latência pode ser mínima, pois os recursos geralmente compartilham a mesma localização e um conjunto comum de infraestrutura. O tempo necessário para ir da origem ao destino é normalmente menor quando os recursos estão fisicamente próximos uns dos outros.
Em comparação, um ambiente de nuvem é feito para escala. Os recursos hospedados na nuvem podem não estar no mesmo rack, datacenter ou região. Essa abordagem distribuída pode ter um impacto sobre o tempo de viagem de ida e volta de suas comunicações de rede. Embora todas as regiões do Azure estejam interconectadas com um backbone de fibra de alta velocidade, a velocidade da luz ainda é uma limitação física. As chamadas entre serviços em locais físicos diferentes ainda têm latência de rede diretamente correldisparada à distância entre eles.
Além disso, dependendo das necessidades de comunicação de um aplicativo, podem ser necessárias mais viagens de ida e volta. Cada viagem de ida e volta tem uma taxa de latência e cada uma delas contribui para a latência geral. A ilustração a seguir mostra como a latência percebida pelo usuário é a combinação das viagens de ida e volta necessárias para atender à solicitação.
Vejamos como aprimorar o desempenho entre os recursos do Azure e também de seus usuários para os recursos do Azure.
Latência entre recursos do Azure
Imagine que você trabalha em uma organização de saúde que está realizando um teste piloto de um novo sistema de agendamento de pacientes. Esse sistema é executado em vários servidores Web e em um banco de dados. Todos os recursos estão localizados na região do Oeste da Europa do Azure. O escopo do teste piloto está disponível somente para usuários no Oeste da Europa. Essa arquitetura minimiza a latência de rede, pois todos os recursos são colocados dentro de uma região do Azure.
Suponha que o teste piloto do sistema de reservas tenha sido bem-sucedido. Como resultado, seu escopo foi expandido para incluir usuários na Austrália. Quando os usuários da Austrália exibem seu site, eles incorrem no tempo extra de ida e volta necessário para acessar todos os recursos localizados no Oeste da Europa. Sua experiência é reduzida devido à latência adicional da rede.
Para resolver os problemas de latência de rede, sua equipe de TI decide hospedar outra instância de front-end na região do Leste da Austrália. Esse design ajuda a reduzir o tempo que seus servidores Web levam para retornar o conteúdo aos usuários na Austrália, mas a experiência deles ainda está reduzida. Há uma latência significativa para os dados que estão sendo transferidos entre os servidores Web de front-end no Leste da Austrália e o banco de dados no Oeste da Europa.
Há algumas maneiras de reduzir a latência restante:
- Criar uma réplica de leitura do banco de dados no Leste da Austrália. Uma réplica de leitura permite um bom desempenho para as leituras, mas as gravações ainda sofreriam latência. A replicação geográfica do Banco de Dados SQL do Azure permite réplicas de leitura.
- Sincronize seus dados entre regiões com a Sincronização de Dados SQL do Azure.
- Use um banco de dados distribuído globalmente, como o Azure Cosmos DB. Esse banco de dados permite que tanto leituras quanto gravações ocorram independentemente da localização, mas pode exigir alterações na forma como o aplicativo armazena e referencia os dados.
- Use tecnologia de cache como o Cache do Azure para Redis para minimizar chamadas de alta latência para bancos de dados remotos no caso dos dados acessados com frequência.
O objetivo é minimizar a latência da rede entre cada camada do aplicativo. A forma de melhorar a latência da rede depende da arquitetura do aplicativo e dos dados. O Azure fornece mecanismos para resolver problemas de latência por meio de vários serviços.
Latência entre usuários e recursos do Azure
Examine a latência entre os recursos do Azure, mas também considere a latência entre usuários e o aplicativo de nuvem. Você quer otimizar a entrega da interface do usuário final frontal para nossos usuários. Vamos ver algumas maneiras de aprimorar o desempenho de rede entre os usuários e o aplicativo.
Usar um balanceador de carga de DNS para otimização de caminho do ponto de extremidade
Em nosso cenário de exemplo, sua equipe de TI criou outro nó de front-end da Web no Leste da Austrália. Entretanto, os usuários precisam especificar explicitamente qual ponto de extremidade de front-end desejam usar. Como o designer de uma solução, você quer tornar a experiência o mais fácil possível para os usuários.
O Gerenciador de Tráfego do Azure pode ajudar. O Gerenciador de Tráfego é um balanceador de carga baseado em DNS que pode ser usado para distribuir o tráfego dentro e entre regiões do Azure. Em vez de fazer o usuário procurar uma instância específica do front-end da Web, o Gerenciador de Tráfego encaminha os usuários de acordo com um conjunto de características:
- Prioridade: você especifica uma lista ordenada de instâncias de front-end. Se aquela com a prioridade mais alta não estiver disponível, o Gerenciador de Tráfego encaminhará o usuário para a próxima instância disponível.
- Peso: você define um peso em relação a cada instância de front-end. Em seguida, o Gerenciador de Tráfego distribui o tráfego conforme essas proporções definidas.
- Desempenho: o Gerenciador de Tráfego encaminha os usuários para a instância de front-end mais próxima com base na latência da rede.
- Geográfico: você configura regiões geográficas para implantações de front-end e roteia os usuários com base nas normas de soberania de dados ou na localização do conteúdo.
Os perfis do Gerenciador de Tráfego também podem ser aninhados. Por exemplo, inicialmente você pode rotear os usuários entre diferentes geografias (como Europa e Austrália) usando o roteamento geográfico. Depois, pode roteá-los para implantações locais de front-end usando o método de roteamento de desempenho.
Lembre-se de que a organização em nosso cenário de exemplo implantou um front-end da Web no Oeste da Europa e outro na Austrália. Suponha que ela implantou o Banco de Dados SQL do Azure com a principal implantação no Oeste da Europa e uma réplica de leitura no Leste da Austrália. Vamos também supor que o aplicativo consiga se conectar à instância SQL local para consultas de leitura.
A equipe implanta uma instância do Gerenciador de Tráfego no modo de desempenho e adiciona as duas instâncias de front-end como perfis do Gerenciador de Tráfego. Como usuário, você navega para um nome de domínio personalizado (por exemplo, contoso.com) que o encaminha para o Gerenciador de Tráfego. Em seguida, o Gerenciador de Tráfego retorna o nome DNS do front-end do Oeste da Europa ou do Leste da Austrália com base no melhor desempenho de latência da rede.
É importante observar que esse balanceamento de carga só é manipulado via DNS. Nenhum cache nem balanceamento de carga embutido está acontecendo aqui. O Gerenciador de Tráfego apenas retorna o nome DNS do front-end mais próximo ao usuário.
Usar uma CDN para armazenar em cache o conteúdo próximo dos usuários
O site provavelmente usa alguma forma de conteúdo estático (páginas inteiras ou ativos, como imagens e vídeos). Esse conteúdo estático pode ser entregue aos usuários mais rapidamente por meio de uma CDN (rede de distribuição de conteúdo), como a Rede de Distribuição de Conteúdo do Azure.
Com o conteúdo implantado na Rede de Distribuição de Conteúdo do Azure, esses itens são copiados para vários servidores no mundo inteiro. Digamos que um desses itens seja um vídeo fornecido pelo Armazenamento de Blobs: HowToCompleteYourBillingForms.MP4. A equipe configura o site de modo que o link de cada usuário para o vídeo referencie o servidor de borda da CDN mais próximo, em vez de referenciar o Armazenamento de Blobs. Essa abordagem coloca o conteúdo mais próximo do destino, o que reduz a latência e aprimora a experiência do usuário. A ilustração a seguir mostra como o uso da Rede de Distribuição de Conteúdo do Azure aproxima o conteúdo do destino, o que reduz a latência e aprimora a experiência do usuário.
Você também pode usar redes de distribuição de conteúdo para hospedar conteúdo dinâmico armazenado em cache. No entanto, é necessário fazer uma consideração adicional, pois o conteúdo armazenado em cache pode estar desatualizado em comparação com a origem. Você pode controlar a expiração do contexto definindo um TTL (vida útil). Se o TTL for muito alto, o conteúdo desatualizado poderá ser exibido e o cache precisará ser limpo.
Uma forma de lidar com o conteúdo armazenado em cache é com um recurso chamado aceleração de site dinâmico, que pode aumentar o desempenho das páginas da Web com conteúdo dinâmico. A aceleração dinâmica de sites também pode fornecer um caminho de baixa latência para alguns serviços na sua solução. Um exemplo é um ponto de extremidade de API.
Usar o ExpressRoute para conectividade do local ao Azure
Otimizar a conectividade de rede do seu ambiente local com o Azure também é importante. É desejável garantir que os usuários tenham a melhor conexão com seus aplicativos, estejam eles hospedados em máquinas virtuais ou em ofertas de plataforma como serviço (PaaS), como o Serviço de Aplicativo do Azure.
Sempre é possível usar a Internet pública para conectar os usuários aos seus serviços, mas o desempenho da Internet pode variar e está sujeito a problemas externos. Além disso, talvez você não queira expor todos os seus serviços pela Internet. Talvez você queira ter uma conexão privada com os recursos do Azure. A VPN site a site pela Internet também é uma opção. Para arquiteturas com alta taxa de transferência, a sobrecarga da VPN e a variabilidade da Internet podem afetar a latência de rede significativamente.
O Azure ExpressRoute pode ajudar. O ExpressRoute é uma conexão privada e dedicada entre sua rede e o Azure. Ele oferece desempenho garantido e certifica que os usuários tenham o melhor caminho para todos os seus recursos do Azure. A ilustração a seguir mostra como um circuito do ExpressRoute fornece conectividade entre aplicativos locais e recursos do Azure.
Vamos considerar nosso cenário de exemplo mais uma vez. Sua equipe decide melhorar ainda mais a experiência dos usuários que estão em suas instalações, provisionando um circuito ExpressRoute no Leste da Austrália e no Oeste da Europa. Essa opção fornece aos usuários uma conexão direta com seu sistema de reservas. Ela também garante a menor latência possível para o aplicativo.
Considerar o impacto da latência de rede sobre sua arquitetura é importante para garantir o melhor desempenho possível para os usuários. Nesta unidade, vimos algumas opções para reduzir a latência da rede entre os usuários e o Azure e entre os recursos do Azure.