Confiabilidade nos Aplicativos de Contêiner do Azure

Os Aplicativos de Contêiner do Azure são um serviço de hospedagem de contêiner totalmente gerenciado sem servidor para implantar microsserviços e aplicativos em contêineres.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar 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 os Aplicativos de Contêiner resilientes a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade, interrupções na região e manutenção do serviço. Ele também descreve como você pode usar backups para se recuperar de outros tipos de problemas e realça algumas informações importantes sobre o SLA (contrato de nível de serviço) dos Aplicativos de Contêiner.

Recomendações de implantação de produção

Para saber mais sobre como implantar Aplicativos de Contêiner para dar suporte aos requisitos de confiabilidade da sua solução e como a confiabilidade afeta outros aspectos de sua arquitetura, consulte as práticas recomendadas de arquitetura para aplicativos de contêiner do Azure no Azure Well-Architected Framework.

Visão geral da arquitetura de confiabilidade

Ao usar Aplicativos de Contêiner, você implanta um ambiente, que serve como a unidade de implantação fundamental e representa um limite seguro em torno de um grupo de aplicativos de contêiner. O ambiente é onde você define as configurações principais, incluindo o suporte à zona de disponibilidade e a configuração de rede. Há dois tipos de ambiente: ambientes de perfis de carga de trabalho e ambientes somente de consumo. Para obter mais informações, consulte Estruturas de computação e cobrança nos Aplicativos de Contêiner do Azure.

Em um único ambiente, você pode implantar vários aplicativos, cada um deles executa um ou mais contêineres. Um ambiente também pode executar um ou mais trabalhos, que representam tarefas não interativas. Para obter mais informações, consulte Contêineres em Aplicativos de Contêiner do Azure e Tarefas em Aplicativos de Contêiner do Azure.

Cada aplicativo possui uma ou mais réplicas, que representam as instâncias em execução do aplicativo. Você pode controlar como seu aplicativo é dimensionado, incluindo o número mínimo e máximo de réplicas, e como o aplicativo adiciona e remove dinamicamente as réplicas. O agendador da plataforma garante a distribuição ideal entre hosts físicos, respeitando os requisitos mínimos de contagem de réplicas. Para saber mais, confira Definir regras de escala nos Aplicativos de Contêiner do Azure.

Os Aplicativos de Contêiner foram projetados para dar suporte à confiabilidade de seus aplicativos usando uma variedade de recursos, incluindo:

• Monitoramento automático de saúde. O controlador de entrada interno equilibra automaticamente o tráfego entre réplicas íntegras. Se uma réplica falhar nas verificações de integridade ou sua infraestrutura subjacente ficar indisponível por um tempo prolongado, o serviço reiniciará automaticamente contêineres com falha ou criará réplicas de substituição, redistribuirá o tráfego de réplicas não íntegras e gerenciará novas tentativas de rede dentro do 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, confira Investigações de integridade.

• Resiliência do aplicativo por meio do Dapr. Os Aplicativos de Contêiner fornecem uma integração apertada com o Dapr, que é uma estrutura que oferece uma variedade de recursos para operar microsserviços de nível de produção e aplicativos em contêineres, inclusive para resiliência a problemas em outros serviços. Para obter mais informações, consulte Microsserviços com Aplicativos de Contêiner do Azure.

• Resiliência de infraestrutura para componentes do sistema, incluindo o plano de controle, controladores de entrada e runtime de contêiner. Em regiões com zonas de disponibilidade, os Aplicativos de Contêiner fornecem redundância de zona. Para saber mais, consulte Resiliência a falhas de zona de disponibilidade.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

Os Aplicativos de Contêiner manipulam automaticamente muitas falhas transitórias por meio de seus mecanismos de repetição no nível da plataforma e monitoramento de integridade. Siga estas recomendações para garantir que seus aplicativos sejam resilientes a falhas transitórias:

• Configure sondas de integridade que permitem à plataforma detectar e reagir a condições específicas de falha do aplicativo. Defina limites de falha e valores de tempo limite apropriados com base nas características de inicialização do aplicativo. Por exemplo, use um limite de falha de 3 com um período de 10 segundos para verificações de integridade, a fim de evitar reinicializações prematuras de contêineres durante problemas temporários. Para obter mais informações, confira Investigações de integridade.

• Use as políticas de resiliência de descoberta de serviços (versão prévia) para prevenir, detectar e recuperar proativamente falhas em solicitações de serviço, utilizando políticas de resiliência simples. Por exemplo, quando você usa uma política de resiliência, cada solicitação de entrada para o 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 de descoberta de serviço (versão prévia).

• Implemente a lógica de repetição em seus aplicativos para chamadas de serviço externas, conexões de banco de dados e solicitações de API.

  Se sua aplicativo utiliza o Dapr para integrar com serviços em nuvem, use a resiliência de componentes do Dapr (versão prévia) para configurar tentativas de repetição, tempos limite e disjuntores.

  Para outras dependências, seu aplicativo deve lidar com falhas transitórias. Use estratégias de retirada exponencial e padrões de disjuntor ao chamar serviços externos para evitar falhas em cascata durante interrupções de serviço downstream. A descoberta de serviços e o balanceamento de carga internos dos Aplicativos de Contêiner redirecionam automaticamente o tráfego para longe de instâncias com falha, mas as políticas de repetição definidas no nível do aplicativo garantem um tratamento eficaz de problemas transitórios antes que as verificações de integridade da plataforma acionem a reinicialização dos contêineres.

• Projete trabalhos para serem resilientes a falhas transitórias, incluindo falhas na execução do trabalho ou de suas dependências. Configure seus trabalhos para retomar a atividade se forem reiniciados, ou para funcionar de forma idempotente, permitindo que sejam executados novamente com segurança.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em cada região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Ao criar um ambiente de Aplicativos de Contêiner, você pode habilitar a redundância de zona para distribuir a infraestrutura subjacente em várias zonas de disponibilidade dentro da região do Azure selecionada. Os Aplicativos de Contêiner agendam automaticamente as réplicas de seus aplicativos entre zonas. Essa distribuição ocorre de forma transparente - você não precisa especificar o posicionamento de zona para réplicas individuais.

A redundância de zona aprimora a resiliência do aplicativo a falhas no nível da zona, garantindo que as réplicas do aplicativo de contêiner sejam distribuídas em várias zonas.

O diagrama a seguir mostra um exemplo de aplicativo de contêiner com redundância de zona que tem três réplicas, cada uma em execução em uma zona de disponibilidade separada:

Requirements

• Suporte regional: A redundância de zona está disponível em todas as regiões que dão suporte a Aplicativos de Contêiner e zonas de disponibilidade. Para ver quais regiões dão suporte a zonas de disponibilidade, consulte as regiões do Azure com suporte à zona de disponibilidade.

  Para ver quais regiões dão suporte a Aplicativos de Contêiner, consulte a Disponibilidade do Produto por Região.

• Perfis de carga de trabalho: a redundância de zona está disponível para todos os planos dos Aplicativos de Contêiner, incluindo perfis de carga de trabalho de Consumo e Dedicado.

• Habilite a redundância de zona durante a criação do ambiente. Essa configuração não pode ser alterada após a criação do ambiente.

• Implantar um ambiente de Aplicativos de Contêiner em uma rede virtual. A rede virtual deve estar em uma região que dê suporte a zonas de disponibilidade. Verifique se a rede virtual tem uma sub-rede de tamanho adequado. Os ambientes somente para consumo precisam de uma sub-rede que tenha um intervalo CIDR de /23 ou maior, enquanto os ambientes com perfis de carga de trabalho exigem /27 ou uma maior.

• Configure sua contagem mínima de réplicas como pelo menos duas para garantir a distribuição em várias zonas de disponibilidade. Considere definir uma contagem mínima de réplicas mais alta se qualquer uma dessas condições se aplicar:

  • A carga de pico esperada precisa de mais de duas réplicas.
  • Você precisa ser resiliente a várias interrupções de zona simultâneas.
  • Você deseja minimizar o tempo de espera para que sejam criadas novas réplicas em outras zonas durante uma interrupção de zona.

Configurar o suporte à zona de disponibilidade

• Crie um ambiente de Aplicativos de Contêiner com redundância de zona. Para obter instruções de implantação que abrangem o portal do Azure, a CLI do Azure e o Azure PowerShell, confira Como criar um aplicativo de contêiner com redundância de zona.

• Migrar para implantação com redundância de zona. Você não pode habilitar a redundância de zona em um ambiente de Aplicativos de Contêiner existente. Para atualizar ambientes existentes que não possuem redundância de zona, crie um novo ambiente com redundância de zona habilitada em uma região suportada. Em seguida, reimplante seus aplicativos de contêiner.

• Desabilite a redundância de zona. A redundância de zona não pode ser desabilitada depois de habilitá-la durante a criação do ambiente. Se você precisar de uma implantação não com 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 dê suporte a zonas de disponibilidade.

• Verifique. Você pode usar o portal do Azure, a CLI do Azure e o Azure PowerShell para verificar o status de redundância de zona do seu ambiente. Para obter instruções, consulte Verificar redundância de zona.

Custo

Você não incorre em encargos adicionais além do preço padrão dos Aplicativos de Contêiner ao habilitar a redundância de zona para Aplicativos de Contêiner. Você paga as mesmas taxas por recursos de computação, solicitações e segundos de vCore, esteja a redundância de zona habilitada ou não. Para obter mais informações, consulte o preço dos Aplicativos de Contêiner do Azure e a cobrança de Aplicativos de Contêiner.

Planejamento e gerenciamento de capacidade

Se uma zona de disponibilidade ficar indisponível, a plataforma dos Aplicativos de Contêiner usará suas regras de escala para decidir quando substituir as réplicas perdidas nessa zona. É importante que as regras de escala estejam configuradas corretamente para que o agendador possa tomar as decisões de agendamento apropriadas.

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 levar um curto período de tempo para que as réplicas perdidas sejam substituídas, pois a plataforma precisa detectar que as réplicas antigas foram perdidas e, em seguida, novas réplicas precisam iniciar e retornar um status de investigação de preparação saudável antes que possam ser enviadas solicitações de entrada. Se você não puder tolerar qualquer período de tempo em que possa ter menos do que as réplicas mínimas especificadas, considere o excesso de provisionamento para garantir que seu aplicativo permaneça com desempenho mesmo que uma zona fique indisponível.

• Defina solicitações de recursos e limites adequadamente para seus contêineres para garantir que o agendador de Aplicativos de Contêiner possa tomar decisões de posicionamento ideais entre zonas. Requisitos de recursos subespecificados podem levar a falhas de distribuição ou posicionamento irregulares durante a alta carga.

Para obter mais informações, consulte Definir regras de dimensionamento para opções de configuração.

Comportamento quando todas as zonas estão saudáveis

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.

• Roteamento de tráfego entre zonas. Com os Aplicativos de Contêiner com redundância de zona, a plataforma opera em um modelo ativo/ativo em que várias réplicas atendem simultaneamente ao tráfego. O controlador de entrada distribui as solicitações recebidas entre todas as réplicas íntegras, independentemente da localização da zona, usando balanceamento de carga round robin por padrão. Cada zona processa solicitações de forma independente e a plataforma não prioriza nenhuma zona específica para distribuição de tráfego. As investigações de integridade se originam de todas as zonas para garantir uma avaliação precisa da integridade de cada réplica sob várias perspectivas.

• Replicação de dados entre zonas. Os Aplicativos de Contêiner não replicam dados de aplicativos entre zonas porque são projetadas para cargas de trabalho sem estado. Todos os dados que seu aplicativo armazena no armazenamento efêmero, incluindo no armazenamento com escopo de contêiner e no armazenamento com escopo de réplica, são excluídos quando o contêiner ou a réplica é desligada.

  Para requisitos de dados com estado, monte um compartilhamento de arquivos dos Arquivos do Azure configurado para ZRS ou utilize outros serviços do Azure, como o Azure Cosmos DB ou Banco de Dados SQL do Azure, que ofereçam suas próprias funcionalidades de replicação entre zonas.

  A plataforma replica apenas os metadados do plano de controle, incluindo as configurações do aplicativo, regras de escalonamento e segredos entre as 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 dos Aplicativos de Contêiner são configurados para redundância de zona e há uma interrupção da zona de disponibilidade.

• Detecção e resposta: o Azure detecta automaticamente falhas de zona. Os Aplicativos de Contêiner interrompem imediatamente o agendamento de novas réplicas para a zona com falha e começam a redistribuir o tráfego para réplicas íntegras nas zonas restantes. A plataforma manipula todas as operações de failover automaticamente sem exigir sua intervenção.

• Notificação: A Microsoft não notifica você automaticamente quando uma zona está inoperante. 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 de problemas.

  Você também pode monitorar a integridade de seus aplicativos por meio de métricas de Aplicativos de Contêiner no Azure Monitor. Configure alertas sobre a redução na quantidade de réplicas e taxas de falha de solicitações para receber imediatamente uma notificação quando problemas relacionados à zona ocorrerem.

• Solicitações ativas: as solicitações disponibilizadas em versão piloto para réplicas na zona com falha podem ser descartadas ou sofrer tempos limite ou erros de conexão. Qualquer execução de tarefas em execução na zona afetada é interrompida e marcada como falha.

• Perda de dados esperada: nenhuma perda de dados ocorre no nível da plataforma dos Aplicativos de Contêiner, pois o serviço foi projetado para cargas de trabalho sem estado. Todos os dados armazenados no 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 esperado: os aplicativos experimentam um tempo de inatividade mínimo ou nenhum durante falhas de zona. O impacto real depende das configurações de investigação de integridade do aplicativo e do número de réplicas em zonas íntegras. Verifique se os clientes seguem diretrizes transitórias de tratamento de falhas para minimizar qualquer impacto.

  Qualquer execução de tarefas em execução na zona afetada é interrompida e marcada como falha. Se você precisar de um trabalho para ser resiliente a uma falha de zona, configure novas tentativas ou configure o paralelismo para que o trabalho execute cópias da mesma execução. Para obter mais informações, consulte Configuração avançada do trabalho.

• Redirecionamento de tráfego: as verificações de integridade do controlador de entrada de tráfego detectam rapidamente réplicas inacessíveis, removendo-as do grupo de balanceamento de carga. Dependendo da configuração de investigação de integridade do aplicativo, isso normalmente acontece em cerca de 30 segundos. O tráfego de entrada seguinte é distribuído entre as réplicas íntegras restantes. Isso acontece de forma transparente para os clientes, que continuam usando a mesma URL do aplicativo.

  Se você tiver habilitado a afinidade de sessão e uma zona ficar inoperante, os clientes que foram roteados anteriormente para réplicas nessa zona serão roteados para novas réplicas porque as réplicas anteriores não estão mais disponíveis. Qualquer estado associado às réplicas anteriores é perdido.

  Nenhuma nova execução de trabalho não será agendada na zona com falha.

• Gerenciamento de instância: novas instâncias de réplica poderão ser criadas em zonas íntegras se as regras de escala automática forem ativadas devido ao aumento da carga.

Recuperação de zona

Quando uma zona de disponibilidade se recupera de uma falha, os Aplicativos de Contêiner reinserem automaticamente a zona no serviço ativo sem a necessidade de intervenção. As investigações de integridade da plataforma detectam quando a infraestrutura na zona recuperada se torna disponível e começam a agendar novas réplicas para a zona com base na sua configuração de escala. As réplicas existentes em zonas íntegras continuam atendendo ao tráfego durante esse processo de reintegração, garantindo que não haja interrupção do serviço.

Os Aplicativos de Contêiner reequilibram gradualmente a distribuição de réplicas em todas as zonas disponíveis como parte das operações normais de escala. Esse rebalanceamento automático ocorre quando as réplicas são criadas devido a eventos de escala ou quando réplicas não íntegras são substituídas. A plataforma não força a redistribuição imediata de réplicas íntegras existentes, o que impede reinicializações desnecessárias do contêiner e mantém a estabilidade do aplicativo durante a recuperação.

Testar falhas em zonas

A plataforma dos Aplicativos de Contêiner gerencia o roteamento de tráfego, o failover e o failback para aplicativos de container com redundância entre zonas. Esse recurso é totalmente gerenciado, então você não precisa iniciar ou validar processos de falha de zona de disponibilidade.

Para validar a resiliência do aplicativo a falhas de zona, simule interrupções no nível da zona na camada do aplicativo usando abordagens de teste controladas. Interrompa ou remova réplicas de zonas específicas, reduzindo verticalmente o número de réplicas do seu aplicativo e monitorando como as réplicas restantes gerenciam a carga aumentada. Monitore as principais métricas durante o teste de resiliência, incluindo a contagem de réplicas, as taxas de êxito da solicitação, os tempos de resposta e o comportamento de dimensionamento automático. Certifique-se que a contagem mínima de réplicas mantenha a disponibilidade do serviço quando as réplicas forem removidas e garanta que suas regras de escalonamento possam lidar com o aumento da carga nas réplicas restantes. Teste as configurações da investigação de integridade, falhando deliberadamente nos pontos de extremidade de verificação de integridade para confirmar se a plataforma remove corretamente instâncias não íntegras da rotação no tempo esperado.

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 região única que afete seu aplicativo, você pode implantar ambientes em várias regiões. As etapas a seguir ajudam a fortalecer a resiliência:

• Implante seus aplicativos nos ambientes em cada região. Cada ambiente requer sua própria configuração de rede virtual e os requisitos de sub-rede se aplicam independentemente a cada implantação regional. Suas imagens de contêiner devem estar acessíveis de todas as regiões, o que você pode obter usando o Registro de Contêiner do Azure com replicação geográfica habilitada.
• Configure políticas de failover e balanceamento de carga usando um serviço como o Azure Front Door ou o Gerenciador de Tráfego do Azure.
• Replique seus dados entre regiões para que você possa recuperar o último estado do aplicativo.

Backup e restauração

Os Aplicativos de Contêiner não fornecem recursos de backup internos para seus aplicativos ou dados. Como uma plataforma de hospedagem de contêiner sem estado, os Aplicativos de Contêiner esperam que os aplicativos 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ão para implantar atualizações em seu aplicativo sem tempo de inatividade. Você pode criar novas revisões com imagens de contêiner atualizadas e executar a substituição utilizando uma estratégia de implantação azul-verde, ou deslocar o tráfego gradualmente usando regras de divisão de tráfego. Durante as atualizações do aplicativo, a plataforma garante que as contagens mínimas de réplica sejam mantidas criando novos contêineres antes de encerrar os antigos, evitando a interrupção do serviço.

Para obter mais informações, consulte Atualizar e implantar alterações nos Aplicativos de Contêiner do Azure.

Resiliência à manutenção do serviço

Os Aplicativos de Contêiner executam 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 usa atualizações sem interrupção em domínios de falha e zonas de disponibilidade para minimizar o impacto na execução de aplicativos. Durante as janelas de manutenção, seus contêineres continuam em execução sem interrupção, pois as atualizações são aplicadas à infraestrutura subjacente em estágios.

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. No entanto, atualizações críticas podem ocorrer fora das janelas de manutenção. Para obter mais informações, consulte Manutenção Planejada dos Aplicativos de Contêiner do Azure.

Contrato de nível de serviço

O acordo de nível de serviço (SLA) dos serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para alcançar essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

O SLA de disponibilidade para Aplicativos de Contêiner baseia-se nas regras de escala definidas em seus aplicativos.

Conteúdo relacionado

• Visão geral dos Aplicativos de Contêiner do Azure
• Investigações de integridade nos Aplicativos de Contêiner do Azure
• Dimensionamento automático em Aplicativos de Contêiner do Azure
• Observabilidade em Aplicativos de Contêiner do Azure
• Documentação de confiabilidade do Azure
• Diretrizes de confiabilidade do Azure Well-Architected Framework