Esta es una publicación de blog invitado coescrita con Zack Rossman de Alcion.

Alcion, una plataforma de copia de seguridad como servicio (BaaS) impulsada por IA que prioriza la seguridad, ayuda a los administradores de Microsoft 365 a proteger los datos de forma rápida e intuitiva contra las amenazas cibernéticas y la pérdida accidental de datos. En caso de pérdida de datos, los clientes de Alcion deben buscar los metadatos de los elementos respaldados (archivos, correos electrónicos, contactos, eventos, etc.) para seleccionar versiones de elementos específicos para restaurar. usos de alción Servicio Amazon OpenSearch para proporcionar a sus clientes una capacidad de búsqueda precisa, eficiente y confiable en este catálogo de respaldo. La plataforma es multiinquilino, lo que significa que Alcion requiere aislamiento de datos y una fuerte seguridad para garantizar que los inquilinos solo puedan buscar sus propios datos.

OpenSearch Service es un servicio totalmente administrado que facilita la implementación, el escalado y el funcionamiento de OpenSearch en la nube de AWS. OpenSearch es una suite de análisis y búsqueda de código abierto con licencia Apache 2.0, que comprende OpenSearch (un motor de búsqueda, análisis y base de datos vectorial), OpenSearch Dashboards (una interfaz de usuario de visualización y utilidad) y complementos que brindan capacidades avanzadas como Enterprise -grado de seguridad, detección de anomalías, observabilidad, alertas y mucho más. Amazon OpenSearch sin servidor es una opción de implementación sin servidor que simplifica el uso de OpenSearch sin configurar, administrar ni escalar los dominios del servicio OpenSearch.

En esta publicación, compartimos cómo la adopción de OpenSearch Serverless permitió a Alcion cumplir con sus requisitos de escala, reducir sus gastos generales operativos y proteger los datos de sus inquilinos mediante la aplicación aislamiento de inquilinos dentro de su entorno multiusuario.

Dominios gestionados por OpenSearch Service

Para la primera iteración de su arquitectura de búsqueda, Alcion eligió la opción de implementación de dominios administrados en OpenSearch Service y pudo lanzar su funcionalidad de búsqueda en producción en menos de un mes. Para cumplir con sus requisitos de seguridad, escala y arrendamiento, almacenaron datos para cada arrendatario en un índice dedicado y utilizaron control de acceso detallado en OpenSearch Service para evitar fugas de datos entre inquilinos. A medida que evolucionó su carga de trabajo, los ingenieros de Alcion rastrearon la utilización del dominio OpenSearch a través del Reloj en la nube de Amazon métricas, realizando cambios para aumentar el almacenamiento y optimizar sus recursos informáticos.

El equipo de Alcion usó varias características de los dominios administrados de OpenSearch Service para mejorar su postura operativa. Introdujeron alias de índice, que proporcionan un solo nombre de alias para acceder (leer y escribir) a múltiples índices subyacentes. También configuraron Gestión del estado del índice (ISM) para ayudarlos a controlar el ciclo de vida de sus datos mediante la transferencia de índices en función del tamaño del índice. Juntos, las políticas de ISM y los alias de índice eran necesarios para escalar índices para grandes inquilinos. Alción también usó plantillas de índice para definir los fragmentos por índice (partición) de sus datos para automatizar su ciclo de vida de datos y mejorar el rendimiento y la estabilidad de sus dominios.

El siguiente diagrama de arquitectura muestra cómo Alcion configuró sus dominios administrados de OpenSearch.

El siguiente diagrama muestra cómo se indexaron y consultaron los datos de Microsoft 365 desde índices específicos de inquilinos. Alcion implementó la autenticación de solicitudes proporcionando las credenciales de usuario principal de OpenSearch con cada solicitud de API.

Descripción general de OpenSearch Serverless y opciones de modelo de tenencia

Los dominios administrados de OpenSearch Service proporcionaron una base estable para la funcionalidad de búsqueda de Alcion, pero el equipo necesitaba proporcionar recursos manualmente a los dominios para su carga de trabajo máxima. Esto dejó espacio para optimizaciones de costos porque la carga de trabajo de Alcion es explosiva: hay grandes variaciones en la cantidad de transacciones de búsqueda e indexación por segundo, tanto para un solo cliente como en conjunto. Para reducir los costos y la carga operativa, el equipo recurrió a OpenSearch Serverless, que ofrece capacidad de escalado automático.

Para usar OpenSearch Serverless, el primer paso es crear una colección. A -- es un grupo de índices de OpenSearch que funcionan juntos para admitir una carga de trabajo o un caso de uso específico. Los recursos informáticos de una colección, denominados Unidades informáticas de OpenSearch (OCU), se comparten entre todas las colecciones de una cuenta que comparten una clave de cifrado. El conjunto de OCU se amplía y reduce automáticamente para satisfacer las demandas de indexación y tráfico de búsqueda.

El nivel de esfuerzo requerido para migrar de un dominio administrado de OpenSearch Service a OpenSearch Serverless fue manejable gracias al hecho de que las colecciones de OpenSearch Serverless admiten las mismas API y bibliotecas de OpenSearch que los dominios administrados de OpenSearch Service. Esto permitió a Alcion concentrarse en optimizar el modelo de tenencia para la nueva arquitectura de búsqueda. Específicamente, el equipo necesitaba decidir cómo particionar los datos de los inquilinos dentro de las colecciones e índices mientras equilibraba la seguridad y el costo total de propiedad. Los ingenieros de Alcion, en colaboración con el equipo de OpenSearch Serverless, consideró tres modelos de tenencia:

• Modelo de silo: cree una colección para cada inquilino
• Modelo de grupo: cree una colección única y use un índice único para múltiples inquilinos
• Modelo de puente: cree una colección única y use un índice único por arrendatario

Las tres opciones de diseño tenían ventajas y desventajas que debían tenerse en cuenta para diseñar la solución final.

Modelo de silo: cree una colección para cada inquilino

En este modelo, Alcion crearía una nueva colección cada vez que un nuevo cliente se incorporara a su plataforma. Aunque los datos de los inquilinos se separarían claramente entre las colecciones, esta opción se descartó porque el tiempo de creación de la colección significaba que los clientes no podrían realizar copias de seguridad y buscar datos inmediatamente después del registro.

Modelo de grupo: cree una colección única y use un índice único para múltiples inquilinos

En este modelo, Alcion crearía una sola colección por cuenta de AWS e indexaría los datos específicos del arrendatario en uno de los muchos índices compartidos que pertenecen a esa colección. Inicialmente, la agrupación de datos de inquilinos en índices compartidos era atractiva desde una perspectiva de escala porque conducía al uso más eficiente de los recursos del índice. Pero después de un análisis más detallado, Alcion descubrió que estarían dentro de la cuota del índice por colección, incluso si asignaran un índice para cada inquilino. Con esa preocupación de escalabilidad resuelta, Alcion buscó la tercera opción porque almacenar los datos de inquilinos en índices dedicados da como resultado un aislamiento de inquilinos más sólido que el modelo de índice compartido.

Modelo de puente: cree una colección única y use un índice único por arrendatario

En este modelo, Alcion crearía una sola colección por cuenta de AWS y crearía un índice para cada uno de los cientos de arrendatarios administrados por esa cuenta. Al asignar cada inquilino a un índice dedicado y agrupar estos índices en una sola colección, Alcion redujo el tiempo de incorporación de nuevos inquilinos y aisló los datos de los inquilinos en cubos claramente separados.

Implementación de control de acceso basado en roles para soportar múltiples inquilinos

OpenSearch Serverless ofrece un conjunto de controles de seguridad heredables multipunto, que cubre el acceso a datos, el acceso a la red y el cifrado. Alcion aprovechó al máximo OpenSearch Serverless políticas de acceso a datos para implementar el control de acceso basado en roles (RBAC) para cada índice específico de arrendatario con los siguientes detalles:

• Asigne un índice con un prefijo común y el ID de arrendatario (por ejemplo, index-v1-<tenantID>)
• Crear un dedicado Gestión de identidades y accesos de AWS (IAM) rol que se usa para firmar solicitudes a la colección OpenSearch Serverless
• Cree una política de acceso a datos sin servidor de OpenSearch que otorgue permisos de lectura/escritura de documentos dentro de un índice de arrendatario dedicado al rol de IAM para ese arrendatario.
• Las solicitudes de API de OpenSearch a un índice de arrendatario se firman con credenciales temporales que pertenecen al rol de IAM específico del arrendatario

El siguiente es un ejemplo de política de acceso a datos sin servidor de OpenSearch para un arrendatario simulado con ID t-eca0acc1-12345678910. Esta política otorga al documento de rol de IAM acceso de lectura/escritura al acceso de arrendatario dedicado.

[ { "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" }
] 

El siguiente diagrama de arquitectura muestra cómo Alcion implementó la indexación y la búsqueda de recursos de Microsoft 365 mediante el enfoque de recopilación compartida OpenSearch Serverless.

El siguiente es el fragmento de código de muestra para enviar una solicitud de API a una colección de OpenSearch Serverless. Observe cómo el cliente de la API se inicializa con un objeto de firmante que firma las solicitudes con el mismo principal de IAM que está vinculado a la política de acceso a datos sin servidor de OpenSearch del fragmento de código anterior.

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
} 

Conclusión

En mayo de 2023, Alcion implementó su arquitectura de búsqueda basada en la colección compartida y el modelo de índice por inquilino dedicado en todos los entornos de producción y preproducción. El equipo pudo eliminar códigos complejos y procesos operativos que se habían dedicado a escalar los dominios administrados por OpenSearch Service. Además, gracias a las capacidades de escalado automático de OpenSearch Serverless, Alcion ha reducido sus costos de OpenSearch en un 30 % y espera que el perfil de costos se escale favorablemente.

En su viaje desde OpenSearch Service gestionado a sin servidor, Alcion se benefició de su elección inicial de dominios gestionados de OpenSearch Service. Al migrar hacia adelante, pudieron reutilizar las mismas API y bibliotecas de OpenSearch para sus colecciones de OpenSearch Serverless que usaron para su dominio administrado de OpenSearch Service. Además, actualizaron su modelo de tenencia para aprovechar las políticas de acceso a datos sin servidor de OpenSearch. Con OpenSearch Serverless, pudieron adaptarse sin esfuerzo a las necesidades de escala de sus clientes al tiempo que garantizaban el aislamiento de los inquilinos.

Para obtener más información sobre Alcion, visite su página web del NDN Collective .

Acerca de los autores

Zack Rossman es miembro del personal técnico de Alcion. Es el líder tecnológico de las plataformas de búsqueda e IA. Antes de Alcion, Zack fue ingeniero de software sénior en Okta y desarrolló productos básicos de administración de acceso e identidad de la fuerza laboral para el equipo de Directorios.

Niraj Jetly es gerente de desarrollo de software para Amazon OpenSearch Serverless. Niraj lidera varios equipos de planos de datos responsables del lanzamiento de Amazon OpenSearch Serverless. Antes de AWS, Niraj dirigió varios equipos de productos e ingeniería como director de tecnología, vicepresidente de ingeniería y director de gestión de productos durante más de 15 años. Niraj ha recibido más de 15 premios a la innovación, incluido ser nombrado CIO del año en 2014 y uno de los 100 mejores CIO en 2013 y 2016. Orador frecuente en varias conferencias, ha sido citado en NPR, WSJ y The Boston Globe.

jon manejador es Arquitecto de Soluciones Principal Senior en Amazon Web Services con sede en Palo Alto, CA. Jon trabaja en estrecha colaboración con OpenSearch y Amazon OpenSearch Service, brindando ayuda y orientación a una amplia gama de clientes que tienen cargas de trabajo de búsqueda y análisis de registros que desean trasladar a la nube de AWS. Antes de unirse a AWS, la carrera de Jon como desarrollador de software incluyó 4 años de codificación de un motor de búsqueda de comercio electrónico a gran escala. Jon tiene una Licenciatura en Artes de la Universidad de Pensilvania y una Maestría en Ciencias y un Doctorado en Ciencias de la Computación e Inteligencia Artificial de la Universidad Northwestern.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Automoción / vehículos eléctricos, Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• Desplazamientos de bloque. Modernización de la propiedad de compensaciones ambientales. Accede Aquí.
• Fuente: https://aws.amazon.com/blogs/big-data/alcion-supports-their-multi-tenant-platform-with-amazon-opensearch-serverless/