Exercício – Definir o estado de integridade, as métricas e os limites
Neste exercício, continuaremos com a estrutura do modelo de integridade que você criou anteriormente. Sua tarefa é quantificar os estados de integridade de componentes individuais do aplicativo de exemplo.
Na estrutura do modelo de integridade, comece avaliando as camadas começando na parte superior com fluxos de usuário e prosseguindo para as camadas inferiores.
Estado de integridade do fluxo do usuário
Até agora, identificamos dois fluxos de usuário: Listar itens do catálogo e Adicionar comentário. Para determinar os estados de integridade de cada fluxo, faça perguntas como:
- Quando o fluxo de usuário é considerado íntegro?
- Ele pode operar em um estado degradado?
Com base na implementação e nos requisitos funcionais, identifique os componentes do aplicativo que participam do fluxo do usuário. Os componentes são descritos em Componentes de arquitetura de exemplo.
| Fluxo de usuário | Componentes |
|---|---|
| Listar itens do catálogo | Aplicativo Web interno de front-end, API de Catálogo |
| Adicionar comentário | Aplicativo Web interno de front-end, API de Catálogo, processador em segundo plano |
Se um desses componentes perder a integridade, o fluxo de usuário também a perderá.
Observação
Alguns aplicativos podem operar em um modo degradado especial. Por exemplo, se a Contoso Shoes implementar o cache do navegador local, os funcionários que estiverem usando o aplicativo Web poderão criar comentários, mas os comentários não poderão ser enviados e a exibição do cliente não será atualizada até que a API de Catálogo fique íntegra, o que o navegador pode verificar continuamente.
Estado de integridade do componente do aplicativo
Determine as métricas que contribuem para o estado de integridade do componente. Para esta etapa, você precisa conhecer a funcionalidade do componente. Faça perguntas como:
- Qual tempo de processamento na API é aceitável para manter uma boa experiência do usuário?
- Há erros esperados? Qual é a taxa de erros "normal"?
- Qual é o tempo de processamento "normal"? O que significa quando o tempo de processamento é maior que o normal?
- O que acontece com as operações de gravação quando o Azure Cosmos DB está inacessível?
Com essas perguntas, você saberá quais são os limites específicos e mensuráveis das principais métricas. Por exemplo, você pode considerar esses valores limite para o componente API de Catálogo.
| Métricas e limite | Estado de integridade |
|---|---|
| Tempo de resposta < Contagem de solicitações com falha de 150 ms < 10 | Healthy |
| Tempo de Resposta < Contagem de solicitações com falha de 300 ms < 50 | Degradado |
| Tempo de Resposta < Contagem de solicitações com falha de 300 ms < 50 | Unhealthy |
Você pode obter os valores de uma solução de monitoramento de aplicativos, como o Application Insights.
Estados do Azure Resource Health
Os estados do Azure Resource Health são baseados em recursos específicos. Por exemplo, o Azure Cosmos DB relata a utilização da unidade de transação de banco de dados (DTU), e os Serviços de Aplicativo do Azure fornecem informações sobre a utilização da CPU.
Para obter informações sobre métricas por tipo de recurso, confira Métricas com suporte no Azure Monitor.
Estados de integridade e limites
Após avaliar todas as camadas do aplicativo, você deve ter uma lista de componentes e suas definições de estado de integridade que se assemelhe a este exemplo.
| Componente | Indicador/métrica | Íntegros | Degradado | Unhealthy |
|---|---|---|---|---|
| Fluxo de usuário Listar itens de catálogo | Estado de integridade subjacente | Front-end e API de Catálogo íntegros | ||
| Fluxo de usuário Adicionar comentário | Estado de integridade subjacente | Front-end, API de Catálogo e processador em segundo plano íntegros | ||
| Aplicativo Web de front-end | Nº de respostas HTTP que não estão em 20 x/min | 0 | 1-10 | > 10 |
| API de catálogo | Nº de exceções/s | < 10 | 10-50 | > 10 |
| Média de tempo de processamento (ms) | < 150 | 150 – 500 | > 500 | |
| Processador em segundo plano | Média de tempo na fila (ms) | < 200 | 200 – 1.000 | > 1.000 |
| Média de tempo de processamento (ms) | < 100 | 100 – 200 | > 200 | |
| Contagem de falhas | < 3 | 3 – 10 | > 10 | |
| Azure Cosmos DB | Utilização de DTU | < 70% | 70% – 90% | > 90% |
| Cofre de Chave do Azure | Contagem de falhas | < 3 | 3 – 10 | > 10 |
| Hubs de eventos do Azure | Comprimento da lista de pendências de processamento (mensagens de saída/entrada) | < 3 | 3 – 20 | > 20 |
| Armazenamento de Blobs do Azure | Latência média (ms) | < 100 | 100 – 200 | > 200 |
Neste exemplo, a tolerância a erros do aplicativo Web de front-end e da API de Catálogo é diferente. Essa diferença está relacionada à compreensão técnica do aplicativo. Todos os erros de front-end devem ser tratados no lado do cliente, portanto, há um limite igual a zero. No entanto, na camada de API, dez exceções têm permissão para considerar erros causados pelo usuário. Por exemplo, erros como 404 – Não Encontrado não indicam necessariamente um problema de integridade.