Résumé Technique : Calibrage du Modèle de Coût de Requête dans les Machines Virtuelles Confidentielles

Énoncé du Problème

L'adoption de l'informatique confidentielle (Confidential Computing), spécifiquement des Machines Virtuelles Confidentielles (CVM) telles qu'AMD SEV-SNP, offre une voie pratique pour exécuter des systèmes de gestion de bases de données (SGBD) hérités sans modification du code source tout en protégeant les données en cours d'utilisation. Cependant, les requêtes analytiques dans les CVM souffrent de surcoûts de performance substantiels par rapport aux machines virtuelles conventionnelles non chiffrées (KVM).

Les recherches antérieures se sont largement concentrées sur le benchmarking de ces ralentissements plutôt que sur leur optimisation. Cet article identifie la cause profonde comme étant un décalage matériel-logiciel : les optimiseurs de requêtes traditionnels reposent sur des modèles de coût calibrés pour les KVM, qui ne sont plus valables dans les environnements CVM. Par conséquent, les optimiseurs classent mal les plans d'exécution, sélectionnant des stratégies qui sont efficaces en KVM mais sous-optimales en CVM.

Les auteurs attribuent ce décalage à deux propriétés architecturales spécifiques de SEV-SNP :

1. Surcoût de Mouvement de Données : Dans les CVM, les transferts de données entre le stockage et la mémoire impliquent un traitement de chiffrement et une copie via des « buffers de rebond » (staging des données dans la mémoire partagée). Ce surcoût est non uniforme ; différents plans de requête (par exemple, Hash Join vs Nested Loop) induisent des schémas de mouvement de données différents, entraînant des pénalités variables.
2. Surcoût lié à la RMP (Reverse Map Table) : SEV-SNP utilise une table de correspondance inverse (RMP) pour valider la propriété et les permissions des pages lors de la traduction d'adresses. Cela introduit une latence dans les chemins d'accès à la mémoire, particulièrement pour les opérations d'accès aléatoire comme les scans d'index et les boucles imbriquées (nested loops) intensives en recherche (probe-heavy). Les preuves expérimentales montrent que cela se manifeste par une augmentation significative du nombre de cycles par instruction (CPI) due à la traduction et aux vérifications de la mémoire protégée, plutôt que par une augmentation du nombre total d'instructions exécutées.

Méthodologie

Les auteurs proposent un calibrage de coût léger et conscient des CVM, intégré directement dans le modèle de coût de l'optimiseur de requêtes. Plutôt que de redessiner le moteur d'exécution, l'approche ajuste les coûts estimés des opérateurs pour refléter les prix relatifs réels des chemins d'exécution dans SEV-SNP.

Mécanisme Central

Le calibrage augmente les formules de coût standard (qui décomposent généralement le coût en CPU, Mémoire et E/S) avec deux termes de surcoût supplémentaires dérivés de proxys physiques déjà disponibles pour l'optimiseur :

1. Coût de Mouvement de Données (datamovecost) : Ce terme pénalise les opérateurs en fonction de leur taille de l'ensemble de travail ($ws$) et d'un facteur de débordement ($x$). Le facteur de débordement est calculé lorsque l'ensemble de travail dépasse le budget de cache effectif. Le coût est modélisé par $ws \cdot \eta_{dm} \cdot \sigma(x)$, où $\eta_{dm}$ est une pénalité calibrée et $\sigma(x)$ active le terme lorsque l'empreinte active sort du cache, déclenchant le trafic de mémoire chiffrée et les interactions de buffer de rebond.
2. Coût de Surcharge RMP (rmptcost) : Ce terme pénalise les opérateurs en fonction de l'intensité d'accès aux pages ($a$) et de la localité. Il est modélisé par $a \cdot \eta_{rmp} \cdot (1 + \alpha_{rmp} \cdot \sigma(x))$. Cela capture l'augmentation de la latence de la traduction d'adresses et de la validation RMP, qui affecte de manière disproportionnée les opérateurs à accès aléatoire (ex: Index Scans, Nested Loop Joins avec recherche d'index).

Calibrage Spécifique aux Opérateurs

Les auteurs appliquent ces termes à des opérateurs spécifiques dans PostgreSQL :

• Scans (Séquentiel, Bitmap, Index) : Les scans séquentiels et de bitmap sont principalement facturés pour le mouvement de données lorsque l'ensemble de travail déborde. Les scans d'index sont facturés pour le mouvement de données et la surcharge RMP, car la traversée d'index implique une poursuite de pointeurs (pointer chasing) et des accès aux pages non séquentiels qui déclenchent des vérifications de traduction.
• Joins (Jointures) :
  • Nested Loop : Facturé pour le mouvement de données et la surcharge RMP conditionnelle si le côté interne est piloté par un index.
  • Hash Join : Le modèle de coût tient explicitement compte de la taille de la table de hachage par rapport au dernier niveau de cache (LLC). Si la table de hachage dépasse le LLC, l'opérateur subit un mouvement de données et des coûts de traduction importants.
  • Merge Join : Principalement facturé pour le mouvement de données, avec des coûts RMP conditionnels si les entrées manquent de localité.
• Materialize/Memoize : Facturé en fonction de la taille de l'état intermédiaire mis en mémoire tampon.

Les paramètres de ces termes de coût sont ajustés à l'aide d'un sous-ensemble représentatif de requêtes de chaque charge de travail, visant un calibrage robuste à travers différents scénarios sans optimisation exhaustive.

Contributions Clés

1. Identification des Distorsions de Performance : L'article démontre que les vérifications RMP et les surcoûts de mouvement de données sont les principaux moteurs des distorsions de performance visibles par l'optimiseur dans les CVM. Il fournit des preuves empiriques (via l'inflation du CPI et l'analyse de l'activité des buffers de rebond) que ces surcoûts dépendent de l'opérateur et du plan.
2. Modèle de Coût Calibré pour CVM : Les auteurs proposent une extension pratique du modèle de coût qui injecte des pénalités ciblées pour l'accès aléatoire sensible à la RMP et le mouvement de données. Cela préserve l'architecture de l'optimiseur tout en rendant les décisions de plan plus fidèles aux réalités des CVM.
3. Implémentation et Évaluation : Le calibrage est implémenté dans PostgreSQL 16.9. L'évaluation couvre des benchmarks OLAP standards (JOB, CEB, Stack, et TPC-DS) sur du matériel AMD SEV-SNP.

Résultats

L'évaluation montre que le calibrage réduit considérablement l'écart de performance entre KVM et SEV-SNP :

• Gains de Temps : Le calibrage réduit le temps d'exécution total à travers les charges de travail de 3,54 % à 48,35 %.
  • JOB : amélioration de 6,90 %.
  • CEB : amélioration de 17,14 %.
  • Stack : amélioration de 48,35 %.
  • TPC-DS : amélioration de 3,54 %.
• Performance Trans-Environnement : Sur les charges de travail CEB et Stack, l'exécution SEV-SNP calibrée surpasse la ligne de base KVM non calibrée, indiquant que la correction du modèle de coût peut récupérer suffisamment d'efficacité pour surpasser la ligne de base non chiffrée dans certains scénarios.
• Couverture des Requêtes : Une fraction substantielle des requêtes a bénéficié du calibrage (allant de 38,8 % à 62,5 % à travers les charges de travail).
• Distribution de la Latence : Le calibrage déplace la distribution de la latence des requêtes vers le bas, réduisant la latence médiane et compressant l'écart (écart-type). Par exemple, dans la charge de travail Stack, la latence maximale est passée de 50,80s à 13,84s, et l'écart-type a diminué de 7,00s à 2,24s.

Signification et Revendications

L'article soutient que le principal obstacle aux charges de travail de bases de données haute performance dans les CVM n'est pas seulement le surcoût matériel brut, mais le désalignement du modèle de coût logiciel. En recalibrant l'optimiseur pour qu'il comprenne les coûts spécifiques du mouvement de données et des vérifications RMP, le système peut automatiquement sélectionner des plans d'exécution qui minimisent ces pénalités.

Les auteurs soulignent que leur approche est légère : elle introduit un surcoût négligeable car elle ne modifie que la logique d'estimation du coût de l'optimiseur sans ajouter de nouveaux mécanismes d'exécution. Ils positionnent ce travail comme une étape nécessaire au-delà du simple benchmarking, progressant vers l'optimisation en traitant le « décalage matériel-logiciel » qui cause la sous-performance des SGBD hérités dans les environnements confidentiels. L'article conclut que, bien que les caractéristiques de la charge de travail influencent le degré d'amélioration, un calibrage raisonnable du modèle de coût est suffisant pour atténuer de manière significative l'écart de performance entre les KVM et les CVM.