🔝 Retour au Sommaire

19.2.2. Azure Database for PostgreSQL

Introduction

Microsoft Azure propose plusieurs options pour héberger PostgreSQL dans le cloud via son service Azure Database for PostgreSQL. Contrairement à AWS qui propose deux moteurs distincts (RDS et Aurora), Azure a fait évoluer son offre avec différentes architectures de déploiement adaptées à divers cas d'usage.

Dans cette section, nous allons explorer les différentes offres Azure pour PostgreSQL, comprendre leurs architectures, leurs avantages et comment choisir la solution adaptée à vos besoins.

Vue d'ensemble de l'Offre Azure PostgreSQL

Microsoft Azure propose trois options principales pour PostgreSQL :

Azure Database for PostgreSQL - Single Server (Legacy - en voie de dépréciation)
Azure Database for PostgreSQL - Flexible Server (Recommandé)
Azure Database for PostgreSQL - Hyperscale (Citus) (Distribué)

Évolution de l'Offre

┌─────────────────────────────────────────────────────────┐
│         Timeline Azure Database for PostgreSQL          │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  2017    Single Server lancé                            │
│           │                                             │
│           ▼                                             │
│  ─────────●──────────────────────────────────           │
│           │    Service managé basique                   │
│           │                                             │
│  2021    Flexible Server lancé                          │
│           │           │                                 │
│           │           ▼                                 │
│  ─────────●───────────●────────────────────             │
│           │           │    Architecture améliorée       │
│           │           │    + Contrôle + Performance     │
│           │           │                                 │
│  2024    Single Server → Dépréciée                      │
│           │           │                                 │
│           ▼           │                                 │
│  ─────────X           ●────────────────────►            │
│       (EOL 2025)      │    Migration vers               │
│                       │    Flexible Server              │
│                       │                                 │
│  Hyperscale (Citus) - En parallèle pour distributed     │
│  ─────────────────────────────────────────────►         │
│           Workloads massivement distribués              │
└─────────────────────────────────────────────────────────┘

Note importante : Single Server est en fin de vie et sera retiré en mars 2025. Microsoft recommande fortement de migrer vers Flexible Server.

Azure Database for PostgreSQL - Flexible Server

Qu'est-ce que Flexible Server ?

Flexible Server est l'offre actuelle et recommandée d'Azure pour PostgreSQL. Elle offre plus de contrôle, de performances et de flexibilité que l'ancienne version Single Server.

Architecture de Flexible Server

┌──────────────────────────────────────────────────────────┐
│                    Azure Region                          │
│                                                          │
│  ┌─────────────────────────────────────────────────────┐ │
│  │              Virtual Network (VNet)                 │ │
│  │                                                     │ │
│  │  ┌────────────────────────────────────────────────┐ │ │
│  │  │            Subnet PostgreSQL                   │ │ │
│  │  │                                                │ │ │
│  │  │   ┌─────────────────────────────────────┐      │ │ │
│  │  │   │  Azure DB for PostgreSQL            │      │ │ │
│  │  │   │  Flexible Server                    │      │ │ │
│  │  │   │                                     │      │ │ │
│  │  │   │  ┌───────────────┐                  │      │ │ │
│  │  │   │  │   Instance    │                  │      │ │ │
│  │  │   │  │   PostgreSQL  │                  │      │ │ │
│  │  │   │  │   (Compute)   │                  │      │ │ │
│  │  │   │  └───────┬───────┘                  │      │ │ │
│  │  │   │          │                          │      │ │ │
│  │  │   │          ▼                          │      │ │ │
│  │  │   │  ┌───────────────┐                  │      │ │ │
│  │  │   │  │   Stockage    │                  │      │ │ │
│  │  │   │  │   Premium SSD │                  │      │ │ │
│  │  │   │  │   (Managed)   │                  │      │ │ │
│  │  │   │  └───────────────┘                  │      │ │ │
│  │  │   └─────────────────────────────────────┘      │ │ │
│  │  │                                                │ │ │
│  │  │   (Option Haute Disponibilité)                 │ │ │
│  │  │   ┌─────────────────────────────────────┐      │ │ │
│  │  │   │  Standby Replica                    │      │ │ │
│  │  │   │  (Zone Redundant ou Same Zone)      │      │ │ │
│  │  │   │                                     │      │ │ │
│  │  │   │  ┌───────────────┐                  │      │ │ │
│  │  │   │  │   Réplication │                  │      │ │ │
│  │  │   │  │   Synchrone   │◄─────────────────┼──────┼─┤ │
│  │  │   │  └───────────────┘                  │      │ │ │
│  │  │   └─────────────────────────────────────┘      │ │ │
│  │  └────────────────────────────────────────────────┘ │ │
│  └─────────────────────────────────────────────────────┘ │
│                                                          │
│  ┌─────────────────────────────────────────────────────┐ │
│  │  Azure Backup (Sauvegardes automatiques)            │ │
│  │  Rétention : 7-35 jours                             │ │
│  └─────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘

Concepts Clés Azure

Avant de plonger dans les détails, voici quelques concepts Azure importants :

Resource Group (Groupe de Ressources)

Conteneur logique pour organiser les ressources Azure
Permet de gérer, facturer et sécuriser les ressources ensemble
Toutes les ressources Azure doivent appartenir à un Resource Group

Virtual Network (VNet)

Réseau privé virtuel dans Azure
Isolation réseau pour vos ressources
Équivalent d'un VPC dans AWS

Availability Zone (Zone de Disponibilité)

Datacenter physiquement séparé dans une même région
Protection contre les pannes de datacenter
Latence très faible entre zones (< 2ms)

Caractéristiques Principales de Flexible Server

1. Versions PostgreSQL Supportées

Flexible Server supporte les versions majeures suivantes :

PostgreSQL 11 (support étendu)
PostgreSQL 12
PostgreSQL 13
PostgreSQL 14
PostgreSQL 15
PostgreSQL 16
PostgreSQL 17 (selon disponibilité)

Mise à jour : Flexible Server facilite les mises à jour majeures avec un temps d'arrêt minimal.

2. Options de Compute (Calcul)

Flexible Server propose plusieurs niveaux de performance :

Burstable (Charges Variables)

Série B : B1ms, B2s, B2ms, B4ms, B8ms, B12ms, B16ms, B20ms
vCPU : 1 à 20 vCPU
RAM : 2 GB à 80 GB
Cas d'usage : Développement, test, charges légères intermittentes
Avantage : Coût réduit, crédits CPU accumulés pendant les périodes d'inactivité

General Purpose (Usage Général)

Série D : D2s_v3, D4s_v3, D8s_v3, D16s_v3, D32s_v3, D48s_v3, D64s_v3
vCPU : 2 à 64 vCPU
RAM : 8 GB à 256 GB
Cas d'usage : Production standard, charges équilibrées CPU/Mémoire
Ratio : 1 vCPU pour 4 GB RAM

Memory Optimized (Optimisé Mémoire)

Série E : E2s_v3, E4s_v3, E8s_v3, E16s_v3, E32s_v3, E48s_v3, E64s_v3
vCPU : 2 à 64 vCPU
RAM : 16 GB à 432 GB
Cas d'usage : Bases volumineuses, cache important, analytique
Ratio : 1 vCPU pour 8 GB RAM

Exemple de dimensionnement :

Charge	SKU Recommandé	Specs	Prix approximatif
Développement	B2ms	2 vCPU, 8 GB	~60€/mois
Production Petite	D4s_v3	4 vCPU, 16 GB	~250€/mois
Production Moyenne	D8s_v3	8 vCPU, 32 GB	~500€/mois
Production Intensive	E16s_v3	16 vCPU, 128 GB	~1200€/mois

3. Stockage

Flexible Server utilise des disques Azure Premium SSD :

Caractéristiques du Stockage

Taille : 32 GB à 32 TB (extensible)
IOPS : Jusqu'à 20 000 IOPS
Débit : Jusqu'à 1 024 MB/s
Type : Premium SSD (P4 à P80)
Auto-scaling : Croissance automatique possible

Performance par Taille

Taille Stockage	IOPS de Base	IOPS Max (Burst)	Débit
32-128 GB	500-1100	3500	125 MB/s
256 GB	1100	3500	125 MB/s
512 GB	2300	3500	150 MB/s
1 TB	5000	5000	200 MB/s
2 TB	7500	7500	250 MB/s
4 TB+	16000-20000	-	900-1024 MB/s

Stockage Optimisé IOPS :

Permet d'allouer des IOPS supplémentaires indépendamment de la taille
Jusqu'à 80 000 IOPS et 4 000 MB/s de débit
Utile pour charges I/O intensives sans sur-provisionner le stockage

4. Haute Disponibilité (HA)

Flexible Server propose deux modes de haute disponibilité :

Zone-Redundant HA (Recommandé)

┌───────────────────────────────────────────────────┐
│              Azure Region (ex: West Europe)       │
│                                                   │
│  ┌──────────────────┐      ┌──────────────────┐   │
│  │ Availability     │      │ Availability     │   │
│  │ Zone 1           │      │ Zone 2           │   │
│  │                  │      │                  │   │
│  │ ┌──────────┐     │      │ ┌──────────┐     │   │
│  │ │ Primary  │     │      │ │ Standby  │     │   │
│  │ │ Instance │◄──────────►│ │Instance  │     │   │
│  │ └────┬─────┘     │ Sync │ └────┬─────┘     │   │
│  │      │           │ Repl │      │           │   │
│  │      ▼           │      │      ▼           │   │
│  │ ┌──────────┐     │      │ ┌──────────┐     │   │
│  │ │ Premium  │     │      │ │ Premium  │     │   │
│  │ │   SSD    │     │      │ │   SSD    │     │   │
│  │ └──────────┘     │      │ └──────────┘     │   │
│  └──────────────────┘      └──────────────────┘   │
│                                                   │
│  Protection contre : Panne matériel, Panne Zone   │
└───────────────────────────────────────────────────┘

Caractéristiques :

Instance primaire dans Zone 1
Standby synchrone dans Zone 2
Réplication synchrone des données
Failover automatique en 60-120 secondes
RPO = 0 (aucune perte de données)
RTO < 2 minutes
Protection contre les pannes de zone entière

Same-Zone HA

Primaire et standby dans la même zone de disponibilité
Coût légèrement inférieur
Protection contre les pannes matérielles uniquement
Pas de protection contre panne de zone
Failover similaire (60-120s)

Aucune HA

Instance unique sans réplication
Coût minimal
Non recommandé pour production
Utilisez uniquement pour dev/test

Comparaison HA :

Aspect	Zone-Redundant	Same-Zone	Aucune HA
Coût	2× instance + stockage	2× instance + stockage	1×
RPO	0 (zéro perte)	0 (zéro perte)	Dernière sauvegarde
RTO	< 2 minutes	< 2 minutes	Temps de restauration
Protection Zone	✅ Oui	❌ Non	❌ Non
Protection Matériel	✅ Oui	✅ Oui	❌ Non
Production	✅ Recommandé	⚠️ Acceptable	❌ Non

5. Read Replicas (Réplicas de Lecture)

Flexible Server supporte jusqu'à 5 Read Replicas :

Fonctionnement

Réplication asynchrone depuis le serveur primaire
Peut être dans la même région ou dans une autre région (Geo-Replicas)
Indépendant de la configuration HA
Utilisé pour scalabilité en lecture et disaster recovery

Cas d'Usage

Décharger les lectures : Rapports, analytics, BI
Géo-distribution : Servir des utilisateurs dans différentes régions
Disaster Recovery : Réplica dans une autre région comme backup

Caractéristiques

Lag de réplication : Quelques secondes à quelques minutes (asynchrone)
Promotion possible en serveur indépendant (pour DR)
Configuration indépendante (peut avoir une SKU différente)

Exemple d'architecture avec Read Replicas :

┌────────────────────────────────────────────────────────┐
│                  Region Primaire (West Europe)         │
│                                                        │
│  ┌─────────────┐       ┌─────────────┐                 │
│  │  Primary    │──────►│ Read Replica│                 │
│  │  (HA Zone-  │       │  (Same      │                 │
│  │  Redundant) │       │  Region)    │                 │
│  └─────────────┘       └─────────────┘                 │
│         │                                              │
└─────────┼──────────────────────────────────────────────┘
          │
          │ Geo-Replication
          ▼
┌────────────────────────────────────────────────────────┐
│             Region Secondaire (North Europe)           │
│                                                        │
│  ┌─────────────┐       ┌─────────────┐                 │
│  │ Read Replica│       │ Read Replica│                 │
│  │ (Geo)       │       │ (Geo)       │                 │
│  └─────────────┘       └─────────────┘                 │
│                                                        │
│  Cas d'usage : DR, Latence réduite pour utilisateurs   │
└────────────────────────────────────────────────────────┘

6. Sauvegardes et Restauration

Sauvegardes Automatiques

Fréquence : Sauvegardes complètes + logs de transactions
Rétention : 7 jours (gratuit) à 35 jours (payant)
Type : Backup incrémental basé sur snapshots
Stockage : Stockage géo-redondant ou localement redondant

Géo-Redondance des Backups

Option de copier les sauvegardes dans une région jumelée
Protection contre une panne régionale complète
Restauration possible dans la région de backup

Point-in-Time Restore (PITR)

Restauration à n'importe quelle seconde dans la période de rétention
Crée un nouveau serveur (l'original n'est pas modifié)
Utile pour récupération après erreur humaine

Sauvegardes Manuelles

Via Azure Portal, CLI ou API
Conservées indéfiniment (jusqu'à suppression manuelle)
Utile avant migrations majeures

Processus de Restauration :

Choisir un point de restauration (date/heure exacte)
Azure crée un nouveau serveur avec les données restaurées
Vérifier l'intégrité des données
Basculer l'application vers le nouveau serveur
(Optionnel) Supprimer l'ancien serveur

7. Options de Réseau

Flexible Server offre deux modes de connectivité :

Private Access (VNet Integration) - Recommandé

Le serveur est déployé dans votre VNet
Accès uniquement depuis le VNet (ou VNets appairés)
Pas d'exposition Internet
Utilise un endpoint privé (Private Link)
Sécurité maximale

Architecture Private Access :

┌─────────────────────────────────────────────┐
│           Virtual Network (VNet)            │
│                                             │
│  ┌────────────────────────────────────────┐ │
│  │   Subnet App (10.0.1.0/24)             │ │
│  │   ┌──────────┐   ┌──────────┐          │ │
│  │   │  Web App │   │  API     │          │ │
│  │   └────┬─────┘   └────┬─────┘          │ │
│  └────────┼──────────────┼────────────────┘ │
│           │              │                  │
│           └──────┬───────┘                  │
│                  │ Communication Privée     │
│  ┌───────────────▼────────────────────────┐ │
│  │   Subnet PostgreSQL (10.0.2.0/24)      │ │
│  │   ┌─────────────────────────────┐      │ │
│  │   │ Azure DB for PostgreSQL     │      │ │
│  │   │ (Flexible Server)           │      │ │
│  │   └─────────────────────────────┘      │ │
│  └────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
       Aucun accès depuis Internet

Public Access (Firewall Rules)

Le serveur a une adresse IP publique
Accès contrôlé par des règles de pare-feu (whitelist IP)
Peut autoriser des services Azure spécifiques
Moins sécurisé, mais plus simple pour débuter

Règles de Pare-feu :

Exemples de règles :
┌────────────────────────────────────────────────────┐
│ Nom                 | IP Début    | IP Fin         │
├────────────────────────────────────────────────────┤
│ Office Network      | 203.0.113.1 | 203.0.113.254  │
│ VPN Gateway         | 198.51.100.5| 198.51.100.5   │
│ Azure Services      | 0.0.0.0     | 0.0.0.0        │
│ Home Developer      | 192.0.2.42  | 192.0.2.42     │
└────────────────────────────────────────────────────┘

Recommandation : Utilisez Private Access pour tout environnement de production. Public Access peut être acceptable pour développement/test avec des règles restrictives.

8. Sécurité

Authentification

PostgreSQL native : Utilisateur/mot de passe
Azure Active Directory (Entra ID) : Authentification centralisée avec AAD
- Single Sign-On (SSO)
- Authentification multi-facteurs (MFA)
- Gestion centralisée des identités
- Rôles Azure RBAC

Exemple AAD :

-- L'utilisateur AAD peut se connecter avec son identité Azure
-- Pas besoin de mot de passe PostgreSQL séparé
psql "host=myserver.postgres.database.azure.com \
      user=alice@contoso.com \
      dbname=mydb sslmode=require"

Chiffrement

En transit : SSL/TLS obligatoire par défaut
- TLS 1.2 minimum
- Certificats gérés par Azure
Au repos : Chiffrement automatique avec Azure Storage Service Encryption
- Clés gérées par Microsoft (par défaut)
- Customer-Managed Keys (CMK) : Utiliser Azure Key Vault pour vos propres clés
- Chiffrement transparent (pas d'impact performance)

Règles de Sécurité

Network Security Groups (NSG) : Firewall au niveau subnet
Service Endpoints : Communication sécurisée entre services Azure
Private Link : Connexion privée via VNet
Azure Firewall : Protection réseau centralisée

Auditing et Conformité

Azure Security Center : Recommandations de sécurité
Azure Policy : Application de règles de gouvernance
Diagnostic Logs : Exportation vers Log Analytics
Compliance : Certifications ISO, SOC, HIPAA, GDPR

9. Paramètres Serveur (Server Parameters)

Flexible Server permet de modifier de nombreux paramètres PostgreSQL :

Catégories de Paramètres

Statiques : Nécessitent un redémarrage (ex: shared_buffers)
Dynamiques : Applicables immédiatement (ex: work_mem)

Paramètres Modifiables Importants

Compute et Mémoire :
- shared_buffers
- work_mem
- maintenance_work_mem
- effective_cache_size

Connexions :
- max_connections
- idle_in_transaction_session_timeout

Autovacuum :
- autovacuum
- autovacuum_max_workers
- autovacuum_naptime

Performance :
- random_page_cost
- effective_io_concurrency
- checkpoint_timeout

Logging :
- log_statement
- log_duration
- log_min_duration_statement

Paramètres Non Modifiables

Certains paramètres sont gérés par Azure et non modifiables :

port (toujours 5432)
wal_level (géré pour la réplication)
max_wal_senders
Configuration liée au stockage

10. Extensions PostgreSQL

Flexible Server supporte de nombreuses extensions :

Extensions Préinstallées

Core Extensions :
- pg_stat_statements (monitoring)
- pgcrypto (cryptographie)
- uuid-ossp (génération UUID)
- citext (texte insensible à la casse)
- hstore (key-value store)
- btree_gin, btree_gist (index)

Analytique :
- tablefunc
- pg_trgm (similarité texte)
- fuzzystrmatch

Data Types :
- ltree (arbre hiérarchique)
- cube
- isn
- pgstattuple

Extensions Populaires Disponibles

PostGIS : Données géospatiales
TimescaleDB : Séries temporelles
pgvector : Vecteurs pour IA/ML
pg_partman : Gestion de partitions
pg_cron : Planification de tâches
pg_repack : Maintenance sans verrous

Installation d'Extension :

-- Lister les extensions disponibles
SELECT * FROM pg_available_extensions;

-- Installer une extension
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;  
CREATE EXTENSION IF NOT EXISTS postgis;

Note : Certaines extensions nécessitent des paramètres serveur spécifiques et un redémarrage.

11. Monitoring et Observabilité

Azure Monitor Integration

Flexible Server est intégré nativement avec Azure Monitor :

Métriques Disponibles :

CPU Utilization : Pourcentage d'utilisation CPU
Memory Usage : Consommation mémoire
Storage Used : Espace disque utilisé
Storage Percent : Pourcentage d'utilisation
IO Consumption : Utilisation des IOPS
Active Connections : Nombre de connexions
Network In/Out : Trafic réseau
Replication Lag : Décalage des réplicas
Failed Connections : Tentatives échouées

Alertes

Création d'alertes sur n'importe quelle métrique :

Exemples d'alertes critiques :
- CPU > 80% pendant 5 minutes
- Storage > 90%
- Active Connections > 90% de max_connections
- Replication Lag > 60 secondes
- Failed Connections > 100 en 5 minutes

Diagnostic Logs

Exportation des logs PostgreSQL vers :

Log Analytics Workspace : Requêtes KQL avancées
Storage Account : Archivage long terme
Event Hub : Streaming vers systèmes tiers

Types de Logs :

PostgreSQL Logs : Requêtes, erreurs, connexions
Query Store : Historique des requêtes et performances
Azure Activity Logs : Opérations sur la ressource

Insights et Analyse

Workbooks : Dashboards personnalisés
Query Performance Insight : Top requêtes lentes
Intelligent Performance : Recommandations automatiques
- Index manquants
- Requêtes lentes
- Problèmes de paramètres

Azure Database for PostgreSQL - Hyperscale (Citus)

Qu'est-ce que Hyperscale (Citus) ?

Hyperscale est une architecture distribuée basée sur l'extension open-source Citus qui transforme PostgreSQL en une base de données scale-out horizontale.

Concept de Sharding Transparent

┌─────────────────────────────────────────────────────────┐
│            Application (Connexion unique)               │
└────────────────────┬────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────┐
│               Coordinator Node (Routeur)                │
│  • Reçoit les requêtes                                  │
│  • Analyse et distribue les requêtes                    │
│  • Agrège les résultats                                 │
└────┬──────────────┬──────────────┬──────────────────────┘
     │              │              │
     ▼              ▼              ▼
┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
│ Worker 1 │  │ Worker 2 │  │ Worker 3 │  │ Worker N │
│          │  │          │  │          │  │          │
│ Shard    │  │ Shard    │  │ Shard    │  │ Shard    │
│ 1-256    │  │ 257-512  │  │ 513-768  │  │ 769-1024 │
└──────────┘  └──────────┘  └──────────┘  └──────────┘

Chaque Worker stocke une portion des données (shards)  
Les requêtes sont parallélisées automatiquement

Architecture Hyperscale

Composants :

Coordinator Node : Point d'entrée unique, gère le routage
Worker Nodes : Stockent et traitent les données en parallèle
Shards : Partitions distribuées des tables

Cas d'Usage de Hyperscale

✅ Multi-tenant SaaS : Un shard par tenant (isolation)
✅ Real-time Analytics : Requêtes parallèles sur gros volumes
✅ Time-series Data : Données chronologiques massives
✅ High-throughput OLTP : Milliers de transactions/seconde
✅ Data Warehousing : Agrégations sur pétaoctets

Tables Distribuées vs Tables de Référence

Tables Distribuées

Partitionnées (sharded) sur les workers
Choisir une distribution key : colonne pour partitionner (ex: tenant_id, user_id)
Requêtes filtrées sur la clé = rapides (routage vers un seul worker)
Requêtes sans la clé = scan de tous les workers

-- Créer une table distribuée
SELECT create_distributed_table('events', 'user_id');

Tables de Référence

Répliquées sur tous les workers
Pour tables petites et utilisées dans beaucoup de jointures
Ex: tables de référence, lookup tables

-- Créer une table de référence
SELECT create_reference_table('countries');

Performances Hyperscale

Scaling :

Scale-out : Ajouter des workers (jusqu'à 20 workers)
Scale-up : Augmenter la taille des workers
Rebalancing : Redistribution automatique des shards

Performances typiques :

Millions de lignes/seconde en ingestion
Sous-seconde pour requêtes analytiques sur milliards de lignes
Parallélisation automatique des requêtes

Limitations Hyperscale

❌ Complexité accrue : Conception différente (choisir bonnes clés de distribution)
❌ Certaines features limitées : Foreign keys entre tables distribuées
❌ Coût : Plus cher (coordinator + multiple workers)
❌ Over-kill : Pour bases < 100 GB, Flexible Server suffit

Quand Utiliser Hyperscale ?

Données > 100 GB et croissance continue
Besoin de performances extrêmes en lecture et écriture
Architecture multi-tenant avec isolation
Charge hautement parallélisable

Sinon, privilégiez Flexible Server.

Comparaison : Flexible Server vs Hyperscale

Aspect	Flexible Server	Hyperscale (Citus)
Architecture	Single-node (avec HA optionnel)	Multi-node distribué
Scaling	Vertical (compute/storage)	Horizontal (ajout de workers)
Capacité Max	32 TB, 64 vCPU, 432 GB RAM	Pétaoctets, 20+ workers
Complexité	Simple	Élevée
Performances	Très bonnes	Exceptionnelles (parallèle)
Cas d'usage	90% des applications	Big Data, SaaS multi-tenant
Coût	Modéré	Élevé
Compatibilité PostgreSQL	100%	~98% (quelques limitations)

Comparaison Azure vs AWS

Flexible Server vs RDS PostgreSQL

Aspect	Azure Flexible Server	AWS RDS PostgreSQL
HA Cross-Zone	Zone-Redundant HA	Multi-AZ
Failover	60-120s	60-120s
Read Replicas	5 max	5 max
Stockage Max	32 TB	64 TB
IOPS Max	80 000 (optimisé)	256 000 (io2)
Réseau	VNet Integration	VPC
Coût	Similaire	Similaire
Serverless	❌ Non	❌ Non

Hyperscale vs Aurora PostgreSQL

Aspect	Azure Hyperscale	AWS Aurora PostgreSQL
Architecture	Distribué (Citus)	Stockage distribué
Scaling	Horizontal (workers)	Vertical + 15 replicas
Stockage Max	Pétaoctets	128 TB
Réplication	Par shard	Au niveau stockage
Multi-tenant	✅ Excellent	⚠️ Possible mais non natif
Coût	Variable (workers)	20-30% > RDS
Complexité	Élevée	Moyenne
Use Case	Distribué, multi-tenant	Haute performance générale

Résumé comparatif :

RDS/Flexible Server : Similaires, choix dépend de votre écosystème cloud
Aurora : Meilleur pour performance générale, stockage distribué transparent
Hyperscale : Meilleur pour true scale-out, multi-tenant, big data

Migration vers Azure Database for PostgreSQL

Méthodes de Migration

1. Azure Database Migration Service (DMS)

Azure DMS est l'outil recommandé par Microsoft :

Fonctionnement

Migration en ligne : Réplication continue avec downtime minimal
Migration hors ligne : Dump & Restore classique
Supporte migration depuis :
- PostgreSQL on-premises
- Autres clouds (AWS RDS, Google Cloud SQL)
- Azure VMs

Processus (Migration en ligne)

┌──────────────────────────────────────────────────┐
│ 1. Source (PostgreSQL existant)                  │
│    • Configuration logical replication           │
│    • Création publication                        │
└────────────────┬─────────────────────────────────┘
                 │
                 ▼
┌──────────────────────────────────────────────────┐
│ 2. Azure DMS                                     │
│    • Full load initial                           │
│    • Synchronisation continue (CDC)              │
└────────────────┬─────────────────────────────────┘
                 │
                 ▼
┌──────────────────────────────────────────────────┐
│ 3. Cible (Azure Flexible Server)                 │
│    • Réplication en continu                      │
│    • Lag quasi-nul                               │
└──────────────────────────────────────────────────┘
                 │
                 ▼
┌──────────────────────────────────────────────────┐
│ 4. Cutover (Basculement)                         │
│    • Arrêt écriture source                       │
│    • Sync finale                                 │
│    • Basculement application                     │
│    • Downtime : Minutes                          │
└──────────────────────────────────────────────────┘

Avantages DMS

Downtime minimal (quelques minutes)
Validation automatique
Interface graphique simple
Gratuit pour migrations vers Azure

2. pg_dump / pg_restore

Migration classique pour petites/moyennes bases :

# Export
pg_dump -h source.hostname.com -U username -d dbname \
  -Fc -f backup.dump

# Import vers Azure
pg_restore -h myserver.postgres.database.azure.com \
  -U myadmin -d dbname backup.dump

Avantages :

Simple et fiable
Contrôle total
Aucune dépendance externe

Inconvénients :

Downtime complet durant la migration
Lent pour grosses bases (> 100 GB)

3. Logical Replication Native

Pour migration manuelle fine :

-- Sur la source
CREATE PUBLICATION my_publication FOR ALL TABLES;

-- Sur Azure Flexible Server (cible)
CREATE SUBSCRIPTION my_subscription
  CONNECTION 'host=source.com dbname=mydb user=repluser'
  PUBLICATION my_publication;

Checklist de Migration

Avant la migration :

✅ Audit de compatibilité (extensions, paramètres)
✅ Dimensionnement cible (SKU, stockage, HA)
✅ Configuration réseau (VNet, firewall)
✅ Tests sur environnement de staging
✅ Sauvegarde complète de la source
✅ Plan de rollback détaillé

Pendant la migration :

✅ Monitoring des performances
✅ Validation de l'intégrité (checksums, counts)
✅ Tests applicatifs

Après la migration :

✅ Recréer les index si nécessaire
✅ ANALYZE pour mettre à jour les statistiques
✅ Configuration du monitoring Azure
✅ Validation des sauvegardes
✅ Tests de charge

Tarification Azure Database for PostgreSQL

Modèle de Tarification Flexible Server

La tarification se décompose en :

1. Compute (Calcul)

Facturé à l'heure
Variable selon SKU (Burstable, General Purpose, Memory Optimized)

Exemples (West Europe) :

B2ms (2 vCPU, 8 GB) : ~0,083€/h ≈ 60€/mois
D4s_v3 (4 vCPU, 16 GB) : ~0,348€/h ≈ 252€/mois
E8s_v3 (8 vCPU, 64 GB) : ~0,868€/h ≈ 628€/mois

2. Stockage

Facturé au GB/mois
Prix : ~0,138€/GB/mois

Exemples :

100 GB : ~13,80€/mois
1 TB : ~138€/mois
5 TB : ~690€/mois

3. IOPS (si optimisé)

IOPS supplémentaires : ~0,05€ par 1000 IOPS/mois
Débit supplémentaire : ~0,10€ par 100 MB/s/mois

4. Backup

Inclus : Jusqu'à 1× la taille du stockage provisionné
Payant : Au-delà, ~0,10€/GB/mois
Backup géo-redondant : Supplément de 2×

5. Haute Disponibilité

Zone-Redundant HA : +100% du coût compute
Same-Zone HA : +100% du coût compute

6. Read Replicas

Chaque réplica = coût compute + stockage séparé
Transfert données cross-region : ~0,02€/GB

Exemple de Coût Total

Scénario Production Moyenne :

Compute : D8s_v3 (8 vCPU, 32 GB) HA Zone-Redundant
Stockage : 500 GB
Backup : Rétention 14 jours (inclus)
Région : West Europe

Calcul :
─────────────────────────────────────────
Compute :        500€/mois × 2 (HA)  = 1 000€  
Stockage :       0,138€ × 500 GB     =    69€  
Backup inclus :  500 GB              =     0€  
─────────────────────────────────────────
Total :                                1 069€/mois

Optimisation des Coûts

1. Azure Reserved Instances

Engagement 1 an : -20% à -30%
Engagement 3 ans : -40% à -60%
Applicable au compute uniquement

2. Dev/Test Pricing

Tarifs réduits pour environnements non-production
Nécessite un abonnement Visual Studio

3. Start/Stop

Arrêt automatique : Pour dev/test non utilisés
Ne paye que le stockage quand arrêté
Économie : ~80% durant arrêt

4. Right-Sizing

Surveiller les métriques d'utilisation
Descendre de SKU si sous-utilisé
Utiliser Azure Advisor pour recommandations

5. Stockage Optimisé

Ne provisionner que le nécessaire
Auto-growth activé pour éviter le sur-provisionnement
Nettoyer les données obsolètes

Outils et Intégration

Azure Portal

Interface web pour gérer tous les aspects
Création, modification, monitoring
Convivial pour les débutants

Azure CLI

# Créer un serveur Flexible
az postgres flexible-server create \
  --resource-group myResourceGroup \
  --name myserver \
  --location westeurope \
  --admin-user myadmin \
  --admin-password <password> \
  --sku-name Standard_D4s_v3 \
  --tier GeneralPurpose \
  --storage-size 128 \
  --version 16 \
  --high-availability ZoneRedundant

# Lister les serveurs
az postgres flexible-server list --output table

# Arrêter/Démarrer
az postgres flexible-server stop --name myserver --resource-group myResourceGroup  
az postgres flexible-server start --name myserver --resource-group myResourceGroup

Azure PowerShell

# Créer un serveur
New-AzPostgreSqlFlexibleServer `
  -ResourceGroupName myResourceGroup `
  -Name myserver `
  -Location westeurope `
  -Sku Standard_D4s_v3

Terraform (Infrastructure as Code)

resource "azurerm_postgresql_flexible_server" "example" {
  name                = "myserver"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  version             = "16"

  administrator_login    = "adminuser"
  administrator_password = var.admin_password

  sku_name   = "GP_Standard_D4s_v3"
  storage_mb = 131072

  high_availability {
    mode = "ZoneRedundant"
  }
}

Intégration avec Services Azure

Azure App Service

Connexion facile via Connection Strings
Intégration VNet pour Private Access
Managed Identity pour authentification sans mot de passe

Azure Functions

Serverless avec Azure Database for PostgreSQL
Idle scale-to-zero (la DB reste active)
Connection pooling nécessaire (PgBouncer)

Azure Kubernetes Service (AKS)

Connexion via Private Link
Secrets stockés dans Azure Key Vault
Service Mesh pour observabilité

Power BI / Azure Data Factory

Connecteurs natifs pour analytics et ETL
DirectQuery ou Import
Pipelines de données automatisés

Bonnes Pratiques Azure Database for PostgreSQL

Sécurité

✅ Toujours utiliser Private Access (VNet) pour production
✅ Activer Azure AD Authentication pour SSO et MFA
✅ Customer-Managed Keys pour chiffrement sensible
✅ Network Security Groups restrictifs
✅ Auditing activé : Diagnostic Logs vers Log Analytics
✅ Pas d'administrateur partagé : Créer des utilisateurs dédiés
✅ Rotation des secrets via Azure Key Vault

Performance

✅ Activer pg_stat_statements pour monitoring requêtes
✅ Utiliser Query Performance Insight pour identifier les lenteurs
✅ Indexation appropriée : Analyser les slow queries
✅ Connection pooling : PgBouncer ou pooling applicatif
✅ Right-size les paramètres : shared_buffers, work_mem
✅ Éviter N+1 queries : Utiliser JOINs ou batching
✅ Autovacuum configuré : Surveiller bloat

Haute Disponibilité

✅ Zone-Redundant HA activé pour production critique
✅ Geo-Replicas pour disaster recovery multi-région
✅ Automated backups : Rétention 14-35 jours
✅ Geo-redundant backups pour protection régionale
✅ Tests de failover réguliers : Valider RTO/RPO
✅ Monitoring actif : Alertes sur métriques critiques
✅ Runbooks documentés : Procédures d'urgence

Coûts

✅ Reserved Instances pour production long terme
✅ Tagging rigoureux : Suivi des coûts par projet
✅ Azure Cost Management : Budgets et alertes
✅ Stop/Start dev/test : Économiser hors horaires
✅ Azure Advisor : Recommandations d'optimisation
✅ Monitorer l'utilisation : Downsize si sous-utilisé
✅ Nettoyer données obsolètes : Réduire stockage

Opérations

✅ Infrastructure as Code : Terraform, ARM, Bicep
✅ CI/CD pour migrations : Azure DevOps, GitHub Actions
✅ Schema versioning : Flyway, Liquibase
✅ Monitoring centralisé : Azure Monitor, Grafana
✅ Documentation : Architecture, runbooks, DR plan
✅ Tests de restauration : Valider backups mensuellement
✅ Mises à jour planifiées : Fenêtres de maintenance

Cas d'Usage Typiques

1. Application Web Standard

SKU : D4s_v3 (4 vCPU, 16 GB)
HA : Zone-Redundant
Stockage : 256 GB
Coût : ~600€/mois
Use case : E-commerce, SaaS, CMS

2. Application Multi-Tenant SaaS

Architecture : Hyperscale (Citus)
Workers : 4× D8s_v3
Distribution : Par tenant_id
Coût : ~3000€/mois
Use case : SaaS avec milliers de tenants

3. Analytique et BI

SKU : E16s_v3 (16 vCPU, 128 GB Memory)
Stockage : 2 TB optimisé IOPS
Extensions : TimescaleDB, pg_stat_statements
Coût : ~1500€/mois
Use case : Data warehouse, dashboards temps réel

4. Développement et Tests

SKU : B2ms (2 vCPU, 8 GB Burstable)
HA : Aucune
Stockage : 64 GB
Start/Stop : Automatique hors horaires
Coût : ~20€/mois (avec stop)
Use case : Environnements dev/test

Limitations et Considérations

Limitations Flexible Server

❌ Pas de superuser complet : Certaines commandes système interdites
❌ Extensions limitées : Moins que PostgreSQL natif (mais plus qu'AWS RDS)
❌ max_connections : Limité par SKU (102 à 5000)
❌ Pas d'accès OS : Pas de SSH, fichiers limités
❌ Maintenance imposée : Fenêtres de mise à jour obligatoires

Limitations Hyperscale

❌ Complexité élevée : Nécessite expertise Citus
❌ Foreign Keys limités : Uniquement sur distribution key
❌ Certaines features PostgreSQL : Non supportées (ex: SERIALIZABLE)
❌ Coût élevé : Multiple workers nécessaires
❌ Over-engineering : Inutile pour bases < 100 GB

Considérations Générales

⚠️ Dépendance Azure : Vendor lock-in (migration sortante complexe)
⚠️ Régions limitées : Tous les services ne sont pas partout
⚠️ Coûts cachés : Transfert données, geo-replication
⚠️ Compliance : Vérifier conformité réglementaire (GDPR, HDS, etc.)

Conclusion

Azure Database for PostgreSQL offre une solution complète et flexible pour héberger PostgreSQL dans le cloud Azure :

Résumé Flexible Server

✅ Solution moderne et recommandée par Microsoft
✅ Compatible 100% avec PostgreSQL
✅ Haute disponibilité robuste (Zone-Redundant)
✅ Excellente intégration avec l'écosystème Azure
✅ Coût prévisible et compétitif
✅ Sécurité entreprise : VNet, AAD, CMK
✅ Monitoring riche : Azure Monitor natif

Résumé Hyperscale (Citus)

✅ Scale-out horizontal pour big data
✅ Performances exceptionnelles en parallèle
✅ Multi-tenant natif : Isolation par shard
✅ Pétaoctets de données possibles
⚠️ Complexité accrue, coût élevé
⚠️ Uniquement si nécessaire (> 100 GB, workloads distribués)

Recommandation Générale

Pour 95% des cas d'usage, Flexible Server est le bon choix :

Déploiement simple
Performances excellentes
Coût maîtrisé
Maintenance réduite

Hyperscale uniquement si :

Données massives (> 100 GB)
Architecture multi-tenant nécessaire
Performances extrêmes requises
Budget conséquent

Comparaison avec AWS

Azure Flexible Server ≈ AWS RDS : Très similaires
Azure Hyperscale ≠ AWS Aurora : Approches différentes
- Hyperscale : True distributed (Citus)
- Aurora : Stockage distribué, compute centralisé

Choix entre Azure et AWS ?

Dépend de votre écosystème cloud existant
Compétences de l'équipe
Services complémentaires utilisés (Azure AD, AKS vs EKS, etc.)
Pricing : Faire des simulations précises

Azure Database for PostgreSQL s'est considérablement amélioré ces dernières années et est maintenant au niveau d'AWS RDS, voire supérieur sur certains aspects (intégration AAD, VNet natif).

Prochaines sections du tutoriel :

19.2.3. Google Cloud SQL et AlloyDB
19.2.4. Managed vs Self-Hosted : Trade-offs

⏭️ Google Cloud SQL et AlloyDB

FilesExpand file tree

02.2-azure-database.md

Latest commit

History

02.2-azure-database.md

File metadata and controls

19.2.2. Azure Database for PostgreSQL

Introduction

Vue d'ensemble de l'Offre Azure PostgreSQL

Évolution de l'Offre

Azure Database for PostgreSQL - Flexible Server

Qu'est-ce que Flexible Server ?

Architecture de Flexible Server

Concepts Clés Azure

Resource Group (Groupe de Ressources)

Virtual Network (VNet)

Availability Zone (Zone de Disponibilité)

Caractéristiques Principales de Flexible Server

1. Versions PostgreSQL Supportées

2. Options de Compute (Calcul)

Burstable (Charges Variables)

General Purpose (Usage Général)

Memory Optimized (Optimisé Mémoire)

3. Stockage

Caractéristiques du Stockage

Performance par Taille

4. Haute Disponibilité (HA)

Zone-Redundant HA (Recommandé)

Same-Zone HA

Aucune HA

5. Read Replicas (Réplicas de Lecture)

Fonctionnement

Cas d'Usage

Caractéristiques

6. Sauvegardes et Restauration

Sauvegardes Automatiques

Géo-Redondance des Backups

Point-in-Time Restore (PITR)

Sauvegardes Manuelles

7. Options de Réseau

Private Access (VNet Integration) - Recommandé

Public Access (Firewall Rules)

8. Sécurité

Authentification

Chiffrement

Règles de Sécurité

Auditing et Conformité

9. Paramètres Serveur (Server Parameters)

Catégories de Paramètres

Paramètres Modifiables Importants

Paramètres Non Modifiables

10. Extensions PostgreSQL

Extensions Préinstallées

Extensions Populaires Disponibles

11. Monitoring et Observabilité

Azure Monitor Integration

Alertes

Diagnostic Logs

Insights et Analyse

Azure Database for PostgreSQL - Hyperscale (Citus)

Qu'est-ce que Hyperscale (Citus) ?

Concept de Sharding Transparent

Architecture Hyperscale

Cas d'Usage de Hyperscale

Tables Distribuées vs Tables de Référence

Tables Distribuées

Tables de Référence

Performances Hyperscale

Limitations Hyperscale

Quand Utiliser Hyperscale ?

Comparaison : Flexible Server vs Hyperscale

Comparaison Azure vs AWS

Flexible Server vs RDS PostgreSQL

Hyperscale vs Aurora PostgreSQL

Migration vers Azure Database for PostgreSQL

Méthodes de Migration

1. Azure Database Migration Service (DMS)

Fonctionnement

Processus (Migration en ligne)

Avantages DMS