Managed Postgres offre des options de mise à l’échelle flexibles pour s’adapter aux exigences de votre charge de travail. Avec plus de 50 types d’instance basés sur NVMe au choix, vous pouvez faire évoluer indépendamment le CPU, la mémoire et le stockage afin d’optimiser les performances et les coûts pour votre use case spécifique.
Types d’instance et flexibilité
- Plus de 50 types d’instance disponibles, avec des configurations optimisées pour la puissance de calcul, la mémoire et le stockage
- Stockage basé sur NVMe sur tous les types d’instance pour des E/S disque stables et hautes performances
- Mise à l’échelle indépendante des ressources : choisissez le bon équilibre entre CPU, mémoire et stockage en fonction de votre charge de travail
Choisir le bon type d’instance
| Type de charge de travail | CPU | Mémoire | Stockage | Instance recommandée |
|---|
| Optimisée pour le calcul | Élevé | Moyen | Moyen | Optimisée pour le calcul (nombre élevé de vCPU) |
| Optimisée pour la mémoire (ensemble de travail important) | Moyen | Élevé | Moyen | Optimisée pour la mémoire (ratio mémoire/CPU élevé) |
| Optimisée pour le stockage (grands jeux de données, E/S intensives) | Moyen | Moyen | Élevé | Optimisée pour le stockage (capacité NVMe élevée) |
Pour des raisons de sécurité, il se peut que vous ne puissiez pas basculer vers des types d’instance dont le stockage est proche de votre capacité de stockage actuellement utilisée. Choisissez toujours des types d’instance offrant une marge de capacité par rapport à votre utilisation actuelle afin d’éviter tout problème.
Fonctionnement de la mise à l’échelle
Processus de mise à l’échelle
-
Provisionnement de l’instance de secours : une nouvelle instance de secours est créée avec le type d’instance cible (CPU, mémoire et configuration du stockage)
-
Restauration à partir des sauvegardes S3 : l’instance de secours est initialisée en restaurant la sauvegarde la plus récente stockée dans S3
-
WAL replay en parallèle : l’instance de secours applique toutes les modifications du Write-Ahead Log (WAL) depuis la sauvegarde à l’aide de mécanismes de restauration parallèles fournis par WAL-G
- WAL-G permet des restore operations rapides et parallélisées
- Le créateur de WAL-G fait partie de l’équipe Ubicloud, avec laquelle nous avons noué un partenariat, ce qui garantit une expertise approfondie et une optimisation poussée
-
Rattrapage de la réplication : l’instance de secours rattrape l’instance primaire en transmettant en continu et en appliquant les modifications WAL en cours
-
Basculement : une fois l’instance de secours entièrement synchronisée, un basculement contrôlé la promeut au rang de nouvelle instance primaire
- C’est la seule étape qui entraîne une indisponibilité (~30 secondes)
- Toutes les connexions actives sont interrompues pendant le basculement
- Les clients doivent se reconnecter une fois le basculement terminé
-
Mise hors service de l’ancienne instance : l’instance d’origine est mise hors service une fois le basculement terminé
Durée de la mise à l’échelle
- Restauration de la sauvegarde : temps nécessaire pour restaurer la sauvegarde complète la plus récente depuis S3 vers la nouvelle instance
- WAL replay : temps nécessaire pour rejouer les modifications WAL incrémentielles depuis la dernière sauvegarde complète
- Restauration parallèle : les mécanismes de restauration parallèle de WAL-G accélèrent considérablement le processus
Le temps de restauration peut varier de quelques minutes à quelques heures, mais la durée de maintenance ou d’indisponibilité reste très faible (environ 30 secondes seulement).
Indisponibilité minimaleVotre application subira environ 30 secondes d’indisponibilité pendant le basculement, quelle que soit la durée totale du processus de mise à l’échelle. Toutes les opérations de restauration et de rattrapage s’effectuent en arrière-plan sur l’instance de secours.
Restauration parallèle avec WAL-G
- Téléchargement et décompression en parallèle : plusieurs segments de sauvegarde sont récupérés depuis S3 et décompressés simultanément
- WAL replay efficace : les changements incrémentaux du WAL sont appliqués en parallèle lorsque c’est possible
- Streaming optimisé : streaming direct depuis le stockage S3, sans copies intermédiaires
- Restauration rapide : bien que la durée totale dépende du volume de données, l’approche parallélisée rend le processus particulièrement rapide
Ces optimisations réduisent considérablement le temps nécessaire pour mettre en service la nouvelle instance de secours. Plus important encore, la restauration s’effectue entièrement en arrière-plan — votre application ne subit une indisponibilité que pendant la brève fenêtre de basculement d’environ 30 secondes.
Démarrer une opération de mise à l’échelle
- Accédez à l’onglet Paramètres de votre instance
- Dans la section Mise à l’échelle, faites défiler jusqu’à Taille du service
- Sélectionnez le type d’instance cible
- Vérifiez les modifications, puis cliquez sur “Appliquer les modifications”
Stratégies de mise à l’échelle
Mise à l’échelle verticale
- Contrôle précis : choisissez parmi plus de 50 types d’instance pour ajuster finement le CPU, la mémoire et le stockage
- Optimisation de la charge de travail : sélectionnez des configurations optimisées pour votre charge de travail spécifique (à forte intensité de calcul, de mémoire ou de stockage)
- Maîtrise des coûts : payez uniquement pour les ressources dont vous avez besoin, sans surprovisionnement
Répliques de lecture pour la mise à l’échelle horizontale
- Déchargez les requêtes de lecture sur des instances de réplique de lecture dédiées
- Chaque réplique de lecture est une instance Postgres entièrement indépendante, avec ses propres ressources de calcul et sa propre mémoire
- Les répliques de lecture transmettent les modifications du WAL depuis le stockage objet pour assurer une réplication efficace
Cette approche est idéale pour les applications présentant un ratio lecture/écriture élevé, comme les tableaux de bord de reporting, les requêtes analytiques ou les points de terminaison de l’API à forte intensité de lecture.
Mise à l’échelle du CDC pour l’intégration ClickHouse
- Mise à l’échelle des workers CDC de 1 à 24 cœurs CPU
- La mémoire est automatiquement dimensionnée à 4x le nombre de cœurs CPU
- Réglez la mise à l’échelle via l’API OpenAPI de ClickPipes
Cela vous permet d’optimiser le débit de réplication indépendamment des ressources de votre instance Postgres.
Mise à l’échelle automatique
Ressources complémentaires
