Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Azure Container Apps é um serviço totalmente gerido, sem servidor, de alojamento de contentores para implementar microserviços e aplicações contentorizadas.
Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer suporte à resiliência e à recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.
Este artigo descreve como tornar as Aplicações Container resilientes a várias potenciais interrupções e problemas, incluindo falhas transitórias, falhas em zonas de disponibilidade, interrupções regionais e manutenção de serviços. Descreve também como usar backups para recuperar de outros tipos de problemas e destaca informações chave sobre o acordo de nível de serviço (SLA) Container Apps.
Recomendações de implantação de produção
Para aprender como implementar Aplicações Container para suportar os requisitos de fiabilidade da sua solução e como a fiabilidade afeta outros aspetos da sua arquitetura, consulte as melhores práticas de arquitetura para Aplicações Container no Azure Well-Architected Framework.
Visão geral da arquitetura de confiabilidade
Quando usa Aplicações Container, implementa um ambiente que serve como unidade fundamental de implementação e define um limite seguro em torno de um grupo de aplicações container. O ambiente é onde você define as configurações principais, incluindo suporte à zona de disponibilidade e configuração de rede. Os dois tipos de ambientes são ambientes com perfis de carga de trabalho e ambientes apenas de consumo. Para mais informações, consulte Estruturas de computação e faturação em Aplicações de Contentores.
Pode implementar várias aplicações num único ambiente. Cada aplicação executa um ou mais contentores. Um ambiente pode também executar um ou mais jobs, que representam tarefas não interativas. Para mais informações, consulte Contentores em Aplicações de Contentores e Tarefas em Aplicações de Contentores.
Cada aplicação tem uma ou mais réplicas, que representam as instâncias em execução da aplicação. Pode controlar como a sua aplicação escala, incluindo o número mínimo e máximo de réplicas e como a aplicação adiciona e remove réplicas dinamicamente. O agendador da plataforma assegura uma distribuição ótima entre hosts físicos, cumprindo os requisitos mínimos de contagem de réplicas. Para obter mais informações, consulte Definir regras de dimensionamento em aplicativos de contêiner.
O Container Apps suporta a fiabilidade das suas aplicações utilizando diferentes capacidades:
Monitorização automática da saúde: O controlador de entrada incorporado balanceia automaticamente o tráfego entre réplicas saudáveis. Se uma réplica falhar nas verificações de saúde ou se a sua infraestrutura subjacente ficar indisponível durante um longo período, o serviço reinicia automaticamente os contentores falhados ou cria réplicas de substituição. Também redistribui o tráfego para longe de réplicas pouco saudáveis e gere as tentativas de rede no cluster. Esse processo de recuperação automática não requer intervenção do cliente e mantém a contagem de réplicas especificada. Para obter mais informações, consulte Verificações de Saúde.
Resiliência de aplicações através do Dapr: O Container Apps proporciona uma integração estreita com o Dapr, que é um framework que suporta microserviços de produção e aplicações containerizadas. O DAPR inclui funcionalidades que ajudam a melhorar a resiliência, incluindo o tratamento de falhas noutros serviços. Para mais informações, consulte Microserviços com Aplicativos de Contêiner.
Resiliência da infraestrutura para componentes do sistema: Esta resiliência inclui o plano de controlo, controladores de entrada e o tempo de execução do contentor. Nas regiões que têm zonas de disponibilidade, as Aplicações de Contentores fornecem redundância de zonas. Para mais informações, veja Resiliência a falhas em zonas de disponibilidade.
Resiliência a falhas transitórias
Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.
Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.
O Container Apps lida automaticamente com muitas falhas transitórias por meio de seus mecanismos de repetição no nível da plataforma e monitoramento de integridade. Para garantir que as suas aplicações são resilientes a falhas transitórias, tome as seguintes ações:
Configure sondas de saúde que permitam à plataforma detetar e responder a condições de falha específicas da aplicação. Defina limiares de falha e valores de timeout adequados com base nas características de arranque da sua aplicação. Por exemplo, para evitar reinicios prematuros do contentor durante problemas temporários, use um limiar de falha de 3 com um período de 10 segundos para sondas de vivacidade. Para obter mais informações, consulte Verificações de Saúde.
Use políticas de resiliência na descoberta de serviços (pré-visualização) para prevenir proativamente, detetar e recuperar de falhas nos pedidos de serviço. Por exemplo, quando você usa uma política de resiliência, cada solicitação de entrada no aplicativo pode ser repetida automaticamente se houver uma falha transitória que impeça o aplicativo de responder. Para obter mais informações, consulte Resiliência da descoberta de serviço (visualização).
Implemente lógica de retentativas nas suas aplicações para chamadas de serviço externas, ligações a bases de dados e pedidos de API.
Se a sua aplicação usa o Dapr para integrar com serviços de nuvem, use a resiliência do componente Dapr (versão prévia) para configurar tentativas, tempos limite e disjuntores.
Para outras dependências, seu aplicativo deve lidar com falhas transitórias. Use estratégias de recuo exponencial e padrões de circuit breaker ao chamar serviços externos para evitar falhas em cascata durante disrupções de serviços a jusante. As funcionalidades integradas de descoberta de serviços e balançamento de carga das Aplicações em Contentores encaminham automaticamente o tráfego para longe das instâncias com falha, mas as suas políticas de tentativas de nova tentativa a nível da aplicação garantem um tratamento eficiente de problemas transitórios antes que as verificações de integridade a nível da plataforma desencadeiem o reinício dos contentores.
Projetar trabalhos para serem resilientes a falhas transitórias, incluindo falhas durante a execução de trabalhos ou nas suas dependências. Projete os seus processos para retomar a execução caso sejam reiniciados, ou planeie para idempotência, de modo a que possam ser executados novamente sem risco.
Resiliência a falhas na zona de disponibilidade
As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.
Ao criar um ambiente Container Apps, pode ativar a redundância de zonas para distribuir a infraestrutura subjacente por várias zonas de disponibilidade na região Azure escolhida. O Container Apps agenda automaticamente as réplicas de seus aplicativos entre zonas. Esta distribuição ocorre de forma transparente, o que significa que não é necessário especificar a colocação das zonas para réplicas individuais.
A redundância de zona aumenta a resiliência do aplicativo a falhas no nível da zona, garantindo que as réplicas do aplicativo contêiner estejam espalhadas por várias zonas.
O diagrama a seguir mostra uma aplicação em contêiner com redundância por zona com três réplicas. Cada réplica corre numa zona de disponibilidade separada.
Requerimentos
Verifica o suporte regional. A redundância de zona está disponível em todas as regiões que suportam Aplicativos de Contêiner e zonas de disponibilidade.
Para ver quais regiões oferecem suporte a zonas de disponibilidade, consulte Regiões do Azure com suporte a zona de disponibilidade.
Para ver quais as regiões que suportam Aplicações Container, consulte Disponibilidade de Produtos por região.
Use perfis de carga de trabalho. A redundância de zonas está disponível para todos os planos Container Apps, incluindo perfis de carga de trabalho de Consumo e Dedicado.
Habilite a redundância de zona durante a criação do ambiente. Esta definição não pode ser alterada depois de o ambiente ser criado.
Implemente um ambiente Container Apps numa rede virtual. A rede virtual deve estar em uma região que ofereça suporte a zonas de disponibilidade. Certifique-se de que a rede virtual tenha uma sub-rede de tamanho adequado. Ambientes apenas de consumo necessitam de uma sub-rede com um intervalo
/23de Classless Inter-Domain Routing (CIDR) ou maior, enquanto ambientes de perfis de carga de trabalho requerem um/27intervalo CIDR ou maior.Defina o número mínimo de réplicas para pelo menos duas para garantir a distribuição em múltiplas zonas de disponibilidade. Considere definir um número mínimo de réplicas mais elevado se se aplicar alguma das seguintes condições:
Sua carga de pico esperada precisa de mais de duas réplicas.
Deve ser resiliente a múltiplas interrupções simultâneas de zona.
Quer minimizar o tempo de espera para que novas réplicas sejam criadas noutras zonas durante uma falha numa zona.
Custo
Não incorre em custos adicionais para além do preço padrão das Aplicações Container ao ativar a redundância de zonas. Você paga as mesmas taxas por recursos de computação, solicitações e segundos de vCore, independentemente de a redundância de zona estar habilitada ou não. Para mais informações, consulte preços das Apps Container e faturação das Apps Container.
Configurar o suporte à zona de disponibilidade
Crie um ambiente de Aplicativos de Contêiner com redundância de zona. Para instruções de implementação que abrangem o portal Azure, a CLI Azure e o Azure PowerShell, consulte Criar uma aplicação container redundante por zona.
Migrar para uma implementação redundante por zona. Não é possível habilitar a redundância de zona em um ambiente existente de Aplicativos de Contêiner. Para atualizar ambientes existentes que não sejam redundantes por zona, crie um novo ambiente com redundância de zona ativada numa região suportada. Depois, reimplante as suas aplicações de container.
Desative a redundância de zona. A redundância de zonas não pode ser desativada depois de ser ativada durante a criação do ambiente. Se você precisar de uma implantação sem redundância de zona, deverá criar um novo ambiente sem habilitar a opção de redundância de zona ou implantar em uma região que não ofereça suporte a zonas de disponibilidade.
Verifique a redundância da zona. Pode usar o portal Azure, a CLI do Azure e o Azure PowerShell para verificar o estado de redundância de zonas do seu ambiente.
Planejamento e gerenciamento de capacidade
Se uma zona de disponibilidade ficar indisponível, a plataforma Container Apps usa as suas regras de escala para decidir quando substituir quaisquer réplicas perdidas nessa zona. É importante configurar corretamente as suas regras de escala para que o agendador possa tomar decisões adequadas de agendamento.
Para configurar suas regras de escala corretamente, siga estes princípios:
Defina um número mínimo de réplicas que seu aplicativo pode tolerar. Pode demorar um curto período de tempo para que as réplicas perdidas sejam substituídas, pois a plataforma tem de detetar que as réplicas antigas desapareceram. Depois, as novas réplicas devem iniciar e devolver um estado saudável da sonda de prontidão antes de poderem receber pedidos recebidos. Se não conseguir tolerar qualquer período com menos do que o número mínimo de réplicas especificado, considere o excesso de provisionamento para manter a sua aplicação em desempenho mesmo que uma zona fique indisponível.
Defina pedidos de recursos e limites para ajudar o agendador de Aplicações de Contentores a tomar decisões ótimas de colocação entre zonas. Requisitos de recursos subespecificados podem levar a falhas de distribuição ou posicionamento desiguais durante cargas elevadas.
Para mais informações sobre opções de configuração, veja Definir regras de escalabilidade.
Comportamento quando todas as zonas estão íntegras
Esta seção descreve o que esperar quando os recursos de Aplicativos de Contêiner são configurados para redundância de zona e todas as zonas de disponibilidade estão operacionais.
Encaminhamento do tráfego entre zonas: Com Aplicações Container redundantes por zona, a plataforma opera num modelo ativo-ativo onde múltiplas réplicas servem simultaneamente o tráfego. O controlador de entrada distribui os pedidos recebidos por todas as réplicas saudáveis, independentemente da sua zona, e utiliza o balanceamento de carga round-robin por defeito. Cada zona processa pedidos de forma independente, e a plataforma não prioriza nenhuma zona específica para a distribuição do tráfego. As sondas de saúde são originadas de todas as zonas para garantir uma avaliação precisa da integridade de cada réplica de várias perspetivas.
Replicação de dados entre zonas: O Container Apps não replica dados de aplicações entre zonas porque foi concebido para cargas de trabalho sem estado. Qualquer dado que a sua aplicação armazene em armazenamento efémero, incluindo armazenamento com âmbito de contentor e armazenamento com âmbito de réplica, é eliminado quando o contentor ou réplica é parado.
Para requisitos de dados com estado, monte um compartilhamento de ficheiros do Azure configurado para armazenamento com redundância de zona ou use outros serviços do Azure, como o Azure Cosmos DB ou o Azure SQL Database, que fornecem as suas próprias capacidades de replicação entre zonas.
A plataforma replica apenas os metadados do plano de controle, incluindo as configurações do seu aplicativo, regras de dimensionamento e segredos entre zonas para alta disponibilidade. As imagens de contêiner são extraídas do seu registro de contêiner para cada zona, conforme necessário, quando as réplicas são criadas.
Comportamento durante uma falha de zona
Esta seção descreve o que esperar quando os recursos de Aplicativos de Contêiner são configurados para redundância de zona e há uma interrupção da zona de disponibilidade.
Deteção e resposta: O Azure deteta automaticamente falhas de zona. Os Aplicativos de Container param imediatamente de agendar novas réplicas para a zona afetada e começam a redistribuir o tráfego para réplicas saudáveis nas zonas restantes. A plataforma lida com todas as operações de failover automaticamente sem exigir sua intervenção.
Notificação: A Microsoft não o notifica automaticamente quando uma zona está inativa. No entanto, você pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Integridade do Serviço para notificá-lo sobre problemas.
Você também pode monitorar a integridade de seus aplicativos por meio das métricas de Aplicativos de Contêiner no Azure Monitor. Configure alertas sobre quedas no número de réplicas e solicite taxas de falha para receber notificações imediatas quando ocorrerem problemas relacionados com a zona.
Pedidos ativos: Pedidos em voo para réplicas na zona falhada podem ser ignorados, ou sofrer timeouts ou erros de ligação. Qualquer execução de trabalho que corra na zona afetada é abortada e marcada como falhada.
Perda de dados esperada: Não ocorre perda de dados ao nível da plataforma Container Apps porque o serviço foi concebido para cargas de trabalho sem estado. Todos os dados armazenados em armazenamento efêmero dentro da zona de disponibilidade são perdidos quando a réplica é encerrada, e o armazenamento efêmero só deve ser usado para dados temporários.
Tempo de inatividade previsto: As aplicações experienciam pouco ou nenhum tempo de inatividade durante falhas de zona. O impacto real depende das configurações da sonda de integridade da aplicação e do número de réplicas em zonas saudáveis. Certifique-se de que os clientes seguem as orientações de tratamento de falhas transitórias para minimizar quaisquer efeitos.
Qualquer trabalho que seja executado na zona afetada é abortado e marcado como falhado. Se precisar que um trabalho seja resiliente a uma falha de zona, configure as tentativas ou o paralelismo para que o trabalho execute múltiplas cópias da mesma execução. Para obter mais informações, consulte Configuração avançada de tarefas.
Redirecionamento de tráfego: As sondas de integridade do controlador de tráfego de entrada detetam rapidamente réplicas inacessíveis e removem-nas do pool de balanceamento de carga. Dependendo da configuração da sonda de saúde da sua aplicação, este processo de failover ocorre normalmente em cerca de 30 segundos. O tráfego de entrada subsequente é distribuído pelas réplicas saudáveis restantes. Este redirecionamento de tráfego ocorre de forma transparente para os clientes, que continuam a usar a mesma URL da aplicação.
Se a afinidade de sessão estiver ativada e uma zona cair, os clientes que anteriormente eram encaminhados para réplicas nessa zona passam a ser redirecionados para novas réplicas porque as anteriores já não estão disponíveis. Qualquer estado associado às réplicas anteriores é perdido.
Não serão iniciados novos casos de empregos na zona defeituosa.
Gestão de instâncias: Novas instâncias de réplica podem ser criadas em zonas saudáveis se as suas regras de dimensionamento automático forem ativadas baseadas no aumento da carga.
Recuperação de zona
Quando uma zona de disponibilidade se recupera de uma falha, os Aplicativos de Contêiner reintegram automaticamente a zona no serviço ativo sem exigir sua intervenção. As sondas de saúde da plataforma detetam quando a infraestrutura na zona recuperada fica disponível e o Container Apps começa a agendar novas réplicas para essa zona com base na sua configuração de escalabilidade. As réplicas existentes em zonas saudáveis continuam a servir o tráfego durante o processo de reintegração, o que ajuda a prevenir interrupções no serviço.
O Container Apps reequilibra gradualmente a distribuição de réplicas em todas as zonas disponíveis como parte das operações normais de dimensionamento. Este reequilíbrio automático ocorre quando réplicas são criadas devido a eventos de escalabilidade ou quando réplicas defeituosas são substituídas. A plataforma não força a redistribuição imediata de réplicas íntegras existentes, o que evita reinicializações desnecessárias de contêineres e mantém a estabilidade do aplicativo durante a recuperação.
Teste de falhas de zona
A plataforma Container Apps gere o encaminhamento de tráfego, comutação em caso de falha e retorno à normalidade para aplicações de contentores com redundância de zona. Esse recurso é totalmente gerenciado, portanto, você não precisa iniciar ou validar processos de falha na zona de disponibilidade.
Para validar a resiliência da sua aplicação a falhas de zona, simule perturbações ao nível da zona na camada da aplicação utilizando abordagens de teste controladas. Pare ou remova réplicas de zonas específicas reduzindo a sua aplicação e monitorize como as réplicas restantes lidam com o aumento da carga. Monitorize métricas-chave durante os testes de resiliência, incluindo a contagem de réplicas, taxas de sucesso dos pedidos, tempos de resposta e comportamento de autoescalonamento. Assegure que o número mínimo de réplicas mantém a disponibilidade de serviço quando as réplicas são removidas e verifique se as suas regras de escalabilidade conseguem suportar o aumento da carga nas réplicas restantes. Teste as suas configurações de sondas de saúde falhando deliberadamente os endpoints de saúde para confirmar que a plataforma remove instâncias não saudáveis da rotação durante os seus períodos de tempo esperados.
Resiliência a falhas em toda a região
Container Apps é um serviço de região única. Se a região ficar indisponível, seu ambiente e aplicativos também ficarão indisponíveis.
Soluções personalizadas de várias regiões para resiliência
Para reduzir o risco de uma falha de uma única região afetar seu aplicativo, você pode implantar ambientes em várias regiões. As seguintes medidas ajudam a reforçar a resiliência:
Implemente as suas aplicações em ambientes em cada região. Cada ambiente requer a sua própria configuração de rede virtual, e os requisitos de sub-rede aplicam-se independentemente a cada implementação regional. As imagens dos seus contentores devem estar disponíveis em todas as regiões, o que pode conseguir usando o Azure Container Registry com a geo-replicação ativada.
Configure políticas de balanceamento de carga e failover usando um serviço como o Azure Front Door ou o Azure Traffic Manager.
Replique seus dados entre regiões para que você possa recuperar o estado do último aplicativo.
Backup e restauração
O Container Apps não fornece recursos de backup internos para seus aplicativos ou dados. Como uma plataforma de hospedagem de contêineres sem estado, o Container Apps espera que as aplicações gerenciem suas próprias estratégias de persistência e recuperação de dados por meio de serviços externos. Os contêineres de aplicativos e seus sistemas de arquivos locais são efêmeros, e todos os dados armazenados localmente são perdidos quando as réplicas são reiniciadas ou movidas.
Resiliência durante atualizações de aplicativos
Use o gerenciamento de revisões para implantar atualizações em seu aplicativo sem tempo de inatividade. Pode criar novas revisões com imagens de contentores atualizadas e realizar um cutover usando uma estratégia de implementação azul-verde, ou deslocar gradualmente o tráfego usando regras de divisão de tráfego. Durante as atualizações da aplicação, a plataforma mantém o número mínimo de réplicas criando novos contentores antes de desativar os antigos, o que ajuda a prevenir interrupções no serviço.
Para mais informações, consulte Atualizar e implementar alterações nas Aplicações Container.
Resiliência à manutenção de serviços
O Container Apps realiza a manutenção automática da plataforma para aplicar atualizações de segurança, implantar novos recursos e melhorar a confiabilidade do serviço. A plataforma utiliza atualizações contínuas entre domínios de falha e zonas de disponibilidade para reduzir a perturbação nas aplicações em execução. Durante as janelas de manutenção, os seus contentores continuam a funcionar sem interrupção porque as atualizações são aplicadas à infraestrutura subjacente em etapas.
Você pode especificar suas próprias janelas de manutenção, que são períodos de tempo que você deseja que a manutenção seja executada em seus aplicativos. Tenha em mente que atualizações críticas podem ocorrer fora das suas janelas de manutenção. Para mais informações, consulte Manutenção planeada de Aplicações de Contentores.
Contrato de nível de serviço
O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte Acordos de Nível de Serviço (SLAs) para serviços online.
O SLA de disponibilidade para Aplicações Container baseia-se nas regras de escala que define nas suas aplicações.