Este artigo mostra como planejar uma implementação do padrão Reliable Web App. O padrão Reliable Web App é 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 dessas diretrizes, há uma implementação de referência do padrão Reliable Web App que você pode implantar.
Arquitetura de arquitetura de implementação de referência. Baixe um arquivo Visio desta arquitetura.
As orientações a seguir usam a implementação de referência como um exemplo em todo o texto. Para planejar uma implementação do padrão Reliable Web App, siga estas etapas:
Definir objetivos de negócio
O passo inicial na transição para a computação em nuvem é articular seus objetivos de negócios. O padrão Reliable Web App enfatiza a importância de definir objetivos imediatos e futuros para seu aplicativo Web. Estes objetivos influenciam a sua escolha de serviços na nuvem e a arquitetura da sua aplicação Web na nuvem.
Exemplo: a empresa fictícia, Contoso Fiber, queria expandir seu aplicativo Web CAMS (Customer Account Management System) local para alcançar outras regiões. Para atender ao aumento da demanda no aplicativo web, eles estabeleceram as seguintes metas:
- Aplique alterações de código de baixo custo e alto valor
- Atingir um objetivo de nível de serviço (SLO) de 99,9%
- Adote práticas de DevOps
- Crie ambientes otimizados em termos de custos
- Melhorar a fiabilidade 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 alcançar seus objetivos imediatos e futuros.
Escolha os serviços gerenciados certos
Ao mover um aplicativo Web para a nuvem, você deve selecionar os serviços do Azure que atendem aos seus requisitos de negócios e se alinham com os 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ção para selecionar os serviços do Azure certos 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. É voltado para o funcionário. Os funcionários da Contoso Fiber usam o aplicativo para gerenciar casos de suporte de seus clientes. O aplicativo Web local sofre de desafios comuns. Esses desafios incluem prazos estendidos para criar e enviar novos recursos e dificuldade em dimensionar diferentes componentes de aplicativos sob carga mais alta.
Plataforma de aplicação
Escolha a melhor plataforma de hospedagem de aplicativos 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 a execução de aplicativos Spring Boot, e foi uma progressão natural para a Contoso Fiber usar o Serviço de Aplicativo. O Azure Spring Apps também é uma alternativa atraente para este aplicativo. Se o aplicativo Web Contoso Fiber CAMS usasse Jakarta EE em vez do Spring Boot, o Azure Spring Apps seria mais adequado. Para obter mais informações, consulte O que é o Azure Spring Apps? e Java EE, Jakarta EE e MicroProfile no Azure.SLA alto. Ele tem um alto SLA que atende aos requisitos para o ambiente de produção.
Redução das despesas gerais de gerenciamento. É uma solução de hospedagem totalmente gerenciada.
Capacidade de contentorizaçã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 colocar o aplicativo Web em contêineres no futuro.
Dimensionamento automático. O aplicativo Web pode aumentar e reduzir, entrar e sair rapidamente com base no tráfego do usuário.
Gestão 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 lida com autenticação e autorização de funcionários.
Escalabilidade. Ele é dimensionado para suportar cenários maiores.
Controle de identidade do usuário. Os funcionários podem usar suas identidades corporativas existentes.
Suporte para protocolos de autorização. Ele suporta OAuth 2.0 para identidades gerenciadas.
Base de Dados
Escolha o melhor banco de dados para seu aplicativo Web. Para obter ajuda com o estreitamento das opções, consulte a árvore de decisão do repositório 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:
Fiabilidade. 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 e mantém um servidor em espera ativa em uma zona de disponibilidade diferente dentro da mesma região do Azure. A configuração replica 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 usando dados de uso real.
Redução das despesas gerais de gerenciamento. É um serviço do Azure totalmente gerenciado que reduz as obrigações de gerenciamento.
Suporte da migração. Ele suporta a migração de banco de dados de bancos 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 suporta diferentes versões da comunidade do PostgreSQL, incluindo a versão que a Contoso Fiber usa atualmente.
Resiliência. A implantação flexível do servidor cria automaticamente backups do servidor e os armazena usando o armazenamento com redundância de zona (ZRS) na mesma região. Eles podem restaurar seu banco de dados para qualquer point-in-time 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:
Deteção de anomalias. Deteta automaticamente anomalias de desempenho.
Resoluçã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 você deseja rastrear em 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 oferece fácil integração com a plataforma e o código do aplicativo.
Cache
Escolha se deseja adicionar cache à arquitetura do seu aplicativo Web. O Cache Redis do Azure é a principal solução de cache do Azure. É um armazenamento de dados gerenciado na memória baseado 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 comumente acessados e de mudança lenta.
Capacidade de suporte diversificada. É um local de cache unificado que todas as instâncias do aplicativo Web podem usar.
Armazenamento de dados externos. Os servidores de aplicativos locais executaram o cache local da VM. Essa configuração não descarregava dados muito frequentados e não podia invalidar dados.
Sessões antiaderentes. O cache permite que o aplicativo Web externalize o estado da sessão usando sessões não aderentes. A maioria dos aplicativos Web Java executados no local usa cache na memória, do lado do cliente. Na memória, o cache do lado do cliente não é bem dimensionado e aumenta o espaço de memória no host. Usando o Cache do Azure para Redis, a Contoso Fiber tem um serviço de cache totalmente gerenciado e escalável 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 o estreitamento das opções, consulte Escolher o melhor balanceador de carga para seu aplicativo.
Exemplo: a Contoso Fiber escolheu Front Door como o balanceador de carga global pelos seguintes motivos:
Flexibilidade de roteamento. Ele permite que a equipe do aplicativo configure as necessidades de entrada para suportar futuras alterações no aplicativo.
Aceleração do tráfego. Ele usa anycast para chegar ao ponto de presença do Azure mais próximo e encontrar a rota mais rápida para o aplicativo Web.
Domínios personalizados. Ele suporta nomes de domínio personalizados com validação de domínio flexível.
Sondas de saúde. O aplicativo precisa de monitoramento inteligente da sonda de integridade. O Azure Front Door usa respostas da sonda para determinar a melhor origem para rotear solicitações de clientes.
Apoio à monitorização. Suporta relatórios integrados com um painel tudo-em-um para portas frontais 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 testes de integridade com falha.
Proteção contra DDoS. Tem built-in camada 3-4 DDoS proteção.
Firewall de aplicações Web
Escolha um firewall de aplicativo Web para proteger seu aplicativo Web contra ataques da Web. O Azure Web Application Firewall (WAF) é o firewall de aplicativos Web do Azure e fornece proteção centralizada contra vulnerabilidades e explorações da Web comuns.
Exemplo: a Contoso Fiber escolheu o Firewall de Aplicativo Web para os seguintes benefícios:
Proteção global. Ele fornece maior proteção global de aplicativos Web sem sacrificar o desempenho.
Proteção contra botnets. Você pode configurar regras de proteção de bot para monitorar ataques de botnet.
Paridade com o local. A solução local estava sendo executada atrás de um firewall de aplicativo Web gerenciado pela TI.
Gestor de segredos
Use o Azure Key Vault se tiver segredos para gerenciar no Azure.
Exemplo: a Contoso Fiber tem segredos para gerenciar. Eles usaram o Key Vault pelos seguintes motivos:
Encriptação. Suporta encriptação em repouso e em trânsito.
Suporta identidades gerenciadas. Os serviços de aplicativo podem usar identidades gerenciadas para acessar o armazenamento secreto.
Monitorização e início de sessão. Facilita o acesso à auditoria e gera alertas quando os segredos armazenados mudam.
Integração. Ele suporta 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 de pontos finais
Escolha habilitar o acesso privado somente aos serviços do Azure. O Azure Private Link fornece acesso a soluções de plataforma como serviço através de um ponto de extremidade privado na sua rede virtual. O tráfego entre a sua rede virtual e o serviço viaja através da rede de backbone da Microsoft.
Exemplo: a Contoso Fiber escolheu Private Link pelos seguintes motivos:
Segurança reforçada. Ele permite que o aplicativo acesse serviços de forma privada no Azure e reduz a pegada de rede dos armazenamentos de dados para ajudar a proteger contra vazamento de dados.
Esforço mínimo. Os pontos de extremidade privados suportam a plataforma do aplicativo Web e a 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 corretos, 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.
Escolher redundância de arquitetura
As metas de negócios determinam o nível de infraestrutura e 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 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 sejam da Microsoft.
Atribua uma estimativa de disponibilidade para cada dependência. Os contratos de nível de serviço (SLAs) 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 de arquitetura.
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 está alinhada com o objetivo da Contoso Fiber de alterações mínimas de código para esta fase da jornada na nuvem. A configuração ativo-passivo fornece uma estratégia de dados simples. Ele evita a necessidade de configurar a 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 Fibra Contoso 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 da Web e de rede. Uma topologia de rede hub e spoke é a configuração padrão no Azure. Ele oferece benefícios de custo, gerenciamento e segurança. Ele também suporta opções de conectividade híbrida para redes locais.
Exemplo: a Contoso Fiber escolheu uma topologia de rede hub and spoke para aumentar a segurança de sua implantação em várias regiões com custo reduzido e sobrecarga de gerenciamento.
Escolher redundância de dados
Garanta a confiabilidade dos dados distribuindo-os pelas regiões e zonas de disponibilidade do Azure; quanto maior for a sua separação geográfica, maior será a fiabilidade.
Defina um RPO (Recovery Point Objetive, objetivo de ponto de recuperação). O RPO define a perda máxima tolerável de dados durante uma interrupçã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 dá suporte à replicação síncrona em zonas de disponibilidade. Utilize várias zonas para melhorar a confiabilidade facilmente. Para aplicativos Web de várias regiões em uma configuração ativo-passivo, replique 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.
Crie um plano de failover. Desenvolva um plano de failover (recuperação de desastres) descrevendo estratégias de resposta a interrupções, determinadas por tempo de inatividade ou 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 do 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 é replicado de forma assíncrona para a réplica de leitura na região passiva. A Contoso Fiber criou um plano de failover de exemplo. A réplica de leitura do Banco de Dados do Azure para PostgreSQL é fundamental para o plano de failover da Contoso Fiber.
Próximo passo
Este artigo mostrou como planejar uma implementação do padrão Reliable Web App. A próxima etapa é aplicar as técnicas de implementação do padrão Reliable Web App.