Exercício: Criar um modelo de integridade do aplicativo
A Contoso Shoes precisa detectar, diagnosticar e prever problemas na arquitetura. Você deseja criar um modelo de integridade mensurável por meio de um status de integridade que é aplicado a fluxos do usuário e do sistema. O objetivo é identificar possíveis pontos de falha antes que eles causem uma interrupção.
Estado atual e problema
Até agora, você adicionou uma API de verificação de integridade e criou recursos de várias regiões em sua arquitetura. No entanto, não há uma maneira de saber mais detalhes sobre a topologia complexa que inclui fluxos do usuário e do sistema. Esse problema precisa ser resolvido para que a equipe de SRE possa identificar e resolver erros rapidamente.
Em um incidente recente, a equipe não conseguiu ver o impacto em cascata de um problema gerado por um componente da API que afeta as dependências de plataforma. Um tempo significativo foi gasto na solução de problemas porque o componente não íntegro não foi detectado imediatamente. Em última análise, essa ineficiência levou a tempos de inatividade mais longos, causando perda financeira para a empresa.
Especificação
Projete um modelo de integridade que mostre a relação entre todos os componentes na arquitetura, incluindo os componentes do aplicativo e as dependências da plataforma. Considere os itens que existem no fluxo de solicitação, como gateway, computação, bancos de dados, armazenamento, caches e assim por diante. Inclua também componentes que normalmente existem fora do fluxo de solicitação. Por exemplo, artefatos da OCI (Open Container Initiative), armazenamentos de segredos, serviços de configuração, entre outros. Todos os serviços do Azure devem ser configurados para enviar dados de diagnóstico.
Adicione um coletor de dados unificado na arquitetura para coletar dados de diversas fontes.
Defina um status de integridade geral com base em métricas e logs históricos agregados. Represente o status em um dos três estados de integridade: não íntegro, degradado e íntegro.
Visualize o status de integridade de todos os componentes em uma hierarquia que representa todos os fluxos.
Abordagem recomendada
Para começar a usar o seu design, recomendamos que você siga estas etapas:
Importante
A modelagem de integridade é um exercício abrangente. A abordagem nesta seção destina-se a ajudar você a começar. Seja abrangente ao aplicar o modelo a todos os fluxos funcionais e não funcionais em seu design crítico para obter uma visão holística do sistema.
1 – Iniciar modelagem de integridade
Este exercício é teórico. Modelagem de integridade em uma atividade de design de cima para baixo em que você precisa de uma lista abrangente de componentes usados na arquitetura. Essa lista deve incluir todos os componentes do aplicativo e os serviços do Azure.
Coloque esses componentes em um gráfico de dependência que mostra uma visão hierárquica da solução. A camada superior tem os fluxos de usuários que acompanham a solicitação do usuário final ao site, e flui no nível da API do aplicativo. A camada inferior contém os fluxos do sistema dos serviços do Azure. Mapeie também as dependências entre os recursos do Azure.
O gráfico deve ser parecido com o seguinte:
Verifique o progresso: Integridade do aplicativo em camadas
2 – Definir as pontuações de integridade
Para cada componente, colete métricas e limites de métrica e decida o valor de acordo com o qual o componente deve ser considerado íntegro, degradado e não íntegro. Essa decisão deve ser influenciada pelo desempenho esperado e pelos requisitos de negócios não funcionais. Categorize suas métricas da seguinte maneira:
Métricas de aplicativo: Pontos de dados do código do aplicativo, como a contagem de exceções.
Métricas de serviço: Pontos de dados dos serviços do Azure, como unidades de transação de banco de dados (DTUs) em uso.
Métricas de solução: Pontos de dados no nível da solução, como o tempo de processamento de ponta a ponta de uma solicitação.
Aqui está um exemplo para os Serviços de Aplicativos do Azure:
| Serviços de Aplicativos | Status de integridade |
|---|---|
| Tempo de resposta < 200 ms Erros do servidor HTTP < 2 |
 |
| Tempo de resposta < 500 ms Erros do servidor HTTP < 2 |
 |
| Tempo de resposta > 500 ms Erros do servidor HTTP > 2 |
 |
3 – Definir um estado geral de integridade
Para cada fluxo do usuário e do sistema, defina um status geral. Será necessário agregar o status de integridade de componentes individuais que participam desse fluxo.
Suponha que um fluxo do sistema seja composto por um componente de aplicativo, um plano do Serviço de Aplicativo do Azure e Serviços de Aplicativo.
| API | Plano do Serviço de Aplicativo | Serviços de Aplicativos | Status de integridade |
|---|---|---|---|
| Latência máxima < 30 ms | % de CPU < 70% Comprimento da fila HTTP < 5 |
Tempo de resposta < 200 ms Erros do servidor HTTP < 2 |
|
| Latência máxima < 30 ms | % de CPU < 90% Comprimento da fila HTTP < 5 |
Tempo de resposta < 500 ms Erros do servidor HTTP < 2 |
|
| Latência máxima > 30 ms | % de CPU > 90% Comprimento da fila HTTP > 5 |
Tempo de Resposta > 500ms Erros de Servidor HTTP > 2 |
|
A pontuação de integridade de um fluxo do usuário deve ser representada pela pontuação mais baixa em todos os componentes mapeados. Para fluxos do sistema, aplique os pesos apropriados com base na importância para os negócios. Entre os dois fluxos, priorize os fluxos de usuário financeiramente significativos ou voltados ao cliente.
Verifique o progresso: Exemplo ─ Modelo de integridade em camadas
4 – Coletar dados de monitoramento
Você precisará de um coletor de dados unificado em cada região que colete logs e métricas para todos os serviços de aplicativo e plataforma implantados como parte do carimbo regional. Você precisará de outro coletor para armazenar as métricas emitidas por recursos globais, como o Azure Front Door e o Cosmos DB.
Opções de tecnologia
- Azure Application Insights: Usado para coletar todos os dados telemétricos do aplicativo.
- Logs do Azure Monitor: Coleta dados enviados por insights de aplicativo e métricas de plataforma para os serviços do Azure.
- Azure Log Analytics: Usado como a ferramenta central para analisar logs e métricas de todos os componentes de aplicativo e infraestrutura.
Verifique o progresso: Coletor de dados unificado para análise correlacionada
5 – Configurar consultas para dados de monitoramento
A KQL (Linguagem de Consulta Kusto) é bem integrada ao Log Analytics. Implemente consultas KQL personalizadas como funções para recuperar dados do Azure Monitor.
Armazene consultas personalizadas no repositório de códigos para importá-las e aplicá-las automaticamente como parte dos pipelines de CI/CD (integração contínua/entrega contínua).
6 – Visualizar o status de integridade
Você pode visualizar o grafo de dependência com pontuações de integridade com uma representação de semáforo. Use ferramentas como Painéis do Azure, Pastas de Trabalho do Azure Monitor ou o Grafana. Aqui está um exemplo:
Verifique o progresso: Visualização
7 – Configurar alertas sobre alterações de status
Você deve usar painéis com alertas para chamar a atenção imediatamente para problemas.
Se o estado de integridade de um componente mudar para Degradado ou Não íntegro, o operador deverá ser notificado imediatamente. Defina alertas no nó raiz, pois qualquer alteração nesse nó indica estado não íntegro nos fluxos ou recursos subjacentes do usuário.
Verifique o progresso: Alertas
Verificar seu trabalho
Assista a esta demonstração sobre monitoramento e modelagem de integridade. Você abordou todos os aspectos do design?
- Você tem um coletor de dados unificado para análise correlacionada?
- Você incluiu logs de aplicativos, métricas de plataforma e pontos de dados de solução?
- Você configurou painéis para visualizar o status de integridade de todos os componentes?
- Você considerou pontos de falha em cada serviço (ou em partes do serviço) que poderiam causar uma interrupção ou impedir o escalonamento, a implantação ou o monitoramento?
- Você considerou os pacotes de consulta para capturar as principais consultas que ajudariam na triagem mais rápida dos problemas?
- Sua API de verificação de integridade foi útil neste modelo? Você precisou alterar essa API para se adequar melhor ao modelo de integridade?