Ich habe kürzlich beschlossen, mit der API auf unserer CardGames.io- Website zu experimentieren und das Serverless- Framework auszuprobieren . In den letzten Jahren ist es ein heißes Thema in der Welt der Technologie geworden, und ich habe gezögert , meine technischen Fähigkeiten auf dem neuesten Stand zu halten und etwas Neues auszuprobieren. Aus diesem Grund habe ich mich entschlossen, mehrere Stunden mit Serverless zu verbringen und zu prüfen, ob eine solche API-Platzierung sinnvoll ist.

Aktuelle Konfiguration

CardGames.io läuft unter AWS. Alle HTML-Seiten, CSS, JavaScript und Bilder werden in S3 gespeichert. Wir haben eine C # -API, die auf Elastic Beanstalk gehostet wird und auf Linux-Servern ausgeführt wird, auf denen .NET Core mit Docker ausgeführt wird. Schließlich verwenden wir CloudFront CDN vor der Statik auf S3 und API. Unten ist der EC2-Score für August 2019. Wir haben mehrere andere Instanzen, aber die APIs funktionieren auf m1.small (ja, t2.small funktioniert wahrscheinlich besser) mit klassischem Lastausgleich. Wenn Sie das rot hervorgehobene zusammenfassen, kommen 164,21 USD pro Monat heraus, nicht schlecht. Ich habe dort sogar EBS aufgenommen, da ich nicht sicher bin, wie ich diese Ausgaben aufteilen soll. Wir haben mehrere Projekte zu EC2.


AWS-Konto für elastische Bohnenstange

Wir haben zwei Umgebungen mit jeweils 1-3 Instanzen: aktiv und inaktiv, da die .NET Core-Bereitstellung in Docker unter AWS einige Minuten dauert. Wir tun dies also in einer inaktiven Umgebung und wechseln dann die CNAME-Datensätze zu der kürzlich bereitgestellten. Langsame Bereitstellung war einer der Gründe, warum ich etwas Neues ausprobieren wollte. Wir haben mehrere Server mit node.js-Anwendungen auf Beanstalk - und diese werden in Sekunden bereitgestellt. Ich wollte, dass es für die API dasselbe ist.

Wechseln zu Serverless

Ich habe ein sehr gutes ASP.NET-Web-API-Hosting- Tutorial mit dem Serverless-Framework studiert und festgestellt, dass Sie einem vorhandenen API-Projekt nur eine einfache Konfigurationsdatei, eine Abhängigkeit und eine kleine Startklasse hinzufügen müssen. Die Bereitstellung dauerte ungefähr zwanzig Sekunden - viel besser als in Beanstalk. Ich denke, dank der integrierten Unterstützung für .NET Core in Lambda (jedoch nur 2.2), während es in Beanstalk nur unterstützt wird, wenn Sie ein unabhängiges Docker verwenden. Auf jeden Fall war ich glücklich, ohne an automatische Skalierungsgruppen, maximale Instanzen und dergleichen zu denken.

Leistungstests

Serverless unter AWS ist Lambda, das Ihre Funktionen wirklich hostet, und die Front Gateway-API, mit der Sie Dinge wie Geschwindigkeitsbegrenzungen, API-Schlüssel und mehr hinzufügen können. Ich habe die Lambda-Funktionen in der Region us-west-2 gehostet, in der sich die Beanstalk-Server befinden. Dann habe ich die CloudFront-Instanz so konfiguriert, dass Anforderungen von einem unserer Spiele an die neue serverlose Konfiguration und das andere an die alte Beanstalk-Konfiguration weitergeleitet werden. Dann startete er einen einfachen Test für zwei URLs: eine Serverless, die andere Beanstalk. Beide URLs haben dieselbe API aufgerufen und dasselbe Ereignis in der Datenbank gespeichert. Ich habe jeweils 100 Abfragen ausgeführt. Hier sind die Ergebnisse:


Leistungsvergleich

In mehreren Läufen war die serverlose Konfiguration um 15% langsamer (wenn überhaupt, habe ich sie von Island aus ausgeführt, daher der große Ping). Die Geschwindigkeit war eine Enttäuschung, aber sie blieb ziemlich hoch - ich erkannte, dass die API-Gateway-Front vor unserer API einen gewissen Overhead hat: Es gibt zu viele Funktionen, auch wenn wir sie nicht verwenden. Also traurig, aber nicht kritisch!

Preise

Ehrlich gesagt habe ich zuerst nicht über Preise nachgedacht. Ich habe gerade entschieden, dass das Bezahlen für den tatsächlichen Gebrauch wahrscheinlich billiger ist als das Bezahlen für Instanzen rund um die Uhr. Daher konnte die neue serverlose Installation mehrere Tage lang ausgeführt werden und begann dann, Konten zu überprüfen. Ups! Die Rechnung für Lambda + API Gateway hat bereits einhundert Dollar überschritten! Zuerst fing ich an, am Lambda-Setup zu basteln und weniger Speicher für das Speichern zuzuweisen, aber als ich mir ansah, was gut lief, wurde klar, dass das Problem im Gateway lag. Hier sind die API-Gateway-Raten:


Gateway-API-Preise

Unsere API akzeptiert ungefähr 10 Millionen Anfragen pro Tag. Dies sind nur ungefähr 35 US-Dollar pro Gateway pro Tag . Darüber hinaus kostet Lambda etwa 10 US-Dollar pro Tag, obwohl dies durch die Zuweisung von weniger Speicher reduziert werden kann. Zusammen ergibt sich ein Preis von 45 US-Dollar pro Tag oder 1350 US-Dollar pro Monat gegenüber 164 US-Dollar pro Monat bei Elastic Beanstalk. Achtmal teurer ! Ich mag neue Technologien und eine schnelle Bereitstellung, aber ich werde dafür keine zusätzlichen 1200 USD pro Monat zahlen. Zurück zu Beanstalk!

Fazit

Wahrscheinlich hätte ich mich im Voraus mit den Preisen vertraut machen und einige mathematische Berechnungen anstellen sollen! Aber dann müsste ich natürlich echte Arbeit leisten und keine wertvollen technischen Fähigkeiten erlernen! Ich bin sicher, dass in einigen Situationen die Gateway- und Lambda-APIs besser sind als die Elastic Beanstalk. Es ist einfach nicht unser Fall. Wenn Sie API-Schlüssel, Geschwindigkeitsbegrenzungen und andere API-Gateway-Funktionen verwenden, ist es möglicherweise sinnvoll, 3,50 USD pro Million Anfragen zu zahlen. Wir sollten besser einen normalen Load Balancer vor Lambda stellen. Soweit ich weiß, ist dies nicht möglich. Für den http-Zugriff auf Lambda ist eine Gateway-API erforderlich.

Aber selbst wenn wir nur für Lambda bezahlt hätten, wären bei 10 USD pro Tag 300 USD pro Monat statt 164 USD herausgekommen. Wir haben viele Abfragen, aber jede Abfrage macht sehr wenig: Grundsätzlich ein DB-Aufruf pro Abfrage. Möglicherweise sind schwerere Abfragen, die mehr Rechenzeit benötigen, besser für Lambda geeignet, bei dem Sie für 100 ms Rechenzeit bezahlen. Unten finden Sie einen Bericht für eine Anfrage. Wie Sie sehen können, verwenden wir 3,50 ms Rechenzeit, aber die Rechnung ist auf 100 ms eingestellt, dies ist keine schwache Rundung.


Lambda-Bericht für eine Anfrage

Schließlich kritisiere ich Gateway-, Lambda- oder Serverless-APIs überhaupt nicht. Nur um zu zeigen, dass sie für einige Workloads viel teurer sind als die langweiligen alten EC2 und Elastic Beanstalk. Auf was wir bleiben werden. Es ist auch wahrscheinlich, dass es eine viel bessere oder effizientere Möglichkeit gibt, das System zu konfigurieren. Ich bin kein AWS-Experte. Wenn Sie also offensichtliche Fehler sehen, geben Sie dies unbedingt in den Kommentaren an.