​

Aperçu de l’architecture AWS

​

Diagramme d’architecture

​

Composants clés

​

1. Couche réseau

​

Fournisseur DNS

• Objectif : Résolution des noms de domaine ; fonctionne avec n’importe quel fournisseur (Route 53, Cloudflare, etc.)
• Domaines (utilisez votre propre domaine, par ex. example.com) :
  • app.example.com — Web Frontend
  • api.example.com — FastAPI Backend
  • automations.example.com — Service Automator
  • supabase.example.com — Supabase Kong (auto-hébergée uniquement)
  • signoz.example.com — Observabilité SigNoz (optionnel)
• Validation SSL : Enregistrements CNAME requis pour la validation DNS d’ACM

​

Application Load Balancer (ALB)

• Objectif : Terminaison SSL, équilibrage de charge et routage basé sur le nom d’hôte
• Fonctionnalités :
  • Terminaison SSL/TLS avec les certificats ACM (caractère générique ou par service)
  • Redirection HTTP → HTTPS
  • Vérifications de santé pour tous les groupes cibles
• Géré par : Contrôleur AWS Load Balancer (graphique Helm dans helm-deployment/infrastructure)

​

VPC

• CIDR : Spécifique à l’environnement (par ex. 10.x.0.0/16)
• Zones de disponibilité : 3 AZs dans la région choisie
• Sous-réseaux : 3 publics (Passerelles NAT) + 3 privés (nœuds EKS)
• Sortant : Passerelle NAT par AZ pour la sortie des nœuds

​

2. Couche de calcul

​

Cluster EKS

• Version : Kubernetes 1.33
• Groupe de nœuds système : Groupe de nœuds géré exécutant le contrôleur Karpenter (pas sur les nœuds gérés par Karpenter, selon les bonnes pratiques d’AWS)
• Modules complémentaires : Pilote CSI EBS, Contrôleur AWS Load Balancer, CoreDNS, kube-proxy

​

Karpenter — Approvisionnement dynamique des nœuds

• Objectif : Approvisionnement des nœuds juste à temps et optimisation des coûts
• Classes de nœuds :
  • Usage général : Instances Spot pour la plupart des charges de travail
  • Calcul intensif : Instances haute-CPU pour les tâches liées au CPU
  • Mémoire intensive : Instances optimisées pour la mémoire pour les grands ensembles de données
  • Base de données : Instances à la demande pour les charges de travail avec état/base de données
  • GPU : Instances GPU pour les charges de travail IA/ML (optionnel)
• Fonctionnalités : Priorisation des Spot, consolidation automatique, gestion des interruptions basée sur SQS

​

KEDA — Mise à l’échelle automatique des pods basée sur les événements Kubernetes

• Objectif : Mise à l’échelle horizontale des pods basée sur les métriques de ressources
• Cibles :

• Réduction d’échelle : Fenêtre de stabilisation de 30 s pour une réponse rapide

​

3. Services d’application

​

Web Frontend

• Port : 3000
• Répliques : 2–8 (gérées par KEDA)
• Objectif : Application React servant l’interface utilisateur

​

FastAPI Backend

• Port : 8001
• Répliques : 2–10 (gérées par KEDA)
• Objectif : Serveur API REST gérant la logique métier et l’accès aux données

​

Travailleurs Celery

• Répliques : 2–8 (gérées par KEDA)
• Objectif : Traitement des tâches en arrière-plan (mis en file d’attente via RabbitMQ)

​

Service Automator

• Port : 80
• Répliques : 2–8 (gérées par KEDA)
• Objectif : Automation des flux de travail et orchestration

​

Supabase Kong

• Port : 8000 (service de cluster interne)
• Objectif : Passerelle API pour tous les services Supabase
• Routage : Le trafic externe atteint Kong via l’entrée ALB définie dans odin-services/main-ingress.yaml

​

SigNoz (optionnel)

• Espace de noms : monitoring
• Composants : Plateforme SigNoz + agent DaemonSet k8s-infra
• Objectif : Traçage distribué, agrégation des métriques, gestion des journaux
• Activé par : ENABLE_SIGNOZ=true

​

4. Couche de données

​

ElastiCache Redis

• Objectif : Cache, stockage de session et courtier/backend de résultats Celery
• Configuration :
  • Type de nœud : configurable (par ex. cache.t3.micro)
  • Port : 6379
  • Chiffrement au repos et en transit
  • Multi-AZ pour la haute disponibilité
• Activé par : ENABLE_AWS_SERVICES=true

​

Amazon MQ (RabbitMQ)

• Objectif : File d’attente de messages pour le traitement asynchrone des tâches
• Configuration :
  • Moteur : RabbitMQ
  • Ports : 5671 (AMQP/SSL), 15671 (Gestion/SSL)
  • Mode de déploiement : instance unique ou active/veille
• Activé par : ENABLE_AWS_SERVICES=true

​

Supabase — Option A : Cloud (géré)

• Objectif : PostgreSQL géré externe, Auth, Storage et Realtime
• Connexion : URL du projet Supabase et clé du rôle de service configurées dans values/odin-services.yaml

​

Supabase — Option B : Auto-hébergée sur EKS

• Objectif : Pile Supabase complète s’exécutant à l’intérieur du cluster
• Composants :
  • Opérateur CloudNativePG (cnpg-system) — gère le cycle de vie du cluster Postgres
  • Base de données Supabase HA (ha-supabase-db) — Ressource Cluster CloudNativePG avec regroupement PgBouncer
  • Application Supabase (namespace supabase) — Kong, Auth, Storage (MinIO), Meta, Rest, Realtime, Studio
• Ordre de déploiement : CloudNativePG → Base de données Supabase HA → Application Supabase
• Activé par : ENABLE_CNPG=true, ENABLE_HA_SUPABASE_DB=true, ENABLE_SUPABASE=true

​

PostgreSQL Automator

• Objectif : Base de données PostgreSQL locale pour le service Automator
• Port : 5432
• Stockage : Volume persistant EBS
• Affinité des nœuds : Nœuds dédiés à la base de données

​

5. Sécurité et IAM

​

Rôles IAM

​

Groupes de sécurité

• ALB : Auto-créé par le contrôleur AWS Load Balancer (entrée 80/443)
• Cluster EKS : Communication nœud-à-nœud et pod
• Redis : Port 6379 uniquement depuis le CIDR VPC
• RabbitMQ : Ports 5671, 15671 uniquement depuis le CIDR VPC

​

SSL/TLS

• Terminaison : Niveau ALB (les pods voient HTTP en clair en interne)
• Certificats : Certificats ACM — soit par service, soit un caractère générique unique
• Validation : Validation DNS CNAME via votre fournisseur DNS
• Protocole minimum : TLS 1.2

​

6. Infrastructure en tant que code

​

Modules Terraform

• modules/eks: Cluster EKS, VPC, groupes de nœuds, Karpenter, IAM, versions Helm
• État : Bucket S3 avec versioning, table de verrouillage DynamoDB

​

Terragrunt

• Isolation de l’environnement : Un répertoire par environnement sous terragrunt/environments/
• Modèle : env-template-folder — copier et remplir les espaces réservés pour créer un nouvel environnement
• Configuration DRY : root.hcl partagée avec les remplacements par environnement
• Indicateurs d’activation/désactivation : Services basculés via variables d’environnement (ENABLE_*)

​

Graphiques Helm

​

Flux de données

​

1. Flux de demande utilisateur

Utilisateur → DNS → ALB (terminaison SSL) → Pod EKS (Web Frontend)
                                          → Pod EKS (FastAPI Backend)
                                          → Pod EKS (Supabase Kong)

1. L’utilisateur accède à app.example.com
2. DNS se résout vers l’ALB
3. ALB termine SSL et route par nom d’hôte vers le groupe cible correct
4. Web Frontend sert l’application React et effectue des appels API vers api.example.com
5. FastAPI Backend traite les demandes et lit/écrit dans les services de données

​

2. Flux de demande API

Client → ALB → FastAPI Backend → Redis (cache) / RabbitMQ (file d'attente) / Supabase (BD)

1. Le client appelle api.example.com
2. ALB route vers le pod FastAPI
3. Le backend vérifie le cache Redis ; en cas d’absence, interroge la base de données Supabase
4. Les tâches asynchrones sont mises en file d’attente dans RabbitMQ et traitées par les travailleurs Celery

​

3. Flux de traitement en arrière-plan

FastAPI → RabbitMQ → Celery Worker → Base de données Supabase

1. FastAPI met une tâche en file d’attente dans RabbitMQ
2. Celery Worker retire de la file d’attente et traite la tâche
3. Les résultats sont réécrits dans la base de données Supabase

​

4. Flux de travail Automator

Automator → PostgreSQL (local) → Redis → APIs externes

1. Automator reçoit une demande de flux de travail
2. L’état du flux de travail est persistant dans l’instance PostgreSQL locale
3. Redis cache les résultats intermédiaires
4. Les API externes sont appelées dans le cadre de l’automation

​

5. Flux de mise à l’échelle

Métriques → KEDA → Mise à l'échelle des pods → Karpenter → Approvisionnement des nœuds

1. KEDA évalue les métriques CPU/Mémoire par rapport aux seuils configurés
2. Les pods sont mis à l’échelle horizontalement dans la plage de répliques configurée
3. Si la capacité du cluster est insuffisante, Karpenter provisionne de nouveaux nœuds EC2 (préférant les Spot)
4. Lorsque la charge diminue, KEDA réduit l’échelle des pods ; Karpenter consolide et termine les nœuds inactifs

​

6. Flux de sécurité

Internet → ALB (TLS 1.2+, ACM) → Groupes de sécurité → Pods → Rôles IRSA IAM → APIs AWS

1. Tout le trafic externe termine TLS à l’ALB
2. Les groupes de sécurité appliquent l’accès réseau à privilège minimal
3. Les pods communiquent avec les services AWS via IRSA (Rôles IAM pour les comptes de service)

​

Résumé de la haute disponibilité

​

Optimisation des coûts

• Instances Spot : Karpenter priorise les Spot pour toutes les charges de travail non-base de données
• Consolidation des nœuds : Karpenter récupère automatiquement les nœuds sous-utilisés
• Dimensionnement correct des pods : KEDA réduit l’échelle des pods pendant les périodes calmes
• À la demande uniquement si nécessaire : La classe de nœud de base de données utilise À la demande pour la stabilité

​

Maintenance et opérations

​

Processus de déploiement

cd terragrunt/environments/<your-env-name>
# Définir les variables d'environnement ENABLE_* et domaine/certificat requises
terragrunt apply
# Mises à jour roulantes : réappliquer après la mise à jour des balises d'image ou des fichiers de valeurs

​

Stratégie de sauvegarde

• Snapshots EBS : Snapshots automatisés pour les volumes persistants (Base de données Automator, Supabase MinIO)
• CloudNativePG : Archivage WAL continu + sauvegardes de base programmées (si configuré)
• Supabase Cloud : Sauvegardes quotidiennes gérées (option cloud)
• État IaC : Bucket S3 versionné

​

Récupération d’urgence

• Multi-AZ : Tous les services avec état s’étendent sur plusieurs zones de disponibilité
• CloudNativePG HA : Basculement automatique entre les répliques principales et Postgres
• Supabase Cloud : Redondance interrégionale (option cloud)
• État Terraform : Le versioning S3 permet de revenir à tout état précédent

​

Ressources supplémentaires

• Contrôleur AWS Load Balancer
• Documentation Karpenter
• Documentation KEDA
• Documentation CloudNativePG
• Auto-hébergement Supabase
• Documentation SigNoz
• Guide de déploiement Terragrunt