Este é um publish convidado co-escrito com Mike Mosher, arquiteto principal sênior de rede de plataforma em nuvem em uma empresa multinacional de relatórios de crédito financeiro.
Trabalho para uma empresa multinacional de relatórios de crédito financeiro que oferece soluções de risco de crédito, fraude, advertising direcionado e decisões automatizadas. Somos um dos primeiros a adotar a AWS e adotamos a nuvem para impulsionar os esforços de transformação digital. Nossa equipe Cloud Heart of Excellence (CCoE) opera uma AWS Touchdown Zone international, que inclui uma infraestrutura de rede AWS centralizada. Também somos um parceiro pronto para AWS PrivateLink e oferecemos nossos E-Conectar solução para permitir que nossos clientes B2B se conectem a uma variedade de produtos por meio de conectividade privada, segura e de alto desempenho.
Nossa solução E-Join é uma plataforma composta por vários serviços AWS, como Balanceador de carga de aplicativos (ALVA), Balanceador de carga de rede (NLB), Balanceador de carga de gateway (GWLB), AWS Transit Gateway, AWS PrivateLink, AWS WAFe dispositivos de segurança de terceiros. Todos esses serviços e recursos, bem como a grande quantidade de tráfego de rede na plataforma, criam um grande número de logs, e precisávamos de uma solução para agregar e organizar esses logs para análise rápida por nossas equipes de operações ao solucionar problemas da plataforma.
Nosso projeto unique consistia em Serviço Amazon OpenSearchselecionado por sua capacidade de retornar entradas de log específicas de conjuntos de dados extensos em segundos. Também complementamos isso com Logstashpermitindo-nos usar vários filtros para enriquecer e aumentar os dados antes de enviá-los para o cluster OpenSearch, facilitando uma experiência de monitoramento mais abrangente e criteriosa.
Neste publish, compartilhamos nossa jornada, incluindo os obstáculos que enfrentamos, as soluções que pensamos e por que optamos por Pipelines de ingestão do Amazon OpenSearch para tornar nosso gerenciamento de log mais fácil.
Visão geral da solução inicial
Originalmente, queríamos armazenar e analisar os logs em um cluster OpenSearch e decidimos usar o serviço gerenciado pela AWS para Pesquisa aberta chamado Serviço Amazon OpenSearch. Também queríamos enriquecer esses logs com Logstash, mas não havia nenhum serviço gerenciado pela AWS para isso, então precisávamos implantar o aplicativo em um Amazon Elastic Compute Nuvem (Amazon EC2). Essa configuração significou que tivemos que implementar muita manutenção no servidor, inclusive usando AWS Code Pipeline e AWS CodeDeploy para enviar novas configurações do Logstash para o servidor e reiniciar o serviço. Também precisávamos executar tarefas de manutenção do servidor, como aplicação de patches e atualização do sistema operacional (SO) e do aplicativo Logstash, e monitorar recursos do servidor, como heap Java, CPU, memória e armazenamento.
A complexidade se estendeu à validação do caminho de rede do servidor Logstash para o cluster OpenSearch, incorporando verificações em listas de controle de acesso (ACLs) e grupos de segurança, bem como rotas nas sub-redes VPC. A escalabilidade além de um único servidor EC2 introduziu considerações para o gerenciamento de um grupo de escalonamento automático, Serviço de fila simples da Amazon (Amazon SQS) e muito mais. Manter a funcionalidade contínua da nossa solução tornou-se um esforço significativo, desviando o foco das tarefas principais de operação e monitoramento da plataforma.
O diagrama a seguir ilustra nossa arquitetura inicial.
Possíveis soluções para nós:
Nossa equipe analisou várias opções para gerenciar os logs desta plataforma. Possuímos uma solução Splunk para armazenar e analisar logs e a avaliamos como um concorrente potencial do OpenSearch Service. No entanto, optámos por não fazê-lo por vários motivos:
- Nossa equipe está mais familiarizada com OpenSearch Service e Logstash do que com Splunk.
- O Amazon OpenSearch Service, sendo um serviço gerenciado na AWS, facilita um processo de transferência de log mais tranquilo em comparação com nossa solução Splunk native. Além disso, transportar logs para o cluster Splunk native incorreria em custos elevados, consumiria largura de banda em nosso AWS Direct Join conexões e introduzem complexidade desnecessária.
- A estrutura de preços do Splunk, baseada no armazenamento em GBs, provou ser de custo proibitivo para o quantity de logs que pretendíamos armazenar e analisar.
Projetos iniciais para uma solução de pipeline do OpenSearch Ingestion
A equipe da Amazon me abordou sobre um novo recurso que estava lançando: Ingestão do Amazon OpenSearch. Esse recurso ofereceu uma ótima solução para os problemas que enfrentávamos ao gerenciar instâncias EC2 para Logstash. Primeiro, o novo recurso eliminou todo o trabalho pesado de nossa equipe de gerenciamento de múltiplas instâncias do EC2, aumento e redução de escala dos servidores com base no tráfego e monitoramento da ingestão de logs e dos recursos dos servidores subjacentes. Em segundo lugar, os pipelines de ingestão do Amazon OpenSearch suportavam a maioria, se não todos, dos filtros Logstash que estávamos usando em nossa solução atual, o que nos permitiu usar a mesma funcionalidade de nossa solução atual para enriquecer os logs.
Ficamos entusiasmados por sermos aceitos no programa beta da AWS, emergindo como um dos primeiros e maiores adotantes. Nossa jornada começou com a ingestão de logs de fluxo de VPC para nossa plataforma de entrada na Web, juntamente com logs de fluxo do Transit Gateway conectando todas as VPCs na região da AWS. Lidar com um quantity tão substancial de logs provou ser uma tarefa significativa, com os logs de fluxo do Transit Gateway sozinhos atingindo mais de 14 TB por dia. À medida que expandimos nosso escopo para incluir outros logs, como logs de acesso ALB e NLB e logs AWS WAF, a escala da solução se traduziu em custos mais elevados.
No entanto, o nosso entusiasmo foi um pouco atenuado pelos desafios que enfrentámos inicialmente. Apesar dos nossos melhores esforços, encontramos problemas de desempenho com o domínio. Por meio de esforços colaborativos com a equipe da AWS, descobrimos configurações incorretas em nossa configuração. Estávamos usando instâncias com tamanho inadequado para o quantity de dados que estávamos manipulando. Consequentemente, essas instâncias operavam constantemente na capacidade máxima da CPU, resultando em um acúmulo de logs recebidos. Esse gargalo atingiu nossos pipelines de ingestão do OpenSearch, forçando-os a aumentar desnecessariamente, mesmo enquanto o cluster do OpenSearch lutava para acompanhar o ritmo.
Esses desafios levaram a um desempenho abaixo do ideally suited do nosso cluster. Não conseguimos analisar logs de fluxo ou acessá-los prontamente, às vezes esperando dias após sua criação. Além disso, os custos associados a estas ineficiências excederam em muito as nossas expectativas iniciais.
No entanto, com a ajuda da equipe da AWS, resolvemos esses problemas com sucesso, otimizando nossa configuração para melhorar o desempenho e a economia. Essa experiência ressaltou a importância da configuração e colaboração adequadas para maximizar o potencial dos serviços da AWS, levando, em última análise, a um resultado mais positivo para nossos processos de ingestão de dados.
Design otimizado para nossa solução de pipelines de ingestão OpenSearch
Colaboramos com a AWS para aprimorar nossa solução geral, criando uma solução de alto desempenho, econômica e alinhada aos nossos requisitos de monitoramento. A solução envolve a ingestão seletiva de campos de log específicos no domínio do OpenSearch Service usando um Amazon S3 Choose gasoduto na origem do pipeline; a ingestão seletiva alternativa também pode ser feita por filtragem dentro de pipelines. Você pode usar include_keys e exclude_keys no coletor para filtrar os dados roteados para o destino. Também usamos o embutido Gerenciamento de estado de índice recurso para remover logs anteriores a um período predefinido para reduzir o custo geral do cluster.
Os logs ingeridos no OpenSearch Service nos permitem derivar dados agregados, fornecendo insights sobre tendências e problemas em toda a plataforma. Para análise detalhada adicional desses logs, incluindo todos os campos de log originais, usamos Amazon Atenas tabelas com particionamento para consultas rápidas e econômicas Serviço de armazenamento simples da Amazon (Amazon S3) para logs armazenados no formato Parquet.
Essa solução abrangente melhora significativamente a visibilidade da nossa plataforma, reduz os custos gerais de monitoramento para lidar com um grande quantity de logs e acelera nosso tempo para identificar as causas principais ao solucionar problemas de incidentes na plataforma.
O diagrama a seguir ilustra nossa arquitetura otimizada.
Comparação de desempenho
A tabela a seguir compara o desempenho do design inicial com o Logstash no Amazon EC2, a solução unique de pipeline do OpenSearch Ingestion e a solução otimizada de pipeline do OpenSearch Ingestion.
| Design inicial com Logstash no Amazon EC2 | Solução unique de pipeline de ingestão | Solução otimizada de pipeline de ingestão | |
| Esforço de Manutenção | Alto: A solução exigia que a equipe gerenciasse vários serviços e instâncias, diminuindo o esforço de gerenciamento e monitoramento de nossa plataforma. | Baixo: o OpenSearch Ingestion gerenciava a maior parte do trabalho pesado indiferenciado, deixando a equipe apenas com a manutenção do arquivo de configuração do pipeline de ingestão. | Baixo: o OpenSearch Ingestion gerenciava a maior parte do trabalho pesado indiferenciado, deixando a equipe apenas com a manutenção do arquivo de configuração do pipeline de ingestão. |
| Desempenho | Alto: as instâncias do EC2 com Logstash podem aumentar ou diminuir conforme necessário no grupo de escalonamento automático. | Baixo: devido a recursos insuficientes no cluster OpenSearch, os pipelines de ingestão estavam constantemente no máximo de OpenSearch Compute Items (OCUs), fazendo com que a entrega do log fosse atrasada por vários dias. | Alto: os pipelines de ingestão podem aumentar ou diminuir em OCUs conforme necessário. |
| Disponibilidade de registro em tempo actual | Médio: para extrair, processar e entregar o grande número de logs no Amazon S3, precisávamos de um grande número de instâncias do EC2. Para economizar custos, executamos menos instâncias, o que levou a uma entrega de log mais lenta ao OpenSearch. | Baixo: devido a recursos insuficientes no cluster OpenSearch, os pipelines de ingestão estavam constantemente no máximo de OCUs, fazendo com que a entrega do log fosse atrasada em vários dias. | Alto: a solução otimizada foi capaz de entregar um grande número de logs ao OpenSearch para serem analisados quase em tempo actual. |
| Economia de custos | Médio: a execução de vários serviços e instâncias para enviar logs ao OpenSearch aumentou o custo da solução geral. | Baixo: devido à insuficiência de recursos no cluster OpenSearch, os pipelines de ingestão estavam constantemente no máximo de OCUs, aumentando o custo do serviço. | Alto: A solução otimizada foi capaz de aumentar ou diminuir as OCUs do pipeline de ingestão conforme necessário, o que manteve o custo geral baixo. |
| Benefício geral | Médio | Baixo | Alto |
Conclusão
Nesta postagem, destacamos minha jornada para construir uma solução usando OpenSearch Service e OpenSearch Ingestion pipelines. Esta solução nos permite focar na análise de logs e no suporte à nossa plataforma, sem precisar dar suporte à infraestrutura para entregar logs ao OpenSearch. Destacamos também a necessidade de otimizar o serviço para aumentar o desempenho e reduzir custos.
Como nossos próximos passos, pretendemos explorar o recentemente anunciado Integração ETL zero do Amazon OpenSearch Service com o Amazon S3 (em versão prévia) recurso no OpenSearch Service. Esta etapa destina-se a reduzir ainda mais os custos da solução e fornecer flexibilidade no tempo e no número de registos que são ingeridos.
Sobre os Autores
Navnit Shukla atua como arquiteto de soluções especialista da AWS com foco em análises. Ele possui um grande entusiasmo em ajudar os clientes a descobrir informações valiosas a partir de seus dados. Através de sua experiência, ele constrói soluções inovadoras que capacitam as empresas a chegarem a escolhas informadas e baseadas em dados. Notavelmente, Navnit Shukla é o autor talentoso do livro intitulado “Knowledge Wrangling on AWS”. Ele pode ser contatado através LinkedIn.
Mike Mosher é arquiteto principal sênior de rede de plataforma em nuvem em uma empresa multinacional de relatórios de crédito financeiro. Ele tem mais de 16 anos de experiência em redes locais e em nuvem e é apaixonado por construir novas arquiteturas na nuvem que atendam aos clientes e resolvam problemas. Fora do trabalho, ele aproveita o tempo com sua família e viaja de volta para casa, nas montanhas do Colorado.