Metodologia de design para cargas de trabalho críticas no Azure

A criação de um aplicativo crítico em qualquer plataforma de nuvem requer conhecimento técnico significativo e investimento em engenharia, especialmente porque há uma complexidade significativa associada a:

• Noções básicas sobre a plataforma de nuvem,
• Escolhendo os serviços e a composição corretos,
• Aplicando a configuração de serviço correta,
• Operacionalizando serviços utilizados e
• Alinhando-se constantemente com as práticas recomendadas e os roteiros de serviço mais recentes.

Essa metodologia de design se esforça para fornecer um caminho de design fácil de seguir para ajudar a navegar nessa complexidade e informar as decisões de design necessárias para produzir uma arquitetura de destino ideal.

1 – Design para requisitos de negócios

Nem todas as cargas de trabalho críticas têm os mesmos requisitos. Espere que as considerações de revisão e as recomendações de design fornecidas por essa metodologia de design gerem diferentes decisões de design e compensações para diferentes cenários de aplicativo.

Selecionar uma camada de confiabilidade

A confiabilidade é um conceito relativo e, para que qualquer carga de trabalho seja adequadamente confiável, ela deve refletir os requisitos de negócios que a cercam. Por exemplo, uma carga de trabalho crítica com um SLO (Objetivo de Nível de Serviço) de disponibilidade de 99,999% requer um nível muito maior de confiabilidade do que outra carga de trabalho menos crítica com um SLO de 99,9%.

Essa metodologia de design aplica o conceito de camadas de confiabilidade expressas como SLOs de disponibilidade para informar as características de confiabilidade necessárias. A tabela a seguir captura os orçamentos de erro permitidos associados a camadas de confiabilidade comuns.

Camada de confiabilidade (SLO de disponibilidade)	Tempo de inatividade permitido (semana)	Tempo de inatividade permitido (mês)	Tempo de inatividade permitido (ano)
99,9%	10 minutos, 4 segundos	43 minutos e 49 segundos	8 horas, 45 minutos, 56 segundos
99,95%	5 minutos, 2 segundos	21 minutos, 54 segundos	4 horas, 22 minutos, 58 segundos
99,99%	1 minuto	4 minutos e 22 segundos	52 minutos, 35 segundos
99,999%	6 segundos	26 segundos	5 minutos e 15 segundos
99.9999%	<1 segundo	2 segundos	31 segundos

Importante

O SLO de disponibilidade é considerado por essa metodologia de design mais do que um tempo de atividade simples, mas sim um nível consistente de serviço de aplicativo em relação a um estado de aplicativo íntegro conhecido.

Como um exercício inicial, os leitores são aconselhados a selecionar uma camada de confiabilidade de destino determinando quanto tempo de inatividade é aceitável? A busca de uma camada de confiabilidade específica terá, em última análise, uma influência significativa no caminho de design e nas decisões de design englobadas, o que resultará em uma arquitetura de destino diferente.

Esta imagem mostra como as diferentes camadas de confiabilidade e os requisitos de negócios subjacentes influenciam a arquitetura de destino para uma implementação de referência conceitual, especialmente no que diz respeito ao número de implantações regionais e tecnologias globais utilizadas.

O RTO (Objetivo de Tempo de Recuperação) e o RPO (Objetivo de Ponto de Recuperação) são aspectos mais críticos ao determinar a confiabilidade necessária. Por exemplo, se você estiver se esforçando para alcançar um RTO de aplicativo de menos de um minuto, as estratégias de recuperação baseadas em backup ou uma estratégia de implantação ativa-passiva provavelmente serão insuficientes.

2 – Avaliar as áreas de design usando os princípios de design

No centro dessa metodologia está um caminho de design crítico composto por:

• Princípios de design fundamentais
• Área de design fundamental com decisões de design fortemente inter-relacionadas e dependentes.

O impacto das decisões tomadas em cada área de design reverberará em outras áreas de design e decisões de design. Examine as considerações e recomendações fornecidas para entender melhor as consequências das decisões englobadas, que podem produzir compensações dentro de áreas de design relacionadas.

Por exemplo, para definir uma arquitetura de destino, é fundamental determinar a melhor maneira de monitorar a integridade do aplicativo entre os principais componentes. É altamente recomendável que você examine a área de design de modelagem de integridade, usando as recomendações descritas para ajudar a impulsionar as decisões.

3 – Implantar seu primeiro aplicativo crítico

Consulte essas arquiteturas de referência que descrevem as decisões de design com base nessa metodologia.

• Arquitetura de linha de base de um aplicativo voltado para a Internet

• Arquitetura de linha de base de um aplicativo voltado para a Internet com controles de rede

Dica

A arquitetura é apoiada pela implementação do Mission-Critical Online que ilustra as recomendações de design.

Artefatos de nível de produção Cada artefato técnico está pronto para uso em ambientes de produção com todos os aspectos operacionais de ponta a ponta considerados.

Enraizado em experiências do mundo real Todas as decisões técnicas são guiadas por experiências de clientes do Azure e lições aprendidas com a implantação dessas soluções.

Alinhamento do roteiro do Azure As arquiteturas de referência crítica têm seu próprio roteiro alinhado com os roteiros de produtos do Azure.

4 – Integrar sua carga de trabalho em zonas de destino do Azure

As assinaturas da zona de destino do Azure fornecem infraestrutura compartilhada para implantações corporativas que precisam de governança centralizada.

É crucial avaliar qual caso de uso de conectividade é exigido pelo seu aplicativo crítico. As zonas de destino do Azure dão suporte a dois arquétipos main separados em diferentes escopos do Grupo de Gerenciamento: Online ou Corp. conforme mostrado nesta imagem.

Assinatura online

Uma carga de trabalho crítica opera como uma solução independente, sem nenhuma conectividade de rede corporativa direta com o restante da arquitetura da zona de destino do Azure. O aplicativo será protegido ainda mais por meio da governança controlada por políticas e se integrará automaticamente ao registro em log de plataforma centralizado por meio da política.

A arquitetura de linha de base e a implementação do Mission-Critical Online se alinham com a abordagem online.

Assinatura corp.

Quando implantada em uma assinatura Corp. uma carga de trabalho crítica depende da zona de destino do Azure para fornecer recursos de conectividade. Essa abordagem permite a integração com outros aplicativos e serviços compartilhados. Você precisará projetar alguns recursos fundamentais, que existirão antecipadamente como parte da plataforma de serviço compartilhado. Por exemplo, o carimbo de implantação regional não deve mais abranger uma Rede Virtual efêmera ou zona de DNS privado do Azure, pois elas existirão na assinatura Corp.

Para começar a usar esse caso de uso, recomendamos a arquitetura de linha de base em uma arquitetura de referência da zona de destino do Azure .

Dica

A arquitetura anterior tem o apoio da implementação de Missão Crítica Conectada .

5 – Implantar um ambiente de aplicativo de área restrita

Em paralelo às atividades de design, é altamente recomendável que um ambiente de aplicativo de área restrita seja estabelecido usando as implementações de referência Mission-Critical.

Isso oferece oportunidades práticas para validar decisões de design replicando a arquitetura de destino, permitindo que a incerteza de design seja avaliada rapidamente. Se aplicado corretamente com cobertura de requisitos representativos, os problemas mais problemáticos que podem dificultar o progresso podem ser descobertos e resolvidos posteriormente.

6 – Evoluir continuamente com os roteiros do Azure

As arquiteturas de aplicativo estabelecidas usando essa metodologia de design devem continuar evoluindo em alinhamento com os roteiros da plataforma Azure para dar suporte à sustentabilidade otimizada.

Próxima etapa

Examine os princípios de design para cenários de aplicativos críticos.

Princípios de design