Escrito por Alex Zarenin, Principal Solutions Architect na Amazon Web Services e Rafet Ducic, Sr Solutions Architect na Amazon Web Services.

Neste blog post, analisaremos o recurso de Optimize CPU do Amazon Elastic Compute Cloud (Amazon EC2) e forneceremos diretrizes para a utilização desse recurso para reduzir o custo da licença do Microsoft SQL Server na Amazon Web Services (AWS) sem sacrificar o desempenho do SQL Server.

1. Introdução

Amazon EC2 oferece uma grande variedade de tipos de instância personalizados para atender a uma grande variedade de casos de uso. Os tipos de instância incluem combinações variadas de especificações de CPU, memória, armazenamento e rede. Cada tipo de instância inclui um ou mais tamanhos de instância, resultando em mais de 750 instâncias diferentes do Amazon EC2. Essa variedade de instâncias oferece aos clientes da AWS a flexibilidade de adaptar os recursos com precisão às necessidades de suas aplicações, ao mesmo tempo em que permite que os clientes escalem de forma consistente os recursos para as demandas atuais e futuras de suas cargas de trabalho específicas.

Ao considerar as cargas de trabalho do SQL Server, a seleção da instância Amazon EC2 mais adequada geralmente depende de dois fatores principais: a memória disponível (RAM) e o nível suportado de I/O dos recursos de armazenamento. Geralmente, o desempenho da carga de trabalho do SQL Server OLTP (online transaction processing) é influenciado por essas características de hardware subjacentes.

Por exemplo, o aumento da RAM permitiria que o SQL Server armazenasse mais dados em cache, enviando assim menos solicitações de leitura para o armazenamento. À medida que você adiciona mais memória, o contador de Page Life Expectancy deve aumentar e o contador Physical Disk: Average Reads/sec deve diminuir. Um bom efeito colateral é que o contador Physical Disk: Average Sec/Read (também conhecido como latência) também deve diminuir, porque quanto menos trabalho para a camada de armazenamento, mais rápido ela é capaz de responder.

Por outro lado, priorizar um subsistema de armazenamento mais rápido com operações de I/O por segundo (IOPS) suficientes garante uma latência mínima na transferência de dados e reduz as filas em todos os discos. É importante observar que o aumento dos recursos de CPU ou memória não pode compensar totalmente o impacto no desempenho de um subsistema de I/O lento. Ao se concentrar em uma infraestrutura de armazenamento robusta, as organizações podem maximizar a eficiência e a capacidade de resposta do sistema, fornecendo uma base sólida para o desempenho ideal em ambientes SQL Server.

A tabela 1 lista os atributos das maiores instâncias (“bare metal”) do Amazon EC2 geralmente recomendadas para implantações de SQL Server na AWS. A configuração de instâncias menores, dentro dos respectivos tipos, fornecerá valores fracionários para os respectivos atributos. Por exemplo, a maior instância do tipo r6idn, r6idn.32xlarge (equivalente a r6idn.metal), terá o mesmo número de vCPUs, quantidade de RAM e recursos de IOPS, conforme listado na Tabela 1 para a família r6idn. As instâncias menores do mesmo tipo, por exemplo, r6idn.16xlarge, terão metade do número de vCPUs, quantidade de RAM e IOPS suportadas da instância r6idn.32xlarge maior.

Tabela 1. Famílias de instâncias selecionadas do Amazon EC2

2. O que é o recurso Optimize CPU e quais os benefícios que ele traz?

Ocasionalmente, devido a fatores como quantidade de memória ou recursos de IOPS (consulte a Tabela 1), talvez seja necessário selecionar uma instância do Amazon EC2 com mais vCPUs do que o necessário para suas cargas de trabalho do SQL Server. Como o licenciamento do SQL Server é baseado em CPUs ativas visíveis para o sistema operacional (OS), selecionar uma instância do Amazon EC2 com mais vCPU pode resultar em maior licenciamento do SQL Server.

Para ajudá-lo a otimizar seus requisitos de licenciamento e os custos associados nessas situações, a AWS oferece um recurso chamado Optimize CPU, disponível somente para implantações de “traga sua própria licença” (BYOL). O recurso de Optimize CPU permite que você desative o hyperthreading ou desative alguns núcleos de processador para a instância do Amazon EC2, limitando assim o número de CPUs visíveis para o sistema operacional. Essa estratégia permite que você se beneficie de outros recursos da instância, como memória, rede e IOPS, enquanto reduz o número necessário de licenças.

Vamos supor que sua carga de trabalho do SQL Server exija 200.000 IOPS. Portanto, para atender a esse requisito, você seleciona a instância r6idn.16xlarge, que é caracterizada pelo conjunto de parâmetros fornecidos na Tabela 2.

Tabela 2. propriedades da instância r6idn.16xlarge

Com a configuração padrão, essa instância torna 64 vCPUs visíveis para o sistema operacional, exigindo 64 licenças do SQL Server. Supondo que a carga de trabalho do SQL Server não esteja vinculada à CPU e que a utilização da CPU seja relativamente baixa, você pode usar o recurso Optimize CPU para reduzir o número de licenças necessárias.

A tabela 3 lista várias possíveis configurações de Optimize CPU para esse caso. A primeira linha desativa o hyperthreading (threads=1), reduzindo o número de vCPUs e, correspondentemente, o número de licenças necessárias em 50%. A segunda linha obtém um resultado semelhante ao reduzir o número de núcleos. Se a utilização da CPU ainda for relativamente baixa, você poderá desativar o hyperthreading e reduzir o número de núcleos para uma redução de 75% no número de licenças do SQL Server.

Tabela 3. Otimize amostras de CPU

O recurso Optimize CPU permite que você desabilite o hyperthreading e/ou desabilite alguns núcleos. Então, qual é a melhor maneira de usar o Optimize CPU para reduzir o custo da licença sem deteriorar o desempenho do SQL Server? Para responder a essa pergunta, é necessário executar testes de desempenho em várias configurações com o recurso de Optimize CPU.

3. Configuração de teste de desempenho

Para executar os testes de desempenho, usaremos a ferramenta de benchmarking HammerDB padrão do setor usando cargas de trabalho semelhantes a TPCC que emulam bancos de dados OLTP. Usaremos instâncias r6idn.32xlarge e r6idn.16xlarge configuradas com o SQL Server 2022 Enterprise Edition e oferecendo 400.000 e 200.000 IOPS máximos, respectivamente. Para testar o desempenho na instância r6idn.32xlarge com 1 TiB de memória, geramos um banco de dados HammerDB de 8 TiB (75.000 warehouses); para uma instância r6idn.16xlarge menor com 512 GiB de RAM, geramos um banco de dados de 3,5 TiB (30.000 warehouses). Configuramos os testes de desempenho do HammerDB com a opção “Use All Warehouses” para aumentar a carga de I/O no sistema.

Para medir o desempenho do sistema de banco de dados, executamos um perfil de desempenho usando o HammerDB Autopilot com um número crescente de usuários virtuais, até o ponto em que a taxa de transação não aumenta ainda mais. Esse valor estável será aceito como o desempenho do sistema. Como o desempenho do SQL Server muda cada vez mais lentamente com o aumento do número de usuários virtuais, configuramos o Autopilot com a série de usuários virtuais com progressão exponencial. Para cada número de usuários virtuais, repetimos o teste 3 vezes e capturamos uma média de 3 execuções para obter consistência estatística.

Configuramos a implantação do SQL Server seguindo as melhores práticas do HammerDB para testes de desempenho e escalabilidade do SQL Server.

4. Resultados do teste de desempenho

4.1. Resultados do teste para r6idn.32xlarge

Considerando o tamanho da instância, usamos as seguintes séries de usuários virtuais: 181, 256, 362, 512, 724 e 1.024 em uma progressão exponencial.

4.1.1. Testes com hyperthreading ativado

Primeiro, avaliamos o desempenho do SQL Server usando a instância em sua configuração básica (128 vCPU) e depois com um número reduzido de núcleos (96 vCPU) sem alterar o hyperthreading. A Figura 1 apresenta os resultados desses testes de desempenho.

Figura 1. r6idn.32xlarge — Número variável de núcleos com hyperthreading

A Figura 2 apresenta a utilização da CPU para essa série de testes capturados usando o Amazon CloudWatch. A utilização da CPU começa em um nível relativamente baixo de cerca de 50%, mas quando o nível de carga atinge 512 usuários virtuais (VUs) ou mais, a utilização aumenta repentinamente para quase 100%.

Figura 2. r6idn.32xlarge — Número variável de núcleos com hyperthreading — Utilização da CPU

Apesar dos picos na utilização da CPU, os dois sistemas alcançaram um nível provisionado de 400.000 IOPS, conforme mostrado na Figura 3.

Figura 3. r6idn.32xlarge — Número variável de núcleos com hyperthreading — utilização de IOPS

4.1.2. Testes com hyperthreading desativado

Apesar dos picos na utilização da CPU, decidimos realizar um conjunto de testes com um número variável de núcleos com o hyperthreading desativado. Os resultados desses testes são apresentados na Figura 4.

Figura 4. r6idn.32xlarge — Número variável de núcleos sem hyperthreading

Conforme mostrado na Figura 5, à medida que reduzimos o número de núcleos ativos, a utilização da CPU aumentou de 75% com 64 núcleos ativos para 88% com 48 núcleos ativos. Como 88% de utilização da CPU é o máximo prático com o qual um DBA se sentiria confortável, paramos de testar em 48 núcleos ativos.

Figura 5. r6idn.32xlarge — Número variável de núcleos sem Hyperthreading — Utilização da CPU

Para cada um desses casos de teste, a utilização de IOPS atingiu o nível de IOPS provisionado de 400.000 para cargas com um alto número de usuários virtuais, conforme ilustrado na Figura 6.

Figura 6. r6idn.32xlarge — Número variável de núcleos sem hyperthreading — utilização de IOPS

4.1.3. Resumo dos testes de desempenho usando r6idn.32xlarge

Os resultados do teste de desempenho do SQL Server implantado em uma instância r6idn.32xlarge do Amazon EC2 estão resumidos na Tabela 4.

Tabela 4. resumo dos testes de desempenho r6idn.32xlarge

4.2. Resultados do teste para r6idn.16xlarge

A desativação do hyperthreading, bem como a desativação subsequente de alguns núcleos da CPU, teve praticamente nenhum efeito no desempenho do SQL Server, conforme mostrado pelos resultados do teste de desempenho na Tabela 4. Mas essa observação vale para instâncias do Amazon EC2 de outros tamanhos? Para resolver essa questão, executamos uma série de testes de desempenho usando o SQL Server implantado em uma instância r6idn.16xlarge.

Considerando o tamanho menor dessa instância, usamos um banco de dados HammerDB menor com a seguinte série de usuários virtuais (VUs): 64, 92, 128, 181 e 256. Os resultados do teste de desempenho para essa configuração são apresentados na Figura 7 e resumidos na Tabela 5.

Figura 7. resultados do teste de desempenho r6idn.16hlarge com e sem hyperthreading

Tabela 5. Resumo dos resultados do teste de desempenho r6idn.16hlarge

Assim como no caso anterior, desabilitar o hyperthreading e reduzir ainda mais o número de núcleos de CPU ativos não afeta o desempenho do SQL Server (dentro do nível de precisão dos testes do HammerDB, com margem de erro de 1 a 2%) até que a carga de trabalho fique dependente de CPU.

5. Efeito do recurso Optimize CPU no custo e na relação custo/desempenho

Conforme demonstrado nos testes de desempenho do SQL Server, desabilitar o hyperthreading, bem como desabilitar alguns núcleos de CPU, não traz uma redução significativa no desempenho se as cargas de trabalho do SQL Server não forem dependentes de CPU. Agora vamos ver qual efeito a aplicação do recurso Optimize CPU tem no custo da implantação do SQL Server.

Para avaliar a redução de custos devido à aplicação do recurso Optimize CPU, tivemos que considerar o custo da licença do SQL Server, que depende das opções de compra e dos descontos aplicáveis. No entanto, para os cálculos a seguir, usamos o custo anunciado da licença de assinatura da Microsoft de $5.434/ano para um pacote de 2 núcleos, o que resulta em $226 por núcleo por mês para o SQL Server Enterprise Edition. Com essa suposição, a Tabela 6 reflete o custo mensal do SQL Server implantado em r6idn.32xlarge.

Tabela 6. Benefícios do Optimize CPU para SQL Server em r6idn.32xlarge

De acordo com as descobertas na Tabela 6, a otimização da CPU pode levar a uma redução de 56,25% no número de licenças necessárias do SQL Server. Isso se traduz em uma redução de mais de 38% no custo mensal de implantação do SQL Server, reduzindo o custo por 1.000 TPM de $23,69 para apenas $14,68, tudo sem afetar visivelmente o desempenho do SQL Server.

Se uma diminuição no desempenho do SQL Server de menos de 5% for aceitável, a otimização adicional da CPU poderá reduzir o número de licenças necessárias em 62,5%. Isso se traduz em uma redução de quase 43% no custo mensal, reduzindo o custo por 1.000 TPM de $23,69 para apenas $14,21.

A tabela 7 reflete os resultados de desempenho e custo de uma implantação do SQL Server em uma instância r6idn.16xlarge do Amazon EC2. Esses resultados seguem o mesmo padrão, mas, nesse caso, podemos reduzir ainda mais o número de núcleos ativos sem um efeito negativo no desempenho do SQL Server.

Tabela 7. Otimize os benefícios da CPU para o SQL Server em r6idn.16xlarge

De acordo com as descobertas na Tabela 7, a otimização da CPU pode levar a uma redução de 62,5% no número de licenças necessárias do SQL Server. Isso se traduz em uma redução de quase 43% no custo mensal de implantação do SQL Server, reduzindo o custo por 1.000 TPM de 22,90 USD para apenas 13,22 USD, tudo isso sem afetar notavelmente o desempenho do SQL Server.

Se uma diminuição no desempenho do SQL Server de menos de 4% for aceitável, a otimização adicional da CPU poderá reduzir o número de licenças necessárias em 68,75%. Isso se traduz em uma redução de quase 47% no custo mensal, reduzindo o custo por 1.000 TPM de $22,90 para apenas $12,56.

6. Conclusão

Os testes de desempenho do SQL Server em várias configurações, conforme discutido neste blog post, dão suporte às seguintes conclusões e permitem que recomendações para o uso eficaz do recurso Optimize CPU:

• A desativação do hyperthreading resulta em uma redução de custo de aproximadamente 35% (SQL Server EE) ou 50% no número de licenças necessárias do SQL Server sem um efeito negativo no desempenho.
• A redução adicional do número de núcleos de CPU ativos reduz ainda mais o custo em até aproximadamente 47%, com redução mínima (menos de 5%) ou nenhuma redução no desempenho do SQL Server.
• A aplicação do recurso Optimize CPU resulta em uma redução significativa no custo por 1.000 TPM.
• Ao aplicar o recurso Optimize CPU, mantenha IOPS por CPU na faixa de 7.000 a 8.000; algo abaixo desses limites pode reduzir o desempenho do SQL Server.

Esses resultados foram obtidos usando cargas de trabalho sintéticas do tipo OLTP. Seus resultados podem ser diferentes dependendo do tipo de sua carga de trabalho específica. Além disso, as estimativas de custo e redução de custos são calculadas usando os custos básicos de licença da Microsoft. Se os custos de sua licença forem diferentes devido a diferentes opções de licenciamento ou descontos negociados, sua redução de custo poderá ser maior ou menor do que a apresentada neste blog post.

Este blog em português é uma tradução do blog original em inglês.

Autores

Alex Zarenin é Principal Solutions Architect na Amazon Web Services. Ele trabalha com empresas de serviços financeiros projetando e implementando uma ampla variedade de soluções técnicas. Com experiência de domínio em tecnologias da Microsoft, Alex tem mais de 30 anos de experiência técnica nos setores comercial e público. Alex tem um Ph.D. em Ciência da Computação pela NYU.

Rafet Ducic é Sr Solutions Architect na Amazon Web Services (AWS). Ele aplica seus mais de 20 anos de experiência técnica para ajudar clientes de indústrias e automotivas globais a fazer a transição de suas cargas de trabalho para a nuvem de forma econômica e com desempenho ideal. Com experiência em tecnologias de banco de dados e licenciamento da Microsoft, Rafet é especialista em orientar empresas de todos os tamanhos em direção a custos operacionais reduzidos e altos padrões de desempenho.

Tradutores e Revisores

Luciano Bernardes trabalha atualmente como Sr Solutions Architect na AWS, especializado em workloads Microsoft. Com 17 anos de experiência no mercado, trabalhou a maior parte em consultoria técnica especializada em Microsoft, em clientes de várias verticais, com demandas voltadas para infraestrutura on-premises e em nuvem. Como SA, trabalha próximo a clientes e parceiros de consultoria em U.S. e LATAM, para apoiá-los em tomadas de decisão e revisão de arquitetura de workoads Microsoft na nuvem AWS.

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 15 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.