From c28ff010a14bf9d64d2dfd83166abdc45b500b81 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arma=C3=ABl=20Gu=C3=A9neau?= Date: Wed, 2 Apr 2025 23:32:10 +0200 Subject: [PATCH] restructuration --- 2025-04-03-stack/talk.tex | 189 ++++++++++++++++++++++---------------- 1 file changed, 111 insertions(+), 78 deletions(-) diff --git a/2025-04-03-stack/talk.tex b/2025-04-03-stack/talk.tex index f1184b1..344a474 100644 --- a/2025-04-03-stack/talk.tex +++ b/2025-04-03-stack/talk.tex @@ -362,90 +362,22 @@ Le design priorise une \textbf{faible empreinte en ressources}, une \textbf{tol \begin{frame} \begin{center} - {\Large \color{TitleOrange}\bf Quelques problèmes de recherche} + {\LARGE \color{TitleOrange}\bf Quelques problèmes de recherche} \vspace{1em} - {\color{TitleOrange}\bf en lien avec Deuxfleurs} + {\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} -\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} -\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} - -\begin{frame} - \frametitle{Architecture de Garage} - \begin{center} - \includegraphics[width=.45\linewidth]{assets/garage.drawio.pdf} - \end{center} -\end{frame} - -\begin{frame} - problèmes de recherche -\end{frame} - \begin{frame}{Auto-hébergement traditionnel : pas de haute disponibilité} \begin{center} \includegraphics[width=0.8\textwidth]{services-oldschool.png} @@ -591,6 +523,107 @@ Conclusion : le fonctionnement d'Aerogramme est subtil \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 :