Considerações da plataforma do aplicativo para cargas de trabalho de missão crítica no Azure

O Azure fornece muitos serviços de computação para hospedar aplicativos altamente disponíveis. Os serviços diferem em capacidade e complexidade. Recomendamos que você escolha serviços com base em:

• Requisitos não funcionais de confiabilidade, disponibilidade, desempenho e segurança.
• Fatores de decisão como escalabilidade, custo, operabilidade e complexidade.

A escolha de uma plataforma de hospedagem de aplicativos é uma decisão crítica que afeta todas as outras áreas de design. Por exemplo, o software de desenvolvimento herdado ou proprietário pode não ser executado em serviços PaaS ou aplicativos em contêineres. Essa limitação influenciaria sua escolha de plataforma de computação.

Um aplicativo de missão crítica pode usar mais de um serviço de computação para dar suporte a várias cargas de trabalho compostas e microsserviços, cada um com requisitos distintos.

Esta área de design fornece recomendações relacionadas à seleção de computação, design e opções de configuração. Também recomendamos que você se familiarize com a árvore de decisão do Compute.

Distribuição global de recursos da plataforma

Um padrão típico para uma carga de trabalho crítica inclui recursos globais e recursos regionais.

Os serviços do Azure, que não são restritos a uma região específica do Azure, são implantados ou configurados como recursos globais. Alguns casos de uso incluem a distribuição de tráfego em várias regiões, o armazenamento do estado permanente de um aplicativo inteiro e o armazenamento em cache de dados estáticos globais. Se você precisar acomodar uma arquitetura de unidade de escala e uma distribuição global, considere como os recursos são distribuídos ou replicados de maneira ideal entre as regiões do Azure.

Outros recursos são implantados regionalmente. Esses recursos, que são implantados como parte de um selo de implantação, normalmente correspondem a uma unidade de escala. No entanto, uma região pode ter mais de um selo e um selo pode ter mais de uma unidade. A confiabilidade dos recursos regionais é crucial porque eles são responsáveis por executar a carga de trabalho principal.

A imagem a seguir mostra o design de alto nível. Um usuário acessa o aplicativo por meio de um ponto de entrada global central que, em seguida, redireciona as solicitações para um selo de implantação regional adequado:

A metodologia de design de missão crítica requer uma implantação multirregional. Esse modelo garante tolerância a falhas regionais, para que o aplicativo permaneça disponível mesmo quando uma região inteira cair. Ao projetar um aplicativo multirregional, considere diferentes estratégias de implantação, como ativo/ativo e ativo/passivo, juntamente com os requisitos do aplicativo, pois há compensações significativas para cada abordagem. Para cargas de trabalho críticas, recomendamos fortemente o modelo ativo/ativo.

Nem toda carga de trabalho dá suporte ou requer a execução de várias regiões simultaneamente. Você deve pesar os requisitos específicos da aplicação em relação às compensações para determinar uma decisão de design ideal. Para determinados cenários de aplicação que têm metas de confiabilidade mais baixas, ativo/passivo ou fragmentação podem ser alternativas adequadas.

As zonas de disponibilidade podem fornecer implantações regionais altamente disponíveis em diferentes datacenters dentro de uma região. Quase todos os serviços do Azure estão disponíveis em uma configuração zonal, em que o serviço é delegado a uma zona específica, ou em uma configuração com redundância de zona, em que a plataforma garante automaticamente que o serviço se estenda entre zonas e possa suportar uma interrupção de zona. Essas configurações fornecem tolerância a falhas até o nível do datacenter.

Considerações sobre o design

• Capacidades regionais e zonais. Nem todos os serviços e funcionalidades estão disponíveis em todas as regiões do Azure. Essa consideração pode afetar as regiões que você escolher. Além disso, as zonas de disponibilidade não estão disponíveis em todas as regiões.

• Pares regionais. As regiões do Azure são agrupadas em pares regionais que consistem em duas regiões em uma única geografia. Alguns serviços do Azure usam regiões emparelhadas para garantir a continuidade dos negócios e fornecer um nível de proteção contra perda de dados. Por exemplo, o GRS (armazenamento com redundância geográfica) do Azure replica dados para uma região emparelhada secundária automaticamente, garantindo que os dados sejam duráveis se a região primária não for recuperável. Se uma interrupção afetar várias regiões do Azure, pelo menos uma região em cada par será priorizada para recuperação.

• Consistência de dados. Para desafios de consistência, considere o uso de um armazenamento de dados distribuído globalmente, uma arquitetura regional carimbada e uma implantação parcialmente ativa/ativa. Em uma implantação parcial, alguns componentes estão ativos em todas as regiões, enquanto outros estão localizados centralmente na região primária.

• Implantação segura. A estrutura de SDP (prática de implantação segura) do Azure garante que todas as alterações de código e configuração (manutenção planejada) na plataforma do Azure passem por uma distribuição em fases. A integridade é analisada quanto à degradação durante a liberação. Depois que as fases canário e piloto são concluídas com êxito, as atualizações de plataforma são serializadas em pares regionais, portanto, apenas uma região em cada par é atualizada em um determinado momento.

• Capacidade da plataforma. Como qualquer provedor de nuvem, o Azure tem recursos finitos. A indisponibilidade pode ser o resultado de limitações de capacidade nas regiões. Se houver uma interrupção regional, haverá um aumento na demanda por recursos à medida que a carga de trabalho tenta se recuperar na região emparelhada. A interrupção pode criar um problema de capacidade, onde a oferta temporariamente não atende à demanda.

Recomendações de design

• Implante sua solução em pelo menos duas regiões do Azure para ajudar a proteger contra interrupções regionais. Implante-o em regiões que tenham os recursos e as características que a carga de trabalho exige. Os recursos devem atender às metas de desempenho e disponibilidade e, ao mesmo tempo, atender aos requisitos de residência e retenção de dados.

  Por exemplo, alguns requisitos de conformidade de dados podem restringir o número de regiões disponíveis e potencialmente forçar comprometimentos de design. Nesses casos, é altamente recomendável que você adicione um investimento extra em wrappers operacionais para prever, detectar e responder a falhas. Suponha que você esteja restrito a uma geografia com duas regiões e apenas uma dessas regiões dê suporte a zonas de disponibilidade (modelo de datacenter 3 + 1). Crie um padrão de implantação secundário usando o isolamento de domínio de falha para permitir que ambas as regiões sejam implantadas em uma configuração ativa e certifique-se de que a região primária hospede vários selos de implantação.

  Se nem todas as regiões adequadas do Azure oferecerem os recursos necessários, esteja preparado para comprometer a consistência dos selos de implantação regionais para priorizar a distribuição geográfica e maximizar a confiabilidade. Se apenas uma única região do Azure for adequada, implante vários selos de implantação (unidades de escala regional) na região selecionada para mitigar alguns riscos e use zonas de disponibilidade para fornecer tolerância a falhas no nível do datacenter. No entanto, um compromisso tão significativo na distribuição geográfica restringe drasticamente o SLO composto atingível e a confiabilidade geral.

  Importante

  Para cenários direcionados a um SLO maior ou igual a 99,99%, recomendamos um mínimo de três regiões de implantação. Calcule o SLO composto para todos os fluxos de usuário. Certifique-se de que essas metas estejam alinhadas com as metas de negócios.

• Para cenários de aplicativos de alta escala que têm volumes significativos de tráfego, projete a solução para escalar em várias regiões para navegar por possíveis restrições de capacidade em uma única região. Selos de implantação regionais adicionais podem obter um SLO composto mais alto. Para obter mais informações, consulte como implementar destinos multirregionais.

• Defina e valide seus objetivos de ponto de recuperação (RPO) e objetivos de tempo de recuperação (RTO).

• Em uma única geografia, priorize o uso de pares regionais para se beneficiar de distribuições serializadas de SDP para manutenção planejada e priorização regional para manutenção não planejada.

• Coloque geograficamente os recursos do Azure com os usuários para minimizar a latência de rede e maximizar o desempenho de ponta a ponta.

  • Você também pode usar soluções como uma rede de distribuição de conteúdo (CDN) ou cache de borda para gerar latência de rede ideal para bases de usuários distribuídas. Para obter mais informações, consulte Roteamento de tráfego global, Serviços de entrega de aplicativos e Cache e entrega de conteúdo estático.

• Alinhe a disponibilidade atual do serviço com os roteiros do produto ao escolher regiões de implantação. Alguns serviços podem não estar disponíveis imediatamente em todas as regiões.

Transporte em contêineres

Um contêiner inclui o código do aplicativo e os arquivos de configuração, bibliotecas e dependências relacionados que o aplicativo precisa executar. A conteinerização fornece uma camada de abstração para o código do aplicativo e suas dependências e cria separação da plataforma de hospedagem subjacente. O pacote de software único é altamente portátil e pode ser executado de forma consistente em várias plataformas de infraestrutura e provedores de nuvem. Os desenvolvedores não precisam reescrever o código e podem implantar aplicativos de forma mais rápida e confiável.

Considerações sobre o design

• Monitoramento. Pode ser difícil para os serviços de monitoramento acessar aplicativos que estão em contêineres. Normalmente, você precisa de software de terceiros para coletar e armazenar indicadores de estado do contêiner, como uso de CPU ou RAM.

• Segurança. O kernel do sistema operacional da plataforma de hospedagem é compartilhado em vários contêineres, criando um único ponto de ataque. No entanto, o risco de acesso à VM (máquina virtual) do host é limitado porque os contêineres são isolados do sistema operacional subjacente.

• Estado. Embora seja possível armazenar dados no sistema de arquivos de um contêiner em execução, os dados não persistirão quando o contêiner for recriado. Em vez disso, persista os dados montando o armazenamento externo ou usando um banco de dados externo.

Recomendações de design

• Conteinerize todos os componentes do aplicativo. Use imagens de contêiner como o modelo principal para pacotes de implantação de aplicativos.

• Priorize os tempos de execução de contêiner baseados em Linux quando possível. As imagens são mais leves e novos recursos para nós/contêineres do Linux são lançados com frequência.

• Torne os contêineres imutáveis e substituíveis, com ciclos de vida curtos.

• Certifique-se de reunir todos os logs e métricas relevantes do contêiner, do host do contêiner e do cluster subjacente. Envie os logs e métricas coletados para um coletor de dados unificado para processamento e análise adicionais.

• Armazene imagens de contêiner no Registro de Contêiner do Azure. Use a replicação geográfica para replicar imagens de contêiner em todas as regiões. Habilite Microsoft Defender para registros de contêiner para fornecer verificação de vulnerabilidade para imagens de contêiner. Verifique se o acesso ao registro é gerenciado pela ID do Microsoft Entra.

Hospedagem e orquestração de contêineres

Várias plataformas de aplicativos do Azure podem hospedar contêineres com eficiência. Existem vantagens e desvantagens associadas a cada uma dessas plataformas. Compare as opções no contexto de seus requisitos de negócios. No entanto, sempre otimize a confiabilidade, a escalabilidade e o desempenho. Para obter mais informações, confira estes tópicos:

• Árvore de decisão de computação
• Comparações de opções de contêiner

Considerações de design e recomendações para o Serviço de Kubernetes do Azure

O AKS, um serviço gerenciado do Kubernetes, permite o provisionamento rápido de cluster sem exigir atividades complexas de administração de cluster e oferece um conjunto de recursos que inclui recursos avançados de rede e identidade. Para obter um conjunto completo de recomendações, consulte Revisão do Azure Well-Architected Framework – AKS.

Confiabilidade

O AKS gerencia o painel de controle nativo do Kubernetes. Se o plano de controle não estiver disponível, a carga de trabalho terá tempo de inatividade. Aproveite os recursos de confiabilidade oferecidos pelo AKS:

• Implante clusters do AKS em diferentes regiões do Azure como uma unidade de escala para maximizar a confiabilidade e a disponibilidade. Use zonas de disponibilidade para maximizar a resiliência em uma região do Azure distribuindo o painel de controle do AKS e os nós do agente em datacenters fisicamente separados. No entanto, se a latência de colocação for um problema, você poderá fazer a implantação do AKS em uma única zona ou usar grupos de posicionamento por proximidade para minimizar a latência de entrenós.

• Use o SLA de Tempo de Atividade do AKS para clusters de produção para maximizar as garantias de disponibilidade do ponto de extremidade da API do Kubernetes.

Escalabilidade

Leve em conta os limites de escala do AKS, como o número de nós, pools de nós por cluster e clusters por assinatura.

• Se os limites de escala forem uma restrição, aproveite a estratégia de unidade de escala e implante mais unidades com clusters.

• Habilite o dimensionador automático de cluster para ajustar automaticamente o número de nós de agente em resposta às restrições de recursos.

• Use o dimensionador automático de pod horizontal para ajustar o número de pods em uma implantação com base na utilização da CPU ou em outras métricas.

• Para cenários de alta escala e intermitência, considere o uso de nós virtuais para escala extensa e rápida.

• Defina solicitações e limites de recursos de pod em manifestos de implantação de aplicativos. Caso contrário, você poderá ter problemas de desempenho.

Isolamento

Mantenha os limites entre a infraestrutura usada pela carga de trabalho e as ferramentas do sistema. O compartilhamento de infraestrutura pode levar a cenários de alta utilização de recursos e vizinhos barulhentos.

• Use pools de nós separados para serviços de sistema e carga de trabalho. Os pools de nós dedicados para componentes de carga de trabalho devem ser baseados em requisitos para recursos de infraestrutura especializados, como VMs de GPU com mais memória. Em geral, para reduzir a sobrecarga de gerenciamento desnecessária, evite implantar um grande número de pools de nós.

• Use taints e tolerações para fornecer nós dedicados e limitar aplicativos com uso intensivo de recursos.

• Avalie os requisitos de afinidade e antiafinidade do aplicativo e configure a colocação apropriada de contêineres nos nós.

Segurança

O Kubernetes padrão requer uma configuração significativa para garantir uma postura de segurança adequada para cenários críticos. O AKS aborda vários riscos de segurança prontos para uso. Os recursos incluem clusters privados, auditoria e logon no Log Analytics, imagens de nó protegidas e identidades gerenciadas.

• Aplique as diretrizes de configuração fornecidas na linha de base de segurança do AKS.

• Use os recursos do AKS para lidar com o gerenciamento de identidade e acesso do cluster para reduzir a sobrecarga operacional e aplicar um gerenciamento de acesso consistente.

• Use identidades gerenciadas em vez de entidades de serviço para evitar o gerenciamento e a rotação de credenciais. Você pode adicionar identidades gerenciadas no nível do cluster. No nível do pod, você pode usar identidades gerenciadas por meio da ID da carga de trabalho do Microsoft Entra.

• Use a integração do Microsoft Entra para gerenciamento centralizado de contas e senhas, gerenciamento de acesso a aplicativos e proteção de identidade aprimorada. Use o RBAC do Kubernetes com a ID do Microsoft Entra para obter privilégios mínimos e minimize a concessão de privilégios de administrador para ajudar a proteger a configuração e o acesso a segredos. Além disso, limite o acesso ao arquivo de configuração do cluster do Kubernetes usando o controle de acesso baseado em função do Azure. Limite o acesso às ações que os contêineres podem executar, forneça o menor número de permissões e evite o uso de escalonamento de privilégios raiz.

Atualizações

Clusters e nós precisam ser atualizados regularmente. O AKS dá suporte a versões do Kubernetes em alinhamento com o ciclo de lançamento do Kubernetes nativo.

• Assine o Roteiro do AKS público e as Notas de versão no GitHub para se manter atualizado sobre as próximas alterações, melhorias e, o mais importante, versões e substituições do Kubernetes.

• Aplique as diretrizes fornecidas na lista de verificação do AKS para garantir o alinhamento com as práticas recomendadas.

• Esteja ciente dos vários métodos compatíveis com o AKS para atualizar nós e/ou clusters. Esses métodos podem ser manuais ou automatizados. Você pode usar a Manutenção Planejada para definir janelas de manutenção para essas operações. Novas imagens são lançadas semanalmente. O AKS também dá suporte a canais de atualização automática para atualizar automaticamente os clusters do AKS para versões mais recentes do Kubernetes e/ou imagens de nó mais recentes quando estiverem disponíveis.

Rede

Avalie os plug-ins de rede que melhor se adaptam ao seu caso de uso. Determine se você precisa de controle granular do tráfego entre pods. O Azure dá suporte a kubenet, CNI do Azure e traga sua própria CNI para casos de uso específicos.

Priorize o uso da CNI do Azure depois de avaliar os requisitos de rede e o tamanho do cluster. A CNI do Azure permite o uso de políticas de rede do Azure ou do Calico para controlar o tráfego dentro do cluster.

Monitoramento

Suas ferramentas de monitoramento devem ser capazes de capturar logs e métricas de pods em execução. Você também deve coletar informações da API de Métricas do Kubernetes para monitorar a integridade dos recursos e cargas de trabalho em execução.

• Use o Azure Monitor e o Application Insights para coletar métricas, logs e diagnósticos de recursos do AKS para solução de problemas.

• Habilite e revise os logs de recursos do Kubernetes.

• Configure as métricas do Prometheus no Azure Monitor. Os insights de contêiner no Monitor fornecem integração, habilitam recursos de monitoramento prontos para uso e habilitam recursos mais avançados por meio do suporte interno do Prometheus.

Governança

Use políticas para aplicar proteções centralizadas a clusters do AKS de maneira consistente. Aplique atribuições de política em um escopo de assinatura ou superior para impulsionar a consistência entre as equipes de desenvolvimento.

• Controle quais funções são concedidas aos pods e se a execução contradiz a política usando o Azure Policy. Esse acesso é definido por meio de políticas internas fornecidas pelo Complemento do Azure Policy para AKS.

• Estabeleça uma linha de base consistente de confiabilidade e segurança para configurações de cluster e pod do AKS usando Azure Policy.

• Use o Complemento do Azure Policy para AKS para controlar as funções do pod, como privilégios raiz, e para não permitir pods que não estejam em conformidade com a política.

Considerações de design e recomendações para o Serviço de Aplicativo do Azure

Para cenários de carga de trabalho baseados em API e Web, o Serviço de Aplicativo pode ser uma alternativa viável ao AKS. Ele fornece uma plataforma de contêiner de baixo atrito sem a complexidade do Kubernetes. Para obter um conjunto completo de recomendações, consulte Considerações de confiabilidade para o Serviço de Aplicativo e Excelência operacional para o Serviço de Aplicativo.

Confiabilidade

Avalie o uso de portas TCP e SNAT. As conexões TCP são usadas para todas as conexões de saída. As portas SNAT são usadas para conexões de saída com endereços IP públicos. O esgotamento da porta SNAT é um cenário de falha comum. Você deve detectar esse problema de forma preditiva por meio de testes de carga ao usar o Diagnóstico do Azure para monitorar portas. Se ocorrerem erros de SNAT, você precisará dimensionar em mais ou maiores workers ou implementar práticas de codificação para ajudar a preservar e reutilizar portas SNAT. Exemplos de práticas de codificação que você pode usar incluem o pool de conexões e o carregamento lento de recursos.

O esgotamento da porta TCP é outro cenário de falha. Ocorre quando a soma das conexões de saída de um determinado trabalhador excede a capacidade. O número de portas TCP disponíveis depende do tamanho do trabalhador. Para obter recomendações, consulte Portas TCP e SNAT.

Escalabilidade

Planeje os requisitos futuros de escalabilidade e o crescimento do aplicativo para que você possa aplicar as recomendações apropriadas desde o início. Ao fazer isso, você pode evitar a dívida de migração técnica à medida que a solução cresce.

• Habilite o dimensionamento automático para garantir que os recursos adequados estejam disponíveis para solicitações de serviço. Avalie o dimensionamento por aplicativo para hospedagem de alta densidade no Serviço de Aplicativo.

• Lembre-se de que o Serviço de Aplicativo tem um limite flexível padrão de instâncias por plano do Serviço de Aplicativo.

• Aplique regras de dimensionamento automático. Um plano do Serviço de Aplicativo será escalado horizontalmente se qualquer regra dentro do perfil for atendida, mas só será reduzido horizontalmente se todas as regras dentro do perfil forem atendidas. Use uma combinação de regras de expansão e redução para garantir que o dimensionamento automático possa tomar medidas para escalar horizontalmente e horizontalmente. Entenda o comportamento de várias regras de dimensionamento em um único perfil.

• Lembre-se de que você pode habilitar o dimensionamento por aplicativo no nível do plano do Serviço de Aplicativo para permitir que um aplicativo seja dimensionado independentemente do plano do Serviço de Aplicativo que o hospeda. Os aplicativos são alocados para nós disponíveis por meio de uma abordagem de melhor esforço para uma distribuição uniforme. Embora uma distribuição uniforme não seja garantida, a plataforma garante que duas instâncias do mesmo aplicativo não sejam hospedadas na mesma instância.

Monitoramento

Monitore o comportamento do aplicativo e obtenha acesso a logs e métricas relevantes para garantir que seu aplicativo funcione conforme o esperado.

• Você pode usar o log de diagnóstico para ingerir logs no nível do aplicativo e da plataforma no Log Analytics, no Armazenamento do Azure ou em uma ferramenta de terceiros por meio dos Hubs de Eventos do Azure.

• O monitoramento do desempenho do aplicativo com o Application Insights fornece insights profundos sobre o desempenho do aplicativo.

• Os aplicativos de missão crítica devem ter a capacidade de se auto-recuperar se houver falhas. Ative a Recuperação automática para reciclar automaticamente trabalhadores não íntegros.

• Você precisa usar verificações de integridade apropriadas para avaliar todas as dependências downstream críticas, o que ajuda a garantir a integridade geral. É altamente recomendável que você habilite a Verificação de integridade para identificar trabalhadores que não respondem.

Implantação

Para contornar o limite padrão de instâncias por plano do Serviço de Aplicativo, implante planos do Serviço de Aplicativo em várias unidades de escala em uma única região. Implante planos do Serviço de Aplicativo em uma configuração de zona de disponibilidade para garantir que os nós de trabalho sejam distribuídos entre zonas dentro de uma região. Considere abrir um tíquete de suporte para aumentar o número máximo de operadores para o dobro da contagem de instâncias necessária para atender à carga de pico normal.

Registro de contêiner

Os registros de contêiner hospedam imagens que são implantadas em ambientes de runtime de contêiner, como o AKS. Você precisa configurar seus registros de contêiner para cargas de trabalho críticas com cuidado. Uma interrupção não deve causar atrasos na extração de imagens, especialmente durante operações de dimensionamento. As considerações e recomendações a seguir se concentram no Registro de Contêiner do Azure e exploram as compensações associadas aos modelos de implantação centralizados e federados.

Considerações sobre o design

• Formato. Considere usar um registro de contêiner que dependa do formato e dos padrões fornecidos pelo Docker para operações de envio e pull. Essas soluções são compatíveis e, em sua maioria, intercambiáveis.

• Modelo de implantação. Você pode implantar o registro de contêiner como um serviço centralizado que é consumido por vários aplicativos em sua organização. Ou você pode implantá-lo como um componente dedicado para uma carga de trabalho de aplicativo específica.

• Registros públicos. As imagens de contêiner são armazenadas no Docker Hub ou em outros registros públicos que existem fora do Azure e de uma determinada rede virtual. Isso não é necessariamente um problema, mas pode levar a vários problemas relacionados à disponibilidade do serviço, limitação e exfiltração de dados. Para alguns cenários de aplicativo, você precisa replicar imagens de contêiner público em um registro de contêiner privado para limitar o tráfego de saída, aumentar a disponibilidade ou evitar possíveis limitações.

Recomendações de design

• Use instâncias de registro de contêiner dedicadas à carga de trabalho do aplicativo. Evite criar uma dependência em um serviço centralizado, a menos que os requisitos organizacionais de disponibilidade e confiabilidade estejam totalmente alinhados com o aplicativo.

  No padrão de arquitetura principal recomendado, os registros de contêiner são recursos globais de longa duração. Considere usar um único registro de contêiner global por ambiente. Por exemplo, use um registro de produção global.

• Certifique-se de que o SLA para registro público esteja alinhado com suas metas de confiabilidade e segurança. Observe especialmente os limites de limitação para casos de uso que dependem do Docker Hub.

• Priorize o Registro de Contêiner do Azure para hospedar imagens de contêiner.

Considerações de design e recomendações para o Registro de Contêiner do Azure

Esse serviço nativo fornece uma variedade de recursos, incluindo replicação geográfica, autenticação do Microsoft Entra, criação automatizada de contêineres e aplicação de patches por meio de tarefas do Registro de Contêiner.

Confiabilidade

Configure a replicação geográfica para todas as regiões de implantação para remover dependências regionais e otimizar a latência. O Container Registry oferece suporte à alta disponibilidade por meio da replicação geográfica para várias regiões configuradas, fornecendo resiliência contra interrupções regionais. Se uma região ficar indisponível, as outras regiões continuarão a atender às solicitações de imagem. Quando a região estiver online novamente, o Registro de Contêiner recuperará e replicará as alterações nela. Essa funcionalidade também fornece a colocação de registro em cada região configurada, reduzindo a latência de rede e os custos de transferência de dados entre regiões.

Nas regiões do Azure que fornecem suporte à zona de disponibilidade, a camada do Registro de Contêiner Premium dá suporte à redundância de zona para fornecer proteção contra falha zonal. A camada Premium também dá suporte a pontos de extremidade privados para ajudar a impedir o acesso não autorizado ao registro, o que pode levar a problemas de confiabilidade.

Hospede imagens próximas aos recursos de computação de consumo, nas mesmas regiões do Azure.

Bloqueio de imagem

As imagens podem ser excluídas, como resultado, por exemplo, de erro manual. O Container Registry dá suporte ao bloqueio de uma versão de imagem ou de um repositório para evitar alterações ou exclusões. Quando uma versão de imagem implantada anteriormente é alterada no local, as implantações da mesma versão podem fornecer resultados diferentes antes e depois da alteração.

Se você quiser proteger a instância do Container Registry contra exclusão, use bloqueios de recursos.

Imagens marcadas

As imagens do Registro de Contêiner marcadas são mutáveis por padrão, o que significa que a mesma marca pode ser usada em várias imagens enviadas por push para o registro. Em cenários de produção, isso pode levar a um comportamento imprevisível que pode afetar o tempo de atividade do aplicativo.

Gerenciamento de identidade e de acesso

Use a autenticação integrada do Microsoft Entra para efetuar push e pull de imagens em vez de depender de chaves de acesso. Para maior segurança, desative totalmente o uso da chave de acesso de administrador.

Computação sem servidor

A computação sem servidor fornece recursos sob demanda e elimina a necessidade de gerenciar a infraestrutura. O provedor de nuvem provisiona, dimensiona e gerencia automaticamente os recursos necessários para executar o código do aplicativo implantado. O Azure fornece várias plataformas de computação sem servidor:

• Azure Functions. Quando você usa o Azure Functions, a lógica do aplicativo é implementada como blocos distintos de código, ou funções, que são executados em resposta a eventos, como uma solicitação HTTP ou uma mensagem de fila. Cada função é dimensionada conforme necessário para atender à demanda.

• Aplicativos Lógicos do Azure. Os Aplicativos Lógicos são mais adequados para criar e executar fluxos de trabalho automatizados que integram vários aplicativos, fontes de dados, serviços e sistemas. Assim como o Azure Functions, os Aplicativos Lógicos usam gatilhos internos para processamento controlado por eventos. No entanto, em vez de implantar o código do aplicativo, você pode criar aplicativos lógicos usando uma interface gráfica do usuário que dá suporte a blocos de código como condicionais e loops.

• Gerenciamento de API do Azure. Você pode usar o Gerenciamento de API para publicar, transformar, manter e monitorar APIs de segurança aprimorada usando a camada de Consumo.

• Power Apps e Power Automate. Essas ferramentas fornecem uma experiência de desenvolvimento low-code ou no-code, com lógica de fluxo de trabalho simples e integrações configuráveis por meio de conexões em uma interface de usuário.

Para aplicativos de missão crítica, as tecnologias sem servidor fornecem desenvolvimento e operações simplificados, o que pode ser valioso para casos de uso de negócios simples. No entanto, essa simplicidade tem o custo da flexibilidade em termos de escalabilidade, confiabilidade e desempenho, e isso não é viável para a maioria dos cenários de aplicativos críticos.

As seções a seguir fornecem considerações de design e recomendações para usar o Azure Functions e os Aplicativos Lógicos como plataformas alternativas para cenários de fluxo de trabalho não críticos.

Considerações e recomendações de design para o Azure Functions

As cargas de trabalho críticas têm fluxos de sistema críticos e não críticos. O Azure Functions é uma opção viável para fluxos que não têm os mesmos requisitos de negócios rigorosos que os fluxos críticos do sistema. Ele é adequado para fluxos controlados por eventos que têm processos de curta duração porque as funções executam operações distintas que são executadas o mais rápido possível.

Escolha uma opção de hospedagem do Azure Functions apropriada para a camada de confiabilidade do aplicativo. Recomendamos o plano Premium porque ele permite configurar o tamanho da instância de computação. O plano Dedicado é a opção menos sem servidor. Ele fornece dimensionamento automático, mas essas operações de escala são mais lentas do que as dos outros planos. Recomendamos que você use o plano Premium para maximizar a confiabilidade e o desempenho.

Existem algumas considerações de segurança. Ao usar um gatilho HTTP para expor um ponto de extremidade externo, use um WAF (firewall de aplicativo Web) para fornecer um nível de proteção para o ponto de extremidade HTTP contra vetores de ataque externos comuns.

Recomendamos o uso de pontos de extremidade privados para restringir o acesso a redes virtuais privadas. Eles também podem mitigar os riscos de exfiltração de dados, como cenários de administração mal-intencionados.

Você precisa usar ferramentas de verificação de código no código do Azure Functions e integrar essas ferramentas a pipelines de CI/CD.

Considerações e recomendações de design para Aplicativos Lógicos do Azure

Assim como o Azure Functions, os Aplicativos Lógicos usam gatilhos internos para processamento controlado por eventos. No entanto, em vez de implantar o código do aplicativo, você pode criar aplicativos lógicos usando uma interface gráfica do usuário que dá suporte a blocos como condicionais, loops e outras construções.

Vários modos de implantação estão disponíveis. Recomendamos o modo Standard para garantir uma implantação de locatário único e mitigar cenários de vizinhos barulhentos. Esse modo usa o runtime dos Aplicativos Lógicos de locatário único em contêineres, que se baseia no Azure Functions. Nesse modo, o aplicativo lógico pode ter vários fluxos de trabalho com e sem estado. Você deve estar ciente dos limites de configuração.

Migrações restritas via IaaS

Muitos aplicativos que têm implantações locais existentes usam tecnologias de virtualização e hardware redundante para fornecer níveis críticos de confiabilidade. A modernização geralmente é prejudicada por restrições de negócios que impedem o alinhamento total com o padrão de arquitetura de linha de base nativa de nuvem (Estrela do Norte) recomendado para cargas de trabalho críticas. É por isso que muitos aplicativos adotam uma abordagem em fases, com implantações iniciais de nuvem usando virtualização e Máquinas Virtuais do Azure como o principal modelo de hospedagem de aplicativos. O uso de VMs de infraestrutura como serviço (IaaS) pode ser necessário em determinados cenários:

• Os serviços de PaaS disponíveis não fornecem o desempenho ou o nível de controle necessários.
• A carga de trabalho requer acesso ao sistema operacional, drivers específicos ou configurações de rede e sistema.
• A carga de trabalho não dá suporte à execução em contêineres.
• Não há suporte do fornecedor para cargas de trabalho de terceiros.

Esta seção se concentra nas melhores maneiras de usar Máquinas Virtuais e serviços associados para maximizar a confiabilidade da plataforma de aplicativos. Ele destaca os principais aspectos da metodologia de design de missão crítica que transpõem cenários de migração nativos da nuvem e IaaS.

Considerações sobre o design

• Os custos operacionais do uso de VMs de IaaS são significativamente mais altos do que os custos de uso de serviços de PaaS devido aos requisitos de gerenciamento das VMs e dos sistemas operacionais. O gerenciamento de VMs exige a distribuição frequente de pacotes e atualizações de software.

• O Azure fornece recursos para aumentar a disponibilidade de VMs:

  • As zonas de disponibilidade podem ajudá-lo a alcançar níveis ainda mais altos de confiabilidade distribuindo VMs em datacenters fisicamente separados em uma região.
  • Os conjuntos de dimensionamento de máquinas virtuais do Azure fornecem funcionalidade para dimensionar automaticamente o número de VMs em um grupo. Eles também fornecem recursos para monitorar a integridade da instância e reparar automaticamente instâncias não íntegras.
  • Os conjuntos de dimensionamento com orquestração flexível podem ajudar a proteger contra falhas de rede, disco e energia distribuindo automaticamente as VMs entre domínios de falha.

Recomendações de design

• Dimensione corretamente os tamanhos de SKU de VM para garantir a utilização eficaz dos recursos.

• Implante três ou mais VMs em zonas de disponibilidade para obter tolerância a falhas no nível do datacenter.

  • Se você estiver implantando software comercial pronto para uso, consulte o fornecedor do software e teste adequadamente antes de implantar o software na produção.

• Para cargas de trabalho que você não pode implantar em zonas de disponibilidade, use conjuntos de dimensionamento de máquinas virtuais flexíveis que contenham três ou mais VMs. Para obter mais informações sobre como configurar o número correto de domínios de falha, consulte Gerenciar domínios de falha em conjuntos de dimensionamento.

• Priorize o uso de Conjuntos de Dimensionamento de Máquinas Virtuais para escalabilidade e redundância de zona. Esse ponto é particularmente importante para cargas de trabalho que têm cargas variadas. Por exemplo, se o número de usuários ativos ou solicitações por segundo for uma carga variável.

• Não acesse VMs individuais diretamente. Use balanceadores de carga na frente deles quando possível.

• Para se proteger contra interrupções regionais, implante VMs de aplicativo em várias regiões do Azure.

  • Consulte a área de design de rede e conectividade para obter detalhes sobre como rotear o tráfego de maneira ideal entre regiões de implantação ativas.

• Para cargas de trabalho que não dão suporte a implantações ativas/ativas de várias regiões, considere implementar implantações ativas/passivas usando VMs de espera quente/passiva para failover regional.

• Use imagens padrão do Azure Marketplace em vez de imagens personalizadas que precisam ser mantidas.

• Implemente processos automatizados para implantar e implementar alterações nas VMs, evitando qualquer intervenção manual. Para obter mais informações, consulte Considerações de IaaS na área de design de procedimentos operacionais.

• Implemente experimentos de caos para injetar falhas de aplicativo em componentes de VM e observe a mitigação de falhas. Para obter mais informações, consulte Validação e teste contínuos.

• Monitore as VMs e verifique se os logs e métricas de diagnóstico são ingeridos em um coletor de dados unificado.

• Implemente práticas de segurança para cenários de aplicativos críticos, quando aplicável, e as práticas recomendadas de segurança para cargas de trabalho de IaaS no Azure.

Próxima etapa

Revise as considerações para a plataforma de dados.