Implement multi-tenant search with Amazon OpenSearch Serverless subsequent technology

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 information isolation with operational value 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 information and workload isolation. The regional endpoint simplifies routing requests for indexing and looking out information.

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

The multi-tenant search drawback

In search workloads, a tenant is a logical unit of information and the queries in opposition to that information. 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 several methods. Within the siloed mannequin, every tenant will get its personal container: a website, 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 information, so your utility routes requests accurately.

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 ultimate. 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 value multiplied by the tenant depend. Constructing for lots of or 1000’s 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 information, even throughout idle intervals.

With the next-generation structure, assortment teams scale compute to zero. You pay for compute solely when a tenant is actively indexing or looking out (storage expenses nonetheless apply). The addition of the regional endpoint additional simplifies multi-tenant workloads by routing site 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 simple.

The OpenSearch Serverless per-account endpoint

OpenSearch Serverless subsequent technology 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’ve gotten.

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 consists of the routing header to focus on a selected assortment:

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

It is a important 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",
    technology="NEXTGEN",
    standbyReplicas="ENABLED",
    capacityLimits={
        "minIndexingCapacityInOCU": 0,
        "maxIndexingCapacityInOCU": 8,
        "minSearchCapacityInOCU": 0,
        "maxSearchCapacityInOCU": 8,
    },
)

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

Create one assortment per tenant

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

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

When selecting a set identify on your tenants, contemplate privateness, identify size, and future ease of upgrading your utility. You need to 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 comprises personally identifiable data (PII), that data can also be seen in logs. Hashing the tenant ID obfuscates the delicate data.

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

You may additionally need to add a prefix to assortment names as a way to use wildcard patterns in entry insurance policies. For instance, naming collections pqa-a1b2c3d4 enables you to write a single information entry coverage matching assortment/pqa-*. Together with a model element within the identify (similar to pqa-v2-a1b2c3d4) makes it simple to create new collections throughout schema migrations with out disrupting current tenants.

Index information utilizing the regional endpoint

A single OpenSearch shopper handles all collections. The x-amz-aoss-collection-name header routes every request to the proper 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 information

Looking out works the identical approach. 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 = {
    "dimension": 3,
    "question": {
        "match": {
            "question_text": "4k decision hdmi"
        }
    },
}

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

The appliance 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 cases.

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 may ship a light-weight warmup question (similar to a match_all with dimension=1) earlier than manufacturing site 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 1000’s of tenants.

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

No cross-collection queries. Every search request targets precisely one assortment. If you have 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 value 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 information isolation between tenants, impartial scaling for every tenant’s workload, and a single endpoint to handle in your utility code.

For extra data, see the Amazon OpenSearch Serverless documentation.

Concerning the creator