Scaling temps réel avec DigitalOcean App Platform

Scaling temps réel avec DigitalOcean App Platform

Temps de lecture : 3 min

Points clés à retenir

  • Réactivité immédiate : le scaling basé sur le nombre de requêtes et la latence P95 réagit aux signaux utilisateur en temps réel, contrairement au CPU.
  • Disponible pour tous : cette fonctionnalité fonctionne aussi bien sur les instances CPU partagé que dédié, sans nécessiter de changement de forfait.
  • Configuration simple : définissez des seuils de requêtes par seconde et de latence P95 dans la console ou via l’app spec, et la plateforme s’adapte automatiquement.

Pourquoi le scaling basé sur le trafic est indispensable

Le trafic n’explose jamais au moment où tu t’y attends le plus. Un lancement produit, un post viral ou une promotion flash peut multiplier le nombre de requêtes en quelques secondes. Les métriques CPU, elles, mettent plusieurs minutes à réagir. Dans cet intervalle, tes utilisateurs subissent des ralentissements.

Concrètement, avec le request-based autoscaling désormais disponible en général sur DigitalOcean App Platform, tes applications peuvent monter en charge automatiquement en fonction de signaux de trafic HTTP en direct : le nombre de requêtes par seconde et la latence P95. L’infrastructure réagit à ce qui se passe maintenant, et non à ce qui s’est produit il y a cinq minutes.

Désormais disponible sur tous les types d’instances

Jusqu’à présent, l’autoscaling sur App Platform nécessitait un plan CPU dédié. Cela excluait une bonne partie des utilisateurs, notamment ceux sur des instances CPU partagé. Ce n’est plus le cas : le request-based autoscaling fonctionne aussi bien sur les plans Shared CPU que Dedicated CPU. Que tu lances un MVP ou que tu gères un service en production à fort trafic, tu peux configurer le scaling sans changer de formule.

A Lire :  Systeme.io : Avis Complet 2026 après 3 Ans d'Utilisation

Des métriques qui reflètent l’expérience utilisateur

Le scaling basé sur le CPU est réactif par nature. C’est un indicateur retardé : tes conteneurs doivent déjà être en difficulté pour que le système détecte le problème. À ce moment-là, tes utilisateurs patientent déjà.

Avec le request-based autoscaling, les décisions sont prises sur des indicateurs directement liés à l’expérience utilisateur :

  • Requêtes par seconde par instance : combien de requêtes chaque conteneur traite en temps réel.
  • Latence P95 : le temps de réponse que 95 % de tes utilisateurs constatent.

Dès que l’un de ces seuils est dépassé, de nouveaux conteneurs sont lancés immédiatement. Quand la charge redescend, ils sont arrêtés automatiquement. Tu obtiens la capacité nécessaire, plus vite, et tu paies uniquement pour l’utilisation réelle.

Sur les plans dédiés, tu peux même combiner les métriques request-based et CPU. Le système monte en charge dès qu’un seuil est franchi, et ne redescend que lorsque tous les indicateurs sont revenus dans la normale.

Analyser ton trafic avant de paramétrer

Pour définir des seuils efficaces, il faut connaître tes schémas de trafic habituels. L’onglet Insights de la console App Platform te donne ces données : le taux de requêtes HTTP entrantes (req/s) et la latence P95. Utilise ces informations pour comprendre le comportement de ton service avant d’ajuster les règles.

Configurer le scaling en trois étapes

Plus précisément, voici comment faire via la console :

  1. Va dans la page Apps, sélectionne ton app, ouvre l’onglet Settings, puis choisis ton service web.
  2. Dans la section Resource Size, clique sur Edit.
  3. Choisis l’onglet Shared CPU ou Dedicated CPU. Active l’autoscaling et définis le nombre minimum et maximum de conteneurs. Configure au moins une règle : skal scale on requests per second, on response time (P95) ou sur l’utilisation CPU (plan dédié uniquement).
A Lire :  Déployer Supabase sur DigitalOcean en 1 clic en 2026

Clique sur Save. Un redéploiement s’effectue automatiquement, et ton app commence à scaler.

Tu peux aussi passer par l’app spec. Ajoute un bloc autoscaling à ton service component. Par exemple, pour scaler entre 1 et 10 conteneurs avec un objectif de 100 req/s et une latence P95 de 500 ms :

services:
  - name: api
    http_port: 8080
    instance_size_slug: shared-s-2vcpu-2gb
    instance_count:
      min: 1
      max: 10
    autoscaling:
      metrics:
        - metric: requests_per_second
          target: 100
        - metric: latency_p95
          target: 500

Envoie la spec via doctl apps update ou l’API Apps. Tu peux ajuster ces valeurs à tout moment : si le scaling se déclenche trop tôt, augmente la cible ; si la latence grimpe avant l’arrivée des nouveaux conteneurs, diminue-la.

Limites à connaître

  • Le request-based autoscaling s’applique uniquement aux services web qui reçoivent du trafic HTTP externe. Les workers et les fonctions ne sont pas éligibles.
  • Il ne peut pas être utilisé en même temps que Scale to Zero (Inactivity Sleep) sur le même service.
  • Les décisions de scaling sont basées sur une fenêtre de 5 minutes, donc le système réagit à une charge soutenue plutôt qu’à des pics instantanés.

Prêt à passer à l’action ?

Ton trafic ne suit pas d’horaire, ton scaling non plus. Le request-based autoscaling est disponible dès maintenant sur tous les comptes DigitalOcean. Va dans l’onglet Insights pour analyser tes schémas, puis configure tes règles dans la console ou via l’app spec.

Consulte la documentation pour démarrer.