\section{Containerisierung und  Modularisierung}

Um eine optimale Skalierbarkeit zu erreichen wird die Anwendung in einzelne
Module aufgeteilt und in einzelne Container verpackt. Dadurch ist es einfach
möglich die Anwendung auf mehreren Rechnern gleichzeitig laufen zu lassen und
entsprechende Interaktionen zwischen den Container zu definieren.

\subsection{Modularisierung des Generators}
Um den Generator zu modularisieren muss erst definiert werden was für
potentielle Module existieren und wie diese miteinander interagieren.

\par Insgesamt generiert der Generator zufällige Werte in einem gegebenen
Intervall, testet mithilfe des NFW-profils ob diese Sterne existieren oder
nicht und schreibt die Sterne anschließend in eine Datenbank. Es sind sofort
ein paar Module ersichtlich: ein Modul welches die Zufälligen Koordinaten
generiert, ein Modul welches den Wert aus dem NFW-Profil berechnet und ein
Modul welches die Daten in die Datenbank schreibt.

\begin{figure}[ht!]
\centering
\begin{forest}
    for tree={draw, grow=0}
    [DB
        [generator
            [traefik
                [NFW]
                [\( \dots \)]
                [NFW]
            ]
        ]
    ]
\end{forest}
\label{fig:generator_setup}
\end{figure}

\subsubsection{Generator Modul}
Das Generator Modul generiert zufällige Koordinaten in einem definiertem
Intervall und sendet diese an einen NFW Container.  Damit nicht ein Container
unter der last der ein kommenden Antworten leidet wird der reverse-Proxy
Traefik\footnote{\url{https://traefik.io/}} verwendet. Dieser routet die
Anfragen an weitere Container weiter wodurch optimale Lastverteilung und
Skalierbarkeit gegeben ist.

\subsubsection{NFW Modul}
Das NFW modul erhält einen Wert und berechnet den entsprechenden NFW Wert.
Dadurch das er durch Traefik angesteuert wird kann falls die Anzahl der
Anfragen zu hoch wird einfach ein identische Container gestartet werden.
Traefik erkennt diesen Container automatisch und kann diesen beim routen der
Anfragen entsprechend nutzen.

\subsubsection{DB Modul (1)}

\subsection{Modularisierung des Simulators}
Der Simulator simuliert die Sterne aus der Datenbank indem er Stern für Stern
die Kraft die auf einen Stern wirkt berechnet, die neue Position des Sternes
ausrechnet und anschließend den ``neuen'' Stern zurück in die Datenbank
schriebt.

\begin{figure}[ht!]
\centering
\begin{forest}
    for tree={draw, grow=0}
    [DB
        [DB-actions
            [manager
                [Simulator]
                [\( \dots \)]
                [Simulator]
            ]
        ]
    ]
\end{forest}
\label{fig:simulator_setup}
\end{figure}

\subsubsection{Manager}
Um die Simulations Container optimal skalieren zu können, wird statt den
Simulations Container aktiv Sterne zu geben darauf gewartet, dass ein
Simulations Container einen Stern anfragt. Der Manager fragt im Vorhinein die
Datenbank an um eine Liste an Stern-IDs zu bekommen auf die die Kraft berechnet
werden müssen. Diese Liste an Stern-IDs wird in einen Channel geschrieben,
welcher die Sterne einzeln ausgeben kann.  Sobald der Channel leer ist,
entnimmt der Manager der Datenbank die nächsten Stern-IDs.

\subsubsection{Simulator}
Der Simulator Container entnimmt dem Manager Container einen Stern und
berechnet die Kraft die auf ihn wirkt indem er den in der Datenbank
gespeicherten Baum in Kombination des Barnes-Hut Algorithmus nutzt. Nachdem die
Kraft berechnet wurde kann die Neue Position des Stenes berechnet werden und
wieder in die Datenbank eingefügt werden.

\subsubsection{DB Modul (2)}
Der Datenbank Container interagiert mit der Datenbank und stellt verschiedene
Methoden zur Verfügung um z.B. Sterne in die Datenbank einzufügen, Daten aus
der Datenbank zu erhalten und den Massen Mittelpunkt aller inneren Knoten zu
berechnen.

\subsection{Sonstige Container}

\subsubsection{Viewer}
\subsubsection{Controller}

\subsection{Datenbank Skalierung}

\begin{figure*}[ht]
\centering
\begin{forest}
    [, s sep+=5mm, draw, circle
        [A,tikz={\node[draw,fit=()(!1)(!l), label=below:Server 1] {};}, draw, circle
            [\(\dots\)]
            [\(\dots\)]
            [\(\dots\)]
            [\(\dots\)]
        ]
        [B,tikz={\node[draw,fit=()(!1)(!l), label=below:Server 2] {};}, draw, circle
            [\(\dots\)]
            [\(\dots\)]
            [\(\dots\)]
            [\(\dots\)]
        ]
        [C,tikz={\node[draw,fit=()(!1)(!l), label=below:Server 3] {};}, draw, circle
            [\(\dots\)]
            [\(\dots\)]
            [\(\dots\)]
            [\(\dots\)]
        ]
        [D,tikz={\node[draw,fit=()(!1)(!l), label=below:Server 4] {};}, draw, circle
            [\(\dots\)]
            [\(\dots\)]
            [\(\dots\)]
            [\(\dots\)]
        ]
    ]
\end{forest}
\caption{Die Teilbäume \(A, B, C\) und \(D\) werden auf vershiedenen Systemen betrieben und entsprechend angesprochen.}
\label{fig:tree_sharding}
\end{figure*}

Ein Bottleneck das bei der Skallierung enersteht ist die Anbinding and die
Datenbank: Desto mehr Simulations-Container mit der Datenbank interagieren,
desto höher wird die Auslastung der Datenbank. Um dieses Problem zu lösen
bietet es sich an die Datenbank in mehrere teile aufzuspalten. Ein weiters
essenzielles Problem das bei der Verteilung der Simulations rechen Knoten in
verschiedene rechenzentren entsteht ist, dass die Bandbreite zur Datenbank
sinkt und die Latenz steigt.  

\subsubsection{Sharding}
Ab einer gewissen Größe kann eine Galaxie nicht mehr in einer Datenbank
gespeichert werden. Diese muss demnach auf mehrere Rechner aufgeteilt werden.
Da die Datenbank einerseits die einzelnen Sterne Speicher und Bäume welche die
Sterne referenziert bietet es sich hier an diese beiden Bestandsteile der
Datenbank in einzelne Datenbanken auszulagern.

\paragraph{Sterne} ~\\
Möchte man eine Liste an Stenen auf mehrere Datenbanken aufspalten wird die
Liste entsprechend aufgeteilt und auf die Datenbanken verteilt. Wird nun ein
bestimmter Stern gesucht wird die Anfrage über einen reverse-proxy geleitet
welcher die Anfrage and die entsprechende Datenbank weiterleitet. 

\par Es ist somit möglich die Liste an sternen auf mehrere Datenbanken
aufzuteilen und somit die Last von einem System auf mehrere zu verteilen.

\paragraph{Bäume} ~\\
Die Aufteilung der Datenbank in der die Bäume gespeichert werden gestaltet sich
ähnlich. Statt alle Bäume in einer Datenbank zu speichern, werden die
entsprechenden Teilbäume ab einer bestimmten Tiefe in verschiedene Datenbanken
verteilt. Die Interaktion mit der Datenbank verändert sich nur minimal. Statt
bei einer Anfrage an die Wurzel eines Baumes die entsprechenden node\_ids der
Kinder zu bekommen, erhält man die Adresse der Datenbank in der der Teilbaum
gespeichert wird. Dies ist in Abbildung \ref{fig:tree_sharding} visuell dargestellt.

\subsubsection{Caching}
Ein weiters Problem das mit der Nutzung eines verteilten Systems entsteht ist
die Bandbreite zwischen den Simulatoren und der Datenbank und die entsprechene
Latenz. Mehrere Messungen zwischen verschiedenen Stervern sind in Abbildung
\ref{fig:bandwidth_latency} dargestellt.

\begin{figure}
\centering
\begin{tabular} {l | l | l | l}
Server 1 & Server 1 & Bandbreite & Latenz \\
(Standort) & (Standort) & (Mb/s) & (ms) \\ \hline\hline
Nuremberg & Helsinki & 450 & 23 \\ \hline
Nuremberg & Nuremberg & 2000 & \\ \hline
localhost & localhost & 55000 & 0.07 \\ \hline
\end{tabular}
\caption{Messungen der Anbindungen zwischen verschiedenen Servern. Die Messung
Nuremberg \( \leftrightarrow \) Nuremberg bezieht sich auf zwei Server im
gleichen Rechenzentrum und die Messung localhost \( \leftrightarrow \)
localhost auf die selbe Maschine}
\label{fig:bandwidth_latency}
\end{figure}

\par Es wird deutlich, dass falls der Server auf der die Datenbank läuft sich
physisch sehr weit von den Servern auf denen sich die Simulation-container
befinden steht, die Bandbreite zu problemen führt. Es bietet sich also an die
Daten die viel von den simulations-containern genutzt werden physisch näher an
die simulations-container zu bringen um so Proleme die durch die niedrige
Bandbreite und hohe Latenz entstehen zu minimieren. Dies ist in Abbildung
\ref{fig:local_caching} zu sehen: Es existiert eine Haupt-Datenbank welche alle
Zeitschritte speichert und mit den lokalen Datenbanken kommuniziert. Diese
Speichern den jeweilichen Zeitschritt, den die Simulations-Container benötigen
um die kraftberechnnung durchzuführen. Sobald der Lokale Cache leer ist wird
der Nächste Zeitschritt von der Datenbank in den cache kopiert und die
Simulations-Container können mit der Arbeit fortfahren.

\begin{figure}
\begin{adjustbox}{width=\textwidth/2}
\tikzset{concept/.append style={fill={none}}}
\begin{tikzpicture}
  \path[mindmap,concept color=black,text=black]
    node[concept] {Haupt Datenbank}
    [clockwise from=0]
    child[draw, concept color=black] {
        node[concept] {Nuremberg \\ Cache}
        [clockwise from=67.5]
        child { node[concept] {Simulator 1} }
        child { node[concept] {Simulator 2} }
        child { node[concept] {Simulator 3} }
    }
    child[draw, concept color=black] {
        node[concept] {Helsinki \\ Cache}
        [clockwise from=0]
        child { node[concept] {Simulator 1} }
        child { node[concept] {Simulator 2} }
        child { node[concept] {Simulator 3} }
    }
    child[draw, concept color=black] {
        node[concept] {Falkenstein \\ Cache}
        [clockwise from=-60.5]
        child { node[concept] {Simulator 1} }
        child { node[concept] {Simulator 2} }
        child { node[concept] {Simulator 3} }
    }
    child[draw, concept color=black] {
        node[concept] {Amsterdam \\ Cache}
        [clockwise from=240]
        child { node[concept] {Simulator 1} }
        child { node[concept] {Simulator 2} }
        child { node[concept] {Simulator 3} }
    }
    child[draw, concept color=black] {
        node[concept] {\( \dots \) \\ Cache}
        [clockwise from=-180]
        child { node[concept] {Simulator 1} }
        child { node[concept] {Simulator 2} }
        child { node[concept] {Simulator 3} }
    };
\end{tikzpicture}
\end{adjustbox}
\caption{Aufspaltung der Datenbank und Nutzung von localen Caches}
\label{fig:local_caching}
\end{figure}