Best Practices für Cloud Storage

Einführung

Diese Seite enthält eine Zusammenfassung der Best Practices, die in anderen Teilen der Cloud Storage-Dokumentation beschrieben werden. Sie können die hier aufgeführten Best Practices als Kurzreferenz für Punkte verwenden, die Sie beachten müssen, wenn Sie eine Anwendung erstellen, für die Cloud Storage genutzt wird. Halten Sie sich an die folgenden Best Practices, wenn Sie eine kommerzielle Anwendung einführen:

Für den Einstieg in Cloud Storage ist diese Seite nicht geeignet, da hier nicht die Grundlagen der Nutzung von Cloud Storage beschrieben werden. Wenn Sie ein neuer Nutzer sind, empfehlen wir zum Einstieg die Seiten Kurzanleitung: GCP Console verwenden und Kurzanleitung: gsutil-Tool verwenden.

Benennung

  • Der Bucket-Namespace ist global und öffentlich sichtbar. Jeder Bucket-Name darf im gesamten Namespace von Cloud Storage nur einmal vorkommen. Weitere Informationen finden Sie in den Benennungsrichtlinien für Buckets und Objekte.

  • Wenn Sie viele Buckets benötigen, verwenden Sie GUIDs oder eine Entsprechung für Bucket-Namen, fügen eine Wiederholungslogik in Ihren Code ein, um Namenskollisionen zu handhaben, und führen eine Liste mit Querverweisen auf Ihre Buckets. Eine weitere Option besteht darin, Buckets mit Domainnamen zu verwenden und die Bucket-Namen als Subdomains zu verwalten.

  • Verwenden Sie in Bucket-Namen keine Nutzer-IDs, E-Mail-Adressen, Projektnamen, Projektnummern oder personenbezogenen Daten, da jeder die Existenz eines Buckets überprüfen kann. Seien Sie ebenso vorsichtig, wenn Sie personenbezogene Daten in Ihre Objektnamen aufnehmen, da die Objektnamen Bestandteil der Objekt-URLs sind.

  • Bucket-Namen sollten den Standard-DNS-Namenskonventionen entsprechen, da ein Bucket-Name in einem DNS-Datensatz als Teil einer CNAME-Weiterleitung angezeigt werden kann. Weitere Informationen zu den Anforderungen für Bucket-Namen finden Sie unter Anforderungen für Bucket-Namen.

  • Schrägstriche in Objekten haben keine besondere Bedeutung in Cloud Storage, da Verzeichnisse nicht nativ unterstützt werden. Aus diesem Grund sind komplex verschachtelte, verzeichnisartige Strukturen mit Schrägstrichen als Trennzeichen möglich. Sie bieten allerdings nicht die Leistung eines nativen Dateisystems mit komplex verschachtelten Unterverzeichnissen.

  • Vermeiden Sie sequenzielle Dateinamen wie etwa zeitstempelbasierte Dateinamen, wenn Sie viele Dateien parallel hochladen. Da Dateien mit sequenziellen Namen nacheinander gespeichert werden, gelangen sie wahrscheinlich zum gleichen Back-End-Server, was den Durchsatz begrenzt. Zur Erzielung eines optimalen Durchsatzes können Sie den Hash der Sequenznummer im Dateinamen hinzufügen, um eine Aufeinanderfolge zu vermeiden. Weitere Informationen finden Sie unter Richtlinien für die Anforderungsrate und Zugriffsverteilung.

Traffic

  • Führen Sie eine Überschlagsschätzung des Traffic-Aufkommens durch, das an Cloud Storage gesendet wird. Berücksichtigen Sie dabei insbesondere Folgendes:

    • Vorgänge pro Sekunde: Wie viele Vorgänge pro Sekunde erwarten Sie für Buckets und Objekte sowie für das Erstellen, Aktualisieren und Löschen?

    • Bandbreite: Wie viele Daten werden in welchem Zeitrahmen gesendet?

    • Cache-Steuerung: Durch die Angabe von Cache-Control-Metadaten bei Objekten mit starker Nutzung und häufigem Zugriff verkürzt sich die Latenz von Lesevorgängen. Eine Anleitung zum Festlegen von Objektmetadaten wie Cache-Control finden Sie unter Metadaten anzeigen und bearbeiten.

  • Entwickeln Sie Ihre Anwendung so, dass Traffic-Spitzen auf ein Minimum reduziert werden. Wenn es in der Anwendung Clients gibt, die Aktualisierungen durchführen, verteilen Sie diese über den Tag.

  • Zwar sieht Cloud Storage für die Anfragerate keine Obergrenze vor, Sie sollten aber die Richtlinien für die Anfragerate und Zugriffsverteilung befolgen, um bei der Skalierung auf hohe Anfrageraten eine optimale Leistung zu erzielen.

  • Berücksichtigen Sie die für bestimmte Vorgänge geltenden Ratenbegrenzungen und gestalten Sie Ihre Anwendung entsprechend.

  • Wenn Sie eine Fehlermeldung erhalten, nutzen Sie den exponentiellen Backoff, um Probleme durch Traffic-Spitzen zu vermeiden.

  • Bestimmen Sie das Leistungsniveau, das Nutzer von Ihrer Anwendung erwarten. Diese Informationen sind nützlich bei der Wahl einer Speicheroption und Region, wenn Sie neue Buckets erstellen.

Optionen für Regionen und Datenspeicher

  • Verwenden Sie für Daten, die mit hoher Rate und hoher Verfügbarkeit bereitgestellt werden, die Klasse Standard Storage. Diese Klasse bietet die bestmögliche Verfügbarkeit, hat jedoch einen höheren Preis.

  • Daten, die nur selten aufgerufen werden und für die eine etwas niedrigere Verfügbarkeit akzeptabel ist, können mit der Klasse Nearline Storage oder Coldline Storage gespeichert werden.

  • Speichern Sie die Daten in der Region, die den Nutzern der Anwendung am nächsten ist. Für EU-Daten können Sie beispielsweise einen EU-Bucket und für US-Daten einen US-Bucket wählen. Weitere Informationen finden Sie unter Bucket-Standorte.

  • Berücksichtigen Sie bei der Wahl des Standorts für Nutzerdaten die Compliance-Anforderungen. Gelten für die Standorte, an denen Ihre Nutzer Daten zur Verfügung stellen, rechtliche Bedingungen?

Sicherheit, ACLs und Zugriffssteuerung

  • Das Wichtigste ist, dass Sie niemals Ihre Zugangsdaten mit anderen teilen dürfen. Jeder Nutzer sollte eigene Anmeldedaten haben.

  • Wenn Sie HTTP-Protokolldetails ausdrucken, sind Ihre Authentifizierungsdaten wie OAuth 2.0-Tokens in den Headern sichtbar. Wenn Sie Protokolldaten in einem Forum posten oder HTTP-Protokolldetails zur Fehlerbehebung senden müssen, achten Sie darauf, alle Anmeldedaten, die dabei mit ausgegeben werden, zu entfernen oder zu sperren.

  • Verwenden Sie nach Möglichkeit für die Datenübertragung immer TLS (HTTPS). Dadurch wird sichergestellt, dass Ihre Anmeldedaten und Ihre Daten bei der Übertragung über das Netzwerk geschützt sind. Sie sollten beispielsweise https://storage.googleapis.com verwenden, um auf die Cloud Storage API zuzugreifen.

  • Verwenden Sie eine HTTPS-Bibliothek, die Serverzertifikate validiert. Eine unzureichende Validierung der Serverzertifikate macht Ihre Anwendung anfällig für Man-in-the-Middle-Angriffe oder andere Angriffe. Beachten Sie, dass HTTPS-Bibliotheken, die mit bestimmten häufig verwendeten Implementierungssprachen ausgeliefert werden, standardmäßig keine Serverzertifikate verifizieren. Beispielsweise bietet Python vor Version 3.2 keine integrierte oder vollständige Unterstützung für die Validierung von Serverzertifikaten. In diesem Fall müssen Sie Wrapper-Bibliotheken von Drittanbietern verwenden, um zu gewährleisten, dass Ihre Anwendung Serverzertifikate validiert. Das Boto-Plugin hingegen enthält Code, der Serverzertifikate standardmäßig validiert.

  • Wenn Anwendungen keinen Zugriff mehr auf Ihre Daten benötigen, sollten Sie ihre Authentifizierungsdaten widerrufen. Melden Sie sich dazu im Fall von Google-Diensten und -APIs bei Ihren Google-Kontoberechtigungen an, klicken Sie auf die nicht benötigten Anwendungen und dann auf Zugriffsrechte entfernen.

  • Anmeldedaten müssen sicher gespeichert werden. Hierfür gibt es je nach Umgebung und Speicherort mehrere Möglichkeiten. Wenn Sie beispielsweise Ihre Anmeldedaten in einer Konfigurationsdatei speichern, müssen Sie für diese Datei die entsprechenden Berechtigungen festlegen, um unbefugte Zugriffe zu verhindern. Wenn Sie Google App Engine verwenden, sollten Sie zum Speichern Ihrer Anmeldedaten StorageByKeyName nutzen.

  • Cloud Storage-Anfragen beziehen sich auf die Namen von Buckets und Objekten. Selbst wenn ACLs verhindern, dass nicht autorisierte Dritte auf Buckets oder Objekte zugreifen, könnten diese versuchen, Anfragen mit Bucket- oder Objektnamen zu senden, um anhand der Fehlermeldungen festzustellen, ob diese existieren. Auf diese Weise können Informationen in Bucket- oder Objektnamen bekannt werden. Wenn Sie Bedenken hinsichtlich der Vertraulichkeit Ihrer Bucket- oder Objektnamen haben, sollten Sie geeignete Vorkehrungen treffen, wie zum Beispiel:

    • Bucket- und Objektnamen wählen, die schwer zu erraten sind. Beispiel: Der Bucket-Name mybucket-gtbytul3 ist ausreichend willkürlich gewählt, sodass unbefugte Dritte ihn nicht so einfach erraten und keine anderen Bucket-Namen daraus ableiten können.

    • Keine vertraulichen Informationen als Bestandteile von Bucket- oder Objektnamen verwenden. Beispiel: Anstatt den Bucket mysecretproject-prodbucket zu nennen, nennen Sie ihn somemeaninglesscodename-prod. In manchen Anwendungen kann es sinnvoll sein, vertrauliche Metadaten in benutzerdefinierten Cloud Storage-Headern wie x-goog-meta beizubehalten, statt die Metadaten in Objektnamen zu codieren.

  • Verwenden Sie vorzugsweise Gruppen, um eine große Anzahl von Nutzern explizit aufzulisten. Gruppen lassen sich nicht nur besser skalieren, sie bieten auch eine sehr effiziente Möglichkeit, die Zugriffssteuerung für eine große Anzahl von Objekten gleichzeitig zu aktualisieren. Außerdem ist diese Lösung wirtschaftlicher, da Sie nicht für jedes einzelne Objekt eine Anfrage senden müssen, um die ACLs zu ändern.

  • Bevor Sie Objekte zu einem Bucket hinzufügen, achten Sie darauf, dass die Standardprojekt-ACLs Ihren Anforderungen entsprechend konfiguriert sind. Damit sparen Sie viel Zeit beim Aktualisieren der ACLs für einzelne Objekte.

  • Bucket- und Objekt-ACLs sind unabhängig voneinander. Das bedeutet, dass die ACLs für einen Bucket die ACLs für Objekte in diesem Bucket nicht beeinflussen. Es ist möglich, dass ein Nutzer ohne Berechtigungen für einen Bucket über Berechtigungen für ein Objekt innerhalb dieses Buckets verfügt. Sie können beispielsweise einen Bucket erstellen, für den nur Gruppe A die Berechtigung erhält, die enthaltenen Objekte aufzulisten, aber dann ein Objekt in diesen Bucket hochladen und Gruppe B READ-Zugriff auf dieses Objekt gewähren. Auf diese Weise kann Gruppe B das Objekt lesen, aber weder den Inhalt des Buckets sehen noch auf den Bucket bezogene Aufgaben ausführen.

  • Das Zugriffssteuerungssystem von Cloud Storage bietet die Möglichkeit, bestimmte Objekte öffentlich lesbar zu machen. Sie sollten sich sehr sicher sein, dass Objekte, die Sie mit dieser Berechtigung schreiben, öffentlich verfügbar sein sollen. Sobald sie "veröffentlicht" wurden, können Daten im Internet an viele Orte kopiert werden. Daher ist es praktisch unmöglich, später die Kontrolle über den Lesezugriff auf ein Objekt wiederherzustellen, das mit dieser Berechtigung geschrieben wurde.

  • Das Zugriffssteuerungssystem von Cloud Storage bietet außerdem die Möglichkeit, für Buckets einen öffentlichen Schreibzugriff zu gewähren. Diese Bucket-Konfiguration kann zwar für verschiedene Zwecke nützlich sein, dennoch empfehlen wir, diese Berechtigung nicht zu verwenden. Sie kann missbraucht werden, um illegale Inhalte, Viren und andere Malware zu verbreiten. Der Bucket-Inhaber ist für die in seinen Buckets gespeicherten Inhalte rechtlich und finanziell verantwortlich.

    Wenn Sie Inhalte auf sichere Weise Nutzern zur Verfügung stellen möchten, die kein Google-Konto haben, sollten Sie signierte URLs verwenden. Mit signierten URLs können Sie zum Beispiel einen Link zu einem Objekt zur Verfügung stellen und die Nutzer Ihrer Anwendung müssen sich für den Zugriff auf dieses Objekt nicht bei Cloud Storage authentifizieren. Wenn Sie eine signierte URL erstellen, bestimmen Sie die Art (Lesen, Schreiben, Löschen) und die Dauer der Zugriffs.

  • Wenn Sie gsutil verwenden, sollten Sie sich diese zusätzlichen Empfehlungen ansehen.

Daten hochladen

  • Wenn Sie XHR-Rückrufe (XMLHttpRequest) verwenden, um Fortschrittsaktualisierungen zu erhalten, vermeiden Sie es, die Verbindung zu trennen und neu aufzubauen, wenn Sie feststellen, dass der Vorgang ins Stocken geraten ist. Auf diese Weise wird bei Netzwerküberlastung ein falsch positiver Feedback Loop generiert. Bei Netzwerküberlastung können XHR-Rückrufe hinter die Bestätigungsaktivität (ACK/NACK) aus dem Uploadstream zurückgestellt werden. Wird die Verbindung unter diesen Voraussetzungen getrennt und neu aufgebaut, wird genau in diesem Engpass noch mehr Netzwerkkapazität beansprucht.

  • Für Uploadtraffic wird empfohlen, ausreichende Zeitlimits einzurichten. Richten Sie für mehr Komfort für die Endnutzer einen clientseitigen Timer ein, der das Statusfenster des Clients mit einer Meldung aktualisiert (z. B. "Netzwerk überlastet"), wenn die Anwendung längere Zeit keinen XHR-Rückruf erhalten hat. Vermeiden Sie es, die Verbindung einfach zu trennen und es noch einmal zu versuchen, wenn dieses Problem auftritt.

  • Wenn Sie Compute Engine-Instanzen mit Prozessen verwenden, die POST-Anfragen an Cloud Storage senden, um fortsetzbare Uploads zu starten, müssen sich diese Compute Engine-Instanzen an denselben Standorten wie Ihre Cloud Storage-Buckets befinden. Dann können Sie einen Geo-IP-Dienst nutzen, um die Compute Engine-Region zu übernehmen, zu der Sie die Kundenanfragen weiterleiten. Auf diese Weise bleibt der Traffic innerhalb einer Region.

  • Bei fortsetzbaren Uploads sollte die fortsetzbare Sitzung in der Region bleiben, in der sie gestartet wurde. Auf diese Weise vermeiden Sie regionenübergreifenden Traffic beim Lesen und Schreiben des Sitzungsstatus, wodurch die Uploadleistung erheblich gesteigert wird.

  • Teilen Sie Übertragungen möglichst nicht in kleinere Teile auf, sondern laden Sie den gesamten Inhalt auf einmal hoch. Wenn Sie Inhalte nicht aufteilen, vermeiden Sie feste Latenzkosten, der Durchsatz wird verbessert und die Anfragen pro Sekunde an Cloud Storage werden reduziert.

    Einen Upload in Teilen hingegen könnten Sie erwägen, wenn Ihre Quelldaten dynamisch erstellt werden, wenn die Größe der Anfragen Ihrer Clients beschränkt ist, was auf viele Browser zutrifft, oder wenn Ihre Clients Byte erst mit einer einzelnen Anfrage streamen können, nachdem sie die gesamte Anfrage in den Speicher geladen haben. Wenn Ihre Clients eine Fehlermeldung erhalten, können sie mit einer Serverabfrage ein Commit-Offset anfordern und den Upload der verbleibenden Bytes aus diesem Offset fortsetzen.

  • Vermeiden Sie möglichst den Upload von Inhalten, bei denen sowohl content-encoding: gzip als auch ein content-type komprimiert sind, da dies zu unerwartetem Verhalten führen kann.

Daten löschen

Wenn Sie befürchten, dass Ihre Anwendungssoftware oder Nutzer zu einem bestimmten Zeitpunkt fälschlicherweise Objekte löschen oder überschreiben könnten, bietet Cloud Storage Funktionen zum Schutz Ihrer Daten:

  • Eine Aufbewahrungsrichtlinie, die eine Aufbewahrungsdauer angibt, kann auf einen Bucket angewendet werden. Ein Objekt im Bucket kann nicht gelöscht oder überschrieben werden, bevor das angegebene Alter erreicht ist.

  • Ein Objekt-Hold kann für einzelne Objekte festgelegt werden, um zu verhindern, dass jemand das Objekt löscht oder überschreibt, bevor der Hold entfernt wurde.

  • Objektversionierung kann für einen Bucket aktiviert werden, um ältere Versionen von Objekten beizubehalten, wenn sie gelöscht oder überschrieben werden. Objektversionierung erhöht die Speicherkosten. Dies kann jedoch teilweise gemindert werden, wenn Sie die Verwaltung des Objektlebenszyklus so konfigurieren, dass ältere Objektversionen gelöscht werden.

Objektauflistung

Wenn Sie gerade viele Objekte aus Ihrem Bucket gelöscht haben, kann sich die Objektauflistung vorübergehend deutlich verlangsamen. Dies liegt daran, dass die gelöschten Datensätze nicht sofort vom zugrunde liegenden Speichersystem gelöscht werden. Daher müssen bei der Objektauflistung die gelöschten Datensätze übersprungen werden, wenn die zurückzugebenden Objekte gefunden wurden.

Schließlich werden die gelöschten Datensätze aus dem zugrunde liegenden Speichersystem entfernt und die Objektauflistung erfolgt wieder mit normaler Geschwindigkeit. Dies dauert in der Regel mehrere Stunden, kann aber auch mehrere Tage dauern.

Planen Sie Ihre Arbeitslast so, dass die Auflistung eines Objektbereichs mit vielen kürzlich gelöschten Objekten vermieden wird. Beispiel: Sie möchten Objekte aus einem Bucket löschen, die Sie immer wieder auflisten und löschen. Verwenden Sie in diesem Fall für die nächste Auflistungsanfrage das als Antwort auf die Objektauflistung zurückgegebene Seitentoken. So ersparen Sie sich, die Auflistung bei jeder Anfrage von vorn zu beginnen. Wenn Sie die Auflistung von vorn beginnen, muss jede Anfrage alle kürzlich gelöschten Objekte überspringen. Dies verlangsamt die Objektauflistung. Wenn Sie viele Objekte unter einem bestimmten Präfix gelöscht haben, empfiehlt es sich daher, direkt nach dem Löschen möglichst keine Objekte darunter aufzulisten.

Websitehosting

Im Thema Cross-Origin Resource Sharing (CORS) wird erläutert, wie Sie auf anderen Websites gehosteten Skripts gestatten können, auf statische Ressourcen zuzugreifen, die in einem Cloud Storage-Bucket gespeichert sind. Umgekehrt können Sie Skripts, die in Cloud Storage gehostet sind, den Zugriff auf statische Ressourcen anderer Websites gestatten. Im letztgenannten Fall stellt die Website CORS-Header bereit, sodass den Inhalten von storage.googleapis.com Zugriff gewährt wird. Es wird empfohlen, für diesen Datenzugriff einen bestimmten Bucket zuzuweisen. Zum Beispiel ist es besser, wenn die Website den CORS-Header Access-Control-Allow-Origin: https://mybucket.storage.googleapis.com anstelle von Access-Control-Allow-Origin: https://storage.googleapis.com bereitstellt. Dadurch wird verhindert, dass Ihre Website statische Ressourcen versehentlich für alle Inhalte von storage.googleapis.com freigibt.

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...