Health Samurai Lab : Mise à l'échelle horizontale et verticale d'Aidbox

8 cœurs CPU, un seul serveur FHIR. Faut-il attribuer tous les cœurs à une seule instance Aidbox ou les répartir entre plusieurs ? Nous avons comparé les deux approches — la mise à l'échelle verticale (plus de cœurs par instance) et la mise à l'échelle horizontale (plus d'instances avec moins de cœurs).

Dans notre article précédent « Game of Pools », nous avons montré qu'Aidbox se met à l'échelle de façon presque linéaire à mesure que vous ajoutez des cœurs CPU. Mais la croissance verticale linéaire n'est que la moitié de l'histoire. Que se passe-t-il lorsque vous distribuez ces mêmes cœurs entre plusieurs instances ?

Fonctionnement d'Aidbox en grappe

Aidbox s'appuie fortement sur des caches : moteur de validation, routage, abonnements, et plus encore. Avec la mise à l'échelle horizontale, le principal défi consiste à maintenir ces caches synchronisés entre les instances. La solution habituelle est un service externe comme Redis.

Aidbox adopte une approche différente — aucun cache externe n'est requis. La synchronisation entre instances fonctionne via le mécanisme LISTEN/NOTIFY de PostgreSQL : lorsqu'une instance met à jour des données, les autres reçoivent une notification et invalident leur cache. PostgreSQL, déjà requis pour le fonctionnement, joue également le rôle de bus d'événements. Aucune infrastructure supplémentaire n'est nécessaire.

Si votre instance est entièrement statique (vous ne créez pas de ressources système à l'exécution), vous pouvez désactiver complètement la synchronisation des caches. Cela procure un léger gain de performance en éliminant la surcharge liée à LISTEN/NOTIFY.

Configuration des tests

Tous les tests ont été exécutés sur une seule machine. Les instances Aidbox se trouvent derrière nginx (least_conn). Base de données : une seule instance PostgreSQL 18. La charge est générée par k6 (5 minutes, scénario CRUD sur 9 types de ressources FHIR). Avant chaque exécution : préchauffage de 30 secondes + refroidissement de 60 secondes. Le nombre d'utilisateurs virtuels (VU) est proportionnel aux cœurs CPU (37 VU par cœur, 300 VU pour 8 cœurs) afin de maintenir une latence comparable entre les configurations.

Mise à l'échelle verticale : une instance sur 1, 2, 4 ou 8 cœurs

Avant de répartir les cœurs entre plusieurs instances, établissons une référence — comment Aidbox se met à l'échelle verticalement lorsque tous les cœurs sont attribués à une seule instance :

Doubler les CPU double le RPS. La latence reste stable (moy. 70–90 ms) parce que la charge croît proportionnellement à la capacité. À 8 cœurs, le multiplicateur est de 7,0× au lieu d'un idéal de 8× — des pertes dues à la contention pour les ressources partagées (mémoire, GC, PostgreSQL, réseau). Un résultat solide : la mise à l'échelle verticale d'Aidbox est prévisible et efficace.

Mise à l'échelle horizontale : répartition de 8 cœurs entre instances

L'expérience clé. Prenons les mêmes 8 cœurs et distribuons-les différemment :

Efficacité de la mise à l'échelle horizontale

La dégradation est progressive jusqu'à 4×2 et abrupte à 8×1 :

• 1×8 → 2×4 : −5,8 % (5747 → 5412)
• 2×4 → 4×2 : −7,5 % (5412 → 5004)
• 4×2 → 8×1 : −21,5 % (5004 → 3926)
• 1×8 → 8×1 : −31,7 % au total

La colonne « Efficacité » indique quelle fraction du maximum théorique (8 × 813 = 6 500 RPS) chaque configuration atteint, triée par efficacité :

Utilisation de la mémoire

La mise à l'échelle horizontale comporte un coût caché : chaque instance JVM entraîne sa propre surcharge mémoire. Huit instances à un seul cœur consomment nettement plus de RAM qu'une seule instance à huit cœurs. Avec la hausse des prix du matériel (en partie due à l'engouement pour l'IA), cela peut augmenter sensiblement le coût d'exploitation d'Aidbox.

• Passer de 1×8 à 2×4 n'ajoute que +0,5 Go en moyenne, mais 8×1 nécessite environ 5× plus de mémoire, tant en valeur moyenne qu'en valeur de pointe
• Conclusion pratique : 2×4 est souvent le point d'équilibre entre tolérance aux pannes et budget RAM, tandis que 8×1 ne se justifie que dans des cas d'isolation très spécifiques

Points à retenir

1. La mise à l'échelle verticale l'emporte en RPS brut. Une seule instance sur 8 cœurs tire le maximum du matériel. La répartition horizontale entraîne toujours une surcharge.
2. La mise à l'échelle horizontale est avantageuse lorsque la tolérance aux pannes est nécessaire. La configuration 2×4 ne perd que 6 % de RPS par rapport à 1×8, mais offre la redondance et le meilleur P99 (80,5 ms contre 87–90 ms). Si une instance tombe en panne, l'autre continue de traiter les requêtes.
3. Le point d'inflexion est à 2 CPU par instance. Les configurations avec 2+ CPU (2×4, 4×2) maintiennent une efficacité de 79–85 %. En dessous de 2 CPU, la surcharge de la JVM devient critique — 8×1 perd ~40 % d'efficacité et affiche le pire P99 de toutes les configurations.
4. Le coût de l'isolation. Le RPS total d'une configuration horizontale est toujours inférieur à celui d'une configuration verticale avec le même nombre de cœurs. Chaque JVM entraîne sa propre surcharge : démarrage des caches, GC, réseau, consommation mémoire de base. Plus les instances sont petites, plus la part de surcharge dans le budget total de ressources est grande.

La suite

Dans le prochain article, nous quitterons le banc d'essai pour observer le comportement d'Aidbox dans un environnement proche de la production. Nous calculerons également le coût réel d'exploitation d'Aidbox dans l'infonuagique.

Voir aussi : Health Samurai Lab : Game of Pools.