DEV Community: Rudney eduardo souza vieira

Migração de Elasticsearch para Opensearch na AWS

Rudney eduardo souza vieira — Fri, 13 Dec 2024 22:08:14 +0000

O que é o RFS

O RFS (Reindex from Snapshot) é um processo de migração de dados entre versões de Elasticsearch e Opensearch, ou até mesmo entre versões de Opensearch, que vem para facilitar o processo completo de migração, incluindo até mesmo um processo de proxy para migração in flight!

Iniciando o processo de migração

Para iniciar o processo de migração, é importante ter um setup preparado para evitar problemas durante a migração, para o começo é importante ter o cdk na conta configurado (o RFS utiliza bastante o cdk da AWS), e para isso segue o primeiro passo:

Para configurar o cdk, rodar no seu terminal local:

cdk bootstrap aws://id_da_conta/região_do_opensearch

Agora com o cdk configurado, é possivel continuar com o passo a passo, o próximo ponto importante é importar no cloudformation o template migration-assistant-for-amazon-opensearch-service.template (ele vai automaticamente para o cloudformation já com a stack), ponto para consideração ao subir a stack:

Se atentar ao stage que vai ser indicado ao Stack, ele vai ser utilizado em outros passos da migração!

Ao final do processo da stack, será criada uma EC2, assim que possível se conecte a ela via SSM, ao entrar na EC2 (algo do tipo bootstrap-instance-STAGE-REGION), rodar o seguinte comando:

sudo su
cd /opensearch-migrations #entrar na pasta correta para dar inicio ao bootstrap que ajudará na migração
./initBootstrap.sh && cd deployment/cdk/opensearch-service-migration

Esse processo geralmente, leva algo em torno de 15 minutos (é bem demorado, mas configura partes importantes a migração)

Agora, ao fim do processo, na pasta atual (opensearch-migrations/deployment/cdk/opensearch-service-migration) existe um arquivo cdk.context.json, ele é o responsável sobre como a migração vai se comportar (guia de configuração), para uma migração com o assistente via console, o arquivo deve ser parecido com algo do tipo a seguir :

{
    "NOME_DO_OBJETO_PRINCIPAL_DO_CDK_CONTEXT": {
      "stage": "STAGE",
      "targetCluster": {
        "endpoint": "TARGET_CLUSTER_URL",
        "auth": {
          "type": "sigv4",
          "region": "us-east-1",
          "serviceSigningName": "es"
        }
      },
      "sourceCluster": {
        "endpoint": "SOURCE_CLUSTER_URL",
        "version": "ES_7.1", 
        "auth": {
          "type": "sigv4",
          "region": "us-east-1",
          "serviceSigningName": "es"
        }
      },
      "vpcId": "VPC_ID",
      "reindexFromSnapshotServiceEnabled": true, //habilita o RFS
      "artifactBucketRemovalPolicy": "RETAIN", // ou DESTROY Após utilizar o snapshot de dados via s3, mantém os arquivos no bucket
      "migrationConsoleServiceEnabled": true, // assistente de migração ativo
      "migrationAssistanceEnabled": true, // assistente de migração ativo
      "reindexFromSnapshotExtraArgs": "--s3-repo-uri s3://migration-artifacts-ACCOUNT_ID-STAGE-REGION/rfs-snapshot-repo --s3-region REGION --snapshot-name rfs-snapshot",
      "managedServiceSourceSnapshotEnabled": true // Configuração para que seja possivel usar o comando de snapshot
    }
  }

OBS: Para substituir o arquivo, pode ser usado o seguinte comando:

vi cdk.context.json
# Dentro do arquivo usando o VIM, usar a seguinte combinação de teclas:
# g g D Shift G # após isso pressionar i (para entrar em modo de edição no Vim)
# assim todo o arquivo antigo sera apagado e será mais fácil de colar sua nova configuração

Após a nova configuração adicionada, será necessário rodar os comandos de bootstrap:

cdk bootstrap --c contextId=NOME_DO_OBJETO_PRINCIPAL_DO_CDK_CONTEXT
cdk deploy "*" --c contextId=NOME_DO_OBJETO_PRINCIPAL_DO_CDK_CONTEXT --require-approval never --concurrency 3

OBS2: É importante garantir que o arquivo cdk.context.json esteja devidamente configurado, de maneira que se não estiver, será um problema futuro na migração via RFS

Agora será iniciada a criação das stacks necessárias para rodar os comandos de migração de dados, após a finalização do último comando (lembre do stage configurado no cloudformation!):

./accessContainer.sh migration-console STAGE REGION

Rodando a migração - Etapa de verificação da configuração

Ao executar o comando mencionado acima, será redirecionado para o console do assistente de migração, onde o primeiro passo importante é executar:

console clusters connection-check #comando que checa a conexão com o cluster de source e de target

Se o comando retornar a conexão com sucesso, então é possível seguir para a criação do snapshot (Tome cuidado, pois a criação afeta diretamente o consumo de CPU do cluster de Source):

Criação do Snapshot

Agora para dar inicio ao snapshot:

#AFETA PERFORMANCE DO CLUSTER (Se for snapshot total do cluster ou parcial com maior parte dos indexes)
console snapshot create #inicia a criação do snapshot do cluster completo de source

# para criar apenas o snapshot de um index usar --index-allowlist index
# para checar o status do snapshot em progresso

console snapshot status --deep-check

OBS3: Antes de seguirmos, é importante que todos os shards do snapshot estejam completos!

O retorno do comando de status será algo do tipo (algumas informações podem estar discrepantes, mas é apenas um bug do terminal)

Ao finalizar a criação do snapshot, será possível iniciar o metadata migration (que é importante para migração prévia de metadados dos indexes e aliases do cluster de source):

console metadata evaluate # importante para checar se todos os indices vão ser migrados
console metadata migrate # migração de metadados | --index-allowlist index  # para migrar metadata de apenas um indice

Rodando a migração - Etapa de migração dos dados

Para darmos inicio à migração de dados é necessário executar o seguinte comando:

console backfill start # inicio da migração
#Para checar o status da migração:

console backfill status --deep-check
#Para escalar o número de tasks do ECS*:

console backfill scale NUM_DESEJADO_DE_TASKS

OBS*: Tome cuidado ao elevar o número de tasks, pois, a depender do número de data nodes e da capacidade do cluster de target, isso pode causar erro 429 no cluster e atrapalhar a migração por completo!

A migração via RFS não para sozinha ao finalizar todas as shards disponíveis no snapshot, para isso, é muito importante que seja parada via execução de comando humano, que segue abaixo:

console backfill stop
# caso precise pausar a migração
console backfill pause

Finalizando a migração - Limpando o ambiente

Agora que tudo foi concluído (tome cuidado e confira se todas as shards foram finalizadas com sucesso), chega ao fim a migração !

Para evitar gastos e limpar o ambiente, execute os seguintes passos, mas primeiro no console, fora da venv:

cdk destroy "*" --c contextId=NOME_DO_OBJETO_PRINCIPAL_DO_CDK_CONTEXT
# é necessário o aceite no console para remover!

Ao terminar a exclusão via cdk destroy, é necessário ir ao cloudformation e deletar a stack referente ao RFS!

Troubleshooting

Nessa seção será disponibilizados algumas maneiras de debuggar os possíveis erros da solução:

Erro de token ‘Too’ (Erro 429 Too many requests)
- Nesse caso é necessário regular a quantidade de documentos por bulk request da solução, pois, o cluster não está aguentando o número de requisições da solução
Erro de versão do cluster
- Será necessário criar novamente o cluster
Erro de conexão aos clusters
- Esse erro é interessante analizar a VPC que foi cadastrada no cdk.context.json, onde é necessário que os domínios estejam dentro da vpc (Ambos), se ao menos 1 dos domínios estiver fora da VPC, será necesário conceder acesso a ele com um NatGateway.
- Se ambos domínios estiverem fora da VPC, a solução do RFS cria uma VPC para uso, que possibilita o uso para o desenvolver da migração
Como rodar a solução após algum ajuste necessário no arquivo cdk.context.json ?
- Para tal sera necessário rodar novamente o comando:
- Onde será refeito o deploy de todas as stacks necessárias para a migração.

cdk deploy "*" --c contextId=NOME_DO_OBJETO_PRINCIPAL_DO_CDK_CONTEXT --require-approval never --concurrency 3

Erro de total de shards
- Para ajustar é necessário no domínio de target rodar o seguinte comando:

PUT /_cluster/settings
{
  "persistent": {
    "cluster.max_shards_per_node": NUM_DESEJADO
  }
}

Caso algum erro esteja fora deste guia:

Entre em contato com Rudney Eduardo Souza Vieira ou também abra uma issue direta no github do projeto do RFS (o projeto será migrado para utilizar k8s, então dependendo da data que você está lendo o guia serão necessários outros ajustes)

Keda in EKS

Rudney eduardo souza vieira — Sun, 21 Jan 2024 19:05:39 +0000

Keda on EKS allows for unparalleled scaling flexibility, where its easy configuration and strengths regarding infrastructure architecture will be demonstrated in this article

When to use Keda ?

Your AutoScalling cant handle event driven cenarios
Need to handle varying levels of traffic
Need to cara about costs in the EKS cluster

What problem Keda will solve in this case cenario ?

Event Driven requests to start new pods in eks
Manage to save costs in stand by pods

How to install keda in eks:

We can download it from here and apply it with:

kubectl apply -f keda-2.13.0-core.yaml

or just execute it like this

kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.13.0/keda-2.13.0-core.yaml

Making it work in EKS:

Then when it is installed we can go and make an sample Python App

import json
from fastapi import FastAPI
import boto3

#Sample Python App for getting queue messages

app = FastAPI()

def getQueue(queue: str):
    sqs = boto3.resource('sqs', region_name='')
    # Get the queue
    print(queue)
    queue = sqs.get_queue_by_name(QueueName='')
    QMessage = []
    for message in queue.receive_messages():
        QMessage.append(message.body)
        message.delete()
    return QMessage

@app.get("/getQueue")
def root(queue: str):
    returnList = getQueue(queue)
    return {"queue Message list": returnList}

@app.get("/ping")
def ping():
    return {"status": "ok"}

Now lets make an Deployment file for it:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: python-app
  namespace: keda
spec:
  selector:
    matchLabels:
      app: python-app
  replicas: 1
  template:
    metadata:
      labels:
        app: python-app
    spec:
      serviceAccount: keda-operator
      containers:
        - name: python-app
          image: ecr_url
          command: ["uvicorn"]
          args :  ["app.main:app", "--host", "0.0.0.0", "--port", "80"]
          resources:
            limits:
              cpu: "1"
              memory: "2Gi"
            requests:
              cpu: "1"
              memory: "2Gi"
          ports:
            - containerPort: 80

Then add the Service Account for permissions:

apiVersion: v1
kind: ServiceAccount
automountServiceAccountToken: true
metadata:
  labels:
    app.kubernetes.io/name: keda-operator
    app.kubernetes.io/part-of: keda-operator
    app.kubernetes.io/version: main
  name: keda-operator
  namespace: keda
  annotations:
   eks.amazonaws.com/role-arn:  arn:aws:iam::accountId:role/KedaSqsExecutionRole

And then add the scaled object for the SQS Queue and the Auth Trigger:

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-aws-credentials
  namespace: keda
spec:
  podIdentity:
    provider: aws-eks
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: aws-sqs-queue-scaledobject
  namespace: keda
spec:
  minReplicaCount: 0  #-> min pods that will be when there is smt in queue
  maxReplicaCount: 5 #-> max pods
  pollingInterval: 10 
  cooldownPeriod:  25 
  scaleTargetRef:
    name: python-app
  triggers:
  - type: aws-sqs-queue
    authenticationRef:
      name: keda-trigger-auth-aws-credentials
    metadata:
      queueURL: sqs_queue_url
      queueLength: "1"
      awsRegion: "aws_regiion"
      identityOwner: operator

Conclusion

Keda gives a lot of flexibility when event driven is needed, because of it various built in scalers, like in this article with AWS SQS, and could scale in various other cenarios, as example, with AWS DynamoDB, granting a cost friendly way to handle EKS needs to scale with your business.