Deuxfleurs/talks
17
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

restructuration

Browse source
This commit is contained in:
Armaël Guéneau 2025-04-02 23:32:10 +02:00
parent de3858f7db
commit c28ff010a1
1 changed files with 111 additions and 78 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

189
2025-04-03-stack/talk.tex
View file

@ -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 :