Ich muss in der Lage sein, von Benutzern hochgeladene Inhalte über mehrere EC2-Anwendungsserver hinweg zu teilen. Ich habe mir rsync, gemountetes NFS und S3 als mögliche Optionen angesehen, um diese Daten nahezu in Echtzeit teilen zu können. Die hoch- und heruntergeladenen Benutzerdateien sind fast immer zwischen 1 und 10 MB groß. Auf einige wird häufig zugegriffen, andere nur einmal und dann gelöscht.
Mein neuester Ansatz besteht darin, eine EC2-Instanz ausschließlich als Dateiserver zu starten, getrennt von den Anwendungsservern. Bei dieser Option wird ein Benutzer, der eine Datei herunterladen möchte, mit einem der Anwendungsserver verbunden, der die Datenbank mit Daten über die herunterzuladende Datei abfragt. Der Benutzer wird dann zum Herunterladen aufgefordert, woraufhin er mit dem Dateiserver zum Herunterladen verbunden wird.
Ich denke, diese Option ist schneller als meine anderen Optionen. Der einzige Nachteil ist, dass ich Dateiserver nicht automatisch hoch-/herunterskalieren kann. Ich kann jedoch hochskalieren und eine Spalte in der Datenbank erstellen, die angibt, auf welchem Dateiserver sich die Datei befindet.
Ist das ein guter Ansatz oder übersehe ich etwas? Und wie kann man anhand der Serverspezifikationen und bei Dateien zwischen 1 und 10 MB am besten ermitteln, wie viele gleichzeitige Uploads/Downloads auf dem Dateiserver erfolgen können, oder lässt sich das am besten durch Belastungstests ermitteln?
Wäre es auch im Hinblick auf die Skalierung ein Problem, wenn eine bestimmte Datei, die sich auf nur einem Dateiserver befindet, extrem populär wird? Könnte die Verwendung eines CDN dieses Problem lösen?
Antwort1
Ein CDN wäre für Sie die bessere Option, S3 mit CloudFront wäre die bessere Option. Ich würde empfehlen, den benutzergenerierten Inhalt von den Anwendungsservern zu dezentralisieren und Ihre Server beim Hoch- oder Herunterskalieren innerhalb Ihrer Architektur volatil zu halten. Dies ist eine gute Designpraxis.
Antwort2
S3 und CloudFront wären die erste Option, aber wenn die Latenz für Sie nicht akzeptabel ist, gibt es auch andere Optionen.
Wenn ein einzelner Dateiserver für Sie gut funktioniert, können Sie auf eine skalierbare, verteilte Dateiserverplattform wieGlusterFS. Dadurch können Sie Dateien auf mehreren EC2-Instanzen speichern und sie als einzelnes Mount anzeigen lassen. Sie können die Option „Replik 2“ verwenden, um 2 Kopien jeder Datei zur Redundanz zu erstellen. Verwenden Sie dann zwei Instanzen in verschiedenen Verfügbarkeitszonen, um die Verfügbarkeit zu erhöhen. Die Dateien selbst werden auf jeder EC2-unterstützten Festplatte gespeichert, einschließlich EBS mit bereitgestellten IOPS oder sogar SSD-Ephemeral (ich habe das schon einmal gemacht – die Redundanz von Gluster macht die Volatilität von Ephemeral weniger besorgniserregend, sodass Sie den Vorteil der schnellen SSD-E/A für Ihre kritischen Daten nutzen können).
Antwort3
Sie möchten Ihre EC2s so strukturieren, dass sie keine einzigartigen Daten enthalten. Betrachten Sie sie einfach als Rechenmaschinen.
Sie haben einige Optionen.
S3
Skalierbarer und zuverlässiger Dienst zum Speichern und Abrufen von Dateien. Als Dateisystem funktioniert er nicht gut. Wenn Sie also viele Lese- und Schreibvorgänge durchführen, ist er keine gute Lösung.
CloudFront (CDN)
Statische Dateien (CSS, JS, Bilder) können aus CloudFront bereitgestellt werden (das seine Daten aus S3 oder EC2s beziehen kann). Dies verbessert die Leistung erheblich, sodass Sie S3 verwenden können, um Ihre Dateien abzurufen und sie aus CloudFront bereitzustellen.
GlusterFS
Sie können einen Cluster von EC2s als NAS-Speicher verwenden. Dies macht Ihr Setup natürlich etwas komplexer und ist nicht die schnellste Lösung.
Elasticache / Memecached
Sie können Ihr eigenes Memecached hosten oder den Elasticache-Dienst verwenden. Diese Lösung ist kein Dateispeicher, eignet sich aber als leistungsstarkes, verteiltes Cachesystem für Speicherobjekte.