{"id":27142,"date":"2025-02-27T17:01:13","date_gmt":"2025-02-27T16:01:13","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=27142"},"modified":"2025-02-27T17:01:15","modified_gmt":"2025-02-27T16:01:15","slug":"entwicklung-eines-skalierbaren-file-share-services-mit-aws","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2025\/02\/27\/entwicklung-eines-skalierbaren-file-share-services-mit-aws\/","title":{"rendered":"Entwicklung eines skalierbaren File-Share-Services mit AWS"},"content":{"rendered":"\n
\"\"<\/a><\/figure>\n\n\n\n
\n

tl;dr:<\/strong> Unser Semester-Projekt bestand im Aufbau einer skalierbaren File-Share-L\u00f6sung auf AWS auf Basis von NextCloud. Unsere Motivation bestand darin die volle Kontrolle \u00fcber die eigenen Daten zu erlangen, individuelle Anpassbarkeit zu erm\u00f6glichen und eine Kosteneffizienz zu erreichen. Es wurden klare Ziele in den Bereichen Verf\u00fcgbarkeit, Performanz, Sicherheit und Skalierbarkeit definiert, anhand deren das Projekt ausgerichtet wurde. Dabei kamen AWS-Dienste wie VPC, Route 53, Certificate Manager, ALB, ASG, EC2, RDS und S3 zum Einsatz. Learnings aus diesem Projekt bestanden in den f\u00fcr uns wertvollen Einblicken in Planung, Skalierung und Herausforderungen mit AWS-Services.<\/p>\n<\/blockquote>\n\n\n\n

Motivation<\/h1>\n\n\n\n

Wie man einen Cloud-Dienst – \u00e4hnlich wie iCloud oder Google Drive – entwickelt und dabei m\u00f6glicherweise den hohen Geb\u00fchren entkommen kann , besch\u00e4ftigt uns schon seit geraumer Zeit. Im Rahmen der Vorlesung System Engineering & Management<\/strong> hatten wir dieses Semester die Gelegenheit dieser Frage nachzugehen.<\/p>\n\n\n\n

Die Entscheidung, einen eigenen Cloud-Dienst aufzusetzen, bietet gleich mehrere interessante Aspekte.<\/p>\n\n\n\n

Ein wesentlicher Vorteil liegt in der vollst\u00e4ndigen Kontrolle \u00fcber die eigenen Daten<\/strong>. Da der Standort und die Speicherung der Daten selbst bestimmt werden, entf\u00e4llt die Abh\u00e4ngigkeit von externen Anbietern \u2013 und damit m\u00f6glicherweise auch der Vendor-Lock-In. Gleichzeitig bringt diese Selbstbestimmung jedoch auch volle Eigenverantwortung f\u00fcr die Datensicherheit mit sich, was ein erhebliches Risiko darstellen kann.<\/p>\n\n\n\n

Ein weiterer Vorteil liegt in der individuellen Anpassbarkeit<\/strong> des Dienstes. Anders als bei standardisierten Angeboten etablierter Cloud-Anbieter bietet eine eigens entwickelte L\u00f6sung die M\u00f6glichkeit, Konfiguration und Anpassungen exakt auf die spezifischen Bed\u00fcrfnisse des Nutzers abzustimmen \u2013 auch wenn dies mit einem h\u00f6heren initialen Entwicklungsaufwand verbunden ist.<\/p>\n\n\n\n

Angesichts der oft hohen monatlichen Kosten kommerzieller Cloud-Dienste stellt sich die Frage, ob eine eigene L\u00f6sung langfristig kosteneffizienter betrieben werden kann. Auch wenn sich diese Frage nicht pauschal beantworten l\u00e4sst, bietet sie zumindest den Anreiz, alternative Ans\u00e4tze auszuprobieren.<\/p>\n\n\n\n

Nicht zuletzt bietet dieses Projekt zudem die ideale M\u00f6glichkeit, praxisnah wertvolle Erfahrungen in der Entwicklung mit modernen Cloud-Technologien zu sammeln. Wie Richard Feynman schon sagte: \u201cWhat I cannot create, I do not understand<\/em>\u201d, wollen wir durch dieses Projekt lernen, was es bedeutet, einen eignen Cloud-Dienst skalierbar aufzubauen.<\/p>\n\n\n\n

\n\n\n\n

Ziele<\/h1>\n\n\n\n

Um den Rahmen f\u00fcr unser Projekt und die sp\u00e4tere Architektur klar abzustecken, haben wir zun\u00e4chst pr\u00e4zise Ziele definiert. Ein zentraler Entschluss war, die Anwendungslogik nicht selbst zu entwickeln \u2013 da unser Team aus lediglich zwei Personen besteht. Stattdessen haben wir uns bewusst daf\u00fcr entschieden, eine bestehende Open-Source-L\u00f6sung zu integrieren. Aufgrund der umfassenden Dokumentation und einer gro\u00dfen Entwickler-Community fiel die Wahl auf NextCloud<\/strong>. Diese Entscheidung erm\u00f6glichte es uns, unseren Fokus auf die kritischen Aspekte der Architektur zu legen, anstatt auf die reine Softwareentwicklung.<\/p>\n\n\n\n

Orientierung \u00fcber den gesamten Projektverlauf hinweg gaben uns daher die nach folgenden Ziele:<\/p>\n\n\n\n

1. Verf\u00fcgbarkeit<\/h3>\n\n\n\n
\n

Die Architektur soll eine prinzipielle Verf\u00fcgbarkeit von 99,9% gew\u00e4hrleisten<\/em>.<\/strong><\/p>\n<\/blockquote>\n\n\n\n

Das bedeutet, dass innerhalb eines Monats maximal ca. 43 Minuten ungeplante Downtime toleriert werden d\u00fcrfen. Diese hohe Verf\u00fcgbarkeit erfordert mehr als den Einsatz eines einzigen Servers. Stattdessen m\u00fcssen ausfallsichere Strukturen in die Planung einbezogen werden, um die geforderte Betriebszeit sicherzustellen.<\/p>\n\n\n\n

2. Performanz<\/h3>\n\n\n\n

Ein weiteres Ziel ist die schnelle Reaktionszeit der Anwendung.<\/p>\n\n\n\n

\n

Konkret soll die Time-to-First-Byte (TTFB) der Benutzeroberfl\u00e4che unter 200 ms liegen.<\/strong><\/em><\/p>\n<\/blockquote>\n\n\n\n

Dieser h\u00e4ufig genannte Richtwert gew\u00e4hrleistet, dass Nutzer nahezu unmittelbar eine Antwort beim Aufruf der Seite erhalten.<\/p>\n\n\n\n

3. Sicherheit<\/h3>\n\n\n\n

Angesichts der sensiblen Daten, die in einer pers\u00f6nlichen Cloud verarbeitet werden, ist Sicherheit eines unserer Hauptziele.<\/p>\n\n\n\n

\n

Zum einen soll ausschlie\u00dflich ein verschl\u00fcsselter Zugriff via HTTPS realisiert werden, um Daten vor unerlaubtem Zugriff zu sch\u00fctzen.<\/strong><\/em><\/p>\n<\/blockquote>\n\n\n\n

\n

Zum anderen soll die Registrierung neuer Accounts so gestaltet werden, dass zwar eine Registrierung m\u00f6glich ist, der tats\u00e4chliche Zugriff jedoch erst nach einer manuellen Best\u00e4tigung durch einen Administrator freigegeben wird.<\/strong><\/em><\/p>\n<\/blockquote>\n\n\n\n

Diese Ma\u00dfnahme verhindert, dass sich unkontrolliert zahlreiche Nutzer registrieren, und st\u00e4rkt somit die Systemsicherheit.<\/p>\n\n\n\n

4. Skalierbarkeit<\/h3>\n\n\n\n

Die Skalierbarkeit der Anwendung ist ein weiterer zentraler Aspekt.<\/p>\n\n\n\n

\n

Sie muss gew\u00e4hrleisten, dass auch bei steigender Nutzerzahl keine Einbu\u00dfe in der Performance auftreten.<\/strong><\/em><\/p>\n<\/blockquote>\n\n\n\n

Das bedeutet, dass in der Regel mehrere Frontend-Server horizontal hinzuf\u00fcgbar sein m\u00fcssen, w\u00e4hrend der Speicher zentralisiert wird. Dieses Konzept erm\u00f6glicht es, bei steigendem Traffic weitere Instanzen hinzuzuf\u00fcgen, um die Leistungsf\u00e4higkeit aufrecht zu erhalten.<\/p>\n\n\n\n

\n\n\n\n

Architektur<\/h1>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n

Network & DNS<\/h3>\n\n\n\n