Quando usar CloudHub vs. Runtime Fabric para Mulas de alto desempenho

Quando usar CloudHub vs. Runtime Fabric para Mulas de alto desempenho

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

[ad_1]

Anypoint Platform oferece várias opções para a implantação e gerenciamento de tempos de execução MuleSoft (“Mulas”). Entre os mais populares estão a plataforma como serviço (iPaaS) CloudHub de integração em nuvem totalmente gerenciada e as opções Anypoint Runtime Fabric hospedadas pelo cliente. Embora ambas as opções forneçam recursos líderes do setor e altos níveis de flexibilidade operacional, as diferenças subjacentes em como elas operam precisam ser consideradas para dimensionar e dimensionar com precisão os Mules em execução nesses modos.

Nesta postagem, examinaremos as diferenças arquitetônicas subjacentes entre os dois modelos e como isso afeta fundamentalmente as características não funcionais dos aplicativos Mule implantados. Consideramos como essas diferenças afetam as abordagens de teste de desempenho, bem como considerações para garantir que os aplicativos funcionem de maneira consistente.

Os termos ‘vCPU’ e ‘vCore’ e como eles são aplicados no contexto de Anypoint, pois são frequentemente usados ​​de forma intercambiável quando, na verdade, têm definições distintas. Uma ‘CPU’ ou ‘vCPU’ é uma unidade técnica de computação que (normalmente) equivale a um soquete ou núcleo de processador. Em comparação, um ‘núcleo’ (ou ‘vCore’) é uma unidade comercial que é como o MuleSoft Runtimes é licenciado principalmente. Embora haja ligações entre esses termos, é importante manter essa distinção entre os dois e nenhuma equivalência entre esses termos deve estar implícita. Usaremos esses termos de forma consistente nesta postagem.

Comparando o CloudHub com a arquitetura Anypoint Runtime Fabric

Tanto o CloudHub quanto o Anypoint Runtime Fabric oferecem isolamento entre os aplicativos em execução no mesmo host, mas diferem substancialmente em como isso é obtido. Para o CloudHub, isso é obtido por virtualização, por meio do uso de instâncias do AWS EC2. Para o Runtime Fabric, no entanto, isso é obtido usando a conteinerização. Isso é importante porque, no nível mais alto no CloudHub, isso efetivamente dá às implantações acesso a uma quantidade quase infinita de computação (sujeito ao seu contrato comercial), enquanto no Runtime Fabric uma implantação é configurada com uma alocação de um pool fixo – embora extensível de computação.

A tabela a seguir fornece mais detalhes sobre as principais diferenças entre as duas abordagens que provavelmente devem ser consideradas ao determinar a melhor plataforma para seu caso de uso.

Examinando CloudHub em detalhes

O CloudHub oferece sete tamanhos de trabalho pré-determinados que determinam a quantidade de memória heap (RAM) JVM e armazenamento disponível para esse trabalhador.

Embora workers maiores também ofereçam mais capacidade de computação, isso nem sempre é linear para o dimensionamento do vCore do trabalhador (núcleo! = CPU). Em vez disso, a MuleSoft usa instâncias de desempenho em burst do AWS EC2 para workers vCore fracionários, que permitem curtos períodos de alto desempenho.

As instâncias estouráveis ​​do EC2 usam um sistema de ‘crédito’, onde os períodos de atividade leve acumulam créditos que podem ser gastos para permitir um desempenho superior. Eles são ideais para aplicativos API que não estão sob carga constante.

Além disso, as instâncias são executadas no modo ‘ilimitado’ durante a primeira hora após a implantação para acelerar os processos de inicialização e aquecimento do aplicativo.

Consulte a tabela abaixo para ver o conjunto completo de tamanhos de trabalho do CloudHub:

O que é uma instância EC2 burstable?

De acordo com a AWS: “Cada instância de desempenho burstable ganha continuamente (em uma resolução de nível de milissegundo) uma taxa definida de créditos de CPU por hora, dependendo do tamanho da instância.

“Se uma instância de desempenho burstable usa menos recursos da CPU do que o necessário para a utilização da linha de base (como quando está ociosa), os créditos da CPU não utilizados são acumulados no saldo de crédito da CPU.

“Se uma instância de desempenho com capacidade de expansão precisa estourar acima do nível de utilização da linha de base, ela gasta os créditos acumulados. Quanto mais créditos uma instância de desempenho burstable acumular, mais tempo ela poderá estourar além de sua linha de base quando mais utilização da CPU for necessária ”.

Embora o dimensionamento exato do trabalhador CloudHub para a instância AWS não seja publicado (já que isso é determinado pela MuleSoft e pode mudar sem aviso prévio), para os trabalhadores apoiados por instâncias de desempenho em burst, o desempenho relativo é controlado pelo acúmulo de créditos de CPU em oposição ao número de vCPUs na instância.

Isso significa que, embora os créditos estejam disponíveis, o desempenho relativo dos workers do CloudHub de núcleo fracionário será igual. No entanto, o desempenho relativo se tornará díspar sob carga em favor de instâncias maiores com o tempo, conforme os créditos da CPU se esgotam.

Como isso se compara ao Runtime Fabric?

Para o Runtime Fabric, o desempenho é controlado diretamente por meio de uma alocação fixa de vCPU ou frações de uma CPU física / virtual.

Pode ser um valor fixo (reserva) ou definido para permitir o comportamento de burst (limite), mas é definido durante a implantação do aplicativo e não pode ser ajustado dinamicamente em um aplicativo em execução.

O Runtime Fabric oferece mais flexibilidade e maior granularidade na especificação da CPU do aplicativo e do dimensionamento da memória. Os valores de reserva da CPU tão baixos quanto 0,02 (1/50) da CPU podem ser configurados e a memória especificada independentemente da alocação da CPU. Como comparação, 1/50 de um laptop atual é quase o equivalente a um desktop Pentium por volta de 1999!

Configurando vCPUs de burst de Runtime Fabric

O recurso de vCPU com burst no Runtime Fabric permite que os recursos sejam utilizados de maneira mais eficiente, especialmente em vários aplicativos em que a carga é inconsistente. No entanto, essa flexibilidade vem com uma redução associada do comportamento determinístico, o que pode levar a um desempenho errático do aplicativo.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

Como as vCPUs de burst são compartilhadas entre vários aplicativos, a capacidade só pode ser fornecida em um modelo de “melhores tentativas”; nunca se deve confiar que esteja disponível. Além disso, outros aplicativos podem ser implantados em espaço de burst, o que significa que a capacidade de burst em um nó de trabalho pode ser reduzida com o tempo.

Conforme os nós de trabalho são preenchidos com mais aplicativos, a disponibilidade de espaço de burst será reduzida. Diferentes nós de trabalho podem ter níveis diferentes de burst disponível a qualquer momento, dependendo das implantações. Além disso, o mecanismo de contêiner subjacente do Runtime Fabric moverá réplicas entre os nós de trabalho (por exemplo, durante a aplicação de upgrades), de forma que a carga de trabalho não permanecerá consistente ao longo do tempo.

No Runtime Fabric, os aplicativos que têm requisitos de desempenho críticos não devem utilizar vCPUs de burst, pois não é possível garantir que estarão disponíveis quando necessário. Esses aplicativos devem ser dimensionados usando apenas vCPUs de ‘reserva’ garantida.

É altamente recomendável que os aplicativos e seus recursos subjacentes sejam gerenciados de forma proativa para garantir que o espaço de burst seja aproveitado de forma adequada. Isso inclui o monitoramento das alocações gerais de vCPU nos nós de trabalho do Runtime Fabric e o escalonamento horizontal ou vertical quando os limites de capacidade são atingidos.

Os aplicativos que têm requisitos críticos de desempenho não devem utilizar vCPUs de burst em RTF, pois não há garantia de que estarão disponíveis quando necessário.

Se o bursting estiver sendo usado, sugere-se “isolar” uma parte das vCPUs do trabalhador para o burst. Deve-se concordar que nenhum aplicativo será normalmente implantado nesta área cercada por anel, de modo que permanecerá disponível para explosão por outros aplicativos. Você pode optar por definir limites de burst de vCPU para aplicativos de acordo, de modo que eles não esperem receber mais vCPUs de burst do que estão disponíveis no nó de trabalho. As vCPUs ainda não têm a garantia de estar sempre disponíveis se vários aplicativos no mesmo nó de trabalho explodirem simultaneamente.

Teste de performance

Portanto, dadas as diferenças arquitetônicas discutidas, está claro que o teste de desempenho não pode ser realizado em uma base semelhante entre o CloudHub e o Runtime Fabric.

Embora o CloudHub seja um ambiente totalmente controlado, as variáveis ​​dentro do ambiente do cliente podem impactar significativamente o desempenho do Runtime Fabric (velocidade / fornecedor / arquitetura da CPU hospedada, velocidade do disco / IOPS, largura de banda da rede, etc.) Variações de desempenho geral devem ser esperadas entre os aplicativos devido a variações na complexidade do aplicativo, formato / dimensionamento da carga útil, conectividade upstream / largura de banda etc.

É sugerido que um destino de implantação (CloudHub / Runtime Fabric) seja selecionado com base nos requisitos funcionais e de conectividade e, em seguida, seja dimensionado de forma adequada para esse destino com base nos requisitos não funcionais. Qualquer aplicativo com NFRs de desempenho declarado deve ter seu desempenho especificamente testado.

No CloudHub, os aplicativos começam no modo ‘ilimitado’ durante a primeira hora, portanto, o teste de desempenho não deve começar até uma hora após a implantação do aplicativo. O teste deve ser executado durante um período longo o suficiente para esgotar os créditos de burst disponíveis e os resultados normalizados para produzir métricas de desempenho agregadas realistas. Idealmente, o carregamento de desempenho deve espelhar a modelagem de tráfego de produção esperada. (por exemplo, carga consistente, pico de carga, etc.)

Os aplicativos CloudHub podem ter seu desempenho testado de forma isolada, pois não há sobreposição de recursos ou impedimento de outros aplicativos.

Um destino de implantação deve ser selecionado com base nos requisitos funcionais e de conectividade e, em seguida, dimensionado de forma adequada para esse destino com base nos requisitos não funcionais.

Ao executar testes de desempenho em um ambiente de pré-produção, quaisquer fatores que possam fazer com que esse ambiente não seja totalmente representativo do desempenho da produção devem ser considerados. Isso inclui a aplicação de carga semelhante à de produção para outros aplicativos nessa malha se vCPUs de burst forem usadas. Se isso não for executado, resultados de teste de desempenho inválidos podem ser produzidos, pois os aplicativos em teste podem depender da capacidade de burst que não está disponível posteriormente no ambiente de produção.

Devem ser esperados tempos de inicialização de aplicativos mais lentos ao usar um nível baixo de vCPUs (<0,5 vCPUs), pois a inicialização é uma operação de computação cara. Isso também aumentará o tempo de inatividade se um aplicativo for reiniciado sem a configuração de alta disponibilidade no local.

Conclusão

A combinação de CloudHub e Anypoint Runtime Fabric oferece um grande grau de flexibilidade em termos de como e onde implantar aplicativos Mule para desbloquear dados e processos de negócios como parte de uma rede de aplicativos. No entanto, é importante garantir que a abordagem de dimensionamento correta seja usada, dependendo da plataforma de implantação que está sendo usada.

O CloudHub fornece uma plataforma poderosa para hospedar aplicativos Mule, com pouca ou nenhuma configuração necessária, com escalonamento integrado, recursos avançados de gerenciamento e inclui hospedagem e suporte. O Runtime Fabric fornece flexibilidade adicional e oportunidades para controle granular, mas mais cuidado deve ser tomado para garantir que o equilíbrio entre escalabilidade e desempenho seja mantido.

Por fim, haverá muitos fatores que influenciam a decisão de usar o CloudHub ou o Anypoint Runtime Fabric para sua rede de aplicativos. Aconselho meus clientes a considerarem primeiro os elementos técnicos – conectividade de rede e modelos de segurança provavelmente dominarão essas discussões. Em segundo lugar, considere os casos de uso do aplicativo, pois alguns serão mais adequados para a natureza burstable do CloudHub e outros para a alta densidade e granularidade do Anypoint Runtime Fabric.

É importante garantir que você esteja dimensionando suas implantações apropriadamente, de acordo com a arquitetura de destino escolhida – e não presuma que o mesmo modelo de desempenho pode ser usado para ambas as arquiteturas. Use ciclos de teste de desempenho, ou linha de base contra aplicativos semelhantes na mesma arquitetura, para ajudar a definir os níveis iniciais e, em seguida, monitorar continuamente o desempenho e ajustar de acordo.

A MuleSoft oferece uma gama de ferramentas e serviços para ajudá-lo a dimensionar suas implantações e obter o melhor desempenho de suas Mulas. Você pode descobrir mais em nossos webinars no CloudHub ou Runtime Fabric.

[ad_2]

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Luiz Presso