Expansion nach Singapur für besseren Asien-Pazifik-Service
Eröffnung in Singapur
Transloadit betreibt derzeit zwei Hauptrechenzentren, eines in den USA (Nord-Virginia) und eines in
der EU (Irland). Die meisten unserer Nutzer werden damit gut bedient, doch für Menschen in Japan
oder Australien geht es noch besser. Deshalb eröffnen wir ein drittes Rechenzentrum in Singapur
(auch bezeichnet als: Asien-Pazifik, AP oder: ap-southeast-1), um deutlich geringere Latenzen für die
gesamte Region zu bieten.
Wir sind mit dem Aufbau fast fertig und haben die Gelegenheit genutzt, auch einige andere große Änderungen an unserem Netzwerk-Setup vorzunehmen. AP wird von Anfang an damit ausgestattet sein, und EU & US erhalten sie in Kürze ebenfalls.
Kurz gesagt: Wir stellen auf Amazon VPCs (Virtual Private Clouds) und NLBs (Network Load Balancers) um. Tauchen wir ein in etwas AWS-Netzwerktechnik 👩💻
Virtual Private Clouds
Wie viele andere Unternehmen baut Transloadit auf AWS auf. Als wir 2009 starteten, war AWS gerade drei Jahre alt, und viele Funktionen, deren Einsatz heute selbstverständlich ist, gab es noch nicht. Eine dieser Selbstverständlichkeiten ist der Einsatz einer VPC.
Eine VPC bietet erhöhte Sicherheit und organisatorische Kontrollmöglichkeiten. So können Sie damit beispielsweise Maschinen vollständig vom Internet abschirmen und mit Netzwerk-ACLs steuern, welcher Datenverkehr zwischen verschiedenen Segmenten Ihres Netzwerks erlaubt ist.
Darüber hinaus sind viele der neuen Funktionen und Maschinentypen, die AWS anbietet, nur innerhalb
von VPCs verfügbar. Wir haben bereits einige neue Maschinentypen im Blick, die höhere Leistung
zu geringeren Kosten liefern und die wir endlich nutzen können, sobald wir in allen Rechenzentren
vollständig auf VPCs umgestellt haben. Wie erwähnt, ist Singapur bereits mit einer VPC ausgestattet.
Das bringt einige Änderungen an unseren Firewalls mit sich, und das könnte Kunden beeinträchtigen,
deren Setups ausgehende Verbindungen zu Nicht-Standard-Ports benötigen. Ein Beispiel wäre jemand,
der unseren Robot /html/convert verwendet, um einen Screenshot
von url zu erstellen, etwa https://example.com:1234/.
Bitte melden Sie sich, falls das für Sie ein Problem darstellt, denn standardmäßig erlauben wir keine ausgehenden Verbindungen zu beliebigen Ports mehr.
Network Load Balancers
Bislang nutzten sowohl unser US- als auch unser EU-Rechenzentrum den Elastic Load Balancer (ELB) von AWS, um eingehenden Datenverkehr auf viele verschiedene Maschinen zu verteilen. Vor Kurzem hat Amazon zwei neue Typen von Loadbalancern eingeführt und den bestehenden in „Classic“ umbenannt:
- Classic Load Balancer (ELB)
- Application Load Balancer (ALB)
- Network Load Balancer (NLB)
Der ALB lässt sich als Weiterentwicklung des ELB verstehen. Beide sind Layer 7-Loadbalancer, das heißt, sie können HTTP-Datenverkehr „verstehen“ und beispielsweise die SSL-Terminierung übernehmen, sodass sich Ihre Backend-Server nicht um SSL kümmern müssen. Der ALB bietet zusätzliche Vorteile, etwa die Möglichkeit, Datenverkehr je nach URL an verschiedene Server zu leiten.
Der neu eingeführte Network Load Balancer ist ein ganz anderes Kaliber. Er arbeitet auf Layer 4, das heißt, er weiß nichts von Dingen wie HTTP und leitet Datenverkehr auf Ebene der IP-Pakete an Backend-Maschinen weiter. Das macht sie funktionsärmer (keine SSL-Terminierung und kein Routing anhand der URL), aber deutlich leistungsfähiger. Aus einer Reihe von Gründen lassen sich Millionen von Anfragen pro Sekunde bei deutlich geringeren Latenzen verarbeiten.
Dass SSL auf dem Loadbalancer nicht mehr verarbeitet werden kann, halten wir für eine gute Sache. Schließlich würde der Datenverkehr bei einer Terminierung ohnehin von AWS entschlüsselt und unverschlüsselt zu unseren Backend-Servern fließen. Es ist nur der letzte Abschnitt, aber dennoch: Die Entschlüsselung selbst an der allerletzten Station vorzunehmen, verkleinert die Angriffsfläche.
Ein weiterer Grund für die Abkehr vom klassischen ELB ist, dass Sie bei einer erwarteten Verkehrsspitze den AWS-Support kontaktieren mussten, damit dieser Loadbalancer für Sie vorwärmt, oder riskierten, für einige Zeit stark gedrosselt zu werden. Nicht so toll! Es ist klar, warum AWS jetzt empfiehlt, davon abzurücken, und genau das tun wir, beginnend mit unserem neuen Rechenzentrum in Singapur.
Wir freuen uns auf die geringeren Latenzen und die erhöhte Sicherheit, die diese Änderungen Ihren Endnutzern bringen werden, aber Vorsicht ist immer gut.
Tests
Wir halten es für unwahrscheinlich, dass diese NLBs Probleme verursachen, wollen aber auch keine
Annahmen treffen. Es gibt Unterschiede darin, wie der Datenverkehr fließt und wie SSL terminiert
wird, sodass immer ein Risiko für Ausfälle besteht. Wenn Sie möchten, können Sie daher schon jetzt
unseren Endpunkt https://api2-ap-southeast-1.transloadit.com in Ihrer Staging-Umgebung ausprobieren, um zu sehen,
ob die Verbindungen korrekt aufgebaut werden.
Beachten Sie, dass einige Probleme zu erwarten sind, da Singapur:
- noch Änderungen durchläuft und nicht mit voller Kapazität läuft, sodass die Encoding-Leistung schlechter ausfällt
- höhere Latenzen aufweist, wenn Sie von den USA oder der EU aus testen. Normalerweise wird beim
Aufruf von
https://api2.transloadit.comUS-Datenverkehr einfach an unser US-DC geleitet, während Nutzer etwa in Tokio nach Singapur geleitet werden. Beim Testen bitten Sie uns nun jedoch möglicherweise explizit darum, Datenverkehr in einem weiter entfernten DC zu verarbeiten
Trotz dieser Einschränkungen lässt sich Singapur bereits nutzen, um zu testen, ob Ihre App und Ihre Integration mit unserem neuen Netzwerk-Setup kompatibel sind. Bitte melden Sie sich, wenn Ihre Tests fehlschlagen, damit wir Probleme gemeinsam ausschließen können.
Fazit
Das sind die größten Änderungen, von denen wir glauben, dass sie sich auf unsere Kunden auswirken könnten. Wir haben jedoch unsere gesamte Infrastruktur von Grund auf neu aufgebaut, sodass es weitere subtile Unterschiede geben könnte. Deshalb werden wir Singapur zunächst gründlich testen, bevor wir diese Änderungen in unseren bestehenden Rechenzentren ausrollen – und wir bitten Sie, dasselbe zu tun.
Wir beabsichtigen, Singapur am 7. Januar 2019 zu starten (also in etwa zwei Wochen); das betrifft nur Endnutzer in der Region Asien-Pazifik (und verbessert deren Latenzen). Beachten Sie, dass wir beim ersten Anzeichen von Problemen problemlos aufhören können, Datenverkehr dorthin zu senden, sodass EU & US diese Last wieder übernehmen, als wäre nichts gewesen.
Wenn alles gut läuft, wollen wir diese Änderungen vor Ende Januar 2019 in den bestehenden US- und EU-Rechenzentren ausrollen.
Beim Aufbau von Singapur haben wir standardisiert, wie Rechenzentren bereitgestellt werden, sodass es für uns sehr unkompliziert geworden ist, ein Rechenzentrum über Singapur hinaus zu eröffnen. São Paulo, ich habe dich im Blick! 👀😄
Wenn Sie Fragen oder Bedenken haben, melden Sie sich gerne bei uns.