S3-PUT-Request-Inkonsistenzen bei Transloadit beheben
Amazon S3 ist großartig. Außer wenn es das nicht ist. Wenn Sie es intensiv nutzen (wir haben bislang rund eine Million Kundenobjekte gespeichert), fallen Ihnen einige seltsame Dinge auf, die eher nach „eventual madness“ als nach „eventual consistency“ aussehen.
Eines der Dinge, die wir sofort gelernt haben: Den Fehlercodes von S3 kann man nicht trauen.
Manchmal begegnet Ihnen 403 Permission Denied, doch wenn Sie exakt dieselbe Anfrage erneut
ausführen, funktioniert sie plötzlich wie durch ein Wunder. Aus diesem Grund sollten Sie es in der
Regel erneut versuchen, wenn Sie eine Fehlermeldung erhalten. Erst wenn ein bestimmter Fehler
mehrfach auftritt, sollten Sie aufmerksam werden. Derzeit wiederholen wir bis zu 6 Mal mit
zunehmenden Timeouts.
Das Neueste, worauf wir gestoßen sind: Auch den Bestätigungen von S3 für PUT-Requests ist nicht zu trauen. Die Symptome, die wir sahen: Einige der S3-URLs, die wir an unsere Kunden zurückgaben, funktionierten schlicht nicht. Das zu reproduzieren war eine enorme Herausforderung. Einmal konnten wir das Problem nach ~25 PUTs beobachten, ein anderes Mal passierte nach 2500 PUTs (insgesamt 10 GB) gar nichts. Es besteht also weiterhin eine winzige Chance, dass der Fehler irgendwo in unserem System steckt, doch inzwischen sind wir ziemlich überzeugt, dass es sich um ein Amazon-Problem handelt, das nur selten auftritt.
Und damit betreten wir das Land des Wahnsinns. Wie verifizieren Sie in einem System mit Eventual Consistency, in dem „eventually“ manchmal „never“ bedeuten kann, den Erfolg eines Schreibvorgangs? Natürlich können Sie nach jedem Schreibvorgang im Bucket prüfen, ob das Objekt existiert. Aber was, wenn es das nicht tut? Ab wann wird daraus ein Fehlerzustand? Und wenn das Objekt tatsächlich existiert, was bedeutet das dann? Man kann davon ausgehen, dass mindestens ein Client das Objekt sehen kann, nicht aber, dass die Replikation abgeschlossen und es damit für alle Clients verfügbar ist.
Eine perfekte Antwort gibt es nicht, doch wir haben uns entschieden, das Vorhandensein einer gespeicherten Datei mit bis zu elf Prüfungen über einen Zeitraum von zwei Minuten zu verifizieren. Existiert die Datei bis dahin nicht, wiederholen wir den Job bis zu sechs Mal. Das ist alles andere als ideal, dürfte die Wahrscheinlichkeit, dass wir ungültige S3-URLs herausgeben, aber wohl auf ein ähnliches Niveau senken wie die Chance auf einen ansehnlichen Lotteriegewinn.
Bemerkenswert fanden wir außerdem, dass das Konsistenzmodell von S3 nicht in allen Regionen dasselbe ist. Während „US Default“ das klassische Modell der „eventual consistency“ nutzt, bieten alle anderen Regionen „read-after-write“-Konsistenz. Aus Kundensicht ist das unglaublich verwirrend, doch der Grund dafür scheint zu sein, dass sich „US Default“ von der Ost- bis zur Westküste erstreckt, sodass die Lichtgeschwindigkeit denselben Garantien im Weg steht.
Wir sammeln gerade bessere Daten zu unseren Erfahrungen mit S3 und werden sie künftig teilen. S3 funktioniert für uns die meiste Zeit definitiv hervorragend, und sollte sich herausstellen, dass wir es falsch verwendet haben, werden wir auch darüber berichten.