Implement multi-tenant search with Amazon OpenSearch Serverless subsequent era

Learn to implement cost-effective multi-tenant search utilizing Amazon OpenSearch Serverless next-generation structure with scale-to-zero compute and simplified routing by means of per-account, regional endpoints.

Constructing multi-tenant search architectures requires balancing knowledge isolation with operational price and complexity. On this submit, we offer code examples for an implementation of multi-tenant search utilizing a collection-per-tenant mannequin with Amazon OpenSearch Serverless per-account, regional endpoints. Assortment-per-tenant gives knowledge and workload isolation. The regional endpoint simplifies routing requests for indexing and looking knowledge.

Amazon OpenSearch Serverless is a serverless deployment choice for Amazon OpenSearch Service that simplifies infrastructure administration, index tuning, and knowledge lifecycle administration. OpenSearch Serverless routinely provisions and scales assets to offer persistently quick knowledge ingestion charges and millisecond question response instances throughout altering utilization patterns and utility demand.

The multi-tenant search downside

In search workloads, a tenant is a logical unit of knowledge and the queries in opposition to that knowledge. An eCommerce website has product classes. Every class is a tenant. A blog-hosting platform has blogs. Every weblog is a tenant. Tenants map to assets in numerous methods. Within the siloed mannequin, every tenant will get its personal container: a site, assortment, or index. Within the pooled mannequin, tenants share a container. The hybrid mannequin silos giant tenants and swimming pools smaller ones collectively. No matter mannequin, you want a mapping between tenant identifiers and the containers that maintain their knowledge, so your utility routes requests appropriately.

OpenSearch Serverless basic supplied a collection-per-tenant technique that simplified, however didn’t take away, the necessity for sustaining a tenant-container mapping. As well as, the price construction of sustaining collection-per-tenant in basic was not best. Basic shared {hardware} throughout collections with the identical AWS Key Administration Service (AWS KMS) key. Tenants with completely different keys couldn’t share {hardware}. The price of the answer was the minimal month-to-month assortment price multiplied by the tenant rely. Constructing for a whole lot or hundreds of tenants was cost-prohibitive. Assortment teams improved this by permitting {hardware} sharing throughout AWS KMS keys, however compute prices had been nonetheless pushed by your listed knowledge, even throughout idle durations.

With the next-generation structure, assortment teams scale compute to zero. You pay for compute solely when a tenant is actively indexing or looking (storage expenses nonetheless apply). The addition of the regional endpoint additional simplifies multi-tenant workloads by routing visitors to any assortment by means of a single hostname. Collectively, scale-to-zero compute and the regional endpoint make the collection-per-tenant mannequin each economically viable and operationally easy.

The OpenSearch Serverless per-account endpoint

OpenSearch Serverless subsequent era introduces a per-account, regional endpoint that serves all collections by means of a single hostname:

https://.aoss..on.aws

The x-amz-aoss-collection-name or x-amz-aoss-collection-id header identifies the goal assortment on every request. This implies one connection pool, one TLS session, and one endpoint to handle no matter what number of collections you might have.

From a shopper perspective, you create a single OpenSearch shopper pointed on the regional endpoint and route requests by setting a header:

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,
    )

Each subsequent request contains the routing header to focus on a selected assortment:

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

This can be a vital enchancment over the basic structure, the place every assortment had its personal endpoint and also you wanted to handle separate connections for every.

Assortment per tenant with question routing

The structure is simple: one assortment group holds all tenant collections, and the regional endpoint handles routing.

Create a set group with scale-to-zero

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

Once you set minIndexingCapacityInOCU and minSearchCapacityInOCU to 0, OpenSearch Serverless scales down your compute to 0 OpenSearch Compute Models (OCUs) when they’re idle for 10 minutes. You pay just for the storage in your indices. If you wish to preserve compute and keep away from chilly begins, set minIndexingCapacityInOCU or minSearchCapacityInOCU to a price higher than 0.

Create one assortment per tenant

Every product class maps to its personal assortment throughout the group:

shopper.create_collection(
    identify=identify,
    sort="SEARCH",
    collectionGroupName=COLLECTION_GROUP_NAME,
)

When selecting a set identify in your tenants, think about privateness, identify size, and future ease of upgrading your utility. You should use a hash operate to map tenant identifiers to assortment names.

import hashlib

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

Assortment names are seen in API calls and logs. In case your tenant ID accommodates personally identifiable info (PII), that info can be seen in logs. Hashing the tenant ID obfuscates the delicate info.

OpenSearch Serverless has a 64-character restrict on assortment names. Your tenant ID might be longer than that. Hashing helps keep inside this restrict.

You may additionally wish to add a prefix to assortment names to be able to use wildcard patterns in entry insurance policies. For instance, naming collections pqa-a1b2c3d4 permits you to write a single knowledge entry coverage matching assortment/pqa-*. Together with a model element within the identify (similar to pqa-v2-a1b2c3d4) makes it easy to create new collections throughout schema migrations with out disrupting present tenants.

Index knowledge utilizing the regional endpoint

A single OpenSearch shopper handles all collections. The x-amz-aoss-collection-name header routes every request to the right assortment:

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)

Question a selected tenant’s knowledge

Looking works the identical means. Set the header to focus on the tenant’s assortment:

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

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

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

The applying layer maps a tenant ID (on this case, a product class) to a set identify, and the regional endpoint handles the remaining. No connection pool administration, no endpoint lookups, no per-tenant shopper situations.

Limitations

There are sensible constraints to contemplate when adopting this sample.

Chilly begin latency. When a set group has scaled to zero compute, the primary request takes roughly 10 seconds whereas capability provisions. For latency-sensitive tenants, you’ll be able to ship a light-weight warmup question (similar to a match_all with measurement=1) earlier than manufacturing visitors arrives.

Assortment group limits. There are account-level limits on the variety of collections and assortment teams. Examine the Amazon OpenSearch Serverless quotas for present numbers if you’re planning hundreds of tenants.

Safety coverage measurement. Encryption, community, and knowledge entry insurance policies record assortment useful resource patterns. As a result of tenant rely grows, these coverage paperwork develop linearly. Use wildcard patterns to remain inside OpenSearch Serverless coverage measurement limits.

No cross-collection queries. Every search request targets precisely one assortment. If it’s essential to question throughout tenants for analytics or world search, you want an aggregation layer or a separate shared assortment.

Conclusion

On this submit, we confirmed how the next-generation OpenSearch Serverless structure makes the collection-per-tenant mannequin sensible for multi-tenant search. Scale-to-zero reduces the minimal price for inactive tenants, becoming the compute assets to the calls for of tenants. The regional endpoint eliminates the operational complexity of managing per-tenant connections. You get full knowledge isolation between tenants, unbiased scaling for every tenant’s workload, and a single endpoint to handle in your utility code.

For extra info, see the Amazon OpenSearch Serverless documentation.

In regards to the writer