68 lines
4.3 KiB
TeX
68 lines
4.3 KiB
TeX
\section{Erkannte Grenze: Nebenläufigkeit im Lookup}
|
|
\label{sec:race-conditions}
|
|
|
|
\subsection{Ausgangslage}
|
|
|
|
Der Lesepfad des Kundenordner-Lookups ist unkritisch. Der in Abschnitt~\ref{sec:folder-management} beschriebene dritte Schritt ist jedoch \emph{verändernd}: Er benennt Ordner um und legt sie an, im Rahmen einer gewöhnlichen Seitenanfrage. Da Houston in mehreren Instanzen betrieben wird, reicht eine Sperre innerhalb einer Instanz nicht aus. Bei der Durchsicht des Codes wurden zwei Fehlerszenarien gefunden, die ausdrücklich formulierte Akzeptanzkriterien verletzen.
|
|
|
|
\subsection{Zwei Szenarien}
|
|
|
|
Abbildung~\ref{fig:race-condition-a} zeigt exemplarisch Szenario~A; Tabelle~\ref{tab:race-conditions} stellt beide Fälle einander gegenüber.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[width=\textwidth]{figures/diagrams/race-condition-a.pdf}
|
|
\caption{Datenverlust bei gleichzeitigem Umbenennen}
|
|
\label{fig:race-condition-a}
|
|
\end{figure}
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\begin{tabularx}{\textwidth}{@{} l X X @{}}
|
|
\toprule
|
|
\textbf{Szenario} & \textbf{Ursache} & \textbf{Auswirkung} \\
|
|
\midrule
|
|
A: Datenverlust beim Umbenennen &
|
|
Zwei Anfragen halten den Zielnamen für frei, da beide prüfen, bevor eine schreibt. A kopiert und löscht die Quelle; B's Fehlerbehandlung entfernt daraufhin dieselben (bereits von A geschriebenen) Objekte. &
|
|
Quelle und Kopie sind gelöscht — Datenverlust. \\
|
|
\addlinespace
|
|
B: Vermischung zweier Mandanten &
|
|
Der Marker wird ohne Bedingung geschrieben. Haben zwei Organisationen denselben Firmennamen, gewinnt beim gleichzeitigen Erstzugriff der zuletzt geschriebene Marker. &
|
|
Beide arbeiten im selben Ordner; zwischenzeitlich Abgelegtes bleibt im fremden Ordner — Vertraulichkeitsproblem, schwerwiegender als A. \\
|
|
\bottomrule
|
|
\end{tabularx}
|
|
\caption{Erkannte Nebenläufigkeitsszenarien im Kundenordner-Lookup}
|
|
\label{tab:race-conditions}
|
|
\end{table}
|
|
|
|
Nicht betroffen sind zwei gleichzeitige Anfragen derselben Organisation (identische Schlüssel) sowie Lesezugriffe während einer Verschiebung, da der Marker zuletzt kopiert wird. Das Problem beschränkt sich auf zwei \emph{unterschiedlich weit fortgeschrittene} verändernde Vorgänge.
|
|
|
|
\subsection{Erwogene Gegenmaßnahmen}
|
|
|
|
Tabelle~\ref{tab:race-countermeasures} stellt die vier erwogenen Ansätze gegenüber; der erste sollte unabhängig von der Serialisierungslösung umgesetzt werden, der vierte ist eine organisatorische statt technische Lösung.
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\begin{tabularx}{\textwidth}{@{} l X @{}}
|
|
\toprule
|
|
\textbf{Ansatz} & \textbf{Wirkung} \\
|
|
\midrule
|
|
Absicherung der Fehlerbehandlung & Prüfung, ob der Marker der Quelle vor dem Entfernen der Teilkopien noch existiert; beseitigt A weitgehend, es bleiben überzählige Objekte statt Datenverlust. \\
|
|
\addlinespace
|
|
Bedingtes Schreiben & Marker nur schreiben, falls noch nicht vorhanden, macht das Beanspruchen eines Namens unteilbar und schließt B aus \autocite{aws-conditional-writes}; setzt Unterstützung durch den Speicher voraus. \\
|
|
\addlinespace
|
|
Instanzübergreifende Sperre & Sperre je Organisation über die Datenbank serialisiert den verändernden Teil sauber, kostet aber einen zusätzlichen Zugriff je Anfrage und ein Konzept für nicht freigegebene Sperren. \\
|
|
\addlinespace
|
|
Verlagerung aus dem Anfragepfad & Einmalige kontrollierte Migration der Bestandsordner; die Anwendung protokolliert nur noch Abweichungen vom Sollzustand — die Ursache verschwindet vollständig. \\
|
|
\bottomrule
|
|
\end{tabularx}
|
|
\caption{Erwogene Gegenmaßnahmen gegen die Nebenläufigkeitsszenarien}
|
|
\label{tab:race-countermeasures}
|
|
\end{table}
|
|
|
|
\subsection{Umgang mit dem Befund}
|
|
|
|
Der Befund wurde als eigenes Backlog Item mit erhöhter Priorität erfasst, vom laufenden Pull Request abgegrenzt und mit einem Zeitrahmen von vier bis sechs Stunden versehen.
|
|
|
|
Den Pull Request offenzuhalten, hätte den Lookup blockiert: Ob bedingtes Schreiben verfügbar ist, ließ sich ohne Rückfrage beim Betreiber nicht beantworten, deren Bearbeitungsdauer zuvor mit mehreren Wochen bemessen worden war. Der Lookup verbessert den Zustand bereits deutlich, und der verändernde Pfad wird nur beim ersten Zugriff einer Organisation durchlaufen — das Risikofenster besteht pro Kunde genau einmal. Die Akzeptanzkriterien des Folgeitems halten fest, dass eine reine Sperre innerhalb einer Instanz nicht akzeptiert wird und beide Szenarien durch Unit-Tests nachzubilden sind.
|