Sites do Azure

Arquiteto para a nuvem usando os sites do Azure

Apurva Joshi
Sunitha Muthukrishna

 

Há uma coisa importante para se lembrar ao criar uma solução de nuvem—sempre crie para falhar. Muitos aplicativos, no entanto, não são projetados desta maneira. O principal motivo para isto é a falta de conscientização de como criar uma arquitetura usando os sites do Microsoft Azure que é suficientemente resiliente. Então como desenvolver uma solução de nuvem que seja robusta o suficiente para lidar com a falha? Este artigo discutirá técnicas que você pode empregar para criar este tipo de sistema.

Instância única do site

Os sites do Azure fornecem planos de hospedagens em várias camadas: Free, Shared, Basic e Standard. As camadas Free e Shared fornecem aos sites uma infraestrutura compartilhada, o que significa que seus sites compartilham recursos com outros sites. Na camada Basic e Standard, seus sites receberão uma infraestrutura dedicada, o que significa que somente o site ou sites que você escolheu associar ao seu plano executarão nestes recursos.

Nestas camadas, você pode configurar seu plano de hospedagem na Web para usar uma ou mais instâncias da máquina virtual (VM). Estas camadas podem suportar instâncias pequenas, médias e grandes. O provedor gerenciará estas VMs em seu nome, o que significa que você não terá mais que se preocupar com as atualizações do SO e com as atualizações da configuração e de segurança.

Para executar um site a um nível de produção nos sites do Azure, a camada Basic ou Standard é recomendada com base no tamanho de seu aplicativo e na quantidade de tráfego no seu site. Compreender os requisitos de seu aplicativo é um bom ponto de partida:

1. Quais componente o seu aplicativo precisa—banco de dados, provedor de email, cache e assim por diante?
2. Quais componentes estão em risco de falhar e precisam ser replicados?
3. Quais recursos você precisa—SSL, slots de produção e assim por diante?
4. Quanto tráfego o seu site deve ser capaz de gerenciar?

Com estas respostas, você pode criar um único site e adicionar componentes, como banco de dados e cache para seu aplicativo, conforme necessário. Na Figura 1, você pode ver como talvez seja possível projetar um único site e seus componentes dependentes.

No cenário de único site, a grande advertência é no evento de uma interrupção relacionada ao serviço para qualquer componente (site, banco de dados ou serviço de cache), seu site estará indisponível durante a interrupção, então haverá um impacto nos seus clientes e nos seus negócios.

Figura 1 Arquitetura padrão para um único site

Este design não considera os risco desenvolvidos com as soluções de nuvem, nem inclui uma maneira de reduzi-los. Em um ambiente de nuvem, a sua meta de design deve ser criar um site altamente disponível que minimize o tempo de inatividade e agilize a recuperação durante uma interrupção. 

A meta é a alta disponibilidade

Uma pilha de aplicativo Web típico nos sites do Azure consistirá em um aplicativo Web, banco de dados e alguma formas de cache. Todos estes componentes são unidos firmemente para evitar que uma única entidade ou componente se torne um ponto único de falha (SPOF). Este é um critério de design chave para projetar qualquer solução de nuvem. A meta é:

• Evitar o SPOF no seu design
• Redundância através de cada camada no seu design

Sites do Azure fornecem um SLA de 99,9 por cento. Isto significa que você pode esperar um tempo de inatividade de aproximadamente 10 minutos por semana devido a implantação agendada ou atualizações conduzidas pelo serviço dos sites do Azure. Ainda, 10 minutos de tempo de inatividade pode ter um grande impacto nos seus negócios. A sua meta deve ser projetar sua solução para reduzir este tempo de inatividade e poder servir seus clientes, dessa forma reduzindo o seu risco de impacto. Você deve se esforçar para criar uma arquitetura da Web, conforme exibido na Figura 2.

Figura 2 Exemplo de uma arquitetura da Web altamente disponível

Alta disponibilidade da camada do aplicativo da Web

Os sites do Azure criam uma solução de nuvem sem monitoração de estado para seu aplicativo Web. Você precisa considerar os seguintes pontos ao criar alta disponibilidade no nível do aplicativo:

1. Use o modo Standard para seus sites, e configure-o para usar pelo menos duas instâncias do site.
2. Com base nos seus padrões de tráfego, simule cargas para testar através de várias ferramentas como o Visual Studio e Apache JMeter (jmeter.apache.org) para identificar o tamanho da instância e quantas instâncias seriam necessárias para seu site gerenciar os níveis reais de tráfego.
3. Assegurar que os dados da sessão e do usuário estejam armazenados em um sistema centralizado, como um banco de dados ou uma camada em cache distribuída. Nos sites do Azure, o servido de arquivo é compartilhado através de todas as VMs ao executar no modo Standard.
4. Replicar a camada do aplicativo Web em pelo menos duas regiões com suporte para os sites do Azure.
5. O conteúdo de usuário, como mídia e documentos que o seu site carrega ou gerencia deve ser armazenado em uma conta de armazenamento do Azure. Verifique se a conta de armazenamento está na mesma região geográfica que o site para reduzir a latência.
6. Sempre siga as práticas de codificação seguras para tornar seu aplicativo resiliente dos ataques maliciosos.

Alta disponibilidade na camada do bancos de dados

Os dados são o que realmente geram valor para qualquer aplicativo, então você deve gerenciá-los de forma eficiente. Para que seu aplicativo funcione corretamente, é essencial evitar um ponto único de falha na camada do banco de dados. O site do Azure suporta o Banco de Dados SQL do Azure e o serviço ClearDB MySQL. Ambos fornecem opções a partir de soluções premium a de baixo alcance.

O Banco de Dados SQL do Azure Premium oferece um desempenho mais previsível e maior capacidade para os aplicativos de nuvem ao usar os sites do Azure. Ele dedica um valor fixo de capacidade de reserva para um banco de dados incluindo seus recursos de replicação de banco de dados integrado. A capacidade reservada é ideal para:

• Pico de carga alto: Um aplicativo que exige bastante CPU, memória ou I/O para concluir suas operações é um bom candidato para usar o banco de dados Premium.
• Muitas solicitações simultâneas: Alguns aplicativos de banco de dados prestam serviços para muitas solicitações simultâneas. As edições normais Web e Business do Banco de Dados SQL do Azure têm um limite de 180 solicitações simultâneas. Os aplicativos que necessitam de mais conexões devem usar um banco de dados Premium com um tamanho de reserva apropriado para lidar com o número máximo de solicitações.
• Latência previsível: Alguns aplicativos precisam garantir uma resposta de um banco de dados em um tempo mínimo. Se um determinado procedimento armazenado é chamado como parte de uma operação de cliente mais ampla, pode haver um requisito para retornar daquela chamada em não mais de 20 ms 99 por cento do tempo. Este tipo de aplicativo se beneficiará de um banco de dados Premium para garantir que a capacidade de processamento esteja disponível.

O ClearDB oferece roteadores de alta disponibilidade (ou CDBRs) que são gerenciadores de tráfego inteligentes, personalizados que monitoram estes clusters de banco de dados. Quando um nó de banco de dados não está íntegro, o CDBR redireciona automaticamente ao seu mestre secundário. Isto ajuda a assegurar o tempo de ativação para seu banco de dados e, por sua vez, do aplicativo Web. Ao desenvolver este design, lembre-se de que há emparelhamentos de regiões de suporte ClearDB para tais cenários, como:

1. Se você escolher um banco de dados do leste dos Estados Unidos, o banco de dados emparelhado deve estar no oeste dos Estados Unidos.
2. Se você escolher um bando de dados no Norte da Europa, o banco de dados emparelhado deve estar no Sul da Europa.

Alta disponibilidade através das regiões

Atualmente os sites do Azure suportam várias regiões. Está trabalhando também na expansão de sua infraestrutura. As arquiteturas que usam várias regiões podem ser classificadas em sites ativos-ativos e sites ativos-passivos.

Sites ativos-ativos: Em uma arquitetura ativa-ativa, você terá vários sites através de regiões servindo o mesmo aplicativo. Neste caso, o tráfego é gerenciado através de todos os sites, portanto eles são todos considerados ativos.

Sites ativos-passivos: Em uma arquitetura ativa-passiva, você terá um único site que atuará como um site primário. Isto servirá como o conteúdo para todos os tráfegos de cliente. Durante uma falha neste site, os clientes serão redirecionados para outro site configurado e em sincronização com o site primário em um datacenter diferente reduzindo a falha. 

Ao projetar a sua arquitetura para operar através de várias regiões, há alguns desafios que você precisa considerar:

• Sincronização de dados: Isto refere-se a capacidade de fazer um cópia em tempo real do banco de dados através das regiões. Qualquer sistema complexo terá um banco de dados, servidor de arquivos, armazenamento externo e cache—apenas para citar alguns componentes. Ao projetar sua arquitetura, você precisa assegurar que os dados replicados através de várias regiões estejam em sincronia para impedir a quebra de seu aplicativo Web. Isto pode exigir algumas alterações ao código de seu aplicativo para suportar este cenário. Os sites do Azure suportam a execução de um processo em segundo plano chamado de Trabalho Web, que permite que você crie ferramentas personalizadas para gerenciar a sincronização de dados.
• Fluxo de rede: Esta é a capacidade de gerenciar tráfego de rede através de várias regiões. O Gerenciador de Tráfego do Azure permite que você faça o balanceamento de carga do tráfego de entrada através de vários sites hospedados, quer estejam executando no mesmo datacenter ou através de datacenters diferentes. Ao gerenciar efetivamente o tráfego, você pode assegurar alto desempenho, disponibilidade e resiliência para seus aplicativos.

Você pode usar o Gerenciador de Tráfego para garantir a alta disponibilidade e capacidade de resposta para seus aplicativos. O Gerenciador de Tráfego fornece três métodos de balanceamento de carga:

1. Failover: Use este método quando desejar usar um ponto de extremidade primário para todos os seus tráfegos, mas forneça um ou mais pontos de extremidade de backup no caso de um ponto de extremidade de backup ou primário se tornar disponível.
2. Round Robin: Com este método, você pode distribuir tráfego igualmente através de um conjunto de pontos de extremidade no mesmo datacenter ou através de diferentes datacenters.
3. Performance: Este método permite solicitar os clientes/usuários a usar o pontos de extremidade mais próximo para reduzir a latência fornecendo pontos de extremidade em diferentes localizações geográficas.

Alta disponibilidade para camada em cache

Para melhorar o desempenho dos seus sites, a camada em cache é crítica. Ao lidar com dados com seu aplicativo, você precisa entender como o cache pode afetar tanto os dados como o aplicativo. Ao escolher a sua camada em cache, considere a necessidade de manter a consistência de dados armazenados através de instâncias em cache. Para evitar inconsistências de dados, você deve usar um mecanismo de cache distribuído. Um cache distribuído pode usar vários servidores, assim é escalável e armazena dados do aplicativo residindo no banco de dados reduzindo o número de chamadas realizadas para o banco de dados.

Há várias soluções em cache baseadas nas nuvens que você pode integrar com os sites do Azure, como o Cache do Azure e o Memcached Cloud. Estes estão disponíveis através da Azure Store no Portal de gerenciamento do Azure.

Monitoramento de desempenho

Agora que você descobriu estratégias de alta disponibilidade para seus sites, você precisará avaliar suas opções de monitoramento. Os sites do Azure fornecem dois tipos de monitoramento no Portal de gerenciamento do Azure:

1. Monitoramento com as métricas do site: Cada painel do site tem uma página Monitor. Isto fornece estatísticas de desempenho para cada site, como uso da CPU, número de solicitações, dados enviados pelo site e assim por diante.
2. Monitoramento de ponto de extremidade: O monitoramento do ponto de extremidade permite que você configure os testes da Web a partir de localizações distribuídas geograficamente que testam o tempo de resposta e o tempo de ativação para as URLs da Web. Cada local configurado executa um teste a cada cinco minutos. O tempo de ativação é monitorado com códigos de respostas HTTP. O tempo de resposta é medido em milissegundos. O tempo de ativação é considerado 100 por cento quando o tempo de resposta é menos do que 30 segundos e o código de status HTTP é menos do que 400. O tempo de ativação é 0 por cento quando o tempo de resposta é maior do que 30 segundos ou o código do status HTTP é maior do que 400. Após você configurar o monitoramento do ponto de extremidade, você pode fazer o detalhamento dons nos pontos de extremidades individuais para exibir detalhes do tempo de resposta e status do tempo de ativação sobre o intervalo de monitoramento de cada um destes locais do teste.

Você pode desempenhar um monitoramento mais detalhado e flexível com o portal de visualização do Azure. Aqui, você pode criar um painel de Operação de Desenvolvimento completo. Figura 3 mostra como o painel de Operação de Desenvolvimento se parece ao executar os sites do Azure.

Figura 3 Um painel típico de Operação de Desenvolvimento

No desenvolvimento para a nuvem, o planejamento do aplicativo, desenvolvimento e teste é geralmente conduzido em outro local, como o Visual Studio Online. O monitoramento da integridade destes aplicativos e a resolução de problemas pode ser realizado ainda em outro portal, como o Application Insights. O faturamento é exibido em uma página separada. Observa um padrão aqui?

Este novo portal reúne todos os recursos da nuvem, membros da equipe e estágios do ciclo de vida do seu aplicativo. Fornece a você um local centralizado para planejar, desenvolver, testar, provisionar, implantar, escalar e monitorar estes aplicativos. Esta abordagem pode ajudar as equipes a adotar uma cultura de Operação de Desenvolvimento ao reunir as perspectivas e capacidades de operações e desenvolvimento de uma maneira significativa. Você pode saber mais sobre isto na postagem do blog, “Building Your Dream DevOps Dashboard with the New Azure Preview Portal,” embit.ly/1sYNRtK.

Opções de recuperação

Às vezes coisas ruins acontecem aos bons aplicativos. Os sites do Azure podem ajudar você a se recuperar automaticamente de falhas nos aplicativos. Geralmente, quando o seu sistema de monitoramento detecta um problema, ele alerta um indivíduo de Operações de alguma maneira. O indivíduo de Operações então vai em frente e reinicia o site para manter as coisas ativadas e em funcionamento novamente.

Você pode configurar o arquivo web.config no seu aplicativo para detectar e atuar nas situações. Por exemplo, se o número X de solicitações usa o tempo Y para executar no tempo Z, depois executa a ação ABC (que pode ser reiniciar o site, registrar um evento ou executar uma ação personalizada). Outro exemplo pode ser se meu processo usa uma memória X, depois executa a ação ABC. Saiba mais sobre os procedimentos de recuperação a partir do blog do Microsoft Azure Blog em bit.ly/LOSEvS.

Enquanto as arquiteturas geograficamente redundantes fornecem proteção das falhas relacionadas à infraestrutura, os recursos, tais como recuperação automatizadas ajudam a construir uma resiliência de camada de aplicativo. No mundo de computação em nuvem, os cliente estão sempre dispostos a se recuperar primeiro em relação à realizar um diagnóstico completo enquanto o site está fora. Por outro lado, há outras situações e cenários onde os diagnósticos são essenciais.

Ferramentas de diagnósticos

Os diagnósticos são semelhantes a descascar uma cebola estragada. Você nunca sabe quantas camadas você precisa descascar. Os sites do Azure é uma plataforma como serviço (PaaS) de vários inquilinos, totalmente gerenciada oferecendo e como tal, não suporta diagnósticos remotos na VM. Isto traz um novo conjunto de desafios. Veja aqui uma lista de ferramentas disponíveis e cenários de diagnósticos para os quais eles são úteis.

Por padrão, este serviço fornece vários tipos de registros em log que ajuda a resolver os problemas. Alguns dos logs incluem Log de Servidor Web, Log de Erro Detalhado, Log de Aplicativo, Rastreamento de Solicitação Falha e assim por diante. Saiba mais sobre os serviços de log em bit.ly/1i0MSou.

O console Kudu é outra ferramenta de diagnóstico. Estes nossos clientes do ponto de extremidade de gerenciamento de configuração de software multiuso usarão com frequência para fins de diagnóstico. Ao fazer logon no ponto de extremidade Kudu, você verá opções de diagnóstico diferentes na faixa de opções superior (consulte a Figura 4).

Figura 4 O console Kudu fornece ferramentas de diagnóstico

A guia Ambiente fornece a você uma exibição somente leitura de coisas como Informações do sistema, Configurações de aplicativo, Cadeias de Conexão, Variáveis de ambiente, Caminhos do sistema, Cabeçalhos HTTP e Variáveis do servidor específicas para seu site e VMs. Isto sempre funciona bem como uma ajuda para investigações contínuas com diferentes pontos de dados.  

A guia Console de Depuração fornece a você um console de execução remota baseado no CMD ou no Windows PowerShell e acesso ao navegador de arquivos para seus sites. Você pode usar o console para executar a maioria das operações de console padrão e comandos externos arbitrários, como os comandos Git, navegar a interface de usuário da pasta, baixar arquivos e pastas, carregar arquivos e pastas usando arrastar e soltar, exibir e editar arquivos de texto e assim por diante. Saiba mais sobre isto assistindo ao vídeo do YouTube, “The Azure Web Sites Diagnostic Console,” em bit.ly/1h0ZZoR.

A guia Process explorer fornece a você uma lista de processos atualmente ativos que seu aplicativo é capaz de ver e se comunicar dentro da área de segurança dos sites do Azure. Esta exibição fornecerá a você informações sobre a memória do processo e uso da CPU. Você pode também considerar as informações detalhadas sobre um determinado processo, gerar e baixar despejos de memória completos para diagnósticos offline e assim por diante.

O guia Despejo de diagnóstico fornecerá a você um despejo de memória em um arquivo .zip para baixar. Você pode então usar o analisador de despejo como o DebugDiag para analisar rapidamente o despejo de memória e obter orientações prescritivas.

A guia Fluxos de log permite que você transmita ao vivo HTTP ou logs de aplicativo diretamente para o console. Isto é útil para resolver um problema ativo. Saiba mais sobre isto lendo a postagem de blog do Scott Hanselman, “Streaming Diagnostics Trace Logging from the Azure Command Line (plus Glimpse!),” em bit.ly/1jXwy7q.

Isto não é uma lista abrangente de ferramentas de depuração de forma alguma. A Microsoft planeja desenvolver diagnósticos mais sofisticados, onde alguns dos cenários mais comumente usados necessitarão de apenas um clique. Até lá, aproveite criar bons aplicativos que são resistente à falha.

Apurva Joshi é um gerente de programa sênior da Microsoft e trabalha na equipe dos sites do Azure. Ele ingressou na Microsoft em 2002 e trabalhou em várias tecnologias da Web como IIS e ASP.NET.

Sunitha Muthukrishna é uma gerente de programa na Microsoft e trabalha na equipe dos sites do Azure. Ela ingressou na Microsoft em 2011 e tem trabalhado na galeria de aplicativos Web do Windows e em sites do Azure. Anteriormente, ela contribuiu com os projetos de TI para duas organizações sem fins lucrativos, como a rede Community Empowerment e o Institute of Systems Biology, ambos localizados em Seattle, Washington.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Equipe de gerenciamento de produção do Microsoft Azure