Wer schon einmal Millionen von Dateien oder mehrere TB an Daten in oder aus S3-Buckets übertragen musste, weiß, wie viel Zeit solche AWS-Datentransfers kosten können. Was wäre, wenn sich Upload-, Download- und Kopiervorgänge um eine bis zwei Größenordnungen beschleunigen ließen – und das genauso einfach wie mit der AWS CLI?
Hier kommt: s5cmd
Eine treffende Darstellung der s3-API-Aufrufe der AWS CLI im Vergleich zu s5cmd
s5cmd ist ein Open-Source-CLI-Tool, das die Funktionen der AWS CLI für S3 nachbildet, dabei aber spürbar performanter ist – denn es ist in Go geschrieben, einer kompilierten Sprache, während die AWS CLI auf der interpretierten Sprache Python aufsetzt. Ein Go-basiertes SDK sorgt für hohen Durchsatz – nicht nur bei einzelnen Dateien, sondern auch bei sehr großen Dateimengen, weil Go von Haus aus parallele Verarbeitung unterstützt und so viele performante Dateitransfers gleichzeitig abwickeln kann. Python hingegen kann durch den Global Interpreter Lock mehrere Kerne nicht effizient nutzen.
Laut README auf GitHub ist das Tool beim Download bis zu 12× schneller als die AWS CLI. Wie die folgenden Benchmarks zeigen, überträgt es Daten unter den richtigen Bedingungen aber deutlich schneller.
Solche Performance-Vorteile bei der Übertragungszeit schlagen sich direkt in eingesparter EC2-Rechenzeit nieder – und damit in barem Geld. Wie Sie gleich sehen werden, verschenkt man ohne s5cmd erhebliche Beträge.
Um die Performance von s5cmd und aws s3 cp in verschiedenen Szenarien zu vergleichen, messe ich die Laufzeiten der folgenden Aufgaben mit jeweils 4 TB Daten:
- Upload von EC2 nach S3
- Download von S3 nach EC2
- Kopie zwischen Buckets in derselben Region
- Kopie zwischen Buckets in unterschiedlichen Regionen
Die Laufzeiten dieser vier Aufgaben werden für beide Tools über vier verschiedene 4-TB-Datensätze hinweg erfasst:
- Sehr große Dateien (5 GB, also 819 Dateien)
- Große Dateien (1 GB, also 4.096 Dateien)
- Mittelgroße Dateien (32 MB, also 131.072 Dateien)
- Kleine Dateien (256 KB, also 16.777.216 Dateien)
Zusätzlich wird die AWS CLI immer zweimal ausgeführt:
- Einmal mit den Standardwerten der AWS CLI
- Ein zweites Mal mit folgenden angepassten Werten, um den Durchsatz auf einer leistungsstarken EC2-Instanz zu erhöhen:
max_concurrent_requests=64 (passend zur 64-Core-VM) statt 10
multipart_threshold=1GB statt 8MB
multipart_chunksize=256MB statt 8MB
Die Performance bei Upload, Download und Kopie hängt eng von Faktoren wie Objektgröße, Objektanzahl, Parallelisierung und der Vermeidung übermäßiger Parallelität durch hohe Schwellenwerte für Multipart-Uploads ab. Die folgenden Benchmarks berücksichtigen diese Faktoren, um die Datentransfer-Performance in mehreren realistischen Nutzungsszenarien aufzuzeigen.
Wer die Benchmarks aus diesem Artikel nachstellen möchte, findet im Git-Repo zu diesem Blogpost alles Nötige. Es macht eine automatisierte Reproduktion der Benchmarks so einfach wie möglich.
Eine kurze Anmerkung, bevor wir in die Laufzeitvergleiche einsteigen:
Für alle Benchmark-Tests kam eine c7gn.16xlarge-Instanz der neuesten Generation zum Einsatz – mit 200 Gbps Netzwerkdurchsatz und 64 leistungsstarken Graviton-Cores. Angeschlossen waren 12× 1,1 GB große gp3-EBS-Volumes in einer RAID0-Konfiguration mit jeweils 16.000 IOPS und 1.000 Mbps Durchsatz. Mit diesem Setup sind Netzwerkdurchsatz, I/O-Durchsatz und Rechenleistung als Engpässe weitgehend ausgeschlossen, sodass die Tools ihr volles Potenzial entfalten können.
Upload von EC2 nach S3
Unten sehen Sie die Laufzeiten von s5cmd cp im Vergleich zu aws s3 cp beim Upload von Dateien aus einer leistungsstarken EC2-Instanz in einen S3-Bucket in derselben Region.
Hinweis: Die y-Achse ist in allen folgenden Diagrammen logarithmisch skaliert:
Das Diagramm zeigt deutlich: s5cmd ist beim Upload wesentlich schneller als die AWS-CLI-Tools – unabhängig von den Dateigrößen.
s5cmd ist beim Upload nach S3 beeindruckende 19× bis 26× schneller als die AWS CLI in deren Standardkonfiguration.
Das Anpassen der AWS-CLI-Konfiguration zur besseren Parallelisierung bringt nur marginale Verbesserungen, solange man nicht mit mittleren bis kleinen Dateigrößen arbeitet. Die Erhöhung der gleichzeitigen Datei-Uploads von 10 auf 64 verringert den Laufzeitunterschied bei 16 Millionen kleinen Dateien spürbar – aber selbst dann bleibt die AWS CLI 7,6× langsamer als s5cmd.
Download von S3 nach EC2
Unten sehen Sie die Laufzeiten von s5cmd cp im Vergleich zu aws s3 cp beim Download von Dateien aus einem S3-Bucket auf eine leistungsstarke EC2-Instanz in derselben Region:
Wie schon beim Upload von EC2 nach S3 ist auch der Download von S3 nach EC2 mit s5cmd deutlich performanter als mit der AWS CLI – mit einigen interessanten Unterschieden.
Auffällig: s5cmd ist beim Download nicht ganz so leistungsstark wie beim Upload – außer bei kleinen Dateigrößen.
s5cmd ist beim Download 15× bis 17× schneller als die AWS CLI in deren Standardkonfiguration. Das ist langsamer als der beim Upload nach S3 beobachtete Faktor von 19× bis 26×. Allerdings steigt die Performance von s5cmd beim Download kleiner Dateien noch weiter und liegt dort bei einem Faktor von 30,5×.
Diese Performance-Diskrepanz zwischen kleinen und größeren Dateien existiert beim Upload nach S3 nicht – beim Download aus S3 sind kleine Dateigrößen jedoch eindeutig ein wichtiger Faktor.
Das Anpassen der AWS-CLI-Konfiguration verbessert die Download-Laufzeiten deutlich stärker als beim Upload und schmälert den Vorsprung von s5cmd auf das 6,4- bis 8,7-Fache. Eine Ausnahme bilden sehr große Dateien, bei denen sich die Download-Zeit nur minimal verbessert.
Bucket-Kopie innerhalb derselben Region
Unten sehen Sie die Laufzeiten von s5cmd cp im Vergleich zu aws s3 cp beim Kopieren von Dateien zwischen zwei S3-Buckets in derselben Region:
Beim Bucket-zu-Bucket-Kopieren zeigen sich die Vorteile eines SDK in einer kompilierten Sprache sowie der Effekt optimierter CLI-Konfigurationswerte besonders deutlich.
s5cmd kopiert zwischen Buckets in derselben Region 27,6× bis 80,2× schneller als die AWS CLI in deren Standardkonfiguration.
Allerdings führt allein die Erhöhung von max_concurrent_requests von 10 auf 64 zu enormen Verbesserungen bei aws s3 cp und reduziert den Vorsprung von s5cmd auf das 3,6- bis 5,0-Fache.
Bucket-Kopie zwischen Regionen
Unten sehen Sie die Laufzeiten von s5cmd cp im Vergleich zu aws s3 cp beim Kopieren von Dateien zwischen zwei S3-Buckets in unterschiedlichen Regionen (us-east-1 nach us-west-2):
Auch wenn regionsübergreifende Bucket-Kopien in allen Dateigrößen-Szenarien sowohl für s5cmd als auch für aws s3 cp deutlich länger dauern als regionsinterne Kopien, ist es bemerkenswert, dass der Geschwindigkeitsvorsprung von s5cmd gegenüber aws s3 cp sehr ähnlich ausfällt wie bei regionsinternen Bucket-Kopien.
s5cmd kopiert Dateien zwischen Buckets in unterschiedlichen Regionen 27,6× bis 40× schneller als die AWS CLI in deren Standardkonfiguration. Die Erhöhung von max_concurrent_requests von 10 auf 64 bringt für AWS-CLI-Befehle dieselben deutlichen Laufzeitverbesserungen und reduziert den Vorsprung von s5cmd auf das 3,5- bis 4,8-Fache.
Endergebnisse
Das untenstehende Liniendiagramm fasst die Geschwindigkeitsvorteile von s5cmd gegenüber den Laufzeiten von aws s3 cp zusammen:
Fazit: Setzen Sie immer auf s5cmd
Unabhängig von Dateigrößen, Anzahl der zu übertragenden Dateien und Art der genutzten S3-Operationen liefert s5cmd in jedem Szenario die bessere Performance.
Die Performance-Vorteile von s5cmd resultieren größtenteils aus der Implementierung in einer kompilierten Sprache. Eine wesentliche Rolle spielt aber auch das Fehlen smarter oder dynamisch ermittelter Defaults bei aws s3 cp. Das Anpassen der AWS-CLI-Konfigurationswerte zur Verbesserung von Parallelisierung und Upload-Durchsatz hat in der Regel nur marginale Auswirkungen – es sei denn, Sie arbeiten mit winzigen Dateien oder kopieren Dateien zwischen zwei Buckets. Aber selbst dann bleibt eine große Performance-Lücke zu s5cmd. Persönlich würde ich für Datentransfers ausschließlich s5cmd empfehlen, sofern keine sehr spezifischen Gründe dagegen sprechen. So könnten beispielsweise die Sicherheitsrichtlinien Ihres Unternehmens nur die Installation "offizieller", von AWS bereitgestellter Tools erlauben.
Wenn Sie die Zeit für Datentransfers in und aus S3-Buckets um ein bis zwei Größenordnungen reduzieren, ergeben sich erhebliche Einsparungen auf Ihrer Cloud-Rechnung – insbesondere wenn die Datennutzung in Ihrem Unternehmen wächst. Vor diesem Hintergrund sehe ich, soweit erkennbar, keinen Grund, die AWS CLI für Datentransfers zu bevorzugen, außer dem Wunsch, ausschließlich bei AWS-eigenem Tooling zu bleiben.
Haben Sie weitere Fragen, wie Sie diese Empfehlungen umsetzen können, um GCP- oder AWS-Data-Warehousing in Ihrem Unternehmen erfolgreich zu betreiben?
Sprechen Sie uns an bei DoiT International. Unser Team besteht ausschließlich aus erfahrenen Senior Engineers und ist auf anspruchsvolle Cloud-Beratung, Architekturdesign und Debugging spezialisiert.