Implemente a pesquisa multilocatário com a próxima geração do Amazon OpenSearch Serverless

Saiba como implementar pesquisa multilocatário econômica usando a arquitetura de próxima geração sem servidor do Amazon OpenSearch com computação escalável até zero e roteamento simplificado por meio de endpoints regionais por conta.

A construção de arquiteturas de pesquisa multilocatários exige o equilíbrio do isolamento de dados com o custo operacional e a complexidade. Nesta postagem, fornecemos exemplos de código para uma implementação de pesquisa multilocatário usando um modelo de coleção por locatário com Amazon OpenSearch Serverless por conta, endpoints regionais. A coleta por locatário fornece isolamento de dados e carga de trabalho. O endpoint regional simplifica solicitações de roteamento para indexação e pesquisa de dados.

Amazon OpenSearch sem servidor é uma opção de implantação sem servidor para Serviço Amazon OpenSearch que simplifica o gerenciamento da infraestrutura, o ajuste do índice e o gerenciamento do ciclo de vida dos dados. O OpenSearch Serverless provisiona e dimensiona recursos automaticamente para fornecer taxas de ingestão de dados consistentemente rápidas e tempos de resposta de consulta em milissegundos durante mudanças nos padrões de uso e na demanda de aplicativos.

O problema de pesquisa multilocatário

Nas cargas de trabalho de pesquisa, um locatário é uma unidade lógica de dados e as consultas nesses dados. Um web site de comércio eletrônico possui categorias de produtos. Cada categoria é um inquilino. Uma plataforma de hospedagem de blogs possui blogs. Cada weblog é um inquilino. Os locatários mapeiam os recursos de diferentes maneiras. No modelo isolado, cada locatário obtém seu próprio contêiner: um domínio, uma coleção ou um índice. No modelo agrupado, os locatários compartilham um contêiner. O modelo híbrido isola grandes inquilinos e agrupa os menores. Independentemente do modelo, você precisa de um mapeamento entre os identificadores de locatário e os contêineres que contêm seus dados, para que seu aplicativo encaminhe as solicitações corretamente.

O OpenSearch Serverless clássico ofereceu uma estratégia de coleta por locatário que simplificou, mas não eliminou, a necessidade de manter um mapeamento locatário-contêiner. Além disso, a estrutura de custos de manutenção da cobrança por inquilino no clássico não period best. {Hardware} compartilhado clássico entre coleções com o mesmo Serviço de gerenciamento de chaves da AWS Chave (AWS KMS). Locatários com chaves diferentes não podiam compartilhar {hardware}. O custo da solução foi o custo mínimo de cobrança mensal multiplicado pelo número de inquilinos. Construir para centenas ou milhares de inquilinos tinha um custo proibitivo. Grupos de coleção melhorou isso permitindo o compartilhamento de {hardware} entre chaves AWS KMS, mas os custos de computação ainda eram impulsionados pelos dados indexados, mesmo durante períodos ociosos.

Com a arquitetura de próxima geração, os grupos de coleta dimensionam a computação para zero. Você paga pela computação somente quando um locatário está indexando ou pesquisando ativamente (ainda serão aplicadas taxas de armazenamento). A adição do endpoint regional simplifica ainda mais as cargas de trabalho multilocatários, roteando o tráfego para qualquer coleção por meio de um único nome de host. Juntos, a computação de escala zero e o endpoint regional tornam o modelo de coleta por locatário economicamente viável e operacionalmente simples.

O endpoint por conta do OpenSearch Serverless

A próxima geração do OpenSearch Serverless apresenta um endpoint regional por conta que atende todas as coleções por meio de um único nome de host:

https://.aoss..on.aws

O x-amz-aoss-collection-name ou x-amz-aoss-collection-id header identifica a coleção de destino em cada solicitação. Isso significa um pool de conexões, uma sessão TLS e um endpoint para gerenciar, independentemente de quantas coleções você tiver.

Da perspectiva do cliente, você cria um único cliente OpenSearch apontado para o endpoint regional e roteia solicitações definindo um cabeçalho:

def get_opensearch_client(account_id: str, area: str) -> OpenSearch:
    """Create an OpenSearch shopper utilizing the regional endpoint."""
    host = f"{account_id}.aoss.{area}.on.aws"
    auth = get_aws4auth(area)

    return OpenSearch(
        hosts=({"host": host, "port": 443}),
        http_auth=auth,
        use_ssl=True,
        verify_certs=True,
        connection_class=RequestsHttpConnection,
        timeout=60,
    )

Cada solicitação subsequente inclui o cabeçalho de roteamento para direcionar uma coleção específica:

headers = {"x-amz-aoss-collection-name": collection_name}

Esta é uma melhoria significativa em relação à arquitetura clássica, onde cada coleção tinha seu próprio endpoint e period necessário gerenciar conexões separadas para cada uma.

Coleta por locatário com roteamento de consulta

A arquitetura é simples: um grupo de coleções contém todas as coleções de locatários e o ponto ultimate regional trata do roteamento.

Crie um grupo de coleta com escala até zero

shopper.create_collection_group(
    title="amazon-pqa-cg",
    technology="NEXTGEN",
    standbyReplicas="ENABLED",
    capacityLimits={
        "minIndexingCapacityInOCU": 0,
        "maxIndexingCapacityInOCU": 8,
        "minSearchCapacityInOCU": 0,
        "maxSearchCapacityInOCU": 8,
    },
)

Quando você outline minIndexingCapacityInOCU e minSearchCapacityInOCU para 0, o OpenSearch Serverless reduz sua computação para 0 OpenSearch Compute Models (OCUs) quando elas ficam ociosas por 10 minutos. Você paga apenas pelo armazenamento de seus índices. Se você quiser manter a computação e evitar inicializações a frio, defina minIndexingCapacityInOCU ou minSearchCapacityInOCU para um valor maior que 0.

Crie uma coleção por locatário

Cada categoria de produto é mapeada para sua própria coleção dentro do grupo:

shopper.create_collection(
    title=title,
    kind="SEARCH",
    collectionGroupName=COLLECTION_GROUP_NAME,
)

Ao escolher um nome de coleção para seus locatários, considere a privacidade, o comprimento do nome e a facilidade futura de atualização do seu aplicativo. Você pode usar uma função hash para mapear identificadores de locatários para nomes de coleções.

import hashlib

def collection_name_for_tenant(tenant_id: str) -> str:
    """Generate an opaque assortment title from a tenant identifier."""
    return hashlib.sha256(tenant_id.encode()).hexdigest()(:16)

Os nomes das coleções ficam visíveis em chamadas e registros de API. Se o seu ID de inquilino contiver informações de identificação pessoal (PII), essas informações também estarão visíveis nos registos. O hash do ID do locatário ofusca as informações confidenciais.

OpenSearch Serverless tem um limite de 64 caracteres em nomes de coleções. Seu ID de locatário pode ser maior que isso. Hashing ajuda a permanecer dentro desse limite.

Talvez você também queira adicionar um prefixo aos nomes de coleções para poder usar padrões curinga em políticas de acesso. Por exemplo, nomear coleções pqa-a1b2c3d4 permite escrever uma única política de acesso a dados correspondente assortment/pqa-*. Incluir um componente de versão no nome (como pqa-v2-a1b2c3d4) simplifica a criação de novas coleções durante as migrações de esquema sem interromper os locatários existentes.

Indexar dados usando o endpoint regional

Um único cliente OpenSearch lida com todas as coleções. O x-amz-aoss-collection-name header roteia cada solicitação para a coleção correta:

headers = {"x-amz-aoss-collection-name": collection_name}

# Construct bulk request
motion = {"index": {"_index": index_name, "_id": doc("question_id")}}
batch.append(json.dumps(motion))
batch.append(json.dumps(doc))

# Ship bulk request routed to the goal assortment
physique = "n".be part of(batch) + "n"
resp = os_client.bulk(physique=physique, headers=headers)

Consultar os dados de um locatário específico

A pesquisa funciona da mesma maneira. Defina o cabeçalho para direcionar a coleção do locatário:

os_client = get_opensearch_client(account_id, area)
headers = {"x-amz-aoss-collection-name": collection_name}

question = {
    "dimension": 3,
    "question": {
        "match": {
            "question_text": "4k decision hdmi"
        }
    },
}

resp = os_client.search(index="questions", physique=question, headers=headers)

A camada de aplicação mapeia um ID de inquilino (neste caso, uma categoria de produto) para um nome de coleção, e o ponto ultimate regional trata do resto. Sem gerenciamento de pool de conexões, sem pesquisas de endpoint, sem instâncias de cliente por locatário.

Limitações

Existem restrições práticas a serem consideradas ao adotar esse padrão.

Latência de inicialização a frio. Quando um grupo de recolha é dimensionado para zero cálculo, o primeiro pedido demora aproximadamente 10 segundos enquanto a capacidade é provisionada. Para locatários sensíveis à latência, você pode enviar uma consulta de aquecimento leve (como uma match_all com dimension=1) antes da chegada do tráfego de produção.

Limites do grupo de coleta. Existem limites no nível da conta quanto ao número de coleções e grupos de coleções. Verifique o Cotas sem servidor do Amazon OpenSearch para números atuais se você estiver planejando milhares de inquilinos.

Tamanho da política de segurança. As políticas de criptografia, rede e acesso a dados listam padrões de recursos de coleta. Como o número de inquilinos aumenta, esses documentos de apólice crescem linearmente. Use padrões curinga para permanecer dentro Limites de tamanho da política OpenSearch Serverless.

Nenhuma consulta entre coleções. Cada solicitação de pesquisa tem como alvo exatamente uma coleção. Se precisar consultar locatários para análise ou pesquisa world, você precisará de uma camada de agregação ou de uma coleção compartilhada separada.

Conclusão

Nesta postagem, mostramos como a arquitetura OpenSearch Serverless de próxima geração torna o modelo de coleta por locatário prático para pesquisa multilocatário. A escalabilidade para zero reduz o custo mínimo para locatários inativos, adequando os recursos de computação às demandas dos locatários. O endpoint regional elimina a complexidade operacional do gerenciamento de conexões por locatário. Você obtém isolamento whole de dados entre locatários, dimensionamento independente para a carga de trabalho de cada locatário e um único endpoint para gerenciar no código do seu aplicativo.

Para obter mais informações, consulte o Documentação sem servidor do Amazon OpenSearch.

Sobre o autor