Load Shedding,
Backpressure, CDC,
Hypervisor Docker
Gabriel Passos
Request
Load Shedding
● Negar requests para evitar que o serviço caia
○ Cenários:
■ Se uma instância cair as outras instâncias vão sofrer com uma sobre carga, potencialmente
derrubando essas outras instâncias.
■ Se um microsserviço demora para dar uma resposta, quem fez a request está esperando e assim por
diante gerando uma latência e problema geral.
● Como fazer?
○ Configurar no serviço?
■ Instância A conhece da saúde da Instância B?
■ Requisição chegando na instância sobrecarregada mesmo que negada vai consumir recurso.
○ Configurar no load balance?
■ Pulling nas instâncias (/health)?
■ Por que não subir outra instância?
○ Produtor?
■ Quem vistoria o produtor?
Load Shedding
Backpressure
● Quando o processo de baseado em um input/request em um output sofre algum tipo de resistência,
interferência, demora.
● Soluções:
○ Controlar o produtor
○ “Estocar” as requisições e processa-las posteriormente
○ Deletar/Ignorar requisições
Backpressure
Control Producers
Buffering
Change data capture
● Baseado em um estado de uma entidade persistida, propagar eventos em caso de mudanças
● Baseado em uma data
○ Se data persistida é mais recente que a último evento, considera-se que aconteceu uma mudança
● Versionamento
○ Quando uma tupla é atualizada, sua versão também é atualizada
○ Poderia fazer o update com versão no where, caso falhe, já existe uma versão mais atualizada
● Status
○ Campo (bool) informando se registro foi atualizado
● Combinações das técnicas anteriores
● Log Scanner
○ Monitorar os logs da database e a partir destes publicar um evento
○ Serviço específico
Hypervisor
● Software, Hardware, Firmware que executa máquinas virtuais.
● Host, Guest
● Gerencia a alocação de recursos do host para n guests.
Hypervisor
Docker
● Namespaces:
○ Aspectos do container estão em namespaces diferentes
■ PID (Process ID) - Processo pai vem os “filhos”, e não vê seus irmãos
■ NET - Isola as os controladores de interface (físicos e virtuais), tabelas de ip e roteamento, firewall,
etc.
■ IPC - Processo de inter comunicação entre namespaces
■ MNT - Sistema de arquivos
■ UTS - Permite mudar o hostname
● Permissions:
○ Acesso de root internamente do container e é feito um map para o exterior:
■ /etc/subuid
■ /etc/subgid
Docker
● Control Groups
○ Compartilhamento do hardware com o container
○ Limitar o uso da memória por parte do container
○ Grupos de controle:
■ CPU
■ Memória
■ Banda de rede
■ Disco
■ Prioridade
○ Capacidade de alocação de recursos para o container
Docker
● Network
● Comunicação entre containers ou container e outro sistema
● Independente do SO
● Bridge:
○ Padrão
○ User Defined
● Host:
○ Usa a network do host
● Overlay:
○ Conecta diferentes containers para se comunicarem,
● Macvlan:
Outros players
● LXC Linux Containers
○ “containers which offer an environment as close as possible as the one you'd get from a VM”
● Mesos Containerizer

Load shedding, backpressure, cdc, hypervisor, docker

  • 1.
  • 2.
  • 3.
    Load Shedding ● Negarrequests para evitar que o serviço caia ○ Cenários: ■ Se uma instância cair as outras instâncias vão sofrer com uma sobre carga, potencialmente derrubando essas outras instâncias. ■ Se um microsserviço demora para dar uma resposta, quem fez a request está esperando e assim por diante gerando uma latência e problema geral. ● Como fazer? ○ Configurar no serviço? ■ Instância A conhece da saúde da Instância B? ■ Requisição chegando na instância sobrecarregada mesmo que negada vai consumir recurso. ○ Configurar no load balance? ■ Pulling nas instâncias (/health)? ■ Por que não subir outra instância? ○ Produtor? ■ Quem vistoria o produtor?
  • 4.
  • 5.
    Backpressure ● Quando oprocesso de baseado em um input/request em um output sofre algum tipo de resistência, interferência, demora. ● Soluções: ○ Controlar o produtor ○ “Estocar” as requisições e processa-las posteriormente ○ Deletar/Ignorar requisições
  • 6.
  • 7.
  • 8.
  • 9.
    Change data capture ●Baseado em um estado de uma entidade persistida, propagar eventos em caso de mudanças ● Baseado em uma data ○ Se data persistida é mais recente que a último evento, considera-se que aconteceu uma mudança ● Versionamento ○ Quando uma tupla é atualizada, sua versão também é atualizada ○ Poderia fazer o update com versão no where, caso falhe, já existe uma versão mais atualizada ● Status ○ Campo (bool) informando se registro foi atualizado ● Combinações das técnicas anteriores ● Log Scanner ○ Monitorar os logs da database e a partir destes publicar um evento ○ Serviço específico
  • 10.
    Hypervisor ● Software, Hardware,Firmware que executa máquinas virtuais. ● Host, Guest ● Gerencia a alocação de recursos do host para n guests.
  • 11.
  • 12.
    Docker ● Namespaces: ○ Aspectosdo container estão em namespaces diferentes ■ PID (Process ID) - Processo pai vem os “filhos”, e não vê seus irmãos ■ NET - Isola as os controladores de interface (físicos e virtuais), tabelas de ip e roteamento, firewall, etc. ■ IPC - Processo de inter comunicação entre namespaces ■ MNT - Sistema de arquivos ■ UTS - Permite mudar o hostname ● Permissions: ○ Acesso de root internamente do container e é feito um map para o exterior: ■ /etc/subuid ■ /etc/subgid
  • 13.
    Docker ● Control Groups ○Compartilhamento do hardware com o container ○ Limitar o uso da memória por parte do container ○ Grupos de controle: ■ CPU ■ Memória ■ Banda de rede ■ Disco ■ Prioridade ○ Capacidade de alocação de recursos para o container
  • 14.
    Docker ● Network ● Comunicaçãoentre containers ou container e outro sistema ● Independente do SO ● Bridge: ○ Padrão ○ User Defined ● Host: ○ Usa a network do host ● Overlay: ○ Conecta diferentes containers para se comunicarem, ● Macvlan:
  • 15.
    Outros players ● LXCLinux Containers ○ “containers which offer an environment as close as possible as the one you'd get from a VM” ● Mesos Containerizer