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 Cloud Storage zum ersten Mal verwenden, empfehlen wir Ihnen, mit Kurzanleitung: Console verwenden oder Kurzanleitung: gsutil-Tool verwenden zu beginnen.

Benennung

  • Informationen zu den Anforderungen und Überlegungen für Namen finden Sie in den Themen Benennungsrichtlinien für Buckets und Benennungsrichtlinien für Objekte.

  • Wenn Sie viele Buckets benötigen, verwenden Sie GUIDs oder eine Entsprechung für Bucket-Namen, fügen Sie eine Wiederholungslogik in Ihren Code ein, um Namenskollisionen zu handhaben, und führen Sie eine Liste mit Querverweisen auf die 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 personenidentifizierbare Informationen in Ihre Objektnamen aufnehmen, da die Objektnamen Bestandteil der Objekt-URLs sind.

  • Vermeiden Sie sequenzielle Dateinamen wie zeitstempelbasierte Dateinamen, wenn Sie viele Dateien parallel hochladen. Dateien mit sequenziellen Namen werden nacheinander gespeichert, sodass sie wahrscheinlich zum selben Back-End-Server gelangen. In diesem Fall wird der Durchsatz begrenzt. Um einen optimalen Durchsatz zu erzielen, fügen Sie den Hash der Sequenznummer als Teil des Dateinamens hinzu, damit dieser nicht sequenziell ist. Weitere Informationen finden Sie unter Richtlinien für die Anforderungsrate und Zugriffsverteilung.

Traffic

  • Führen Sie eine Überschlagsschätzung des Trafficaufkommens 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 Trafficspitzen auf ein Minimum reduziert werden. Wenn es in der Anwendung Clients gibt, die Aktualisierungen ausfü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:

    • Verwenden Sie den exponentiellen Backoff als Teil Ihrer Wiederholungsstrategie, um Probleme aufgrund hoher Trafficspitzen zu vermeiden.

    • Wiederholen Sie den Vorgang mit einer neuen Verbindung und lösen Sie den Domainnamen eventuell noch einmal auf. Dadurch wird eine "Server Stickiness" vermieden, bei der wiederholt versucht wird, über denselben Pfad zu laufen, und dieselbe fehlerhafte Komponente wie bei der ersten Anfrage durchlaufen wird.

  • Wenn Ihre Anwendung latenzabhängig ist, sollten Sie abgesicherte Anfragen verwenden. Mit abgesicherten Anfragen können Sie den Vorgang schneller wiederholen und die Extremwertlatenz verringern. Hierbei wird die Frist für Anfragen allerdings nicht verkürzt, was dazu führen kann, dass Anfragen vorzeitig ablaufen. Weitere Informationen finden Sie unter https://www2.cs.duke.edu/courses/cps296.4/fall13/838-CloudPapers/dean_longtail.pdf.

  • 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, Coldline Storage oder Archive 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.

  • 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 Account Permissions an, klicken Sie auf die nicht benötigten Anwendungen und dann auf Remove Access.

  • 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 Nutzern, die kein Google-Konto haben, Inhalte auf sichere Weise zur Verfügung stellen möchten, sollten Sie signierte URLs verwenden. Mit signierten URLs können Sie zum Beispiel einen Link zu einem Objekt bereitstellen 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 den Typ (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 stagniert 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 einen fortsetzbaren Upload zu starten, sollten sich diese Compute Engine-Instanzen an denselben Standorten befinden wie Ihre Cloud Storage-Buckets. Sie können dann einen Geo-IP-Dienst nutzen, um die Compute Engine-Region zu übernehmen, an die Sie die Kundenanfragen weiterleiten. Auf diese Weise bleibt der Traffic innerhalb der 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 könnten Sie hingegen 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 Byte 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. Gleichzeitig erhöht Objektversionierung die Speicherkosten. Dies kann jedoch teilweise ausgeglichen werden, wenn Sie die Verwaltung des Objektlebenszyklus so konfigurieren, dass ältere Objektversionen gelöscht werden.

  • Wenn Sie mehrere Hunderttausend Objekte im Bulk löschen möchten, sollten Sie gsutil nicht verwenden, da der Vorgang sehr lange dauert. Wählen Sie stattdessen eine der folgenden Optionen:

    • Die Cloud Console kann im Hintergrund bis zu mehrere Millionen Objekte im Bulk löschen. Mit der Cloud Console können Sie auch nur Objekte mit gemeinsamen Präfixen im Bulk löschen. Diese Objekte werden bei Verwendung der Cloud Console als Teil eines Ordners angezeigt.

    • Die Verwaltung des Objektlebenszyklus kann eine beliebige Anzahl von Objekten im Bulk löschen. Wenn Sie Objekte in Ihrem Bucket im Bulk löschen möchten, legen Sie eine Regel für die Lebenszykluskonfiguration im Bucket fest, wobei Age auf 0 Tage und die Aktion auf Delete festgelegt ist. Beachten Sie, dass dies während des Löschvorgangs Auswirkungen auf die Objektliste für den jeweiligen Bucket haben kann.

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 gesucht werden.

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.

Als Best Practice sollten Sie für diesen Datenzugriff einen bestimmten Bucket zuweisen. Dadurch wird verhindert, dass die Website statische Ressourcen versehentlich für alle Inhalte von storage.googleapis.com freigibt. Wenn Sie beispielsweise einen Bucket namens mybucket für den Datenzugriff zuweisen möchten, sollte die Website den CORS-Header Access-Control-Allow-Origin: https://mybucket.storage.googleapis.com statt Access-Control-Allow-Origin: https://storage.googleapis.com bereitstellen.