Desenvolver aplicativos do Azure confiáveis

Criar um aplicativo confiável na nuvem é diferente do desenvolvimento de aplicativos tradicional. Embora historicamente você possa ter adquirido níveis de hardware redundante de alto nível para minimizar a chance de uma plataforma de aplicativo inteira falhar, na nuvem, confirmamos antecipadamente que ocorrerão falhas. Em vez de tentar evitar completamente a falha, a meta é minimizar os efeitos de uma falha em um componente individual. As falhas que você pode esperar aqui são inerentes a sistemas altamente distribuídos, não um recurso do Azure.

Pontos Principais

  • Use Zonas de Disponibilidade quando aplicável para melhorar a confiabilidade e otimizar os custos.
  • Crie aplicativos para operar quando impactados por falhas.
  • Use os recursos de resiliência nativa do PaaS para dar suporte à confiabilidade geral do aplicativo.
  • Design para escalar horizontalmente.
  • Valide se a capacidade necessária está dentro dos limites e das cotas de escala de serviço do Azure.

Usar Zonas de Disponibilidade dentro de uma região

Se seus requisitos exigirem um isolamento de falha ainda maior do que Zonas de Disponibilidade sozinho pode oferecer, considere a implantação em várias regiões. Várias regiões devem ser usadas para fins de failover em um estado de desastre. O custo adicional precisa ser levado em consideração. Exemplos de necessidades de custo são dados e rede, e serviços como Azure Site Recovery.

Projete a arquitetura do aplicativo para usar zonas de disponibilidade em uma região. Zonas de Disponibilidade pode ser usado para otimizar a disponibilidade do aplicativo dentro de uma região, fornecendo tolerância a falhas no nível do datacenter. No entanto, a arquitetura do aplicativo não deve compartilhar dependências entre zonas para usá-las com eficiência.

Observação

Zonas de Disponibilidade pode introduzir considerações de desempenho e custo para aplicativos que são extremamente "informais" entre zonas dadas a separação física implícita entre cada zona e encargos de largura de banda entre zonas. Isso também significa que Zonas de Disponibilidade pode ser considerada para obter um SLA maior para um custo mais baixo.

Considere se a proximidade do componente é necessária para os motivos de desempenho do aplicativo. Se todo ou parte do aplicativo for altamente sensível à latência, ele poderá exigir a colocalização do componente, o que pode limitar a aplicabilidade de estratégias de várias regiões e de várias zonas.

Responder à falha

Evitar falhas é impossível na nuvem pública e, como resultado, os aplicativos exigem resiliência para responder a interrupções e fornecer confiabilidade. O aplicativo deve, portanto, ser projetado para operar mesmo quando impactado por falhas regionais, zonais, de serviço ou de componente em cenários e funcionalidades de aplicativos críticos. As operações de aplicativo podem ter funcionalidade reduzida ou degradar o desempenho durante uma interrupção.

Defina uma estratégia de disponibilidade para capturar como o aplicativo permanece disponível quando estiver em um estado de falha. Ele deve ser aplicado em todos os componentes do aplicativo e no selo de implantação do aplicativo como um todo, como por meio da abordagem de implantação de unidade de escala geográfica. Também há implicações de custo: mais recursos precisam ser provisionados com antecedência para fornecer alta disponibilidade. A configuração ativa-ativa, embora mais cara do que a implantação única, pode balancear o custo reduzindo a carga em um carimbo e reduzindo a quantidade total de recursos necessários.

Além de uma estratégia de disponibilidade, defina uma estratégia de recuperação de desastre de continuidade de negócios (BCDR) para o aplicativo e/ou seus principais cenários. Uma estratégia de recuperação de desastres deve capturar como o aplicativo responde a uma situação de desastre, como uma interrupção regional ou a perda de um serviço de plataforma crítico, usando uma abordagem de reimplantação, ativo-passivo de quente ou ativo-ativo de hot spare.

Para impulsionar o custo, considere dividir os componentes e os dados do aplicativo em grupos. Por exemplo:

  • Deve proteger
  • Bom para proteger
  • Efêmero/pode ser recriado/perdido, em vez de proteger todos os dados com a mesma política

Considerações para melhorar a confiabilidade

O aplicativo foi projetado para usar serviços gerenciados?


Os serviços gerenciados do Azure fornecem recursos de resiliência nativa para dar suporte à confiabilidade geral do aplicativo. As ofertas de PaaS (plataforma como serviço) devem ser usadas para aproveitar esses recursos. As opções de PaaS são mais fáceis de configurar e administrar. Você não precisa provisionar máquinas virtuais, configurar VNets, gerenciar atualizações e patches e toda a outra sobrecarga associada à execução de software em uma máquina virtual. Para saber mais, confira usar serviços gerenciados.

O aplicativo foi projetado para escalar horizontalmente?


O Azure fornece escalabilidade elástica e você deve projetar para escalar horizontalmente. No entanto, os aplicativos devem aproveitar uma abordagem de unidade de escala para navegar pelos limites de serviço e assinatura para garantir que os componentes individuais e o aplicativo como um todo possam ser dimensionados horizontalmente. Não se esqueça de reduzir horizontalmente, o que é importante para reduzir o custo. Por exemplo, reduzir e reduzir horizontalmente para o serviço de aplicativo é feito por meio de regras. Geralmente, os clientes escrevem regras de expansão e nunca gravam a escala em regras. Isso deixa o serviço de aplicativo mais caro.

O aplicativo é implantado em várias assinaturas do Azure?


Compreender o panorama da assinatura do aplicativo e como os componentes são organizados dentro ou entre assinaturas é importante ao analisar se os limites de assinatura ou cotas relevantes podem ser navegados. Examine a assinatura do Azure e os limites de serviço para validar se a capacidade necessária está dentro das cotas e limites de escala de serviço do Azure. Para saber mais, confira assinatura e limites de serviço do Azure.

Próxima etapa

Volte para o artigo principal: design