Padrões de design para aplicativos SaaS multilocatários e Azure AI Search

Um aplicativo multilocatário é aquele que fornece os mesmos serviços e recursos para qualquer número de locatários que não podem ver ou compartilhar os dados de nenhum outro locatário. Este artigo discute estratégias de isolamento de locatário para aplicativos multilocatários criados com o Azure AI Search.

Conceitos do Azure AI Search

Como uma solução de pesquisa como serviço, o Azure AI Search permite que os desenvolvedores adicionem experiências de pesquisa avançadas a aplicativos sem gerenciar nenhuma infraestrutura ou se tornar um especialista em recuperação de informações. Os dados são carregados para o serviço e, em seguida, armazenados na nuvem. Usando solicitações simples para a API de Pesquisa do Azure AI, os dados podem ser modificados e pesquisados.

Serviços de pesquisa, índices, campos e documentos

Antes de discutir padrões de design, é importante entender alguns conceitos básicos.

Ao usar o Azure AI Search, uma pessoa se inscreve em um serviço de pesquisa. À medida que os dados são carregados no Azure AI Search, são armazenados num índice dentro do serviço de pesquisa. Pode haver vários índices dentro de um único serviço. 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 dentro de um banco de dados.

Cada índice dentro de um serviço de pesquisa tem seu próprio esquema, que é definido por um número de campos personalizáveis. Os dados são adicionados a um índice do Azure AI Search na forma de documentos individuais. Cada documento deve ser carregado para um índice específico e deve se ajustar ao esquema desse índice. Ao pesquisar dados usando o Azure AI Search, as consultas de pesquisa de texto completo são emitidas em relação a um índice específico. Para comparar esses conceitos com os de um banco de dados, os campos podem ser comparados a colunas em uma tabela e os documentos podem ser comparados a linhas.

Escalabilidade

Qualquer serviço Azure AI Search na camada de preço Standard pode ser dimensionado em duas dimensões: armazenamento e disponibilidade.

• As partições podem ser adicionadas para aumentar o armazenamento de um serviço de pesquisa.
• As réplicas podem ser adicionadas a um serviço para aumentar a taxa de transferência de solicitações que um serviço de pesquisa pode manipular.

Adicionar e remover partições e réplicas permitirá que a capacidade do serviço de pesquisa cresça com a quantidade de dados e tráfego que o aplicativo exige. Para que um serviço de pesquisa atinja um SLA de leitura, ele requer duas réplicas. Para que um serviço atinja um SLA de leitura-gravação, ele requer três réplicas.

Limites de serviço e índice na Pesquisa de IA do Azure

Existem alguns níveis de preços diferentes no Azure AI Search, cada um dos níveis tem limites e quotas diferentes. Alguns desses limites estão no nível de serviço, alguns estão no nível de índice e alguns estão no nível de partição.

S3 Alta Densidade

No nível de preços do S3 do Azure AI Search, há uma opção para o modo de Alta Densidade (HD) projetado especificamente para cenários multilocatário. Em muitos casos, é necessário dar suporte a um grande número de locatários menores sob um único serviço para obter os benefícios da simplicidade e eficiência de custos.

O S3 HD permite que os muitos índices pequenos sejam embalados sob o gerenciamento de um único serviço de pesquisa, negociando a capacidade de escalar índices usando partições para a capacidade de hospedar mais índices em um único serviço.

Um serviço S3 foi projetado para hospedar um número fixo de índices (máximo 200) e permitir que cada índice seja dimensionado horizontalmente à medida que novas partições são adicionadas ao serviço. Adicionar partições aos serviços S3 HD aumenta o número máximo de índices que o serviço pode hospedar. O tamanho máximo ideal para um índice S3HD individual é de cerca de 50 - 80 GB, embora não haja limite de tamanho rígido em cada índice imposto pelo sistema.

Considerações para aplicativos multilocatários

Os aplicativos multilocatários devem distribuir efetivamente os recursos entre os locatários, preservando algum nível de privacidade entre os vários locatários. Há algumas considerações ao projetar a arquitetura para tal aplicativo:

• Isolamento do 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. Além da perspetiva da privacidade de dados, as estratégias de isolamento do locatário exigem gerenciamento eficaz de recursos compartilhados e proteção contra vizinhos barulhentos.

• Custo dos recursos na nuvem: como acontece com qualquer outro aplicativo, as soluções de software devem permanecer competitivas em termos de custos como um componente de um aplicativo multilocatário.

• Facilidade de operações: ao desenvolver uma arquitetura multilocatário, o impacto nas operações e na complexidade do aplicativo é uma consideração importante. O Azure AI Search tem um SLA de 99,9%.

• Pegada global: os aplicativos multilocatários geralmente precisam atender locatários distribuídos em todo o mundo.

• Escalabilidade: os desenvolvedores de aplicativos precisam considerar como conciliam 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.

O Azure AI Search oferece alguns limites que podem ser usados para isolar os dados e a carga de trabalho dos locatários.

Modelando multilocação com o Azure AI Search

No caso de um cenário multilocatário, o desenvolvedor de aplicativos consome um ou mais serviços de pesquisa e divide seus locatários entre serviços, índices ou ambos. O Azure AI Search tem alguns padrões comuns ao modelar um cenário multilocatário:

• Um índice por inquilino: cada inquilino tem o seu próprio índice num serviço de pesquisa que é partilhado com outros inquilinos.

• Um serviço por locatário: cada locatário tem seu próprio serviço dedicado Azure AI Search, oferecendo o mais alto nível de separação de dados e carga de trabalho.

• 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.

Modelo 1: Um índice por inquilino

Em um modelo de índice por locatário, vários locatários ocupam um único serviço de Pesquisa de IA do Azure onde cada locatário tem seu próprio índice.

Os locatários obtêm isolamento de dados porque todas as solicitações de pesquisa e operações de documentos são emitidas em um nível de índice no Azure AI Search. Na camada de aplicativo, há a necessidade de direcionar o tráfego dos vários locatários para os índices adequados e, ao mesmo tempo, gerenciar recursos no nível de serviço em todos os locatários.

Um atributo chave do modelo de índice por locatário é a capacidade do desenvolvedor do aplicativo de sobrescrever a capacidade de um serviço de pesquisa entre os locatários do aplicativo. Se os locatários tiverem uma distribuição desigual da carga de trabalho, a combinação ideal de locatários poderá ser distribuída pelos índices de um serviço de pesquisa para acomodar vários locatários altamente ativos e que consomem muitos recursos e, ao mesmo tempo, atender a uma longa cauda de locatários menos ativos. A contrapartida é a incapacidade do modelo de lidar com situações em que cada inquilino é simultaneamente altamente ativo.

O modelo de índice por locatário fornece a base para um modelo de custo variável, onde todo um serviço de Pesquisa de IA do Azure é comprado antecipadamente e, posteriormente, preenchido com locatários. Isso permite que a capacidade não utilizada seja designada para avaliações e contas gratuitas.

Para aplicativos com uma pegada global, o modelo de índice por locatário pode não ser o mais eficiente. Se os locatários de um aplicativo estiverem distribuídos pelo mundo, um serviço separado poderá ser necessário para cada região, duplicando os custos em cada uma delas.

O Azure AI Search permite que a escala dos índices individuais e o número total de índices cresçam. Se um nível de preço apropriado for escolhido, partições e réplicas poderão ser adicionadas a todo o serviço de pesquisa quando um índice individual dentro do serviço crescer demais em termos de armazenamento ou tráfego.

Se o número total de índices crescer demais para um único serviço, outro serviço deverá ser provisionado para acomodar os novos locatários. Se os índices tiverem de ser movidos entre serviços de pesquisa à medida que novos serviços forem adicionados, os dados do índice terão de ser copiados manualmente de um índice para o outro, uma vez que o Azure AI Search não permite que um índice seja movido.

Modelo 2: Um serviço por inquilino

Em uma arquitetura de serviço por locatário, cada locatário tem seu próprio serviço de pesquisa.

Neste modelo, a aplicação atinge o nível máximo de isolamento para os seus inquilinos. Cada serviço tem armazenamento e taxa de transferência dedicados para lidar com solicitações de pesquisa. Cada locatário tem propriedade individual das chaves de API.

Para aplicativos em que cada locatário tem uma grande pegada ou a carga de trabalho tem pouca variabilidade de locatário para locatário, o modelo de serviço por locatário é uma escolha eficaz, pois os recursos não são compartilhados entre as cargas de trabalho de vários locatários.

Um modelo de serviço por inquilino também oferece o benefício de um modelo de custo fixo previsível. Não há investimento inicial em um serviço de pesquisa inteiro até que haja um inquilino para preenchê-lo, no entanto, o custo por locatário é maior do que um modelo de índice por locatário.

O modelo de serviço por locatário é uma escolha eficiente para aplicativos com presença global. Com inquilinos geograficamente distribuídos, é fácil ter o serviço de cada inquilino na região apropriada.

Os desafios no dimensionamento desse padrão surgem quando os locatários individuais superam seu serviço. Atualmente, o Azure AI Search não oferece suporte à atualização da camada de preços de um serviço de pesquisa, portanto, todos os dados teriam que ser copiados manualmente para um novo serviço.

Modelo 3: Híbrido

Outro padrão para modelar a multilocação é misturar estratégias de índice por locatário e serviço por locatário.

Ao misturar os dois padrões, os maiores locatários de um aplicativo podem ocupar serviços dedicados, enquanto a cauda longa de locatários menores e menos ativos pode ocupar índices em um serviço compartilhado. Este modelo garante que os maiores inquilinos tenham consistentemente alto desempenho do serviço, ajudando a proteger os inquilinos menores de quaisquer vizinhos barulhentos.

No entanto, a implementação dessa estratégia depende de previsão na previsão de quais locatários precisarão de um serviço dedicado versus um índice em um serviço compartilhado. A complexidade do aplicativo aumenta com a necessidade de gerenciar esses dois modelos de multilocação.

Alcançando uma granularidade ainda mais fina

Os padrões de design acima para modelar cenários multilocatários na Pesquisa de IA do Azure assumem um escopo uniforme em que cada locatário é uma instância inteira de um aplicativo. No entanto, os aplicativos às vezes podem lidar com muitos escopos menores.

Se os modelos de serviço por locatário e índice por locatário não forem escopos suficientemente pequenos, é possível modelar um índice para obter um grau ainda mais fino de granularidade.

Para que um único índice se comporte de forma diferente para diferentes pontos de extremidade do cliente, um campo pode ser adicionado a um índice, que designa um determinado valor para cada cliente possível. Sempre que um cliente chama o Azure AI Search para consultar ou modificar um índice, o código do aplicativo cliente especifica o valor apropriado para esse campo usando o recurso de filtro do Azure AI Search no momento da consulta.

Esse método pode ser usado para obter a funcionalidade de contas de usuário separadas, níveis de permissão separados e até mesmo aplicativos completamente separados.

Nota

O uso da abordagem descrita acima para configurar um único índice para atender vários locatários afeta a relevância dos resultados da pesquisa. As pontuações de relevância da pesquisa são calculadas em um escopo de nível de índice, não em um escopo de nível de locatário, portanto, todos os dados dos locatários são incorporados nas estatísticas subjacentes das pontuações de relevância, como frequência de prazos.

Próximos passos

O Azure AI Search é uma escolha atraente para muitos aplicativos. Ao avaliar os vários padrões de design para aplicativos multilocatário, considere as várias camadas de preços e os respetivos limites de serviço para melhor adaptar a Pesquisa de IA do Azure para se adequar a cargas de trabalho e arquiteturas de aplicativos de todos os tamanhos.