リクエストのレイテンシとエラー処理のベスト プラクティス

このページでは、Cloud Healthcare API でリクエスト レイテンシを最適化し、エラーを処理するためのベスト プラクティスについて説明します。これらのプラクティスは、システム アーキテクチャを計画、設計する際に実装します。

Google は、Cloud Healthcare API サービスの予想される稼働時間と、クライアントがエラーを処理する方法を定義するサービスレベル契約（SLA）を提供しています。詳細については、Cloud Healthcare サービスレベル契約（SLA）をご覧ください。

再試行ロジックとタイムアウトを実装する

失敗したリクエストによる遅延とエラーを処理するには、適切な再試行ロジックとタイムアウトを実装します。タイムアウト時間を設定する際は、次の処理に十分な時間を確保してください。

  • Cloud Healthcare API にリクエストを処理させます。
  • エラーの原因がサービスかクライアントかを確認します。

一部のエラーは再試行できますが、その他のエラーは再試行できないため、複数回の再試行にまたがって存続します。たとえば、リクエストデータの形式が正しくない場合、サーバーは 400 Bad Request ステータス コードで応答します。データを修正するまで、リクエストは成功しません。

このような状況に対応するには、最終的なエラー状態を計画する必要があります。

再試行ロジックとタイムアウトの詳細については、失敗したリクエストを再試行するをご覧ください。

複数のレイヤでエラーを処理する

ミドルウェアで Cloud Healthcare API を操作する場合は、クライアントとミドルウェアに再試行ロジックとタイムアウトを実装します。クライアントで再試行の上限を超えるエラーが発生した場合は、クライアント、ミドルウェア、または基盤となる Cloud Healthcare API サービスでエラーが発生したかどうかを特定できる必要があります。これは、最終的なエラー状態を計画する際に特に重要です。

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

  1. ミドルウェアが、リクエストの送信時に Cloud Healthcare API から 500 Internal Server Error エラーを受け取ります。
  2. ミドルウェア レイヤは、上限である 5 回リクエストを再試行してから、再試行を停止します。
  3. クライアントが最後の 500 Internal Server Error エラーを受け取ります。

エラーがミドルウェアではなく、Cloud Healthcare API で発生したのを理解することが重要です。デバッグを簡素化するために、クライアントに返されるエラーでこの情報を提供します。

次の図は、クライアントから Cloud Healthcare API にリクエストを転送するときに、ミドルウェア プロキシが 500 Internal Server Error エラーを受け取るシナリオを示しています。クライアントとプロキシの両方で、エラー処理と再試行が実装されます。

クライアント / ミドルウェア / サーバー スタックのエラーを処理する場所の図。
図 1。再試行ロジックとタイムアウトを実装する必要があるレイヤは、クライアントとプロキシです。

図 1 は、次の手順を示しています。

  1. クライアントは、ミドルウェア プロキシを介して Cloud Healthcare API に有効なリクエストを送信します。
  2. プロキシはリクエストを Cloud Healthcare API に転送します。
  3. Cloud Healthcare API は、プロキシに 500 Internal Server Error エラーを返します。プロキシは、再試行の上限に達するまで、リクエストをさらに 5 回再試行します。

  4. プロキシは、最終的なエラー状態 500 Internal Server Error をクライアントに返します。

    前述の推奨事項を使用して、プロキシで次のエラーをクライアントに返すことで、最終的なエラー状態をデバッグできます。 

    Error with underlying FHIR store in Cloud Healthcare API after 5 retries: 500 Internal Server Error

    Cloud Healthcare API から返されるエラーについての詳細情報を追加します。

クライアントまたはプロキシが再試行の上限を超えた 500 Internal Server Error エラーを受け取り、それ以降、再試行できない場合があります。この場合、エラーがプロキシまたは Cloud Healthcare API に起因するのかを診断するために、人間が介入する必要がある場合があります。

再試行するエラーを選択する

システムのアーキテクチャによっては、特定のエラーを再試行して他のものを無視できます。以下は、再試行可能な Cloud Healthcare API のエラーコードの一部を紹介するリストです。

  • 408 Request Timeout
  • 425 Too Early
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

通常、これらのエラーは同じ頻度で発生せず、発生しないこともあります。

システム アーキテクチャの効果

システムのアーキテクチャは、エラーの再試行方法とタイミングに影響します。

たとえば、直接クライアント ツー サーバーアーキテクチャでは、Cloud Healthcare API から 401 UNAUTHENTICATED エラーを受け取ったクライアントは、リクエストを再認証して再試行できます。

システムに、クライアントと Cloud Healthcare API の間にミドルウェア レイヤがあるとします。クライアントが正しく認証され、期限切れの認証トークンによって問題が発生した場合、ミドルウェアはトークンを更新してリクエストを再試行する必要があります。

最終的なエラー状態を分析した後、検出結果に基づいてクライアントが再試行するエラーを調整できます。

最終的なエラー状態を計画する

再試行ロジックとタイムアウトを実装した後でも、再試行が上限に達するまでクライアントまたはミドルウェアがエラーを受け取ることがあります。再試行とタイムアウトが終わる前に返された最後のエラーが、最終的なエラー状態になります。データ整合性エラーでは、最終的なエラー状態が発生する場合があります。

最終的なエラー状態では、人間による介入が必要になる場合があります。リクエストの最終的なエラー状態を解消する方法を実装することを試みます。できない場合は、人間が確認できるように最終的なエラー状態を記録します。

最終的なエラー状態を処理する方法を計画する際は、次のことを検討してください。

  • FHIR トランザクションまたはバンドルが正常に完了できない場合に停止する必要がある処理依存関係があるかどうか。
  • 多くの仮想マシン（VM）インスタンスが永久に起動に失敗する場合、クライアントは失敗したトラフィックを報告する必要があります。問題が解決したら、クライアントはリクエストを再試行する必要があります。
  • システムの安定性を確保するには、モニタリング システム、アラート システム、サービスレベル目標（SLO）が必要です。詳細については、テストとモニタリングをご覧ください。

レイテンシの増加に対して計画する

Cloud Healthcare API はスケーラブルでパフォーマンスの良いサービスですが、それでも次の理由によりリクエストのレイテンシが異なる可能性があります。

  • リクエスト間の小さな違いが、たとえそれらが重要ではない場合でも、余分な処理時間を引き起こす可能性があります。
  • 同様のリクエストのレイテンシが異なる場合があります。たとえば、データ ストレージにレコードを追加する 2 つの同様のリクエストは、1 つのリクエストが追加のタスク（追加のストレージの割り当てなど）をトリガーするしきい値を超えた場合のレイテンシが異なる場合があります。
  • Cloud Healthcare API は、多くのリクエストを同時に処理します。クライアントがリクエストを送信した時間を 1 秒未満で測定すると、Cloud Healthcare API の負荷が通常よりも高い時間と一致する場合があります。
  • ディスクなどの Cloud Healthcare API の物理リソースが多数のリクエストを処理している場合は、他のリクエストを処理する前に、キューにあるタスクを完了する必要があります。
  • Cloud Healthcare API がサーバー側でエラーを再試行するため、クライアントのレイテンシが増加することがあります。
  • リージョンまたはマルチリージョンのロケーションの異なるデータセンターにデータのコピーが複数存在する場合があります。元のリクエストと再試行のいずれかでリクエストが複数のデータセンターにわたってルーティングされていると、レイテンシが増加する場合があります。

パーセンタイルのレイテンシを使用して計画する

リクエストのパーセンタイルのレイテンシを分析することで、レイテンシの増加に対して計画できます。次の例では、50 パーセンタイルのレイテンシと 99 パーセンタイルのレイテンシについて説明します。

  • 50 パーセンタイルのレイテンシは、最も処理時間の短い 50% のリクエストの最大レイテンシ（秒）です。たとえば、50 パーセンタイルのレイテンシが 0.5 秒の場合、Cloud Healthcare API は 50% のリクエストを 0.5 秒以内に処理しています。50 パーセンタイルのレイテンシは「中央値のレイテンシ」とも呼ばれます。
  • 99 パーセンタイルのレイテンシは、最も処理時間の短い 99% のリクエストの最大レイテンシ（秒）です。たとえば、99 パーセンタイルのレイテンシが 2 秒の場合、Cloud Healthcare API は 99% のリクエストを 2 秒以内に処理しています。

Cloud Healthcare API が数リクエストしか処理していない間隔でパーセンタイル レイテンシを分析する場合、外れ値のリクエストは影響が大きい可能性があるため、パーセンタイルのレイテンシは全体的なパフォーマンスに有益ではないか、示していません。

たとえば、Cloud Healthcare API のプロセスが 100 分間で 100 件のリクエストを処理したとします。100 分間の 99 パーセンタイルのレイテンシは、1 つの最も遅いリクエストに基づきます。1 つのリクエストを使用したレイテンシの測定では、パフォーマンスの問題があるかどうかを把握するのに十分ではありません。

24 時間などの長い期間にわたってサイズの大きいリクエスト サンプルを収集すると、システムの全体的な動作をより詳しく分析できます。これらのサンプルを使用して、システムが大量のトラフィックに対応する方法を確認できます。