Aller au contenu
quest'n'click

Clever CloudExplicationPour adminsS'applique de 4.2.3

RPO et RTO

This page in EnglishCette page sur le wiki GitHub

Deux chiffres disent ce qu’un Studio hébergé peut perdre et combien de temps il peut rester à l’arrêt : le RPO (l’objectif de point de reprise, les modifications qu’une reprise peut perdre) et le RTO (l’objectif de temps de reprise, la durée de la reprise). Cette page définit les deux pour le Studio Server, dit comment chacun se mesure sur votre installation, et les rattache aux mesures du déploiement de référence. Ce sont des observations, jamais des promesses.

Pourquoi

Une équipe écrit le jeu ensemble, toute la journée. Si la base est perdue, la question n’est pas de savoir si une sauvegarde existe, mais quelles modifications reviennent, et quand on peut écrire de nouveau. Le Studio Server y répond par deux mécanismes, chacun lié à un chiffre :

  • Le journal expédié vers le bucket borne le RPO. Chaque opération confirmée est copiée dans Cellar en segment immuable, dans l’ordre, dès qu’elle est écrite (un échec est retenté sous 30 s).
  • La sauvegarde quotidienne plus le rejeu bornent le RTO. Une restauration écrit la dernière sauvegarde dans une nouvelle base, puis rejoue chaque segment expédié depuis (exercice de restauration).

Le RPO, défini

Ce qu’une restauration peut perdre, ce sont les opérations confirmées mais pas encore expédiées vers le bucket au moment où la base a été perdue. À tout instant, c’est l’âge de la plus ancienne opération pas encore expédiée :

  • GET /readyz le donne en rpoMs (0 quand tout est expédié) ;
  • avec les métriques, studio_journal_rpo_seconds dit la même chose (Supervision).

La cible est une minute (D42) : surveillée, avec une alerte au-delà de 60 s pendant 5 min, jamais promise.

Le RTO, défini

Le temps qui sépare la décision de restaurer du moment où le Studio sert de nouveau les écritures (/readyz à 200 sur la base restaurée). Il s’additionne :

  1. créer un nouvel add-on PostgreSQL (non mesuré) ;
  2. télécharger la dernière sauvegarde (non mesuré) ;
  3. la restauration avec son rejeu ;
  4. faire pointer l’application studio sur le nouvel add-on (clever service link-addon, en déliant celui qui est perdu) et redéployer (un déploiement du studio a pris de 29 s à 1 min 29 s au déploiement de référence, migrations comprises) ;
  5. la nouvelle instance qui prend le bail de service.

Seule l’étape 3 est mesurée :

Ce qui n’est pas une perte

  • Un redéploiement refuse les écritures un moment (503 avec Retry-After) et n’en perd aucune : une écriture retentée avec son identifiant d’opération est appliquée une fois (Redéploiements).
  • Une restauration déconnecte tout le monde (les sessions ne sont pas dans une sauvegarde), et les brouillons encore dans le navigateur d’un membre n’ont jamais été confirmés : ils ne font pas partie du RPO, et le Studio garde un brouillon refusé dans l’éditeur.

Les autres possibilités écartées

  • Les seules sauvegardes de PostgreSQL. Elles restaureraient les tables, sans les lier au contenu des fichiers dans Cellar au même instant. La sauvegarde du Studio liste les blobs qu’elle nomme et refuse de restaurer quand l’un manque.
  • Une réplique continue. Non proposée : une instance, une base, et le journal expédié vers le bucket à la place.

Les compromis

  • Le journal et les sauvegardes partagent le bucket avec les contenus : un seul endroit à perdre. Copiez-le ailleurs.
  • Le RPO dépend de Cellar joignable : tant qu’il ne l’est pas, rpoMs grandit (Worker, PostgreSQL ou Cellar en panne).
  • Les mesures viennent d’un petit jeu et d’un seul membre qui écrit, sur l’organisation de test : pas d’une charge de production.

Décisions et ADR