Kinesis - AWS Integration & Messaging Flashcards
Para que serve Kinesis Data Streams?
Kinesis Data Stream é para realizar o stream de big data
Como funciona o Kinesis Data Streams?
Kinesis é divido em shards (paralelo com tópicos em kafka). Assim os dados serão divididos entre os shards para você inserir e consumir dados dos shards
Cite exemplos de Producers para o Kinesis
Podem ser aplicações, clients, SDK ou KPL (Kinesis Producer Library), Kinesis Agent (monitor log files).
Do que é composto o registro que será produzido pelos Producers no Kinesis?
O registro é composto por um Partition Key e Data Blob (1MB).
A Partition Key definirá para onde o registro será enviado.
O Data Blob é o dado em si
Qual é o throughput para os Producers do Kinesis?
[Producer] - Cada shard pode receber 1MB/sec ou 1000 msg por sec por shard. Então com 1 shard, é possível enviar 1MB/sec e com 5 shards, 5 MB/s
Cite exemplos de consumers para o Kinesis
Podem ser funções Lambda, Aplicações (KCL, SDK), Kinesis Data Firehose, Kinesis Data Analytics.
Qual a estrutura da mensagem que o consumer do Kinesis?
O registro recebido é composto pela Partition Key, o número da sequência da mensagem e Data Blob.
Como é feito a cobrança do Kinesis?
A cobrança é feito por shard provisionado. Não há limitação da quantidade de shards.
Qual o tempo de retenção do Kinesis?
O tempo de retenção default é de 1 dia, podendo ir até 365 dias.
Quais as diferenças entre o Kinesis e SQS?
É possível reprocessar o dado no Kinesis,
Uma vez que o dado é inserido, ele não pode ser deletado.
[Segurança]
Como é feito a gestão dos acessos no Kinesis?
Como o dado em trânsito é criptografado?
Como é criptografado o dado em repouso no Kinesis?
É possível implementar uma criptografia diferente?
É possível gerenciar os acessos através de IAM polices.
O dado em trânsito utiliza protocolo HTTPS.
O dado em repouso usa KMS.
É possível implementar criptografia do dado no lado do cliente, mas é mais complexo.
Como posso monitorar as chamas APIs para o Kinesis?
Através do AWS CloudTrail.
Como é definido para qual shard do Kinesis o dado será enviado?
Que cuidados são necessários para escolha do Partition Key do Kinesis?
É executado uma função hash com o input do Partition Key escolhido. O output dessa função com o Partition Key definirá para qual shard a informação será enviada.
É necessário cuidado na escolha do Partition Key para que os shards não fiquem desequilibrados, ou seja, uma mesma Partition Key seja utilizada 90% das vezes, sobrecarregando um Shard, enquanto os outros shards ficam com os outros 10% das informações.
Caso seja excedido o throughput do producer do Kinesis, o que irá acontecer? Quais são as possíveis soluções?
Caso o Throughput do kinesis seja excedido, será gerado uma exceção ProvisionedThroughtputExceeded.
Para solucionar é importante rever se está sendo utilizado uma PartitionKey altamente distribuida (alta granularidade). Também é importante criar retry com exponential backoff e aumentar a quantidade de shards.
Qual é o throughput para os Consumers do Kinesis?
Para o consumer, existem dois modos: shared (classic) fan-out consumer pull, Enhanced Fan-out consumer - push
O shared (classic) fan-out consumer pull é utilizado para redução de custo, porém possui uma limitação de 2MB/sec/shard para todos os consumers, um máximo de 5 GetRecords API calls/sec e uma latência de ~200ms.
Para o Enhanced Fan-out consumer - push é possível ter várias aplicações para o mesmo stream, 2MB/sec por consumer por shard, latência de ~70ms porém com um custo maior.
O que é Kinesis Client Library?
É uma biblioteca Java que auxilia o desenvolvedor a ler registros do Kinesis Data Stream com aplicações distribuidas compartilhando o workload.
É importante ressaltar que cada shard pode ser lido por uma única instância KCL (4 shards = max 4 KCL instances).
Também é necessário acesso do KCL no DynamoDb para checkpointed do progresso de leitura das mensagens.
O que é a operação Shard Splitting do Kinesis?
É uma forma de aumentar a capacidade dos shards quebrando um “hot shard” em dois novos shards. É necessário realizar esta ação manualmente e não é possível quebrar um shard em mais de dois shards em uma única operação. O shard antigo é encerrado após os dados expirarem.
O que é a operação Merging Shards do Kinesis?
É uma forma de reduzir a capacidade dos shards unindo dois “cold shards” em um único shard. É necessário realizar esta ação manualmente e não é possível unir mais do que dois shards em um único shard em uma única operação. Os shards antigos são encerrados após os dados expirarem.
Para o que serve o Kinesis Data Firehose?
Kinesis Data Firehose recebe dados dos producers (Kinesis Data Streams, CloudWatch, IoT, aplicações,…), realiza transformações através de lambdas e insere essas informações, utilizando batch writes, em destinos como AWS Destinations (S3, Redshift, ElasticsSearch), 3rd-party Partner Destinations ou custom destinations (http endpoint).
Qual a diferença entre Kinesis Data Streams e Kinesis Data Firehose?
Kinesis data streams é um serviço de ingestão com escala, com códigos customizados de producers e consumers, real time (~200ms), é necessário gerenciar a escalabilidade com operações manuais (shard splitting e mergin), os dados podem ser armazenados de 1 a 365 dias e possui replay capability.
Já Kinesis Data Firehose é um serviço para carregar dados em S3, redshift, ElasticSearch, 3rd part, custom HTTP, fully managed, near real-time (min 60sec), com escalabilidade automatica, sem data storage e não suporta replay capability
O que é Kinesis Data Analytics?
É um módulo da AWS que permite realizar real-time analytics no Kinesis Streams utilizando SQL.
É fully managed, escala automaticamente. O pagamento é feito por utilização. É possível criar streams out of the real-time queries.
Alguns casos de uso são Time-series analytics, real-time dashboard e real-time metrics.
Qual a diferença entre SQS, SNS e Kinesis?
Aula 263
