Architecture de référence : application OLTP 3-tiers
Les applications métier classiques (commandes, paiements, stocks) exécutent un grand nombre de transactions courtes, mono-ligne et critiques pour la cohérence (OLTP). Cet arbre montre pas à pas, à partir de l'identification du profil de charge, quand introduire la base relationnelle principale, un pooler de connexions, des réplicas de lecture, une couche de cache, la sauvegarde + PITR et la supervision. L'objectif n'est pas de « tout ajouter d'emblée » mais d'ajouter le bon composant à mesure que chaque goulot est avéré.
Quel est votre profil de charge : mix transactionnel et exigences de cohérence ?
La première décision d'une architecture OLTP est de savoir si la charge est réellement transactionnelle (un mix court d'écritures et de lectures exigeant ACID). Les données sont-elles naturellement relationnelles et la cohérence critique (argent, stock, commandes), la charge est-elle surtout en lecture, ou la charge est-elle encore très faible ?
- Transactions courtes, cohérence forte (argent/stock/commandes)
- Les lectures dominent largement, peu d'écritures, et le trafic augmente
- Charge très faible ; la configuration la plus simple suffit-elle ?
Avez-vous choisi le moteur de base principal, et l'échelle vous inquiète-t-elle ?
Un moteur relationnel est la bonne fondation pour le cœur transactionnel (PostgreSQL, MySQL/InnoDB, Oracle, SQL Server). Une fois le moteur choisi, la question suivante est la montée en charge : une seule instance suffit-elle pour l'instant, ou le nombre de connexions et la charge en lecture augmentent-ils ?
- Le moteur est choisi ; une seule instance suffit pour l'instant
- Le nombre de connexions a explosé, les ressources s'épuisent
- La charge en lecture augmente et sollicite l'instance d'écriture principale
Comment ferez-vous monter les lectures en charge : réplica ou cache ?
Si la charge en lecture sollicite l'instance principale, il existe deux options complémentaires. Les lectures tolérant des données légèrement en retard, comme les rapports/listes, peuvent être acheminées vers un réplica de lecture ; si les mêmes données 'chaudes' sont demandées sans cesse, un cache à latence de l'ordre de la microseconde (Redis) soulage la base.
- Nombreuses lectures de rapports/listes ; un léger retard est acceptable
- Les mêmes données populaires sont lues encore et encore
Recommandation : commencez avec un primaire unique + pool + sauvegarde
Gardez l'architecture simple au départ : une seule instance relationnelle principale, un pool de connexions devant elle et des sauvegardes régulières suffisent. N'ajoutez de la complexité que lorsqu'un goulot mesuré l'impose.
Recommandation : ajoutez un pooler de connexions
En OLTP, lorsque chaque instance applicative ouvre ses propres connexions, la base principale étouffe sous la charge mémoire et d'ordonnancement de milliers de connexions. Placer un pooler entre les deux partage un petit nombre de connexions réelles à la base entre de nombreuses requêtes applicatives.
Recommandation : ajoutez un réplica de lecture
Les écritures restent sur le primaire tandis que le trafic en lecture seule (rapports, listes, recherche) est acheminé vers un ou plusieurs réplicas asynchrones alimentés par le primaire. Cela libère le primaire pour les écritures et les lectures critiques pour la cohérence.
Recommandation : ajoutez une couche de cache (Redis)
Si les mêmes données populaires (sessions, catalogue, profils, fragments de page) sont lues de façon répétée, placez un cache en mémoire devant la base et servez la plupart des lectures sans jamais atteindre la base. La latence baisse et la base principale est soulagée.