OpenSearch Serverless NextGen: O que há de novo e como migrar do Classic

AWS lançou uma nova geração do OpenSearch Serverless. Se você está atualmente em coleções Classic, vale a pena entender o que realmente mudou antes de decidir se deve — e como — migrar.

O problema com o Classic

O OpenSearch Serverless Classic era uma ótima maneira de começar com o OpenSearch sem gerenciar o dimensionamento do cluster você mesmo. Mas tinha uma pegadinha cara: a capacidade mínima de indexação e pesquisa era fixa em 2 OCUs cada, independentemente de o seu índice estar fazendo algo ou não. (Uma OCU, ou Unidade de Cálculo do OpenSearch, é a unidade de cobrança que a AWS usa para capacidade de computação e memória serverless — você é cobrado por hora de OCU, independentemente de estar realmente processando algo.) Para uma carga de trabalho de produção sempre ativa, isso é um piso razoável. Para um ambiente de teste, um projeto paralelo ou qualquer coisa com tráfego intermitente ou esporádico, você está pagando um custo base constante 24/7 por capacidade que você está, na maior parte, não utilizando.

O que muda no NextGen

A principal novidade: o NextGen pode escalar para zero. Se nada está consultando ou indexando, você para de pagar por essa capacidade.

Há um verdadeiro trade-off a ser conhecido antes de migrar: escalar de zero não é instantâneo. Se sua capacidade de pesquisa escalou para zero, a primeira solicitação pode apresentar latência de dezena de segundos enquanto reinicia. Para desenvolvimento/teste, isso não é um problema. Para produção, você vai querer manter pelo menos 1 unidade de capacidade de pesquisa sempre ativa para que as consultas voltadas para o usuário nunca enfrentem um início frio — você ainda pode deixar a indexação escalar para zero se a ingestão for intermitente.

O lado positivo em relação ao escalonamento não é apenas o piso zero. A AWS relata que o NextGen escala aproximadamente 20x mais rápido que o Classic, em ambas as direções — reage mais rapidamente a picos de carga e também escala para baixo mais rapidamente, o que é o que realmente transforma "pode escalar para zero" em "gasta a maior parte do tempo em zero" em vez de ficar preso em uma capacidade mais alta devido ao tráfego residual.

O NextGen também permite que você defina capacidade mínima e máxima de forma independente para indexação e pesquisa. Assim, em vez de um único piso fixo se aplicando a ambos, você pode, por exemplo, deixar a indexação escalar para zero enquanto mantém um mínimo de 1 OCU na pesquisa — ou limitar a capacidade máxima de qualquer lado se você quiser um teto rígido sobre o custo, independentemente da carga.

Por que isso importa para o custo

Resumindo: você não está mais preso a pagar por um piso fixo de 2+2 OCUs, independentemente de precisar ou não. Você paga aproximadamente pelo que realmente usa. Isso é mais impactante para desenvolvimento, teste e qualquer ambiente com tráfego irregular ou intermitente — os casos exatos em que o mínimo fixo do Classic era mais difícil de justificar.

Se isso realmente vale a pena depende do seu padrão de tráfego, no entanto — um índice de produção consistentemente ocupado pode não ver muita diferença. Se você quiser uma visão rápida sobre se veria economias reais antes de se comprometer com uma migração, pode executar a ferramenta de varredura MCP Jungle Cleaner contra sua conta — ela analisa seu uso atual do OpenSearch Serverless e estima o que você economizaria ao mudar para o NextGen.

Por que a migração não é uma simples atualização

Não há um caminho de atualização in-loco. A geração de coleção (Classic vs. NextGen) é imutável no OpenSearch Serverless — você não pode alterar uma configuração em uma coleção existente. Você deve:

1. Criar um novo grupo de coleções NextGen, e então uma coleção dentro dele (com suas próprias políticas de acesso, rede e criptografia)
2. Copiar seus dados
3. Apontar seu aplicativo para o novo endpoint
4. Excluir a coleção Classic antiga assim que você confirmar que a migração funcionou

A AWS não fornece uma ferramenta de primeira parte para o passo 2. A recomendação deles para cópias entre coleções é configurar um pipeline de ingestão do OpenSearch — o que significa um papel IAM, uma política de acesso a dados, YAML do pipeline e sua própria capacidade de OCU, apenas para um trabalho de cópia único. Isso é muita infraestrutura para algo que você vai executar uma vez.

Configurando o novo grupo e coleção NextGen

Montamos um exemplo simples de stack — uma única Lambda conectando ao índice — mostrando como provisionar uma coleção NextGen com padrões sensatos (política de acesso, política de rede, política de criptografia): opensearch-nextgen.yaml. Se você estiver configurando isso com um agente de codificação, vale a pena apontá-lo para nosso modelo como um guia em vez de deixá-lo escrever as políticas do zero — os agentes costumam ter dificuldades com o NextGen porque seus dados de treinamento terminam antes que essas configurações existam, então eles vão buscar confiantes uma configuração da era Classic que não se aplica.

Migrando os dados

Uma vez que sua coleção NextGen exista e esteja funcionando, use nosso script de migração de código aberto para copiar tudo:

migrate-opensearch-classic-to-nextgen.py

Algumas coisas que vale a pena saber sobre como funciona:

• Sem _reindex. O Serverless não suporta _reindex com uma fonte remota, então o script copia documentos diretamente — abrindo um Ponto no Tempo no índice de origem, paginando com search_after, e escrevendo lotes via _bulk. Essa é a mesma abordagem fundamental que um pipeline de ingestão usa nos bastidores, menos a sobrecarga de configuração.
• É idempotente. Os documentos são escritos no destino com seu _id original, então reexecutar o script nunca cria duplicatas — ele apenas sobrescreve com conteúdo idêntico. Isso é importante na prática: se novos dados forem escritos na coleção antiga enquanto você estiver no meio da migração, você pode apontar seu aplicativo para a nova coleção e, em seguida, simplesmente executar o script novamente para pegar qualquer coisa que tenha chegado após sua primeira execução.
• Mapeamentos e analisadores também são copiados. Mapeamentos de campo personalizados e analisadores são copiados antes dos dados, para que o índice de destino não acabe com o OpenSearch adivinhando os tipos de campo por meio de mapeamento dinâmico.
• Falhas não interrompem a execução. Qualquer documento que falhe após uma nova tentativa é registrado em um arquivo separado em vez de abortar — um documento problemático não bloqueará a migração dos outros milhões.

Uso básico:

python3 migrate-opensearch-classic-to-nextgen.py \
  --source-collection-id <classic-collection-id> \
  --target-collection-id <existing-nextgen-collection-id> \
  --region us-east-1

Adicione --dry-run primeiro para ver contagens de índice e documento sem copiar nada.

Após a migração

Uma vez que você tenha transferido seu aplicativo para o endpoint NextGen e confirmado que o tráfego está fluindo corretamente, exclua a antiga coleção Classic assim que tiver certeza de que a migração foi bem-sucedida.