[Epic] Attachments - Optimierung Ablageort
Ziel
Die interne Ablage der Attachments soll auf die beste (Performance, Skalierbarkeit, Sicherheit) technische Architektur umgestellt werden.
Warum
Die Ablage der Anhänge in der Datenbank entspricht nicht dem optimalen technischen Lösungsweg. Die Ablage und Abruf der Anhänge sollten skalierbar, schneller und stabiler werden.
Links, Notes, Remarks
Stories
Konzept für Ablage der Anhänge auf dem Dateisystem #83 (closed)
-
Storage-Optionen evaluieren #1702 (closed) -
SDK / Libraries für Storage-Option auswählen #1703 (closed) -
Lokales Test-Setup mit ausgewählter Storage-Option #1704 (closed) -
Attachment-Handling anpassen #1705 -
Löschkonzept für Attachments #1707 (closed) -
Backup-Konzept für Zustelldienst mit Attachment-Storage überarbeiten #1708Update 17.4 an Team INF übergeben - gehört nicht in dieses EPIC, sondern in das Setup des S3 Backends -
Attachments aus Zustelldienst-Datenbank entfernen und Anwendungscode bereinigen #1706- als Follow-Up einzuplanen, kann erst umgesetzt werden, wenn S3 auf allen Umgebungen eingerichtet ist.
Acceptance criteria
-
Die Ablage der Anhänge auf dem Dateisystem (über S3 API) bietet eine stabile und zuverlässige Lösung, die heutigen und künftigen Anforderungen entspricht. -
Aktivierung der Umstellung muss je Umgebung konfigurierbar sein - Deployment und Aktivierung erst später um andere Deployments nicht zu blocken)
- Vielleicht macht es Sinn für die Umstellung keine Migration zu machen, sondern nur die neuen Attachments in S3 abzulegen.
-
Konfiguration des S3-Dockercontainers in Abstimmung mit Team Infrastruktur vorbereiten - kann sein, dass wir einen nicht von uns betriebenen S3 Service erst mit der Cloudmigration Ende des Jahres bekommen
Follow-Up
- Prüfen ob wir in einem EPIC den S3-Service(durch Anpassung der API) für Nutzer sichtbarer machen
- Ausbauen der DB-Funktionalitäten nach der Aktivierung auf allen Umgebungen
- Bereitstellung S3 Service für alle Umgebungen und Abstimmung mit den Betreibern (v.a. IT.N)
- im Nachgang dazu sollten wir auch (bei Bedarf) die lokalen DEV-Umgebungen mit den produktiven möglichst vereinheitlichen
- Backup-Konzept für Zustelldienst mit Attachment-Storage überarbeiten #1708
- Attachments aus Zustelldienst-Datenbank entfernen und Anwendungscode bereinigen #1706
offene Fragen
Beantwortete und eingearbeitete Fragen
-
S3 statt Filesystem des Containers zur Ablage nutzen? - externes Volume sollte hier gemountet werden
- S3 sollte genutzt werden (Standardisierte API) - das vereinfacht uns zukünftige Ausbaustuffen (daher sprechen wir zur Ablage / Abruf der Anhänge über eine interne S3 API)
- TODO: Ansatz sollten wir final mit dem Team Infrastruktur als auch ITN(bietet ITN einen S3 Service direkt an?) besprechen
- Streaming erst mit dem Konzept Einzeldateien >500MB prüfen
-
Ablage in der DB - Grund dafür ist vor allem die Konsistenz - durch unsere Einzelschritte ist das aber keine wirkliche Herausforderung
- Skalierung (schnelles Wachstum in DB eher schwierig)
- TODO: Löschszenarien in diesem Kontext zusammentragen
Neue Fragen
-
Ist Ablage im Filesystem Sicherheitskritisch - Wojtek: ja, unseren Lösungsansatz sollten wir mit Team Infrastruktur & Andreas als Architekten besprechen
-
Mandantenfähigkeit / Sicherstellung dass nicht auf falsche Anhänge zugegriffen wird - Wojtek: sollen wir wie bei der DB absichern
-
Welches Dateisystem ist gemeint? Das Dateisystem des Zustelldienst Containers oder ein dediziertes System (S3 mit z.B. MinIO)? ( @Christoph_Metzger) - Wojtek: S3 Service, welcher für die Entwicklung in einem eigenen Container von Euch gestartet wird. Nachdem wir die Lösung bewertet haben würde Team Infrastruktur dafür sorgen wie die S3 Services in alle Umgebungen kommen. Der anzusprechende Service sollte je Umgebung konfigurierbar sein.
-
Wen brauchen wir hier alles? Andreas, IT.N, Team Infrastruktur, ...? ( @Christoph_Metzger) - Wojtek: Während der Entwicklung können wir Andreas als Sparring-Partner nutzen. Manuel hat wohl auch eine Idee welcher S3 Service genutzt werden könnte.
-
"Aktivierung der Umstellung muss je Umgebung konfigurierbar sein" → die Konfigurationsoption betrifft dann nur neue Anhänge? ( @Christoph_Metzger) - Wojtek: ja genau. Ich denke langfristiger Parallelbetrieb wird eher keine Vorteile für die Skalierung bieten (können wir aber gerne besprechen)
-
Parallelbetrieb mit aktueller Lösung (Anhänge in Datenbank) und neuer Lösung (Anhänge in Dateisystem) oder sollen die Anhänge aus der DB zunächst migriert werden? ( @Christoph_Metzger) - Wojtek: Idee war keine Migration zu machen, sondern es in der DB "auslaufen" zu lassen
-
→ Dann müssen wir im Nachgang die aktuelle Lösung (Anhänge in Datenbank) explizit ausbauen. - Wojtek: ja, könnten wir als Follow-Up einplanen (denke aber das können wir erst gegen Ende des Jahres, nach der Cloud Umstellung)
-
Es soll sich nur der "Ablageort" ändern? Die API zum Up- und Download soll nicht angepasst werden und weiterhin über den zustelldienst stattfinden, korrekt? Es gelten weiterhin die bestehenden Validierungsregeln für Anhänge, korrekt? ( @Christoph_Metzger) - Wojtek: ganz genau. Wenn wir aber durch eine Änderung der API sehr Signifikaten Mehrwert erwarten würden, dann sollten wir das für den nächsten Major Release Wechsel einplanen und als neues Issue für die Zukunft festlegen.
-
Ist auch die Implementierung / Anpassung eines Backup Konzepts vorgesehen? ( @Christoph_Metzger) - Wojtek: ich denke darum muss sich im Nachgang Team Infrastruktur gemeinsam mit den Betreibern kümmern, wir würden bei Bedarf aber unterstützen.
-
S3 bringt Skalierung mit - es wird keinen Bedarf geben mehrere S3 anzubinden. -
Zurückschalten auf DB soll nicht berücksichtigt werden
Edited by Wojciech Gdaniec