Share via

Considerações da plataforma de aplicações para cargas de trabalho críticas para a missão no Azure

  • Artigo

O Azure fornece muitos serviços de computação para alojar aplicações de elevada disponibilidade. Os serviços diferem em capacidade e complexidade. Recomendamos que escolha os serviços com base em:

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

A escolha de uma plataforma de alojamento de aplicações é uma decisão crítica que afeta todas as outras áreas de design. Por exemplo, o software de desenvolvimento legado ou proprietário pode não ser executado em serviços PaaS ou aplicações em contentores. Esta limitação influenciaria a sua escolha de plataforma de computação.

Uma aplicação crítica para a missão pode utilizar mais do que um serviço de computação para suportar várias cargas de trabalho compostas e microsserviços, cada um com requisitos distintos.

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

Importante

Este artigo faz parte da série de cargas de trabalho críticas para a missão do Azure Well-Architected Framework . Se não estiver familiarizado com esta série, recomendamos que comece com O que é uma carga de trabalho crítica para a missão?.

Distribuição global de recursos da plataforma

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

Os serviços do Azure, que não estão restritos a uma determinada região do Azure, são implementados ou configurados como recursos globais. Alguns casos de utilização incluem a distribuição de tráfego em várias regiões, o armazenamento do estado permanente de toda uma aplicação e a colocação em cache de dados estáticos globais. Se precisar de acomodar uma arquitetura de unidades de escala e uma distribuição global, considere como os recursos são distribuídos ou replicados de forma otimizada em todas as regiões do Azure.

Outros recursos são implementados regionalmente. Estes recursos, que são implementados como parte de um selo de implementação, normalmente correspondem a uma unidade de escala. No entanto, uma região pode ter mais do que um selo e um selo pode ter mais do que uma unidade. A fiabilidade dos recursos regionais é crucial porque são responsáveis pela execução da carga de trabalho principal.

A imagem seguinte mostra a estrutura de alto nível. Um utilizador acede à aplicação através de um ponto de entrada global central que, em seguida, redireciona os pedidos para um carimbo de implementação regional adequado:

Diagrama que mostra uma arquitetura crítica para a missão.

A metodologia de conceção crítica para a missão requer uma implementação de várias regiões. Este modelo garante a tolerância a falhas regionais, para que a aplicação permaneça disponível mesmo quando uma região inteira fica inativa. Quando cria uma aplicação de várias regiões, considere diferentes estratégias de implementação, como ativas/ativas e ativas/passivas, juntamente com os requisitos da aplicação, porque existem compromissos significativos para cada abordagem. Para cargas de trabalho críticas para a missão, recomendamos vivamente o modelo ativo/ativo.

Nem todas as cargas de trabalho suportam ou necessitam de executar várias regiões em simultâneo. Deve ponderar requisitos de aplicações específicos relativamente a compromissos para determinar uma decisão de conceção ideal. Para determinados cenários de aplicação que têm destinos de fiabilidade mais baixos, as partições ativas/passivas ou horizontais podem ser alternativas adequadas.

As zonas de disponibilidade podem fornecer implementações regionais de elevada disponibilidade em diferentes datacenters numa região. Quase todos os serviços do Azure estão disponíveis numa configuração zonal, em que o serviço é delegado a uma zona específica ou numa configuração com redundância entre zonas, em que a plataforma garante automaticamente que o serviço se estende por zonas e pode suportar uma indisponibilidade de zona. Estas configurações fornecem tolerância a falhas até ao nível do datacenter.

Considerações de design

  • Capacidades regionais e zonais. Nem todos os serviços e capacidades estão disponíveis em todas as regiões do Azure. Esta consideração pode afetar as regiões que 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 numa única geografia. Alguns serviços do Azure utilizam regiões emparelhadas para garantir a continuidade do negócio e fornecer um nível de proteção contra a perda de dados. Por exemplo, o armazenamento georredundante (GRS) do Azure replica automaticamente os dados para uma região emparelhada secundária, garantindo que os dados são duráveis se a região primária não for recuperável. Se uma falha afetar várias regiões do Azure, pelo menos uma região em cada par é priorizada para recuperação.

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

  • Implementação segura. A arquitetura de práticas de implementação segura (SDP) do Azure garante que todas as alterações de código e configuração (manutenção planeada) na plataforma do Azure são submetidas a uma implementação faseada. O estado de funcionamento é analisado para degradação durante a versão. Após a conclusão das fases canary e pilot com êxito, as atualizações da plataforma são serializadas em pares regionais, pelo que apenas uma região em cada par é atualizada num determinado momento.

  • Capacidade da plataforma. Como qualquer fornecedor de cloud, o Azure tem recursos finitos. A indisponibilidade pode ser o resultado de limitações de capacidade em regiões. Se ocorrer uma indisponibilidade regional, haverá um aumento da procura de recursos à medida que a carga de trabalho tenta recuperar na região emparelhada. A indisponibilidade pode criar um problema de capacidade, em que a oferta não satisfaz temporariamente a procura.

Recomendações de conceção

  • Implemente a sua solução em, pelo menos, duas regiões do Azure para ajudar a proteger contra falhas regionais. Implemente-o em regiões com as capacidades e características necessárias para a carga de trabalho. As capacidades devem cumprir os objetivos de desempenho e disponibilidade ao cumprir os 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 compromissos de conceção. Nestes casos, recomendamos vivamente que adicione um investimento adicional em wrappers operacionais para prever, detetar e responder a falhas. Suponha que está limitado a uma geografia com duas regiões e que apenas uma dessas regiões suporta zonas de disponibilidade (modelo de datacenter 3 + 1). Crie um padrão de implementação secundário com o isolamento de domínio de falha para permitir que ambas as regiões sejam implementadas numa configuração ativa e certifique-se de que a região primária aloja vários selos de implementação.

    Se as regiões adequadas do Azure não oferecerem todas as capacidades de que precisa, esteja preparado para comprometer a consistência dos selos de implementação regional para priorizar a distribuição geográfica e maximizar a fiabilidade. Se apenas uma única região do Azure for adequada, implemente vários selos de implementação (unidades de escala regional) na região selecionada para mitigar algum risco e utilize zonas de disponibilidade para fornecer tolerância a falhas ao nível do datacenter. No entanto, um compromisso tão significativo na distribuição geográfica restringe drasticamente o SLA composto alcançável e a fiabilidade geral.

    Importante

    Para cenários que visam um SLO maior ou igual a 99,99%, recomendamos um mínimo de três regiões de implementação para maximizar o SLA composto e a fiabilidade geral. Calcular o SLA composto para todos os fluxos de utilizador. Certifique-se de que o SLA composto está alinhado com os destinos empresariais.

  • Para cenários de aplicação de alta escala com volumes significativos de tráfego, crie a solução para dimensionar em várias regiões para navegar por potenciais restrições de capacidade numa única região. Os selos de implementação regional adicionais alcançarão um SLA composto mais elevado. A utilização de recursos globais restringe o aumento do SLA composto que obtém ao adicionar mais regiões.

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

  • Numa única geografia, priorize a utilização de pares regionais para beneficiar das implementações serializadas do SDP para manutenção planeada e priorização regional para manutenção não planeada.

  • Coloca geograficamente os recursos do Azure com os utilizadores para minimizar a latência de rede e maximizar o desempenho ponto a ponto.

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

Contentorização

Um contentor inclui o código da aplicação e os ficheiros de configuração, bibliotecas e dependências relacionados que a aplicação precisa de executar. A contentorização fornece uma camada de abstração para o código da aplicação e as respetivas dependências e cria separação da plataforma de alojamento subjacente. O pacote de software único é altamente portátil e pode ser executado de forma consistente em várias plataformas de infraestrutura e fornecedores de cloud. Os programadores não precisam de reescrever código e podem implementar aplicações de forma mais rápida e fiável.

Importante

Recomendamos que utilize contentores para pacotes de aplicações críticos para a missão. Melhoram a utilização da infraestrutura porque pode alojar vários contentores na mesma infraestrutura virtualizada. Além disso, uma vez que todo o software está incluído no contentor, pode mover a aplicação em vários sistemas operativos, independentemente dos runtimes ou versões da biblioteca. A gestão também é mais fácil com os contentores do que com o alojamento virtualizado tradicional.

As aplicações críticas para a missão têm de ser dimensionadas rapidamente para evitar estrangulamentos de desempenho. Uma vez que as imagens de contentor são pré-criadas, pode limitar o arranque a ocorrer apenas durante o arranque da aplicação, o que proporciona uma escalabilidade rápida.

Considerações de design

  • Monitorização. Pode ser difícil para os serviços de monitorização acederem a aplicações que estão em contentores. Normalmente, precisa de software de terceiros para recolher e armazenar indicadores de estado de contentor, como a utilização da CPU ou da RAM.

  • Segurança. O kernel do SO da plataforma de alojamento é partilhado em vários contentores, criando um único ponto de ataque. No entanto, o risco de acesso à VM do anfitrião é limitado porque os contentores estão isolados do sistema operativo subjacente.

  • Estado. Embora seja possível armazenar dados no sistema de ficheiros de um contentor em execução, os dados não persistem quando o contentor for recriado. Em vez disso, mantenha os dados ao montar o armazenamento externo ou utilizar uma base de dados externa.

Recomendações de conceção

  • Colocar todos os componentes da aplicação em contentores. Utilize imagens de contentor como o modelo principal para pacotes de implementação de aplicações.

  • Priorize os runtimes de contentor baseados no Linux sempre que possível. As imagens são mais leves e as novas funcionalidades para nós/contentores do Linux são lançadas com frequência.

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

  • Certifique-se de que recolhe todos os registos e métricas relevantes do contentor, do anfitrião do contentor e do cluster subjacente. Envie os registos e as métricas recolhidos para um sink de dados unificado para processamento e análise adicionais.

  • Armazene imagens de contentor no Azure Container Registry. Utilize a georreplicação para replicar imagens de contentor em todas as regiões. Ative Microsoft Defender para registos de contentores para fornecer análise de vulnerabilidades para imagens de contentor. Certifique-se de que o acesso ao registo é gerido por Microsoft Entra ID.

Alojamento e orquestração de contentores

Várias plataformas de aplicações do Azure podem alojar contentores de forma eficaz. Existem vantagens e desvantagens associadas a cada uma destas plataformas. Compare as opções no contexto dos seus requisitos empresariais. No entanto, otimize sempre a fiabilidade, a escalabilidade e o desempenho. Para obter mais informações, veja estes artigos:

Importante

Azure Kubernetes Service (AKS) e a Azure Container Apps devem estar entre as suas primeiras opções de gestão de contentores, consoante os seus requisitos. Embora Serviço de Aplicações do Azure não seja um orquestrador, como uma plataforma de contentores de baixa fricção, ainda é uma alternativa viável ao AKS.

Considerações e recomendações de design para Azure Kubernetes Service

O AKS, um serviço do Kubernetes gerido, permite o aprovisionamento rápido de clusters sem exigir atividades de administração de clusters complexas e oferece um conjunto de funcionalidades que inclui redes avançadas e capacidades de identidade. Para obter um conjunto completo de recomendações, veja Revisão do Azure Well-Architected Framework – AKS.

Importante

Existem algumas decisões de configuração fundamentais que não pode alterar sem voltar a implementar o cluster do AKS. Os exemplos incluem a escolha entre clusters do AKS públicos e privados, ativar a Política de Rede do Azure, Microsoft Entra integração e a utilização de identidades geridas para o AKS em vez de principais de serviço.

Fiabilidade

O AKS gere o plano de controlo nativo do Kubernetes. Se o plano de controlo não estiver disponível, a carga de trabalho sofrerá um período de indisponibilidade. Tire partido das funcionalidades de fiabilidade oferecidas pelo AKS:

  • Implemente clusters do AKS em diferentes regiões do Azure como uma unidade de escala para maximizar a fiabilidade e a disponibilidade. Utilize zonas de disponibilidade para maximizar a resiliência numa região do Azure ao distribuir o plano de controlo do AKS e os nós de agente em datacenters fisicamente separados. No entanto, se a latência da colocação for um problema, pode realizar a implementação do AKS numa única zona ou utilizar grupos de colocação por proximidade para minimizar a latência de internos.

  • Utilize o SLA de Uptime do AKS para clusters de produção para maximizar as garantias de disponibilidade do ponto final da API do Kubernetes.

Escalabilidade

Tenha em conta os limites de dimensionamento do AKS, como o número de nós, conjuntos de nós por cluster e clusters por subscrição.

Isolamento

Mantenha os limites entre a infraestrutura utilizada pela carga de trabalho e as ferramentas do sistema. A infraestrutura de partilha pode levar a uma utilização elevada de recursos e cenários de vizinhos ruidosos.

  • Utilize conjuntos de nós separados para serviços de sistema e carga de trabalho. Os conjuntos de nós dedicados para componentes de carga de trabalho devem basear-se em requisitos para recursos de infraestrutura especializados, como VMs de GPU de memória elevada. Em geral, para reduzir a sobrecarga de gestão desnecessária, evite implementar um grande número de conjuntos de nós.

  • Utilize taints e tolerâncias para fornecer nós dedicados e limitar aplicações que consomem muitos recursos.

  • Avalie os requisitos de afinidade e antiafinidade da aplicação e configure a colocalização adequada de contentores em nós.

Segurança

O Kubernetes de baunilha predefinido requer uma configuração significativa para garantir uma postura de segurança adequada para cenários críticos para a missão. O AKS resolve vários riscos de segurança fora da caixa. As funcionalidades incluem clusters privados, auditoria e início de sessão no Log Analytics, imagens de nós endurecidas e identidades geridas.

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

  • Utilize as funcionalidades do AKS para processar a gestão de identidades e acessos do cluster para reduzir a sobrecarga operacional e aplicar uma gestão de acesso consistente.

  • Utilize identidades geridas em vez de principais de serviço para evitar a gestão e rotação de credenciais. Pode adicionar identidades geridas ao nível do cluster. Ao nível do pod, pode utilizar identidades geridas através de ID de carga de trabalho Microsoft Entra.

  • Utilize Microsoft Entra integração para gestão de contas e palavras-passe centralizadas, gestão de acesso a aplicações e proteção de identidade melhorada. Utilize o RBAC do Kubernetes com Microsoft Entra ID para obter o mínimo de privilégios e minimize a concessão de privilégios de administrador para ajudar a proteger o acesso à configuração e aos segredos. Além disso, limite o acesso ao ficheiro de configuração do cluster do Kubernetes com o controlo de acesso baseado em funções do Azure. Limite o acesso a ações que os contentores podem executar, forneça o menor número de permissões e evite a utilização do escalamento de privilégios de raiz.

Atualizações

Os clusters e nós têm de ser atualizados regularmente. O AKS suporta versões do Kubernetes em linha com o ciclo de lançamento do Kubernetes nativo.

  • Subscreva as Notas de Versão e o Plano do AKS públicos no GitHub para se manter atualizado sobre as próximas alterações, melhorias e, mais importante, versões e depreciações do Kubernetes.

  • Aplique a documentação de orientação fornecida na lista de verificação do AKS para garantir o alinhamento com as melhores práticas.

  • Tenha em atenção os vários métodos suportados pelo AKS para atualizar nós e/ou clusters. Estes métodos podem ser manuais ou automatizados. Pode utilizar a Manutenção Planeada para definir janelas de manutenção para estas operações. As novas imagens são lançadas semanalmente. O AKS também suporta canais de atualização automática para atualizar automaticamente clusters do AKS para versões mais recentes do Kubernetes e/ou imagens de nós mais recentes quando estiverem disponíveis.

Rede

Avalie os plug-ins de rede que melhor se adequam ao seu caso de utilização. Determine se precisa de um controlo granular do tráfego entre pods. O Azure suporta kubenet, Azure CNI e traga a sua própria CNI para casos de utilização específicos.

Priorize a utilização do CNI do Azure após avaliar os requisitos de rede e o tamanho do cluster. O Azure CNI permite a utilização de políticas de rede do Azure ou do Calico para controlar o tráfego dentro do cluster.

Monitorização

As ferramentas de monitorização devem conseguir capturar registos e métricas de pods em execução. Também deve recolher informações da API de Métricas do Kubernetes para monitorizar o estado de funcionamento dos recursos e cargas de trabalho em execução.

Governação

Utilize políticas para aplicar salvaguardas centralizadas aos clusters do AKS de forma consistente. Aplique atribuições de políticas num âmbito de subscrição ou superior para impulsionar a consistência entre equipas de desenvolvimento.

  • Controle as funções que são concedidas aos pods e se a execução contradiz a política com Azure Policy. Este acesso é definido através de políticas incorporadas fornecidas pelo Suplemento Azure Policy para o AKS.

  • Estabeleça uma linha de base de segurança e fiabilidade consistentes para configurações de clusters e pods do AKS com Azure Policy.

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

Nota

Quando implementa numa zona de destino do Azure, as políticas do Azure para o ajudar a garantir uma fiabilidade e segurança consistentes devem ser fornecidas pela implementação da zona de destino.

As implementações de referência críticas para a missão fornecem um conjunto de políticas de linha de base para impulsionar a fiabilidade recomendada e as configurações de segurança.

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

Para cenários de cargas de trabalho baseados na Web e na API, Serviço de Aplicações pode ser uma alternativa viável ao AKS. Fornece uma plataforma de contentores com pouca fricção sem a complexidade do Kubernetes. Para obter um conjunto completo de recomendações, veja Considerações de fiabilidade para Serviço de Aplicações e Excelência operacional para Serviço de Aplicações.

Fiabilidade

Avalie a utilização das portas TCP e SNAT. As ligações TCP são utilizadas para todas as ligações de saída. As portas SNAT são utilizadas para ligações de saída a endereços IP públicos. O esgotamento da porta SNAT é um cenário de falha comum. Deve detetar previsivelmente este problema através do teste de carga ao utilizar Diagnóstico do Azure para monitorizar as portas. Se ocorrerem erros SNAT, tem de dimensionar entre mais ou mais trabalhos ou implementar práticas de codificação para ajudar a preservar e reutilizar as portas SNAT. Exemplos de práticas de codificação que pode utilizar incluem o conjunto de ligações e o carregamento em diferido de recursos.

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

Escalabilidade

Planeie futuros requisitos de escalabilidade e crescimento de aplicações para que possa aplicar as recomendações adequadas desde o início. Ao fazê-lo, pode evitar a dívida de migração técnica à medida que a solução cresce.

  • Ative o dimensionamento automático para garantir que estão disponíveis recursos adequados para pedidos de serviço. Avalie o dimensionamento por aplicação para alojamento de alta densidade no Serviço de Aplicações.

  • Tenha em atenção que Serviço de Aplicações tem um limite predefinido e flexível de instâncias por plano Serviço de Aplicações.

  • Aplicar regras de dimensionamento automático. Um plano de Serviço de Aplicações aumenta horizontalmente se qualquer regra dentro do perfil for cumprida, mas apenas dimensiona se todas as regras dentro do perfil forem cumpridas. Utilize uma combinação de regras de aumento horizontal e redução horizontal para garantir que o dimensionamento automático pode tomar medidas para aumentar horizontalmente e reduzir horizontalmente. Compreender o comportamento de múltiplas regras de dimensionamento num único perfil.

  • Tenha em atenção que pode ativar o dimensionamento por aplicação ao nível do plano de Serviço de Aplicações para permitir que uma aplicação seja dimensionada de forma independente do plano de Serviço de Aplicações que o aloja. As aplicações são alocadas a nós disponíveis através 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 da mesma aplicação não estão alojadas na mesma instância.

Monitorização

Monitorize o comportamento da aplicação e obtenha acesso a registos e métricas relevantes para garantir que a sua aplicação funciona conforme esperado.

  • Pode utilizar o registo de diagnósticos para ingerir registos ao nível da aplicação e ao nível da plataforma no Log Analytics, no Armazenamento do Azure ou numa ferramenta de terceiros através de Hubs de Eventos do Azure.

  • A monitorização do desempenho de aplicações com o Application Insights fornece informações aprofundadas sobre o desempenho da aplicação.

  • As aplicações fundamentais para a missão têm de ter a capacidade de se auto-curar se existirem falhas. Ative a Recuperação Automática para reciclar automaticamente as funções de trabalho em mau estado de funcionamento.

  • Tem de utilizar as verificações de estado de funcionamento adequadas para avaliar todas as dependências críticas a jusante, o que ajuda a garantir o estado de funcionamento geral. Recomendamos vivamente que ative a Verificação de Estado de Funcionamento para identificar as funções de trabalho não reativas.

Implementação

Para contornar o limite predefinido de instâncias por Serviço de Aplicações plano, implemente Serviço de Aplicações planos em várias unidades de escala numa única região. Implemente Serviço de Aplicações planos numa configuração de zona de disponibilidade para garantir que os nós de trabalho são distribuídos entre zonas numa região. Considere abrir um pedido de suporte para aumentar o número máximo de trabalhadores para o dobro da contagem de instâncias de que precisa para servir a carga máxima normal.

Registo de contentor

Os registos de contentores alojam imagens que são implementadas em ambientes de runtime de contentor, como o AKS. Tem de configurar cuidadosamente os registos de contentores para cargas de trabalho fundamentais para a missão. Uma falha não deve causar atrasos na solicitação de imagens, especialmente durante as operações de dimensionamento. As seguintes considerações e recomendações focam-se no Azure Container Registry e exploram as compensações associadas a modelos de implementação centralizados e federados.

Considerações de design

  • Formatar. Considere utilizar um registo de contentor que se baseie no formato e padrões fornecidos pelo Docker para operações push e pull. Estas soluções são compatíveis e, na sua maioria, intercambiáveis.

  • Modelo de implementação. Pode implementar o registo de contentor como um serviço centralizado que é consumido por várias aplicações na sua organização. Em alternativa, pode implementá-lo como um componente dedicado para uma carga de trabalho de aplicação específica.

  • Registos públicos. As imagens de contentor são armazenadas em Docker Hub ou noutros registos públicos que existem fora do Azure e numa determinada rede virtual. Isto não é necessariamente um problema, mas pode levar a vários problemas relacionados com a disponibilidade do serviço, a limitação e a exfiltração de dados. Para alguns cenários de aplicações, tem de replicar imagens de contentor públicas num registo de contentor privado para limitar o tráfego de saída, aumentar a disponibilidade ou evitar uma possível limitação.

Recomendações de conceção

  • Utilize instâncias do registo de contentores dedicadas à carga de trabalho da aplicação. Evite criar uma dependência num serviço centralizado, a menos que os requisitos de disponibilidade e fiabilidade organizacionais estejam totalmente alinhados com a aplicação.

    No padrão de arquitetura principal recomendado, os registos de contentores são recursos globais que têm uma vida longa. Considere utilizar um único registo de contentor global por ambiente. Por exemplo, utilize um registo de produção global.

  • Certifique-se de que o SLA do registo público está alinhado com os seus destinos de fiabilidade e segurança. Tome nota especial dos limites de limitação para casos de utilização que dependem de Docker Hub.

  • Priorize Azure Container Registry para alojar imagens de contentor.

Considerações e recomendações de design para Azure Container Registry

Este serviço nativo fornece uma variedade de funcionalidades, incluindo georreplicação, autenticação Microsoft Entra, criação automatizada de contentores e aplicação de patches através de tarefas do Container Registry.

Fiabilidade

Configure a georreplicação para todas as regiões de implementação para remover dependências regionais e otimizar a latência. O Container Registry suporta elevada disponibilidade através da georreplicação para várias regiões configuradas, proporcionando resiliência contra falhas regionais. Se uma região ficar indisponível, as outras regiões continuarão a apresentar pedidos de imagem. Quando a região estiver novamente online, o Container Registry recupera e replica as alterações à mesma. Esta capacidade também fornece colocalização de registo 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 para a zona de disponibilidade, o escalão Premium Container Registry suporta redundância de zona para fornecer proteção contra falhas zonais. O escalão Premium também suporta pontos finais privados para ajudar a impedir o acesso não autorizado ao registo, o que pode levar a problemas de fiabilidade.

Aloje imagens perto dos recursos de computação que consomem, nas mesmas regiões do Azure.

Bloqueio de imagem

As imagens podem ser eliminadas, como resultado, por exemplo, de um erro manual. O Container Registry suporta o bloqueio de uma versão de imagem ou de um repositório para impedir alterações ou eliminações. Quando uma versão de imagem implementada anteriormente é alterada, as implementações da mesma versão podem fornecer resultados diferentes antes e depois da alteração.

Se quiser proteger a instância do Container Registry contra a eliminação, utilize bloqueios de recursos.

Imagens com etiquetas

As imagens do Container Registry etiquetadas são mutáveis por predefinição, o que significa que a mesma etiqueta pode ser utilizada em várias imagens enviadas para o registo. Em cenários de produção, isto pode levar a comportamentos imprevisíveis que podem afetar o tempo de atividade da aplicação.

Gestão de identidades e acessos

Utilize Microsoft Entra autenticação integrada para emitir e extrair imagens em vez de depender de chaves de acesso. Para maior segurança, desative totalmente a utilização da chave de acesso de administrador.

Computação sem servidor

A computação sem servidor fornece recursos a pedido e elimina a necessidade de gerir a infraestrutura. O fornecedor de cloud aprovisiona, dimensiona e gere automaticamente os recursos necessários para executar o código da aplicação implementado. O Azure fornece várias plataformas de computação sem servidor:

  • Funções do Azure. Quando utiliza Funções do Azure, a lógica da aplicação é implementada como blocos distintos de código ou funções, que são executados em resposta a eventos, como um pedido HTTP ou uma mensagem de fila. Cada função dimensiona conforme necessário para satisfazer a procura.

  • Azure Logic Apps. O Logic Apps é mais adequado para criar e executar fluxos de trabalho automatizados que integram várias aplicações, origens de dados, serviços e sistemas. Tal como Funções do Azure, o Logic Apps utiliza acionadores incorporados para processamento orientado por eventos. No entanto, em vez de implementar o código da aplicação, pode criar aplicações lógicas com uma interface de utilizador gráfica que suporte blocos de código como condicionais e ciclos.

  • Azure Gestão de API. Pode utilizar Gestão de API para publicar, transformar, manter e monitorizar APIs de segurança melhorada com a camada Consumo.

  • Power Apps e Power Automate. Estas ferramentas fornecem uma experiência de desenvolvimento de baixo código ou sem código, com lógica de fluxo de trabalho simples e integrações configuráveis através de ligações numa interface de utilizador.

Para aplicações críticas para a missão, as tecnologias sem servidor fornecem operações e desenvolvimento simplificados, que podem ser úteis para casos de utilização empresarial simples. No entanto, esta simplicidade tem o custo da flexibilidade em termos de escalabilidade, fiabilidade e desempenho, o que não é viável para a maioria dos cenários de aplicação críticos para a missão.

As secções seguintes fornecem considerações e recomendações de conceção para utilizar Funções do Azure e Logic Apps como plataformas alternativas para cenários de fluxo de trabalho não críticos.

Considerações e recomendações de design para Funções do Azure

As cargas de trabalho críticas para a missão têm fluxos de sistema críticos e não críticos. Funções do Azure é uma opção viável para fluxos que não têm os mesmos requisitos de negócio rigorosos que os fluxos de sistema críticos. É adequado para fluxos orientados 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 alojamento Funções do Azure adequada para o escalão de fiabilidade da aplicação. Recomendamos o plano Premium porque lhe permite configurar o tamanho da instância de computação. O plano Dedicado é a opção menos sem servidor. Fornece dimensionamento automático, mas estas operações de dimensionamento são mais lentas do que as dos outros planos. Recomendamos que utilize o plano Premium para maximizar a fiabilidade e o desempenho.

Existem algumas considerações de segurança. Quando utiliza um acionador HTTP para expor um ponto final externo, utilize uma firewall de aplicações Web (WAF) para fornecer um nível de proteção para o ponto final HTTP a partir de vetores de ataque externos comuns.

Recomendamos a utilização de pontos finais privados para restringir o acesso a redes virtuais privadas. Também podem mitigar riscos de exfiltração de dados, como cenários de administrador malicioso.

Tem de utilizar ferramentas de análise de código no código Funções do Azure e integrar essas ferramentas em pipelines ci/CD.

Considerações e recomendações de design para o Azure Logic Apps

Tal como Funções do Azure, o Logic Apps utiliza acionadores incorporados para processamento orientado por eventos. No entanto, em vez de implementar o código da aplicação, pode criar aplicações lógicas através de uma interface de utilizador gráfica que suporte blocos como condicionais, ciclos e outras construções.

Estão disponíveis vários modos de implementação . Recomendamos o modo Standard para garantir uma implementação de inquilino único e mitigar cenários de vizinhos ruidosos. Este modo utiliza o runtime do Logic Apps de inquilino único em contentores, que se baseia em Funções do Azure. Neste modo, a aplicação lógica pode ter vários fluxos de trabalho com estado e sem estado. Deve estar ciente dos limites de configuração.

Migrações restritas através de IaaS

Muitas aplicações que têm implementações no local existentes utilizam tecnologias de virtualização e hardware redundante para fornecer níveis críticos de fiabilidade. A modernização é muitas vezes dificultada por restrições empresariais que impedem o alinhamento total com o padrão de arquitetura da linha de base nativa da cloud (Estrela do Norte) recomendado para cargas de trabalho críticas para a missão. É por isso que muitas aplicações adotam uma abordagem faseada, com implementações na cloud iniciais que utilizam a virtualização e o Azure Máquinas Virtuais como o modelo de alojamento de aplicações primária. A utilização de máquinas virtuais IaaS pode ser necessária em determinados cenários:

  • Os serviços PaaS disponíveis não fornecem o desempenho ou o nível de controlo necessários.
  • A carga de trabalho requer acesso ao sistema operativo, controladores específicos ou configurações de rede e sistema.
  • A carga de trabalho não suporta a execução em contentores.
  • Não existe suporte de fornecedor para cargas de trabalho de terceiros.

Esta secção foca-se nas melhores formas de utilizar o Azure Máquinas Virtuais e os serviços associados para maximizar a fiabilidade da plataforma de aplicações. Destaca aspetos fundamentais da metodologia de design crítica para a missão que transpõe cenários de migração IaaS e nativos da cloud.

Considerações de design

  • Os custos operacionais da utilização de máquinas virtuais IaaS são significativamente superiores aos custos da utilização de serviços PaaS devido aos requisitos de gestão das máquinas virtuais e dos sistemas operativos. A gestão de máquinas virtuais requer a implementação frequente de pacotes de software e atualizações.

  • O Azure fornece capacidades para aumentar a disponibilidade das máquinas virtuais:

Recomendações de conceção

Importante

Utilize os serviços e contentores PaaS sempre que possível para reduzir a complexidade operacional e os custos. Utilize máquinas virtuais IaaS apenas quando precisar.

  • Tamanhos de SKU da VM de tamanho correto para garantir uma utilização eficaz dos recursos.

  • Implemente três ou mais máquinas virtuais em zonas de disponibilidade para alcançar a tolerância a falhas ao nível do datacenter.

    • Se estiver a implementar software comercial fora da prateleira, consulte o fornecedor de software e teste adequadamente antes de implementar o software em produção.

  • Para cargas de trabalho que não podem ser implementadas em zonas de disponibilidade, utilize conjuntos de disponibilidade que contenham três ou mais VMs.

    • Considere os conjuntos de disponibilidade apenas se as zonas de disponibilidade não cumprirem os requisitos da carga de trabalho, como para cargas de trabalho chaty com requisitos de latência baixos.

  • Priorize a utilização de Conjuntos de Dimensionamento de Máquinas Virtuais para escalabilidade e redundância entre zonas. Este ponto é particularmente importante para cargas de trabalho que têm cargas variadas. Por exemplo, se o número de utilizadores ativos ou pedidos por segundo for uma carga variável.

  • Não aceda diretamente a máquinas virtuais individuais. Utilize balanceadores de carga à sua frente sempre que possível.

  • Para proteger contra falhas regionais, implemente máquinas virtuais de aplicações em várias regiões do Azure.

  • Para cargas de trabalho que não suportam implementações ativas/ativas de várias regiões, considere implementar implementações ativas/passivas com máquinas virtuais de reserva frequentes/quentes para ativação pós-falha regional.

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

  • Implemente processos automatizados para implementar e implementar alterações em máquinas virtuais, evitando qualquer intervenção manual. Para obter mais informações, veja Considerações de IaaS na área de estrutura procedimentos operacionais .

  • Implemente experimentações de caos para injetar falhas de aplicações em componentes de máquinas virtuais e observe a mitigação de falhas. Para obter mais informações, veja Validação e teste contínuos.

  • Monitorize máquinas virtuais e certifique-se de que os registos de diagnóstico e as métricas são ingeridos num sink de dados unificado.

  • Implemente práticas de segurança para cenários de aplicações fundamentais para a missão, quando aplicável, e as melhores práticas de segurança para cargas de trabalho IaaS no Azure.

Passo seguinte

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

Plataforma de dados