Preparação

Concluído

Você adicionará seus próprios aprimoramentos a uma arquitetura existente que atenda aos requisitos de alta confiabilidade da organização. Aqui, discutiremos o contexto de fundo que você precisa para ter sucesso com os exercícios.

Contexto do problema

A Contoso Shoes precisa estar pronta para seu próximo lançamento de produto de alto perfil, que deve gerar um aumento significativo no tráfego. Nos últimos dois anos, houve vários incidentes que fizeram com que o site ficasse offline por até meio dia. O sistema não foi testado completamente no ambiente de desenvolvimento/teste, e alguns bugs entraram em produção. A solução de problemas e a correção levaram muito tempo, porque os operadores não foram capazes de identificar as causas básicas rapidamente.

Houve alguns desafios quando certos componentes não estão disponíveis. As operações de expansão na computação foram afetadas quando o Azure Key Vault foi configurado incorretamente. Além disso, não há estratégias em vigor para interrupções regionais. Num incidente recente, toda a região da Europa Ocidental caiu. Como a carga de trabalho estava funcionando apenas naquela região, a empresa teve que arcar com perdas financeiras até que a região voltasse a funcionar.

Arquitetura atual

Para concluir este desafio, você precisa ter um bom entendimento da arquitetura atual da Contoso Shoes. Vamos nos concentrar em sua camada de API.

Componentes

Todos os componentes dessa arquitetura são implantados em uma única região.

• A SKU Standard S2 do plano do Serviço de Aplicativo do Azure fornece a plataforma de computação que hospeda o aplicativo. O dimensionamento automático está ativado. O ambiente de desenvolvimento usa o Basic B1 SKU.

• O Serviço de Aplicativo do Azure fornece a plataforma de aplicativo que executa o código da API em um contêiner. O recurso Autenticação do Serviço de Aplicativo está habilitado para autorização.

• Os slots de implantação permitem preparar uma implantação e, em seguida, trocá-la pela implantação de produção. Eles são usados apenas na produção.

• O Registro de Contêiner do Azure armazena o código de API conteinerizado e é enviado por meio de pipelines de Integração Contínua/Entrega Contínua (CI/CD) que a equipe de carga de trabalho cria e gerencia. Tanto a produção quanto o ambiente de desenvolvimento/teste usam o registro de contêiner.

• O Azure Cosmos DB com API SQL armazena todo o estado relacionado à carga de trabalho. A conta de banco de dados do Cosmos DB tem um único banco de dados que contém alguns contêineres no modelo de taxa de transferência compartilhada. A conta do Azure Cosmos usa o modo de capacidade sem servidor. Há uma instância para produção e outra para desenvolvimento/teste.

• O Azure Key Vault armazena segredos necessários para que a API faça uma chamada HTTP POST para uma API externa de terceiros como parte de um fluxo de solicitação. O aplicativo acessa os segredos por meio de uma referência do Cofre da Chave na configuração do aplicativo do Serviço de Aplicativo do Azure. Há um Key Vault para produção e outro para desenvolvimento/teste.

• O Azure Log Analytics é usado como um coletor unificado para armazenar logs e métricas para todas as configurações de Diagnóstico do Azure para todos os componentes usados na solução. Há um espaço de trabalho para produção e outro para desenvolvimento/teste.

• O Azure Application Insights é usado para capturar telemetria e logs da API. O Application Insights usa o modo independente, não gravando em um espaço de trabalho dedicado de análise de log. Produção e desenvolvimento/teste não compartilham uma instância comum.

• O Azure Pipelines é usado para CI/CD que cria, testa e implanta a carga de trabalho em ambientes de pré-produção e produção. A equipe de carga de trabalho gerencia os pipelines, que também gerenciam toda a infraestrutura em sua solução. Bicep é a escolha da tecnologia para Infraestrutura como Código (IaC).

Opções de conceção

Na lista de componentes, o carimbo de implantação consiste em serviços que participam do processamento de uma solicitação. Esses serviços incluem os Serviços de Aplicativos e o código da API e o Cosmos DB. O carimbo também inclui componentes não funcionais: Key Vault e Container Registry. O aplicativo tem uma dependência de terceiros em uma estrutura de desempenho e resiliência. As identidades gerenciadas pelo sistema são usadas entre os componentes do carimbo.

No carimbo, os Serviços de Aplicativo são configurados para serem dimensionados automaticamente com base na carga.

Ambientes separados são usados para produção e desenvolvimento/teste. O ambiente de produção usa a SKU padrão do plano do Serviço de Aplicativo. A empresa fez essa escolha para poder pré-aquecer o aplicativo em um slot antes de implantá-lo na produção. O ambiente de desenvolvimento/teste usa o SKU básico para otimização de custos. Ambos os ambientes têm suas próprias instâncias de serviços. Os ambientes compartilham apenas o Registro de Contêiner.

O código da API em contêiner é entregue em uma única imagem de contêiner que é executada no Serviço de Aplicativo. A API tem vários pontos de extremidade HTTP que os vários frontends usam para leituras e gravações. Os frontends estão fora do escopo deste módulo, mas estão no escopo no panorama geral para o status de missão crítica dessa situação. O código foi instrumentado com o Application Insights para capturar algumas telemetrias básicas. A equipe que desenvolveu esse código também gerencia o pipeline de CI/CD para a imagem de contêiner de API e os pipelines de CI/CD.

Vantagens e desvantagens

No entanto, como em tudo, há compensações com a arquitetura atual. Os requisitos de negócios priorizaram a otimização de custos em detrimento da confiabilidade e das operações. Para se manter dentro dos limites de custo, a arquitetura não evoluiu. Os componentes ficam aquém quando se aproveitam os recursos de confiabilidade que a plataforma oferece. Por exemplo, a escolha de SKU para computação impede que a carga de trabalho use zonas de disponibilidade. Para telemetria, é usada uma versão mais antiga do Application Insights que não está integrada ao Log Analytics.

Além disso, o acesso à carga de trabalho é excessivamente generalizado. Por exemplo, sem qualquer integração de rede virtual, todos os serviços do Azure podem ser acessados diretamente pela Internet pública.

Quando a solução foi desenvolvida, a equipe de desenvolvimento de aplicativos usou uma única Assinatura do Azure, colocando desenvolvimento/teste e produção na mesma assinatura para facilitar as ferramentas para as equipes de DevOps. No entanto, os recursos de produção e os recursos de desenvolvimento/teste não estão completamente isolados. Alguns recursos são compartilhados entre os dois ambientes, embora eles tenham obtido uma assinatura isolada do restante das soluções da Contoso Shoes.

Além disso, o ambiente de desenvolvimento/teste é um ambiente único que é compartilhado entre todos os membros da equipe de desenvolvimento e controle de qualidade. A escolha foi justificada dada a dimensão das equipas e a coordenação entre elas não necessitava de um maior grau de isolamento. À medida que a equipe e a solução evoluíam, o ambiente único de desenvolvimento/teste causava cada vez mais complexidade de integração à medida que os ciclos de vida do fluxo de trabalho colidiam. A rotatividade e seu impacto na confiabilidade têm sido caros.

Especificação do projeto

A empresa quer adicionar recursos à sua arquitetura de soluções para que seja capaz de lidar com o aumento esperado de carga. Aqui estão os requisitos de negócios:

• Desenvolva a capacidade de resistir a falhas regionais estendendo a arquitetura a várias regiões
• Melhore a experiência do cliente atendendo os clientes mais rapidamente em uma região geograficamente mais próxima deles
• Alinhe-se com o roteiro do Azure e aproveite os recursos de confiabilidade mais recentes que os serviços do Azure oferecem
• Detete problemas precocemente e detete seu impacto em cascata no sistema, construindo um modelo de saúde geral

Esses requisitos são apenas a lista de prioridades de seus planos de melhoria. A equipe de aplicativos está ciente de que todas as áreas de projeto devem ser consideradas para elevar a confiabilidade desta solução aos padrões de missão crítica. Tenha certeza, eles não vão parar de melhorar sua solução e operações depois que você os ajudou com os aspetos abordados nos próximos exercícios.

Bem-vindo à equipa! A Contoso Shoes está ansiosa para ouvir suas recomendações.

Configurar

Neste Projeto de Desafio, você assumirá o papel de um arquiteto que ajudará a Contoso Shoes a alcançar seus resultados de confiabilidade, começando com os itens priorizados na seção anterior.

• Recomendamos que você use a ferramenta de diagramação de arquitetura para visualizar a arquitetura.
• Você não precisa de uma assinatura do Azure para este desafio se estiver confortável com os serviços e seus recursos.