Manish Singh é CTO da empresa MityLytics Inc, empresa fundada em julho de 2015, que desenvolve software para o gerenciamento de desempenho contínuo de aplicativos distribuídos em nuvem e localmente. Singh e suas equipes desenvolvem produtos para fornecedores de infra-estrutura e conduziram esses produtos desde o início até sua implementação em diversas empresas, incluindo GoGrid, Netscaler, Redback Networks / Ericsson, Ascend/ Lucent.
Na palestra, Singh explica como usar metodologias durante o projeto, desenvolvimento, implantação e operação para entrega de plataformas de análise em tempo real que oferecem SLAs (acordo de nível de serviço). Para aplicações IoT são necessários alguns requisitos básicos como:
- Tempo Real: para certificação de certas garantias e baixo tempo de resposta.
- Baixa latência: garante o tempo de resposta seja baixo.
- Alta credibilidade: o sistema deve ser resiliente.
- Alta disponibilidade: o sistema deve ser sempre responsivo. Quando um componente cair, outro componente terá que responder às requisições.
Além dessas garantias é necessário saber com qual plataforma trabalhar, e qual a melhor para sua aplicação. Dentre os tipos de plataforma Singh destaca as seguintes: Nuvem privada, Nuvem publica, Localmente, Nuvem híbrida, Nuvem Bare-metal e Plataformas.
Após decidir qual a melhor plataforma para o seu produto, é necessário verificar os provedores de gerenciamento de serviços, ou seja, entender um pouco mais sobre elas, como fatores a serem levados em consideração: Trade offs, Custo, Gerenciamento, Controle, Escala e Escala dinâmica.
Fonte: InfoQ
A imagem acima mostra o ciclo de vida para a ánalise. Os dados apresentam-se de diversas fontes, e precisam ser analisados em tempo real, armazenados para então chegar a um resultado que possa ser apresentado ao usuário. Para realizar essa análise é necessário realizar perguntas importantes sobre o seu sistema:
- Quais as garantias que ele oferece?
- Quais as diferentes componentes?
- Onde eles estão?
- Quais os tipos de limitações durante a performance?
A equipe de Singh realizou testes em cima de dois tipos de servidores:
O servidor tipo 1 foi escolhido para rodar o Apache Kafka, e o tipo 2 rodou Apache Spark. As medições foram realizadas de forma que pudéssemos analisar a performance dos sistemas. Para analisar essa performance foram utilizados benchmarks open source. Os dados são categorizados em diferentes streams, e para esse exemplo foram produzidas mensagens pelo Kafka e consumidas pelo Spark.
Inicialmente foram produzidos 100k mensagens por segundo, e cada mensagem possuindo 200 bytes. Por mais que sua aplicação não exija um processamento tão rápido de milissegundos, pode ser que meio segundo seja muito tempo, e isso deve ser levado em consideração ao decidir quais componentes são importantes para o seu sistema. Outras questões a serem consideradas dizem respeito à necessidade das mensagens que chegam serem persistentes. Todos esses fatores são uma base de como medir a performance de injeção no streaming e qual hardware escolher.
Para consumir os dados produzidos foi utilizado o Spark. ele foi realizado um benchmark e os resultados são apresentados na imagem abaixo:
Algumas ferramentas que podem ser utilizadas e ajudam na performance do sistema são:
- Hadoop - maps, reduces, shuffles.
- Kafka - message rate, partition, replication.
- Spark - RDD, list operations.
- Hive - maps, reduces.
- Query - query latency, queries/sec.
- Cassandra - gossip, read/write.
Realizar um benchmark e este produzir resultados satisfatórios não quer dizer que o mesmo resultado ocorrerá em sua aplicação. É necessário verificar as características desejáveis de sua aplicação e então buscar a performance que deseja, verificando o que cabe melhor a ela. Isso deve ser feito de forma contínua, pois os objetivos mudam com o tempo, mais dados surgem, os dados mudam, e com isso você precisa planejar para esses diferentes cenários.
A metodologia que Singh utiliza é rodar benchmarks isolados no cluster, e após isso rodar os benchmarks entre si, pois as diferentes ferramentas podem estar concorrendo para utilizar o mesmo recurso e isso dar conflito em sua aplicação. Por fim, deve ser comparado o desempenho nos 2 casos para ver se os clusters devem ser isolados ou podem estar no mesmo cluster e entender o custo/desempenho.
Você pode conferir a apresentação completa realizada por Manish Sinh no InfoQ.