674 lines
20 KiB
TeX
674 lines
20 KiB
TeX
\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}
|
|
|
|
\textbf{Baptiste Jonglez}
|
|
\begin{itemize}
|
|
\item ingénieur recherche à Inria Stack
|
|
\end{itemize}
|
|
|
|
\vfill
|
|
|
|
\textbf{Armaël Guéneau}
|
|
\begin{itemize}
|
|
\setlength\itemsep{0.5em}
|
|
\item chargé de recherche à Inria Toccata
|
|
\item domaine de recheche : méthodes formelles, preuve de programmes, sémantique \\ (Coq, Iris, OCaml, Why3...)
|
|
\item membre du projet Creusot, un outil de vérification de code Rust
|
|
\item intérêt grandissant pour les systèmes distribués grâce à Deuxfleurs !
|
|
\end{itemize}
|
|
|
|
\vfill
|
|
|
|
Membres de Deuxfleurs
|
|
|
|
\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}{Tous les services de Deuxfleurs ne sont pas encore distribués}
|
|
|
|
E-mail et agenda \; \& \; Bureautique
|
|
\begin{itemize}
|
|
\item stockent des fichiers sur le disque local
|
|
\item \textbf{pas distribué}
|
|
\end{itemize}
|
|
|
|
\bigskip
|
|
|
|
Discussion instantanée \; \& \; Forge logicielle
|
|
\begin{itemize}
|
|
\item utilisent une BDD SQL
|
|
\item distribué mais via un logiciel qui n'est \textbf{plus maintenu} (PostgreSQL + Stolon)
|
|
\end{itemize}
|
|
|
|
\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}
|
|
\centering
|
|
\includegraphics[width=.15\linewidth]{assets/logos/deuxfleurs.pdf}
|
|
\vfill
|
|
{\Large Une infrastructure alternative avec des choix radicaux possibles}
|
|
\vfill
|
|
{\Large Mais aussi des vrais utilisateurs, des attentes de qualité}
|
|
\vfill
|
|
{\Large $\Longrightarrow$ réappropriation de problèmes de recherche hors GAFAM / grandes entreprises}
|
|
\end{frame}
|
|
|
|
\end{document}
|
|
|
|
%% vim: set ts=4 sw=4 tw=0 noet spelllang=en :
|