O blog da AWS
Use o Amazon OpenSearch Ingestion para migrar para o Amazon OpenSearch Serverless
Por Muthu Pitchaimani, Prashant Agrawal e Rahul Sharma
O Amazon OpenSearch Serverless é uma configuração de escalabilidade automática sob demanda para o Amazon OpenSearch Service. Desde seu lançamento, o interesse pelo OpenSearch Serverless não parava de crescer. Os clientes preferem permitir que o serviço gerencie sua capacidade automaticamente, em vez de precisar provisionar a capacidade manualmente. Até agora, os clientes dependiam do uso de código personalizado ou soluções de terceiros para mover os dados entre os domínios provisionados do OpenSearch Service e o OpenSearch Serverless.
Recentemente, introduzimos um recurso com o Amazon OpenSearch Ingestion (OSI) para tornar essa migração ainda mais fácil. O OSI é um coletor de dados totalmente gerenciado e sem servidor que fornece dados de registro, métricas e rastreamento em tempo real para domínios do OpenSearch Service e coleções do OpenSearch Serverless.
Neste post, descrevemos as etapas para fazer a migração dos dados entre os domínios provisionados do OpenSearch Service e o OpenSearch Serverless. A migração de metadados, como funções de segurança e objetos do painel, será abordada em outra postagem subsequente.
Visão geral da solução
O diagrama a seguir mostra os componentes necessários para mover dados entre os domínios provisionados do OpenSearch Service e o OpenSearch Serverless usando OSI. Você usará o OSI com o OpenSearch Service como fonte e uma coleção OpenSearch Serverless como coletor.
Pré-requisitos
Antes de começar, conclua as etapas a seguir para criar os recursos necessários:
-
-
- Crie uma função do AWS Identity and Access Management (IAM) que o pipeline de ingestão do OpenSearch assumirá para gravar na coleção OpenSearch Serverless. Essa função precisa ser especificada no parâmetro sts_role_arn da configuração do pipeline.
- Anexe uma política de permissões na função para permitir que ela leia dados do domínio do OpenSearch Service. Veja a seguir um exemplo de política com menos privilégios:
-
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"es:ESHttpGet",
"Resource":[
"arn:aws:es:us-east-1:{account-id}:domain/{domain-name}/",
"arn:aws:es:us-east-1:{account-id}:domain/{domain-name}/_cat/indices",
"arn:aws:es:us-east-1:{account-id}:domain/{domain-name}/_search",
"arn:aws:es:us-east-1:{account-id}:domain/{domain-name}/_search/scroll",
"arn:aws:es:us-east-1:{account-id}:domain/{domain-name}/*/_search"
]
},
{
"Effect":"Allow",
"Action":"es:ESHttpPost",
"Resource":[
"arn:aws:es:us-east-1:{account-id}:domain/{domain-name}/*/_search/point_in_time",
"arn:aws:es:us-east-1:{account-id}:domain/{domain-name}/*/_search/scroll"
]
},
{
"Effect":"Allow",
"Action":"es:ESHttpDelete",
"Resource":[
"arn:aws:es:us-east-1:{account-id}:domain/{domain-name}/_search/point_in_time",
"arn:aws:es:us-east-1:{account-id}:domain/{domain-name}/_search/scroll"
]
}
]
}
- Anexe uma política de permissões na função para permitir que ela envie dados para a coleção. Veja a seguir um exemplo de política com menos privilégios:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"aoss:BatchGetCollection",
"aoss:APIAccessAll"
],
"Effect": "Allow",
"Resource": "arn:aws:aoss:{region}:{your-account-id}:collection/{collection-id}"
},
{
"Action": [
"aoss:CreateSecurityPolicy",
"aoss:GetSecurityPolicy",
"aoss:UpdateSecurityPolicy"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"aoss:collection": "{collection-name}"
}
}
}
]
}
-
- Configure a função para assumir a relação de confiança, da seguinte forma:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "osis-pipelines.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
-
- É recomendável adicionar as chaves de condição aws:sourceAccount e aws:sourceArn na política para proteção contra o problema do substituto confuso (“confused deputy”):
"Condition": {
"StringEquals": {
"aws:SourceAccount": "{your-account-id}"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:osis:{region}:{your-account-id}:pipeline/*"
}
}
- Mapeie o ARN da função de domínio do OpenSearch Ingestion como usuário de back-end (como usuário all_access) para o usuário do domínio. Mostramos um exemplo simplificado para usar a função all_access. Para cenários de produção, certifique-se de usar uma função com permissões suficientes para apenas ler e escrever.
-
- Crie uma coleção OpenSearch Serverless, que é onde os dados serão ingeridos.
- Associe uma política de dados, conforme mostrado no código a seguir, para conceder permissões ao papel de Ingestão do OpenSearch na coleção:
[
{
"Rules": [
{
"Resource": [
"index/collection-name/*"
],
"Permission": [
"aoss:CreateIndex",
"aoss:UpdateIndex",
"aoss:DescribeIndex",
"aoss:WriteDocument",
],
"ResourceType": "index"
}
],
"Principal": [
"arn:aws:iam::{account-id}:role/pipeline-role"
],
"Description": "Pipeline role access"
}
]
- Se a coleção for definida como uma coleção em VPC, você precisará criar uma política de rede e configurá-la no pipeline de ingestão.
Agora você está pronto para mover dados do seu domínio provisionado para o OpenSearch Serverless.
Mova dados de domínios provisionados para o Serverless
Configurar o Amazon OpenSearch IngestionPara começar, você deve ter um domínio ativo do serviço do OpenSearch (fonte) e uma coleção no OpenSearch Serverless (coletor). Conclua as etapas a seguir para configurar um pipeline de ingestão para migração:
- No console do OpenSearch Service, escolha Pipeline em Ingestion no painel de navegação.
- Escolha Create a pipeline.
- Em Pipeline name, insira um nome (por exemplo, octank-migration).
- Para Pipeline Capacity, você pode definir a capacidade mínima e máxima para escalar os recursos. Por enquanto, você pode deixar o mínimo padrão como 1 e o máximo como 4.
- Para Configuration Blueprint, selecione AWS-OpenSearchDataMigrationPipeline.
- Atualize as seguintes informações para a fonte:
- Remova os comentários em hosts e especifique o endpoint do OpenSearch Service existente.
- Descomente distribution_version se seu cluster de origem for um cluster do OpenSearch com o modo de compatibilidade ativado; caso contrário, deixe o comentário.
- Descomente indices, include, index_name_regex e adicione um nome ou padrão de índice que você deseja migrar (por exemplo, octank-iot-logs-2023.11.0*).
- Atualize region em aws onde está seu domínio de origem (por exemplo, us-west-2 ).
- Atualize sts_role_arn em aws para a função que tem permissão para ler dados do domínio do OpenSearch Service (por exemplo, arn:aws:iam::111122223333:role/osis-pipeline). Essa função deve ser adicionada como uma função de back-end nas funções de segurança do OpenSearch.
- Atualize as seguintes informações para o coletor:
- Remova os comentários em hosts e especifique o endpoint do OpenSearch Service existente.
- Atualize sts_role_arn em aws para a função que tem permissão para gravar dados na coleção do OpenSearch Serverless (por exemplo, arn:aws:iam::111122223333:role/osis-pipeline). Essa função deve ser adicionada como parte da política de acesso a dados na coleção OpenSearch Serverless.
- Atualize a flag serverless para true.
- Para índice, você pode deixá-lo como padrão, o que obterá os metadados do índice de origem e gravará com o mesmo nome no destino das fontes. Como alternativa, se você quiser ter um nome de índice diferente no destino, modifique esse valor com o nome desejado.
- Para document_id, você pode obter o ID dos metadados do documento na origem e usá-lo no destino. Observe que IDs de documentos personalizados são compatíveis somente com o tipo de coleção SEARCH; se você tiver sua coleção como TIMESERIES ou VECTORSEARCH, você deve comentar esta linha.
- Em seguida, você pode validar seu pipeline para verificar a conectividade da fonte e do coletor para garantir que o endpoint exista e esteja acessível.
- Para Network Setting, escolha sua configuração preferida:
- Escolha o VPC access e selecione sua VPC, sub-rede e grupo de segurança para configurar o acesso de forma privada.
- Escolha Public para ter o acesso público. A AWS recomenda que você use um VPC endpoint para todas os workloads de produção, mas neste passo a passo, selecione Public.
- Para a Log Publishing Option, você pode criar um novo grupo do Amazon CloudWatch ou usar um grupo existente do CloudWatch para escrever os logs de ingestão. Isso fornece acesso a informações sobre erros e avisos gerados durante a operação, o que pode ajudar na solução de problemas. Para este passo a passo, escolha Create new group.
- Escolha Next e verifique os detalhes que você especificou para as configurações do seu pipeline.
- Escolha Criar pipeline.
A criação do pipeline de ingestão deve levar alguns minutos.
O GIF a seguir mostra uma rápida demonstração da criação do pipeline de ingestão do OpenSearch usando as etapas anteriores.
Verifique os dados ingeridos na coleção OpenSearch Serverless de destino
Depois que o pipeline for criado e ativo, faça login no OpenSearch Dashboards da sua coleção no OpenSearch Serverless e execute o seguinte comando para listar os índices:
GET _cat/índices? v
O GIF a seguir mostra uma rápida demonstração da listagem dos índices antes e depois da ativação do pipeline.
Conclusão
Neste post, vimos como o OpenSearch Ingestion pode ingerir dados em uma coleção OpenSearch Serverless sem a necessidade de usar soluções de terceiros. Com a configuração mínima do produtor de dados, ele ingeriu automaticamente os dados para a nova coleção. O OSI também permite transformar ou reindexar os dados da versão ES7.x antes da ingestão em um domínio do OpenSearch Service ou coleção do OpenSearch Serverless. O OSI elimina a necessidade de provisionar, escalar ou gerenciar servidores. A AWS oferece vários recursos para você começar rapidamente a criar pipelines usando o OpenSearch Ingestion. Você pode usar várias integrações de pipeline incorporadas para ingerir rapidamente dados do Amazon DynamoDB, Amazon Managed Streaming for Apache Kafka (Amazon MSK), Amazon Security Lake, Fluent Bit e muito mais. Os esquemas de ingestão do OpenSearch a seguir permitem que você crie pipelines de dados com o mínimo de alterações na configuração.
Este conteúdo é uma tradução do blog original em inglês (Link aqui).
Sobre os autores
Muthu Pitchaimani is a Search Specialist with Amazon OpenSearch Service. He builds large-scale search applications and solutions. Muthu is interested in the topics of networking and security, and is based out of Austin, Texas. | |
Prashant Agrawal is a Sr. Search Specialist Solutions Architect with Amazon OpenSearch Service. He works closely with customers to help them migrate their workloads to the cloud and helps existing customers fine-tune their clusters to achieve better performance and save on cost. Before joining AWS, he helped various customers use OpenSearch and Elasticsearch for their search and log analytics use cases. When not working, you can find him traveling and exploring new places. In short, he likes doing Eat → Travel → Repeat. | |
Rahul Sharma is a Technical Account Manager at Amazon Web Services. He is passionate about the data technologies that help leverage data as a strategic asset and is based out of New York city, New York. |
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. |