Preparar

Concluído

Você adicionará seus próprios aprimoramentos a uma arquitetura existente que atende aos requisitos de alta confiabilidade da organização. Aqui, discutiremos o contexto em segundo plano necessário para ter sucesso com os exercícios.

Contexto do problema

A Contoso Shoes precisa estar pronta para o próximo grande lançamento de produto, que deve criar um aumento significativo no tráfego. Nos últimos dois anos, houve diversos 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 passaram para a produção. A solução de problemas e a correção levaram muito tempo porque os operadores não conseguiram identificar rapidamente as causas-raiz.

Alguns desafios foram enfrentados quando certos componentes estavam indisponí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 para interrupções regionais. Em um incidente recente, toda a região Oeste da Europa ficou inativa. Como a carga de trabalho estava sendo executada somente naquela região, a empresa teve que arcar com prejuízos financeiros até que a região voltasse a funcionar.

Arquitetura atual

Para que você conclua esse desafio, é necessário ter uma boa compreensão da arquitetura atual da Contoso Shoes. Vamos nos concentrar na camada de API deles.

Componentes

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

• O 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 SKU B1 Básico.

• 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 de autenticação do Serviço de Aplicativo está habilitado para a autorização.

• Os slots de implantação permitem o preparo de uma implantação e, em seguida, a troca dela pela implantação de produção. Eles são usados somente na produção.

• O Registro de Contêiner do Azure armazena o código da API conteinerizada e é enviado por push através de pipelines de CI/CD (integração contínua/entrega contínua) criados e gerenciados pela equipe de carga de trabalho. A produção e o ambiente de desenvolvimento/teste usam o registro de contêiner.

• O Azure Cosmos DB com a API do 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 “Compartilhado”. A conta do Azure Cosmos DB usa o modo de capacidade “Sem Servidor”. Há uma instância para produção e outra para desenvolvimento/teste.

• O Azure Key Vault armazena os segredos necessários a fim de 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 Key Vault 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 a fim de armazenar logs e métricas de todas as configurações do Diagnóstico do Azure para todos os componentes usados na solução. Há um workspace para produção e outro para desenvolvimento/teste.

• O Azure Application Insights é usado para capturar a telemetria e os logs da API. Ele usa o modo independente, e não faz gravações em um workspace dedicado do Log Analytics. Os ambientes de produção e desenvolvimento/teste não compartilham uma instância comum.

• O Azure Pipelines é usado para abordagens de CI/CD que criam, testam e implantam a carga de trabalho em ambientes de pré-produção e produção. Os pipelines são gerenciados pela equipe de carga de trabalho, que também gerencia toda a infraestrutura na solução. O Bicep é a opção de tecnologia para IaC (infraestrutura como código).

Escolhas de design

Na lista de componentes, o selo de implantação consiste em serviços que participam do processamento de uma solicitação. Esses serviços incluem os Serviços de Aplicativos, o código da API e o Cosmos DB. O carimbo também inclui componentes não funcionais: Key Vault e Registro de Contêiner. 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 selo.

No selo, os Serviços de Aplicativos são configurados para que sejam dimensionados automaticamente com base na carga.

Ambientes separados são usados para produção e desenvolvimento/teste. O ambiente de produção usa o SKU Standard 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 em produção. O ambiente de desenvolvimento/teste usa o SKU Básico para otimização de custo. Ambos os ambientes têm as próprias instâncias de serviços. Os ambientes compartilham apenas o Registro de Contêiner.

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

Compensações

No entanto, como em tudo, há compensações com a arquitetura atual. Os requisitos de negócios priorizaram a otimização de custos sobre a confiabilidade e as operações. Para manter os limites de custo, a arquitetura não foi aprimorada. Os componentes ficam aquém ao aproveitar os recursos de confiabilidade oferecidos pela plataforma. 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 é muito pervasivo. 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 do 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 tenham obtido uma assinatura isolada do restante das soluções da Contoso Shoes.

Além disso, o ambiente de desenvolvimento/teste é um ambiente único e compartilhado por todos os membros da equipe de desenvolvimento e controle de qualidade. A escolha justificou-se pelo tamanho das equipes e pela coordenação entre elas não necessitar de maior grau de isolamento. À medida que a equipe e a solução evoluíram, o ambiente único de desenvolvimento/teste causou cada vez mais complexidade de integração à medida que os ciclos de vida de fluxo de trabalho colidiram. A rotatividade e seu impacto na confiabilidade têm sido caros.

Especificação do projeto

A empresa deseja adicionar recursos à arquitetura de solução para lidar com o aumento esperado na carga. Veja os seguintes requisitos de negócios:

• Adquirir a capacidade de resistir a falhas regionais estendendo a arquitetura para diversas regiões
• Melhorar a experiência do cliente oferecendo um atendimento mais rápido em uma região geograficamente mais próxima dele
• Alinhar-se ao roteiro do Azure e aproveitar os recursos de confiabilidade mais recentes oferecidos pelos serviços do Azure
• Detectar problemas antecipadamente e seu impacto em cascata no sistema por meio de um modelo geral de integridade

Esses requisitos consistem apenas na lista priorizada de planos de melhoria. A equipe de aplicativos está ciente de que todas as áreas de design devem ser consideradas a fim de elevar a confiabilidade desta solução a padrões de missão crítica. Depois que você ajudá-los com os aspectos abordados nos próximos exercícios, eles continuarão melhorando as soluções e operações.

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

Instalação

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

• Recomenda-se usar a ferramenta de diagramação de arquitetura para a visualização da arquitetura.
• Uma assinatura do Azure não será necessária para este desafio se você estiver familiarizado com os serviços e seus respectivos recursos.