Série Tech Talk: Projetando para Escala em sua Nuvem Multi-tenant

Na Jitterbit, nossa missão é simplificar até os desafios de conectividade mais complexos e permitir que qualquer pessoa se conecte no mundo digital de hoje. Embora ressaltemos que você não precisa ser um desenvolvedor para usar os produtos da Jitterbit, por trás de toda grande solução de software há uma equipe de desenvolvedores fantásticos. Na série Jitterbit Tech Talk blog, membros da equipe de desenvolvimento da Jitterbit nos dão uma visão sobre a construção de uma plataforma em nuvem de nível empresarial e os desafios que eles tiveram que resolver em relação à multilocação, escalabilidade e segurança.

Esta semana, Pankaj Arora, nosso Diretor Sênior de Tecnologia, analisa como projetar e arquitetar uma plataforma em nuvem de nível corporativo altamente escalável.

A Nuvem oferece às empresas uma maneira poderosa de disponibilizar seus produtos e serviços com fácil acesso de qualquer lugar e em qualquer dispositivo. Ela também proporciona enormes benefícios ao fornecedor, incluindo visibilidade sobre como sua oferta é utilizada, rápido desenvolvimento e implantação e reduções gerais nos custos de TI e manutenção. Como resultado, quase todas as empresas hoje buscam disponibilizar suas soluções na Nuvem.

Mas há muito mais para se tornar uma verdadeira empresa de nuvem do que instalar software em um servidor hospedado e colar “Nuvem” em seus materiais de marketing.

Recentemente, eu estava conversando com um estrategista de tecnologia e ele observou que cerca de 75% das empresas gostariam de migrar suas ofertas corporativas legadas para a nuvem. Surpreendentemente, 90% delas elaboram um plano inicial que seria construído sobre uma arquitetura na qual seus aplicativos legados seriam simplesmente implantados em um servidor de nuvem publicamente acessível. Essa abordagem anula todos os benefícios que a Nuvem tem a oferecer.

Construir uma verdadeira plataforma em nuvem multi-inquilino exige a resolução de vários tipos diferentes de desafios, como segurança, confiabilidade, escalabilidade, alta disponibilidade, tolerância a falhas, registro em log, monitoramento, sistema de notificações, capacidade de implantação contínua e muito mais.

No post de hoje, faremos uma análise mais profunda de como lidamos com o desafio da ‘escalabilidade’ ao desenvolver nossa plataforma de integração em nuvem multilocatária.

A extensão da escalabilidade de uma aplicação está atrelada à sua capacidade de escalar vertical e horizontalmente. Em um ambiente de Nuvem, isso significa projetar serviços que atendem a solicitações externas e que escalam para que possam aproveitar sistemas de backend internos, como bancos de dados, caches, camadas de mediação, processos em lote (mecanismo analítico, mecanismo de recomendação), etc., para lidar com solicitações praticamente infinitas em um espaço de tempo razoavelmente curto. Nem sempre é possível prever o número de usuários acessando sua plataforma. Projetar uma arquitetura que leve isso em conta no modelo multi-tenant ajuda a transformar essa incerteza em um problema genérico de escalabilidade.

Escalonamento vertical

A escalabilidade vertical envolve a adição de recursos, como CPUs ou memória adicionais, a um único nó em um sistema, e esta deve ser a primeira coisa em que você deve pensar ao dimensionar seus serviços. É muito mais importante projetar seus aplicativos para que eles utilizem esses recursos de forma ideal. Considere o caso de uso comum para nossa plataforma de nuvem de integração híbrida, onde as operações de integração são atendidas por um nó de servidor local ou em nuvem. Aqui, os serviços devem receber uma solicitação para executar integrações, passar a solicitação para os nós do servidor e continuar atendendo a mais solicitações. A camada de serviços não deve ser dependente ou bloqueada pelos processos que ocorrem em várias camadas do sistema. Como tal, é muito importante ter uma arquitetura assíncrona orientada a eventos.

Uma maneira simples de entender a arquitetura assíncrona é pensar na sua arquitetura como um restaurante. Um garçom pega os pedidos de uma mesa e os repassa para o chef. Enquanto o chef, o entregador de comida e o ajudante de limpeza cuidam de atividades como cozinhar, servir e limpar, o garçom continua atendendo novos clientes e faz a cobrança no final do atendimento.

Manter a assincronicidade enquanto o sistema trabalha com todos os componentes, como banco de dados, cache e camada de mediador, é muito importante. Distribuir a carga para nós de servidores clusterizados e de alta disponibilidade que executam integrações libera recursos para a camada de serviço receber mais solicitações e responder quando os processos forem concluídos.

Escalabilidade horizontal

A próxima consideração importante deve ser que os serviços sejam escritos de forma que não importe quantas instâncias desses serviços estejam em execução e qual sistema compartilhado esteja realizando transações em um determinado momento. Isso dá à nossa plataforma em nuvem flexibilidade para dimensionar automaticamente a camada de serviços. Cada parte do backend é altamente disponível e escalável automaticamente para acompanhar a demanda de contêineres de serviços em crescimento.

No entanto, não podemos ter contêineres infinitos executando camadas de serviço que usam componentes compartilhados. Esse não é o design ideal. Vamos voltar ao nosso exemplo de restaurante. Com o escalonamento vertical, um único restaurante pode se tornar altamente escalável adicionando mais funcionários, mas, a um determinado ponto, o número de recursos (cozinheiros, atendentes, ajudantes de limpeza) atingirá um ponto de saturação. Para escalar ainda mais, esse negócio precisaria abrir locais adicionais que ajudassem a distribuir os clientes e equilibrar a carga.

É melhor dividir toda a plataforma em várias zonas, com cada zona funcionando como uma réplica da zona inicial. Isso nos permite usar várias zonas para balancear a carga de necessidades futuras.

Este modelo tem várias vantagens:

1. Possível escalabilidade horizontal infinita, já que podemos incorporar qualquer número de zonas

2. Tolerância a falhas, caso toda a zona falhe devido a um desastre natural

3. Separação de dados, no caso de uma plataforma SaaS que requer segregação de metadados baseada em localização, como para as zonas dos EUA, EMEA, etc.

O resultado desejado aqui é que a experiência do usuário seja a mesma, independentemente de onde ele esteja e de qual zona ele acesse. Nenhuma intervenção manual deve ser necessária por parte do usuário para realizar o trabalho.

No nosso nuvem de integração híbrida blog, discutimos como encontramos o desafio de usar uma camada mediadora de forma que ela suportasse escala vertical limitada. Ao escrevermos nossa própria camada de conexão personalizada e não bloqueante baseada em transporte HTTPS seguro, conseguimos estender a arquitetura para ter uma escala vertical 50 vezes maior. É claro que ela também é escalável horizontalmente. Essa combinação de escala vertical e horizontal nos proporcionou uma camada mais barata e facilmente extensível para atender às nossas necessidades crescentes.

Otimizando o uso de componentes compartilhados:

Componentes compartilhados devem ser escaláveis e altamente disponíveis por si só para dar suporte à plataforma em nuvem. Mas os componentes compartilhados são compartilhados e, como resultado, não são tão escaláveis quanto a camada de serviços. É muito importante cuidar de alguns componentes que podem ser sensíveis a uma carga alta, por exemplo, bancos de dados. Um modelo pode ser priorizar e enfileirar o usosage de componentes compartilhados onde várias cargas altas simultâneas e de alto volume podem causar problemas. A priorização pode reduzir a carga e mitigar erros em solicitações críticas de missão. De volta ao nosso restaurante, a cozinha é um componente compartilhado e, embora o garçom possa anotar o pedido de um cliente para entrada, prato principal e sobremesa, a cozinha priorizará o preparo desses itens e equilibrará sua carga.

Outra forma de lidar com a carga é armazenar em cache dados que mudam raramente para evitar uma alta usage desses componentes. Se batatas fritas forem um item popular no menu, o restaurante pode decidir “fazer cache” de um lote contínuo em vez de fritá-las sob encomenda.

Monitoramento de componentes:

Finalmente, é muito importante monitorar cada componente e conhecer suas limitações. O sistema deve ser capaz de aumentar a largura de banda automaticamente e no momento certo para manter os sistemas em funcionamento de acordo com as necessidades da plataforma em nuvem. O monitoramento pode ser externo ou iniciado pelo aplicativo, mas em ambos os casos o objetivo final é permitir que o sistema faça o dimensionamento automático com base na carga.

No próximo post blog, falaremos sobre monitoramento, registro de logs e outros elementos da arquitetura.