CloudPredict

01 Contexte

Une plateforme de production cloud-native qui prédit des prix immobiliers (dataset California Housing) et couvre tout le cycle MLOps, de l'entraînement automatisé au monitoring proactif sur un cluster orchestré. Réalisée en binôme : ingénierie ML d'un côté, architecture système de l'autre.

02 Problème

Un modèle n'est utile que s'il est servi de façon fiable. La plateforme avait besoin d'images légères et sûres, d'une haute disponibilité sous charge, d'un accès à moindre privilège pour la stack de monitoring et d'une visibilité complète sur les métriques d'infrastructure comme métier.

03 Ce que j'ai construit

1. 01

   Build Docker multi-stage - une étape de build pour les dépendances lourdes et une étape d'exécution python:3.11-slim, sans compilateurs en production pour réduire la surface d'attaque.

2. 02

   Déploiement Kubernetes - au moins 2 réplicas avec une stratégie RollingUpdate.

3. 03

   Horizontal Pod Autoscaler - passage de 2 à 10 pods selon un seuil CPU de 50 %.

4. 04

   Réseau - Nginx Ingress Controller pour centraliser le trafic, service NodePort pour la communication interne.

5. 05

   Sécurité - RBAC avec un ServiceAccount et un ClusterRole dédiés pour isoler les droits de la stack de monitoring.

6. 06

   Observabilité - collecte Prometheus en mode pull toutes les 15 s, Loki & Promtail pour centraliser les logs, et un dashboard Grafana unifié mêlant métriques d’infrastructure (CPU/RAM) et métier (volume de prédictions).

04 Résultats

• de taille d'image Docker (multi-stage)-60%
• pods, autoscaling à 50 % de CPU2 → 10
• piliers d'observabilité : Prometheus, Grafana, Loki3

05 Ma part

06 Ce que j'ai appris

• La taille d'une image est un enjeu de vitesse et de sécurité : les builds multi-stage gardent compilateurs et outils de build hors de la production.
• La disponibilité vient de la configuration : nombre minimal de réplicas, rolling updates et seuils d'autoscaling adaptés à la charge réelle.
• Le moindre privilège s'applique aussi dans le cluster : la stack de monitoring a son propre ServiceAccount et son propre ClusterRole.
• Métriques et logs ne sont utiles qu'ensemble : une vue Grafana qui mêle infrastructure et métier répond à « est-ce que ça marche ? » en quelques secondes.
• Un partage clair des responsabilités (ML vs plateforme) permet à un binôme d’avancer vite sans se marcher dessus.