Webserver mit Google Compute Engine

Vor allem die großen Cloud Anbieter bieten ein breites Spektrum an Diensten. In der Google Cloud kann man z.B. virtuelle Maschinen (Compute Engine), Container (Kubernetes), Apps (App Engine) oder zustandslose Funktionen (Cloud Functions) ausführen lassen.

Dabei ist Compute Engine die einfachste Form der Virtualisierung, bei der man zwar die größte Kontrolle hat, aber für die Konfiguration, Verwaltung und Überwachung selbst verantwortlich ist.
Am anderen Ende des Spektrums befinden sich die Cloud Functions. Hier schreibt der Entwickler Funktionen, die in der Cloud ausgeführt werden sollen, und muss sich nicht um Infrastruktur oder Verwaltung kümmern.

Ich nutze Firebase und Cloud Functions bereits für kleinere Projekte und denke, dass sich Serverless und Cloud Computing in Zukunft weiter durchsetzen werden.
Gerade Anfängern dürfte es jedoch schwer fallen, das passende Angebot zu finden und die anfallenden Kosten abzuschätzen. Deshalb möchte ich hier einen kurzen Überblick über meine ersten Erfahrungen mit Google Compute Engine geben.

GCE Maschinen Typen

Es gibt etliche Maschinenkonfigurationen, die sich jeweils für verschiedene Zwecke eignen: allgemeine Zwecke, computing-optimiert oder arbeitsspeicher-optimiert. Dazu kommt noch die Auswahl der CPU Generation: N1, N2 oder E2.

N1 ist die ältere CPU Generation, während N2 und E2 neuere CPU's beinhalten.
Meinen Anforderungen als Webserver (nginx, PHP, MySQL etc.) genügen zwei vCPU und ca. 4 GB RAM. Die Nutzung einer relativ kleinen Maschine ist möglich, da ich bereits zuvor die Serverlast mit Hilfe von Cloudflare (siehe Artikel) deutlich reduzieren konnte.

Die preiswerteste Variante wäre e2-medium mit 2 vCPU und 4 GB RAM. In der Anwendung konnte ich keinen großen Unterschied zwischen N1 und E2 erkennen, N2 Maschinen fand ich dagegen deutlich schneller: Unter Produktionsbedingungen halbierte sich die durchschnittliche Prozessorlast beim Umschalten von e2-medium auf n2-standard. Es zeigte sich, dass eine n2-standard Maschine meine Webseite schneller renderte, als mein 8-core-vServer beim alten Provider.

Bootlaufwerke

Beim Bootlaufwerk kann man zwischen drei Laufwerkstypen wählen. Dabei ist zu beachten, dass die Durchsatzleistung eines Laufwerks vom Laufwerkstyp abhängt und proportional zur Laufwerksgröße ist.
Zu beachten ist auch, dass durch das Bootlaufwerk Kosten entstehen, was mir vorher nicht bewusst war. Im Rückblick hätte für meinen Webserver ein 100 GB großes Bootlaufwerk ausgereicht. Doch dazu später mehr.

Wie man im Formular der Laufwerkserstellung sehen kann, hat ein 10 GB großes SSD-Laufwerk ein Limit von 300 IOPS und 4 MB/s (!).
Ja, tatsächlich 4 Megabyte pro Sekunde, nicht Gigabyte pro Sekunde, wie man es von einer SSD erwarten würde. Da mir das zu wenig war, habe ich beim ersten Versuch ein 200 GB SSD-Laufwerk erstellt, nur um ein einigermaßen performantes Laufwerk zu haben.

Für eine 200 GB SSD sind die Limits schon besser, bei 6000 IOPS und 96 MB/s. (Diese Limits gelten übrigens auch, wenn man Cloud SQL-Instanzen erstellt.)

Für meine Anwendung habe ich später feststellen können, dass sich die Limits zwischen einer 100 GB und 200 GB SSD nicht so sehr auf die Performance auswirken wie der Maschinentyp, also N1 oder N2. Nun wollte ich mir die monatlichen 15 EUR für 100 GB SSD sparen und mein Bootlaufwerk verkleinern.

Hier kam die nächste Hürde: Man kann ein Laufwerk zwar einfach über die Cloud Console vergrößern, aber nicht mehr verkleinern. Ich habe im Netz einige Anleitungen zum verkleinern eines Laufwerks mit weresync gefunden. Das hat bei mir nicht funktioniert. Schließlich habe ein neues 100 GB Bootlaufwerk mit allen Partitionen erstellt und meine Daten mit rsync kopiert.

Man kann einer Maschine auch physische SSD's (je 375 GB) zuordnen. Diese bringen die hohe Leistung einer 'echten' SSD, werden aber beim Neustart der Maschine gelöscht. Für mein Verständnis lohnt sich das nur für temporäre Dateien oder man muss mit einem nichtflüchtigen Speicher synchronisieren.

Backup / Images

Mit wenigen Klicks lassen sich Maschinen-Images, normale Images und Snapshots erstellen. Ein Maschinen-Image beeinhaltet die komplette Konfiguration, während Snapshots, die sich im übrigen auch automatisch über einen Zeitplan erstellen lassen, jeweils nur die Änderungen eines Laufwerkes festhalten.

Um bestimmte Verzeichnisse und MySQL Dumps zu sichern, habe ich auf der Maschine einen Cronjob angelegt, der diese Dateien in einen Cloud Storage Bucket schiebt. Für Backups kann man einen preiswerten Cold Line Bucket anlegen. Man muss der Maschine nur noch die Rechte zum schreiben in Cloud Storage geben. Hier zeigt sich ein Vorteil der Cloud: Man kann über Dienstekonten die Rechte kontrollieren, ohne selbst etwas dafür programmieren zu müssen.

Monitoring

Das Monitoring macht richtig Spaß. So etwas hatte ich mir von meinem alten Hoster immer gewünscht! Es lassen sich Dashboards mit verschiedensten Messwerten für CPU, RAM, MySQL etc. zusammenstellen. Man kann Alarme definieren und bekommt dann beim Überschreiten bestimmter Schwellwerte eine E-Mail oder wird sofort über die Cloud Consolen App auf dem Smartphone benachrichtigt.

(Man kann auf dem Smartphone tatsächlich eine Cloud Shell öffnen)

Damit das Monitoring funktioniert, wird auf der Maschine der Monitoring Agent installiert. Man kann auch einen Logging Agenten installieren. Diese Agenten benötigen natürlich Ressourcen auf der Maschine (Monitoring Agent: 250MB RAM) und erzeugen einen gewissen Traffic.

Kosten

Welche Kosten ungefähr anfallen, kann man mit dem Google Cloud Preisrechner durchspielen. Allerdings beinhaltet die Kalkulation für Compute Engine nicht das Bootlaufwerk und auch nicht den erwarteten Netzwerktraffic. Für eine 200 GB großes Bootlaufwerk entstehen zusätzliche Kosten von ca. 30 EUR/Monat.

Wer sich sicher ist, dass er bestimmte Leistungen über die nächsten Jahre benötigt, kann sogenannte Zusicherungen (Commitments) kaufen. Ich habe eine Zusicherung über 3 Jahre für eine vCPU und 4 GB RAM gekauft. Durch Zusicherungen hat Google mehr Planungssicherheit und der Anwender spart für diese Ressourcen ungefähr die Hälfte der Kosten. Zusicherungen für Bootlaufwerke oder Netzwerktraffic kann man leider (noch) nicht kaufen.

Mein Fazit

Wenn man lediglich virtuelle Maschinen hosten möchte, gibt es sicherlich günstigere Angebote bei bekannten Hostern.
Richtig Sinn macht die Google Cloud meiner Meinung nach erst durch die Verknüpfung der verschiedenen Dienste und Regionen. So kann ich ein privates VPC-Netzwerk aufbauen, in dem meine Compute Engines, Cloud Funktions, Cloud SQL oder App Engines schnell und sicher miteinander kommunizieren und den guten alten Webserver mit PHP und MySQL aufdröseln in mehrere skalierbare Services und API's für eine moderne WebApp mit Next.js, React oder Vue.