Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Os Aplicativos de Contêiner do Azure são um serviço de hospedagem de contêiner totalmente gerenciado e sem servidor para implantação de 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 várias 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 usar backups para se recuperar de outros tipos de problemas e realça as principais informações 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 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 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 define 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. Os dois tipos de ambientes são 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 em Aplicativos de Contêiner.
Você pode implantar vários aplicativos em um único ambiente. Cada aplicativo 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 e Trabalhos em Aplicativos de Contêiner.
Cada aplicativo tem 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 os hosts físicos ao atender aos 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 dão suporte à confiabilidade de seus aplicativos usando diferentes funcionalidades:
Monitoramento automático de integridade: 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. Também redistribui o tráfego retirado de réplicas não íntegras e gerencia 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, 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 dá suporte a microsserviços de nível de produção e aplicativos em contêineres. O Dapr inclui recursos que ajudam a melhorar a resiliência, incluindo o tratamento de falhas em outros serviços. Para obter mais informações, veja Microsserviços com Aplicativos de Contêiner.
Resiliência de infraestrutura para componentes do sistema: Essa resiliência inclui o plano de controle, os controladores de entrada e o runtime do contêiner. Em regiões que têm zonas de disponibilidade, aplicativos de contêiner oferecem redundância de zona. Para obter mais informações, 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. Para garantir que seus aplicativos sejam resilientes a falhas transitórias, execute as seguintes ações:
Configure sondas de integridade para que a plataforma possa detectar e responder a condições de falha específicas do aplicativo. Defina os limites de falha apropriados e os valores de tempo limite com base nas características de inicialização do aplicativo. Por exemplo, para evitar reinicializações prematuras de contêiner durante problemas temporários, use um limite de falha de 3 com um período de 10 segundos para investigações de atividade. Para obter mais informações, confira Investigações de integridade.
Utilize as políticas de resiliência da descoberta de serviço (versão preliminar) para prevenir de forma proativa, detectar e recuperar falhas de solicitação de serviço. 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. Os recursos internos de descoberta de serviço e balanceamento de carga dos Aplicativos de Contêiner encaminham automaticamente o tráfego para longe de instâncias com falha, mas suas políticas de nova tentativa ao nível do aplicativo garantem o manejo suave de problemas transitórios antes que as checagens de integridade no nível da plataforma disparem a reinicialização do contêiner.
Projete trabalhos para serem resilientes a falhas transitórias, incluindo falhas durante a execução do trabalho ou em 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 uma 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 na região do Azure escolhida. Os Aplicativos de Contêiner agendam automaticamente as réplicas de seus aplicativos entre zonas. Essa distribuição ocorre de forma transparente, o que significa que 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 aplicativo de contêiner redundante em zonas com três réplicas. Cada réplica é executada em uma zona de disponibilidade separada.
Requirements
Verifique o suporte por região. A redundância de zona está disponível em todas as regiões que dão suporte aos 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.
Use perfis de carga de trabalho. A redundância de zona está disponível para todos os planos de 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 depois que o ambiente é criado.
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 com um
/23intervalo roteamento de Inter-Domain sem classe (CIDR) ou maior, enquanto os ambientes de perfis de carga de trabalho exigem um/27intervalo CIDR ou maior.Defina 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 das seguintes condições se aplicar:
A carga de pico esperada precisa de mais de duas réplicas.
Você deve ser resiliente a interrupções simultâneas em várias zonas.
Você deseja minimizar o tempo de espera para que novas réplicas sejam criadas em outras zonas geográficas durante uma interrupção de zona.
Custo
Você não incorre em encargos extras além dos preços padrão dos Aplicativos de Contêiner ao habilitar a redundância de zona. 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 e a cobrança de Aplicativos de Contêiner.
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, consulte Criar um aplicativo de contêiner com redundância de zona.
Migre para uma 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 têm 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 habilitada 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 a redundância de zona. 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.
Planejamento e gerenciamento de capacidade
Se uma zona de disponibilidade se tornar indisponível, a plataforma de Aplicativos de Contêiner usará suas regras de escala para decidir quando as réplicas perdidas nessa zona serão substituídas. É importante configurar as regras de escala corretamente para que o agendador possa tomar 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 porque a plataforma deve detectar que as réplicas antigas se foram. Em seguida, as novas réplicas devem iniciar e retornar um status de investigação de preparação íntegra para que possam receber solicitações. Se você não puder tolerar nenhum período com menos do que o número mínimo de réplicas especificadas, considere o excesso de provisionamento para manter o desempenho do aplicativo mesmo que uma zona fique indisponível.
Defina solicitações de recursos e limites para ajudar o agendador de Aplicativos de Contêiner a 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 sobre opções de configuração, consulte Definir regras de dimensionamento.
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 aplicativos de contêiner com redundância zonal, a plataforma opera em um modelo ativo-ativo no qual várias réplicas atendem simultaneamente ao tráfego. O controlador de entrada distribui solicitações de entrada em todas as réplicas íntegras, independentemente de sua zona, e usa o 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: aplicativos de contêiner não replicam dados do aplicativo entre zonas porque foram projetados 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 para redução da contagem de réplicas e taxas de falhas de solicitação a fim de receber notificação imediata de problemas relacionados à zona.
Solicitações ativas: as solicitações em andamento para réplicas na zona com falha podem ser descartadas ou sofrer tempos limite ou erros de conexão. Todas as execuções de trabalho executadas na zona afetada são anuladas e são marcadas como com falha.
Perda de dados esperada: Nenhuma perda de dados ocorre no nível da plataforma de Aplicativos de Contêiner porque 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 tempo de inatividade mínimo a 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 quaisquer efeitos.
Todos os trabalhos executados na zona afetada são anulados e são marcados como com 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 várias cópias da mesma execução. Para obter mais informações, consulte Configuração avançada do trabalho.
Redirecionamento de tráfego: as investigação de integridade do controlador de entrada de tráfego detectam rapidamente réplicas inacessíveis, removendo-as do grupo de balanceamento de pool. Dependendo da configuração de investigação de integridade do aplicativo, esse processo de failover normalmente ocorre em cerca de 30 segundos. O tráfego de entrada seguinte é distribuído entre as réplicas íntegras restantes. Esse redirecionamento de tráfego ocorre de forma transparente para os clientes, que continuam a usar a mesma URL do aplicativo.
Se a afinidade de sessão estiver habilitada e uma zona falhar, 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 instância de trabalhos será iniciada na zona com falha.
Gerenciamento de instância: novas instâncias de réplica poderão ser criadas em zonas íntegras se as políticas de dimensionamento automático dispararem com base no 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 os aplicativos de contêiner começam a escalonar novas réplicas para essa zona com base na sua configuração de dimensionamento. As réplicas existentes em zonas saudáveis continuam a servir o tráfego durante o processo de reintegração, o que ajuda a evitar a 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. Pare ou remova réplicas de zonas específicas, reduzindo o escalonamento do seu aplicativo e monitore como as réplicas restantes gerenciam o aumento da carga. Monitore as principais métricas durante o teste de resiliência, incluindo contagem de réplicas, taxas de êxito de solicitação, tempos de resposta e comportamento de dimensionamento automático. Verifique se a contagem mínima de réplicas mantém a disponibilidade do serviço quando as réplicas são removidas e verifique se as regras de dimensionamento podem lidar com o aumento da carga nas réplicas restantes. Teste as suas configurações de sondagem de integridade falhando deliberadamente nos pontos de extremidade de integridade para confirmar que a plataforma remove as instâncias não íntegras da rotação dentro dos prazos 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 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 em 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 disponíveis em todas as regiões, o que você pode obter usando o Registro de Contêiner do Azure com a 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 uma substituição usando uma estratégia de implantação azul-verde ou deslocar gradualmente o tráfego usando regras de divisão de tráfego. Durante as atualizações de aplicações, a plataforma mantém o número mínimo de réplicas criando novos contêineres antes de desativar os antigos, o que ajuda a evitar interrupções de serviço.
Para obter mais informações, consulte Atualizar e implantar alterações em Aplicativos de Contêiner.
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 reduzir a interrupção em aplicativos em execução. Durante as janelas de manutenção, seus contêineres continuam a ser executados sem interrupção porque 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. Tenha em mente que as atualizações críticas podem ocorrer fora das janelas de manutenção. Para obter mais informações, consulte a manutenção planejada dos Aplicativos de Contêiner.
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.