Na Jitterbit, nossa missão é simplificar até mesmo os desafios de conectividade mais complexos e permitir que qualquer pessoa se conecte no mundo digital de hoje. Embora enfatizemos que você não precisa ser um desenvolvedor para usar os produtos da Jitterbit – por trás de cada grande solução de software está uma equipe de desenvolvedores fantásticos. No Jitterbit Tech Talk blog series, os membros da equipe de desenvolvimento do Jitterbit nos fornecem informações sobre como criar uma plataforma de nuvem de classe 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 você projeta e arquiteta uma plataforma de nuvem de nível empresarial altamente escalável.
A nuvem oferece às empresas uma maneira poderosa de oferecer seus produtos e serviços fáceis de acessar de qualquer lugar e em qualquer dispositivo. Ele também oferece enormes benefícios ao fornecedor, incluindo visibilidade de como sua oferta é usada, rápido desenvolvimento e implantação e reduções gerais nos custos de TI e manutenção. Como resultado, quase todos company hoje busca disponibilizar suas soluções na nuvem.
Mas há muito mais para se tornar uma verdadeira nuvem company do que instalar software em um servidor hospedado e colocar “nuvem” em seus materiais de marketing.
Recentemente, conversei 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% deles elaboram um plano inicial que seria construído em uma arquitetura na qual seus aplicativos legados seriam implantados apenas em um servidor de nuvem acessível ao público. Essa abordagem anula todos os benefícios que a nuvem tem a oferecer.
Construir uma verdadeira plataforma de nuvem multilocatário requer resolver vários tipos diferentes de desafios, como segurança, confiabilidade, escalabilidade, alta disponibilidade, tolerância a falhas, registro, monitoramento, sistema de notificação, capacidade de implantação contínua e muito mais.
No post de hoje, vamos dar uma olhada mais profunda em como lidamos com o desafio de 'escalabilidade' ao desenvolver nossa plataforma de integração de nuvem multilocatário.
A extensão da escalabilidade de um aplicativo está vinculada à sua capacidade de escalar vertical e horizontalmente. Em um ambiente de nuvem, isso significa projetar serviços que atendem a solicitações externas que escalam para que possam aproveitar sistemas de back-end internos, como bancos de dados, caches, camadas mediadoras, processos em lote (mecanismo analítico, mecanismo de recomendação) etc. curto espaço de tempo. Nem sempre é possível prever o número de usuários que acessam sua plataforma. Projetar uma arquitetura que considere isso no modelo de multilocação ajuda a tornar essa incerteza um problema genérico de escalabilidade.
Dimensionamento Vertical
A escalabilidade vertical envolve a adição de recursos como CPUs adicionais ou memória a um único nó em um sistema, e essa deve ser a primeira coisa em que você deve pensar ao dimensionar seus serviços. É muito importante projetar seus aplicativos para que eles utilizem esses recursos de maneira ideal. Considere o caso de uso comum para nossa plataforma de nuvem de integração híbrida, em que 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 em sua arquitetura como um restaurante. Um garçom anota os pedidos de uma mesa e os entrega ao chef. Enquanto o chef, o ajudante de comida e o ajudante de ônibus cuidam de atividades como cozinhar, servir e limpar, o garçom continua atendendo novos clientes e faz contas ao final do serviço.
Manter a assincronia enquanto o sistema trabalha com todos os componentes como banco de dados, cache e camada mediadora é muito importante. Passar a carga para nós de servidor altamente disponíveis em cluster que executam integrações libera os recursos para a camada de serviço receber mais solicitações e responder quando os processos são concluídos.
Dimensionamento Horizontal
A próxima consideração importante deve ser que os serviços sejam escritos de forma que não importa quantas instâncias desses serviços estão em execução e qual sistema compartilhado está executando transações em um determinado momento. Isso dá flexibilidade à nossa plataforma de nuvem para dimensionar automaticamente a camada de serviços. Cada parte do back-end é altamente disponível e autoescalável para acompanhar a demanda de crescentes contêineres de serviço.
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 dimensionamento vertical, um único restaurante pode se tornar altamente escalável adicionando mais funcionários, mas, em certo ponto, o número de recursos (cozinheiros, corredores, ajudantes de ônibus) atingirá um ponto de saturação. Para escalar ainda mais, esse negócio precisaria abrir locais adicionais que ajudariam a distribuir os clientes e equilibrar a carga.
É melhor dividir toda a plataforma em várias zonas, com cada zona se comportando como uma réplica da zona inicial. Isso nos permite usar várias zonas para equilibrar a carga das necessidades futuras.
Este modelo tem múltiplas vantagens:
1. Possível dimensionamento horizontal infinito, pois podemos trazer 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 exija segregação de metadados baseada em localização, como nos EUA, zonas EMEA, etc.
O resultado desejado aqui é que a experiência do usuário seja a mesma, não importa onde ele esteja e em que zona ele esteja. Nenhuma intervenção manual deve ser exigida de um usuário para realizar o trabalho.
No nosso nuvem de integração híbrida blog, discutimos como enfrentamos o desafio de usar uma camada mediadora de forma a suportar uma escala vertical limitada. Ao escrever nossa própria camada de conexão sem bloqueio personalizada com base no transporte HTTPS seguro, conseguimos estender a arquitetura para ter uma escala vertical de 50x. Claro, também é escalável horizontalmente. Essa combinação de dimensionamento vertical e horizontal nos deu uma camada mais barata e facilmente extensível para atender às nossas crescentes necessidades.
Otimizando o uso de componentes compartilhados:
Os próprios componentes compartilhados devem ser escaláveis e altamente disponíveis para suportar a plataforma Cloud. 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 uso de componentes compartilhados em que vários carregamentos simultâneos de alto volume podem causar problemas. A priorização pode diminuir a carga e atenuar o erro em qualquer solicitação de missão crítica. De volta ao nosso restaurante, a cozinha é um componente compartilhado e, embora o garçom possa anotar os pedidos de aperitivo, prato principal e sobremesa, a cozinha priorizará o cozimento desses itens e equilibrará sua carga.
Outra maneira de lidar com a carga pode ser o armazenamento em cache de dados que raramente são alterados para evitar um alto uso desses componentes. Se as batatas fritas forem um item popular no cardápio, o restaurante pode decidir “armazenar” um lote contínuo em vez de fritá-las na hora.
Monitoramento de componentes:
Por fim, é 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 funcionando de acordo com as necessidades da plataforma Cloud. O monitoramento pode ser externo ou iniciado pelo aplicativo, mas em ambos os casos o objetivo final é permitir que o sistema dimensione automaticamente com base na carga.
Na próxima blog post, falaremos sobre monitoramento, registro e outros elementos da arquitetura.
