SentiOne

A SentiOne, reconhecida pela Deloitte como uma das empresas de tecnologia com crescimento mais rápido da Europa Central, oferece uma plataforma de IA conversacional única que lhe permite monitorizar discussões online, interagir com o seu público e automatizar o serviço de apoio ao cliente em todos os canais web.

Enquanto que a maioria das empresas de IA que fornecem chatbots tem dificuldade na formação dos recursos, a SentiOne utiliza discussões reais retiradas da Internet para treinar o seu motor NLU (“Natural Language Understanding” - compreensão da linguagem natural). Graças a um vasto conjunto de dados, recolhidos durante o desenvolvimento de uma ferramenta de escuta social aprofundada, a SentiOne é capaz de treinar motores de Deep Learning extremamente rigorosos.

“Graças à colaboração com a OVHcloud ao longo destes anos, conseguimos fazer evoluir o nosso negócio de forma estável e processar terabytes de dados, fornecendo informações de qualidade aos nossos clientes.”

Michał Brzezicki, cofundador e CTO da SentiOne

Com uma quantidade elevada de dados a recolher e analisar em tempo real, a empresa enfrentou vários desafios em matéria de infraestrutura e software. Por um lado, o desempenho do seu cluster Elasticsearch, crucial para uma boa experiência de cliente durante a utilização da plataforma, diminuiu. Por outro, a SentiOne também verificou uma utilização desproporcionada de alguns clusters, com alguns deles sobrecarregados e outros totalmente inativos.

Para melhorar a velocidade da sua plataforma de IA conversacional, a SentiOne levou a cabo um enorme plano de manutenção para migrar o hardware e, ao mesmo tempo, atualizar o software. Michał Brzezicki, cofundador e CTO da SentiOne, partilhou connosco os detalhes deste complexo projeto gerido pela sua equipa.

A equipa de especialistas de TI da SentiOne listou várias razões potenciais que podem ter levado à degradação do cluster Elasticsearch, incluindo a falta de potência da CPU, o baixo rendimento do armazenamento, as falhas de hardware, a configuração do software e problemas de ligação e de rede.

Rede

O Elasticsearch é muito propenso a problemas de ligação e em caso de instabilidade de rede entre dois nós, o cluster inteiro abranda. Para manter uma ligação fiável e segura entre os nós, a SentiOne optou por usar o vRack – a solução de rede privada concebida pela OVHcloud.

Os problemas de rede foram resolvidos quase de forma permanente graças à ativação desta solução, uma vez que o vRack permitiu à SentiOne estabelecer ligações estáveis entre os nós, sem recurso à rede pública.

Para uma compreensão mais profunda do estado da sua infraestrutura, a equipa da SentiOne utiliza Grafana com o plug-in Sensu para armazenar todos os valores do sistema e do Elasticsearch. Uma vez que não foram verificadas anomalias, nem com as interfaces públicas nem com o vRack, a equipa descartou a rede como possível fonte dos problemas de desempenho.

CPU

Ao aprofundar a procura das possíveis causas dos problemas de desempenho, a equipa analisou a utilização da CPU e a gestão dos threads. A utilização geral da CPU no cluster aproximava-se dos 80%, o que é considerado adequado. De facto, este valor indicava uma correta utilização dos recursos em termos de custos. No entanto, a equipa verificou que o cluster tornava-se consideravelmente mais lento durante os reajustamentos.

Durante estes períodos de abrandamento, a utilização da CPU era muito baixa e limitava-se a um único core e, após uma análise mais aprofundada, revelou-se que a maior parte do tempo da CPU era dedicado a operações de I/O. Uma vez que a equipa já tinha excluído a rede como possível causa do problema, começaram a investigar o armazenamento.

Armazenamento

A criação de um painel Grafana para a métrica I/O do Sensu deu à equipa da SentiOne a resposta que procurava. O gráfico resultante revelou claramente o tempo que a CPU dedicava às operações de I/O num determinado período, e esse número podia alcançar os 100%!

Isso também explicava a razão pela qual o cluster abrandava durante o reajustamento. Se um nó aleatório a partir do qual se tinha copiado um fragmento tivesse estado sujeito a uma grande carga de I/O, tentar copiar esse fragmento só iria piorar as coisas.

Configuração do cluster Elasticsearch

A infraestrutura da SentiOne estava baseada em nós “quentes e frios”. Os nós quentes alojavam os índices mais populares, ou seja, os que eram consultados com mais frequência, enquanto que os nós frios continham os dados consultados com pouca frequência. Adicionar mais réplicas aos índices quentes para equilibrar a carga parecia ser uma solução óbvia, mas neste caso não era adequado. Em primeiro lugar, as consultas eram atribuídas aos fragmentos de forma aleatória, pelo que, se se repetisse uma consulta pesada várias vezes (por exemplo, grupos diferentes para a mesma consulta), todas as réplicas ficariam sobrecarregadas com cálculos semelhantes ou idênticos. Além disso, a versão do Elasticsearch instalada no cluster da SentiOne na altura não oferecia o Adaptive Replica Selection (ARS). Tornou-se claro que a adição de novos nós no cluster não permitiria equilibrar o desempenho, a menos que a equipa atualizasse o software.

Depois de ter identificado os obstáculos que causavam a degradação do desempenho do cluster Elasticsearch, a equipa de TI pôde começar a planear as modificações de software, arquitetura e hardware que permitiriam melhorar a capacidade de resposta da plataforma.

Substituir o hardware e escalar os clusters de forma horizontal parecia ser a opção mais lógica, mas, devido ao seu orçamento significativo mas limitado, a SentiOne começou por otimizar a utilização do cluster.

Antes de a equipa estar pronta para migrar para uma nova infraestrutura de servidores dedicados, era necessário realizar outras ações.

Repartição de dados mais inteligente

Em primeiro lugar, os engenheiros da SentiOne analisaram as consultas dos utilizadores e a forma como estas afetavam o desempenho do cluster. A relação entre o tempo das consultas e o número de fragmentos consultados e o seu respetivo tamanho era simples: quanto maiores fossem os fragmentos, maior seria a duração das consultas, e quanto mais fragmentos fossem consultados, maior seria a duração de todo o processo.

Para otimizar o tempo de consulta, a SentiOne decidiu dividir os dados em fragmentos mais pequenos, não superiores a 30 GB. Depois de consultados, os dados de um único fragmento devem poder ser integrados na cache do sistema de ficheiros da RAM, pelo menos em teoria.

Após analisar que intervalos eram consultados pelos utilizadores, a SentiOne também alterou a forma como os dados eram divididos em índices: dividindo os dados de acordo com o comportamento do cliente, para minimizar o número de fragmentos por consulta, e reduzindo o intervalo dos índices de mensal para semanal.

Aplicação

A equipa da SentiOne reviu os pontos em que o cluster era consultado, otimizou as chamadas e alterou a interface para que os utilizadores não tivessem a impressão de “freezing” do sistema. Também introduziram verificações para bloquear as consultas excessivamente pesadas, baseando-se nos tempos de execução dentro de um período de tempo variável. Historicamente, uma única consulta pesada poderia degradar o desempenho de todo o cluster. Este controlo de segurança era assim necessário, mesmo que limitasse o acesso de alguns utilizadores.

Alterações na arquitetura

Com a nova versão do cluster, a SentiOne abandonou a abordagem “quente e frio” por diversas razões. Antes de mais nada, é difícil distinguir os índices quentes e frios. Em que momento é que um índice pode ser considerado “quente”? Em segundo lugar, os nós frios tinham um uso de I/O muito baixo com picos de utilização da CPU, enquanto que os nós quentes estavam sobrecarregados pelas I/O, mas tinham recursos da CPU que não eram utilizados. Um claro desperdício de recursos e dinheiro. Finalmente, conseguir o equilíbrio certo entre os nós frios e quentes demonstrou ser uma tarefa complexa que envolvia custos desnecessários.

Novo hardware

A infraestrutura anterior incluía três nós principais, 82 nós quentes e 42 nós frios, todos equipados com a mesma solução de armazenamento: dois discos Intel® SSD DC S4500. Uma vez que o principal objetivo da migração do hardware era melhorar o desempenho do armazenamento, a SentiOne escolheu os servidores da gama Advance, especialmente os modelos ADV-2 com discos NVMe, para os seus novos nós de dados.

A tecnologia NVMe é uma combinação de SSD, bus PCIe e protocolos NVMe, concebida para colmatar as diferenças de desempenho entre o processamento e o armazenamento.

A interface entre os SSD pode influenciar de forma significativa a latência total que o utilizador perceciona a nível da aplicação, enquanto que a interface física (PCIe) e o protocolo (NVMe) determinam o desempenho geral. Uma ligação PCIe 3.0 x4 oferece uma taxa de transferência quase cinco vezes maior que a interface SATA mais rápida e quase três vezes maior que a melhor interface SAS. O protocolo NVMe oferece até 64 000 filas, garantindo assim que a interface é capaz de gerir o elevado número de threads I/O que as CPU multicore podem gerar.

Para implementar o novo cluster de 121 nós de dados e 3 nós principais, a SentiOne dedicou dois meses a desenvolver, testar e planear. Embora o processo de migração e de atualização do Elasticsearch não estivesse isento de problemas e tivesse causado uma interrupção do cluster de seis horas, ofereceu os resultados esperados.

A plataforma omnicanal da SentiOne monitoriza milhares de milhões de discussões em milhares de fontes web. Para fornecer às empresas informações sobre o público e um apoio ao cliente automatizado e baseado em IA, a empresa recolhe, processa e analisa quantidades enormes de dados. O rendimento do armazenamento desempenha assim um papel fundamental.

O novo cluster, integrado em servidores dedicados ADV-2 e equipado com discos NVMe, veio mudar o cenário da SentiOne. A migração do hardware trouxe uma melhoria imediata do desempenho, com um cluster seis vezes mais rápido.

A atualização da versão do Elasticsearch – que incluía a ativação da funcionalidade ARS – permitiu que o cluster funcionasse de forma mais uniforme, distribuindo a carga de forma equilibrada entre vários nós durante os picos. A equipa realizou medições e verificou que a carga aproximava-se dos 50% em operações regulares e não superava os 80% em condições de stress, garantindo níveis de reserva suficientes para as futuras necessidades de escalabilidade ou novas funcionalidades.

“De um ponto de vista orçamental, o processo de migração revelou-se muito vantajoso. Os custos de gestão do cluster foram reduzidos em cerca de 5%, com uma melhoria significativa do desempenho.”

Michał Brzezicki, cofundador e CTO da SentiOne