Detta är ett gästblogginlägg skrivet tillsammans med Zack Rossman från Alcion.

Alcion, en säkerhets-först, AI-driven backup-as-a-service (BaaS)-plattform, hjälper Microsoft 365-administratörer att snabbt och intuitivt skydda data från cyberhot och oavsiktlig dataförlust. I händelse av dataförlust måste Alcions kunder söka i metadata för de säkerhetskopierade objekten (filer, e-postmeddelanden, kontakter, händelser och så vidare) för att välja specifika objektversioner för återställning. Alcion använder Amazon OpenSearch Service för att förse sina kunder med korrekt, effektiv och pålitlig sökfunktion i denna backupkatalog. Plattformen är multi-tenant, vilket innebär att Alcion kräver dataisolering och stark säkerhet för att säkerställa att hyresgäster bara kan söka i sin egen data.

OpenSearch Service är en helt hanterad tjänst som gör det enkelt att distribuera, skala och använda OpenSearch i AWS-molnet. OpenSearch är en Apache-2.0-licensierad sök- och analyssvit med öppen källkod, som består av OpenSearch (en sök-, analysmotor och vektordatabas), OpenSearch Dashboards (ett användargränssnitt för visualisering och verktyg) och plugins som tillhandahåller avancerade funktioner som företag. -säkerhet, avvikelsedetektering, observerbarhet, varning och mycket mer. Amazon OpenSearch Serverlös är ett serverlöst distributionsalternativ som gör det enkelt att använda OpenSearch utan att konfigurera, hantera och skala OpenSearch Service-domäner.

I det här inlägget delar vi hur antagandet av OpenSearch Serverless gjorde det möjligt för Alcion att möta deras skalkrav, minska deras driftskostnader och säkra sina hyresgästers data genom att upprätthålla hyresgästens isolering inom sin miljö med flera hyresgäster.

OpenSearch Service-hanterade domäner

För den första iterationen av deras sökarkitektur valde Alcion driftsättningsalternativet för hanterade domäner i OpenSearch Service och kunde lansera sin sökfunktion i produktion på mindre än en månad. För att möta sina krav på säkerhet, skala och hyresrätt lagrade de data för varje hyresgäst i ett dedikerat index och använde finkornig passerkontroll i OpenSearch Service för att förhindra dataläckor mellan hyresgäster. Allteftersom deras arbetsbelastning utvecklades, spårade Alcions ingenjörer användningen av OpenSearch-domänen via det medföljande amazoncloudwatch mätvärden, göra ändringar för att öka lagringsutrymmet och optimera sina beräkningsresurser.

Teamet på Alcion använde flera funktioner i OpenSearch Service-hanterade domäner för att förbättra sin operativa hållning. De introducerade indexalias, som ger ett enda aliasnamn för att komma åt (läsa och skriva) flera underliggande index. De konfigurerade också Index State Management (ISM)-policyer för att hjälpa dem att kontrollera sin datalivscykel genom att rulla över index baserat på indexstorlek. Tillsammans var ISM-policyerna och indexaliasen nödvändiga för att skala index för stora hyresgäster. Alcion används också indexmallar att definiera fragmenten per index (partitionering) av deras data för att automatisera deras datalivscykel och förbättra prestanda och stabilitet för deras domäner.

Följande arkitekturdiagram visar hur Alcion konfigurerade sina OpenSearch-hanterade domäner.

Följande diagram visar hur Microsoft 365-data indexerades till och frågades från klientspecifika index. Alcion implementerade autentisering av begäran genom att tillhandahålla OpenSearchs primära användaruppgifter med varje API-begäran.

OpenSearch Serverlös översikt och alternativ för hyresmodeller

OpenSearch Service-hanterade domäner gav en stabil grund för Alcions sökfunktionalitet, men teamet behövde manuellt tillhandahålla resurser till domänerna för deras högsta arbetsbelastning. Detta lämnade utrymme för kostnadsoptimeringar eftersom Alcions arbetsbelastning är sprängfylld – det finns stora variationer i antalet sök- och indexeringstransaktioner per sekund, både för en enskild kund och som helhet. För att minska kostnader och operativ börda vände sig teamet till OpenSearch Serverless, som erbjuder automatisk skalning.

För att använda OpenSearch Serverless är det första steget att skapa en samling. A samling är en grupp av OpenSearch-index som arbetar tillsammans för att stödja en specifik arbetsbelastning eller användningsfall. Beräkningsresurserna för en samling, som kallas OpenSearch Compute Units (OCU), delas mellan alla samlingar i ett konto som delar en krypteringsnyckel. Poolen av OCU skalas automatiskt upp och ner för att möta kraven på indexering och söktrafik.

Ansträngningsnivån som krävdes för att migrera från en OpenSearch Service-hanterad domän till OpenSearch Serverless var hanterbar tack vare det faktum att OpenSearch Serverless-samlingar stöder samma OpenSearch API:er och bibliotek som OpenSearch Service-hanterade domäner. Detta gjorde det möjligt för Alcion att fokusera på att optimera hyresmodellen för den nya sökarkitekturen. Specifikt behövde teamet bestämma hur de skulle partitionera hyresgästdata inom samlingar och index samtidigt som säkerhet och totala ägandekostnader balanserades. Alcions ingenjörer, i samarbete med OpenSearch Serverless-teamet, övervägt tre hyresmodeller:

• Silomodell: Skapa en samling för varje hyresgäst
• Poolmodell: Skapa en enda samling och använd ett enda index för flera hyresgäster
• Bromodell: Skapa en enda samling och använd ett enda index per hyresgäst

Alla tre designvalen hade fördelar och avvägningar som måste beaktas för att utforma den slutliga lösningen.

Silomodell: Skapa en samling för varje hyresgäst

I den här modellen skulle Alcion skapa en ny kollektion när en ny kund gick ombord på deras plattform. Även om hyresgästdata skulle vara rent separerade mellan samlingar, diskvalificerades det här alternativet eftersom samlingens skapandetid innebar att kunderna inte skulle kunna säkerhetskopiera och söka efter data direkt efter registrering.

Poolmodell: Skapa en enda samling och använd ett enda index för flera hyresgäster

I den här modellen skulle Alcion skapa en enda samling per AWS-konto och indexera hyresgästspecifika data i ett av många delade index som tillhör den samlingen. Inledningsvis var det attraktivt att samla hyresgästdata till delade index ur ett skalperspektiv eftersom detta ledde till den mest effektiva användningen av indexresurser. Men efter ytterligare analys fann Alcion att de skulle ligga väl inom indexkvoten per samling även om de tilldelade ett index för varje hyresgäst. Med det skalbarhetsproblemet löst, valde Alcion det tredje alternativet eftersom att silo hyresgästdata till dedikerade index resulterar i starkare hyresgästisolering än den delade indexmodellen.

Bromodell: Skapa en enda samling och använd ett enda index per hyresgäst

I den här modellen skulle Alcion skapa en enda samling per AWS-konto och skapa ett index för var och en av de hundratals hyresgäster som hanteras av det kontot. Genom att tilldela varje hyresgäst ett dedikerat index och slå samman dessa index i en enda samling, minskade Alcion introduktionstiden för nya hyresgäster och släpade hyresgästdata i rent separerade hinkar.

Implementera rollbaserad åtkomstkontroll för att stödja multi-tenancy

OpenSearch Serverless erbjuder en flerpunkts, ärftlig uppsättning säkerhetskontroller som täcker dataåtkomst, nätverksåtkomst och kryptering. Alcion drog full nytta av OpenSearch Serverless dataåtkomstpolicyer att implementera rollbaserad åtkomstkontroll (RBAC) för varje hyresgästspecifikt index med följande detaljer:

• Tilldela ett index med ett gemensamt prefix och klient-ID (t.ex. index-v1-<tenantID>)
• Skapa en dedikerad AWS identitets- och åtkomsthantering (IAM) roll som används för att signera förfrågningar till OpenSearch Serverless-samlingen
• Skapa en OpenSearch Serverlös dataåtkomstpolicy som ger dokument läs/skrivbehörigheter inom ett dedikerat klientindex till IAM-rollen för den klienten
• OpenSearch API-förfrågningar till ett klientindex är signerade med tillfälliga referenser som tillhör den klientspecifika IAM-rollen

Följande är ett exempel på OpenSearch Serverless dataåtkomstpolicy för en falsk hyresgäst med ID t-eca0acc1-12345678910. Denna policy ger IAM-rolldokumentet läs-/skrivåtkomst till den dedikerade hyresgästen.

[ { "Rules": [ { "Resource": [ "index/collection-searchable-entities/index-v1-t-eca0acc1-12345678910" ], "Permission": [ "aoss:ReadDocument", "aoss:WriteDocument", ], "ResourceType": "index" } ], "Principal": [ "arn:aws:iam::12345678910:role/OpenSearchAccess-t-eca0acc1-1b9f-4b3f-95d6-12345678910" ], "Description": "Allow document read/write access to OpenSearch index belonging to tenant t-eca0acc1-1b9f-4b3f-95d6-12345678910" }
] 

Följande arkitekturdiagram visar hur Alcion implementerade indexering och sökning efter Microsoft 365-resurser med OpenSearch Serverless delad samlingsmetod.

Följande är exempelkodavsnittet för att skicka en API-begäran till en OpenSearch Serverless-samling. Lägg märke till hur API-klienten initieras med ett signeringsobjekt som signerar förfrågningar med samma IAM-princip som är länkad till OpenSearch Serverless dataåtkomstpolicy från det tidigare kodavsnittet.

package alcion import ( "context" "encoding/json" "strings" "github.com/aws/aws-sdk-go-v2/aws" "github.com/aws/aws-sdk-go-v2/config" "github.com/aws/aws-sdk-go-v2/credentials/stscreds" "github.com/aws/aws-sdk-go-v2/service/sts" "github.com/opensearch-project/opensearch-go/v2" "github.com/opensearch-project/opensearch-go/v2/opensearchapi" "github.com/opensearch-project/opensearch-go/v2/signer" awssignerv2 "github.com/opensearch-project/opensearch-go/v2/signer/awsv2" "github.com/pkg/errors"
) const ( // Scope the API request to the AWS OpenSearch Serverless service aossService = "aoss" // Mock values indexPrefix = "index-v1-" collectionEndpoint = "<https://kfbr3928z4y6vot2mbpb.us-east-1.aoss.amazonaws.com>" tenantID = "t-eca0acc1-1b9f-4b3f-95d6-b0b96b8c03d0" roleARN = "arn:aws:iam::1234567890:role/OpenSearchAccess-t-eca0acc1-1b9f-4b3f-95d6-b0b96b8c03d0"
) func CreateIndex(ctx context.Context, tenantID string) (*opensearchapi.Response, error) { sig, err := createRequestSigner(ctx) if err != nil { return nil, errors.Wrapf(err, "error creating new signer for AWS OSS") } cfg := opensearch.Config{ Addresses: []string{collectionEndpoint}, Signer: sig, } aossClient, err := opensearch.NewClient(cfg) if err != nil { return nil, errors.Wrapf(err, "error creating new OpenSearch API client") } body, err := getSearchBody() if err != nil { return nil, errors.Wrapf(err, "error getting search body") } req := opensearchapi.SearchRequest{ Index: []string{indexPrefix + tenantID}, Body: body, } return req.Do(ctx, aossClient)
} func createRequestSigner(ctx context.Context) (signer.Signer, error) { awsCfg, err := config.LoadDefaultConfig(ctx) if err != nil { return nil, errors.Wrapf(err, "error loading default config") } stsClient := sts.NewFromConfig(awsCfg) provider := stscreds.NewAssumeRoleProvider(stsClient, roleARN) awsCfg.Credentials = aws.NewCredentialsCache(provider) return awssignerv2.NewSignerWithService(awsCfg, aossService)
} func getSearchBody() (*strings.Reader, error) { // Match all documents, page size = 10 query := map[string]interface{}{ "size": 10, } queryJson, err := json.Marshal(query) if err != nil { return nil, err } return strings.NewReader(string(queryJson)), nil
} 

Slutsats

I maj 2023 rullade Alcion ut sin sökarkitektur baserad på den delade samlingen och dedikerade index-per-hyresgäst-modellen i alla produktions- och förproduktionsmiljöer. Teamet kunde riva ut komplex kod och operativa processer som hade dedikerats till att skala OpenSearch Service-hanterade domäner. Dessutom, tack vare den automatiska skalningskapaciteten hos OpenSearch Serverless, har Alcion minskat sina OpenSearch-kostnader med 30 % och förväntar sig att kostnadsprofilen ska skalas gynnsamt.

I sin resa från hanterad till serverlös OpenSearch Service, gynnades Alcion i deras första val av OpenSearch Service-hanterade domäner. När de migrerade framåt kunde de återanvända samma OpenSearch API:er och bibliotek för sina OpenSearch Serverless-samlingar som de använde för sin OpenSearch Service-hanterade domän. Dessutom uppdaterade de sin hyresmodell för att dra fördel av OpenSearch Serverless dataåtkomstpolicyer. Med OpenSearch Serverless kunde de enkelt anpassa sig till sina kunders skalabehov samtidigt som de säkerställde hyresgästisolering.

För mer information om Alcion, besök deras webbplats.

Om författarna

Zack Rossman är en medlem av teknisk personal på Alcion. Han är den tekniska ledaren för sök- och AI-plattformarna. Före Alcion var Zack senior mjukvaruingenjör på Okta, och utvecklade kärnanställda identitets- och åtkomsthanteringsprodukter för Directories-teamet.

Niraj Jetly är en mjukvaruutvecklingschef för Amazon OpenSearch Serverless. Niraj leder flera dataplansteam som ansvarar för lanseringen av Amazon OpenSearch Serverless. Före AWS ledde Niraj flera produkt- och ingenjörsteam som CTO, VP of Engineering och Head of Product Management i över 15 år. Niraj har mottagit över 15 innovationspriser, bland annat utsedd till årets CIO 2014 och topp 100 CIO 2013 och 2016. Han är en frekvent talare på flera konferenser och har citerats i NPR, WSJ och The Boston Globe.

Jon Handler är Senior Principal Solutions Architect på Amazon Web Services baserad i Palo Alto, CA. Jon arbetar nära OpenSearch och Amazon OpenSearch Service, och tillhandahåller hjälp och vägledning till ett brett spektrum av kunder som har sök- och logganalysarbetsbelastningar som de vill flytta till AWS-molnet. Innan han började på AWS inkluderade Jons karriär som mjukvaruutvecklare 4 år av kodning av en storskalig e-handelssökmotor. Jon har en Bachelor of the Arts från University of Pennsylvania och en Master of Science och en doktorsexamen i datavetenskap och artificiell intelligens från Northwestern University.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Fordon / elbilar, Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• BlockOffsets. Modernisera miljökompensation ägande. Tillgång här.
• Källa: https://aws.amazon.com/blogs/big-data/alcion-supports-their-multi-tenant-platform-with-amazon-opensearch-serverless/