Integration - ribeiry/AWS-Professional-Study GitHub Wiki

SNS

O Amazon Simple Notification Service (Amazon SNS) é um serviço de mensagens totalmente gerenciado para a comunicação de aplicação para aplicação (A2A) e de aplicação para pessoa (A2P). A funcionalidade pub/sub de A2A fornece tópicos para sistemas de mensagens de alta taxa de transferência baseados em push e de muitos para muitos entre sistemas distribuídos, microsserviços e aplicações sem servidor orientadas por eventos.

  • Pode ocasionalmente duplicar mensagens, a aplicação deve ser preparada para que mensagens duplicadas não gere inconsistencias;
  • Protocolos de notificação que são compatíveis (ou seja, HTTP/HTTPS, e-mail)
  • Limites :
    • SNS oferece 10 milhões de assinaturas por tópico e 100.000 tópicos por conta. Para solicitar um limite maior, entre em contato com o suporte.

SQS

Tipos

  • Standard : Maior performace, não garante ordem, garante a entrega de pelo menos uma vez a mensagem

  • FIFO : Menor performace, garante ordem, não tem mensagem duplicada

    • O nome de uma fila FIFO deve terminar com o sufixo .fifo. O sufixo conta para a cota de nomes de fila de 80 caracteres. Para determinar se uma fila é FIFO, você pode verificar se o nome da fila termina com o sufixo. Obs.: Uma vez criada, não é possível a conversão do tipo da fila, caso necessite deve ser deletada e criada uma nova.

  • Suporta até 3,000 mensagens por segundo

  • Suporta até 10 transações por operação

  • Incompatível com RabbitMQ e ActiveMQ

  • Tamanho : Ilimitado

    • Restrições : Há uma cota de 120.000 mensagens em andamento para uma fila padrão e de 20.000 mensagens para uma fila FIFO. As mensagens são consideradas em andamento quando foram recebidas da fila por um componente de utilização, mas ainda não foram excluídas da fila.

  • Traking on SQS Necessário Implementar podendo ser feito por exemplo com SWF (Amazon Simple Workflow Service)

Configuração

Visibility Timeout

  • Mínimo : 0,
  • Máximo : - 12 horas
  • Default : 30 segundos

Obs.: Caso a aplicação consumidora não delete a menssagem da fila após o processamento ter ocorrido, a menssagem permanecerá na fila até que se dê o tempo de visibilidade configurado

Disponibilidade - 14 dias

Diferença entre ShortPolling e LongPolling

  • ShortPolling (Default) : Leitura de um sub-conjunto aleatório de seus servidores com que pode não encontrar todas as mensagens da fila, mas que em uma leitura subsequente as encontrará. A resposta para essa leitura é imediata mesmo que não encontre nada.

  • LongPolling : Quando o tempo de espera de ação da API ReceiveMessageWaitTimeSeconds é maior que 0, nesse caso a busca é feita em todos os servidores e o tempo máximo de espera é de até 20 segundos e trará todas as mensagens encontradas. É também o método mais barato entre eles.

É possivel habilitar o mensagem delay, aonde voce pode configurar a uma fila inteira o valor é de 0 até 15 minutos; para habilidar o delay em uma única mensagem espcífica, use o message timers. Obs..: Para Habilitar para uma mensagem em particular é suportado apenas para filas do tipo standard

  • AWS MQ não é usado como fila propriamente mas como um broker gerenciador de fila. A opção EnableTaskIAMRole é usada para task ECS Windows Based que requer configuração extra.

Temporary Queue

As filas temporárias ajudam a economizar tempo de desenvolvimento e custos de implantação ao usar pattern de mensagem comuns, como request-response. Você pode usar o Temporary Queue Client para criar filas temporárias de alto rendimento, econômicas e gerenciadas por aplicativos. O client mapeia várias filas temporárias - filas gerenciadas por aplicativo criadas sob demanda para um processo específico - em uma única fila Amazon SQS automaticamente. Isso permite que seu aplicativo faça menos chamadas de API e tenha uma taxa de transferência mais alta quando o tráfego para cada fila temporária estiver baixo. Quando uma fila temporária não está mais em uso, o cliente limpa a fila temporária automaticamente, mesmo se alguns processos que usam o client não forem encerrados corretamente. Os benefícios das filas temporárias são:

  • Eles servem como canais de comunicação leves para threads ou processos específicos.
  • Eles podem ser criados e excluídos sem incorrer em custos adicionais.
  • Eles são compatíveis com APIs de filas Amazon SQS estáticas (normais). Isso significa que o código existente que envia e recebe mensagens pode enviar e receber mensagens de filas virtuais.

Para oferecer melhor suporte a destinos de mensagens leves e de curta duração, a AWS recomenda Amazon SQS Temporary Queue Client. Este client facilita a criação e exclusão de muitos destinos de mensagens temporárias sem inflar sua conta da AWS. O conceito-chave por trás do client é a fila virtual. As filas virtuais permitem multiplexar muitas filas de baixo tráfego em uma única fila SQS. A criação de uma fila virtual instancia apenas um buffer local para conter mensagens para os consumidores à medida que chegam; não há chamada de API para SQS e nenhum custo associado à criação de uma fila virtual.

EventBridge

O Amazon EventBridge é um barramento de eventos serveless que torna mais fácil a criação de aplicações orientadas por eventos em escala usando eventos gerados com base em suas aplicações, aplicações integradas de software como serviço (SaaS) e serviços da AWS. O EventBridge fornece um stream de dados em tempo real de fontes de eventos, como Zendesk ou Shopify, para destinos como AWS Lambda e outras aplicações SaaS. Você pode configurar regras de roteamento para determinar para onde enviar seus dados para criar arquiteturas de aplicações que reagem em tempo real às suas fontes de dados com o editor de eventos e o consumidor completamente dissociados.

Obs.: Embora SNS pode ser usado para serviços baseados em eventos, ele não é SaaS e não oferece suporte à integração de serviços de terceiros.

Rules of EventBridges

As regras de entrada corresponde a eventos e envios aos alvos para processamento. Uma unica regra pode enviar um evento para multiplos alvos, qual então roda em paralelo. Regras são baseadas qualquer padrão de evento ou agendado. Um padrão de evento pode definir uma estrutura de evento e campos que correspondem as regras. Regras que são baseadas em um agendamento de performance uma ação que é de intervalo regulares.

Serviços da AWS pode criar e gerenciar uma regra de EventBridge em sua conta aws que são necessárias para certas funções nesses serviços. Esses são chamados de regras gerenciadas.

Quando uma regra de serviço é criado ou gerenciado, isso pode criar uma policy de IAM que garante permissões que o serviço cria para a regra. Policy de IAM cria desta forma são com escopo estreito com nivel de permissão de recurso que permite a criação apenas para as regras necessárias.

Amazon MQ

  • O Amazon MQ é um serviço gerenciado de agente de mensagens para o Apache ActiveMQ e RabbitMQ que facilita a configuração e a operação de agentes de mensagens na AWS. O Amazon MQ reduz suas responsabilidades operacionais gerenciando o provisionamento (NÃO É SERVELESS), a configuração e a manutenção dos agentes de mensagem para você. Como o Amazon MQ se conecta às suas aplicações atuais com APIs e protocolos padrão do setor, você pode migrar facilmente para a AWS sem ter de reescrever o código.

Quando usar SNS x SQS x EventBridge

SQS

  • Voce esta olhando por confiança de 1:1 de comunicação assincrona e desacoplar as suas aplicações uma da outra;
  • Voce esta com limite de consumo de mensagens (talvez um gargalo no banco de dados ou algum outro caso)
  • Quando voce quer ordernar as menssagens de aberturas

SNS

  • Quando voce quer publicar menssagens para diferentes inscritos com uma unica ações;
  • Requer alto throughput e escabilidade para publicar e entregar para os seus consumidores
  • Quando tem muitos insicritos

Eventbridge

  • Quando voce quer publicar mensagens para muitos inscritos diferentes e o uso do dado em si atinge um certo padrão interessado;
  • Quando voce quer integrar com outros providers SAAS como o Shopify, Datadog,Pagerduty e outros;
  • Quando voce quer facilitar a discoberta de schemas que outros times produzem e incorporam em sua aplicação;
  • Quando voce usa agendamentos de eventos regularmente usando como um cron job com expressão de envio de mensagens periodicas para o seu event bus

Kinesis

Kinesis Data Firehouse

  • Utilizado para caputra, transformação, e carga de stream de dados, em um storage para análise de dados usando SQL padrão e ferramentas de Business Intelligence (BI) existentes. Não pode ser consumido diretamente por uma apliação, ele conecta-se apenas ao S3, Redshift, Elasticsearch or Splunk (mais usual para data base, data store e analítics.).
  • Pode ser utilizado com diferentes Data Sources, como : AWS SDK, Kinesis Data Stream, Amazon Kinesis Agent, Agents Open source e + 20 Serviços AWS,
  • Auto Gerenciado
  • Near Real Time
    • 60 segundos de Latencia
    • Minimo de 32MB de dados de uma vez
  • Suporta muitos formatos, conversão, transformação e compressão
  • Dados que falham podem ser enviados para um bucket S3
  • FireHouse Buffer
    • Acumula registros em seu buffer
    • O Buffer é descarregado baseado em tempo ou regras de tamanho
    • Por Tamanho
      • Se o tamanho do Buffer é atingido ele é descarregado
    • Por Tempo
      • Se o tempo é atingido o buffer é descarregado
    • FireHouse pode automaticamente aumentar o tamanho do buffer para atender o throughput
    • Alto throughput o buffer irá aumentar
    • Baixo throughput o buffer irá diminuir
    • Se um descarregamento de buffer para um S3 em tempo real for necessário use um Lambda

Amazon Kinesis Data Streams

  • O Amazon Kinesis Data Streams pode coletar e processar grandes streamings de registros de dados em tempo real.
  • A coleta pode ser feita por sensores, agent instalado no host da aplicação, Library do próprio Kinesis, Microserviços e outros serviços AWS.
  • Gerenciamento manual de Shards
  • Uma vez o dado inserido dentro do Kinesis Data Stream ele não pode ser deletado é um tipo immutavel
  • Consumer Enhanced Fan0-Out Pattern
    • 2Mb/s de leitra por Shard, por Enhanced Consumer
    • Não tem a necessidade de chamada de API, usa o modelo de push
  • Pode pode ser consumido por função lambda, Kinesis Data Analytics, Kinesis Data Firehouse e Containers

Enhanced Fan-Out

Você deve usar enhanced fan-out se tiver vários consumidores recuperando dados de um fluxo em paralelo. Com o fan-out aprimorado, os desenvolvedores podem registrar consumidores de stream para usar o fan-out aprimorado e receber seu próprio canal de 2 MB/segundo de throughput de leitura por shard, e esse throughput é dimensionado automaticamente com o número de shards em um stream. Enhaced Fan-Out

Kinesis Producer e Kinesis Consumer

Kinesis Producer :

* KPL (Kinesis Producer Library) por batch, compressão, retentativas, C++ e Java
* Kinesis Agent: Monitora log e arquivos e envia-os para o Kinesis diretamente
* Pode escrever no Kinesis Data Streams e Kinesis Data Firehouse
* 1Mb/s ou 1000 menssagens escritas por Shard

Kinesis Consumer :

  • O período default de retenção do dado no Kinesis Data Stream é de 24horas, o período de retenção pode ser configurado para até 168 horas ou 7 dias.
  • A seguir, alguns cenários típicos de uso do Kinesis Data Streams:
    • Accelerated log and data feed intake and processing
    • Real-time metrics and reporting
    • Real-time data analytics
    • Complex stream processing

Kinesis Client Library (KCL)

  • KCL (Kinesis Client Library) : Checkpoint, e coordena as leituras
  • 2Mb/s de leitura por Shard atraves de todos os consumos
  • 5 API chamadas por segundo por Shard atraves de todos os consumidores
  • KCL com DynamoDb:
    • Apenas o Dynamo pode ser usado como checkpoint para o KCL.
    • Cada aplicação de KCL deve usar sua própria tabela do DynamoDB.
    • Uma Tabela de DynamoDb pode ser usada para um checkpoint do KCL.
    • Shard IDs no streams são usadas como chaves primarias no DynamoDb table durante o checkpoint. Quando aplicações diferentes de aplicações de KCL usa a mesma a DynamoDb table e o mesmo shard IDs são usados no streams, inconsistencias em checkpoint pode ocorrer.
    • Scan de operações são usados para obter o menor do DynamoDb table. Entretando se uma tabela contem menos de diferente aplicações KCL, e a cada aplicação pode receber um o menor que não é relacionada a aplicação propira.

Kinesis Data Analitics

O Amazon Kinesis Data Analytics é a maneira mais fácil de transformar e analisar dados de streaming em tempo real com o Apache Flink. O Apache Flink é uma estrutura e um mecanismo de código aberto para o processamento de streams de dados. O Amazon Kinesis Data Analytics reduz a complexidade de criar, gerenciar e integrar aplicações do Apache Flink com outros serviços da AWS.

  • Lambda pode ser usado para um pré processamento dos dados
  • Pague apenas pelos recursos consumidos, não é barato
  • Apache Flink
  • Apache Flink é um framework de processamento em lote e stream unificado de código aberto desenvolvido pela Apache Software Foundation

Kinesis Video Stream

O Kinesis Video Streams provisiona e escala de maneira elástica e automática toda a infraestrutura necessária para consumir dados de streaming de vídeo de milhões de dispositivos. O serviço oferece armazenamento resiliente, criptografa e indexa dados de vídeo de streams e permite acessar os dados por meio de APIs fáceis de usar. Shard Iterater normalmente não expira antes de você utilizar, ou se passou 5 minutos. Se ele expirar antes do 5 minutos e você não tiver utilizado pode haver um problema de espaço no Dynamo e necessitara de um aumento de capacidade.

SWF

O SWF ajuda contruir workflows paralelos ou sequenciais. Se a execução do seu aplicativo levar mais de 500 milissegundos o swf pode lhe ajudar.

Step Functions

É um orquestrador serverless que facilita as sequencias de lambda functions, voce pode criar, configurar , popular, executar e evoluir. Step functions pode coordernar serviços como lambda e glue etl dentro de seus workflows. Cada workflow é composto por uma série de passos com uma entrada e uma saida.

Quando usar Step Functions e SWF

Clientes aws devem considerar a usar Step Functions para novas aplicações. Se Step Functions não atender as suas necessidades, então deve considerar o SWF. O SWF prove completo controle sobre sua orquestração logica, mas incrementa a complexidade de desenvolvimento de suas aplicações.Voce deve escrever um programa de decisões (BPM) na linguagem de sua escolha or voce deve usar o Fluxo framework para usar o programa de construção que estrutura asincronamente as interações para voce. Aws ira continuar a prover o SWF para o seus serviços, Fluxos e suporte para todos os clientes do SWF.