Este artigo mostra como planejar uma implementação do padrão de aplicativo Web confiável. O padrão de aplicativo Web confiável é um conjunto de princípios e técnicas de implementação que definem como você deve modificar aplicativos Web (replataforma) ao migrar para a nuvem. Ele se concentra nas atualizações mínimas de código que você precisa fazer para ter sucesso na nuvem.
Para facilitar a aplicação dessa diretriz, há uma implementação de referência do padrão de aplicativo Web confiável que você pode implantar.
Arquitetura da implementação de referência. Baixe um Arquivo Visio dessa arquitetura.
A orientação a seguir usa a implementação de referência como um exemplo em todo o processo. Para planejar uma implementação do padrão de aplicativo Web confiável, siga estas etapas:
Defina as metas de negócios
A etapa inicial na transição para a computação na nuvem é articular seus objetivos de negócios. O padrão de aplicativo Web confiável enfatiza a importância de definir objetivos imediatos e futuros para seu aplicativo Web. Esses objetivos influenciam sua escolha de serviços de nuvem e a arquitetura do seu aplicativo Web na nuvem.
Exemplo: a empresa fictícia, Contoso Fiber, queria expandir seu aplicativo Web CAMS (Sistema de gerenciamento de conta de cliente) local para alcançar outras regiões. Para atender ao aumento da demanda no aplicativo Web, eles estabeleceram as seguintes metas:
- Aplicar alterações de código de baixo custo e de alto valor
- Atingir um objetivo de nível de serviço (SLO) de 99,9%
- Adotar práticas de DevOps
- Criar ambientes com otimização de custo
- Melhorar a confiabilidade e a segurança
A Contoso Fiber determinou que sua infraestrutura local não era uma solução econômica para dimensionar o aplicativo. Então, eles decidiram que migrar seu aplicativo Web CAMS para o Azure era a maneira mais econômica de atingir seus objetivos imediatos e futuros.
Escolha os serviços gerenciados corretos
Ao migrar um aplicativo Web para a nuvem, você deve selecionar os serviços do Azure que atendam aos seus requisitos de negócios e se alinhem aos recursos atuais do aplicativo Web local. O alinhamento ajuda a minimizar o esforço de replataforma. Por exemplo, use serviços que permitem manter o mesmo mecanismo de banco de dados e oferecer suporte a middleware e estruturas existentes. As seções a seguir fornecem orientações para selecionar os serviços do Azure corretos para seu aplicativo Web.
Exemplo: antes da mudança para a nuvem, o aplicativo Web CAMS da Contoso Fiber era um aplicativo Web Java monolítico local. É um aplicativo Spring Boot com um banco de dados PostgreSQL. O aplicativo Web é um aplicativo de suporte de linha de negócios. Ele é voltado para os funcionários. Os funcionários da Contoso Fiber usam o aplicativo para gerenciar casos de suporte de seus clientes. O aplicativo Web local enfrenta desafios comuns. Esses desafios incluem linhas do tempo estendidas para criar e enviar novos recursos e dificuldade para dimensionar diferentes componentes do aplicativo sob uma carga mais alta.
Plataforma de aplicativo
Escolha a melhor plataforma de hospedagem de para seu aplicativo Web. O Azure tem muitas opções de computação diferentes para atender a uma variedade de requisitos de aplicativos Web. Para obter ajuda com opções de estreitamento, consulte a árvore de decisão de computação do Azure.
Exemplo: a Contoso Fiber escolheu o Serviço de Aplicativo do Azure como a plataforma de aplicativo pelos seguintes motivos:
Progressão natural. A Contoso Fiber implantou um arquivo Spring Boot
jarem seu servidor local e queria minimizar a quantidade de rearquitetura para esse modelo de implantação. O Serviço de Aplicativo fornece suporte robusto para executar aplicativos Spring Boot e foi uma progressão natural para a Contoso Fiber usar o Serviço de Aplicativo. Os Azure Spring Apps também são uma alternativa atraente para esse aplicativo. Se o aplicativo Web CAMS da Contoso Fiber usasse o Jakarta EE em vez do Spring Boot, os Azure Spring Apps seriam mais adequados. Para obter mais informações, consulte O que são os Azure Spring Apps? e Java EE, Jakarta EE e MicroProfile no Azure.SLA alto. Possui um alto SLA que atende aos requisitos do ambiente de produção.
Sobrecarga de gerenciamento reduzida. É uma solução de hospedagem totalmente gerenciada.
Funcionalidade de contêinerização. O Serviço de Aplicativo funciona com registros de imagem de contêiner privado, como o Registro de Contêiner do Azure. A Contoso Fiber pode usar esses registros para conteinerizar o aplicativo Web no futuro.
Dimensionamento automático. O aplicativo Web pode escalar verticalmente e reduzir rapidamente com base no tráfego do usuário.
Gerenciamento de identidades
Escolha a melhor solução de gerenciamento de identidade para seu aplicativo Web. Para obter mais informações, consulte Comparar soluções de gerenciamento de identidade e métodos de autenticação.
Exemplo: a Contoso Fiber escolheu o Microsoft Entra ID pelos seguintes motivos:
Autenticação e autorização. Ele gerencia autenticação e autorização de funcionários.
Escalabilidade. Ele é dimensionado para dar suporte a cenários maiores.
Controle de identidade do usuário. Os funcionários podem usar suas identidades empresariais existentes.
Suporte a protocolos de autorização. Ele oferece suporte a OAuth 2.0 para identidades gerenciadas.
Backup de banco de dados
Escolha o melhor banco de dados para seu aplicativo Web. Para obter ajuda com a redução das opções, consulte a árvore de decisão de armazenamento de dados do Azure.
Exemplo: a Contoso Fiber escolheu o Banco de Dados do Azure para PostgreSQL e a opção de servidor flexível pelos seguintes motivos:
Confiabilidade. O modelo de implantação de servidor flexível oferece suporte à alta disponibilidade com redundância de zona em várias zonas de disponibilidade. Essa configuração mantém um servidor em espera quente em uma zona de disponibilidade diferente dentro da mesma região do Azure. A configuração replica os dados de forma síncrona para o servidor em espera.
Replicação entre regiões. Ele tem um recurso de réplica de leitura que permite replicar dados de forma assíncrona para um banco de dados de réplica somente leitura em outra região.
Desempenho. Ele fornece desempenho previsível e ajuste inteligente para melhorar o desempenho do banco de dados utilizando dados de uso real.
Sobrecarga de gerenciamento reduzida. É um serviço do Azure totalmente gerenciado que reduz as obrigações de gerenciamento.
Suporte à migração. Ele oferece suporte à migração de banco de dados PostgreSQL de servidor único local. Eles podem usar a ferramenta de migração para simplificar o processo de migração.
Consistência com configurações locais. Ele oferece suporte a diferentes versões de comunidade do PostgreSQL, incluindo a versão que a Contoso Fiber usa atualmente.
Resiliência. A implantação de servidor flexível cria automaticamente backups de servidor e os armazena usando ZRS (armazenamento com redundância de zona) na mesma região. Eles podem restaurar seu banco de dados para qualquer momento dentro do período de retenção de backup. O recurso de backup e restauração cria um RPO (quantidade aceitável de perda de dados) melhor do que a Contoso Fiber poderia criar localmente.
Monitoramento de desempenho de aplicativos
Escolha um monitoramento de desempenho de aplicativo para seu aplicativo Web. O Application Insights é a solução de gerenciamento de desempenho de aplicativos (APM) nativa do Azure. É um recurso da solução de monitoramento do Azure, o Azure Monitor.
Exemplo: a Contoso Fiber adicionou o Application Insights pelos seguintes motivos:
Detectar anomalias. Ele detecta anomalias de desempenho automaticamente.
Solução de problemas. Ele ajuda a diagnosticar problemas no aplicativo em execução.
Telemetria. Ele coleta informações sobre como os usuários estão usando o aplicativo e permite que você envie facilmente eventos personalizados que deseja acompanhar no seu aplicativo.
Lacuna de visibilidade local. A solução local não tinha uma solução de monitoramento de desempenho de aplicativo. O Application Insights fornece fácil integração com a plataforma e o código do aplicativo.
Cache
Escolha se deseja adicionar cache à arquitetura do aplicativo Web. O Cache do Azure para Redis é a principal solução de cache do Azure. É um armazenamento de dados na memória gerenciado com base no software Redis.
Exemplo: a Contoso Fiber precisava de um cache que fornecesse os seguintes benefícios:
Velocidade e volume. Ele tem alta taxa de transferência de dados e leituras de baixa latência para dados de alteração lenta e comumente acessados.
Suporte diversificado. É um local de cache unificado que todas as instâncias do aplicativo Web podem usar.
Armazenamento de dados externo. Os servidores de aplicativos locais executaram o cache local da VM. Essa configuração não descarregou dados altamente frequentes e não pôde invalidar dados.
Sessões não autoadesivas. O cache permite que o aplicativo Web externalize o estado da sessão usando sessões não adesivas. A maioria dos aplicativos Web Java em execução no local usa cache do lado do cliente na memória. Na memória, o cache do lado do cliente não é bem dimensionado e aumenta o volume de memória no host. Usando o Cache do Azure para Redis, a Contoso Fiber tem um serviço de cache escalonável e totalmente gerenciado para melhorar a escalabilidade e o desempenho de seus aplicativos. A Contoso Fiber estava usando uma estrutura de abstração de cache (Spring Cache) e só precisava de alterações mínimas de configuração para trocar o provedor de cache. Isso permitiu que eles mudassem de um provedor Ehcache para o provedor Redis.
Balanceador de carga
Escolha o melhor balanceador de carga para seu aplicativo Web. O Azure tem vários balanceadores de carga. Para obter ajuda com a redução das opções, consulte Escolher o melhor balanceador de carga para seu aplicativo.
Exemplo: a Contoso Fiber escolheu o Front Door como o balanceador de carga global pelos seguintes motivos:
Flexibilidade de roteamento. Ele permite que a equipe de aplicativos configure as necessidades de entrada para dar suporte a alterações futuras no aplicativo.
Aceleração de tráfego. Ele usa o anycast para alcançar o ponto de presença mais próximo do Azure e encontrar a rota mais rápida para o aplicativo Web.
Domínios personalizados. Ele dá suporte a nomes de domínio personalizados com validação de domínio flexível.
Investigações de integridade. O aplicativo precisa de monitoramento de investigação de integridade inteligente. O Azure Front Door usa respostas da investigação para determinar a melhor origem para roteamento de solicitações de cliente.
Suporte de monitoramento. Ele oferece suporte a relatórios integrados com um painel completo para Front Door e padrões de segurança. Você pode configurar alertas que se integram ao Azure Monitor. Ele permite que o aplicativo registre cada solicitação e teste de integridade com falha.
Proteção contra DDoS. Ele tem proteção interna contra DDoS da camada 3-4.
Firewall do aplicativo Web
Escolha um firewall de aplicativo Web para proteger seu aplicativo Web contra ataques na Web. Firewall de Aplicativo Web do Azure WAF é o Firewall de Aplicativo Web do Azure. Ele fornece proteção centralizada contra vulnerabilidades e explorações comuns na Web.
Exemplo: a Contoso Fiber escolheu o Firewall de Aplicativo Web pelos seguintes benefícios:
Proteção global. Ele fornece proteção de aplicativo Web global aprimorada sem sacrificar o desempenho.
Proteção contra botnet Você pode configurar regras de proteção contra bots para monitorar ataques de botnet.
Paridade com o local. A solução local estava em execução por trás de um firewall de aplicativo Web gerenciado pela TI.
Gerenciador de segredos
Use o Azure Key Vault se você tiver segredos para gerenciar no Azure.
Exemplo: a Contoso Fiber tem segredos para gerenciar. Eles usaram o Key Vault pelos seguintes motivos:
Criptografia. Ele dá suporte à criptografia em repouso e em trânsito.
Dá suporte a identidades gerenciadas. Os serviços de aplicativo podem usar identidades gerenciadas para acessar o repositório de segredos.
Monitoramento e registro em log. Ele facilita o acesso à auditoria e gera alertas quando os segredos armazenados são alterados.
Integração. Ele oferece suporte a dois métodos para o aplicativo Web acessar segredos. A Contoso Fiber pode usar as configurações do aplicativo na plataforma de hospedagem (Serviço de Aplicativo) ou pode fazer referência ao segredo no código do aplicativo (arquivo de propriedades do aplicativo).
Segurança do ponto de extremidade
Opte por habilitar somente o acesso privado aos serviços do Azure. O Link Privado do Azure permite acessar soluções de plataforma como serviço (PaaS) em um ponto de extremidade privado em sua rede virtual. O tráfego entre sua rede virtual e o serviço viaja PELA rede de backbone da Microsoft.
Exemplo: a Contoso Fiber escolheu o Link Privado pelos seguintes motivos:
Segurança aprimorada. Ele permite que o aplicativo acesse serviços no Azure e reduz o volume de rede de armazenamentos de dados para ajudar a proteger contra vazamento de dados.
Esforço mínimo. Os pontos de extremidade privados oferecem suporte à plataforma de aplicativo Web e à plataforma de banco de dados que o aplicativo Web usa. Ambas as plataformas espelham a configuração local existente, portanto, são necessárias alterações mínimas.
Escolha a arquitetura certa
Depois de definir o que significa disponível para seu aplicativo Web e selecionar os serviços de nuvem certos, você precisa determinar a melhor arquitetura para seu aplicativo Web. Sua arquitetura precisa dar suporte aos requisitos de negócios, aos requisitos técnicos e ao objetivo de nível de serviço.
Escolha a redundância de arquitetura
As metas de negócios determinam o nível de infraestrutura e a redundância de dados de que seu aplicativo Web precisa. O SLO do aplicativo Web fornece uma boa linha de base para entender seus requisitos de redundância. Calcule o SLA composto de todas as dependências no caminho crítico de disponibilidade. As dependências devem incluir serviços do Azure e soluções que não são da Microsoft.
Atribua uma estimativa de disponibilidade para cada dependência. Os SLAs (Contratos de Nível de Serviço) fornecem um bom ponto de partida, mas os SLAs não levam em conta o código, as estratégias de implantação e as decisões de conectividade arquitetônica.
Exemplo: a implementação de referência usa duas regiões em uma configuração ativo-passivo. A Contoso Fiber tinha um SLO de 99,9% e precisava usar duas regiões para atender ao SLO. A configuração ativo-passivo se alinha com o objetivo da Contoso Fiber de alterações mínimas de código para essa fase da jornada para a nuvem. A configuração ativo-passivo fornece uma estratégia de dados simples. Ela evita a necessidade de configurar uma sincronização de dados baseada em eventos, fragmentos de dados ou alguma outra estratégia de gerenciamento de dados. Todo o tráfego de entrada segue para a região ativa. Se ocorrer uma falha na região ativa, a Contoso Fiber iniciará manualmente seu plano de failover e roteará todo o tráfego para a região passiva.
Escolha uma topologia de rede
Escolha a topologia de rede certa para seus requisitos de rede e da Web. Hub-spoke é uma topologia de rede de configuração padrão no Azure. Ela oferece benefícios de custo, gerenciamento e segurança. Ela também oferece suporte a opções de conectividade híbrida para redes locais.
Exemplo: a Contoso Fiber escolheu uma topologia de rede hub e spoke para aumentar a segurança de sua implantação em várias regiões com custo reduzido e sobrecarga de gerenciamento.
Escolha a redundância de dados
Garanta a confiabilidade dos dados distribuindo-os entre as regiões e zonas de disponibilidade do Azure. Quanto maior for a separação geográfica, maior será a confiabilidade.
Defina um RPO (objetivo de ponto de recuperação). O RPO define a perda máxima tolerável de dados durante uma paralisação, orientando a frequência com que os dados precisam de replicação. Por exemplo, um RPO de uma hora significa aceitar até uma hora de perda de dados recente.
Implemente a replicação de dados. Alinhe a replicação de dados com sua arquitetura e RPO. O Azure normalmente oferece suporte à replicação síncrona dentro de zonas de disponibilidade. Utilize várias zonas para aumentar a confiabilidade facilmente. Para aplicativos Web de várias regiões em uma configuração ativa-passiva, replique os dados para a região passiva de acordo com o RPO do aplicativo Web, garantindo que a frequência de replicação supere o RPO. As configurações ativo-ativo exigem sincronização de dados quase em tempo real entre regiões, o que pode exigir ajustes de código.
Criar um plano de failover. Desenvolva um plano de failover (recuperação de desastres) descrevendo estratégias de resposta a paralisações, determinadas pelo tempo de inatividade ou pela perda de funcionalidade. Especifique os objetivos de tempo de recuperação (RTO) para o tempo de inatividade máximo aceitável. Verifique se o processo de failover é mais rápido que o RTO. Decida sobre mecanismos de failover automatizados ou manuais para consistência e controle e detalhe o processo de retorno às operações normais. Teste o plano de failover para garantir a eficácia.
Exemplo: para o Banco de Dados do Azure para PostgreSQL, a implementação de referência usa alta disponibilidade redundante de zona com servidores em espera em duas zonas de disponibilidade. O banco de dados também replica de forma assíncrona para a réplica de leitura na região passiva.
Próxima etapa
Esse artigo mostrou como planejar uma implementação do padrão de aplicativo Web confiável. A próxima etapa é aplicar as técnicas de implementação do padrão de aplicativo Web confiável.