Padrões de design para aplicativos SaaS multilocatários e Azure SearchDesign patterns for multitenant SaaS applications and Azure Search

Um aplicativo multilocatário é aquele que fornece os mesmos serviços e funcionalidades para qualquer número de locatários que não conseguem ver nem compartilhar os dados de qualquer outro locatário.A multitenant application is one that provides the same services and capabilities to any number of tenants who cannot see or share the data of any other tenant. Este documento discute estratégias de isolamento de locatário para aplicativos multilocatários criados com o Azure Search.This document discusses tenant isolation strategies for multitenant applications built with Azure Search.

Conceitos do Azure SearchAzure Search concepts

Como uma solução de pesquisa como serviço, o Azure Search permite aos desenvolvedores adicionar experiências de pesquisa avançada para aplicativos sem gerenciar nenhuma infraestrutura ou se tornar um especialista em pesquisa.As a search-as-a-service solution, Azure Search allows developers to add rich search experiences to applications without managing any infrastructure or becoming an expert in information retrieval. Os dados são carregados para o serviço e, em seguida, são armazenados na nuvem.Data is uploaded to the service and then stored in the cloud. Usando solicitações simples para a API do Azure Search, os dados podem então ser modificados e pesquisados.Using simple requests to the Azure Search API, the data can then be modified and searched. Uma visão geral do serviço pode ser encontrada em neste artigo.An overview of the service can be found in this article. Antes de discutir os padrões de design, é importante compreender alguns conceitos do Azure Search.Before discussing design patterns, it is important to understand some concepts in Azure Search.

Serviços Search, índices, campos e documentosSearch services, indexes, fields, and documents

Ao usar o Azure Search, alguém assina um serviço de pesquisa.When using Azure Search, one subscribes to a search service. Como os dados são carregados no Azure Search, eles são armazenados em um índice dentro do serviço de pesquisa.As data is uploaded to Azure Search, it is stored in an index within the search service. Pode haver um número de índices em um único serviço.There can be a number of indexes within a single service. Para usar os conceitos familiares de bancos de dados, o serviço de pesquisa pode ser comparado a um banco de dados, enquanto os índices dentro de um serviço podem ser comparados a tabelas em um banco de dados.To use the familiar concepts of databases, the search service can be likened to a database while the indexes within a service can be likened to tables within a database.

Cada índice dentro de um serviço de pesquisa tem seu próprio esquema, que é definido por um número de campospersonalizáveis.Each index within a search service has its own schema, which is defined by a number of customizable fields. Os dados são adicionados a um índice do Azure Search na forma de documentosindividuais.Data is added to an Azure Search index in the form of individual documents. Cada documento deve ser carregado em um índice específico e deve se ajustar o esquema do índice.Each document must be uploaded to a particular index and must fit that index's schema. Ao pesquisar dados usando o Azure Search, as consultas de pesquisa de texto completo são emitidas em relação a um índice específico.When searching data using Azure Search, the full-text search queries are issued against a particular index. Para comparar esses conceitos àqueles de um banco de dados, os campos podem ser comparados a colunas em uma tabela e os documentos podem ser comparados a linhas.To compare these concepts to those of a database, fields can be likened to columns in a table and documents can be likened to rows.

EscalabilidadeScalability

Qualquer serviço do Azure Search no tipo de preço Standard pode ser dimensionado em duas dimensões: armazenamento e disponibilidade.Any Azure Search service in the Standard pricing tier can scale in two dimensions: storage and availability.

  • Partições podem ser adicionadas para aumentar o armazenamento de um serviço de pesquisa.Partitions can be added to increase the storage of a search service.
  • Réplicas podem ser adicionados a um serviço para aumentar a taxa de solicitações que pode lidar com um serviço de pesquisa.Replicas can be added to a service to increase the throughput of requests that a search service can handle.

Adicionar e remover partições e réplicas permitirá que a capacidade do serviço de pesquisa cresça de acordo com a quantidade de dados e tráfego que o aplicativo exige.Adding and removing partitions and replicas at will allow the capacity of the search service to grow with the amount of data and traffic the application demands. Para que um serviço de pesquisa obtenha um SLAde leitura, ele requer duas réplicas.In order for a search service to achieve a read SLA, it requires two replicas. Para que um serviço de pesquisa obtenha um SLAde leitura/gravação, ele requer três réplicas.In order for a service to achieve a read-write SLA, it requires three replicas.

Há alguns tipos de preço diferentes no Azure Search, cada um dos tipos tem limites e cotas diferentes.There are a few different pricing tiers in Azure Search, each of the tiers has different limits and quotas. Alguns desses limites estão no nível de serviço, alguns estão no nível do índice e alguns estão no nível da partição.Some of these limits are at the service-level, some are at the index-level, and some are at the partition-level.

BasicBasic Standard1Standard1 Standard2Standard2 Standard3Standard3 Standard3 HDStandard3 HD
Máximo de réplicas por serviçoMaximum Replicas per Service 33 1212 1212 1212 1212
Máximo de partições por serviçoMaximum Partitions per Service 11 1212 1212 1212 33
Máximo de unidades de pesquisa (réplicas * partições) por serviçoMaximum Search Units (Replicas*Partitions) per Service 33 3636 3636 3636 36 (máx. de 3 partições)36 (max 3 partitions)
Armazenamento máximo por serviçoMaximum Storage per Service 2 GB2 GB 300 GB300 GB 1,2 TB1.2 TB 2,4 TB2.4 TB 600 GB600 GB
Armazenamento máximo por partiçãoMaximum Storage per Partition 2 GB2 GB 25 GB25 GB 100 GB100 GB 200 GB200 GB 200 GB200 GB
Índices máximos por serviçoMaximum Indexes per Service 55 5050 200200 200200 3000 (máx. de 1000 índices/partição)3000 (max 1000 indexes/partition)

Alta densidade S3S3 High Density'

No tipo de preço S3 do Azure Search, há uma opção para o modo HD (alta densidade) desenvolvido especificamente para cenários de multilocatários.In Azure Search’s S3 pricing tier, there is an option for the High Density (HD) mode designed specifically for multitenant scenarios. Em muitos casos, é necessário dar suporte a um grande número de locatários menores em um único serviço para obter os benefícios de simplicidade e redução de custos.In many cases, it is necessary to support a large number of smaller tenants under a single service to achieve the benefits of simplicity and cost efficiency.

S3 HD permite que os muitos índices pequenos sejam empacotados no gerenciamento de um único serviço de pesquisa, negociando a capacidade de escalar horizontalmente índices usando partições para a capacidade de hospedar mais índices em um único serviço.S3 HD allows for the many small indexes to be packed under the management of a single search service by trading the ability to scale out indexes using partitions for the ability to host more indexes in a single service.

Concretamente, um serviço S3 poderia ter entre 1 e 200 índices que juntos podem hospedar até 1,4 bilhão de documentos.Concretely, an S3 service could have between 1 and 200 indexes that together could host up to 1.4 billion documents. Por outro lado, um S3 HD permitiria que índices individuais tenham apenas até 1 milhão de documentos, mas pode manipular até 1000 índices por partição (até 3000 por serviço) com uma contagem total do documento de 200 milhões por partição (até 600 milhões por serviço).An S3 HD on the other hand would allow individual indexes to only go up to 1 million documents, but it can handle up to 1000 indexes per partition (up to 3000 per service) with a total document count of 200 million per partition (up to 600 million per service).

Considerações para aplicativos multilocatáriosConsiderations for multitenant applications

Aplicativos multilocatários devem distribuir efetivamente recursos entre locatários preservando algum nível de privacidade entre os vários locatários.Multitenant applications must effectively distribute resources among the tenants while preserving some level of privacy between the various tenants. Há algumas considerações ao criar a arquitetura para esse aplicativo:There are a few considerations when designing the architecture for such an application:

  • Isolamento de locatário: Os desenvolvedores de aplicativos precisam tomar as medidas apropriadas para garantir que nenhum locatário tenha acesso não autorizado ou indesejado aos dados de outros locatários.Tenant isolation: Application developers need to take appropriate measures to ensure that no tenants have unauthorized or unwanted access to the data of other tenants. Além da perspectiva de privacidade de dados, estratégias de isolamento de locatários requerem um gerenciamento eficiente de recursos compartilhados e a proteção de vizinhos com ruídos.Beyond the perspective of data privacy, tenant isolation strategies require effective management of shared resources and protection from noisy neighbors.
  • Custo de recursos de nuvem: Assim como ocorre com qualquer outro aplicativo, as soluções de software precisam permanecer competitivas em termos de custo como um componente de um aplicativo multilocatário.Cloud resource cost: As with any other application, software solutions must remain cost competitive as a component of a multitenant application.
  • Facilidade de operações: Ao desenvolver uma arquitetura de multilocatário, o impacto sobre as operações e a complexidade do aplicativo é uma consideração importante.Ease of Operations: When developing a multitenant architecture, the impact on the application's operations and complexity is an important consideration. O Azure Search tem um SLA de 99,9%.Azure Search has a 99.9% SLA.
  • Volume global: Os aplicativos multilocatário podem precisar atender efetivamente a locatários distribuídos em todo o mundo.Global footprint: Multitenant applications may need to effectively serve tenants which are distributed across the globe.
  • Escalabilidade: Os desenvolvedores de aplicativos precisam considerar como reconciliam entre manter um nível suficientemente baixo de complexidade do aplicativo e projetar o aplicativo para ser dimensionado com o número de locatários e o tamanho dos dados e da carga de trabalho dos locatários.Scalability: Application developers need to consider how they reconcile between maintaining a sufficiently low level of application complexity and designing the application to scale with number of tenants and the size of tenants' data and workload.

O Azure Search oferece alguns limites que podem ser usados para isolar dados e carga de trabalho de locatários.Azure Search offers a few boundaries that can be used to isolate tenants’ data and workload.

No caso de um cenário de multilocatário, o desenvolvedor do aplicativo consome um ou mais serviços de pesquisa e divide seus locatários entre serviços, índices ou ambos.In the case of a multitenant scenario, the application developer consumes one or more search services and divide their tenants among services, indexes, or both. O Azure Search tem alguns padrões comuns ao modelar um cenário de multilocatário:Azure Search has a few common patterns when modeling a multitenant scenario:

  1. Índice por locatário: Cada locatário tem seu próprio índice em um serviço de pesquisa que é compartilhado com outros locatários.Index per tenant: Each tenant has its own index within a search service that is shared with other tenants.
  2. Serviço por locatário: Cada locatário tem seu próprio serviço dedicado do Azure Search, oferecendo o nível mais alto de separação de dados e de carga de trabalho.Service per tenant: Each tenant has its own dedicated Azure Search service, offering highest level of data and workload separation.
  3. Combinação de ambos: Locatários maiores e mais ativos recebem serviços dedicados, enquanto locatários menores recebem índices individuais em serviços compartilhados.Mix of both: Larger, more-active tenants are assigned dedicated services while smaller tenants are assigned individual indexes within shared services.

1. Indexar por locatário1. Index per tenant

Uma descrição do modelo de índice por locatário

Em um modelo de índice por locatário, vários locatários ocupam um único serviço do Azure Search, em que cada locatário tem seu próprio índice.In an index-per-tenant model, multiple tenants occupy a single Azure Search service where each tenant has their own index.

Locatários atingem o isolamento de dados porque todas as solicitações de pesquisa e operações de documento são emitidas em um nível de índice no Azure Search.Tenants achieve data isolation because all search requests and document operations are issued at an index level in Azure Search. Na camada de aplicativo, há o reconhecimento da necessidade de direcionar o tráfego de vários locatários para os índices certos enquanto gerencia recursos no nível de serviço em todos os locatários.In the application layer, there is the need awareness to direct the various tenants’ traffic to the proper indexes while also managing resources at the service level across all tenants.

Um atributo de chave do modelo de índice por locatário é a capacidade do desenvolvedor do aplicativo de subscrever a capacidade de um serviço de pesquisa entre locatários do aplicativo.A key attribute of the index-per-tenant model is the ability for the application developer to oversubscribe the capacity of a search service among the application’s tenants. Se os locatários têm uma distribuição desigual de carga de trabalho, a combinação ideal de locatários pode ser distribuída em índices de um serviço de pesquisa para acomodar inúmeros locatários altamente ativos e com uso intensivo de recursos, ao mesmo tempo em que atende uma cauda longa de locatários menos ativos.If the tenants have an uneven distribution of workload, the optimal combination of tenants can be distributed across a search service’s indexes to accommodate a number of highly active, resource-intensive tenants while simultaneously serving a long tail of less active tenants. A desvantagem é a incapacidade do modelo de lidar com situações em que cada locatário é altamente ativo simultaneamente.The trade-off is the inability of the model to handle situations where each tenant is concurrently highly active.

O modelo de índice por locatário fornece a base para um modelo de custo variável, em que um serviço inteiro do Azure Search é comprado antecipado e, em seguida, preenchido com locatários.The index-per-tenant model provides the basis for a variable cost model, where an entire Azure Search service is bought up-front and then subsequently filled with tenants. Isso permite que a capacidade não utilizada seja designada para contas gratuitas e de avaliação.This allows for unused capacity to be designated for trials and free accounts.

Para aplicativos com uma superfície global, o modelo de índice por locatário pode não ser o mais eficiente.For applications with a global footprint, the index-per-tenant model may not be the most efficient. Se locatários do aplicativo são distribuídos em todo o mundo, um serviço separado pode ser necessário para cada região que pode duplicar os custos em cada um deles.If an application's tenants are distributed across the globe, a separate service may be necessary for each region which may duplicate costs across each of them.

O Azure Search permite a escala de índices individuais e do número total de índices para crescer.Azure Search allows for the scale of both the individual indexes and the total number of indexes to grow. Se um tipo de preço apropriado for escolhido, partições e réplicas poderão ser adicionadas ao serviço de pesquisa inteiro quando um índice individual dentro do serviço se tornar muito extenso em termos de armazenamento ou tráfego.If an appropriate pricing tier is chosen, partitions and replicas can be added to the entire search service when an individual index within the service grows too large in terms of storage or traffic.

Se o número total de índices aumenta muito para um único serviço, outro serviço deve ser configurado para acomodar novos locatários.If the total number of indexes grows too large for a single service, another service has to be provisioned to accommodate the new tenants. Se os índices precisam ser movidos entre os serviços de pesquisa à medida que novos serviços são adicionados, os dados do índice devem ser copiados manualmente de um índice para o outro, já que o Azure Search não permite que um índice seja movido.If indexes have to be moved between search services as new services are added, the data from the index has to be manually copied from one index to the other as Azure Search does not allow for an index to be moved.

2. Serviço por locatário2. Service per tenant

Uma descrição do modelo de serviço por locatário

Em uma arquitetura de serviço por locatário, cada locatário tem seu próprio serviço de pesquisa.In a service-per-tenant architecture, each tenant has its own search service.

Nesse modelo, o aplicativo atinge o nível máximo de isolamento para seus locatários.In this model, the application achieves the maximum level of isolation for its tenants. Cada serviço tem armazenamento dedicado e taxa de transferência para lidar com solicitação de pesquisa, bem como chaves de API separadas.Each service has dedicated storage and throughput for handling search request as well as separate API keys.

Para aplicativos em que cada locatário tem uma grande superfície ou a carga de trabalho tem menos variabilidade de locatário para locatário, o modelo de serviço por locatário é uma opção adequada, já que recursos não são compartilhados entre cargas de trabalho de vários locatários.For applications where each tenant has a large footprint or the workload has little variability from tenant to tenant, the service-per-tenant model is an effective choice as resources are not shared across various tenants’ workloads.

Um modelo de serviço por locatário também oferece o benefício de um modelo de custo fixo e previsível.A service per tenant model also offers the benefit of a predictable, fixed cost model. Não há nenhum investimento antecipado em um serviço de pesquisa inteiro até que haja um locatário para preenchê-lo. No entanto, o custo por locatário é maior do que um modelo de índice por locatário.There is no up-front investment in an entire search service until there is a tenant to fill it, however the cost-per-tenant is higher than an index-per-tenant model.

O modelo de serviço por locatário é uma opção eficiente para aplicativos com uma superfície global.The service-per-tenant model is an efficient choice for applications with a global footprint. Com locatários distribuídos geograficamente, é fácil ter cada serviço do locatário na região apropriada.With geographically-distributed tenants, it is easy to have each tenant's service in the appropriate region.

Os desafios de dimensionamento desse padrão surgem quando locatários individuais excedem o serviço.The challenges in scaling this pattern arise when individual tenants outgrow their service. O Azure Search atualmente não dá suporte à atualização do tipo de preço de um serviço de pesquisa, por isso todos os dados precisam ser copiados manualmente para um novo serviço.Azure Search does not currently support upgrading the pricing tier of a search service, so all data would have to be manually copied to a new service.

3. Combinação dos dois modelos3. Mixing both models

Outro padrão para modelar a multilocação é misturar estratégias de índice por locatário e de serviço por locatário.Another pattern for modeling multitenancy is mixing both index-per-tenant and service-per-tenant strategies.

Combinando os dois padrões, locatários maiores do aplicativo podem ocupar serviços dedicados, enquanto a cauda longa de locatários menores, menos ativos pode ocupar índices em um serviço compartilhado.By mixing the two patterns, an application's largest tenants can occupy dedicated services while the long tail of less active, smaller tenants can occupy indexes in a shared service. Esse modelo garante que os locatários maiores tenham consistentemente alto desempenho do serviço, ajudando a proteger os locatários menores de vizinhos com ruídos.This model ensures that the largest tenants have consistently high performance from the service while helping to protect the smaller tenants from any noisy neighbors.

No entanto, implementar essa estratégia depende da antecipação para prever quais locatários exigirão um serviço dedicado em vez de um índice em um serviço compartilhado.However, implementing this strategy relies foresight in predicting which tenants will require a dedicated service versus an index in a shared service. A complexidade do aplicativo aumenta com a necessidade de gerenciar esses dois modelos multilocação.Application complexity increases with the need to manage both of these multitenancy models.

Como obter granularidade ainda maiorAchieving even finer granularity

Os padrões de design acima para modelar cenários de multilocatários no Azure Search presumem um escopo uniforme, no qual cada locatário é uma instância inteira de um aplicativo.The above design patterns to model multitenant scenarios in Azure Search assume a uniform scope where each tenant is a whole instance of an application. No entanto, às vezes, os aplicativos podem manipular vários escopos menores.However, applications can sometimes handle many smaller scopes.

Se os modelos de serviço por locatário e de índice por locatário não são escopos suficientemente pequenos, é possível modelar um índice para atingir um nível ainda maior de granularidade.If service-per-tenant and index-per-tenant models are not sufficiently small scopes, it is possible to model an index to achieve an even finer degree of granularity.

Para que um único índice se comporte de modo diferente para pontos de extremidade de cliente diferentes, é possível adicionar um campo a um índice que designa um valor determinado para cada cliente possível.To have a single index behave differently for different client endpoints, a field can be added to an index which designates a certain value for each possible client. Cada vez que um cliente chama o Azure Search para consultar ou modificar um índice, o código do aplicativo cliente especifica o valor apropriado para o campo usando a funcionalidade de filtro do Azure Search no momento da consulta.Each time a client calls Azure Search to query or modify an index, the code from the client application specifies the appropriate value for that field using Azure Search's filter capability at query time.

Esse método pode ser usado para obter uma funcionalidade de contas de usuário separadas, níveis de permissão separados e até mesmo aplicativos completamente separados.This method can be used to achieve functionality of separate user accounts, separate permission levels, and even completely separate applications.

Observação

Usar a abordagem descrita acima para configurar um único índice para atender a vários locatários afeta a relevância dos resultados da pesquisa.Using the approach described above to configure a single index to serve multiple tenants affects the relevance of search results. Pontuações de relevância de pesquisa são calculadas em um escopo no nível do índice, não no nível do locatário, para que dados de todos os locatários sejam incorporados às estatísticas subjacentes das pontuações de relevância, tal como frequência de termo.Search relevance scores are computed at an index-level scope, not a tenant-level scope, so all tenants' data is incorporated in the relevance scores' underlying statistics such as term frequency.

Próximas etapasNext steps

O Azure Search é uma opção atraente para muitos aplicativos. Leia mais sobre os recursos avançados do serviço.Azure Search is a compelling choice for many applications, read more about the service's robust capabilities. Ao avaliar os vários padrões de design para aplicativos multilocatários, considere os vários tipos de preços e os respectivos limites de serviço para melhor personalizar o Azure Search para ajustar cargas de trabalho do aplicativo e arquiteturas de todos os tamanhos.When evaluating the various design patterns for multitenant applications, consider the various pricing tiers and the respective service limits to best tailor Azure Search to fit application workloads and architectures of all sizes.

Perguntas sobre o Azure Search e cenários de multilocatários podem ser direcionadas para azuresearch_contact@microsoft.com.Any questions about Azure Search and multitenant scenarios can be directed to azuresearch_contact@microsoft.com.