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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図 1 に次のステップを示します。

クライアントがミドルウェアプロキシを介して Cloud Healthcare API に有効なリクエストを送信します。
プロキシは、リクエストを Cloud Healthcare API に転送します。
Cloud Healthcare API は、プロキシに 500 Internal Server Error エラーを返します。プロキシは、再試行の上限に達するまで、リクエストをさらに 5 回再試行します。
プロキシは、最終的なエラー状態 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 時間などの長い期間にわたってサイズの大きいリクエストサンプルを収集すると、システムの全体的な動作をより詳しく分析できます。これらのサンプルを使用して、大量のトラフィックに対するシステムの対応方法を決定できます。

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