PHP: Mensageria com Amazon SQS

Fundamentos do Amazon SQS com PHP - Introdução

Apresentando o curso e realizando audiodescrição

Olá! Seja bem-vinde à Alura. Meu nome é Jeferson Silva e serei a pessoa instrutora deste curso chamado [EM BREVE] PHP: Mensageria com SQS.

Por motivos de acessibilidade, farei uma breve autodescrição.

Audiodescrição: Sou um homem branco, calvo, com barba, uso óculos de grau na cor azul-escuro, estou com fones de ouvido pretos e visto uma camiseta verde.

Apresentando objetivos e diferenciando filas, tópicos e modelos do SQS

Este curso tem como foco entender o Amazon SQS integrado ao PHP.

O que vamos ver ao longo deste treinamento? Vamos abordar conceitos essenciais. Primeiro, vamos entender o que é o Amazon SQS e quando utilizá-lo. Também vamos compreender a diferença entre filas e tópicos. Muitas pessoas no mercado não conhecem essa distinção, então vamos detalhar a diferença teórica entre filas e tópicos.

Além disso, vamos estudar o SQS Standard, a diferença entre SQS Standard e SQS FIFO (First-In-First-Out). São dois modelos de funcionamento do SQS que são específicos da AWS. Falaremos também sobre o que é uma Dead Letter Queue (fila de mensagens com erro), conhecida pela sigla DLQ, e entenderemos para que serve uma DLQ.

Explorando o SQS na AWS e integrando com PHP

No segundo módulo, veremos o SQS na AWS. Vamos criar uma fila no console da AWS, abri-la, navegar pela interface, e configurar uma DLQ para essa fila, isto é, como fazer com que uma fila aponte para outra fila DLQ. Também vamos entender como configurar permissões para a pessoa usuária. Veremos o AWS Identity and Access Management (IAM) com foco em conceder permissões para consumir e publicar mensagens na fila. Testaremos também uma fila do tipo FIFO, para observar, na prática, a diferença de funcionamento em comparação com uma fila SQS Standard.

No módulo 3, trabalharemos com PHP e o AWS SDK for PHP (SDK oficial da AWS para PHP). Vamos configurar as credenciais e entender como criar uma credencial para utilizá-la em nosso código PHP. Em seguida, faremos o envio de mensagens via PHP, com código PHP puro, incluindo o envio múltiplo de mensagens usando sendMessageBatch. Também veremos como receber mensagens por meio de polling (sondagem) e entenderemos esse mecanismo, abordando short polling (sondagem curta) e long polling (sondagem longa), bem como a diferença entre ambos os casos.

Também entenderemos a visibilidade das mensagens (Visibility Timeout), um recurso exclusivo do SQS, no qual podemos manipular a visibilidade das mensagens e fazer com que retornem mais rapidamente à fila em caso de erros, entre outros aspectos.

Aprimorando resiliência, implementando idempotência e migrando para Lambda

No módulo seguinte, abordaremos resiliência e erros. Nessa parte, aperfeiçoaremos nosso worker (trabalhador). Transformaremos esse worker (trabalhador) para que seja mais resiliente, de modo que gerencie interrupções solicitadas pelo sistema ou pela própria pessoa usuária. Veremos retry (nova tentativa) com backoff (intervalo de espera), isto é, como realizamos novas tentativas exponenciais: primeiro um segundo, depois dois segundos, três, quatro, oito, e assim exponencialmente.

Também veremos como implementamos idempotência em nosso worker (trabalhador), verificando quando a mesma mensagem chega mais de duas vezes, mantendo um controle para não duplicar processos. Para um sistema de processamento de pagamentos, é muito importante não permitir que a pessoa usuária pague duas vezes o mesmo valor, no mesmo momento ou em um intervalo de tempo, o que é muito relevante.

Veremos como levamos nosso consumer (consumidor) para a AWS Lambda. Converteremos nosso worker (trabalhador) em uma função Lambda sem servidor. Obviamente é uma demonstração, mas será muito interessante.

Concluindo com projeto final, integrando com Laravel e orientando próximos passos

Por fim, teremos um projeto final, que será uma apresentação da arquitetura e da ideia do projeto, que é nosso sistema de pagamentos. Analisaremos a problemática: qual seria o problema de ter um sistema de pagamentos integrado diretamente em nossa aplicação e que seja lento? Quais problemas podem ocorrer?

Também veremos como configurar o SQS no Laravel. Criaremos uma mensagem na fila usando o próprio framework, o Laravel, aproveitando os recursos que o Laravel oferece para tratar mensageria. Por fim, veremos como funciona o modelo de mensageria com o worker (trabalhador) do Laravel. Ou seja, como iniciamos um worker (trabalhador) do Laravel para que consuma; estando configurado para observar o SQS, ele começará a consumir as mensagens que chegarem lá. Veremos como fazer um retry (nova tentativa), e com isso terminamos a parte geral do nosso curso.

Esperamos que você goste do curso, estude bastante e faça os desafios. Em caso de dúvidas, existe a comunidade: há um fórum da comunidade e também uma comunidade no Discord, onde você pode resolver suas dúvidas. Sucesso nos estudos!

Fundamentos do Amazon SQS com PHP - O que é SQS e quando usar

Apresentando a aula e contextualizando o SQS

Aula 1 — PHP: Mensageria com SQS

Nesta aula, veremos o que é o SQS e quando utilizá-lo. Antes de começar, vamos contextualizar o SQS. SQS é a sigla de Amazon Simple Queue Service (Serviço de Fila Simples), isto é, um sistema de filas de mensagens. A palavra em inglês queue (fila) refere-se a filas, e podemos ter múltiplas filas gerenciadas para microsserviços, sistemas distribuídos e aplicações serverless (sem servidor).

Qual é a grande vantagem de usar o SQS? Primeiro, por ser um serviço exclusivo da Amazon Web Services (AWS) e totalmente gerenciado, externalizamos a gestão da infraestrutura de filas. No mercado existem diversos tipos, variantes e modelos de filas; provavelmente já ouvimos falar de RabbitMQ, Apache Kafka ou outros serviços de mensageria. Apesar de existirem diferenças entre esses modelos, neste caso o SQS é focado em filas tradicionais. Em uma aula mais adiante, abordaremos a diferença entre filas, tópicos e outros padrões de mensageria.

Por ser totalmente gerenciado, o SQS oferece escalabilidade automática, o que é uma grande vantagem: se precisarmos de mais escala ou recursos, quem se encarrega disso é a AWS, não nós. Não precisamos de especialistas em infraestrutura para administrar esse aspecto. Outra vantagem é a integração nativa com o ecossistema da AWS, algo importante de destacar.

Exemplificando pagamentos e comunicação síncrona

Quando faz sentido utilizar? Qual é o motivo e o contexto de uso? Tomemos a ideia de um sistema com uma aplicação tradicional que possui um módulo de pagamentos. Esse módulo de pagamentos se comunica com um gateway (intermediador) de pagamento, que pode ser qualquer um do mercado; em outras palavras, precisamos de um terceiro para processar o pagamento da pessoa cliente.

Imaginemos a operação em que a aplicação captura os dados dessa pessoa cliente e os registra internamente, mas, antes de concluir, precisa saber se o pagamento foi aprovado ou não, fazendo isso de uma vez em uma comunicação síncrona. A aplicação utiliza o módulo de pagamentos interno — a classe, o componente, o que estiver implementado —, que vai até o gateway (intermediador) e pergunta: foi possível processar o pagamento desta pessoa cliente? Durante esse tempo, o gateway estará ocupado tentando processar a solicitação. Alguns intermediadores processam até retornar um “OK”. Esse “OK” volta para a nossa aplicação, que então devolve a resposta para a pessoa cliente. Nesse cenário, a pessoa clica em comprar e fica aguardando na tela enquanto tudo ocorre. Esse é o conceito de comunicação síncrona.

Se houver um problema no gateway (intermediador) de pagamento, teremos de retornar um erro. E se quisermos tentar novamente o processamento? Já temos os dados dessa pessoa cliente, mas, por algum motivo, o gateway pode ter ficado indisponível — é um serviço de terceiros, não o administramos e não sabemos se está ativo. Pode falhar. Como reprocessar? Vamos pedir que a pessoa cliente tente pagar de novo? Isso não é uma boa experiência. Essa situação nos leva ao conceito de comunicação assíncrona.

Nesse caso, faz sentido introduzir comunicação assíncrona com a seguinte garantia: primeiro, temos um elemento chamado produtor, que é a nossa aplicação. A aplicação deixa de se comunicar diretamente com o módulo de pagamentos e passa a colocar uma mensagem na fila com os dados necessários para processar o pagamento. Para esse processamento, teremos o que chamamos de consumidor. Esse consumidor captura a mensagem — isto é, consome a mensagem —, recebe o conteúdo que foi colocado na fila e o repassa ao módulo de pagamentos, que então fará a comunicação com o gateway (intermediador).

Se houver um problema, o módulo de pagamentos detectará e poderá executar outra operação ou tentar novamente. Se ocorrer algum problema, outra coisa muito útil: aqui podemos pensar primeiro no caso positivo.

Então, nós nos comunicamos com o gateway (intermediador) e ele retornou um OK para o pagamento; não precisamos fazer mais nada. Podemos, obviamente, acessar um banco de dados. Não colocamos um banco de dados aqui, mas imagine que tivéssemos um banco no qual tanto a aplicação quanto nosso consumidor acessariam. Assim, tudo fica centralizado, o que é bem mais interessante.

Detalhando reprocessamento, confirmação e filas mortas

Podemos devolver a mensagem para a fila e veremos que é possível colocá-la em uma fila de mensagens mortas, ou mesmo não remover a mensagem para que, no futuro, esse consumidor volte a capturar esse item da fila e tente processar o pagamento. Dessa forma, a fila passa a centralizar mensagens. Por isso falamos em mensageria: a fila contém mensagens que são consumidas, processadas e, em seguida, há comunicação entre o consumidor e a fila confirmando com um OK quando tudo ocorreu bem. Se não ocorreu bem, pode-se não confirmar/remover a mensagem e ela volta para a fila para ser reprocessada, como em uma técnica que veremos mais adiante: dead-letter queue (DLQ, fila de mensagens mortas). Teremos, portanto, um local para colocar mensagens que não foram processadas.

Temos dois conceitos aí. Um é não enviar OK para a mensagem. Outro é enviar OK quando a mensagem foi processada; depois, ela pode até entrar em outra fila, em outro recurso do Amazon SQS, para continuar o processamento.

Apontando outros cenários de uso e arquitetura orientada a eventos

Prosseguindo, pensemos em outros pontos. Trouxemos a ideia do processamento de pagamentos, mas há situações em que faz muito sentido usar filas ou mensageria. Um exemplo são operações de escrita cujo processamento demora. Não queremos que a pessoa usuária, que está acessando nossa API ou nossa página, permaneça esperando 2 ou 3 minutos, o que pode gerar timeout (tempo limite). Não queremos deixar a pessoa esperando. Precisamos, então, de uma operação em segundo plano. Assim, podemos responder imediatamente ao request (requisição): esta mensagem será processada. Dessa forma, realizamos o chamado processamento assíncrono, no qual não ficamos aguardando a conclusão.

Picos de carga também são relevantes, sejam previsíveis ou imprevisíveis. Por exemplo, precisamos registrar 10 mil pessoas usuárias na base de dados ou carregar 10 mil registros em uma integração entre sistemas. Enviar isso diretamente para a aplicação gera 10 mil requests (requisições) em um segundo. O que podemos fazer com esse pico de mensagens? Armazená-las e processá-las no nosso ritmo, por lotes, em partes — por exemplo, de 10 em 10 — enquanto vamos processando as informações. Isso ocorre em segundo plano. Não é necessário que quem está no cliente, no front-end (camada de interface) — ou mesmo o nosso próprio front-end (camada de interface) — espere. Nem precisamos exibir uma barra de progresso; estamos processando de forma assíncrona.

O mesmo vale para integrações entre sistemas independentes. Quando algo acontece em um sistema, o outro precisa ser notificado. Isso se relaciona com o conceito de arquitetura de software chamada arquitetura orientada a eventos, isto é, arquiteturas baseadas em eventos. Esses eventos podem ser considerados mensagens que transitam entre sistemas. Aqui, obviamente, entramos em um conceito mais complexo. Vamos nos concentrar nos conceitos mais básicos, importantes e usados no contexto tradicional de filas.

Reforçando resiliência e concluindo a aula

Também há a necessidade de resiliência a falhas. Às vezes, temos um serviço que está falhando e precisamos reprocessar. Tentamos uma vez, falhou; precisamos tentar novamente. Precisamos persistir a mensagem e trabalhar as novas tentativas. A fila também ajuda em outros cenários: se um serviço estiver fora do ar, podemos ir armazenando as mensagens na fila; quando o serviço voltar, retomamos e reprocessamos, e assim por diante. Existem várias técnicas e padrões voltados a arquiteturas mais distribuídas, que fazem ainda mais sentido quando nossa aplicação passa a exigir processos assíncronos, em segundo plano e distribuídos.

Nesta aula, falamos bastante sobre SQS e também sobre quando usar filas, quando não usar e por que usar. Obviamente, esses são apenas alguns pontos interessantes que devemos conhecer.

Até a próxima aula!

Fundamentos do Amazon SQS com PHP - Filas vs Tópicos

Contextualizando filas e tópicos

Nesta aula, vamos discutir a diferença entre filas e tópicos. Vamos ao quadro. Precisamos observar e entender as diferenças práticas. Atualmente, fala-se muito sobre filas, tópicos e intermediários de mensagens, o que gera muitos termos em torno do conceito de assincronia — usando filas, usando tópicos, usando intermediários de mensagens. Qual é a diferença entre tudo isso?

Esta aula fornece a base para alinharmos esses conceitos, principalmente em relação ao serviço Amazon SQS da AWS.

Definindo intermediários de mensagens e contextualizando o SQS

Quando falamos em message broker (intermediário de mensagens), estamos nos referindo a um serviço de filas ou, como veremos adiante, a um serviço de tópicos. Ou seja, para viabilizar comunicação ou execução de tarefas entre nossos sistemas ou microserviços por meio de troca de mensagens, precisamos de um intermediário de mensagens.

Um intermediário de mensagens é qualquer tipo de serviço intermediário que oferece armazenamento e gestão de mensagens. Existem diversos conceitos e ferramentas, cada uma com seu próprio modelo. Neste curso, vamos nos concentrar no Amazon SQS e destacar algumas diferenças entre os serviços da AWS.

Tenhamos em mente o que é um intermediário de mensagens ao falarmos do serviço de mensageria.

Comparando SQS e SNS na AWS

Qual é a diferença entre Amazon SQS e Amazon SNS? Muitas vezes encontramos essas duas definições e surge a dúvida: ambos trabalham com mensagens, então qual é a diferença?

• SQS é fila. Esse é o primeiro ponto que precisamos entender — já mencionado na aula passada — SQS trata de filas.
• SNS é notificação. SNS vem do termo em inglês Amazon Simple Notification Service (Serviço de Notificação Simples).

Veremos essa diferença na prática, na visualização. É importante saber que existem SQS e SNS, e que são serviços diferentes na AWS.

Detalhando o funcionamento de filas no SQS

Amazon SQS é fila. Em termos práticos, observamos o conceito de produtores: podemos ter Produtor 1, Produtor 2 e Produtor 3. Podem ser três sistemas diferentes ou três partes de um mesmo sistema principal. O ponto importante é que esses produtores geram mensagens que serão colocadas na fila.

Como a fila é definida na AWS? No SQS, podemos ter um ou mais consumidores, mas as mensagens são recebidas individualmente: a partir do momento em que colocamos uma mensagem na fila, ela será retirada por um único e exclusivo consumidor. Esse é o ponto central da fila aqui. Um consumidor único recebe a mensagem e se encarrega do seu processamento.

No Amazon SQS, não é possível entregar a mesma mensagem a mais de um consumidor simultaneamente. Portanto, ainda que outros intermediários de mensagens no mercado adotem modelos diferentes, no contexto da AWS, o SQS garante que apenas um consumidor receba a Mensagem 1 e seja responsável por ela. Não há como o Consumidor 2 também receber a Mensagem 1.

Na prática:

• A Mensagem 1 é colocada na fila e o Consumidor 1 lê a Mensagem 1.
• O Produtor 2 envia a Mensagem 2 (os Produtores 1, 2 ou 3 não precisam seguir uma ordem específica).
• Se o Consumidor 1 já está processando a Mensagem 1, quem recebe a próxima mensagem é o Consumidor 2.

Não há como o Consumidor 1 e o Consumidor 2 receberem a Mensagem 1 simultaneamente.

Como já dissemos na aula passada, pode acontecer de o Consumidor 1 não conseguir processar a mensagem por algum motivo, e essa mensagem ser devolvida para a fila. Nesse caso, o Consumidor 2, se estiver livre, poderá consumir a Mensagem 1, pois ela não foi processada. Entretanto, no ciclo completo, se o Consumidor 1 concluir o processamento da Mensagem 1, encerra-se o fluxo e essa mensagem é retirada da fila. Portanto, não é possível, simultaneamente, notificar no SQS outro consumidor, como o Consumidor 2, com a mesma mensagem. A Mensagem 1 não chegará ao Consumidor 2 enquanto o Consumidor 1 for o “dono” da mensagem. SQS garante esse padrão de comunicação. Sobre ordenação, falaremos mais adiante.

Explicando o modelo de tópicos no SNS

Esse é o principal conceito de SQS, pois SNS funciona exatamente de forma oposta. Em SNS, trabalhamos com tópicos. No caso anterior, comunicávamos por filas. Aqui, comunicamos por tópicos. No conceito de tópicos, alteramos inclusive a nomenclatura: passamos a ter um publisher (publicador), e não mais, como chamamos anteriormente, produtor. Esses nomes podem variar conforme o contexto, mas vamos entender o conceito no ecossistema da AWS. Publicamos uma mensagem em um tópico, diferente do conceito anterior de mensagem em fila. O tópico possui seus interessados, isto é, seus inscritos, que chamamos aqui de subscriber (assinante). Mantemos o termo em inglês para nos acostumarmos. Assim, temos Subscriber 1, Subscriber 2, Subscriber 3 — três assinantes interessados em tudo o que acontece em um tópico específico. Podemos ter múltiplos tópicos: Tópico 1, Tópico 2, Tópico 3. Cada subscriber observa um tópico; no exemplo, temos três subscribers observando um único tópico. Quando uma mensagem chega a esse tópico, os três subscribers recebem a notificação, daí o conceito de notificação.

Podemos relacionar esse cenário ao contexto de dispositivos móveis ligados a um aplicativo. Imaginemos 10 dispositivos móveis conectados à aplicação, e a aplicação precisa notificar esses 10 dispositivos simultaneamente. Esse é o conceito do tópico. Tecnicamente, isso ocorre por trás dos panos, mas em linhas gerais é a isso que nos referimos: temos múltiplos interessados em um mesmo tópico. Quando o tópico recebe uma mensagem de origem — aqui ilustramos com um único publisher, mas poderíamos ter 10 publishers em 10 tópicos diferentes, ou 2 publishers apontando para um mesmo tópico — não há problema na quantidade “à esquerda” em relação à quantidade “à direita”. O que importa é que a Mensagem 1 será replicada para 3, 4, 5, 10 ou 1 milhão de subscribers inscritos naquele tópico. Essa é a grande diferença.

A fila (queue), no conceito da AWS, direciona a mensagem para um único interessado, por assim dizer. Voltando ao termo anterior, chamamos esse interessado de consumidor. Um consumidor recebe, de forma exclusiva, um item da fila no momento em que precisa realizar o processamento; ele é o “dono” desse item enquanto o trabalho estiver em andamento. Já no caso de notificações por tópicos, é diferente: temos múltiplos interessados para um único tópico. Essa é a distinção fundamental entre os modelos.

Listando intermediários de mensagens do mercado

Agora, vejamos os tipos de brokers (intermediários de mensagens) que existem, apenas por curiosidade. No mercado, há vários brokers, e cada um tem seu próprio modelo de trabalho. Temos, por exemplo, o Google Cloud Pub/Sub, que se aproxima mais do conceito de tópicos. Precisamos entender que ele pode, inclusive, atender ambos os casos de uso — tanto o modelo de fila quanto o de tópico — de forma nativa. Vale investigar as particularidades de cada serviço. Neste momento, não precisamos compreender tudo em profundidade; é importante apenas saber que existem serviços e metodologias diferentes entre eles.

Temos também o Azure Service Bus, da Microsoft Azure, e serviços do Google Cloud Platform (GCP) — como mencionamos, o Google Cloud Pub/Sub. Entre as soluções independentes, o RabbitMQ segue um modelo baseado em filas, mas incorpora diversos padrões; nele, encontramos o conceito de exchange (roteador de mensagens), que é uma particularidade da ferramenta. Já o Apache Kafka é uma plataforma de event streaming (transmissão de eventos) muito poderosa para alto volume de mensagens, com um modo de operação bastante específico. Ele também trabalha com os conceitos de broker e tópicos — o uso de tópicos é muito comum — mas adota outras ideias e estruturas que não são nosso foco aqui.

Encerrando e definindo o foco do curso

No nosso contexto, quando falamos em tópico, estamos nos referindo ao Amazon SNS da AWS. Quando falamos em fila, estamos nos referindo ao Amazon SQS. O curso terá foco principal em Amazon SQS.

Encerramos por hoje. Até a próxima.

Sobre o curso PHP: Mensageria com Amazon SQS

O curso PHP: Mensageria com Amazon SQS possui 242 minutos de vídeos, em um total de 47 atividades. Gostou? Conheça nossos outros cursos de PHP em Back-end, ou leia nossos artigos de Back-end.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Primeira aula do curso
• Segunda aula do curso
• Terceira aula do curso
• Quarta aula do curso
• Quinta aula do curso