このページでは、Cloud Healthcare API の割り当てを管理するためのベスト プラクティスについて説明します。このページは、Google Cloud プロジェクトに大量のトラフィックがある、またはその可能性があり、Cloud Healthcare API がデフォルトで提供するよりも多くの割り当てが必要な場合に使用してください。
Cloud Healthcare API のデフォルトの割り当て
デフォルトの Cloud Healthcare API の割り当ては、特に Google Cloud プロジェクトに大量のトラフィックがある場合に、すべてのユースケースに対して設計されてはいません。Cloud Healthcare API は割り当てを自動的に増やしません。割り当て使用量を計画してモニタリングする必要があります。
割り当てのモニタリングと表示に関するベスト プラクティス
割り当て使用量を表示する方法はいくつかあります。Cloud Healthcare API の割り当てを見積もったり確認したりする場合は、サービス割り当てモデルを使用することをおすすめします。このモデルを使用すると、次の基準に基づいて利用可能な割り当てを正確に評価できます。
- 管理者オーバーライドが存在するかどうか。組織で割り当て管理者ロールが付与されているプリンシパルは、組織内の Google Cloud プロジェクトの割り当てに管理者オーバーライドを適用できます。管理者オーバーライドは、デフォルトの上限とプロデューサー オーバーライドよりも優先されます。
プロデューサー オーバーライドが存在するかどうか。サービス オーナーは、サービスのコンシューマにプロデューサー オーバーライドを付与します。Google Cloud は Cloud Healthcare API サービスのサービス オーナーです。Google Cloud が提供する割り当てオーバーライドは、プロデューサー オーバーライドです。
コンシューマー オーバーライドが存在するかどうか。Cloud Healthcare API にリクエストする人は、Cloud Healthcare API サービスのコンシューマです。コンシューマ オーバーライドは、予算超過を防ぐためのコスト管理対策として Google Cloud プロジェクトの割り当てを制限するなど、さまざまな状況で適用できます。
これらのオーバーライドのいずれかが有効になっている場合は、ユーザー割り当て上限を計算して、使用可能な割り当ての正確な評価を得ることができます。
追加の割り当てをリクエストする際のベスト プラクティス
Google Cloud には、より多くの割り当てをリクエストする手順があります。割り当て増加リクエストを処理する方法については、割り当て増加リクエストについてをご覧ください。
追加の割り当てをリクエストする前に、次の両方を実装していることを確認してください。
次の理由から、これらの実装によって必要な割り当ての量が減る場合があります。
- どちらの実装も、負荷の急増を数秒間ではなく数時間または数分間に分散させます。
- どちらの実装も、24 時間の期間にわたって割り当てを効率的に使用します。デフォルトの割り当てを大幅に超えるリクエストが 24 時間の期間にわたって継続している場合、リソースのより大きなプールを Cloud Healthcare API サービスに割り当てることができます。リソースの追加の割り当ては、リクエストのみによって行われ、ケースバイケースで決定されます。
- リソース使用量が一貫しているため、Google Cloud が割り当て要件を理解し、必要な割り当てを提供することが簡単になります。
容量と割り当てを効果的に管理するには、組織の容量の要件を知る必要があります。容量の要件を計画していて、Google Cloud プロジェクトが本番環境にあるときに大幅な割り当ての増加が必要になると考える場合は、Google Cloud カスタマーケアに増加をリクエストしてください。カスタマーケアは、Google Cloud プロジェクトのテストフェーズとロールアウト フェーズの間の割り当てとその増加を支援できます。
割り当ての増加をリクエストするために、有料のカスタマーケア サービスは必要ありません。一部の割り当ての増加リクエストは 2 ～ 3 営業日以内に完了しますが、それ以上で計画することをおすすめします。割り当ての増加が大幅な場合、割り当ての増加が完了するまでに 10 営業日以上かかる可能性があります。計画の一環として、リクエストに関する質問と未解決の問題を解消するために、カスタマーケアに対応する割り当て時間を含む必要があります。最初の割り当て増加のリクエストが十分になるようにしたら、リクエストの完了を待つのに費やす時間を短縮できる場合があります。
割り当てニーズを予測するためのベスト プラクティス
Google Cloud プロジェクトを本番環境に移行する前に、必要な割り当て量を予測して計画します。割り当て要件を計画しておけば、後でリソースの使用量が予期せず制限されることはありません。
以降のセクションでは、割り当ての計画時に考慮することについて説明します。
すべてのデータストアとクライアントの合計使用量を予測する
Cloud Healthcare API のすべてのデータストア全体の合計使用量を把握し、Google Cloud プロジェクトにリクエストを行うすべてのクライアントの合計使用量を把握します。
- 一部の Google Cloud プロジェクトでは、複数の Cloud Healthcare API ユースケースを実装しています。たとえば、Google Cloud プロジェクトがさまざまな種類のデータに複数の Cloud Healthcare API データセットとデータストアを使用すると、合計割り当て使用量が増加する場合があります。
- 割り当ては、Google Cloud プロジェクトごととリージョンごとに適用されます。複数のリージョンにわたって必要な割り当てを正確に測定していることを確認します。複数の Google Cloud プロジェクトがある場合は、プロジェクト間でより正確な測定値が必要になる場合があります。リージョンごとの割り当ての計画について詳しくは、リージョンごとの使用量を予測するをご覧ください。
- Cloud Healthcare API は、クライアント、データセット、データストア間で割り当てをロード バランシングしません。クライアントは、最も重要なトラフィックが
429 RESOURCE_EXHAUSTEDエラーを起こさないように、優先順位付けスキームを実装するかどうかを決定する必要があります。
リージョンごとの使用量を予測する
Cloud Healthcare API は、Google Cloud プロジェクトごととリージョンごとに割り当てを測定します。通常、割り当ては 1 分ごとに測定されます。これにより、1 秒あたりのリクエストの急増が小規模になり、1 分単位のスケールで分散できます。
Google Cloud プロジェクトで複数のリージョンを使用する場合は、リージョンごとの割り当てを設定できます。
Cloud Healthcare API データセットが us マルチリージョン ロケーションにあり、追加の割り当てをリクエストする場合は、割り当てリクエスト内で、割り当ては「US メタ リージョン」向けと記載します。us マルチリージョン ロケーションは、次のサブリージョンで構成されています。
us-central1us-east1us-west1
us- サブリージョンのいずれかの割り当てを使用する Cloud Healthcare API トラフィックがすでにある場合は、us マルチリージョンに対する割り当て増加のリクエストを行う際には、それらのサブリージョンの既存のトラフィックを必ず考慮します。たとえば、us-central1 と us にデータセットがあり、us に割り当ての増加をリクエストする場合は、us-central1 にデータセットがあることをリクエストに明記します。
一貫性に基づいて少量のトランザクションを優先する
次のシナリオでは、大量のトランザクションをトランザクションの間隔をより長くして送信するのではなく、一貫性に基づいて少量のトラフィックを送信することの重要性について説明します。
トラフィックの量は、式 request payload * time = traffic volume を使用して計算されます。大量のトランザクションは、大きなペイロードを含む短い間隔で Cloud Healthcare API に対する 1 つ以上のリクエストです。ペイロード サイズに関係なく、短い間隔で多数のリクエストが送信される場合、一連のリクエストは大量とみなされる可能性もあります。
クライアントが大量のトランザクションを収集し、5 分ごとにバーストで Cloud Healthcare API にトランザクションを送信するとします。次のようになります。
- トラフィックの最初のバーストは、すべての割り当てが尽きるまで最初の 1 分間の割り当てを使用します（分単位のロールオーバーによります）。
- 残りのバースト トラフィックは
429 RESOURCE_EXHAUSTEDエラーを受け取ります。構成すると、影響を受けるすべてのリクエストに指数バックオフが発生します。 - 最初の指数バックオフが発生したリクエストの一部は、次の 1 分間に再試行されるように再スケジュールされます。一部のリクエストは 1 分間に複数回試行され、次の 1 分間で再試行されます。
- リクエストの量が十分に大きい場合、再試行したリクエストでは再び
429 RESOURCE_EXHAUSTEDエラーが発生し、指数バックオフが発生する場合があります。特定のトラフィックのバーストは、指数関数的バックオフを異なるタイミングで発生させる場合があります。また、トラフィックを再度送信しようとする試みは、今後同じ分内に収束する場合があります。 - 依然としてリクエスト量が多い場合は、一部のトラフィックが次のトラフィックのバーストが始まると再試行されます。より多くのトラフィックがリクエストの既存のバックログに追加されるため、この問題は悪化します。アプリケーションでリクエストのバックログを維持し、一貫して Cloud Healthcare API に送信するのが難しい場合があります。
このシナリオでは、1 分単位でトラフィックの量を把握することの重要性を示しています。トラフィック量とバックオフを実装して、ネットワークの輻輳を防ぎ、再試行が必要な障害が発生しないようにします。
DICOM と FHIR の割り当てを確認する
FHIR ストアと DICOM ストアとオペレーションに関連付けられた Cloud Healthcare API の割り当てを表示するには、割り当ての上限をご覧ください。