Best Practices für die Kontingentverwaltung

Auf dieser Seite werden Best Practices für die Verwaltung des Cloud Healthcare API-Kontingents beschrieben. Verwenden Sie diese Seite, wenn Ihr Google Cloud-Projekt einen hohen Traffic hat oder haben könnte und Sie ein größeres Kontingent benötigen als das, das standardmäßig von der Cloud Healthcare API bereitgestellt wird.

Standardkontingente der Cloud Healthcare API

Die Standardkontingente für die Cloud Healthcare API sind nicht für alle Anwendungsfälle geeignet, insbesondere wenn Ihr Google Cloud-Projekt einen hohen Traffic hat. Das Kontingent wird von der Cloud Healthcare API nicht automatisch erhöht. Sie müssen Ihre Kontingentnutzung planen und im Blick behalten.

Best Practices für die Überwachung und Anzeige des Kontingents

Es gibt mehrere Möglichkeiten, die Kontingentnutzung aufzurufen. Wenn Sie das Kontingent für die Cloud Healthcare API schätzen und ansehen möchten, empfehlen wir Ihnen, das Modell für Dienstkontingente zu verwenden. Mit dem Modell können Sie Ihr verfügbares Kontingent anhand der folgenden Kriterien genau bewerten:

  • Gibt an, ob eine Administratorüberschreibung vorhanden ist. Ein Hauptkonto, dem die Rolle Kontingentadministrator in einer Organisation zugewiesen wurde, kann eine Überschreibung durch den Administrator auf das Kontingent in Google Cloud-Projekten innerhalb der Organisation anwenden. Eine Überschreibung durch den Administrator ersetzt Standardlimits und Überschreibungen durch den Ersteller.

  • Gibt an, ob eine Überschreibung durch den Ersteller vorhanden ist. Ein Diensteigner gewährt einem Nutzer eines Dienstes eine Überschreibung durch den Ersteller. Google Cloud ist der Dienstinhaber des Cloud Healthcare API-Dienstes. Alle von Google Cloud bereitgestellten Kontingentüberschreitungen sind Produzentenüberschreitungen.

  • Ob eine Überschreibung durch Nutzer vorliegt. Nutzer, die Anfragen an die Cloud Healthcare API senden, sind Nutzer des Cloud Healthcare API-Dienstes. Sie können Überschreibungen durch den Nutzer in verschiedenen Situationen anwenden, z. B. um Kontingente in Ihrem Google Cloud-Projekt als Kostenkontrollmaßnahme zu begrenzen und so ein Überschreiten Ihres Budgets zu verhindern.

Wenn eine dieser Überschreibungen aktiv ist, können Sie das Limit für Ihr Nutzerkontingent berechnen, um eine genaue Einschätzung Ihres verfügbaren Kontingents zu erhalten.

Best Practices für das Anfordern eines zusätzlichen Kontingents

Bei Google Cloud gibt es Verfahren, um ein höheres Kontingent anzufordern. Weitere Informationen zur Bearbeitung von Anfragen zur Kontingenterhöhung finden Sie unter Anfragen zur Kontingenterhöhung.

Bevor Sie ein zusätzliches Kontingent beantragen, müssen Sie Folgendes implementiert haben:

Durch diese Implementierungen kann das erforderliche Kontingent aus folgenden Gründen reduziert werden:

  • Bei beiden Implementierungen werden Lastspitzen über mehrere Stunden oder Minuten statt über Sekunden verteilt.
  • Bei beiden Implementierungen wird das Kontingent über einen Zeitraum von 24 Stunden effizient genutzt. Wenn Anfragen, die das Standardkontingent deutlich überschreiten, über einen Zeitraum von 24 Stunden hinweg konstant sind, können dem Cloud Healthcare API-Dienst größere Ressourcenpools zugewiesen werden. Die zusätzliche Ressourcenzuweisung erfolgt nur auf Anfrage und wird von Fall zu Fall entschieden.
  • Eine gleichbleibende Ressourcennutzung erleichtert es Google Cloud, Ihre Kontingentanforderungen zu verstehen und Ihnen das erforderliche Kontingent zur Verfügung zu stellen.

Um Ihre Kapazität und Ihr Kontingent effizient verwalten zu können, müssen Sie die Kapazitätsanforderungen Ihrer Organisation kennen. Wenn Sie Ihre Kapazitätsanforderungen planen und der Meinung sind, dass Sie in der Produktionsphase Ihres Google Cloud-Projekts eine große Kontingenterhöhung benötigen, fordern Sie eine Erhöhung beim Google Cloud Customer Care an. Customer Care kann Ihnen bei der Zuweisung und Erhöhung des Kontingents während der Test- und Einführungsphase Ihres Google Cloud-Projekts helfen.

Sie benötigen keinen kostenpflichtigen Kundendienst, um eine Kontingenterhöhung anzufordern. Einige Anfragen zur Kontingenterhöhung werden innerhalb von 2–3 Arbeitstagen abgeschlossen. Wir empfehlen Ihnen jedoch, mehr Zeit einzuplanen. Bei einer großen Kontingenterhöhung kann es zehn Arbeitstage oder länger dauern, bis der Antrag bearbeitet ist. Ein Teil Ihrer Planung muss die Zeit umfassen, die Sie für die Beantwortung von Fragen des Kundensupports benötigen, um alle Fragen zu beantworten oder offene Probleme im Zusammenhang mit der Anfrage zu lösen. Wenn Sie dafür sorgen, dass Ihr ursprünglicher Antrag auf Kontingenterhöhung ausreichend detailliert ist, können Sie die Wartezeit auf die Bearbeitung des Antrags möglicherweise verkürzen.

Best Practices für die Bedarfsplanung für Kontingente

Bevor Ihr Google Cloud-Projekt in die Produktion geht, sollten Sie das erforderliche Kontingent abschätzen und planen. Wenn Sie Ihre Kontingentanforderungen planen, können Sie unerwartete Einschränkungen bei der Ressourcennutzung vermeiden.

In den folgenden Abschnitten wird erläutert, was Sie bei der Planung des Kontingents beachten sollten.

Gesamtnutzung für alle Datenspeicher und ‑clients vorhersagen

Sie können die Gesamtnutzung aller Cloud Healthcare API-Datenspeicher und die Gesamtnutzung aller Clients abrufen, die Anfragen an Ihr Google Cloud-Projekt senden.

  • Einige Google Cloud-Projekte implementieren mehrere Anwendungsfälle für die Cloud Healthcare API. In Ihrem Google Cloud-Projekt werden beispielsweise möglicherweise mehrere Cloud Healthcare API-Datasets und -Speicher für verschiedene Datentypen verwendet, wodurch die Gesamtnutzung des Kontingents steigt.
  • Kontingente werden pro Google Cloud-Projekt und pro Region erzwungen. Achten Sie darauf, dass Sie Ihr erforderliches Kontingent in mehreren Regionen genau messen. Wenn Sie mehrere Google Cloud-Projekte haben, benötigen Sie möglicherweise genauere Messungen für alle Projekte. Weitere Informationen zur Planung von Kontingenten pro Region finden Sie unter Nutzung pro Region vorhersagen.
  • Die Cloud Healthcare API verteilt das Kontingent nicht auf Clients, Datensätze oder Datenspeicher. Der Kunde muss entscheiden, ob er ein Priorisierungsschema implementieren möchte, damit beim kritischsten Traffic keine 429 RESOURCE_EXHAUSTED-Fehler auftreten.

Nutzung pro Region vorhersagen

Die Cloud Healthcare API misst Kontingente pro Google Cloud-Projekt und pro Region. Kontingente werden in der Regel pro Minute gemessen. So können kleine Spitzen bei den Anfragen pro Sekunde auf Minutenbasis ausgeglichen werden.

Wenn in Ihrem Google Cloud-Projekt mehrere Regionen verwendet werden, können Sie regionale Kontingente 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 Ihrem Kontingentantrag an, dass das Kontingent für die „Metaregion USA“ 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 nutzen, müssen Sie den vorhandenen Traffic in diesen Unterregionen berücksichtigen, wenn Sie eine Kontingenterhöhung für die us-Region beantragen. Wenn Sie beispielsweise Datasets in us-central1 und us haben und eine Kontingenterhöhung in us beantragen, geben Sie in Ihrer Anfrage an, dass Sie Datasets in us-central1 haben.

Transaktionen mit geringem Volumen sollten regelmäßig bevorzugt werden

Im folgenden Szenario wird erläutert, warum es wichtig ist, regelmäßig kleinere Datenmengen zu senden, anstatt Transaktionen mit hohem Volumen mit einem längeren Intervall zwischen den Transaktionen zu senden.

Der Traffic-Volumen wird mit der Formel request payload * time = traffic volume berechnet. Eine Transaktion mit hohem Volumen besteht aus einer oder mehreren Anfragen an die Cloud Healthcare API in einem kurzen Intervall, die eine große Nutzlast enthalten. Eine Reihe von Anfragen kann auch als hochvolumig eingestuft werden, wenn viele Anfragen in einem kurzen Intervall gesendet werden, unabhängig von der Nutzlastgröße.

Angenommen, ein Client erfasst Transaktionen in großem Umfang und sendet sie alle fünf Minuten in einem Burst an die Cloud Healthcare API. Folgendes geschieht:

  1. Der anfängliche Trafficanstieg verbraucht das Kontingent in der ersten Minute (je nach Minutenübergang), bis es aufgebraucht ist.
  2. Für den verbleibenden Burst-Traffic werden 429 RESOURCE_EXHAUSTED-Fehler ausgegeben. Wenn diese Funktion konfiguriert ist, wird für alle betroffenen Anfragen ein exponentieller Backoff angewendet.
  3. Ein bestimmter Prozentsatz der Anfragen, bei denen das ursprüngliche exponentielle Backoff aufgetreten ist, wird neu geplant und in der nächsten Minute noch einmal versucht. Einige Anfragen werden innerhalb einer Minute mehrmals versucht und dann in der nächsten Minute noch einmal.
  4. Wenn das Anfragevolumen hoch genug ist, kann es bei wiederholten Anfragen zu 429 RESOURCE_EXHAUSTED-Fehlern und wieder zu einem exponentiellen Backoff kommen. Bei bestimmten Traffic-Spitzen kann es zu unterschiedlichen Zeiten zu einem exponentiellen Backoff kommen und die Versuche, wieder Traffic zu senden, können in Zukunft in derselben Minute zusammenfallen.
  5. Wenn das Anfragevolumen weiterhin hoch ist, wird ein Teil des Traffics bei Beginn der nächsten Traffic-Spitzen wieder versucht. Das Problem wird dadurch verschärft, dass dem bestehenden Rückstau an Anfragen mehr Traffic hinzugefügt wird. Ihre Anwendung hat möglicherweise Schwierigkeiten, den Rückstau an Anfragen zu bewältigen und sie regelmäßig an die Cloud Healthcare API zu senden.

Dieses Szenario zeigt, wie wichtig es ist, das Volumen Ihres Traffics pro Minute zu kennen. Implementieren Sie Ihr Traffic-Volumen und Backoffs, um Netzwerküberlastungen zu vermeiden und dafür zu sorgen, dass Ihre Anwendung nicht häufig Fehler auftritt, die Neuversuche erfordern.

DICOM- und FHIR-Kontingente prüfen

Informationen zu den Cloud Healthcare API-Kontingenten für FHIR- und DICOM-Speicher und ‑Vorgänge finden Sie unter Kontingentlimits.