このページでは、Cloud Healthcare API にデータを取り込む際にデータ スループットを最適化するためのベスト プラクティスについて説明します。これらの推奨事項は、大規模なシステムのデータ スループットの管理経験を持つ技術者を対象としています。
データ スループット
データ スループットは、FHIR リソースや DICOM インスタンスなどのリソースの量。または、Cloud Healthcare API が 1 秒ごとに取り込むバイト数です。
データ スループットの制約
データ スループットが制限される理由は次のとおりです。
- トラフィックの急増の原因となる大量のリクエストを計画していない。
- 帯域幅の制約により、短時間で送信される大量のデータの取り込みが遅くなります。
- 複数の同時トランザクションで同じ Cloud Healthcare API リソースが変更されるため、データ競合が発生します。
- 小さいリクエストの数が多すぎる。詳細については、小規模なインポートとエクスポートのリクエストを回避するをご覧ください。
- 同時に実行される長時間実行オペレーション(LRO)が多すぎるため、帯域幅が制限されます。
- 同時にスケジュール設定される LRO が多すぎると、エラーが発生します。
失敗したリクエストの再試行
障害発生後にクライアントが迅速かつ繰り返しリクエストを再試行すると、Cloud Healthcare API の割り当てを超える可能性があります。以下のセクションでは、失敗したリクエストを効率的に再試行する方法について説明します。
ジッターと永続的な再試行キューで指数バックオフを使用する
ジッターを伴う指数バックオフは、ネットワーク アプリケーションの標準的なエラー処理方法です。クライアントは、失敗したリクエストを定期的に再試行し、再試行間の遅延は指数関数的に増加し、小規模でランダムな遅延が発生します。
再試行のたびに指数バックオフの実装がべき等であることを確認します。特に、障害ロジックをバイパスするためにカスタム ロジックを使用している場合はその限りではありません。詳細については、HTTP 仕様の 9.2.2 べき等メソッドをご覧ください。
ほとんどのプログラミング言語には、指数バックオフなどの再試行戦略の実装を簡素化するライブラリが用意されています。長期またはマルチプロセスの再試行の場合は、永続再試行キューを実装します。このキューは、最大バックオフ時間を超えると再試行メカニズムをリセットできます。
これらのリクエストを再試行する際には、指数バックオフを使用します。
- FHIR リソースまたは FHIR リソースのバンドルを変更するオペレーション。
同期 LRO リクエスト。LRO の開始時にエラーが発生した場合や、LRO が失敗した場合に再試行します。
LRO には固有のエラーがあるため、次の再試行戦略の実装が必要になる場合があります。
- インポートまたは作成オペレーションが失敗した場合にデータを保存するには、別のバンドルを使用します。
- 処理に失敗したデータの同期リクエストを使用します。
指数バックオフ アルゴリズムの例
指数バックオフのアルゴリズムは、再試行の待ち時間の間隔を最大バックオフ時間まで増加させながら、指数関数的にリクエストを再試行します。次のアルゴリズムは、ジッターを伴う切り捨て型指数バックオフを実装しています。
Cloud Healthcare API にリクエストを送信します。
リクエストが失敗した場合、1 +
random-fraction
秒待ってから、リクエストを再試行します。リクエストが失敗した場合、2 +
random-fraction
秒待ってから、リクエストを再試行します。リクエストが失敗した場合、4 +
random-fraction
秒待ってから、リクエストを再試行します。再試行のたびに 2n +
random-fraction
秒待機します。このパターンを最大でmaximum-backoff
時間まで繰り返します。deadline
秒後に、リクエストの再試行を停止します。
アルゴリズムを実装するときに以下の値を使用します。
各再試行までの待機時間は
min((2n + random-fraction), maximum-backoff)
です。n
は 0 から始まり、再試行のたびに 1 ずつ増えます。random-fraction
は、1 以下のランダムな小数値に置き換えます。再試行ごとに異なる値を使用します。このランダムな値を追加すると、クライアントの同期と多数の再試行を同時に送信できなくなります。maximum-backoff
は、再試行の最大待機時間(秒数)に置き換えます。通常の値は 32 秒または 64 秒(25 または 26)です。ユースケースに適した値を選択してください。deadline
は、再試行を持続する最大秒数に置き換えます。ユースケースに適した値を選択してください。
クライアントは、バックオフと同じ値を使用して maximum-backoff
時間に達した後に再試行できます。たとえば、maximum-backoff
時間が 64 秒の場合、64 秒ごとに再試行します。クライアントが無期限に再試行しないようにします。
トラフィック シェーピングによってクライアント側のレート制限を実装する
レート制限は、過剰なリクエストによる過負荷を防ぐために、大規模なシステムを保護します。クライアント側レート制限が十分でない場合、Cloud Healthcare API 割り当てシステムはデータ スループットを制限することがあります。詳細については、割り当て管理のベスト プラクティスをご覧ください。
再試行間の配信の保証など、追加の要件がある場合は、失敗したリクエストを再試行する方法では不十分なことがあります。 トラフィック シェーピングは、クライアント側のリクエストのレートを帯域幅の制約内に限定するレート制限手法です。これにより、負荷の急増が数時間または数分に分散し、スループットが向上します。割り当てが制約されている場合、トラフィック シェーピングはプッシュバックを回避し、ワーカー単位を追跡するため、再試行のみを使用する場合よりもスループットが高くなります。
fhir.executeBundle
など、同期作成、削除、更新、削除(CRUD)オペレーション用にトラフィック シェーピングを実装できます。
トラフィック シェーピングの要件
トラフィック シェーピングを実装するには、システムで以下を実装する必要があります。
- ディスク障害を回避するための冗長性を備えたストレージ格納型の処理キュー。
- 処理キューから pull する調整されたワーカー。
- 全体的に検出を使用して、割り当て制限に基づいてワーカー数とその処理速度を調整します。
- ストレージでサポートされる処理キューの障害復旧。障害が発生した場合は、システムがキューを削除または復元できる必要があります。
- ピーク時の LRO の削減。詳細については、割り当てを効率的に計画して使用すると LRO をキューして管理するをご覧ください。
場合によっては、トラフィック シェーピングは単一のパイプライン ステージでのみ必要になる場合があります。
- 前のパイプライン ステップから pull するワーカーの数を制限する。
- 各ワーカーを個別に制限します。
- ワーカープール コーディネーターを使用して、1 秒あたりのクエリ(QPS)や 1 秒あたりの取り込みバイト数など、個々の作業単位を処理するレートを調整します。
システムの他の領域にレート制限を実装する
既存のプログラミング言語とフレームワークを使用して、トラフィック シェーピングを実装できます。次のオープンソース プロジェクトとビルド済みソリューションを検討してください。
Apache Beam でのクライアント側のスロットリング。
numWorkers
フラグとmaxNumWorkers
フラグを使用してスロットリングを制御する方法については、水平自動スケーリングをご覧ください。コア Java ライブラリの Google Guava セットから Java
RateLimiter
クラス。Python
ratelimiter
モジュール。
フロー制御には、高レベルの Pub/Sub クライアント ライブラリを使用します。
非同期処理か同期処理かを選択する
複数のレイヤでエラーを処理するで説明されているように、Cloud Healthcare API へのリクエストをラップするクライアント側プロキシ レイヤでも、Cloud Healthcare API を使用するサービス全体のスロットリングを制御できます。必要なトラフィック シェーピングの種類に応じて、次のいずれかのオプションを使用します。
- 非同期
- 非同期処理を使用してリクエストをキューに入れ、ワーカーを制御します。プロキシレイヤは、受信リクエストをキューに書き込み、各リクエストがキューに登録された後に
200 OK
レスポンスを返します。これは書き込みリクエストには最適な方法ですが、クライアントが読み取り結果を受け取ることができる場合は、LRO フレームワークの読み取りリクエストに使用できます。 - 同期
同期処理は、作業単位が前の単位終了に依存する場合、簡単なフィードバック メカニズムを提供します。プロキシレイヤは QPS またはバイト スループットの上限に基づいて送信リクエストを遅延させ、クライアントはプロキシ レイヤのレスポンスをブロックして待機します。
プロキシレイヤは、インスタンス数に基づいてレート制限を調整できます。また、数秒ごとにレート制限を調整するコントローラ プロセスと連携することもできます。プロキシ レイヤがインスタンスの数とそのレート制限を追跡するには、各プロキシ インスタンスが定期的にファイルを読み取るか、レート制限をエンコードしたリモート プロシージャ コール(RPC)を行います。
同期処理には、次のようなデメリットがあります。
クライアントがレスポンスをブロックして待機している間は、クライアント レイヤとプロキシ レイヤのリソースは使用できません。エラー、タイムアウト、データ スループットの低下につながるため、スケーリングが難しくなります。
クライアントとプロキシのレイヤが切断された場合は、リクエストどおりにデータが変更されるようにさらに作業が必要になります。
Cloud Tasks の使用
Cloud Tasks を使用して、リクエストをキューにオフロードします。Cloud Tasks は、次の Google Cloud 割り当てを自動的に設定してモニタリングします。
RateLimits
オブジェクトを使用した最大バースト サイズと最大リクエスト同時実行RetryConfig
オブジェクトを使用して制限を再試行する
Cloud Tasks でキューを作成するには、キューの作成をご覧ください。Queue
リソースには、キューに設定できるオプションが表示されます。たとえば、RetryConfig
オブジェクトを使用して指数バックオフを実装できます。言語固有のライブラリについては、Cloud Tasks クライアント ライブラリをご覧ください。
Cloud Tasks を使用する場合は、次の点を考慮してください。
- Cloud Tasks では 1 回限りの配信は保証されません。1 回限りの配信では、重複データを含むリクエストは重複として認識され、サーバーによって無視されます。詳細については、ラムダの後: Dataflow における 1 回限りの処理(パート 1)をご覧ください。
- タスクの最大サイズは、Cloud Healthcare API の最大 FHIR バンドルサイズよりもはるかに小さい場合があります。詳細については、Cloud Tasks の割り当てと上限と Cloud Healthcare API の割り当てと上限をご覧ください。
- Cloud Tasks には問題と制限事項があります。
FHIR バンドルとレート制限機能を組み合わせる
指数バックオフとレート制限機能を使用して FHIR バンドルを再試行すると、高データ スループットの維持と負荷の急増の管理に役立ちます。
クライアントはバッチとトランザクションの FHIR バンドルを Cloud Tasks に送信し、Cloud Tasks はバンドル内のリクエストを Cloud Healthcare API に送信します。レート制限がいっぱいの場合、または最大キューサイズに達してディスク容量が不足した場合、クライアントは指数バックオフを実装してバンドルをキューに入れることができます。
次のリソースをモニタリングすることで、レート制限キューがいっぱいにならないようにします。
- Cloud Healthcare API での FHIR オペレーションの割り当て
- レート制限機能の割り当て
- レート制限機能のエラー
レート制限キューがいっぱいになると、システムは人間にアラートを送り、クライアントによるリクエストの送信を停止する必要があります。
HTTP の永続的(再利用可能なキープアライブ)接続を使用します
デフォルトでは、Cloud Healthcare API は CRUD リクエストごとに新しい TCP 接続を開きます。これには TCP handshake が必要であり、オーバーヘッドが発生し、パフォーマンスが低下する可能性があります。パフォーマンスを向上させるには、HTTP keep-alive を使用して、複数のリクエストで TCP 接続を開いたままにします。
HTTP/1.1 で HTTP keep-alive を使用するには、Connection
ヘッダーを keep-alive
に設定します。
Connection: keep-alive
HTTP/2 は、順次リクエストと同時リクエストに 1 つの TCP 接続を使用します。これにより、オーバーヘッドが自動的に回避されます。
Python requests
ライブラリでは、デフォルトで HTTP keep-alive が使用されます。Node.js を使用している場合、http.Agent
オブジェクトの作成時に keepAlive
を true
に設定して、オブジェクトを渡します。
テスト用フレームワークを使用する
テスト フレームワークは、コードが機能することを保証し、次のことに役立ちます。
- アプリケーションやパイプラインでのトラフィックの急増に備えます。
- 指数バックオフとクライアント側レート制限を使用してパフォーマンスが向上するかどうかをテストします。テストでは、これらの実装によって個別に処理する必要があるタスクのバックログが作成されているかどうかを確認できます。
- 優先度の高いトラフィックを分離して制御します。たとえば、ユーザーがレスポンスを待機している場合、ユーザー エクスペリエンスが低下しないように、バックグラウンド処理タスクのワークロードを減らすことができます。
- トラフィック フローを制御する同期および非同期のキューイング戦略をテストするか、プロキシ レイヤがプッシュバックを処理するかどうかをテストします。
- 災害復旧計画。これには通常、障害発生後に受信トラフィックをリセットするか、キューを使用してトラフィックを再開する必要があります。
Cloud Monitoring を使用する
Cloud Monitoring を使用して、テスト環境と本番環境をモニタリングします。ご紹介します
- Cloud Tasks と Cloud Audit Logs など、他の Google Cloud のロギング サービスやモニタリング サービスを統合します。
- Cloud Monitoring API を使用してカスタム指標を作成し、再試行、キューサイズ、キュー経過時間などの主要な指標を追跡します。
- 環境のサービスレベル目標(SLO)とサービスレベル指標(SLI)を作成する。推奨事項については、SLI の概要をご覧ください。
- Google Cloud Observability を使用してアラート ポリシーを作成します。アラート ポリシーにより、システムに負荷がかかっている場合や人間による介入が必要な場合などの問題が通知されます。
- 運用ハンドブックを作成して、アラート ポリシーが通知を送信する場合はシステム管理者が処理内容を把握できるようにします。
ステージング 環境での運用ハンドブックを使用して、次のシナリオに対応します。
- レート制限によるバックログ
- 割り当て上限の超過によるプッシュバック
- 受信トラフィックの急増
429 Resource Exhausted operation_too_costly
防止エラー
FHIR リソースに毎日数千件の並列更新を行うと、ロックの競合やレイテンシが発生し、トランザクションが完了できなくなります。完了できないトランザクションでは、429 Resource Exhausted operation_too_costly
エラーのバックログが発生する可能性があります。
HTTP/1.1 429 Too many requests ... { "issue": [ { "code": "too-costly", "details": { "text": "operation_too_costly" }, "diagnostics": "aborted due to lock contention while executing transactional bundle. Resource type: FHIR_RESOURCE_TYPE", "severity": "error" } ], "resourceType": "OperationOutcome" }
エラーにおける「費用」は、費用ではなく、リソースの使用量とデータ スループットを意味します。
429 Too Many Requests
エラーは、割り当ての問題を示すとは限りません。このエラーは、Cloud Healthcare API の FHIR サーバーがデータベース レコードで過剰なロック競合を検出した場合に発生します。これは、FHIR バンドルの多くのオペレーション、または CRUD オペレーションの組み合わせによって発生することがあります。
次のシナリオを考えてみます。
- 患者リソースと他の FHIR リソースを更新する FHIR トランザクション バンドルは、トランザクションが終了するまで患者リソースをロックします。
複数の FHIR バンドルが Patient リソースを並行して更新しようとすると、ロックの競合が発生します。エラー レスポンスには、
Resource type: PATIENT
というテキストを含むdiagnostics
フィールドが含まれます。指数バックオフを使用して Patient リソースの更新を再試行できますが、ロックの競合期間が長いと、タイムアウト、スループットの低下、リソース使用量の増加につながる可能性があります。
Cloud Healthcare API の FHIR サーバーは、最終的に
operation_too_costly
エラーを返すことで、トランザクションとロードシェーディングのバックログを検出します。これにより、トラフィックが制限され、エラーが防止されます。operation_too_costly
エラーは、Google Cloud プロジェクト内のすべての FHIR CRUD オペレーションを抑制します。これは、プロジェクトに接続されているすべてのアプリケーションに影響します。
429 Too Many Requests
エラーのトラブルシューティングを行う
429 Too Many Requests
エラーのトラブルシューティングを行うには、Cloud Logging を検索します。operation_too_costly
を含むエラーは、ロックの競合を示します。エラーがリソース枯渇による場合は、割り当ての問題を確認します。
スロットリングが発生すると、高レベルのロック競合が原因でトランザクション バンドルが失敗し、次のエラーが発生する可能性があります。
HTTP/1.1 429 Too many requests
...
{
"issue": [
{
"code": "too-costly",
"details": {
"text": "operation_too_costly"
},
"diagnostics": "aborted due to cumulative heavy load or lock contention in this project while executing transactional bundle, please see https://cloud.google.com/healthcare-api/docs/troubleshooting#fhir_transaction_bundle_heavy_load for more information",
"severity": "error"
}
],
"resourceType": "OperationOutcome"
}
このエラーのトラブルシューティングを行うには、diagnostics
フィールドの累積的な高負荷により FHIR トランザクション バンドルが中止されましたに移動します。
大規模なバンドルの回避
429 Too Many Requests
エラーは、大規模なトランザクション バンドルで発生する可能性が高くなります。バンドルのサイズがバンドルされることでスループットのボトルネックが発生する可能性があります。さまざまなバンドルをテストして、最適なサイズを見つけます。
再試行した大規模なバンドルの場合、パフォーマンスが低下する可能性があり、複数の障害の影響を受けやすくなります。クライアントは、トランザクションで失敗した FHIR リソースのサブセットを管理するための追加のロジックを実装する必要があります。
バッチバンドルが大きい場合や QPS が高い場合、429 Too Many Requests
と 413 Request Entity Too Large
のエラーとスループットのボトルネックが発生することがあります。
何千ものトランザクションを含む大規模なバンドルは使用しないでください。代わりに、次のようにします。
- データの整合性をサポートする小規模なトランザクション バンドルを使用します。FHIR リソースが互いに依存していない場合は、個別に更新します。たとえば、FHIR リソースが同じバンドル内の別のリソースの特定のバージョンに依存していない場合があります。
- 一括でいくつかのバッチを使用し、個々のリクエストを回避します。一括処理することでパフォーマンスが向上する可能性がありますが、大規模な一括処理を行うとエラーが発生し、データ スループットが低下する可能性があります。類似したサイズのバッチバンドルは、FHIR リソースの更新間でロックを保持しないため、競合が少なくなります。
小規模なトランザクション バンドルは、一度に少数のロックのみを保持して迅速に終了するため、競合を回避できます。これにより、スタックされたトランザクションのバックログを防ぐことができます。
LRO スループット
LRO データ スループットをご覧ください。
FHIR データ ストレージ オプション
FHIR データ量が小~中程度の場合は、fhir.create
を使用してデータを保存します。大量の FHIR リソースを保存するには、fhir.executeBundle
または fhirStores.import
を使用します。各メソッドの詳細については、FHIR インポート オプションをご覧ください。
FHIR リソースをインポートする
FHIR のインポートを使用するかどうかを決定する際は、次の点を考慮してください。
FHIR インポートでは、インポートするデータの合計サイズは制限されません。FHIR バンドルが 50 MB を超える場合は、FHIR リソースを Cloud Storage にアップロードしてインポートできます。高レイテンシや大規模なインポートを同時に行うことは避けてください。データ スループットが制限される場合があります。
FHIR インポートは、FHIR バンドルを使用するよりも複雑ではありません。たとえば、次のことを行う必要はありません。
- 大規模なバンドルを小さなバンドルに分割する
- スケジュールを管理
- リソースレベルまたはバンドルレベルで一時的なエラーを再試行する
FHIR インポートでは参照整合性が強制されません。詳細については、FHIR 参照整合性をご覧ください。
データの更新頻度が高い場合は、FHIR インポートを使用しないでください。インポートは高速ですが、数時間から数日かかることがあります。
Google Cloud プロジェクトに LRO が少ない場合、FHIR インポートのパフォーマンスが向上します。
アプリケーションがリソースのサブセットで一括エラーと障害を処理できる場合は、FHIR インポートによってデータのスループットが向上します。
FHIR バンドルの使用
次の場合は、FHIR インポートの代わりに FHIR バンドルを使用してください。
Cloud Storage にデータを保存してパイプラインをインポートするには、請求コストまたはネットワーク帯域幅のどちらでもコストがかかりすぎます。
参照整合性の適用が必要です。
FHIR プロファイルの検証を適用する必要があります。
FHIR リソースを保存したら、Pub/Sub 通知を送信する必要があります。FHIR インポートは Pub/Sub 通知をサポートしていません。
データの鮮度が優先され、データは数秒または数分で取り込まれる必要があります。ただし、適切に設計されたシステムでも、次の方法でデータ スループットを制限できます。
- 処理パイプラインのアップストリーム遅延。パイプラインでは、データを取り込む前にデータの準備に時間がかかることがあります。
- プロキシレイヤのバックオフ、再試行、トラフィック シェーピング。
FHIR バンドルには次の制限があります。
割り当てと課金は、各オペレーションが個別に実行されたかのように、バンドル内の各オペレーションに適用されます。たとえば、バンドルに 10 個の
POST
オペレーション、5 個のGET
オペレーション、1 個のDELETE
オペレーションがある場合、バンドルに適用される割り当てと請求はそれらのオペレーションが個別に実行された場合と同様のものになります。トランザクション バンドルが大きいと、トランザクションの競合が発生してロック競合が発生する可能性があります。詳細については、
429 Resource Exhausted operation_too_costly
エラーの防止をご覧ください。バッチバンドルはデータ スループットを向上させることができますが、参照整合性などのトランザクション整合性機能はありません。
バッチサイズが大きいと、スループットが低下する可能性があります。詳しくは、大規模なバンドルを避けるをご覧ください。
DICOM データ ストレージ オプション
Picture Archiver and Communication System(PACS)から Cloud Healthcare API にデータを送信する際に、以下の方法を使用してデータ スループットを高めることができます。
- DICOM メッセージ サービス要素(DIMSE)プロトコルを使用したオープンソースの Cloud Healthcare API DICOM アダプタ
アダプタは、PACS を Cloud Healthcare API と同期する際にデータ スループットを最適化します。同期前にパフォーマンス テストを実行し、アダプタがピークデータのスループットを維持できることを確認します。
Storage Transfer Service や他の転送オプションを使用して Cloud Storage に DICOM ファイルをアップロードできない場合は、このアダプタを使用してください。たとえば、次の Storage Transfer Service の要件を満たしていない場合があります。
- エージェント プール内のエージェントをホストするすべてのマシンにファイル システムをマウントして、ソースデータを取得します。
- 1 回限りのバッチ読み込みではなく定期的な間隔でデータを転送する場合は、時間の経過とともにデータサイズの変化を測定して、変更内容を確認する必要があります。
- エージェントの転送パフォーマンスの最大化。
- Cloud Storage のストレージの費用と割り当て。
- Cloud Storage へのデータ転送を検証します。
- Cloud Healthcare API にデータをインポートした後に Cloud Storage リソースを削除し、インポート エラーを修正する。
- 臨床システムのネットワークとストレージ容量に基づくバッチ取り込み間隔のスケジューリング。
単一のバッチ読み込みには Storage Transfer Service を使用して DICOM ストアにデータを入力することをおすすめします。Storage Transfer Service を使用するには、同期インポート パイプラインなど、定期的に追加作業が必要です。詳しくは、Storage Transfer Service ファイル システム転送の詳細をご覧ください。
dicomStores.import
このメソッドを使用して、大量の DICOM データを保存します。
- DICOMweb ストア トランザクション
このメソッドを使用して、DICOM データをプログラムで保存します。
割り当てを管理してデータのスループットを最適化する
以下のセクションでは、データ スループットを最適化するために、割り当ての管理と計画の方法について説明します。割り当て管理に関する一般的なベスト プラクティスについては、割り当て管理のベスト プラクティスをご覧ください。
予測可能なトラフィックの割り当てを計画する
まず、クライアント アプリケーションの一般的な 1 日あたりのトラフィックを分析して、割り当て要件を計画します。トラフィックが予測可能であっても、平均が必要以上に割り当てを計画します。これにより、エラーを回避し、トラフィックの急増や日常的な使用の増加に対する安全マージンを確保できます。
次の図は、サイズに一貫性があり、予測可能なパターンで送信される Cloud Healthcare API へのリクエストを示しています。
大量のリクエストに対する割り当てを計画する
ピーク時に大規模なバッチジョブをスケジュールしないでください。詳細については、少量のトランザクションを一貫した方法で優先するをご覧ください。
次の図に、予測可能なトラフィック パターンを示します。ただし、トラフィックのピーク期間中に大量のバッチ リクエストが利用可能な割り当てを超過すると、 これにより、プロジェクト内のすべてのリクエストで 429 Resource Exhausted
エラーが発生する可能性があります。
システムに柔軟な割り当てがある場合、トラフィックの急増によってエラーを発生させたり、予測可能なピーク負荷でエラーが発生したりすることはありません。小規模なスパイクは、Google Cloud プロジェクトで負荷を生成する多くのデータストア、アプリケーション、その他のクライアントに分散する必要があります。
1 つの大規模なバッチジョブでトラフィックの急増を防ぐには、大規模なバンドルを避けるをご覧ください。
追加の割り当てをリクエストする
高いデータ スループットを維持し、429 Resource Exhausted
エラーを回避するには、このページのベスト プラクティス、特にデータ スループットを最適化する割り当ての管理をご覧ください。これらのベスト プラクティスにより、クライアント アプリケーションが堅牢で、リクエスト量の変化に応じてスケールできるようになります。ベスト プラクティスを実装せずに追加の割り当てをリクエストしても、長期的にエラーが防止される可能性があります。
ベスト プラクティスを実装しても割り当ての増加が必要な場合は、追加の割り当てをリクエストするためのベスト プラクティスをご覧ください。
データ取り込みスループット リソース
データの取り込みスループットの詳細については、Google Cloud のワークロードのトラフィックと読み込みの管理をご覧ください。