O blog da AWS
Análise de logs em escala de petabytes com Amazon S3, Amazon OpenSearch Service e Amazon OpenSearch Ingestion
Por Jagadish Kumar (Jag), Muthu Pitchaimani e Sam Selvan.
Muitas vezes, as organizações precisam gerenciar um grande volume de dados que está crescendo a uma taxa extraordinária. Ao mesmo tempo, eles precisam otimizar os custos operacionais para liberar o valor desses dados para obter insights oportunos e fazer isso com um desempenho consistente.
Com esse enorme crescimento de dados, a proliferação de dados em seus data stores, data warehouse e data lakes pode se tornar igualmente desafiadora. Com uma arquitetura de dados moderna na AWS, você pode criar rapidamente Data lakes escaláveis; usar uma coleção ampla e profunda de serviços de dados; garantir a conformidade por meio de acesso, segurança e governança unificados aos dados; escalar seus sistemas a um custo baixo sem comprometer o desempenho; e compartilhar dados entre fronteiras organizacionais com facilidade, permitindo que você tome decisões com rapidez e agilidade em grande escala.
Você pode pegar todos os seus dados de vários silos, agregar esses dados em seu data lake e realizar análises e machine learning (ML) diretamente sobre esses dados. Você também pode armazenar outros dados em data stores específicos para analisar e obter insights rápidos de dados estruturados e não estruturados. Essa movimentação de dados pode ser de dentro para fora, de fora para dentro, ao redor do perímetro ou de forma compartilhada.
Por exemplo, registros e rastreamentos de aplicativos da web podem ser coletados diretamente em um data lake, e uma parte desses dados pode ser transferida para “storage”de análise de log, como o Amazon OpenSearch Service, para análise diária. Consideramos esse conceito como uma movimentação de dados de dentro para fora. Os dados analisados e agregados armazenados no Amazon OpenSearch Service podem novamente ser movidos para o data lake para executar algoritmos de ML para consumo posterior dos aplicativos. Nós nos referimos a esse conceito como movimentação de dados de fora para dentro.
Vamos dar uma olhada em um exemplo de caso de uso. A Example Corp. é uma empresa fictícia líder da Fortune 500, especializada em conteúdo social. Eles possuem centenas de aplicativos, gerando dados e “tracings” de aproximadamente 500 TB por dia e têm os seguintes critérios:
- Ter registros disponíveis para análises rápidas por 2 dias
- Além de 2 dias, tenha dados disponíveis em um nível de armazenamento que possa ser disponibilizado para análise com um SLA razoável
- Retenha os dados por mais de 1 semana em armazenamento frio por 30 dias (para fins de conformidade, auditoria e outros)
Nas seções a seguir, discutimos três soluções possíveis para lidar com casos de uso semelhantes:
- Armazenamento hierárquico no Amazon OpenSearch Service e gerenciamento do ciclo de vida dos dados
- Ingestão sob demanda de registros usando o Amazon OpenSearch Ingestion
- Consultas diretas do Amazon OpenSearch Service com o Amazon Simple Storage Service (Amazon S3)
Solução 1: armazenamento hierárquico no OpenSearch Service e gerenciamento do ciclo de vida dos dados
O OpenSearch Service oferece suporte a três níveis de armazenamento integrados: armazenamento quente, UltraWarm e armazenamento frio. Com base em seus requisitos de retenção de dados, latência de consultas e orçamento, você pode escolher a melhor estratégia para equilibrar custo e desempenho. Você também pode migrar dados entre diferentes níveis de armazenamento.
O armazenamento dinâmico é usado para indexação e atualização e fornece o acesso mais rápido aos dados. O armazenamento dinâmico assume a forma de um armazenamento de instâncias ou volumes do Amazon Elastic Block Store (Amazon EBS) anexados a cada nó.
O UltraWarm oferece custos significativamente mais baixos por GiB para dados somente para leitura que você consulta com menos frequência e que não precisam do mesmo desempenho do armazenamento dinâmico. Os nós UltraWarm usam o Amazon S3 com soluções de cache para melhorar o desempenho.
O armazenamento frio é otimizado para armazenar dados históricos ou acessados com pouca frequência. Ao usar o armazenamento a frio, você separa seus índices da camada UltraWarm, tornando-os inacessíveis. Você pode reanexar esses índices em alguns segundos quando precisar consultar esses dados.
Para obter mais detalhes sobre os níveis de dados no OpenSearch Service, consulte Escolha o nível de armazenamento certo para suas necessidades no Amazon OpenSearch.
Visão geral da solução
O fluxo de trabalho dessa solução consiste nas seguintes etapas:
- Os dados recebidos gerados pelos aplicativos são transmitidos para um data lake S3.
- Os dados são ingeridos no Amazon OpenSearch usando a ingestão do S3-SQS quase em tempo real por meio de notificações configuradas nos buckets S3.
- Depois de 2 dias, os dados ativos são migrados para o armazenamento UltraWarm para suportar consultas de leitura.
- Depois de 5 dias no UltraWarm, os dados são migrados para o armazenamento frio por 21 dias e separados de qualquer computação. Os dados podem ser reanexados ao UltraWarm quando necessário. Os dados são excluídos do armazenamento frio após 21 dias.
- Os índices diários são mantidos para facilitar a transferência. Uma política de Gerenciamento do Estado do Índice (ISM) automatiza a prorrogação ou exclusão de índices com mais de 2 dias.
Veja a seguir um exemplo de política do ISM (Index State Management) que transfere os dados para o nível UltraWarm após 2 dias, os move para o armazenamento refrigerado após 5 dias e os exclui do armazenamento refrigerado após 21 dias:
{
"policy": {
"description": "hot warm delete workflow",
"default_state": "hot",
"schema_version": 1,
"states": [
{
"name": "hot",
"actions": [
{
"rollover": {
"min_index_age": "2d",
"min_primary_shard_size": "30gb"
}
}
],
"transitions": [
{
"state_name": "warm"
}
]
},
{
"name": "warm",
"actions": [
{
"replica_count": {
"number_of_replicas": 5
}
}
],
"transitions": [
{
"state_name": "cold",
"conditions": {
"min_index_age": "5d"
}
}
]
},
{
"name": "cold",
"actions": [
{
"retry": {
"count": 5,
"backoff": "exponential",
"delay": "1h"
},
"cold_migration": {
"start_time": null,
"end_time": null,
"timestamp_field": "@timestamp",
"ignore": "none"
}
}
],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "21d"
}
}
]
},
{
"name": "delete",
"actions": [
{
"retry": {
"count": 3,
"backoff": "exponential",
"delay": "1m"
},
"cold_delete": {}
}
],
"transitions": []
}
],
"ism_template": {
"index_patterns": [
"log*"
],
"priority": 100
}
}
}Considerações
O UltraWarm usa técnicas sofisticadas de cache para permitir a consulta de dados acessados com pouca frequência. Embora o acesso aos dados não seja frequente, a computação dos nós UltraWarm precisa estar em execução o tempo todo para possibilitar esse acesso.
Ao operar em escala de PB, para reduzir a área de efeito de quaisquer erros, recomendamos decompor a implementação em vários domínios do OpenSearch Service ao usar o armazenamento em camadas.
Os próximos dois padrões eliminam a necessidade de computação de longa duração e descrevem técnicas sob demanda em que os dados são trazidos quando necessário ou consultados diretamente onde residem.
Solução 2: ingestão sob demanda de dados de registros por meio do OpenSearch Ingestion
O OpenSearch Ingestion é um coletor de dados totalmente gerenciado que fornece dados de registro e rastreamento em tempo real para os domínios do OpenSearch. O OpenSearch Ingestion é desenvolvido pelo coletor de dados de código aberto Data Prepper. O Data Prepper faz parte do projeto OpenSearch de código aberto.
Com o OpenSearch Ingestion, você pode filtrar, enriquecer, transformar e fornecer seus dados para análise e visualização posteriores. Você configura seus produtores de dados para enviar dados para o OpenSearch Ingestion. Ele entrega automaticamente os dados para o domínio ou coleção que você especificar. Você também pode configurar o OpenSearch Ingestion para transformar seus dados antes de entregá-los. O OpenSearch Ingestion não tem servidor, então você não precisa se preocupar em escalar sua infraestrutura, operar sua frota de ingestão e corrigir ou atualizar o software.
Há duas maneiras de usar o Amazon S3 como fonte para processar dados com o OpenSearch Ingestion. A primeira opção é o processamento S3-SQS. Você pode usar o processamento S3-SQS quando precisar escanear arquivos quase em tempo real depois que eles forem gravados no S3. Ela exige uma fila do Amazon Simple Queue Service (Amazon S3) que receba notificações de eventos do S3. Você pode configurar buckets do S3 para gerar um evento sempre que um objeto for armazenado ou modificado dentro do bucket a ser processado.
Como alternativa, você pode usar uma verificação agendada única ou recorrente para processar dados em lote em um bucket do S3. Para configurar uma verificação agendada, configure seu pipeline com uma programação no nível da verificação que se aplique a todos os seus buckets do S3 ou no nível do bucket. Você pode configurar escaneamentos agendados com um escaneamento único ou recorrente para processamento em lote.
Para uma visão geral abrangente da ingestão do OpenSearch, consulte Ingestão do Amazon OpenSearch. Para obter mais informações sobre o projeto de código aberto Data Prepper, visite Data Prepper.
Visão geral da solução
Apresentamos um padrão de arquitetura com os seguintes componentes principais:
- Os registros do aplicativo são transmitidos para o data lake, o que ajuda a alimentar dados quentes no OpenSearch Service quase em tempo real usando o processamento do OpenSearch Ingestion S3-SQS.
- As políticas do ISM no OpenSearch Service lidam com sobreposições ou exclusões de índices. As políticas do ISM permitem automatizar essas operações administrativas periódicas, acionando-as com base nas mudanças na idade do índice, no tamanho do índice ou no número de documentos. Por exemplo, você pode definir uma política que mova seu índice para um estado somente para leitura após 2 dias e o exclua após um determinado período de 3 dias.
- Os dados inativos estão disponíveis no data lake do S3 para serem consumidos sob demanda no OpenSearch Service usando escaneamentos programados do OpenSearch Ingestion.
O diagrama a seguir ilustra a arquitetura da solução.
O fluxo de trabalho inclui as seguintes etapas:
- Os dados recebidos gerados pelos aplicativos são transmitidos para o data lake S3.
- Atualmente, os dados são ingeridos no OpenSearch Service usando a ingestão do S3-SQS quase em tempo real por meio de notificações configuradas nos buckets do S3.
- Os índices diários são mantidos para facilitar a transferência. Uma política do ISM automatiza a substituição ou exclusão de índices com mais de 2 dias.
- Se for feita uma solicitação para análise de dados além de 2 dias e os dados não estiverem no nível UltraWarm, os dados serão ingeridos usando o recurso de verificação única do Amazon S3 entre a janela de tempo específica.
Por exemplo, se o dia atual é 10 de janeiro de 2024 e você precisa de dados de 6 de janeiro de 2024 em um intervalo específico para análise, você pode criar um pipeline de ingestão do OpenSearch com um escaneamento do Amazon S3 em sua configuração YAML, com o start_time e end_time para especificar quando você deseja que os objetos no bucket sejam escaneados:
version: "2"
ondemand-ingest-pipeline:
source:
s3:
codec:
newline:
compression: "gzip"
scan:
start_time: 2023-12-28T01:00:00
end_time: 2023-12-31T09:00:00
buckets:
- bucket:
name: <bucket-name>
aws:
region: "us-east-1"
sts_role_arn: "arn:aws:iam::<acct num>:role/PipelineRole"
acknowledgments: true
processor:
- parse_json:
- date:
from_time_received: true
destination: "@timestamp"
sink:
- opensearch:
index: "logs_ondemand_20231231"
hosts: [ "https://search-XXXX-domain-XXXXXXXXXX.us-east-1.es.amazonaws.com" ]
aws:
sts_role_arn: "arn:aws:iam::<acct num>:role/PipelineRole"
region: "us-east-1"
Considerações
Aproveite a compressão
Os dados no Amazon S3 podem ser compactados, o que reduz os dados e resulta em economias de custo significativas. Por exemplo, se você estiver gerando 15 PB de registros brutos de aplicativos JSON por mês, poderá usar um mecanismo de compactação como o GZIP, que pode reduzir o tamanho para aproximadamente 1 PB ou menos, resultando em economias significativas.
Pare o pipeline quando possível
O OpenSearch Ingestion é escalado automaticamente entre as OCUs mínimas e máximas definidas para o pipeline. Depois que o pipeline concluir a verificação do Amazon S3 pela duração especificada mencionada na configuração do pipeline, o pipeline continua em execução para monitoramento contínuo nas OCUs mínimas.
Para a ingestão sob demanda de períodos anteriores em que você não espera que novos objetos sejam criados, considere usar métricas de pipeline compatíveis, como recordsOut.count para criar alarmes do Amazon CloudWatch que possam interromper o pipeline. Para ver uma lista de métricas compatíveis, consulte Métricas do pipeline de monitoramento.
Os alarmes do CloudWatch realizam uma ação quando uma métrica do CloudWatch excede um valor especificado por um determinado período de tempo. Por exemplo, talvez você queira monitorar recordsOut.count como 0 por mais de 5 minutos para iniciar uma solicitação para interromper o pipeline por meio da AWS Command Line Interface (AWS CLI) ou da API.
Solução 3: consultas diretas do OpenSearch Service com o Amazon S3
As consultas diretas do OpenSearch Service com o Amazon S3 (preview) são uma nova forma de consultar registros operacionais nos data lakes do Amazon S3 e do S3 sem precisar alternar entre os serviços. Agora você pode analisar dados consultados com pouca frequência em armazenamentos de objetos na nuvem e usar simultaneamente os recursos operacionais de análise e visualização do OpenSearch Service.
As consultas diretas do OpenSearch Service com o Amazon S3 oferecem integração sem ETL para reduzir a complexidade operacional da duplicação de dados ou do gerenciamento de várias ferramentas de análise, permitindo que você consulte diretamente seus dados operacionais, reduzindo os custos e o tempo de ação. Essa integração sem ETL é configurável no OpenSearch Service, onde você pode aproveitar vários modelos de tipos de log, incluindo painéis predefinidos, e configurar acelerações de dados personalizadas para esse tipo de log. Os modelos incluem registros de fluxo de VPC, registros do Elastic Load Balancing e registros do NGINX, e as acelerações incluem ignorar índices, visualizações materializadas e índices cobertos.
Com as consultas diretas do OpenSearch Service com o Amazon S3, você pode realizar consultas complexas que são essenciais para a análise forense de segurança e de ameaças e correlacionar dados em várias fontes de dados, o que ajuda as equipes a investigar o tempo de inatividade do serviço e os eventos de segurança. Depois de criar uma integração, você pode começar a consultar seus dados diretamente dos painéis do OpenSearch ou da API do OpenSearch. Você pode auditar as conexões para garantir que elas sejam configuradas de forma escalável, econômica e segura.
As consultas diretas do OpenSearch Service para o Amazon S3 usam tabelas do Spark no catálogo de dados do AWS Glue. Depois que a tabela for catalogada em seu catálogo de metadados do AWS Glue, você poderá executar consultas diretamente nos seus dados no seu data lake do S3 por meio dos painéis do OpenSearch.
Visão geral da solução
O diagrama a seguir ilustra a arquitetura da solução.
Essa solução consiste nos seguintes componentes principais:
- Os dados ativos do dia atual são transmitidos e processados em domínios do OpenSearch Service por meio do padrão de arquitetura orientado a eventos usando o recurso de processamento OpenSearch Ingestion S3-SQS
- O ciclo de vida dos dados ativos é gerenciado por meio de políticas do ISM anexadas aos índices diários
- Os dados frios residem em seu bucket do Amazon S3 e são particionados e catalogados
A captura de tela a seguir mostra um exemplo de tabela http_logs que está catalogada no catálogo de metadados do AWS Glue. Para obter etapas detalhadas, consulte o catálogo de dados e os crawlers no AWS Glue.
Antes de criar uma fonte de dados, você deve ter um domínio do OpenSearch Service com a versão 2.11 ou posterior e uma tabela S3 de destino no catálogo de dados do AWS Glue com as permissões apropriadas do AWS Identity and Access Management (IAM). O IAM precisará acessar os buckets S3 desejados e ter acesso de leitura e gravação ao catálogo de dados do AWS Glue. Veja a seguir um exemplo de função e política de confiança com as permissões apropriadas para acessar o catálogo de dados do AWS Glue por meio do OpenSearch Service:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "directquery.opensearchservice.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Veja a seguir um exemplo de política personalizada com acesso ao Amazon S3 e ao AWS Glue:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:*:<acct_num>:domain/*"
},
{
"Sid": "Statement2",
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*",
"s3:Put*",
"s3:Describe*"
],
"Resource": [
"arn:aws:s3:::<bucket-name>",
"arn:aws:s3:::<bucket-name>/*"
]
},
{
"Sid": "GlueCreateAndReadDataCatalog",
"Effect": "Allow",
"Action": [
"glue:GetDatabase",
"glue:CreateDatabase",
"glue:GetDatabases",
"glue:CreateTable",
"glue:GetTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTables",
"glue:GetPartition",
"glue:GetPartitions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:GetUserDefinedFunctions"
],
"Resource": [
"arn:aws:glue:us-east-1:<acct_num>:catalog",
"arn:aws:glue:us-east-1:<acct_num>:database/*",
"arn:aws:glue:us-east-1:<acct_num>:table/*"
]
}
]
}
Para criar uma nova fonte de dados no console do OpenSearch Service, forneça o nome da sua nova fonte de dados, especifique o tipo de fonte de dados como Amazon S3 com o AWS Glue Data Catalog e escolha a função do IAM para sua fonte de dados.
Depois de criar uma fonte de dados, você pode acessar o painel do OpenSearch do domínio, que você usa para configurar o controle de acesso, definir tabelas, configurar painéis baseados em tipos de log para tipos de log populares e consultar seus dados.
Depois de configurar suas tabelas, você pode consultar seus dados em seu data lake do S3 por meio dos painéis do OpenSearch. Você pode executar um exemplo de consulta SQL para a tabela http_logs que você criou nas tabelas do AWS Glue Data Catalog, conforme mostrado na captura de tela a seguir.
Melhores práticas
Faça a ingestão somente dos dados de que você precisa
Trabalhe retroativamente de acordo com suas necessidades comerciais e estabeleça os conjuntos de dados certos de que você precisará. Avalie se você pode evitar a ingestão de dados ruidosos e ingerir somente dados selecionados, amostrados ou agregados. O uso desses conjuntos de dados limpos e organizados ajudará você a otimizar os recursos de computação e armazenamento necessários para ingerir esses dados.
Reduza o tamanho dos dados antes da ingestão
Ao projetar seus pipelines de ingestão de dados, use estratégias como compactação, filtragem e agregação para reduzir o tamanho dos dados ingeridos. Isso permitirá que tamanhos de dados menores sejam transferidos pela rede e armazenados em sua camada de dados.
Conclusão
Neste post, discutimos soluções que permitem a análise de registros em escala de petabytes usando o OpenSearch Service em uma arquitetura de dados moderna. Você aprendeu a criar um pipeline de ingestão sem servidor para entregar registros a um domínio do OpenSearch Service, gerenciar índices por meio de políticas do ISM, configurar as permissões do IAM para começar a usar o OpenSearch Ingestion e criar a configuração do pipeline para dados em seu data lake. Você também aprendeu a configurar e usar as consultas diretas do OpenSearch Service com o recurso Amazon S3 (em “preview” no momento de escrita deste blog) para consultar dados do seu data lake.
Para escolher o padrão de arquitetura certo para suas cargas de trabalho ao usar o OpenSearch Service em grande escala, considere o desempenho, a latência, o custo e o crescimento do volume de dados ao longo do tempo para tomar a decisão certa.
- Use a arquitetura de armazenamento hierárquico com políticas de gerenciamento do estado do índice quando precisar de acesso rápido aos seus dados ativos e quiser equilibrar o custo e o desempenho com os nós UltraWarm para dados somente para leitura.
- Use a ingestão sob demanda de seus dados no OpenSearch Service quando você pode tolerar latências de ingestão para consultar seus dados não retidos em seus hot nodes. Você pode obter economias de custo significativas ao usar dados compactados no Amazon S3 e ingerir dados sob demanda no OpenSearch Service.
- Use o recurso Consulta direta com S3 quando quiser analisar diretamente seus registros operacionais no Amazon S3 com os recursos avançados de análise e visualização do OpenSearch Service.
Como próxima etapa, consulte o Amazon OpenSearch Developer Guide para explorar logs e pipelines métricos que você pode usar para criar uma solução de observabilidade escalável para seus aplicativos corporativos.
Este conteúdo é uma tradução do blog original em inglês (Link aqui).
Sobre os autores
 |
Jagadish Kumar (Jag) é arquiteto sênior de soluções especializado na AWS com foco no Amazon OpenSearch Service. Ele é profundamente apaixonado pela arquitetura de dados e ajuda os clientes a criar soluções de análise em grande escala na AWS. |
 |
Muthu Pitchaimani é arquiteto sênior de soluções especializado no Amazon OpenSearch Service. Ele cria aplicativos e soluções de pesquisa em grande escala. Muthu se interessa pelos tópicos de rede e segurança e mora em Austin, Texas. |
 |
Sam Selvané o principal arquiteto especialista em soluções do Amazon OpenSearch Service.
|
Sobre o tradutor
 |
Eduardo Pereira é Arquiteto de Soluções. Atua ajudando clientes do setor Enterprise durante a sua jornada na nuvem da AWS. Tem grande interesse na área de Analytics, observabilidade e serverless. |