In Google Cloud gibt es viele Möglichkeiten, Daten zu speichern. Dieser Artikel stellt eine davon vor: den Object Storage Google Cloud Storage (GCS).
**Aufgabe**
Google Cloud Storage dient dazu, binäre Daten als Ganzes zu speichern und wieder abzurufen. Liegt eine solche Einheit auf Ihrem Rechner, sprechen Sie von einer Datei – in GCS heißt sie hingegen Object. Anders als Dateien auf Ihrem Rechner sind GCS-Objects immutable und lassen sich niemals verändern.
GCS-Objects können gelöscht oder ersetzt, aber nicht verändert werden. Diese Eigenschaft lässt sich in vielen Architekturen im Cloud-Maßstab gezielt nutzen.
GCS-Objects sind außerdem opak. GCS kennt die interne Struktur der Objects nicht, da es sich schlicht um binäre Datensequenzen handelt. Über zugehörige Metadaten hält GCS Eigenschaften eines Objects fest – etwa Erstellungsdatum und -zeit, MIME-Typ und Größe.
GCS-Objects sind durable. Google speichert Objects mit unterschiedlichsten Verfahren und erreicht damit mindestens elf "Neunen", also eine jährliche Durability von 99,999999999 % innerhalb einer Region. (Zum Schutz vor Verlusten durch lokale Katastrophen – ob natürlichen oder menschlichen Ursprungs – lassen sich Daten in mehreren Regionen oder sogar in mehreren Clouds ablegen.) Elf Neunen heißt: Bei einer Milliarde Objects, die 100 Jahre lang gespeichert werden, wäre höchstens ein Verlust zu erwarten.
GCS-Objects sind verfügbar. Verfügbar bedeutet, dass GCS ein Object auf Anfrage ausliefern kann. GCS bietet verschiedene SLA-Optionen für die monatliche Verfügbarkeit: 99,95 %, 99,9 % oder 99,0 %. In Zeit ausgedrückt entspricht das 22 Minuten, 44 Minuten oder 7 Stunden 18 Minuten Nichtverfügbarkeit pro Monat.
GCS-Objects werden in Buckets innerhalb eines GCP-Projekts gespeichert. Buckets liefern den Speicherkontext für die Objects – inklusive Identität, hostendem Projekt (das mit Security und einem Billing-Account verknüpft ist), geografischem Standort, diversen Policies und mehr.
Ein GCS-Bucket besitzt einen global eindeutigen Identifier in Form eines URI . Google verwendet das URI-Schema gs: für GCS-Buckets und -Objects.
Die URI-Syntax lautet: gs://
Ein Beispiel: gs://doit-intl-storage/logo.png ist ein global eindeutiger URI.
Architektonische Rolle
GCS spielt in den Architekturen vieler Cloud-Systeme eine zentrale Rolle. Generell ist GCS-Storage die günstigste Option zum Ablegen von Informationen. Behalten Sie dennoch Latenz, Bandbreite und klassische Architekturanforderungen im Blick, um die Kosteneffizienz zu wahren.
Bedenken Sie: GCS ist ein Service. Der Zugriff erfolgt über eine REST-API, die wiederum durch Client-Bibliotheken für viele Programmiersprachen, eine CLI und zahlreiche Drittanbieter-Tools gekapselt wird. GCS ist kein Block-Storage-System und lässt sich nicht direkt als Dateisystem für eine virtuelle Maschine oder Container einbinden.
Kosten
Die Kosten für die Nutzung von Google Cloud Storage hängen von mehreren Faktoren ab. Die wichtigsten sind:
- Größe eines Objects
- Speicherdauer
- Eigenschaften des Buckets: Standort, Redundanz und Storage-Klasse
- Aktivität, etwa Schreib- und Lesezugriffe auf ein Object und seine Metadaten
- Über ein oder mehrere Netzwerke übertragene Bytes beim Transfer des Objects
Sie können die Kosten aus zwei Blickwinkeln betrachten. Erstens: Was kostet es, ein Object zu speichern, wenn nichts damit geschieht – nach dem Schreiben wird es weder gelesen noch gelöscht? Das sind die reinen Speicherkosten. Zweitens: aktivitätsbasierte Kosten wie Lesen, Übertragen, Löschen, Abfragen usw.
Schauen wir uns konkrete Zahlen an. Für die reinen Speicherkosten nehmen wir das Beispiel eines einzelnen Objects mit 1 GiB, das ein Jahr lang gespeichert wird. (Hinweis: 1 GiB = 1073741824 Byte (= 10243 B = 230 B).)
Am teuersten ist Standard-Storage in Brasilien mit 0,42 $; an vielen anderen Standorten sinkt der Preis auf bis zu 0,24 $. Standard-Storage eignet sich am besten für häufig genutzte Objects. Für inaktive Objects sind die Kosten für Archive-Class-Storage drastisch niedriger: 0,036 $ in Brasilien, 0,0144 $ andernorts.
Aktivitätskosten können neue Nutzer überraschen. Gebühren fallen an für Schreibvorgänge, Lesevorgänge, das Auflisten von Objects sowie für das vorzeitige Löschen von Objects (sofern ein Object in einem Langzeit-Storage-Kontext liegt). Diese Gebühren können das Engineering und sogar die Architektur eines Cloud-Systems beeinflussen.
Ein Beispiel: Ich habe einmal ein Unternehmen beraten, das Satellitenbilder verwaltet. Dessen On-Premise-System legte viele kleine Bildkacheln ab. Beim Umzug nach GCS zeigte sich, dass das ursprüngliche Design – kleine Kacheln zu lesen und daraus ein großes Bild zusammenzusetzen – wegen der vielen Lesezugriffe extrem hohe Kosten verursachte.
Das System wurde so überarbeitet, dass weniger, dafür größere Bilder gespeichert und nach dem Lesen im Arbeitsspeicher zerlegt werden. Sehr kontraintuitiv, aber Realität in GCS.
Security
Das übergreifende Thema Cloud-Security behandle ich in einem separaten Artikel. In GCS wird Security über IAM verwaltet. Früher gab es einige gravierende Sicherheitslecks, weil sich versehentlich allzu leicht öffentlicher Zugriff auf einen Storage-Bucket einrichten ließ. Google hat das geändert und zahlreiche Warnhinweise eingebaut.
Bleiben Sie mit uns in Kontakt – über den DoiT Engineering Blog , den DoiT LinkedIn-Kanal und den DoiT Twitter-Kanal . Karrieremöglichkeiten finden Sie unter https://careers.doit-intl.com .