データ取り込みのスループットに関するベストプラクティス

このページでは、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 秒待ってから、リクエストを再試行します。
再試行のたびに 2ⁿ + random-fraction 秒待機します。このパターンを最大で maximum-backoff 時間まで繰り返します。
deadline 秒後に、リクエストの再試行を停止します。

アルゴリズムを実装するときに以下の値を使用します。

各再試行までの待機時間は min((2ⁿ + random-fraction), maximum-backoff) です。n は 0 から始まり、再試行のたびに 1 ずつ増えます。
random-fraction は、1 以下のランダムな小数値に置き換えます。再試行ごとに異なる値を使用します。このランダムな値を追加すると、クライアントの同期と多数の再試行を同時に送信できなくなります。
maximum-backoff は、再試行の最大待機時間（秒数）に置き換えます。通常の値は 32 秒または 64 秒（2⁵ または 2⁶）です。ユースケースに適した値を選択してください。
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 へのリクエストを示しています。

ピーク時と一般的な時間の割り当て使用量の比較。 — **図 1。**Google Cloud プロジェクトのデータセットとデータストア全体での 1 時間ごとの API 負荷の合計。

大量のリクエストに対する割り当てを計画する

ピーク時に大規模なバッチジョブをスケジュールしないでください。詳細については、少量のトランザクションを一貫した方法で優先するをご覧ください。

次の図に、予測可能なトラフィックパターンを示します。ただし、トラフィックのピーク期間中に大量のバッチリクエストが利用可能な割り当てを超過すると、これにより、プロジェクト内のすべてのリクエストで 429 Resource Exhausted エラーが発生する可能性があります。

ピーク時と通常時における割り当て使用量のピークの比較。 — **図 2** ピーク時の大規模なバッチジョブによって引き起こされるリソース使用量の不均等な分布。

システムに柔軟な割り当てがある場合、トラフィックの急増によってエラーを発生させたり、予測可能なピーク負荷でエラーが発生したりすることはありません。小規模なスパイクは、Google Cloud プロジェクトで負荷を生成する多くのデータストア、アプリケーション、その他のクライアントに分散する必要があります。

1 つの大規模なバッチジョブでトラフィックの急増を防ぐには、大規模なバンドルを避けるをご覧ください。

追加の割り当てをリクエストする

高いデータスループットを維持し、429 Resource Exhausted エラーを回避するには、このページのベストプラクティス、特にデータスループットを最適化する割り当ての管理をご覧ください。これらのベストプラクティスにより、クライアントアプリケーションが堅牢で、リクエスト量の変化に応じてスケールできるようになります。ベストプラクティスを実装せずに追加の割り当てをリクエストしても、長期的にエラーが防止される可能性があります。

ベストプラクティスを実装しても割り当ての増加が必要な場合は、追加の割り当てをリクエストするためのベストプラクティスをご覧ください。

データ取り込みスループットリソース

データの取り込みスループットの詳細については、Google Cloud のワークロードのトラフィックと読み込みの管理をご覧ください。

データ取り込みのスループットに関するベスト プラクティス

データ スループット

データ スループットの制約