[PT-BR] Shoryuken Vs Sidekiq
Tags: ruby, rails, gem, aws
Published: 2023-11-20 18:55:08

Quando pensamos em processamento em background no mundo `Ruby`, levamos em conta atualmente com algumas `Gems` que fazem esse trabalho. Atualmente as que mais se destacam é a [Shoryuken](https://github.com/ruby-shoryuken/shoryuken) e a [Sidekiq](https://github.com/sidekiq/sidekiq), e nesse post vamos ver quais são suas diferenças e quando usar cada uma delas.

(Esse artigo leva em conta apenas o `Sidekiq` em sua versão gratuita) 

### Sidekiq

Visto que a `Gem` mais velha é a `Sidekiq`, é importante olharmos para ela primeiro e entender qual é a função que ela desempenha.

Diferente da [Resque](https://github.com/resque/resque), a `Sidekiq` veio com a ideia de processar os `jobs` de forma concorrente usando `threads`. Antes era necessário aumentar o número de processos, para conseguir processar mais jobs, de forma que era usado mais memória.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8oy581fgqtsazji5eue9.png)

Mas também há semelhanças com o `Resque`, uma delas é o uso do [Redis](https://redis.io/) para armazenar e processar os jobs. Por ser um banco `in-memory`, tanto a escrita como sua leitura são bem rápidas, já que essas operações serão feitas apenas sobre a **memória RAM**.

Levando em conta esses pontos, porque usar o `Shoryuken`? O que ele entrega, que o `Sidekiq` não entrega (pelo menos na versão Free)?

### Shoryuken

A principal diferença entre o `Shoryuken` e o `Sidekiq` está no armazenamento e processamento dos jobs. O `Shoryuken` usa o serviço [SQS](https://aws.amazon.com/pt/sqs/) da **AWS**, ou seja, não temos que configurar e manter uma instancia do `Redis`, todo esse trabalho fica a cargo da **AWS**.

#### Por que usar o SQS?

Segundo a própria **AWS** [os beneficios de se usar o SQS](https://docs.aws.amazon.com/pt_br/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-benefits.html) são:

- **Segurança**: você controla quem pode enviar e receber mensagens em uma fila do Amazon SQS. Você pode optar pela transmissão de dados sigilosos protegendo o conteúdo das mensagens em filas por meio da criptografia do lado do servidor (SSE) gerenciada pelo Amazon SQS ou das chaves de SSE gerenciadas no AWS Key Management Service (AWS KMS).

- **Durabilidade**: para garantir a segurança de suas mensagens, o Amazon SQS as armazena em vários servidores. As filas comuns são compatíveis com a entrega de mensagens pelo menos uma vez, e as filas FIFO são compatíveis com o processamento de mensagens exatamente uma vez e com o modo de alto throughput.

- **Disponibilidade**: o Amazon SQS usa infraestrutura redundante para fornecer acesso altamente simultâneo às mensagens, além de alta disponibilidade para produzir e consumir mensagens.

- **Escalabilidade**: o Amazon SQS pode processar cada solicitação em buffer de forma independente, escalando de forma transparente para lidar com qualquer aumento ou pico de carga sem nenhuma instrução de provisionamento.

- **Confiabilidade**: o Amazon SQS bloqueia suas mensagens durante o processamento, para que vários produtores possam enviar, e vários consumidores possam receber, mensagens ao mesmo tempo.

- **Personalização**: suas filas não precisam ser exatamente iguais. Você pode definir um atraso padrão em uma fila, por exemplo. Você pode armazenar o conteúdo de mensagens maiores que 256 KB usando o Amazon Simple Storage Service (Amazon S3) ou o Amazon DynamoDB, com o Amazon SQS mantendo um ponteiro no objeto do Amazon S3, ou pode dividir uma mensagem grande em mensagens menores.

E o melhor, temos [1 milhão de requests grátis para cada mês de uso](https://aws.amazon.com/sqs/pricing/)!

#### Desempenho

Assim como o `Sidekiq`, o `Shoryuken` também utiliza de threads para processar suas mensagens. Há um benchmarking de um [artigo](https://www.pablocantero.com/blog/2015/03/14/sidekiq-redis-vs-shoryuken-aws-sqs/) que li, mostrando que há um pequena vantagem do `Sidekiq` sobre o `Shoryuken`, porém não acredito ser um ponto tão importante quando vamos escolher entre um dos dois.

#### Armazenamento

Quando usamos o `Redis` para armazenar os nossos `jobs`, precisamos ter em mente que esse banco de dados PODE estar apenas na memória RAM. Falo "PODE", porque existe algumas [features do `Redis`](https://redis.io/docs/management/persistence/) que é possivel configurar-lo para que armazene o que está na `RAM` para o disco rígido. Caso aconteça da instância que está rodando o `Redis` morra, podemos perder jobs importantes que não foram processados.

Já para o SQS não temos que nos preocupar com isso, poís é garantido pela AWS que não iremos perder de forma alguma nossas mensagens.

#### Escalabilidade

Outro ponto que temos que levar em conta é a escalabilidade.

Se houver um pico de usuário que não foi planejado anteriormente, o seu sistema está pronto para continuar atuando da mesma maneira em relação ao processamento em background?

Quando usamos o `Redis` para guardar nossos `jobs`, temos que nos preocupar com isso.
Já quando usamos o `SQS` não é necessário, pois de novo, a AWS garante que irá atender todos os produtores e consumidores da fila, mesmo quando houver picos de acesso.

### Conclusão

A decisão entre `Shoryuken` e `Sidekiq` está mais atrelada a `Redis` e `SQS`.

Para decidir qual das duas `GEMs` usar, deve-se levar em conta o quão importante é não perder o job que será enfileirado e processado.
Além de também levar em conta de há hoje um time que irá conseguir dar manutenção necessária, para que no caso do `Redis`, não tenha grandes problemas.


#### Referencias
- https://docs.aws.amazon.com/pt_br/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-benefits.html
- https://blog.appsignal.com/2022/02/15/delayed-job-vs-sidekiq-which-is-better.html
- https://sidekiq.org/
- https://github.com/ruby-shoryuken/shoryuken