Fault Tolerance

A aba FAULT TOLERANCE permite definir regras de tolerância a falhas para um serviço específico, bem como gerenciar as regras já criadas. Para acessá-la, selecione o serviço para o qual você deseja criar uma regra na listagem da tela Services (ou depois de clicar sobre um mesh na tela Meshes).

Aba "Fault Tolerance"

A criação de tais regras torna seu sistema de microsserviços mais resiliente, limitando o impacto de falhas, picos de latência, e outros problemas de rede.

Para criar uma nova regra para o serviço selecionado, clique no botão ADD NEW RULE. Você poderá então escolher entre quatro funcionalidades: Circuit Breaker, Request Timeout, Fault Injection e Retry.

Como o Sensedia Service Mesh é uma aplicação Kubernetes-native, também é possível configurar essas regras pela linha de comando usando kubectl. O quadro "Criando uma regra pela linha de comando" na seção de cada funcionalidade traz um exemplo de arquivo .yaml para fazer isso.

Veja como configurar uma regra para cada uma delas a seguir.

Permissões de acesso

As ações que você poderá realizar nesta tela dependem das permissões definidas para seu usuário no Sensedia Access Control.

A tabela a seguir apresenta as permissões possíveis e as respectivas ações:

Permissão	Descrição
List Circuit Breakers	Permite a visualização na lista de regras das informações básicas de uma regra de Circuit Breaker criada para um serviço.
List Fault Injections	Permite a visualização na lista de regras das informações básicas de uma regra de Fault Injection criada para um serviço.
List Timeouts	Permite a visualização na lista de regras das informações básicas de uma regra de Request Timeout criada para um serviço.
List Retries	Permite a visualização na lista de regras das informações básicas de uma regra de Retry criada para um serviço.
Read Circuit Breakers	Permite a visualização da configuração de uma regra de Circuit Breaker criada para um serviço. Não possibilita, contudo, a edição da regra.
Read Fault Injections	Permite a visualização da configuração de uma regra de Fault Injection criada para um serviço. Não possibilita, contudo, a edição da regra.
Read Timeouts	Permite a visualização da configuração de uma regra de Request Timeout criada para um serviço. Não possibilita, contudo, a edição da regra.
Read Retries	Permite a visualização da configuração de uma regra de Retry criada para um serviço. Não possibilita, contudo, a edição da regra.
Write Circuit Breakers	Permite a edição, exclusão e a criação de uma regra de Circuit Breaker para um serviço.
Write Fault Injections	Permite a edição, exclusão e a criação de uma regra de Fault Injection para um serviço.
Write Timeouts	Permite a edição, exclusão e a criação de uma regra de Request Timeout para um serviço.
Write Retries	Permite a edição, exclusão e a criação de uma regra de Retry para um serviço.

Permissão

Descrição

List Circuit Breakers

Permite a visualização na lista de regras das informações básicas de uma regra de Circuit Breaker criada para um serviço.

List Fault Injections

Permite a visualização na lista de regras das informações básicas de uma regra de Fault Injection criada para um serviço.

List Timeouts

Permite a visualização na lista de regras das informações básicas de uma regra de Request Timeout criada para um serviço.

List Retries

Permite a visualização na lista de regras das informações básicas de uma regra de Retry criada para um serviço.

Read Circuit Breakers

Permite a visualização da configuração de uma regra de Circuit Breaker criada para um serviço. Não possibilita, contudo, a edição da regra.

Read Fault Injections

Permite a visualização da configuração de uma regra de Fault Injection criada para um serviço. Não possibilita, contudo, a edição da regra.

Read Timeouts

Permite a visualização da configuração de uma regra de Request Timeout criada para um serviço. Não possibilita, contudo, a edição da regra.

Read Retries

Permite a visualização da configuração de uma regra de Retry criada para um serviço. Não possibilita, contudo, a edição da regra.

Write Circuit Breakers

Permite a edição, exclusão e a criação de uma regra de Circuit Breaker para um serviço.

Write Fault Injections

Permite a edição, exclusão e a criação de uma regra de Fault Injection para um serviço.

Write Timeouts

Permite a edição, exclusão e a criação de uma regra de Request Timeout para um serviço.

Write Retries

Permite a edição, exclusão e a criação de uma regra de Retry para um serviço.

Circuit Breaker

O Circuit Breaker é um mecanismo que possibilita limitar o impacto de falhas e atrasos na rede, rejeitando novas requisições quando certos limites forem atingidos. Uma das vantagens de se ter um circuit breaker configurado é que ao interromper um fluxo de comunicação falho evita-se a propagação em cadeia de falhas. Você pode estabelecer limites de chamadas para hosts individuais em um serviço, tais como o número de conexões simultâneas ou de chamadas falhas feitas a esse host. Também é possível configurar a regra para detectar e remover temporariamente da conexão hosts que apresentem erros.

Criando uma regra de circuit breaking

Na tela Services (ou na tela Meshes, após selecionar o mesh correspondente), selecione o serviço para o qual você deseja criar a regra.

Clique na aba FAULT TOLERANCE e em seguida no botão ADD NEW RULE. Selecione a opção Circuit Breaker.

Será exibida uma tela com duas opções: CONNECTION POOL e OUTLIER DETECTION.

Opções de circuit breaking

Essas opções requerem configurações específicas, a serem exibidas quando a opção correspondente for habilitada.

Connection Pool

A configuração da opção CONNECTION POOL permite rejeitar novas requisições quando o número de conexões simultâneas e o de requisições excederem os valores informados.

É possível configurar a regra para requisições HTTP, TCP ou ambas:

Configurando o Circuit Breaker por Connection Pool

Para o caso de requisições HTTP, os campos a serem preenchidos são:

Max Requests Per Connection: número máximo de requisições por conexão.
Max Pending Requests: número máximo de requisições pendentes (a serem colocadas em fila de espera).

Para as requisições TCP, é necessário informar os seguintes valores:

Max Connections: número máximo de conexões simultâneas.
TCP connection timeout: tempo limite para uma conexão TCP. Deve ser informado em formato de duração (exemplos: 1h, 1m, 1s, 1ms).

Outlier Detection

A funcionalidade de outlier detection monitora o estado de cada host e remove da conexão aquele que apresentar determinada quantidade de erros consecutivos.

Configurando o Circuit Breaker por Outlier Detection

Para configurar a opção OUTLIER DETECTION, é necessário preencher os seguintes campos:

Base Ejection Time: duração mínima de ejeção. O host permanecerá removido por um período de tempo igual ao produto da duração mínima de ejeção pelo número de vezes em que ele já foi removido.
Consecutive Errors: número de erros consecutivos para que um host seja removido da conexão.
Injection Analysis Interval: intervalo de tempo entre cada varredura de análise.
Max Ejection Percent: porcentagem máxima de hosts que podem ser ejetados.

Uma vez preenchidos os campos, clique no botão SAVE para criar a regra.

É possível combinar as funcionalidades de connection pool e outlier detection em uma mesma regra.

Criando uma regra pela linha de comando

Para criar uma regra de circuit breaker via kubectl, aplique um arquivo .yaml como o do exemplo a seguir:

apiVersion: networking.sensedia.com/v1
kind: CircuitBreaker
metadata:
  name: players-cb
spec:
  connectionPool:
    http:
      http1MaxPendingRequests: 1
      maxRequestsPerConnection: 1
    tcp:
      connectTimeout: 10ms
      maxConnections: 1
  enabled: true
  outlierDetection:
    baseEjectionTime: 3m
    consecutive5xxErrors: 1
    interval: 1s
    maxEjectionPercent: 100
  serviceName: players

A configuração da regra nesse arquivo se dá por meio dos seguintes campos:

.kind: especifica o tipo de objeto a ser criado; nesse caso, um objeto do tipo CircuitBreaker;
.metadata.name: define um nome para identificar o recurso;
.spec.enabled: habilita (enabled: true) ou desabilita (enabled: false) a regra;
.spec.serviceName: especifica o serviço para o qual a regra será aplicada;

Os campos de .spec.connectionPool dizem respeito à configuração da opção Connection Pool:

.spec.connectionPool.http.http1MaxPendingRequests: número máximo de requisições a serem colocadas em fila de espera;
.spec.connectionPool.http.maxRequestsPerConnection: número máximo de requisições por conexão;
.spec.connectionPool.tcp.connectTimeout: tempo limite para uma conexão TCP, em formato de duração;
.spec.connectionPool.tcp.maxConnections: número máximo de conexões simultâneas.

Os campos de .spec.outlierDetection se referem à configuração da opção Outlier Detection:

.spec.outlierDetection.baseEjectionTime: duração mínima de ejeção do host;
.spec.outlierDetection.consecutive5xxErrors: número de erros consecutivos aceitos antes que um host seja removido da conexão;
.spec.outlierDetection.interval: intervalo de tempo entre cada varredura de análise;
.spec.outlierDetection.maxEjectionPercent: percentual máximo de hosts que podem ser ejetados.

É possível, em uma regra, configurar apenas uma opção de circuit breaker (Connection Pool ou Outlier Detection) ou ambas as opções.

Gerenciando uma regra criada

Ao criar a regra, você será redirecionado à tela de visualização da aba FAULT TOLERANCE para o serviço correspondente, onde poderá gerenciar a regra criada.

Visualizando uma regra de Circuit Breaker criada

Nessa tela são exibidas as seguintes informações sobre a regra:

valores configurados para connection pool (coluna CONNECTION POOL);
valores configurados para outlier detection (coluna OUTLIER DETECTION);
status da regra, que pode ser "provisionado" (PROVISIONED) ou "desabilitado" (DISABLED) — (coluna STATUS);
data e horário da criação da regra (coluna CREATED AT).

Além de visualizar essas informações, é possível desabilitar ou habilitar a regra por meio do botão localizado na coluna ENABLED.

Por meio dos ícones contidos na coluna ACTIONS você pode:

editar as configurações da regra ();
excluir a regra ().

Só é possível ter uma regra de Circuit Breaker configurada por serviço. Se você já tiver criado uma, a opção "Circuit Breaker" não estará mais disponível na lista do botão ADD NEW RULE daquele serviço.

Exemplo de configuração

No exemplo mostrado na imagem abaixo, estamos configurando um Circuit Breaker para limitar em uma o número de conexões, requisições por conexão e de requisições pendentes e em 10 milissegundos o tempo da conexão TCP. Além disso, configuramos a regra para checar possíveis falhas nos hosts a cada 1 segundo e para remover por no mínimo 3 minutos um host do load balancing pool caso apresente um erro 5xx. Nesse último caso, estamos permitindo que até 100% dos hosts sejam ejetados.

Exemplo de configuração de Circuit Breaker

Request Timeout

A funcionalidade de Request Timeout permite lidar com a latência nas chamadas aos serviços de uma maneira simples. O fato de um serviço levar mais tempo do que o habitual para responder pode impactar todo o sistema, uma vez que esse atraso será propagado ao longo da rede. Ao configurar uma regra de request timeout você especifica o tempo máximo de espera por uma resposta de um determinado serviço. Caso uma chamada a esse serviço demore mais do que o tempo especificado para se completar, ela será interrompida (um erro de "timeout" é retornado). Desse modo, esse atraso não afeta os demais microsserviços e não impacta o tempo de resposta da aplicação como um todo.

Configurar uma regra de request timeout no Sensedia Service Mesh é simples, como mostrado a seguir.

Criando uma regra de Request Timeout

Na tela Services (ou na tela Meshes, após selecionar o mesh correspondente), selecione o serviço para o qual você deseja criar a regra.

Clique na aba FAULT TOLERANCE e em seguida no botão ADD NEW RULE. Selecione a opção Request Timeout.

Na tela seguinte, você deverá preencher um único campo:

Duration: tempo limite para uma requisição se completar. Deve ser informado no formato de duração (exemplos: 1m, 1s, 1ms).

Criando uma regra de Request Timeout

Após preencher o campo, clique no botão SAVE para criar a regra.

Criando uma regra pela linha de comando

Para configurar uma regra de request timeout pela linha de comando, basta aplicar via kubectl um arquivo .yaml como o do exemplo a seguir:

  apiVersion: networking.sensedia.com/v1
  kind: Timeout
  metadata:
    name: timeout-matches
  spec:
    serviceName: matches
    duration: 1s

Nesse arquivo, o objeto de tipo Timeout é especificado no campo .kind e o tempo limite para as requisições (o timeout), no campo .spec.duration (trata-se do mesmo parâmetro informado no campo Duration da interface do Sensedia Service Mesh).

No campo .spec.serviceName deverá ser especificado o serviço para o qual a regra será criada.

No campo .metadata.name você deve informar um nome para identificar o recurso.

O exemplo no arquivo acima define um timeout de um segundo para o serviço matches.

Gerenciando uma regra criada

Ao criar uma regra pela interface do Sensedia Service Mesh ou pela linha de comando, você poderá visualizá-la na aba FAULT TOLERANCE do serviço correspondente.

Visualizando uma regra de Request Timeout criada

Aqui são apresentadas as seguintes informações sobre a regra:

valor especificado para o parâmetro Duration (coluna DURATION);
status da regra, que pode ser "provisionado" (PROVISIONED) ou "desabilitado" (DISABLED) — (coluna STATUS);
data e horário da criação da regra (coluna CREATED AT).

Além disso, é possível desabilitar ou habilitar a regra por meio do botão localizado na coluna ENABLED.

Por meio dos ícones contidos na coluna ACTIONS você pode:

atualizar a configuração da regra ();
excluir a regra ().

Você só pode ter uma regra de Request Timeout por serviço. Se já tiver criado uma, a opção "Request Timeout" não estará mais disponível na lista do botão ADD NEW RULE daquele serviço.

Fault Injection

A funcionalidade Fault Injection possibilita configurar a injeção de falhas na rede. Com isso, você pode testar a resiliência do seu sistema de microsserviços e observar o impacto de possíveis falhas na aplicação como um todo. Ela é útil, por exemplo, para verificar se suas políticas de recuperação de falhas estão adequadas ao seu sistema, evitando, assim, que serviços críticos fiquem indisponíveis.

Criando uma regra de Fault Injection

Na tela Services (ou na tela Meshes, após selecionar o mesh correspondente), selecione o serviço para o qual você deseja criar a regra.

Clique na aba FAULT TOLERANCE e em seguida no botão ADD NEW RULE. Selecione a opção Fault Injection.

Será então exibida uma tela com duas opções de falhas: HTTP ABORT e HTTP DELAY. Os campos a serem preenchidos dependem do tipo de falha a ser configurada.

Opções de Fault Injection

HTTP Abort

Por meio da configuração da opção HTTP ABORT você pode observar como sua aplicação irá se comportar quando falhas de HTTP surgirem no sistema. É possível especificar o código de status HTTP a ser retornado, bem como o percentual de requisições que serão afetadas pela falha.

Configurando a injeção de HTTP Abort

A configuração da injeção de HTTP Abort requer o preenchimento dos seguintes campos:

HTTP Status Code: código de status HTTP a ser retornado para requisições ao serviço correspondente. Exemplo: 503.
Requests percent: percentual de requisições a serem abortadas com o código de erro especificado no campo HTTP Status Code. O valor informado deve ser um número inteiro maior que zero.

HTTP Delay

A configuração da opção HTTP DELAY permite adicionar um atraso na resposta de um serviço específico. Com isso, é possível simular o aumento da latência da rede ou a situação em que um serviço esteja sobrecarregado.

Configurando a injeção de HTTP Delay

Os seguintes campos são necessários para configurar a injeção de HTTP Delay:

Fixed Delay: atraso a ser acrescentado ao tempo de resposta do serviço. O valor deve ser informado no formato de duração. Exemplos: 1h, 1m, 1s, 1ms.
Requests percent: percentual de requisições nas quais o atraso será injetado. O valor informado deve ser um número inteiro maior que zero.

Uma vez preenchidos os campos necessários para o tipo de falha desejado, clique no botão SAVE para criar a regra.

É possível combinar os dois tipos de falhas (HTTP Abort e HTTP Delay) em uma mesma regra.

Criando uma regra pela linha de comando

Também é possível criar uma regra de fault injection por kubectl, aplicando um arquivo .yaml como o do exemplo a seguir:

  apiVersion: networking.sensedia.com/v1
  kind: FaultInjection
  metadata:
    name: fault-injection
  spec:
    serviceName: matches
    enabled: true
    abort:
      httpStatusCode: 500
      percentage:
        value: 10
    delay:
      fixedDelay: 2s
      percentage:
        value: 10

A configuração da regra nesse arquivo é feita por meio dos seguintes campos:

.kind: especifica o tipo de objeto a ser criado; nesse caso, FaultInjection;
.metadata.name: define um nome para identificar o recurso;
.spec.serviceName: usado para especificar o serviço para o qual a regra será criada;
.spec.enabled: permite habilitar (enabled: true) ou desabilitar (enabled: false) a regra;
.spec.abort.httpStatusCode: campo para especificar o código de status HTTP a ser retornado quando da configuração de injeção de HTTP Abort;
.spec.abort.percentage.value: especifica o percentual de requisições a serem abortadas quando da configuração de injeção de HTTP Abort;
.spec.delay.fixedDelay: define o atraso a ser acrescentado ao tempo de resposta do serviço quando da configuração de injeção de HTTP Delay;
.spec.delay.percentage.value: percentual de requisições nas quais o atraso será injetado quando da configuração de injeção de HTTP Delay.

O arquivo .yaml do exemplo acima configura uma regra de fault injection que adiciona um atraso de dois segundos a 10% das chamadas feitas ao serviço matches e define que 10% das requisições a esse serviço serão abortadas com código de status HTTP 500.

É possível, em uma regra, definir um único tipo de falha (HTTP Abort ou HTTP Delay) ou combinar os dois tipos (HTTP Abort e HTTP Delay).

Gerenciando uma regra criada

A regra de fault injection criada ficará visível na tela de visualização da aba FAULT TOLERANCE para o serviço correspondente.

Visualizando a regra de Fault Injection criada

Aqui é possível visualizar as seguintes informações sobre a regra:

valores configurados para HTTP Delay (coluna DELAY). Se essa opção não tiver sido definida na regra, a mensagem "Not defined" é exibida;
valores configurados para HTTP Abort (coluna ABORT). Se essa opção não tiver sido definida na regra, a mensagem "Not defined" é exibida;
status da regra, que pode ser "provisionado" (PROVISIONED) ou "desabilitado" (DISABLED) — (coluna STATUS);
data e horário da criação da regra (coluna CREATED AT).

O botão localizado na coluna ENABLED permite desabilitar ou habilitar a regra.

Por meio dos ícones contidos na coluna ACTIONS você pode:

editar as configurações da regra ();
excluir a regra ().

Só é possível ter uma regra de Fault Injection configurada por serviço. Se já houver uma, a opção "Fault Injection" não estará mais disponível na lista do botão ADD NEW RULE daquele serviço.

Retry

A funcionalidade Retry permite que você determine o número máximo de retentativas de conexão a um serviço no caso de uma chamada falhar. O propósito dessa funcionalidade é evitar que chamadas a um serviço falhem permanentemente devido a problemas temporários na rede ou no serviço. O ajuste adequado dos parâmetros de Retry é importante para garantir a disponibilidade dos microsserviços e para evitar que retentativas mal configuradas causem lentidão na resposta da aplicação.

Veja a seguir como configurar uma regra de Retry para um serviço específico no Sensedia Service Mesh.

Criando uma regra de Retry

Na tela Services da interface do Sensedia Service Mesh (ou na tela Meshes, após selecionar o mesh correspondente), selecione o serviço para o qual você deseja criar a regra.

Clique na aba FAULT TOLERANCE e em seguida no botão ADD NEW RULE. Selecione a opção Retry.

Uma janela modal com dois campos para a configuração da regra será então aberta:

Criando uma regra de Retry pela interface do Sensedia Service Mesh

Os campos disponíveis para preenchimento nessa tela são os seguintes:

Retry quantity: número máximo de retentativas de conexão ao serviço correspondente se a chamada inicial falhar. Campo de preenchimento obrigatório.
Per try timeout: tempo limite de espera por sucesso de conexão em cada retentativa. Campo de preenchimento opcional. Deve ser informado como uma duração (exemplos: 1m, 1s, 1ms).

Após informar os valores desejados, clique no botão SAVE para criar a regra.

Criando uma regra pela linha de comando

Para criar uma regra de Retry via kubectl, aplique um arquivo .yaml como o do exemplo a seguir:

apiVersion: networking.sensedia.com/v1
kind: Retry
metadata:
  name: my-service-retry
  namespace: test
spec:
  enabled: true
  perTryTimeout: 1s
  quantity: 2
  serviceName: my-service

A configuração da regra nesse arquivo é feita por meio dos seguintes campos:

.kind: tipo de objeto a ser criado;
.metadata.name: nome para identificar o recurso;
.metadata.namespace: namespace no qual o recurso será criado;
.spec.enabled: habilita (enabled: true) ou desabilita (enabled: false) a regra;
.spec.perTryTimeout: tempo limite de espera por sucesso de conexão, incluindo a chamada inicial e retentativas. Deve ser informado como uma duração (exemplos: 1m, 1s, 1ms);
.spec.quantity: número máximo de retentativas de conexão ao serviço correspondente se a chamada inicial falhar;
.spec.serviceName: serviço para o qual a regra será aplicada.

O exemplo no arquivo acima define um número máximo de duas retentativas de conexão ao serviço my-service se a chamada inicial falhar, cada uma delas com um tempo limite de espera de 1 segundo.

Gerenciando uma regra criada

Uma regra de Retry criada ficará visível na tela de visualização da aba FAULT TOLERANCE para o serviço correspondente:

Visualizando uma regra de Retry criada

Nessa tela são apresentadas as seguintes informações sobre a regra:

valor especificado para o parâmetro "Retry quantity" (coluna QUANTITY);
valor especificado para o parâmetro "Per try timeout" (coluna TIMEOUT);
status da regra, que pode ser "provisionado" (PROVISIONED) ou "desabilitado" (DISABLED) — (coluna STATUS);
data e horário da criação da regra (coluna CREATED AT).

Além de visualizar essas informações, é possível desabilitar ou habilitar a regra por meio do botão localizado na coluna ENABLED.

A coluna ACTIONS contém ícones que lhe permitem:

editar a configuração da regra ();
excluir a regra ().

Você só pode ter uma regra de Retry por serviço. Se já tiver criado uma, a opção "Retry" não estará mais disponível na lista do botão ADD NEW RULE daquele serviço.

Thanks for your feedback!

EDIT

How useful was this article to you?