scalability

DMS_paper15_gitlab.tex

@@ -505,6 +505,21 @@ stages:
 		\end{table}
 		\subsection{Skalierbarkeit}
 		
+		GitLab bietet Empfehlungen für Referenz-Architekturen, welche versuchen einen Kompromiss zwischen den Kriterien Performanz, Resilienz und finanzieller Kosten herzustellen. Um eine passende Architektur zu wählen orientiert sich GitLab an der Metrik: \ac{RPS}. Die RPS lassen sich nach Anfrage in folgende Typen aufgliedern \cite{gitlab_gitlab_nodate}:
+		\begin{itemize}
+			\item API-Anfragen, zu welchen Integrationen, Automatisierungsmechanismen, Webhooks und sonstige Dienste, die direkt auf die API zugreifen, gehören. Üblicherweise machen API-Anfragen ca. 80 \% der gesamten \ac{RPS}-Anfragen aus
+			\item Web-Anfragen, dazu zählen beispielsweise Interaktionen mit der Weboberfläche. Dies sind meist 10 \% aller Anfragen.
+			\item Git-Operationen, hier aufgeschlüsselt in Pull und Push-Operationen. Git-Operationen entsprechen ca. den restlichen 10 \%.
+		\end{itemize}
+		Mithilfe von Abbildung \ref{fig:reference_architecture_users} lassen sich ungefähre Anzahlen an \ac{RPS} nach Benutzern einer GitLab-Instanz schätzen. In einigen Umgebungen können die vorgegebenen Schätzungen von der Realität stark abweichen. Es ist notwendig selbst zu evaluieren wie das System aufgebaut werden soll bzw. welche Anpassungen gemacht werden müssen.
+		\begin{figure}[H]
+			\includegraphics[width=\columnwidth]{bilder/gitlab_reference_architecture_users_rps.png}
+			\caption{RPS-Schätzung nach Benutzeranzahl für das Linux-Paket \cite{gitlab_gitlab_nodate}}
+			\label{fig:reference_architecture_users}
+		\end{figure} Im Grunde gibt es zwei Möglichkeiten zu skalieren. Dazu zählt die Verwendung einer höher liegenden Referenzarchitektur oder die horizontale oder Vertikale Skalierung einzelner Komponenten. Bei der horizontalen Skalierung müssen Lastverteiler hinzugefügt und konfiguriert werden.
+		GitLab bietet für einige Intervalle an zu erwartenden Nutzern (bzw. \ac{RPS}) Empfehlungen für \href{https://docs.gitlab.com/administration/reference_architectures/}{Architekturen}. Alle Architekturen sind auf eine Skalierung ausgelegt. Weitere Funktionalitäten ergeben erst ab einer gewissen Anzahl an Benutzern Sinn. Der Betrieb von GitLab im High Availability Modus stellt sicher, dass einzelne Komponenten bei Ausfällen kompensiert werden können. Durch Redundanz ergeben sich höhere finanzielle Kosten. GitLab gibt an, dass die Schwelle für den Betrieb im High Availability Modus bei ungefähr 3000 Nutzern liegt \cite{gitlab_gitlab_nodate}. Um die Ausfallsicherheit weiter zu erhöhen kann GitLab in mindestens zwei Umgebungen innerhalb unterschiedlicher Regionen betrieben werden. Dies führt zu höheren Kosten und einem komplexeren Systemaufbau. Einzelne Komponenten von GitLab können in die Cloud ausgelagert werden. Grössere Repositories, sogenannte \textit{Monorepos} mit einer Grösse von mehreren Gigabytes, können zu hohen Auslastungen führen. Die hohe Last ist softwareseitig begründet, weshalb die Skalierung durch zusätzliche Hardware kaum Nutzen erweist. Die Auslastung kann durch Optimierungsmassnahmen am Repository verringert werden \cite{gitlab_gitlab_nodate}. Eine Gefahr beim Skalieren einer einzelnen Komponente kann zu ungewollten Konsequenzen führen. Die empfohlenen Architekturen sind so ausgelegt, dass die Skalierung der einzelnen Komponenten in einem passenden Verhältnis zueinander stehen. Besitzt eine skalierte Komponente einen höheren Durchlauf kommt die Last, bei abhängigen Komponenten an. Diese müssen zwangsweise ebenso skaliert werden \cite{gitlab_gitlab_nodate}.
+		
+		
 		\subsection{Dokumentation}
 		
 		Alle GitLab-Lösungen sind umfassend auf der offiziellen Seite \url{https://docs.gitlab.com/} dokumentiert. Jeder Release von GitLab besitzt bezüglich Haupt- und Nebenversionsnummer eine eigene Version der Dokumentation. Online kann auf eine eingeschränkte Auswahl zugegriffen werden. Nach den Ausgaben der Dokumentation kann unter \url{https://archives.docs.gitlab.com/} gesucht werden. Diese Suche reicht zurück bis zur Version 16.0. Nach Bedarf können ältere Versionen im Offline-Archiv \url{https://docs.gitlab.com/archives/#offline-archives} als Docker-Container heruntergeladen und gestartet werden. Das Offline Archiv reicht bis zu der Version 10.3 zurück. Die Dokumentation wird aus den Quellcode-Repositories der GitLab Projekte gebaut und in regelmässigen Abständen aktualisiert \cite{gitlab_gitlab_nodate}.
@@ -542,6 +557,7 @@ stages:
 			\acro{HTTPS}{Hypertext Transfer Protocol Secure}
 			\acro{SSH}{Secure Shell}
 			\acro{S/MIME}{Secure/Multipurpose Internet Mail Extensions}
+			\acro{RPS}{Requests per Second}
 		\end{acronym}
 		
 		\printbibliography

other/.~lock.statistics.ods#

@@ -0,0 +1 @@
+,Lambda/Roman,Lambda,09.06.2026 18:04,file:///C:/Users/Roman/AppData/Roaming/LibreOffice/4;