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.
