ObjectGateway
Wie schnell ist S3 aus Anwendungssicht?
Von Marc Singer
Aktualisiert 6 Min. Lesezeit
In meinem letzten Beitrag kamen zwei Speicher-Cluster nicht hinterher. Der Weg zu den Daten war zu lang, und die Metadaten bremsten den Speicher aus. Als ich die Architektur von ObjectGateway entwarf, wurde Performance deshalb zu einem von drei Grundpfeilern, neben einem stabilen Betrieb und S3 genau so, wie Ihre Software es erwartet.
Wie schnell ist ObjectGateway also? Das Gateway selbst ist nur die halbe Antwort. Die andere Hälfte ist, wo die Anwendung läuft, die S3 nutzt. Dasselbe Gateway beantwortet einen kleinen Lesezugriff aus demselben Rechenzentrum in 2 ms und über eine Landesgrenze hinweg in 20 ms. Ein Batch-Job, der 10’000 kleine Objekte nacheinander liest, braucht im selben Rechenzentrum 20 Sekunden. Aus dem Nachbarland braucht er über 3 Minuten. Der Speicher darunter ist in beiden Fällen derselbe.
So habe ich gemessen
Leo (@leodev) hat storage-bench veröffentlicht. Der Benchmark misst, was Anwendungen im Alltag tun. Ich habe mich für ihn entschieden, weil Leo damit seinen Vergleich öffentlicher S3-Angebote gebaut hat.
Seine Version ist auf die Anbieter aus seinem Vergleich zugeschnitten. Ich habe storage-bench deshalb so angepasst, dass er mit jedem beliebigen S3-Dienst funktioniert. Anschliessend habe ich ihn aus vier Cloud-Zonen in Frankfurt, München, Genf und Wien gegen unsere beiden Gateways in Bern und Nürnberg laufen lassen. Beide Standorte laufen mit unserer aktuellen stabilen Version v0.7.4. Die Rohdaten sind online.
Was die Entfernung kostet
So lange dauert ein typischer Download von 1 KB, je nach Standort der Anwendung:
Als Tabelle anzeigen
| Anwendung | Bern | Netz | Nürnberg | Netz |
|---|---|---|---|---|
| Gleiche Maschine | 1,8 ms | 0,2 ms | 1,8 ms | 0,3 ms |
| Gleiches Rechenzentrum | 2,2 ms | 1,1 ms | 3,0 ms | 1,4 ms |
| Frankfurt | 9,4 ms | 6,5 ms | 5,4 ms | 3,8 ms |
| München | 13,3 ms | 10,3 ms | 11,4 ms | 9,2 ms |
| Genf | 8,3 ms | 4,1 ms | 19,4 ms | 16,2 ms |
| Wien | 20,0 ms | 16,2 ms | 16,1 ms | 13,2 ms |
Aus dem Nachbarland dauert jeder kleine Zugriff rund zehnmal so lange wie aus demselben Rechenzentrum.
Ich wollte wissen, wie viel Zeit das Gateway selbst braucht. Dafür habe ich an beiden Standorten zusätzlich die reine Netzwerkzeit gemessen, auf derselben Maschine wie das Gateway. In beiden Fällen kamen für Gateway und Client nur ca. 1,5 ms dazu. Aus den Cloud-Zonen war es etwas mehr, je nach Client-Maschine. Alles andere im Diagramm ist Entfernung.
Abseits des Gateways
Das Problem mit den Metadaten aus meinem letzten Beitrag macht sich auch hier bemerkbar. In Bern läuft das Gateway in einer virtuellen Maschine und erreicht seine ZFS-Disks über eine zusätzliche Abstraktionsschicht. Kleine Lese- und Schreibzugriffe merken davon nichts. Auf derselben Maschine dauert ein kleiner Lesezugriff an beiden Standorten 1,8 ms. Das Auflisten von 1’000 Objekten dauert in Bern 77 ms, in Nürnberg jedoch nur 25 ms. Ohne Netz dazwischen kommt dieser Unterschied vom Speicher.
Jede Abstraktionsschicht zwischen Gateway und Disks kostet Performance. Aber ich betreibe das Gateway in Bern absichtlich so. An unseren eigenen Standorten probiere ich die Varianten aus, die Kunden betreiben könnten, ob unterstützt oder nicht. So lerne ich, was eine Variante kostet und was sich optimieren lässt, bevor ein Kunde darauf stösst.
In Nürnberg ist der Benchmark über einen Filter im Netz, vermutlich den DDoS-Schutz meines Hosting-Anbieters, vor dem Gateway gestolpert. Der Benchmark startet 32 Uploads im selben Moment, und beim ersten Mal kamen einige davon nie an. Das Gateway selbst zeigt keine Fehler. Von einem anderen Server im selben Rechenzentrum kamen alle Uploads an. Kommen zu viele neue Verbindungen auf einmal, lässt der Filter nur einen Teil davon durch. Da Anwendungen ihre Verbindungen standardmässig wiederverwenden, merken sie davon üblicherweise nichts.
Bei 100 MB stösst der Test selbst an seine Grenze. Aus Frankfurt liefern beide Standorte ca. 160 MB/s, also nur genau so viel, wie der Netzwerkanschluss der kleinen Testmaschine hergibt. Auf derselben Maschine liefern die Gateways 360 bis 410 MB/s.
Nah an Ihrer Anwendung
Ich habe ObjectGateway so entworfen, dass es direkt auf bestehenden POSIX-Dateisystemen funktioniert. Idealerweise steht es am selben Ort wie die Anwendung. Das kann Ihr eigenes Rechenzentrum sein oder ein europäischer Cloud-Anbieter. Bei rund 1’000 Anfragen pro Sekunde und einer Million Objekten braucht es nur ca. 100 MiB Arbeitsspeicher. Neben der Anwendung findet es also problemlos Platz. Steht der Speicher im Ausland, dauert jede einzelne Anfrage länger.
Unsere Zahlen zeigen nur, was unsere eigenen Standorte leisten können. Wie schnell S3 für Ihre Anwendungen ist, zeigt der angepasste Benchmark in Ihrer eigenen Umgebung. Er funktioniert mit jedem S3-Dienst. Wenn Sie ihn ausprobieren, schreiben Sie mir gerne Ihre Ergebnisse.
Kommen neue Standorte oder Betriebsmodelle dazu, ergänze ich die Zahlen in diesem Beitrag. So wird zunehmend genauer, womit Sie rechnen können. Abonnieren Sie unsere Produkt-Updates, um auf dem Laufenden zu bleiben.