Auf dieser Seite werden Best Practices zum Verwalten von Cloud Healthcare API-Kontingenten beschrieben. Verwenden Sie diese Seite, wenn Ihr Google Cloud-Projekt eine große Traffic-Menge hat oder haben könnte und Sie ein höheres Kontingent benötigen, als die Cloud Healthcare API standardmäßig bereitstellt.
Standardkontingente für die Cloud Healthcare API
Die Cloud Healthcare API-Standardkontingente sind nicht für alle Anwendungsfälle vorgesehen, insbesondere wenn Ihr Google Cloud-Projekt viel Traffic hat. Die Cloud Healthcare API erhöht das Kontingent nicht automatisch. Sie müssen Ihre Kontingentnutzung planen und überwachen.
Best Practices zum Überwachen und Aufrufen von Kontingenten
Es gibt mehrere Möglichkeiten, Ihre Kontingentnutzung aufzurufen. Zum Schätzen und Anzeigen von Kontingenten für die Cloud Healthcare API empfehlen wir die Verwendung des Dienstkontingentmodells. Mit diesem Modell können Sie Ihr verfügbares Kontingent anhand der folgenden Kriterien genau einschätzen:
- Gibt an, ob eine Administratorüberschreibung vorhanden ist. Ein Hauptkonto, dem die Rolle Kontingentadministrator in einer Organisation zugewiesen ist, kann eine Administratorüberschreibung auf Kontingente in Google Cloud-Projekten innerhalb der Organisation anwenden. Die Überschreibung durch den Administrator hebt die Standardlimits und die Überschreibung durch den Hersteller auf.
Gibt an, ob eine Überschreibung durch den Hersteller vorhanden ist. Ein Dienstinhaber erteilt dem Nutzer eines Dienstes eine Überschreibung durch den Hersteller. Google Cloud ist der Dienstinhaber des Cloud Healthcare API-Dienstes. Jede von Google Cloud bereitgestellte Kontingentüberschreibung wird durch den Hersteller überschrieben.
Gibt an, ob eine Überschreibung durch den Nutzer vorhanden ist. Eine Person, die Anfragen an die Cloud Healthcare API sendet, ist ein Nutzer des Cloud Healthcare API-Dienstes. Sie können Überschreibungen durch Nutzer in verschiedenen Situationen anwenden, z. B. um Kontingente in Ihrem Google Cloud-Projekt als Maßnahme zur Kostenkontrolle zu begrenzen, um eine Überschreitung Ihres Budgets zu verhindern.
Wenn eine dieser Überschreibungen wirksam ist, können Sie Ihr Nutzerkontingentlimit berechnen, um eine präzise Einschätzung des verfügbaren Kontingents zu erhalten.
Best Practices zum Anfordern zusätzlicher Kontingente
In Google Cloud gibt es Verfahren, mit denen Sie höhere Kontingente anfordern können. Informationen dazu, wie Anfragen zur Kontingenterhöhung verarbeitet werden, finden Sie unter Informationen zu Anfragen zur Kontingenterhöhung.
Bevor Sie ein zusätzliches Kontingent anfordern, müssen Sie Folgendes implementiert haben:
Diese Implementierungen können aus folgenden Gründen das Kontingent reduzieren, das Sie benötigen:
- Beide Implementierungen verteilen Lastspitzen über mehrere Stunden oder Minuten statt über Sekunden hinweg.
- Beide Implementierungen nutzen das Kontingent effizient über einen Zeitraum von 24 Stunden. Wenn Anfragen, die das Standardkontingent deutlich überschreiten, über einen Zeitraum von 24 Stunden hinweg konsistent sind, können dem Cloud Healthcare API-Dienst größere Ressourcenpools zugewiesen werden. Die zusätzliche Zuweisung von Ressourcen erfolgt nur auf Anfrage und wird von Fall zu Fall entschieden.
- Eine konstante Ressourcennutzung macht es Google Cloud leichter, Ihre Kontingentanforderungen zu verstehen und Ihnen das benötigte Kontingent zur Verfügung zu stellen.
Damit Sie Ihre Kapazität und Ihr Kontingent effektiv verwalten können, müssen Sie die Kapazitätsanforderungen Ihrer Organisation kennen. Wenn Sie Ihre Kapazitätsanforderungen planen und glauben, dass Sie in der Produktionsphase Ihres Google Cloud-Projekts eine große Kontingenterhöhung benötigen, beantragen Sie bei Google Cloud Customer Care eine Erhöhung. Customer Care kann Sie während der Test- und Roll-out-Phase Ihres Google Cloud-Projekts beim Zuweisen und Erhöhen von Kontingenten unterstützen.
Sie benötigen keinen kostenpflichtigen Kundendienst, um eine Kontingenterhöhung anzufordern. Einige Anfragen zur Kontingenterhöhung werden innerhalb von zwei bis drei Werktagen abgeschlossen. Wir empfehlen jedoch, länger einzuplanen. Bei einer großen Kontingenterhöhung kann es 10 Arbeitstage oder länger dauern, bis die Anfrage abgeschlossen ist. Im Rahmen Ihrer Planung müssen Sie Zeit für die Beantwortung von Fragen oder offenen Problemen im Zusammenhang mit der Anfrage einplanen. Wenn Sie dafür sorgen, dass Ihre ursprüngliche Anfrage zur Kontingenterhöhung ausreichend detailliert ist, können Sie möglicherweise die Zeit verkürzen, die Sie für die Bearbeitung der Anfrage aufwenden müssen.
Best Practices zur Vorhersage von Kontingentanforderungen
Bevor Ihr Google Cloud-Projekt in Betrieb genommen wird, sollten Sie voraussagen und planen, wie viel Kontingent Sie benötigen. Wenn Sie Ihre Kontingentanforderungen planen, können Sie später eine unerwartete Begrenzung Ihres Ressourcenverbrauchs vermeiden.
In den folgenden Abschnitten wird erläutert, was bei der Planung von Kontingenten zu beachten ist.
Gesamtnutzung für alle Datenspeicher und Clients prognostizieren
Hier erhalten Sie Informationen zur Gesamtnutzung aller Datenspeicher der Cloud Healthcare API und zur Gesamtnutzung aller Clients, die Anfragen an Ihr Google Cloud-Projekt senden.
- In einigen Google Cloud-Projekten sind mehrere Cloud Healthcare API-Anwendungsfälle implementiert. Beispielsweise kann Ihr Google Cloud-Projekt mehrere Cloud Healthcare API-Datasets und -Datenspeicher für verschiedene Datentypen verwenden, wodurch Ihre Gesamtkontingentnutzung erhöht wird.
- Kontingente werden pro Google Cloud-Projekt und Region erzwungen. Sorgen Sie dafür, dass Sie Ihr erforderliches Kontingent in mehreren Regionen präzise messen. Wenn Sie mehrere Google Cloud-Projekte haben, benötigen Sie möglicherweise genauere Messungen für alle Projekte. Weitere Informationen zur Planung des Kontingents pro Region finden Sie unter Nutzung pro Region voraussagen.
- Die Cloud Healthcare API führt kein Load-Balancing von Kontingenten zwischen Clients, Datasets oder Datenspeichern durch. Der Client muss bestimmen, ob ein Priorisierungsschema implementiert werden soll, damit der kritischste Traffic keine
429 RESOURCE_EXHAUSTED
-Fehler verursacht.
Nutzung pro Region voraussagen
Die Cloud Healthcare API misst Kontingente pro Google Cloud-Projekt und pro Region. Kontingente werden in der Regel pro Minute gemessen. Dadurch können kleine Spitzen von Anfragen pro Sekunde auf Minutenbasis ausgeglichen werden.
Wenn Ihr Google Cloud-Projekt mehrere Regionen verwendet, können Sie Kontingente pro Region festlegen.
Wenn sich Ihr Cloud Healthcare API-Dataset am multiregionalen Standort us
befindet und Sie ein zusätzliches Kontingent anfordern möchten, geben Sie in Ihrer Kontingentanfrage an, dass das Kontingent für die US-Metaregion gilt. Der multiregionale Standort us
besteht aus den folgenden Unterregionen:
us-central1
us-east1
us-west1
Wenn Sie bereits Cloud Healthcare API-Traffic in einer der us-
-Unterregionen verwenden, müssen Sie den vorhandenen Traffic in diesen Unterregionen berücksichtigen, wenn Sie eine Kontingenterhöhung für den multiregionalen Standort us
beantragen.
Wenn Sie beispielsweise Datasets in us-central1
und us
haben und eine Kontingenterhöhung in us
anfordern, geben Sie in Ihrer Anfrage an, dass Datasets in us-central1
vorhanden sind.
Regelmäßige Bevorzugung von Transaktionen mit geringem Volumen
Im folgenden Szenario wird erläutert, wie wichtig es ist, kleinere Traffic-Mengen regelmäßig zu senden, anstatt Transaktionen mit hohem Volumen mit einem längeren Intervall zwischen den Transaktionen zu senden.
Das Traffic-Volumen wird mit der Formel request payload * time = traffic volume
berechnet.
Eine Transaktion mit hohem Volumen ist eine oder mehrere Anfragen an die Cloud Healthcare API in einem kurzen Intervall, die eine große Nutzlast enthalten.
Eine Reihe von Anfragen kann auch als hohes Volumen angesehen werden, wenn unabhängig von der Größe der Nutzlast viele Anfragen in einem kurzen Intervall gesendet werden.
Angenommen, ein Client erfasst Transaktionen mit hohem Volumen und sendet die Transaktionen alle fünf Minuten zeitweise an die Cloud Healthcare API. Folgendes geschieht:
- Der anfängliche Traffic-Burst verbraucht in der ersten Minute (abhängig von minutenbasierten Überschlägen) das Kontingent, bis das gesamte Kontingent erschöpft ist.
- Der verbleibende Burst-Traffic erhält
429 RESOURCE_EXHAUSTED
-Fehler. Wenn die Richtlinie konfiguriert ist, treten bei allen betroffenen Anfragen exponentielle Backoffs auf. - Ein Teil der Anfragen, bei denen der anfängliche exponentielle Backoff aufgetreten ist, werden so geplant, dass sie in der nächsten Minute noch einmal wiederholt werden. Einige Anfragen werden mehrmals innerhalb einer Minute wiederholt und in der nächsten Minute wiederholt.
- Wenn das Anfragevolumen hoch genug ist, können bei wiederholten Anfragen
429 RESOURCE_EXHAUSTED
-Fehler und ein erneuter exponentieller Backoff auftreten. Bei bestimmten Traffic-Bursts kann ein exponentieller Backoff zu verschiedenen Zeiten auftreten und die Versuche, den Traffic noch einmal zu senden, können in der gleichen Minute in der Zukunft konvergieren. - Wenn das Anfragevolumen noch hoch ist, wird ein Teil des Traffics noch einmal versucht, wenn der nächste Traffic-Burst beginnt. Das Problem verschärft sich, da dem bestehenden Rückstand von Anfragen mehr Traffic hinzugefügt wird. Ihre Anwendung kann Schwierigkeiten haben, den Rückstand von Anfragen zu verwalten und sie konsistent an die Cloud Healthcare API zu senden.
Dieses Szenario zeigt, wie wichtig es ist, das Traffic-Volumen pro Minute zu kennen. Implementieren Sie das Trafficvolumen und die Backoffs, um eine Netzwerküberlastung zu vermeiden und dafür zu sorgen, dass in Ihrer Anwendung nicht viele Fehler auftreten, die Wiederholungsversuche erfordern.
DICOM- und FHIR-Kontingente überprüfen
Informationen zum Ansehen der Cloud Healthcare API-Kontingente für FHIR- und DICOM-Speicher und -Vorgänge finden Sie unter Kontingentlimits.
Ressourcen für die Kontingentverwaltung
Weitere Informationen zum Planen und Verwalten von Kontingenten finden Sie unter Kapazität und Kontingente verwalten.