InhaltsverzeichnisKlicke auf den Link, um zur gewünschten Stelle zu navigieren
Warum es sich überhaupt lohnt, von S3 umzuziehenWas ist ein S3-kompatibler SpeicherArchitektur: Warum Schreiben und Lesen unterschiedlich sein solltenSchreibenLesenRead-only Proxy: Ein kleines Detail, das den gesamten Speicher schütztFehler Nr. 1. Offene VerzeichnisauflistungFehler Nr. 2. Cache-Control und der Parameter alwaysÖffentliche Domain ohne offene PortsDatenübertragung: Wo die echten Abenteuer beginnenModerne SDKs sind manchmal „intelligenter“ als nötigContent-Type - ein Detail, das Bilder kaputt machtVorab komprimierte Dateien - eine eigene GeschichteDie einfachste LösungNicht alle Fehler sind beim Kopieren sichtbarDie Überprüfung der Dateizahl ist keine FormalitätManchmal lügt sogar das ÜberprüfungstoolDer gefährlichste Moment - der WechselWarum schrittweises Umschalten gefährlich istDie richtige Reihenfolge des Übergangs1. Bereiten Sie die neue Infrastruktur vollständig vor2. Übertragen Sie alle Daten3. Ein Deployment - eine ÄnderungCheckliste vor der Abschaltung des alten S3Beeilen Sie sich nicht, den alten Bucket zu löschenIst ein Umzug überhaupt sinnvoll?
Dieser Inhalt wurde automatisch aus dem Ukrainischen übersetzt.
Früher oder später steht fast jedes Projekt, das Benutzerdaten wie Avatare und andere Medien speichert, vor der gleichen Frage: Muss man wirklich weiterhin dem Cloud-Anbieter für jedes Byte an Traffic und jede HTTP-Anfrage bezahlen?
Besonders relevant ist dies für kleine Dienste. Die Anwendung läuft bereits auf einem eigenen VPS, der über ausreichend Speicherplatz, Rechenzeit und Bandbreite verfügt. Gleichzeitig berechnet ein separater Dienst für Dateien weiterhin jede GET-Anfrage, jedes Gigabyte an ausgehendem Traffic und zusätzlich - das CDN davor.
In diesem Artikel werde ich auf konzeptioneller Ebene erläutern, wie man einen Dateispeicher von Amazon S3 auf einen eigenen Server migriert, ohne die Anwendung neu zu schreiben oder die Geschäftslogik zu ändern. Wir werden die Architektur, das Sicherheitsmodell, reale Probleme während der Migration und eine Checkliste betrachten, die man durchgehen sollte, bevor man den alten Bucket endgültig abschaltet.
Warum auf konzeptioneller Ebene? Es gibt viele Werkzeuge, und die Ansätze sind universell. Ich habe kürzlich Dateien von Amazon S3 auf SeaweedFS (Container auf demselben Server wie die Anwendung) migriert. Daher schreibe ich, solange die Erfahrung frisch ist.
Warum es sich überhaupt lohnt, von S3 umzuziehen
Amazon S3 ist ein ausgezeichneter Dienst. Seine Hauptvorteile sind gut bekannt: hohe Verfügbarkeit, praktisch unbegrenzte Skalierbarkeit und minimaler Verwaltungsaufwand.
Aber für diese Vorteile muss man bezahlen, und zwar nicht nur für den Speicherplatz der Dateien.
Das Zahlungsmodell basiert auf der Nutzung des Dienstes:
- jede GET- und PUT-Anfrage;
- jedes Gigabyte an ausgehendem Traffic;
- zusätzliche Dienste wie CDN.
Für die meisten kleinen Websites ist das unauffällig. Das Problem tritt auf, wenn die Last unkontrollierbar wird.
Zum Beispiel:
- Scraper oder Hotlinker können innerhalb weniger Stunden Hunderttausende von Anfragen erzeugen;
- CDN reduziert nur die Last auf S3, wird aber selbst auch für Anfragen und Traffic berechnet;
- Budgetwarnungen von AWS informieren über Kostenüberschreitungen, können diese aber nicht automatisch stoppen.
- Fehler im Code. Ein Retry-Sturm im Hintergrundprozess der Bildverarbeitung kann zu ständigen Anfragen an S3 führen. Und das ist aus realer Erfahrung.
Infolgedessen kann selbst ein kleines Ereignis am Ende des Monats zu einer unangenehmen Rechnung führen.
Wenn Ihre Anwendung bereits auf einem VPS mit fester monatlicher Gebühr läuft, stellt sich die logische Frage: Warum zusätzlich für den Dateispeicher bezahlen, wenn der Server über ausreichend Speicherplatz und Netzwerkressourcen verfügt?
Hier kommt die Idee eines eigenen S3-kompatiblen Speichers ins Spiel.
Was ist ein S3-kompatibler Speicher
Die Existenz von S3-kompatiblen Speichern macht eine solche Migration relativ einfach.
Heute gibt es viele Open-Source-Implementierungen von Objektspeichern, die dieselbe API wie Amazon S3 unterstützen:
- PUT Object
- GET Object
- ListObjects
- AWS Signature Version 4
- Standard-SDKs von Amazon
Für die Anwendung bedeutet das, dass sie weiterhin über denselben Client (aws-sdk, fog-aws oder eine andere Bibliothek) arbeitet, und es ändern sich nur:
- Endpoint;
- Zugriffsschlüssel;
- geheimer Schlüssel;
- Parameter force_path_style (path_style).
Der Code zur Arbeit mit Dateien bleibt dabei praktisch unverändert.
Es gibt mehrere qualitativ hochwertige self-hosted Implementierungen auf dem Markt. Sie unterscheiden sich in der Leistung, den Ressourcenanforderungen und der Reife der S3 API-Implementierung, aber das Prinzip der Funktionsweise ist gleich.
Deshalb wird der Umzug nicht zu einer Neuschreibung der Hälfte der Anwendung - es reicht aus, die Speicheradresse zu ändern.
Architektur: Warum Schreiben und Lesen unterschiedlich sein sollten
Der häufigste Fehler beim Übergang besteht darin, einfach die S3 API nach außen zu öffnen und sie gleichzeitig für das Schreiben und Lesen zu verwenden.
So wird es funktionieren.
Aber das ist eine schlechte Idee.
Das Schreiben von Dateien und deren Lesen hat völlig unterschiedliche Sicherheitsanforderungen.
Schreiben
Die Dateien werden von der Anwendung selbst hochgeladen.
Sie arbeitet innerhalb eines privaten Netzwerks, hat Zugriffsschlüssel und muss die vollständige S3 API sehen.
Keiner dieser Ports sollte aus dem Internet zugänglich sein.
Lesen
Benutzer müssen nur bereits vorhandene Dateien herunterladen.
Dafür reicht es aus, nur zwei HTTP-Methoden zuzulassen:
- GET
- HEAD
Alles andere sollte blockiert werden, bevor die Anfrage den Speicher erreicht.
Infolgedessen sieht die Architektur ungefähr so aus:
┌────────────────────────────────┐
│ Ihr Server │
│ │
Anwendung ──────▶│ S3-kompatibler Speicher │
(privates Netzwerk) │ │
│ │ │
│ ▼ │
│ nginx (read-only proxy) │
└─────────────┬──────────────────┘
│
assets.example.com
GET / HEAD
Dieser Ansatz hat mehrere Vorteile:
- Die Schreib-API ist überhaupt nicht aus dem Internet zugänglich.
- Besucher können nur Dateien anzeigen.
- Zu jedem Zeitpunkt kann ein CDN hinzugefügt werden, ohne die Anwendung zu ändern.
- Nginx kann selbst Cache-Header hinzufügen und unerwünschte Anfragen einschränken.
Mit anderen Worten, die Anwendung und die Benutzer arbeiten nicht mehr mit demselben Interface - jeder erhält nur die Funktionen, die er wirklich benötigt.
Read-only Proxy: Ein kleines Detail, das den gesamten Speicher schützt
Normalerweise wird die Rolle eines solchen Proxys von einem gewöhnlichen nginx übernommen. Er speichert keine Dateien und weiß nichts über die S3 API - seine einzige Aufgabe besteht darin, bereits vorhandene Objekte sicher bereitzustellen.
Eine typische Konfiguration sieht ungefähr so aus:
server {
listen 80;
server_name _;
# Verhindern Sie die Anzeige der Dateiliste.
location ~ /$ {
return 403;
}
location / {
limit_except GET HEAD {
deny all;
}
proxy_pass http://storage:8080/bucket-name/;
proxy_set_header Host $host;
add_header Cache-Control "public, max-age=31536000, immutable";
}
}
Die Konfiguration ist klein, aber genau hier verstecken sich oft Fehler.
Fehler Nr. 1. Offene Verzeichnisauflistung
Wenn man dies übersieht, kann eine gewöhnliche Anfrage an:
GET /
eine Liste aller Objekte im Bucket zurückgeben.
Das bedeutet nicht, dass ein Angreifer etwas löschen oder hochladen kann. Aber er erhält:
- Dateinamen;
- Größen;
- Erstellungsdaten;
- Verzeichnisstrukturen.
Faktisch geben Sie die Möglichkeit, Ihr Dateispeicher vollständig zu indizieren.
Deshalb ist die einfachste Lösung, Anfragen an Verzeichnisse vollständig zu verbieten. Der Benutzer sollte den vollständigen Pfad zu einer bestimmten Datei kennen. Wenn der Pfad nicht vorhanden ist - soll er 403 Forbidden erhalten.
Fehler Nr. 2. Cache-Control und der Parameter always
Eine weitere tückische Problematik ist ein anderes Problem.
Viele Beispiele für nginx-Konfigurationen empfehlen die Verwendung von:
add_header Cache-Control "public, max-age=31536000, immutable" always;
Auf den ersten Blick scheint das sogar logisch: Lassen Sie alle Antworten gleichmäßig zwischenspeichern.
Aber wenn ein CDN (zum Beispiel Cloudflare) vor dem Server arbeitet, kann die Situation sehr unangenehm werden.
Stellen Sie sich ein typisches Bereitstellungsszenario vor.
Der neue HTML-Code ist bereits veröffentlicht, aber die JavaScript-Datei hat es noch nicht in den neuen Speicher geschafft.
Der erste Benutzer öffnet die Seite.
Der Origin gibt zurück:
404 Not Found
Zusammen mit ihm fügt nginx hinzu:
Cache-Control: public, max-age=31536000
Das CDN führt die Anweisung gewissenhaft aus und speichert die Antwort für ein Jahr im Cache.
Nach ein paar Sekunden erscheint die Datei im Speicher.
Aber die Benutzer erhalten weiterhin 404 aus dem Cache.
Von der Anwendung aus funktioniert alles richtig.
Die Datei existiert.
Der Origin gibt sie zurück.
Und das CDN überprüft das nicht erneut.
Deshalb sollte Cache-Control nur zu erfolgreichen Antworten und nicht zu Fehlern hinzugefügt werden.
Öffentliche Domain ohne offene Ports
Eine weitere interessante Möglichkeit der modernen Infrastruktur besteht darin, den Server überhaupt nicht nach außen zu öffnen.
Wenn ein CDN oder ein Reverse Proxy vor der Website arbeitet, unterstützt es höchstwahrscheinlich ausgehende Tunnel.
Das Prinzip ist sehr einfach.
Anstatt auf eingehende TCP-Verbindungen zu warten, stellt der Server selbst eine dauerhafte ausgehende Verbindung zum Netzwerk des Anbieters her.
Der weitere Traffic wird genau darüber geleitet.
Aus der Sicht des Internets sieht es so aus, als ob Ihr Server überhaupt nicht existiert.
Portscans zeigen nichts an.
Kein offenes HTTP.
Kein HTTPS.
Keine S3 API.
Nach außen sind nur die Edge-Knoten des CDN sichtbar.
Das bietet mehrere Vorteile:
- Die IP-Adresse des Origin-Servers ist verborgen;
- Die Firewall für eingehende Verbindungen kann vollständig geschlossen werden;
- Es ist viel schwieriger, DDoS-Angriffe direkt auf den Server durchzuführen;
- Der Speicher ist selbst bei Kenntnis der IP-Adresse nicht direkt zugänglich.
Für einen Heimserver oder einen kleinen VPS ist dies wahrscheinlich der einfachste Weg, einen zusätzlichen Schutzgrad praktisch kostenlos zu erhalten.
Datenübertragung: Wo die echten Abenteuer beginnen
Auf dem Papier sieht alles sehr einfach aus.
Wir nehmen rclone.
Wir erstellen zwei Remotes:
- Amazon S3;
- neuen S3-kompatiblen Speicher.
Danach führen wir aus:
rclone sync s3:bucket storage:bucket
Und warten.
In der Praxis beginnen hier die meisten Überraschungen.
Und sie hängen fast nie mit rclone selbst zusammen.
In der Regel treten Probleme aufgrund kleiner Unterschiede zwischen den Implementierungen der S3 API auf.
Moderne SDKs sind manchmal „intelligenter“ als nötig
In den letzten Jahren haben die Client-Bibliotheken von Amazon gelernt, neue Mechanismen zur Signierung von Anfragen zu verwenden.
Zum Beispiel:
- Streaming-Signaturen;
- Trailer-Prüfziffern;
- zusätzliche Integritätsprüfungen.
Amazon S3 unterstützt all dies hervorragend.
Aber nicht jeder self-hosted Speicher tut das.
Infolgedessen kann eine sehr seltsame Situation entstehen.
Die Zugriffsschlüssel sind korrekt.
Die Zeit ist synchronisiert.
Die Berechtigungen sind ebenfalls korrekt.
Und der Server antwortet:
SignatureDoesNotMatch
Deshalb ist es leicht, das Problem in IAM, Schlüsseln oder Zeitzonen zu suchen, obwohl der wahre Grund ganz anders ist.
Wenn Sie mit einem ähnlichen Verhalten konfrontiert sind, versuchen Sie, die neuen Signaturmodi zu deaktivieren oder das native Importwerkzeug des Speichers zu verwenden.
Manchmal spart das Stunden der Suche nach einem nicht existierenden Fehler.
Content-Type - ein Detail, das Bilder kaputt macht
Ein weiteres unerwartetes Problem sind die MIME-Typen.
Viele Werkzeuge versuchen beim Kopieren, den Dateityp selbst zu bestimmen.
Meistens analysieren sie die ersten Bytes der Datei.
Für PNG oder JPEG funktioniert das hervorragend.
Aber moderne Formate wie AVIF oder HEIC werden nicht immer erkannt.
Infolgedessen gelangt die Datei mit folgendem Header in den neuen Speicher:
Content-Type: application/octet-stream
Der Browser weiß nicht mehr, dass es sich um ein Bild handelt.
In einem Fall schlägt er vor, die Datei herunterzuladen.
Im anderen Fall weigert er sich einfach, sie anzuzeigen.
Die beste Lösung ist, den MIME-Typ gar nicht neu zu bestimmen, sondern ihn zusammen mit den Metadaten des ursprünglichen Objekts zu übertragen.
Diese sind die Quelle der Wahrheit.
Vorab komprimierte Dateien - eine eigene Geschichte
Wenn im Speicher JavaScript, CSS oder andere Textdateien vorhanden sind, die beim Hochladen bereits komprimiert wurden (gzip oder brotli), sollte man separat überprüfen, ob der neue Speicher korrekt mit den entsprechenden HTTP-Headern arbeitet.
Es geht in erster Linie um:
- Content-Encoding
- Content-Type
Amazon S3 speichert diese Metadaten ohne Überraschungen. Aber einige self-hosted Implementierungen verhalten sich weniger vorhersehbar - insbesondere wenn die Dateien mit externen Werkzeugen hochgeladen wurden.
Infolgedessen kann der Browser unentpacktes JavaScript erhalten, das buchstäblich einen Strom komprimierter Bytes darstellt.
Der Fehler sieht ziemlich seltsam aus.
Anstelle des erwarteten JavaScripts zeigt die Konsole des Browsers etwas wie:
Failed to load module script: Expected a JavaScript module but the server responded with application/octet-stream
oder
Unexpected token
Auf den ersten Blick scheint es, als läge das Problem im Frontend-Build.
Tatsächlich existiert die Datei, aber der Server gibt sie mit falschen Metadaten zurück.
Die einfachste Lösung
Wenn vor Ihrem Server bereits ein CDN (Cloudflare oder ähnliches) arbeitet, ist die Vorabkomprimierung von Dateien oft überhaupt nicht notwendig.
Moderne CDNs komprimieren selbst Textinhalte während der Bereitstellung:
- gzip;
- brotli;
- zstd (je nach Client).
Deshalb vereinfacht der Verzicht auf vorab komprimierte Dateien oft die Infrastruktur und beseitigt eine ganze Klasse potenzieller Probleme.
Nicht alle Fehler sind beim Kopieren sichtbar
Wenn der Bucket mehrere tausend Dateien enthält, verläuft die Migration normalerweise ohne Probleme.
Aber wenn es Dutzende oder Hunderttausende sind, besteht die Versuchung, die Parallelität maximal zu erhöhen.
Das ist richtig.
Andernfalls kann das Kopieren viele Stunden dauern.
Es gibt jedoch ein anderes Problem.
Bei einer großen Anzahl gleichzeitiger Anfragen wird ein Teil davon fast unvermeidlich mit einem Fehler enden.
Die Gründe können unterschiedlich sein:
- kurzfristige Netzwerkstörungen;
- Überlastung des Speichersystems;
- vorübergehende Unzugänglichkeit des Dienstes;
- interne Timeouts.
In den meisten Fällen werden dies Zehntel oder sogar Hundertstel Prozent sein.
Das klingt nicht beängstigend.
Aber wenn Sie eine Million Dateien übertragen, sind selbst 0,05 % bereits Hunderte fehlender Objekte.
Das Gefährlichste ist, dass einige Werkzeuge solche Situationen möglicherweise nicht als kritisch betrachten und die Arbeit ohne offensichtlichen Fehler beenden.
Deshalb muss nach Abschluss der Migration unbedingt das Ergebnis überprüft werden.
Verlassen Sie sich nicht einfach auf die Meldung:
Transfer completed successfully
sondern stellen Sie sicher, dass alle Dateien tatsächlich angekommen sind.
Die Überprüfung der Dateizahl ist keine Formalität
Nach Abschluss des Kopiervorgangs sollte man eine sehr einfache Frage beantworten:
Ist die Anzahl der Objekte im alten und neuen Speicher gleich?
Wenn die Antwort „ja“ lautet - großartig.
Wenn nicht - beeilen Sie sich nicht, die Migration erneut zu starten.
Es ist viel effektiver, die tatsächlich fehlenden Objekte zu finden und einen weiteren Durchgang durchzuführen.
Das erneute Kopieren des gesamten Buckets nur wegen ein paar Dutzend oder Hundert Dateien verschwendet in der Regel nur Zeit.
Deshalb ist das finale „Nachladen“ eine absolut normale Praxis, selbst für große Unternehmen.
Manchmal lügt sogar das Überprüfungstool
Es gibt noch eine weitere Überraschung, die leicht vergessen werden kann.
Bei sehr großen Buckets können die Zählwerkzeuge selbst fehlerhaft arbeiten.
Zum Beispiel können sie:
- ein internes Limit für die Anzahl der Einträge haben;
- das Ergebnis nach einer bestimmten Marke abschneiden;
- die Liste der Objekte cachen.
In einer solchen Situation scheint es, dass die Anzahl der Dateien nach der letzten Synchronisierung nicht gestiegen ist.
Obwohl die neuen Objekte bereits lange im Speicher vorhanden sind.
Wenn Sie seltsame Statistiken sehen, sollten Sie nicht sofort in Panik geraten.
Es ist besser, einige spezifische Dateien direkt zu überprüfen.
Zum Beispiel:
- ob die URL geöffnet werden kann;
- ob der richtige Content-Type zurückgegeben wird;
- ob die Prüfziffer übereinstimmt.
Sehr oft stellt sich heraus, dass das Problem nicht in der Migration, sondern im Werkzeug liegt, das die Statistiken anzeigt.
Der gefährlichste Moment - der Wechsel
Nach erfolgreichem Kopieren scheint es, als wäre der schwierigste Teil bereits vorbei.
Das ist in der Tat nicht der Fall.
Das größte Risiko besteht genau in dem Moment, in dem die Anwendung auf den neuen Speicher umschaltet.
Sehr oft besteht die Versuchung, dies schrittweise zu tun.
Zum Beispiel:
- zuerst das Lesen umschalten;
- überprüfen, ob alles funktioniert;
- erst dann das Schreiben umschalten.
Das klingt logisch.
Aber das ist einer der häufigsten Fehler.
Warum schrittweises Umschalten gefährlich ist
In den meisten Anwendungen wird die URL der Datei aus zwei Teilen generiert:
- dem Schlüssel des Objekts;
- der Basisdomain des Speichers.
Wenn Lesen und Schreiben beginnen, unterschiedliche Speicher zu verwenden, entsteht ein sehr unangenehmes Fenster der Inkonsistenz.
Stellen Sie sich die Situation vor.
Ein Benutzer lädt ein neues Avatarbild hoch.
Die Anwendung schreibt es bereits in den neuen Speicher.
Aber die Profilseite generiert immer noch die URL des alten S3.
Die Datei existiert physisch.
Der Benutzer sieht jedoch nur:
404 Not Found
Nach ein paar Minuten öffnet ein anderer Benutzer dieselbe Seite.
Bei ihm funktioniert bereits alles.
Infolgedessen erscheint das Problem zufällig, es ist schwer zu reproduzieren und noch schwieriger zu erklären.
Die richtige Reihenfolge des Übergangs
Es ist viel sicherer, die Migration in drei Phasen durchzuführen.
1. Bereiten Sie die neue Infrastruktur vollständig vor
Wir setzen auf:
- Speicher;
- nginx;
- CDN;
- öffentliche Domain;
- Überwachung.
Die Anwendung arbeitet weiterhin mit dem alten S3.
2. Übertragen Sie alle Daten
Wir führen eine vollständige Synchronisierung durch.
Direkt vor der Bereitstellung führen wir eine weitere kurze Synchronisierung durch, um die Dateien zu übertragen, die Benutzer während des ersten Kopiervorgangs hochgeladen haben.
Diese „Delta“ macht den Wechsel praktisch schmerzlos.
3. Ein Deployment - eine Änderung
Erst danach ändert die Anwendung gleichzeitig:
- den Endpoint für das Schreiben;
- den Endpoint für das Lesen.
Nicht zwei separate Änderungen.
Nicht zwei verschiedene Releases.
Ein atomarer Deployment.
So bleibt praktisch kein Moment, in dem neue Dateien an einem Ort geschrieben und an einem anderen Ort gelesen werden können.
Checkliste vor der Abschaltung des alten S3
Bevor Sie endgültig auf Amazon S3 verzichten, sollten Sie eine kleine Checkliste durchgehen. Die meisten Punkte erscheinen offensichtlich, aber genau sie sind oft die Ursache für Probleme nach dem Umschalten.
- Die öffentliche Domain gibt keine Dateiliste zurück. Eine Anfrage an / oder an ein Verzeichnis gibt 403 Forbidden zurück, anstatt eine Liste von Objekten.
- Über die öffentliche Domain kann nichts geschrieben werden. PUT-, POST-, DELETE-Anfragen und andere Methoden außer GET und HEAD werden bereits auf der Ebene von nginx blockiert.
- S3 API ist nicht öffentlich. Wenn darauf dennoch zugegriffen werden kann, erfordert jede Anfrage unbedingt eine korrekte Authentifizierung gemäß AWS Signature V4.
- CDN cached tatsächlich Dateien. Überprüfen Sie die Antwort-Header (CF-Cache-Status, Age oder ähnliche) und stellen Sie sicher, dass wiederholte Anfragen nicht zum Origin gelangen.
- Content-Type aller Dateien stimmt mit dem Original überein. Dies gilt insbesondere für AVIF, WebP, SVG, Schriftarten und andere Formate, bei denen ein falscher MIME-Typ Probleme im Browser verursachen kann.
- Die Kompressionsheader sind nicht verloren gegangen. Wenn vorab komprimierte Dateien verwendet werden, überprüfen Sie Content-Encoding.
- Alle Objekte wurden übertragen. Die Anzahl der Dateien im alten und neuen Speicher stimmt überein, und eine zufällige Stichprobe bestätigt, dass die Dateien geöffnet werden und die richtigen Metadaten zurückgeben.
- Die finale Synchronisierung wurde durchgeführt. Vor der eigentlichen Bereitstellung wurden alle Dateien übertragen, die Benutzer während der Hauptmigration hochgeladen haben.
Wenn alle Punkte erfüllt sind, ist es Zeit, die Anwendung umzuschalten.
Beeilen Sie sich nicht, den alten Bucket zu löschen
Nach einer erfolgreichen Bereitstellung besteht der natürliche Wunsch, den alten Bucket sofort zu löschen und nicht mehr dafür zu bezahlen.
Ich würde das nicht tun. Mindestens einen Monat oder zwei.
Amazon S3 ist nicht nur ein Ort, an dem Dateien liegen. Es ist ein Dienst mit hoher Ausfallsicherheit, Replikation und einer Infrastruktur, die schwer auf einem einzigen VPS nachzubauen ist.
Im Gegensatz dazu hat der eigene Speicher, insbesondere wenn er auf einem einzigen Server läuft, einen einzigen Ausfallpunkt.
Selbst wenn Sie regelmäßig Backups erstellen, sollten Sie die ersten Wochen nach der Migration den alten Bucket als zusätzliche Versicherung behalten.
Das bietet mehrere Vorteile:
- Sie können schnell jede Datei finden, wenn der Verdacht auf einen Fehler während der Migration besteht;
- Sie können Metadaten oder Prüfziffern leicht vergleichen;
- Im schlimmsten Fall können Sie immer schnell zur vorherigen Konfiguration zurückkehren.
Nachdem der neue Speicher eine gewisse Zeit ohne Probleme funktioniert hat und das Backup praktisch überprüft wurde, kann der alte Bucket sicher gelöscht werden.
Ist ein Umzug überhaupt sinnvoll?
Wie bei fast jeder architektonischen Entscheidung ist dies keine universelle Empfehlung.
Wenn Ihr Dienst Millionen von Benutzern bedient, Dutzende von AWS-Regionen nutzt oder garantierte Verfügbarkeit erfordert, wird ein eigener Speicher wahrscheinlich keine bessere Alternative sein.
Für kleine und mittlere Projekte sieht die Situation jedoch ganz anders aus.
Wenn die Anwendung bereits auf einem eigenen Server läuft und der Dateispeicher keine globale Replikation benötigt, kann der Umstieg auf eine self-hosted Lösung durchaus spürbare Vorteile bringen:
- feste Kosten anstelle von Abrechnung pro Anfrage;
- keine Rechnungen für ausgehenden Traffic;
- vollständige Kontrolle über die Infrastruktur;
- Unabhängigkeit von einem bestimmten Cloud-Anbieter.
Das Angenehmste ist, dass eine solche Migration dank der S3-kompatiblen API keine Neuschreibung der Anwendung erfordert. In den meisten Fällen reicht es aus, den Endpoint und die Anmeldedaten zu ändern.
Auf den ersten Blick scheint es, als wäre die Übertragung des Dateispeichers einfach das Kopieren von Daten von einem Bucket in einen anderen.
In Wirklichkeit liegt die Hauptschwierigkeit jedoch nicht im Kopieren von Dateien.
Das Wichtigste ist, die Architektur richtig zu gestalten.
Das Schreiben vom Lesen zu trennen.
Die S3 API nicht nach außen zu öffnen.
Keine Verzeichnisauflistungen zuzulassen.
Das Caching korrekt einzustellen.
Die Metadaten der Dateien nach der Migration zu überprüfen.
Und erst danach einen atomaren Wechsel der Anwendung durchzuführen.
Wenn alles in dieser Reihenfolge gemacht wird, dauert der Übergang deutlich weniger Zeit, als es zu Beginn scheint. Stattdessen erhalten Sie die volle Kontrolle über den Dateispeicher, vorhersehbare Kosten und eine Infrastruktur, die Sie unabhängig von den Tarifen eines bestimmten Cloud-Anbieters weiterentwickeln können.
Das Wichtigste ist, die Migration nicht als einfaches Kopieren von Dateien zu betrachten. Es ist in erster Linie eine Änderung der Architektur. Und ob die Benutzer den Umzug überhaupt bemerken, hängt davon ab, wie sorgfältig diese Architektur durchdacht wird.
