As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Medindo a disponibilidade
Como vimos anteriormente, é difícil criar um modelo de disponibilidade voltado para o futuro para um sistema distribuído e pode não fornecer os insights desejados. O que pode oferecer mais utilidade é desenvolver formas consistentes de medir a disponibilidade de sua carga de trabalho.
A definição de disponibilidade como tempo de atividade e tempo de inatividade representa falha como uma opção binária, ou a carga de trabalho está ativa ou não.
No entanto, isso raramente é o caso. A falha tem um grau de impacto e geralmente ocorre em algum subconjunto da carga de trabalho, afetando uma porcentagem de usuários ou solicitações, uma porcentagem de locais ou um percentil de latência. Todos esses são modos de falha parcial.
E embora o MTTR e o MTBF sejam úteis para entender o que impulsiona a disponibilidade resultante de um sistema e, portanto, como melhorá-lo, sua utilidade não é uma medida empírica de disponibilidade. Além disso, as cargas de trabalho são compostas por vários componentes. Por exemplo, uma carga de trabalho, como um sistema de processamento de pagamentos, é composta por várias interfaces de programação de aplicativos (APIs) e subsistemas. Então, quando queremos fazer uma pergunta como “qual é a disponibilidade de toda a carga de trabalho?” , na verdade, é uma pergunta complexa e cheia de nuances.
Nesta seção, examinaremos três maneiras pelas quais a disponibilidade pode ser medida empiricamente: taxa de sucesso de solicitações do lado do servidor, taxa de sucesso de solicitações do lado do cliente e tempo de inatividade anual.
Taxa de sucesso de solicitações do lado do servidor e do cliente
Os dois primeiros métodos são muito semelhantes, diferindo apenas do ponto de vista em que a medição é feita. As métricas do lado do servidor podem ser coletadas da instrumentação no serviço. No entanto, eles não estão completos. Se os clientes não conseguirem acessar o serviço, você não poderá coletar essas métricas. Para entender a experiência do cliente, em vez de confiar na telemetria dos clientes sobre solicitações fracassadas, uma maneira mais fácil de coletar métricas do lado do cliente é simular o tráfego de clientes com canários, um software que sonda regularmente seus serviços e registra métricas.
Esses dois métodos calculam a disponibilidade como a fração do total de unidades de trabalho válidas que o serviço recebe e as que ele processa com sucesso (isso ignora unidades de trabalho inválidas, como uma solicitação HTTP que resulta em um erro 404).
Equação 8
Para um serviço baseado em solicitações, a unidade de trabalho é a solicitação, como uma solicitação HTTP. Para serviços baseados em eventos ou tarefas, as unidades de trabalho são eventos ou tarefas, como processar uma mensagem fora de uma fila. Essa medida de disponibilidade é significativa em intervalos de tempo curtos, como janelas de um ou cinco minutos. Também é mais adequado em uma perspectiva granular, como em um nível por API para um serviço baseado em solicitações. A figura a seguir fornece uma visão de como seria a disponibilidade ao longo do tempo quando calculada dessa forma. Cada ponto de dados no gráfico é calculado usando a Equação (8) em uma janela de cinco minutos (você pode escolher outras dimensões de tempo, como intervalos de um ou dez minutos). Por exemplo, o ponto de dados 10 mostra 94,5% de disponibilidade. Isso significa que, durante os minutos t+45 a t+50, se o serviço recebeu 1.000 solicitações, somente 945 delas foram processadas com sucesso.
Exemplo de medição da disponibilidade ao longo do tempo para uma única API
O gráfico também mostra a meta de disponibilidade da API, 99,5% de disponibilidade, o contrato de nível de serviço (SLA) que ela oferece aos clientes, 99% de disponibilidade e o limite para um alarme de alta severidade, 95%. Sem o contexto desses diferentes limites, um gráfico de disponibilidade pode não fornecer uma visão significativa de como seu serviço está operando.
Também queremos poder rastrear e descrever a disponibilidade de um subsistema maior, como um plano de controle ou um serviço inteiro. Uma forma de fazer isso é calcular a média de cada ponto de dados de cinco minutos para cada subsistema. O gráfico será semelhante ao anterior, mas representará um conjunto maior de entradas. Ele também dá o mesmo peso a todos os subsistemas que compõem seu serviço. Uma abordagem alternativa pode ser somar todas as solicitações recebidas e processadas com êxito de todas as APIs no serviço para calcular a disponibilidade em intervalos de cinco minutos.
No entanto, esse último método pode ocultar uma API individual com baixa taxa de transferência e baixa disponibilidade. Como um exemplo simples, considere um serviço com duas APIs.
A primeira API recebe 1.000.000 de solicitações em uma janela de cinco minutos e processa com sucesso 999.000 delas, oferecendo uma disponibilidade de 99,9%. A segunda API recebe 100 solicitações na mesma janela de cinco minutos e processa apenas 50 delas com êxito, oferecendo uma disponibilidade de 50%.
Se somarmos as solicitações de cada API, haverá um total de 1.000.100 solicitações válidas e 999.050 delas serão processadas com sucesso, fornecendo uma disponibilidade geral de 99,895% para o serviço. Mas, se calcularmos a média das disponibilidades das duas APIs, o método anterior, obteremos uma disponibilidade resultante de 74,95%, o que pode ser mais revelador da experiência real.
Nenhuma abordagem está errada, mas mostra a importância de entender o que as métricas de disponibilidade estão dizendo a você. Você pode optar por somar as solicitações para todos os subsistemas se sua carga de trabalho receber um volume de solicitações semelhante em cada um. Essa abordagem se concentra na “solicitação” e em seu sucesso como medida da disponibilidade e da experiência do cliente. Como alternativa, você pode optar por calcular a média da disponibilidade do subsistema para representar igualmente sua criticidade, apesar das diferenças no volume de solicitações. Essa abordagem se concentra no subsistema e na capacidade de cada um como substituto da experiência do cliente.
Tempo de inatividade anual
A terceira abordagem é calcular o tempo de inatividade anual. Essa forma de métrica de disponibilidade é mais apropriada para definição e revisão de metas de longo prazo. É necessário definir o que significa tempo de inatividade para sua carga de trabalho. Em seguida, você pode medir a disponibilidade com base no número de minutos em que a carga de trabalho não esteve em uma condição de “interrupção” em relação ao número total de minutos no período determinado.
Algumas cargas de trabalho podem definir o tempo de inatividade como algo como uma queda abaixo de 95% da disponibilidade de uma única API ou função de carga de trabalho por um intervalo de um ou cinco minutos (o que ocorreu no gráfico de disponibilidade anterior). Você também pode considerar o tempo de inatividade apenas quando ele se aplica a um subconjunto de operações críticas do plano de dados. Por exemplo, o Acordo de Nível de Serviço do Amazon Messaging (SQS, SNS)
Cargas de trabalho maiores e mais complexas podem precisar definir métricas de disponibilidade em todo o sistema. Para um grande site de comércio eletrônico, uma métrica de todo o sistema pode ser algo como a taxa de pedidos do cliente. Aqui, uma queda de 10% ou mais nos pedidos em comparação com a quantidade prevista durante qualquer janela de cinco minutos pode definir o tempo de inatividade.
Em qualquer uma das abordagens, você pode somar todos os períodos de interrupção para calcular uma disponibilidade anual. Por exemplo, se durante um ano civil houve 27 períodos de inatividade de cinco minutos, definidos como a disponibilidade de qualquer API de plano de dados caindo abaixo de 95%, o tempo de inatividade geral foi de 135 minutos (alguns períodos de cinco minutos podem ter sido consecutivos, outros isolados), representando uma disponibilidade anual de 99,97%.
Esse método adicional de medir a disponibilidade pode fornecer dados e insights ausentes nas métricas do lado do cliente e do servidor. Por exemplo, considere uma carga de trabalho prejudicada e com taxas de erro significativamente elevadas. Os clientes dessa carga de trabalho podem parar de fazer chamadas para seus serviços por completo. Talvez eles tenham ativado um disjuntor ou seguido seu plano de recuperação de desastres
Latência
Por fim, também é importante medir a latência das unidades de processamento de trabalho em sua carga de trabalho. Parte da definição de disponibilidade é fazer o trabalho dentro de um SLA estabelecido. Se a devolução de uma resposta demorar mais do que o tempo limite do cliente, a percepção do cliente é de que a solicitação falhou e a carga de trabalho não está disponível. No entanto, no lado do servidor, a solicitação pode parecer ter sido processada com sucesso.
A medição da latência fornece outra lente com a qual avaliar a disponibilidade. Usar percentis e médias reduzidas são boas estatísticas para essa medição. Eles são comumente medidos no percentil 50 (P50 e TM50) e no 99º percentil (P99 e TM99). A latência deve ser medida com canários para representar a experiência do cliente, bem como com métricas do lado do servidor. Sempre que a média de algum percentual de latência, como P99 ou TM99.9, ultrapassar o SLA desejado, você pode considerar esse tempo de inatividade, que contribui para o cálculo anual do tempo de inatividade.
