Resumo Técnico: Calibração do Modelo de Custo de Consulta em Máquinas Virtuais Confidenciais

Declaração do Problema

A adoção de Computação Confidencial, especificamente Máquinas Virtuais Confidenciais (CVMs) como o AMD SEV-SNP, oferece um caminho prático para executar Sistemas de Gerenciamento de Banco de Dados (DBMSs) legados sem modificações no código-fonte, ao mesmo tempo em que protege os dados em uso. No entanto, consultas analíticas em CVMs sofrem sobrecargas de desempenho substanciais em comparação com as máquinas virtuais convencionais não criptografadas (KVMs).

Pesquisas anteriores concentraram-se amplamente em realizar benchmarks desses atrasos, em vez de otimizá-los. Este artigo identifica a causa raiz como um descompasso entre hardware e software: os otimizadores de consulta tradicionais dependem de modelos de custo calibrados para KVMs, que não se sustentam mais em ambientes CVM. Consequentemente, os otimizadores classificam incorretamente os planos de execução, selecionando estratégias que são eficientes em KVMs, mas subótimas em CVMs.

Os autores atribuem este descompasso a duas propriedades arquiteturais específicas do SEV-SNP:

1. Sobrecarga de Movimentação de Dados: Em CVMs, as transferências de dados entre armazenamento e memória envolvem processamento de criptografia e cópia para "buffers de salto" (bounce-buffer) (estagiamento de dados em memória compartilhada). Esta sobrecarga é não uniforme; diferentes planos de consulta (por exemplo, Hash Join vs. Nested Loop) induzem diferentes padrões de movimentação de dados, levando a penalidades variáveis.
2. Sobrecarga de Tradução Relacionada ao RMP: O SEV-SNP utiliza uma Tabela de Mapeamento Reverso (RMP) para validar a propriedade e as permissões de página durante a tradução de endereços. Isso introduz latência nos caminhos de acesso à memória, particularmente para operações de acesso aleatório, como varreduras de índice (index scans) e nested loops intensivos em busca (probes). Evidências experimentais mostram que isso se manifesta como um aumento significativo nos Ciclos Por Instrução (CPI) devido à tradução e verificações de memória protegida, em vez de um aumento no número total de instruções executadas.

Metodologia

Os autores propõem uma calibração de custo leve e consciente de CVM, integrada diretamente ao modelo de custo do otimizador de consulta. Em vez de redesenhar o mecanismo de execução, a abordagem ajusta os custos estimados dos operadores para refletir os preços relativos reais das vias de execução no SEV-SNP.

Mecanismo Central

A calibração aumenta as fórmulas de custo padrão (que tipicamente decompõem o custo em CPU, Memória e E/S) com dois termos de sobrecarga adicionais derivados de proxies físicos já disponíveis para o otimizador:

1. Custo de Movimentação de Dados (datamovecost): Este termo penaliza os operadores com base no seu tamanho de conjunto de trabalho ($ws$) e um fator de transbordamento ($x$). O fator de transbordamento é calculado quando o conjunto de trabalho excede o orçamento de cache efetivo. O custo é modelado como $ws \cdot \eta_{dm} \cdot \sigma(x)$, onde $\eta_{dm}$ é uma penalidade calibrada e $\sigma(x)$ ativa o termo quando a pegada ativa extrapola o cache, disparando o tráfego de memória criptografada e interações de bounce-buffer.
2. Custo de Sobrecarga de RMP (rmptcost): Este termo penaliza os operadores com base na intensidade de acesso à página ($a$) e localidade. É modelado como $a \cdot \eta_{rmp} \cdot (1 + \alpha_{rmp} \cdot \sigma(x))$. Isso captura o aumento de latência na tradução de endereços e validação de RMP, o que afeta desproporcionalmente operadores de acesso aleatório (ex: Index Scans, Nested Loop Joins com buscas de índice).

Calibração Específica por Operador

Os autores aplicam estes termos a operadores específicos no PostgreSQL:

• Varreduras (Sequencial, Bitmap, Índice): Varreduras sequenciais e de bitmap são cobradas principalmente pela movimentação de dados quando o conjunto de trabalho transborda. Varreduras de índice são cobradas tanto pela movimentação de dados quanto pela sobrecarga de RMP, pois a travessia de índices envolve perseguição de ponteiros (pointer chasing) e acessos a páginas não sequenciais que disparam verificações de tradução.
• Joins:
  • Nested Loop: Cobrado por movimentação de dados e sobrecarga condicional de RMP se o lado interno for orientado a índice.
  • Hash Join: O modelo de custo contabiliza explicitamente o tamanho da tabela de hash em relação ao Último Nível de Cache (LLC). Se a tabela de hash exceder o LLC, o operador incorre em significativa movimentação de dados e custos de tradução.
  • Merge Join: Cobrado principalmente por movimentação de dados, com custos de RMP condicionais se as entradas carecerem de localidade.
• Materialize/Memoize: Cobrado com base no tamanho do estado intermediário bufferizado.

Os parâmetros para estes termos de custo são ajustados usando um subconjunto representativo de consultas de cada carga de trabalho, visando uma calibração robusta em diferentes cenários sem uma otimização exaustiva.

Contribuições Principais

1. Identificação de Distorções de Desempenho: O artigo demonstra que as verificações de RMP e as sobrecargas de movimentação de dados são os principais impulsionadores das distorções de desempenho observadas pelo otimizador em CVMs. Ele fornece evidência empírica (via inflação de CPI e análise de atividade de bounce-buffer) de que estas sobrecargas dependem do operador e são sensíveis ao plano.
2. Modelo de Custo Calibrado para CVM: Os autores propõem uma extensão prática ao modelo de custo que injeta penalidades direcionadas para o acesso aleatório sensível ao RMP e movimentação de dados. Isso preserva a arquitetura do otimizador enquanto torna as decisões de plano mais fiéis às realidades da CVM.
3. Implementação e Avaliação: A calibração é implementada no PostgreSQL 16.9. A avaliação abrange benchmarks OLAP padrão (JOB, CEB, Stack e TPC-DS) em hardware AMD SEV-SNP.

Resultados

A avaliação mostra que a calibração reduz significativamente a lacuna de desempenho entre KVM e SEV-SNP:

• Economia de Tempo: A calibração reduz o tempo total de execução em todas as cargas de trabalho em 3,54% a 48,35%.
  • JOB: melhoria de 6,90%.
  • CEB: melhoria de 17,14%.
  • Stack: melhoria de 48,35%.
  • TPC-DS: melhoria de 3,54%.
• Desempenho entre Ambientes: Nas cargas de trabalho CEB e Stack, a execução SEV-SNP calibrada supera a linha de base KVM não calibrada, indicando que a correção do modelo de custo pode recuperar eficiência suficiente para ultrapassar a linha de base não criptografada em cenários específicos.
• Cobertura de Consultas: Uma fração substancial de consultas beneficiou-se da calibração (variando de 38,8% a 62,5% entre as cargas de trabalho).
• Distribuição de Latência: A calibração desloca a distribuição de latência das consultas para baixo, reduzindo a latência mediana e comprimindo a dispersão (desvio padrão). Por exemplo, na carga de trabalho Stack, a latência máxima caiu de 50,80s para 13,84s, e o desvio padrão diminuiu de 7,00s para 2,24s.

Significância e Alegações

O artigo alega que a principal barreira para cargas de trabalho de alto desempenho em CVMs não é apenas o overhead bruto de hardware, mas o desalinhamento do modelo de custo do software. Ao recalibrar o otimizador para compreender os custos específicos de movimentação de dados e verificações de RMP, o sistema pode selecionar automaticamente planos de execução que minimizem essas penalidades.

Os autores enfatizam que sua abordagem é leve: ela introduz um overhead negligenciável porque apenas modifica a lógica de estimativa de custo do otimizador, sem adicionar novos mecanismos de tempo de execução. Eles posicionam este trabalho como um passo necessário além do benchmarking, movendo-se em direção à otimização ao abordar o "descompasso entre hardware e software" que faz com que DBMSs legados tenham desempenho inferior em ambientes confidenciais. O artigo conclui que, embora as características da carga de trabalho influenciem o grau de melhoria, uma calibração razoável do modelo de custo é suficiente para mitigar significativamente a lacuna de desempenho entre KVMs e CVMs.