DEV Community: Mario Beani

Threads: Como definir e limitar a execução visando a performance?

Mario Beani — Tue, 12 Nov 2024 20:54:33 +0000

Threads, uma ferramenta que ajuda e que se torna indispensável nos desenvolvimentos de soluções modernas e com alto desempenho. Independente da linguagem, o recurso de fazer tarefas em paralelo é algo que tem um grande apelo. Mas obviamente tem a famosa frase do tio Ben: "Com grandes poderes vêm grandes responsabilidades". Como essa solução pode ser usada da melhor maneira, visando performance, melhor uso de recursos e saúde da aplicação? Primeiro é necessário entender os conceitos básicos desse tema.

O que é uma "thread"?

Threads são unidades básicas de execução de um processo em um sistema operacional. Eles permitem que um programa execute múltiplas operações simultaneamente dentro do mesmo processo. Cada thread compartilha o mesmo espaço de memória do processo principal, mas pode executar de forma independente, o que é útil para tarefas que podem ser realizadas em paralelo, como operações de entrada/saída(I/O), cálculos complexos, ou atualizações de interface de usuário.

Em muitos sistemas, threads são gerenciados pelo sistema operacional, que aloca tempo de CPU para cada thread e gerencia a troca de contexto entre eles. Em linguagens de programação como Java, Python, e C++, existem bibliotecas e frameworks que facilitam a criação e o gerenciamento de threads.

Por que usar threads?

Threads são usadas principalmente para melhorar a eficiência e a capacidade de resposta de um programa. Os motivos para usar threads, principalmente focando em backend são:

Paralelismo: Threads permitem que você execute múltiplas operações simultaneamente, aproveitando melhor os recursos de CPU disponíveis, especialmente em sistemas com múltiplos núcleos.
Desempenho: Em operações de I/O, como leitura e escrita de arquivos ou comunicação de rede, threads podem ajudar a melhorar o desempenho ao permitir que o programa continue executando outras tarefas enquanto aguarda a conclusão dessas operações.
Modularidade: Threads podem ser usadas para dividir um programa em partes menores e mais gerenciáveis, cada uma executando uma tarefa específica.

No entanto, é importante gerenciar threads com cuidado, pois o uso incorreto pode levar a problemas como condições de corrida, deadlocks e dificuldades de depuração. Para um melhor gerenciamento das mesmas é usada uma solução de pool de threads.

O que é um pool de threads e por que preciso dele?

Um pool de threads é um padrão de design de software que envolve a criação e gerenciamento de um conjunto de threads que podem ser reutilizados para executar tarefas. Em vez de criar e destruir threads repetidamente para cada tarefa, um pool de threads mantém um número fixo de threads prontos para executar tarefas conforme necessário. Isso pode melhorar significativamente o desempenho de aplicações que precisam lidar com muitas tarefas simultâneas. Os pontos positivos em usar um pool de threads são:

Desempenho Melhorado: Criar e destruir threads é uma operação custosa em termos de recursos. Um pool de threads minimiza esse custo, reutilizando threads existentes.
Gerenciamento de Recursos: Controla o número de threads em execução, evitando a criação excessiva de threads que podem sobrecarregar o sistema.
Facilidade de Uso: Simplifica o gerenciamento de threads, permitindo que os desenvolvedores foquem na lógica da aplicação em vez de no gerenciamento de threads.
Escalabilidade: Ajuda a escalar aplicações para lidar com um grande número de tarefas simultâneas de forma eficiente.

Como definir o limite de threads no pool

Ok, é claro que tenho que criar um pool de threads para melhor utilizar esse recurso, mas uma pergunta que vem rapidamente é: "Quantas threads devem conter no pool?". Seguindo uma lógica básica, quanto mais melhor, certo? Se tudo pode ser feito em paralelo, logo, será feito, pois vai ser mais rápido. Sendo assim é melhor não limitar o número de threads, ou então colocar um número alto, para que que isso não seja uma preocupação. Correto?
É uma afirmação justa, então vamos testar. O código para esse teste foi feito em Kotlin apenas por familiaridade e facilidade de escrever os exemplos. Esse ponto é agnóstico a linguagens.
Foram feitos 4 exemplos explorando diferentes naturezas de sistema. O exemplo 1 e 2 foram feitos para utilizar o CPU, fazer muitas contas, ou seja, ter processamento massivo. O exemplo 3 é focado em I/O, sendo o exemplo uma leitura de um arquivo e por fim, no exemplo 4 é uma situação de chamadas de APIs em paralelo, também focando em I/O. Todos usaram pools com diferentes tamanhos, sendo eles respectivamente com 1, 2, 4, 8, 16, 32, 50, 100 e 500 threads. Todos processos ocorrem mais do que 500 vezes.

Exemplo 1 - Código que calcula quantos números primos existem entre 1 e 100000

import kotlinx.coroutines.*
import kotlin.math.sqrt
import kotlin.system.measureTimeMillis

fun isPrime(number: Int): Boolean {
    if (number <= 1) return false
    for (i in 2..sqrt(number.toDouble()).toInt()) {
        if (number % i == 0) return false
    }
    return true
}

fun countPrimesInRange(start: Int, end: Int): Int {
    var count = 0
    for (i in start..end) {
        if (isPrime(i)) {
            count++
        }
    }
    return count
}

@OptIn(DelicateCoroutinesApi::class)
fun main() = runBlocking {
    val rangeStart = 1
    val rangeEnd = 100_000
    val numberOfThreadsList = listOf(1, 2, 4, 8, 16, 32, 50, 100, 500)

    for (numberOfThreads in numberOfThreadsList) {
        val customDispatcher = newFixedThreadPoolContext(numberOfThreads, "customPool")
        val chunkSize = (rangeEnd - rangeStart + 1) / numberOfThreads
        val timeTaken = measureTimeMillis {
            val jobs = mutableListOf<Deferred<Int>>()
            for (i in 0 until numberOfThreads) {
                val start = rangeStart + i * chunkSize
                val end = if (i == numberOfThreads - 1) rangeEnd else start + chunkSize - 1
                jobs.add(async(customDispatcher) { countPrimesInRange(start, end) })
            }
            val totalPrimes = jobs.awaitAll().sum()
            println("Total de números primos encontrados com $numberOfThreads threads: $totalPrimes")
        }
        println("Tempo levado com $numberOfThreads threads: $timeTaken ms")
        customDispatcher.close()
    }
}

Saída do console do exemplo 1

Total de números primos encontrados com 1 threads: 9592
Tempo levado com 1 threads: 42 ms
Total de números primos encontrados com 2 threads: 9592
Tempo levado com 2 threads: 17 ms
Total de números primos encontrados com 4 threads: 9592
Tempo levado com 4 threads: 8 ms
Total de números primos encontrados com 8 threads: 9592
Tempo levado com 8 threads: 8 ms
Total de números primos encontrados com 16 threads: 9592
Tempo levado com 16 threads: 16 ms
Total de números primos encontrados com 32 threads: 9592
Tempo levado com 32 threads: 12 ms
Total de números primos encontrados com 50 threads: 9592
Tempo levado com 50 threads: 19 ms
Total de números primos encontrados com 100 threads: 9592
Tempo levado com 100 threads: 36 ms
Total de números primos encontrados com 500 threads: 9592
Tempo levado com 500 threads: 148 ms

Exemplo 2 - Código que calcula o 30º número na escala fibonacci

import kotlinx.coroutines.DelicateCoroutinesApi
import kotlinx.coroutines.launch
import kotlinx.coroutines.newFixedThreadPoolContext
import kotlinx.coroutines.runBlocking
import kotlin.system.measureTimeMillis

fun fibonacci(n: Int): Long {
    return if (n <= 1) n.toLong() else fibonacci(n - 1) + fibonacci(n - 2)
}

@OptIn(DelicateCoroutinesApi::class)
fun main() = runBlocking {
    val numberOfThreadsList = listOf(1, 2, 4, 8, 16, 32, 50, 100, 500)

    for (numberOfThreads in numberOfThreadsList) {
        val customDispatcher = newFixedThreadPoolContext(numberOfThreads, "customPool")
        val numbersToCalculate = mutableListOf<Int>()
        for (i in 1..1000) {
            numbersToCalculate.add(30)
        }
        val timeTaken = measureTimeMillis {
            val jobs = numbersToCalculate.map { number ->
                launch(customDispatcher) {
                    fibonacci(number)
                }
            }
            jobs.forEach { it.join() }
        }
        println("Tempo levado com $numberOfThreads threads: $timeTaken ms")
        customDispatcher.close()
    }
}

Saída do console do exemplo 2

Tempo levado com 1 threads: 4884 ms
Tempo levado com 2 threads: 2910 ms
Tempo levado com 4 threads: 1660 ms
Tempo levado com 8 threads: 1204 ms
Tempo levado com 16 threads: 1279 ms
Tempo levado com 32 threads: 1260 ms
Tempo levado com 50 threads: 1364 ms
Tempo levado com 100 threads: 1400 ms
Tempo levado com 500 threads: 1475 ms

Exemplo 3 - Código que lê um arquivo de números randômicos e os soma ao final da leitura

import kotlinx.coroutines.*
import java.io.File
import kotlin.system.measureTimeMillis

@OptIn(DelicateCoroutinesApi::class)
fun main() = runBlocking {
    val file = File("numeros_aleatorios.txt")

    if (!file.exists()) {
        println("Arquivo não encontrado!")
        return@runBlocking
    }
    val numberOfThreadsList = listOf(1, 2, 4, 8, 16, 32, 50, 100, 500)
    for (numberOfThreads in numberOfThreadsList) {
        val customDispatcher = newFixedThreadPoolContext(numberOfThreads, "customPool")
        val timeTaken = measureTimeMillis {
            val jobs = mutableListOf<Deferred<Int>>()
            file.useLines { lines ->
                lines.forEach { line ->
                    jobs.add(async(customDispatcher) {
                        processLine(line)
                    })
                }
            }
            val totalSum = jobs.awaitAll().sum()
            println("Total da soma com $numberOfThreads threads: $totalSum")
        }
        println("Tempo levado com $numberOfThreads threads: $timeTaken ms")
        customDispatcher.close()
    }

}

fun processLine(line: String): Int {
    return line.toInt() + 10
}

Saída do console do exemplo 3

Total da soma de 1201 linhas com 1 threads: 60192
Tempo levado com 1 threads: 97 ms
Total da soma de 1201 linhas com 2 threads: 60192
Tempo levado com 2 threads: 28 ms
Total da soma de 1201 linhas com 4 threads: 60192
Tempo levado com 4 threads: 30 ms
Total da soma de 1201 linhas com 8 threads: 60192
Tempo levado com 8 threads: 26 ms
Total da soma de 1201 linhas com 16 threads: 60192
Tempo levado com 16 threads: 33 ms
Total da soma de 1201 linhas com 32 threads: 60192
Tempo levado com 32 threads: 35 ms
Total da soma de 1201 linhas com 50 threads: 60192
Tempo levado com 50 threads: 44 ms
Total da soma de 1201 linhas com 100 threads: 60192
Tempo levado com 100 threads: 66 ms
Total da soma de 1201 linhas com 500 threads: 60192
Tempo levado com 500 threads: 297 ms

Exemplo 4 - Código que chama uma API 500 vezes

import io.ktor.client.*
import io.ktor.client.engine.cio.*
import io.ktor.client.request.*
import kotlinx.coroutines.DelicateCoroutinesApi
import kotlinx.coroutines.launch
import kotlinx.coroutines.newFixedThreadPoolContext
import kotlinx.coroutines.runBlocking
import kotlin.system.measureTimeMillis

@OptIn(DelicateCoroutinesApi::class)
fun main() = runBlocking {
    val client = HttpClient(CIO)

    try {
        val numberOfThreadsList = listOf(1, 2, 4, 8, 16, 32, 50, 100, 500)
        for (numberOfThreads in numberOfThreadsList) {
            val customDispatcher = newFixedThreadPoolContext(numberOfThreads, "customPool")
            val timeTaken = measureTimeMillis {
                repeat(500) {
                    val jobs = launch(customDispatcher) { client.get("http://127.0.0.1:5000/example") }
                    jobs.join()
                }
            }
            println("Tempo levado com $numberOfThreads threads: $timeTaken ms")
            customDispatcher.close()
        }
    } catch (e: Exception) {
        println("Erro ao conectar à API: ${e.message}")
    } finally {
        client.close()
    }
}

Saída do console do exemplo 4

Tempo levado com 1 threads: 7104 ms
Tempo levado com 2 threads: 4793 ms
Tempo levado com 4 threads: 4170 ms
Tempo levado com 8 threads: 4310 ms
Tempo levado com 16 threads: 4028 ms
Tempo levado com 32 threads: 4089 ms
Tempo levado com 50 threads: 4066 ms
Tempo levado com 100 threads: 3978 ms
Tempo levado com 500 threads: 3777 ms

Os exemplos 1 ao 3 tem um comportamento em comum, todos eles ficam mais performáticos até 8 threads, depois voltam a subir no tempo de processamento, mas não o exemplo 4, o que então isso mostra? Não é interessante usar sempre o maior número possível de threads?

A resposta simples e rápida é não.

O processador da minha máquina tem 8 cores, ou seja, ele consegue fazer 8 tarefas ao mesmo tempo, mais do que isso o tempo aumenta pois o tempo de gerenciar os estados de cada thread acaba degradando a performance.

Ok, isso responde do exemplo 1 ao 3, mas e o exemplo 4? Qual o motivo da performance melhorar quanto mais threads são lançadas?

Simples, pois é uma integração, a maquina não tem processamento, ela basicamente espera uma resposta, ela fica "dormindo" até a resposta chegar, então sim, aqui o número de threads pode ser maior. Mas cuidado, não significa que pode ser o maior número possível, threads causam exaustão de recursos, usá-las indiscriminadamente tem um efeito reverso que vai afetar a saúde como um todo do serviço.
Sendo assim, para definir o número de threads que seu pool terá, a maneira mais fácil e segura é separar a natureza da tarefa que será feita. Sendo elas separadas em duas:

Tarefas que não exigem processamento:
Quando o tipo de tarefa não exige processamento, podem ser criadas mais threads do que os cores de processadores da máquina. Isso acontece por não ser necessário processar a informação para a completude da thread, basicamente as threads com essa natureza, em sua maioria, esperam respostas de integrações, como por exemplo a escrita em um BD ou a resposta de uma API.
Tarefas que exigem processamento:
Quando a solução tem um processamento, ou seja, que a máquina efetivamente está tendo trabalho, o número máximo de threads deve ser o número de cores do processador da máquina. Isso pelo motivo de um core de processador ser incapaz de fazer mais de uma coisa ao mesmo tempo. Por exemplo, se o processador em que a solução roda tem 4 cores, então seu pool de threads deve ser do tamanho dos cores do seu processador, um pool de 4 threads.

Conclusão

Primeiro ponto a se definir quando se pensa em pool de threads não é nem necessariamente o número que limitará o tamanho do mesmo, mas sim a natureza da tarefa executada. As threads ajudam e muito na performance dos serviços, mas devem ser usadas da melhor maneira para que ela não tenha o efeito contrário e degrade a performance, ou ainda pior, faça que o serviço inteiro tenha a saúde afetada. Fica claro que pools menores acabam favorecendo as tarefas com muito uso de processamento, as tarefas CPU bounded em outras palavras. Caso não tenha certeza se a solução em que as threads serão usadas tem um comportamento em que o processamento será usado massivamente, peque pela precaução, limite seu pool ao número de processadores da máquina, acredite, vai lhe poupar muita dor de cabeça.

Construindo Microsserviços com Alta Perfomance

Mario Beani — Mon, 29 Jul 2024 20:30:45 +0000

O que é desempenho?

De acordo com o dicionário Cambridge, desempenho significa: “quão bem uma pessoa, máquina, etc. faz um trabalho ou uma atividade”. Ok, isso explica o significado geral de desempenho, mas como isso afeta a modelagem de uma API, na arquitetura de sistemas e, mais importante, como isso afeta a qualidade do sistema?

Como pode ser medido?

Tomando como medida a definição que foi fornecida anteriormente, o desempenho mede o quão “bem” uma atividade é feita. Mas então como o sucesso de um sistema, de uma API, pode ser medido? O que pode ser usado para um roteiro de padrões a serem criados? Vamos nos concentrar em um aspecto principal do desempenho e uma medição para conquistá-los todos (desculpe pela piada). Latência.

Definição de latência

Primeiro de tudo, uma explicação geral do que é latência, de acordo com o dicionário Cambridge latência é “o atraso entre uma instrução para transferir (= mover) informações do computador e as informações sendo transferidas, por exemplo, pela internet”. Então, basicamente latência é quanto tempo leva para uma ação ser concluída, ou neste caso, em quanto tempo a API responde.

Latência ideal

Agora que a definição de latência está clara, qual é o modelo que deve ser seguido? Como podemos saber se a latência, o tempo de resposta da API, é realmente bom?

Uma pesquisa liderada pela Dra. Gitte Lindgaard descobriu que as pessoas podem tomar decisões difíceis sobre o apelo visual de uma página da web após serem expostas a ela por apenas 50 ms, o que é 1/20 de segundo (50 ms é apenas metade de 0,1 segundo, mas é próximo o suficiente para os propósitos de uma análise de "potências de 10".)

No estudo de Lindgaard, imagens de tela foram exibidas para os participantes do teste por 0,05 segundos, após o que eles puderam distinguir entre designs mais e menos atraentes. É importante perceber que não é assim que os usuários realmente abordam as páginas da web durante o uso real. Por um lado, as páginas não piscam na tela por um instante e depois desaparecem. Em vez disso, elas são renderizadas ao longo de um período de um segundo (se tivermos sorte — caso contrário, mais). Além disso, as pessoas passam alguns segundos olhando a página antes de decidir o que fazer a respeito.

Ainda assim, o estudo mostra que as pessoas podem formar impressões visuais básicas muito rapidamente, nos limites da percepção humana.

0,1 segundo é o limite de tempo de resposta se você quiser que os usuários sintam que suas ações estão causando algo diretamente na tela. Por exemplo, se você clicar em um menu expansível e ver a versão expandida em menos de 0,1 segundo, então parece que você fez o menu abrir. Se demorar mais de 0,1 segundo para o estado revisado aparecer, então a resposta não parece instantânea — em vez disso, parece que o computador está fazendo algo para abrir o menu.

Assim, para criar a ilusão de manipulação direta, uma interface de usuário deve ser mais rápida do que 0,1 segundo.

Em estudos de rastreamento ocular, a maioria das fixações que rastreamos duram pouco mais de 0,1 segundo. Na verdade, a primeira coisa que as pessoas notam ao executar seu primeiro estudo de rastreamento ocular é a rapidez com que o olho humano se move pelas páginas da web (ou outros estímulos). Os usuários olham as coisas muito brevemente, o que é um grande motivo para enfatizar a clareza na usabilidade do conteúdo.

Ok, isso é muito legal, mas quais são os intervalos de tempo em que o tempo de resposta deve passar? Existem 3 limites de tempo principais (que são determinados pelas habilidades perceptivas humanas) para ter em mente ao otimizar o desempenho, e eles são bem novos, estão aqui desde 1968 (sim, você leu certo) [Miller 1968; Card et al. 1991]. São eles:

0,1 segundo é o limite para que o usuário sinta que o sistema está reagindo instantaneamente, o que significa que nenhum feedback especial é necessário, exceto para exibir o resultado.
1,0 segundo é o limite para que o fluxo de pensamento do usuário permaneça ininterrupto, mesmo que o usuário perceba o atraso. Normalmente, nenhum feedback especial é necessário durante atrasos de mais de 0,1, mas menos de 1,0 segundo, mas o usuário perde a sensação de operar diretamente nos dados.
10 segundos é o limite para manter a atenção do usuário focada no diálogo. Para atrasos maiores, os usuários desejarão executar outras tarefas enquanto esperam o computador terminar, então eles devem receber feedback indicando quando o computador espera terminar. O feedback durante o atraso é especialmente importante se o tempo de resposta provavelmente for altamente variável, já que os usuários não saberão o que esperar.

Então, com base nessas informações, o gráfico abaixo mostra o nível de paciência e atenção dos usuários conforme o tempo passa, ou conforme a latência aumenta.

E por que isso é um problema com a arquitetura de microsserviços?

Comparando a arquitetura de microsserviços com um monolito, há uma diferença óbvia, há mais serviços se comunicando entre si, como mostrado na imagem abaixo:

Esse tipo de arquitetura certamente tem muitos benefícios, mas um dos maiores problemas é o desempenho. Mas por quê? Bem, no monolito, todo o processo feito durante uma chamada é feito no mesmo serviço, mas em microsserviços há mais partes envolvidas, mais serviços, isso levou a um problema que às vezes é negligenciado: latência nas integrações. Por exemplo, se sua chamada tem 5 microsserviços envolvidos, e a latência de rede é de apenas 20 ms para cada, há apenas 100 ms de latência aumentada na resposta do cliente. E certamente em uma solução simples isso não é muito, mas em arquiteturas complexas isso começa a se multiplicar exponencialmente e esse problema não pode ser negligenciado.

Resolução

Infelizmente não há uma resposta que resolva esse problema de uma vez por todas, então vamos listar algumas delas:
Entendendo seu software

Seu design de software deve levar em conta o problema que ele está tendo que resolver e qual é a melhor maneira de resolvê-lo. Seja o mais simples que puder, mas sempre projete para o pior cenário.

Usando a melhor ferramenta (linguagem de programação) e algoritmo para o trabalho — otimização

Um dos benefícios dos microsserviços é que um serviço pode ter linguagens de programação diferentes dos outros, então use a melhor ferramenta para o trabalho, não tente resolver diferentes problemas da mesma maneira, eles não são o mesmo problema, por que a mesma solução funcionaria então? E reserve mais tempo para escrever bem os algoritmos, planejar as integrações, sempre tente resolver os problemas da maneira mais simples e inteligente possível.

Cache

O cache é uma ferramenta poderosa que pode fazer toda essa latência de rede cair drasticamente, mas precisa ser usada da melhor maneira e com o TTL (tempo de vida) certo para a solução. Gosto de dividi-los em três tipos:

Local: Um cache que pode ser criado dentro do próprio serviço, por exemplo, salvando na memória do serviço uma lista de tipos de moeda.
Distribuído: Um cache que é distribuído dentro de várias instâncias do seu serviço ou até mesmo vários serviços. Normalmente isso se dá quando existe um serviço de cache em que gerencia os dados e outros serviços se integram com ele. Ex: Redis.
Gateway: Armazenar em cache as respostas dos seus endpoints no lado do gateway, por exemplo, como a AWS dá a possibilidade, ajuda a diminuir a latência e o estresse no seu serviço. O serviço precisa processar as chamadas necessárias, mas não necessariamente todas elas. Para um exemplo concreto, se um serviço retorna o preço de um produto que é alterado diariamente apenas, não há necessidade de cada requisição passar por toda a cadeia de serviço. Armazenar em cache a resposta pode ser a solução.

Claro que o cache não é uma solução barata, então deve ser bem analisado se é realmente necessário e a melhor maneira de usá-lo. Mas uma coisa deve ser levada em conta, vamos supor que um serviço de geração de links de pagamento leve 5 segundos para responder, e isso, como mostrado no gráfico, impacta a atenção e retenção do usuário. Armazenando em cache as integrações, essa latência cairia para 2 segundos, por exemplo, fazendo uma rápida matemática de quanto é perdido devido a essa latência e o quanto isso afeta o UX, a solução de cache pode até se pagar.

Paralelismo

Da mesma forma que a seção "otimização" olhou na seção de codificação, o paralelismo é uma ferramenta poderosa, mas leve em conta que uma ferreamente poderosa tem uma possibilidade de construção gigante, mas o potencial de destruição [e diretamente proporcional. Pode ajudar muito a fazer tarefas usando o máximo de sua estrutura e recursos de hardware, mas tem que ser bem usado e bem pensado, ou pode levar à hardware starvation ou até mesmo racing conditions.

I/O

Este é bem simples, quanto mais I/O o sistema tiver, mais latência ele terá, mas um ponto que é negligenciado e que está incluído aqui é o log. Log e observabilidade são essenciais em todas as soluções, mas logs em excesso afetam drasticamente o desempenho da solução construída. Então, da mesma forma que todas as outras partes da solução, o log devem ser bem projetado e pensado.

Chamadas assíncronas

Não há como resolver as muitas integrações que a arquitetura de microsserviços traz, mas há uma maneira de projetar do melhor modo essas integrações. Usando soluções assíncronas, a latência também cai enormemente. É lógico o raciocínio aqui, se eu não dependo de esperar uma ação para finalizar o meu processo, ele será mais rápido, e para entender a possibilidade de usar chamadas assíncronas podem ser respondidas as seguinte pergunta: é preciso esperar a resposta dessa integração para retornar algo ao cliente? E em uma análise ainda mais profunda: Esse serviço ser feito orientado a eventos?

Segurança: evitando chamadas maliciosas

Usar estratégias para bloquear chamadas maliciosas ou DDoS, por exemplo, no início do fluxo, como um firewall ou AWS Shield, ajuda a reduzir o stress nos serviços, não permitindo que chamadas maliciosas cheguem a toda a cadeia da solução.

Balanceamento de carga

Ter mais de uma instância da solução lidando com as requisições é uma maneira conhecida de aliviar o estresse no sistema. Mas ter um balanceador de carga que sabe para qual instância a chamada deve ir, com base não apenas no round robin, mas também em dados, por exemplo: quantas chamadas a instância está segurando ou como a infraestrutura da instância está se comportando, pode ter um grande impacto no desempenho.

Rate Limiting / Throttling

Se a solução tiver um pico que não é conhecido anteriormente, ou não levado em consideração quando o design da solução foi feito, é melhor ter uma rate limit, em outras palavras, é melhor colocar algumas chamadas em espera do que redirecionar todas as chamadas para o sistema. Isso teria um impacto nas chamadas que devem ser retidas e também nas chamadas que estão sendo processadas. Em síntese, é melhor ter uma latência maior em algumas chamadas do que em todas as chamadas.

Monitoramento

Este é um tema negligenciado que simplesmente não pode ser, toda solução tem que ser monitorada. Toda solução deve ter observabilidade. Claro que isso deve ser bem pensado e projetado, pois em excesso o desempenho pode ser afetado, como abordado anteriormente. Mas tracing, logs e alarmes são o mínimo para uma solução sustentável.

Conclusão

Mas finalmente, como fazer uma solução ter um bom desempenho? A resposta é o famoso "depende". Existem muitas possibilidades e maneiras, mas um ponto é permeado: Construa e analise sua solução visando o que ela deve fazer e como fazê-lo melhor. Não use uma solução porque ela vai resolver todos os problemas, estude o sistema, estude a solução, projete e analise o custo dela. Mas acima de tudo isso, o design da solução é vivo e deve ser atualizado junto com seus requisitos e funcionalidades. Independente das ferramentas escolhidas elas devem ser usadas da maneira mais adequada, simples e inteligente possível. Não tente usar uma chave de fenda como um martelo, às vezes pode até funcionar, mas você sofrerá muito mais para chegar no seu objetivo e pode até se machucar.

Referências
Lindgaard, G. , Fernandes, G., Dudek, C. and Brown, J. (2006) Attention web designers: You have 50 milliseconds to make a good
first impression! — Behaviour & Information Technology, Vol. 25, №2

Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267–277.

Nielsen, J. (1993). Usability Engineering — Chapter 5