\nonstopmode
\documentclass[aspectratio=169,xcolor={svgnames}]{beamer}
\usepackage[utf8]{inputenc}
% \usepackage[frenchb]{babel}
\usepackage{amsmath}
\usepackage{mathtools}
\usepackage{breqn}
\usepackage{multirow}
\usetheme{boxes}
\usepackage{graphicx}
\usepackage{import}
\usepackage{adjustbox}
\usepackage[absolute,overlay]{textpos}
\usepackage{tikz}
%\useoutertheme[footline=authortitle,subsection=false]{miniframes}
%\useoutertheme[footline=authorinstitute,subsection=false]{miniframes}
\useoutertheme{infolines}
\setbeamertemplate{headline}{}

\beamertemplatenavigationsymbolsempty

\definecolor{TitleOrange}{RGB}{255,137,0}
\setbeamercolor{title}{fg=TitleOrange}
\setbeamercolor{frametitle}{fg=TitleOrange}

\definecolor{ListOrange}{RGB}{255,145,5}
\setbeamertemplate{itemize item}{\color{ListOrange}$\blacktriangleright$}

\definecolor{verygrey}{RGB}{70,70,70}
\setbeamercolor{normal text}{fg=verygrey}


\usepackage{tabu}
\usepackage{multicol}
\usepackage{vwcol}
\usepackage{stmaryrd}
\usepackage{graphicx}

\usepackage[normalem]{ulem}

\AtBeginSection[]{
  \begin{frame}
  \vfill
  \centering
  \begin{beamercolorbox}[sep=8pt,center,shadow=true,rounded=true]{title}
    \usebeamerfont{title}\insertsectionhead\par%
  \end{beamercolorbox}
  \vfill
  \end{frame}
}

\title{Deuxfleurs : une infrastructure numérique distribuée low-tech}
\author{Armaël Guéneau, Baptiste Jonglez}
\date{2025-04-03}

\begin{document}

\begin{frame}
	\centering
	\includegraphics[width=.2\linewidth]{assets/logos/deuxfleurs.pdf}
	\vfill

	{\large\bf Deuxfleurs : une infrastructure numérique distribuée low-tech}
	\vspace{1em}

	{Armaël Guéneau, Inria Toccata} \\
	{Baptiste Jonglez, Inria Stack} \\
\end{frame}

\begin{frame}{Qui sommes nous}

\end{frame}

\begin{frame}{L'association Deuxfleurs}



  Deuxfleurs est une association loi 1901 qui héberge des services numériques

  \vfill

	Objectif : \\ \textbf{Construire une infrastructure numérique robuste,
	  utile, et gérée en commun}

  \vfill

  Membre du collectif CHATONS (hébergeurs associatifs)
\end{frame}

\begin{frame}{Choix politiques}

\begin{enumerate}
\setlength\itemsep{1.5em}
  \item \textbf{Réduire les dépendances} aux acteurs dominants, maîtriser les dépendances
		inévitables (électricité, réseau). Jusqu'à maîtriser toute la pile
		logicielle, matérielle et hébergement.

  \item \textbf{Sobriété radicale :} empreinte matérielle minimale et fixe. Adapter les
		usages aux ressources et non l'inverse.

  \item \textbf{Bonne qualité de service :} alternative crédible aux GAFAM (CHATONS
		souvent critiqués pour leur qualité de service)
\end{enumerate}

\end{frame}

\begin{frame}{Conséquences de ces choix}

\begin{itemize}
\setlength\itemsep{1.5em}
\item \textbf{hébergement hors datacenters}, à la maison \\
  $\Longrightarrow$ électricité et réseau domestique pas fiables
\item \textbf{matériel reconditionné peu puissant}, de capacité fixe \\
  $\Longrightarrow$
  adapter les services et usages en fonction des limites (RAM, CPU, stockage)
\item \textbf{infrastructure géo-distribuée et tolérante aux fautes} pour assurer une bonne
		disponibilité \\
		$\Longrightarrow$ besoin de logiciels adaptés
\end{itemize}

\end{frame}

\begin{frame}
\begin{center}
\textbf{
Qu'est-ce qui rend l'infra Deuxfleurs intéressante dans un contexte recherche ?
}
\end{center}

\vfill

\begin{itemize}
\setlength\itemsep{1.8em}
\item R\&D sur des nouveaux logiciels car souvent rien sur l'étagère qui répond à nos besoins \\[0.2em]
{\small $\Longrightarrow$ par ex: stockage géo-distribué résistant aux fautes }

\item Peu de contraintes vis-à-vis de technos existantes ou legacy. \\
Approche greenfield : on choisit et conçoit les services que l'on fournit. \\ [0.2em]
{\small $\Longrightarrow$ par ex: hébergement de sites web, mais seulement statiques }
% FaaS à notre sauce ?
%
\end{itemize}
\end{frame}

\begin{frame}

\begin{center}
  {\Large \color{TitleOrange}\bf Deuxfleurs aujourd'hui}

  \vspace{1em}

  {\color{TitleOrange}\bf ce qui marche, comment ça marche}
\end{center}

\end{frame}

\begin{frame}{Services}

\textbf{Communication}\\[0.5em]
Discussion instantanée \qquad E-mails et agenda \qquad Visio

\vfill

\textbf{Édition collaborative}\\[0.5em]
Bureautique \qquad Forge logicielle

\vfill

\textbf{Publication}\\[0.5em]
\only<1>{Sites web statiques}%
\only<2->{{\color{TitleOrange}{Sites web statiques}}
\quad {} $\leftarrow$ {} \quad
Utilise entièrement du logiciel maison. Service le plus fiable !
}

\vspace{1em}

\onslide<3>{
\qquad Partenariat avec l'agence web Noesya qui y héberge une partie de ses clients
}

\begin{tikzpicture}[overlay]
  \node<3> at (14, 0.1) {\includegraphics[width=3em]{noesya.png}};
\end{tikzpicture}

\end{frame}

{
    \usebackgroundtemplate{\includegraphics[height=\paperheight,width=\paperwidth]{fresque-web.png}}
    \setbeamertemplate{navigation symbols}{}
	\begin{frame}[plain]
	\end{frame}
}

\begin{frame}
\frametitle{Infrastructure et logiciels actuels}

{\Large Choix radicaux $\Longrightarrow$ infrastructure spécifique}

\vfill

{\large Comment ça fonctionne actuellement ?}

\end{frame}

{
    \usebackgroundtemplate{\includegraphics[height=\paperheight,width=\paperwidth]{infra.jpg}}
    \setbeamertemplate{navigation symbols}{}
	\begin{frame}[plain]
	\end{frame}
}

\begin{frame}
\frametitle{Infrastructure et logiciels actuels}
\begin{itemize}
\item Des machines en nombre limité et peu puissantes
\item Plusieurs zones géographiques
\item Un orchestrateur distribué ``off the shelf'' (Nomad + Consul)
\item Un logiciel de stockage objet distribué ``maison'' (Garage)
\item Des boucles de rétroaction
\item Des services majoritairement distribués
\end{itemize}
\end{frame}

{
    \usebackgroundtemplate{\includegraphics[height=\paperheight,width=\paperwidth]{assets/deuxfleurs-nomad-20241022.png}}
    \setbeamertemplate{navigation symbols}{}
	\begin{frame}[plain]
	\end{frame}
}

\begin{frame}
\frametitle{Nomad}
\begin{itemize}
\item \textbf{Orchestrateur} développé par Hashicorp / IBM
\item Définition déclarative de ``jobs'' et ``tâches'' avec contraintes
\item Drivers pour exécuter diverses types de tâches (conteneur, Nix, process, classe Java...)
\item Réalise l'ordonnancement des tâches et le maintien en condition
\item Control plane en haute disponibilité (clustering Raft)
\item Possibilité de fédération inter-clusters via gossip (pas utilisé chez Deuxfleurs)
\end{itemize}
\end{frame}

\begin{frame}[fragile]
\frametitle{Exemple de job Nomad (simplifié)}
\begin{footnotesize}
\begin{verbatim}
job "jitsi" {
  datacenters = ["neptune", "scorpio", "corrin"]
  type = "service"
  task "front" {
    driver = "docker"
    config { image = "superboum/amd64_jitsi_meet:v7"
             volumes = ["secrets/certs/jitsi.key:/etc/nginx/jitsi.key"] }
    template { data = "{{ key \"secrets/jitsi/jitsi.key\" }}"
               destination = "secrets/certs/jitsi.key" }
    resources { cpu = 300, memory = 200 }
    service {
      port = "https_port"
      name = "https-jitsi"
      check { type = "tcp"
              port = "https_port"
              interval = "60s"
              timeout = "5s" }
    }
  }
}
\end{verbatim}
\end{footnotesize}
\end{frame}

\begin{frame}
\frametitle{Consul}
\begin{itemize}
\item \textbf{Outil de coordination distribuée} développé par Hashicorp
\item Base de données clé-valeur distribuée (similaire à etcd)
\item Stocke la configuration utile à Nomad + contenu arbitraire
\item Service discovery (via intégration Nomad + API dédiée + DNS)
\item Haute disponibilité (clustering Raft)
\end{itemize}
\end{frame}

\begin{frame}[plain]
\begin{center}
\includegraphics[height=\textheight]{infra_services_control_loop.png}
\end{center}
\end{frame}

\begin{frame}
	\frametitle{Stockage objet avec Garage}
		\begin{center}
			\includegraphics[height=6em]{assets/logos/Amazon-S3.jpg}
			\hspace{3em}
			\includegraphics[height=5em]{assets/logos/minio.png}
			\hspace{3em}
			\includegraphics[height=6em]{logo/garage_hires_crop.png}
		\end{center}
		\vspace{1em}
	S3 est un standard de-facto, beaucoup d'applications sont compatibles

	\vspace{1em}
	MinIO permet d'auto-héberger un service S3 mais ne fonctionne pas en géo-distribué

	\vspace{1em}
	\textbf{Garage est un logiciel libre de stockage objet géo-distribué compatible S3}

        \url{https://garagehq.deuxfleurs.fr/}
\end{frame}

\begin{frame}
\frametitle{Pourquoi du stockage objet S3 ?}
\begin{itemize}
\setlength\itemsep{1.5em}
\item \textbf{API standard} pour stocker des fichiers multimédia\\
  $\Longrightarrow$ compatible Nextcloud, Peertube, Matrix, applis custom ``cloud-native''...
\item \textbf{multi-tenant} : création de buckets via une API standard, isolation entre utilisateurs, clés d'accès avec droits différenciés, quotas...
\item \textbf{facile à exposer en web} pour l'hébergement de sites web statiques\\
  $\Longrightarrow$ Plus pratique et fiable que les systèmes FTP (e.g. intégration Hugo native)
\item \textbf{plus facile à géodistribuer} qu'un système de fichiers POSIX \\
  $\Longrightarrow$ Les applications s'attendent à une cohérence faible.
\end{itemize}
\vfill
Garage offre une cohérence \textbf{Read-after-Write} pour chaque objet.\\
Pas de garantie entre objets.
\end{frame}

\begin{frame}
\frametitle{La sauce (pas si) secrète de Garage}
\begin{itemize}
\item Réplication de chaque objet sur 3 zones, algo de layout optimal statique
\item Tous les noeuds peuvent répondre aux requêtes d'API (pas de master)
\item Quorum de 2 sur 3 noeuds à chaque lecture/écriture $\rightarrow$ garantie de cohérence en évitant un consensus coûteux en latence
\item CRDTs pour les structures de données interne (résiste à la déconnexion)
\end{itemize}
\begin{center}
  \includegraphics[width=.45\linewidth]{assets/garage_carte.png}
\end{center}
\end{frame}

\begin{frame}
	\frametitle{Architecture de Garage}
	\begin{center}
		\includegraphics[width=.45\linewidth]{assets/garage.drawio.pdf}
	\end{center}
\end{frame}

\begin{frame}
\frametitle{La génèse de Garage}

\begin{itemize}
\item Né de la frustration avec GlusterFS, Ceph, MinIO : ils échouent en géodistribué (trop de latence)
\item Développé par Deuxfleurs sur un financement NGI (6 personnes-ans) + NLNet
\item Écrit en Rust
\item Logiciel libre AGPL, contributions externes
\item Bien connu et utilisé, fait concurrence à MinIO sur un segment ``hobbyist++''
\end{itemize}

\vfill

Le design priorise une \textbf{faible empreinte en ressources}, une \textbf{tolérance aux fortes latences} et aux \textbf{déconnexions}, de la \textbf{robustesse}.
\end{frame}

\begin{frame}
\begin{center}
  {\LARGE \color{TitleOrange}\bf Quelques problèmes de recherche}

  \vspace{1em}

  {\Large \color{TitleOrange}\bf en lien avec Deuxfleurs}

  \vspace{3em}

  \begin{enumerate}
  \item \underline{Quel modèle de base de données distribuée ?} \\
  \item FaaS avec limites \\
  \item Ordonnancement distribué, etc \\
  \end{enumerate}
\end{center}
\end{frame}

\begin{frame}{Auto-hébergement traditionnel : pas de haute disponibilité}
  \begin{center}
	\includegraphics[width=0.8\textwidth]{services-oldschool.png}
  \end{center}
\end{frame}

\begin{frame}{Deuxfleurs aujourd'hui : haute disponibilité pour le stockage objet}
  \begin{center}
	\includegraphics[width=0.8\textwidth]{services-garage.png}
  \end{center}
\end{frame}

\begin{frame}{Objectif : haute disponibilité pour les données applicatives}
  \begin{center}
	\only<1>{\includegraphics[width=0.8\textwidth]{services-bdd.png}}%
	\only<2>{\includegraphics[width=0.8\textwidth]{services-bdd-modifies.png}}
  \end{center}
\end{frame}

\begin{frame}
  \textbf{Question : quel modèle de ``base de données distribuée'' veut-on dans ce contexte ?}

  \vfill

  Contraintes :
  \begin{itemize}
  \item tolérance aux fautes $\Rightarrow$ réplication et donc questions de cohérence
  \item géo-distribution avec latence $\Rightarrow$ cohérence plus faible pour avoir des performances acceptables
  \item ressources matérielles limitées $\Rightarrow$ contexte plus ``Edge'' que ``Cloud''
  \end{itemize}
\end{frame}

\begin{frame}{}

  {\large \textbf{Question plus précise :} quel est le bon compromis entre la facilité
  d'implémentation et d'opération de la base de données, et la facilité
  d'utilisation par les applications ?}

  \bigskip

  \begin{itemize}
	\item quel modèle de données ? quelles garanties de cohérence ?
	\item solutions plutôt à chercher du côté des bases NoSQL (Cassandra, Riak, Scylla, ...)
  \end{itemize}

\end{frame}

\begin{frame}
\frametitle{Exemple avec Cassandra : base de données distribuée orientée colonne}

SQL-like, mais expose le sharding à l'application pour avoir de bonnes
performances :

\begin{itemize}
\item l'application définit un modèle de données (table et colonnes) comme en SQL
\item mais pas de ``join'' ou de foreign key (trop coûteux en distribué)
\item l'application choisit une \textbf{partition key} : garantie que toutes les entrées avec la même partition key seront stockées sur le même noeud
\item SELECT sur une valeur unique de partition key : optimisé (un seul noeud à contacter)
\item SELECT sur plusieurs valeurs de partition key : possible mais lent
\end{itemize}
\begin{center}
  \includegraphics[width=.4\linewidth]{assets/cassandra-data-model.jpg}
\end{center}
\end{frame}

\begin{frame}{Une étude de cas encore expérimentale}

  \vfill

  \begin{itemize}
    \setlength\itemsep{1em}
	\item \textbf{Aerogramme} : service d'hébergement e-mail distribué
	%\qquad \includegraphics[width=3em]{assets/logos/aerogramme.pdf}

    \item[] \hspace{-1em} implémenté par dessus :
	\item \textbf{Garage K2V} : BDD clé-valeur, extension expérimentale de Garage
  \end{itemize}

  \vfill

  \begin{center} \includegraphics[width=0.45\textwidth]{aerogramme.png} \end{center}

\end{frame}

\begin{frame}{Garage K2V}

\begin{itemize}
\setlength\itemsep{1em}
\item API clé-valeur
  \begin{itemize}
	\item opérations sur clés individuelles et intervalles de clés
	\item la structure des clés expose la localisation des données : partition key + sort key
  \end{itemize}
\item cohérence faible
  \begin{itemize}
    \item read-after-write sur une même clé
    \item pas de cohérence entre différentes clés
  \end{itemize}
\item les écritures concurrentes sont détectées et doivent être résolues par l'application
\end{itemize}

\end{frame}

\begin{frame}{Aerogramme : serveur IMAP par dessus Garage}

\begin{center}
  \includegraphics[height=0.9\textheight]{aerogramme-general.png}
\end{center}

\end{frame}

\begin{frame}{Aerogramme : modèle de données}

\begin{center}
  \includegraphics[width=.4\linewidth]{aerogramme_datatype.drawio.pdf}
\end{center}

\end{frame}

\begin{frame}{Aerogramme : log d'opérations et cohérence}

Log K2V : historique d'opérations sur une boite mail

\medskip

\begin{itemize}
  \item cohérence faible $\Rightarrow$ certaines opérations sont ajoutées de manière concurrente
  \item ... on peut donc avoir des \textbf{conflits} entre les noeuds pour numéroter un email !
  \item \textbf{astuce} : IMAP permet au serveur de déclarer aux clients qu'il
		faut invalider tous les numéros d'email $\Rightarrow$ permet de renuméroter en cas de conflit
\end{itemize}

\vfill\pause

Conclusion : le fonctionnement d'Aerogramme est subtil

\medskip
\begin{itemize}
\item uniquement possible grâce à une fonctionnalité obscure de IMAP
\item requiert probablement également la cohérence ``monotonic read'' dans K2V (TODO)
\item \textbf{opportunité pour un modèle et une preuve formelle}
\end{itemize}

\end{frame}

\begin{frame}
\begin{center}
  {\LARGE \color{TitleOrange}\bf Quelques problèmes de recherche}

  \vspace{1em}

  {\Large \color{TitleOrange}\bf en lien avec Deuxfleurs}

  \vspace{3em}

  \begin{enumerate}
  \item Quel modèle de base de données distribuée ? \\
  \item \underline{FaaS avec limites} \\
  \item Ordonnancement distribué, etc \\
  \end{enumerate}
\end{center}
\end{frame}

\begin{frame}
\frametitle{Function as a Service (FaaS) contraint}
\begin{itemize}
\setlength\itemsep{1em}
\item \textbf{Sites web statiques} mis en avant par Deuxfleurs mais parfois limitant
\item \textbf{Fonctionnalités dynamiques} souvent demandées\\
  $\Longrightarrow$ suivi de fréquentation, redimensionnement d'images, interface d'édition type CMS
\item \textbf{Choix d'un modèle d'exécution générique} de type FaaS (WebAssembly)
\item \textbf{Contraintes fortes} en ressources (CPU limité) et en sécurité (infra partagée)
\item \textbf{Dynamicité} de la demande (effet Slashdot / Hackernews)
\end{itemize}
%AWS Lambda, Cloudflare Workers.  Maintenant WASM
\vfill
{\Large Quels mécanismes de partage des ressources entre des utilisateurs FaaS sous charge dynamique sur une infrastructure limitée ?}
\end{frame}

\begin{frame}
\frametitle{Des questions de design}
\begin{itemize}
\item Veut-on limiter l'usage \textit{a priori} ou uniquement en cas de surcharge ?
\item Quel contrat moral avec l'utilisateur ?  Peut-on couper ses fonctions en cas de surcharge ?
\item Comment être équitable face à des besoins et usages très hétérogènes ?
\item Comment visibiliser la consommation de ressources auprès de chaque utilisateur ?
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Des questions informatiques}
\begin{itemize}
\setlength\itemsep{1em}
\item Système de quota ou de ``karma''\\
      $\rightarrow$ comment on regagne du karma (au fil du temps, plafond, équitable ou selon le trafic du site web...)\\
      $\rightarrow$ comment on dépense du karma (temps CPU, nombre d'instruction WASM...)\\
      $\rightarrow$ comment le karma sert-il à prioriser les requêtes entre elles (relatif, absolu)
\item Stratégie de file d'attente pour ``drop'' des requêtes\\
      $\rightarrow$ une file d'attente par utilisateur ou par service
\item Les requêtes ont potentiellement des deadlines
\item Ordonnancement des requêtes entre plusieurs machines
\item Garanties statistiques sur le temps d'exécution ou le taux de drop
\end{itemize}

\vfill

Related work : OS scheduler, FaaS, théorie des files d'attente (mais ressources limitées = peu de multiplexage statistique et pas de modèle fluide)
\end{frame}

\begin{frame}
\begin{center}
  {\LARGE \color{TitleOrange}\bf Quelques problèmes de recherche}

  \vspace{1em}

  {\Large \color{TitleOrange}\bf en lien avec Deuxfleurs}

  \vspace{3em}

  \begin{enumerate}
  \item Quel modèle de base de données distribuée ? \\
  \item FaaS avec limites \\
  \item \underline{Ordonnancement distribué, etc} \\
  \end{enumerate}
\end{center}
\end{frame}

\begin{frame}
\frametitle{Autres pistes de recherche}
\begin{itemize}
\setlength\itemsep{0.8em}
\item Orchestrateur géo-distribué à la Nomad/Consul sans consensus Raft\\
  \textit{``Nomad servers are expected to be able to communicate in high bandwidth, low latency network environments and have below 10 millisecond latencies between cluster members.''}
\item Analyse de performance de Garage
\item Analyse de robustesse de Garage
\item Mesures de la résilience d'une infrastructure distribuée
\item Modélisation d'une infrastructure distribuée pour prouver des propriétés de correction
\item Continuum de coordination entre Raft (fort) et quorum (faible) : leaderless consensus ?
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Conclusion}

\end{frame}

\end{document}

%% vim: set ts=4 sw=4 tw=0 noet spelllang=en :
