finagle.org

Sobre Finagle

Comunicacao entre 2 pontos:

HTTP

Thrift

MySQL

Memcached

…

Kafka

Colaboracao de N partes 1 servico acessa N outros servicos para responder uma requisicao;

E se uma dessas partes falha ?

Retry

Timeout

Circuit Breaker

Robustez

HTTP-Kit: Connection Timeout

1-2x por minuto no CCA

60-70x por hora no CCA

Picos antes de causar Circuit Breaker

DNS Caching

ELB ciclam, route 53 muda o DNS

DNS do Java nao respeita muito bem cache

Zerar o TTL do cache do Java nao resolveu (problema descartado)

Falha na Rede da Amazon ?

Storm de sockets entre duas maquinas nao mostrou nenhum problema;

Apontar direto de um servico pro outro mostrou os mesmos problemas (descartando ELB)

Acontecia antes da NAT ser Gigabit e continuou acontecendo depois (descartando throttle na NAT)

Removendo uma maquina do ELB diminuiu o problema consideravelmente (3 ocorrencias em 6 horas)

Consumers fazem no maximo N requisicoes ao mesmo tempo (N e o numero de consumers) (nao ha conexoes paralelas)

ELB nao ha um limite (enquanto receber requests, ira fazer requests) (confirmar)

Servicoes com menos carga de HTTP in quase nao tem esse problema;

Tyrion;

Gerenciamento do pool de conexoes HTTP-Kit parece ser o vilao;

Problema dificil de reproduzir;

Finagle!

Twitter usa uma arquitetura de microservicoes ha um bom tempo;

70k req/s (6,000,000,000 por dia)

comofas/

Finagle

Construir aplicacoes/bibliotecas robustas nao e trivial

https://blog.twitter.com/2011/finagle-a-protocol-agnostic-rpc-system

Sucesso e Falha

200 (Success)

503 ()

504 (Gateway Timeout)

400 (Invalid Input)

401 (Unauthorized)

500 (Server Error)

https://twitter.com/finagle/status/697184041267662849?ref_src=twsrc%5Etfw

Futures, Filtros

Req => Fut(Res)

Faz a requisicao e ele te retorna um filtro;

Futures podem estar

Pending

Succeeded

Failed

Implementacao atual da um await logo depois;

Filtros

Client Based:

Se um servico depende do servico A e B e so o servico B esta fora, requests que dependem so de A continuam funcionando;

“Interceptors”

Estrategias

Failure Accrual

Porcentagem P, e janela de tempo W

Se Porcentagem(sucesso) < P dentro de uma janela W de tempo

Marca como morto por N segundos

Depois de N segundos volta a vida

Se ainda nao voltou, marca como morto por M segundos

Relacao entre M e N pode ser constante, exponencial, exponencial jittered, constante jittered, etc;

https://www.awsarchitectureblog.com/2015/03/backoff.html

Retries

Nao foi um sucesso tenta denovo;

Budget de retries, muitos retries quebrando vao zerar esse budget e vai parar de retentar (se o outro servico estiver zoado, retentar pode derrubar

Baseado em idempotencia

Pode forcar retentativas

Usa um budget (muitas retentativas podem derrubar o outro lado);

Alguns status code sao sempre tentados (503 por exemplo)

Definido via uma funcao: https://github.com/nubank/common-finagle/blob/master/src/common_finagle/filters/response_classifier.clj

Timeout

Configuracao Global;

Sobrescrito a nivel de request

Load balancing*

Usa um discovery pra descobrir o no que vai receber o request;

Um no esta dando muitos erros => nao faz mais requests pra ele;

Resolveria um problema relativamente raro: peers cacheando dados incorretos no datomic devido a um erro na leitura

Simple Finagle client*

Para usar no e2e;

Sem failure accrual;

Backoff constante;