Bild von dennizn auf Shutterstock
Einer unserer Kunden stieß kürzlich auf ein Problem mit seinem S3-Bucket, als er Objekte vom Standard-Speicher nach Glacier Deep Archive verschieben wollte. Obwohl die Objekte nach Glacier Deep Archive verschoben wurden, tauchten sie weiterhin im Standard-Speicher auf.
Bei der Analyse des S3-Buckets zeigte sich, dass der Standard-Speicher tatsächlich nicht unter die ursprünglichen 4,9 TB gefallen war. Das veranschaulicht die folgende Abbildung aus der Speichermetrik des Kunden-Buckets.
S3-Metrik Total Bucket Size
An der S3-Metrik Total Bucket Size ist zu erkennen, dass der Standard-Speicher 4,9 TB belegt. Die orangefarbene Linie steht dabei für den Standard-Speicher. Der Kunde hatte den Transfer der Objekte nach Glacier Deep Archive am 6. Mai angestoßen, doch bis zum 10. Mai bildete die Metrik diese Änderung noch immer nicht ab.
S3-Metrik für Standard-Speicher
Als ich die Metrik Total Bucket Size in CloudWatch öffnete, fiel mir eine Abweichung zwischen S3- und CloudWatch-Metriken auf. Die S3-Metrik wies 4,9 TB Standard-Speicher für den Bucket aus, die CloudWatch-Metrik dagegen 5,3 TB.
CloudWatch-Metriken für die Buckets nach Speicherklasse
Aufschlüsselung der Metriken pro Speicherklasse
Bei der Analyse stieß ich auf zwei Probleme beim Wechsel der Objekte zwischen den Speicherklassen:
(1) Die Metrik für den S3-Standard-Speicher war nicht gesunken, nachdem Objekte in eine andere Speicherklasse verschoben wurden.
(2) S3-Metrik und CloudWatch-Metrik wiesen eine deutliche Abweichung beim gesamten Standard-Speicher aus.
Die Probleme lösen
Bei der genaueren Analyse, wie unser Kunde die Objekte vom Standard-Speicher nach Glacier Deep Archive verschoben hatte, zeigte sich, dass dies manuell über die S3-Konsole erfolgte. Nach dem Öffnen des Objekts in der Konsole wurden Action, Edit actions, Edit storage class ausgewählt.
Manuelles Ändern der Speicherklasse eines Objekts
Wird die Speicherklasse eines Objekts über die Konsole geändert, legt S3 schlicht eine Kopie des Objekts an und behält das ursprüngliche als ältere Version bei (sofern die Versionierung für den Bucket aktiviert ist).
Beim Bearbeiten der Speicherklasse über die Konsole wird also nicht die Klasse selbst geändert, sondern eine neue Datei in der gewählten Speicherklasse erzeugt.
Da die Versionierung für den Bucket aktiviert ist, existieren nun zwei Versionen der Datei: eine in Glacier Deep Archive (die aktuelle Version) und eine im Standard-Speicher (die veraltete Version). Aus diesem Grund verringerte sich der Standard-Speicher nicht.
Lifecycle-Regel
Bei der Analyse der Abweichung zwischen S3- und CloudWatch-Metrik für die Standard-Klasse stellte ich fest, dass die S3-Metriken auf der Bucket-Seite nur die zusammengefasste Größe der aktuellen Dateien im S3-Bucket ausweisen, während CloudWatch zusätzlich auch veraltete Versionen sowie fehlgeschlagene Multipart-Uploads erfasst.
Da der Kunde die Speicherklasse der Objekte manuell geändert hatte, landete eine neue Kopie als aktuelle Version in Glacier Deep Archive, während das Objekt im Standard-Speicher zur veralteten Version wurde.
Da unser Kunde die veraltete Version im Standard-Speicher nicht mehr brauchte, empfahl ich, eine Lifecycle-Regel zu erstellen, um den Bucket aufzuräumen und die veralteten Versionen aus dem Standard-Speicher zu entfernen.
Unser Kunde setzte die folgende Lifecycle-Regel um. Sie besagt: Zwei Tage nachdem ein Objekt veraltet (also durch eine neuere Version ersetzt wird), werden alle veralteten Versionen dieses Objekts dauerhaft gelöscht.
Lifecycle-Regel zum Löschen veralteter Versionen
**Das Ergebnis**
Nach dem Aktivieren der Lifecycle-Regel am 14. Mai war zu beobachten, wie S3 die veralteten Versionen automatisch entfernte.
Standard-Speicher nach Aktivierung der Lifecycle-Regel reduziert
Die Lifecycle-Regel verringerte das Volumen im S3-Bucket deutlich – von 4,9 TB auf 1,3 TB. Das senkte die S3-Bucket-Kosten des Kunden und verbesserte zugleich die Performance des Buckets.
Diese unkomplizierte Maßnahme senkte nicht nur die Speichergebühren, sondern optimierte auch die Performance des Buckets. Das folgende Diagramm zeigt, wie die S3-Kosten des Kunden nach dem manuellen Verschieben der Objekte nach Glacier Deep Archive am 6. Mai anstiegen und nach Aktivierung der Lifecycle-Regel am 14. Mai wieder fielen. Die Auswertung stammt aus DoiT Cloud Navigator – Cloud Analytics.
Fazit
Der Fall zeigt, wie wichtig S3-Lifecycle-Regeln für eine effektive Verwaltung von S3-Buckets und für Speicherklassen-Wechsel sind. Die manuelle Änderung des Kunden führte zu unnötigen Duplikaten in Glacier Deep Archive und im Standard-Speicher – mit Lifecycle-Regeln wäre das vermeidbar gewesen.
Außerdem sind S3- und CloudWatch-Metriken zentral, um den Inhalt Ihrer S3-Buckets zu verstehen – sie unterstützen sowohl das Kostenmanagement als auch die Performance-Optimierung.
Kontakt aufnehmen
Wenn Sie Fragen zur S3-Optimierung haben oder Unterstützung beim Review Ihrer AWS-Architektur benötigen, melden Sie sich gerne bei DoiT International. Unser Expertenteam ist jederzeit für Sie da.