Elasticsearch Meetup::Case Reclame Aqui
•Transferir como PPTX, PDF•
0 gostou•121 visualizações
Caso do Reclame Aqui apresentado no Meetup da Elasticsearch br
![Reclame
AquiAdoção do Elasticsearch como fonte de dados
Diego Campos (CTO) [ diego@reclameaqui.com.br ]
André Rocha (S.A.) [andre.rocha@reclameaqui.com.br] v.1.2.0](https://image.slidesharecdn.com/w9owaxsossa8tqwdfaac-signature-7e63cf5d336176655202ba3a8b8c445ae0cec6bd76ff45108e8b43cab42ec1d7-poli-180705173629/85/Elasticsearch-Meetup-Case-Reclame-Aqui-1-320.jpg)
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Elasticsearch Meetup::Case Reclame Aqui
Semelhante a Elasticsearch Meetup::Case Reclame Aqui (20)
Elasticsearch Meetup::Case Reclame Aqui
- 1. Reclame AquiAdoção do Elasticsearch como fonte de dados Diego Campos (CTO) [ diego@reclameaqui.com.br ] André Rocha (S.A.) [andre.rocha@reclameaqui.com.br] v.1.2.0
- 2. Motivação ● 95 % dos usuários entram no site do Reclame Aqui para pesquisar: ○ Empresas ○ Produtos ○ Reclamações similares ● Difícil prever comportamento dos consumidores nas buscas, portanto, difícil de cachear ● Frequência de alteração dos dados implica nas estratégias de cache e indexação ● Agregar informações para adicionar filtros complexos estava se tornando uma tarefa árdua e complexa de criar e manter
- 3. ● Solr ● Elasticsearch (1.7) ● Cassandra + Solr ● CouchDB ● MongoDB Opções para aceleração das buscas
- 4. ● Opensource ● Plugável ● Escalável ● Confiável ● Adoção da comunidade ● Adoção de produtos em Cloud Premissas para decidir
- 7. ● Modelo de dados adotado ( crud e consolidações) ● Modelo de segurança para operações ● Número de réplicas, índices e shards ● Dashboards operacionais ● Modelo de upgrade de versão ● Metrificação segmentada ● Curva de aprendizado maior do que esperávamos O que deu errado?
- 8. ● Disponibilidade ● Escalabilidade ● Confiabilidade ● Modelo de Snapshot x backup ● Performance ● Alteração dos modelos ● Agregações, buscas complexas, scrolls, caching por uri ● Métricas, versionamento de objetos ● Monitoria O que deu certo?
- 9. ● Upgrade! ● Metrificação segmentada ● Exploração de dados ● Dashboard administrativa ● Segurança para operações ● Modelo de dados ● Operações de CRUD síncronas em outro DB, Elasticsearch assíncrono Próximos passos
- 10. Perguntas? Diego Campos (CTO) [ diego@reclameaqui.com.br ] Andre (Sof.Arch) [ andre.rocha@reclameaqui.com.br ] Estamos contratando!
Notas do Editor
- - Modelo de dados adotado, nós erramos por criar indices por tipo de operação (raichucrud e reduces), isso tornou esses indices e os shards deles grandes demais e quanto mais dados entram, pior fica a gestão - Modelo de segurança para operações: Nós operamos o elasticsearch atraves da api rest dele (com o sense), isso cria a possibilidade de dedo gordo fazer cagada com facilidade, fora isso, não encontramos um modelo de gestao de usuarios para limitar o acesso para certos desenvolvedores e definir o grao de acesso, como acontece por exemplo com as Grants em banco de dados relacional - Numero de replicas, indices e shars, como falado no item 'modelo adotado', nossa falta de conhecimento na epoca da modelagem fez com que no medio prazo esses indices agrupassem muitos shards, toda vez que temos problema em uma replica de shard, o nivel de consumo de recurso do elasticsearch quase esgota as maquinas envolvidas na operação - Dashboard operacionais: Nos so temos o Sense hoje e o Kibana, funciona em um escopo exploratorio, em um escopo operacional de manutenção de dados, exige um certo grau de cuidado e conhecimento do operador - Modelo de upgrade de versão: Como adotamos o es 1.7 na epoca do desenvolvimento, e ficamos tomados por um tempo durante os proximos meses, perdemos o timming de upgrade, isso gerou a ncessidade de refatorar as aplicações (queries, drivers, agregações, scrolls) para capacitar o raichu a atender esse upgrade ...estamos migrando para o 6, mas vamos dar um salto pro 2.4 primei ro - Metrificação segmentada: Nos temos metricas gerais do cluster (numero de queries online, numero de merges, saude do cluster), mas não conseguimos metrificar as operações (por exemplo quais queries estao performando e quais não estão, quais shards estão performando e quais não estao) - Curva de aprendizado: Nós sabiamos muito pouco a respeito do elastic quando começamos a desenvolver, a curva da equipe demorou meses ate estabilizar e ainda estamos aprendendo,
- - Disponibildade: O cluster raramente apresenta problemas, mesmo quando um nó apresenta problemas, normalmente os demais continuam atendendo, o numero de replicas afeta essa capacidade obviamente - Escalar é simples como instalar uma nova maquina - Confiabilidade: Não tivemos nenhum evento de catastrofe por culpa do cluster de elasticsearch em que ele mesmo não ofereceu a solução (as vezes nem era necessario atuar), fora isso o Uptime do cluster hoje é de: 1.14 anos, nao precisa dizer muito mais a respeito =D - Modelo de backup: Não fazemos backup, tiramos apenas snapshot dos discos diariamente, fazemos testes com certa frequencia aplicando esses snapshots em outros clusters, tudo acontece programagicamente - Performance: Salvo eventos em que temos shards com segmentos quebrados, o cluster atende entre 1000 a 6000 queries simultaneas com latencia variando entre 200mili a 2 segundos dependendo da complexidade, isso atende a nossa estrategia atual. Fora isso ao mesmo tempo sempre temos uma media de 200 a 2000 requisicoes de indexação e entre 3000 a 20000 requisicões de objetos (Seria legal falar nesse ponto da media de acesso simultanea no site, diaria e mensal tb) - Alteração dos modelos: Nós alteramos os templates de objeto com frequencia, as vezes reindexando os dados e as vezes somente alterando os astributos dos novos objetos, raramente é necessario um nivel pesado de operação nestas migrações, isso acelerou conisideravelemente nosso processo de desenvolvimento continuo - Agregações, buscas complexas, scrolls, caching por uri: Boa parte dos dados exibidos no site fazem uso de agregações somadas a caches dinâmicos e estaticos para serem construidos na camada de exibição, o elasticsearch consegue performar mais do que o suficiente nesse modelo. Nos modelos de buscas, por exemplo é possivel recem criar uma reclamação e buscar por partes do seu conteudo, classificação e tags, o tempo de indexação é de segundos (normalmente menos de 1 segundo), e é possivel buscar por termos, frases ou a conjunção deles logo em seguida, alem disso é possivel fazer sugestão instantanea com base nos termos (usamos essa soluçao para busca de empresas por exemplo), a latencia das buscas é adequada a nossa necessidade - Metricas, versionamento de objetos: Apesar de precisarmos de mais, as metricas de saude do cluster vem de brinde na solução, é necessario construir muito pouco para monitorar o cluster desde o dia 0, depois de qse 2 anos uso, não tivemos eventos onde as metricas de saude falharam. Outra coisa bacana e que cada alteração incrementa um inteiro na versão dos objetos, isso possibilita que saibamos quantas alteracoes esse objeto sofreu, tambem usamos esse inteiro para gerar uma pseudo atomicidade nas operações de crud e em algumas agregações - Monitoria: O marvel é uma solução simples e precisa, ele nos salvou nos primeiros meses, hoje adotamos o Grafana mas agradecemos imensamente ao marvel pela colaboração, fora isso as metricas acessiveis pelas apis de _cat trazem tudo que precisamos em crises, migrações e geração de capacity
- - Upgrade!, vamos visitar o 2.4, isso esta em fase de homologação, e logo em seguida vamos para o 6 - Metrificação segmentada: Nós estamos construindo metricas baseadas em log de requisição para consolidar em tempo real quais segmentos do projeto estao afetando a performance do cluster - Exploração de dados: Nós estamos construindo um projeto de Dados, o elasticsearch é a fonte de dados para a construção do data lake inicial, mas ja estamos a alguns meses experimentando formas de minerar os dados do elastic, fazendo paineis online do comportamento dos usuarios alem de paineis de auditoria do sistema. Fora isso estamos explorando as capacidades de ML do elastic (baby steps ainda) - Dashboard administrativa: Projetamos uma solução administrativa para poder operar os dados do elastic com maior segurança, alem de simular ACID e pseudo transações para poder dar manutenção nos dados durante o dia a dia. - Segurança para operações: Complementar ao assunto dashboard, estamos estudando opções para granular o acesso para os desenvolvedores e aplicações - Modelo de dados: Estamos abandonando o modelo de dados inicial e adotando modelos baseados em templates de data, fora isso iremos aumentar consideravelmente nosso numero de indices, shards e replicas - Operações de CRUD sincronas em outro Database, elastic assincrono: Hoje usamos o Mysql para as operações sincronas e temos um pool de operações para gerenciar a ingestao de dados e solicitação de dados para o elastic, a solução que pretendemos adotar é trocar o Mysql por uma solução que escale melhor para as operações ACID, retirando a responsabilidade da aplicação em termos transacionais, e enfileirar as solicitacoes de indexação do es no modelo tradicional de fila, alem de tornar as requisicoes de busca assincrona e não somente fazendo uso de pooling de recursos.