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

FaaS contraint

Browse source
This commit is contained in:
Baptiste Jonglez 2025-04-02 22:49:46 +02:00
parent aff93f0c17
commit c766d31a90
1 changed files with 74 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -360,6 +360,80 @@ Pas de garantie entre objets.
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}
{\color{TitleOrange}\bf en lien avec Deuxfleurs}
\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}