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

このページでは、Cloud Healthcare API にデータを取り込む際のデータスループットを最適化するためのベストプラクティスについて説明します。これらの推奨事項は、大規模システムのデータスループットの管理経験がある技術担当者を対象としています。

データスループット

データスループットは、Cloud Healthcare API が 1 秒間に取り込むリソース（FHIR リソース、DICOM インスタンスなど）またはバイト数です。

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

データスループットが制限される理由は次のとおりです。

トラフィックの急増を引き起こす大量のリクエストを想定していません。
帯域幅の制約により、短時間に送信される大量のデータの取り込みが遅くなります。
複数の同時実行トランザクションが同じ Cloud Healthcare API リソースを変更し、データ競合が発生します。
小さなリクエストが多すぎます。詳細については、小さなインポートリクエストとエクスポートリクエストを回避するをご覧ください。
長時間実行オペレーション（LRO）が同時に実行されすぎて、帯域幅が制限されている。
同時にスケジュールされる LRO が多すぎるため、障害が発生します。

失敗したリクエストの再試行

クライアントが失敗後にリクエストをすばやく繰り返し再試行すると、Cloud Healthcare API の割り当てを超える可能性があります。以降のセクションでは、失敗したリクエストを効率的に再試行する方法について説明します。

ジッターと永続的な再試行キューを使用して指数バックオフを使用する

ジッターを伴う指数バックオフは、ネットワークアプリケーション向けの標準エラー処理戦略です。クライアントは、失敗したリクエストを定期的に再試行し、再試行間の遅延は指数関数的に増加し、小さなランダムな遅延が発生します。

特に、カスタムロジックを使用して障害条件を回避する場合は、指数バックオフの実装がリトライごとにべき等であることを確認してください。詳細については、HTTP 仕様の 9.2.2 Idempotent Methods をご覧ください。

ほとんどのプログラミング言語には、指数バックオフや同様の再試行戦略の実装を簡素化するライブラリが用意されています。長期またはマルチプロセスの再試行の場合は、永続的な再試行キューを実装します。このキューは、最大バックオフ時間を超過した場合に再試行メカニズムをリセットできます。

次のリクエストを再試行するときには、指数バックオフを使用します。

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 するワーカーの数を制限する。
各ワーカーを個別に制限する。
ワーカープールコーディネーターを使用して、個々の作業単位（秒間クエリ数（QPS）や秒間取り込まれたバイト数など）の処理速度を調整します。

システムの他の領域にレート制限を実装する

既存のプログラミング言語とフレームワークを使用して、トラフィックシェーピングを実装できます。次のオープンソースプロジェクトとビルド済みソリューションを検討してください。

Apache Beam のクライアントサイドスロットリング。numWorkers フラグと maxNumWorkers フラグを使用してスロットルを制御する方法については、水平自動スケーリングをご覧ください。
Google Guava のコア Java ライブラリセットの 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 回限りの配信では、重複するデータを含むリクエストは重複として認識され、サーバーで無視されます。詳細については、Lambda の後: Dataflow における exactly-once 処理（パート 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 ハンドシェイクが必要になり、オーバーヘッドが発生してパフォーマンスが低下する可能性があります。パフォーマンスを向上させるには、HTTP キープアライブを使用して、複数のリクエストに対して TCP 接続を開いたままにします。

HTTP/1.1 で HTTP キープアライブを使用するには、Connection ヘッダーを keep-alive に設定します。

Connection: keep-alive

HTTP/2 は、順次リクエストと同時リクエストに 1 つの TCP 接続を使用します。これにより、オーバーヘッドが自動的に回避されます。

Python の requests ライブラリは、デフォルトで HTTP キープアライブを使用します。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 オペレーションの組み合わせが原因で発生することがあります。

次のシナリオを考えてみます。

Patient リソースと他の FHIR リソースを更新する FHIR トランザクションバンドルは、トランザクションが完了するまで Patient リソースをロックします。
複数の 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 や他の転送オプションを使用して DICOM ファイルを Cloud Storage にアップロードできない場合は、このアダプタを使用します。たとえば、Storage Transfer Service の次の要件を満たせない場合があります。

エージェントプール内のエージェントをホストするすべてのマシンにファイルシステムをマウントして、ソースデータを取得する。
1 回のバッチ読み込みではなく、定期的にデータを転送する場合は、時間の経過に伴うデータサイズの変化を測定して、何が変更されたかを判断する必要があります。
エージェントの転送パフォーマンスを最大化する。
Cloud Storage ストレージの支払いと割り当て。
Cloud Storage へのデータ転送の検証。
Cloud Healthcare API にデータをインポートしてインポートエラーを修正した後、Cloud Storage リソースを削除する。
臨床システムのネットワークとストレージ容量に基づいてバッチ取り込み間隔をスケジュールする。

DICOM ストアにデータを一括読み込むには、Storage Transfer Service を使用することをおすすめします。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 でワークロードのトラフィックと負荷を管理するをご覧ください。

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

データ スループット

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