Ich baue derzeit eine einfache Webapp-Architektur auf AWS, wie folgt: Elastic Load Balancer – mehrere Frontends – RDS-Datenbank.
Ich habe außerdem einen NFS-Server eingerichtet, um alle von Benutzern über die Webanwendung hochgeladenen Bilder zu speichern, hauptsächlich Profilbilder (ich kann hierfür nicht S3 verwenden, ich halte mich nur an die Spezifikationen, die ich bekomme ...).
Die Frontend-VMs werden von einer Autoscaling-Gruppe gestartet. Wenn eine VM gestartet wird, lädt sie die Web-App-Quellen aus einem S3-Bucket herunter. Das Problem ist, dass ich in diesen Quellen einige große Dateien habe (hauptsächlich statische Dateien wie MP4 oder Bilder). Ich denke darüber nach, diese großen statischen Dateien auch auf dem NFS-Server zu speichern, da das Herunterladen von S3 zu lange dauert.
Meine Frage ist also: Wann ist es sinnvoll, eine Datei auf dem NFS zu speichern, und wann ist es besser, sie auf jedem Front-End zu lassen? Wenn ich z. B. eine MP4-Datei auf dem NFS speichere, warum speichere ich dann nicht die gesamte Webanwendung auf diesem NFS?
Hinweis: Ich möchte kein AMI mit diesen Dateien erstellen, da es bei der Änderung dieser Dateien nicht flexibel genug ist
Antwort1
Das hängt alles von der Leistung ab. Wenn Ihr NFS-Speicher schnell genug ist, hindert Sie nichts daran, alle Ihre Web-App- und Web-Inhaltsdateien darauf abzulegen, damit sie für alle Ihre Front-End-VMs zugänglich sind.
Der häufigste Grund dafür, dass dies nicht getan wird, liegt darin, dass die zusätzliche Netzwerklatenz beim Abrufen von Dateien aus einem Netzwerkspeicher zu einer zusätzlichen Verzögerung führt, wenn Clients Ihre Webanwendung/Site in ihrem Browser laden.
Dies hängt natürlich vom zugrunde liegenden Speicher der VM ab, aber normalerweise hat lokaler Speicher fast immer eine geringere Latenz und wird daher zum Speichern statischer Inhalte bevorzugt. Viele Lastausgleichsbereitstellungen, an denen ich beteiligt war, verwenden DRDB, um die statischen Inhalte synchron und für alle Webserver verfügbar zu halten.