要求延遲時間和錯誤處理最佳做法

本頁面說明如何在 Cloud Healthcare API 中，最佳化要求延遲時間和處理錯誤的最佳做法。在規劃及設計系統架構時，請實施這些做法。

Google 提供服務水準協議 (SLA)，其中定義了 Cloud Healthcare API 服務的預期正常運作時間，以及用戶端如何處理錯誤。詳情請參閱 Cloud Healthcare 服務水準協議 (SLA)。

實作重試邏輯和逾時

如要處理要求失敗所造成的延遲和錯誤，請實作適當的重試邏輯和逾時。設定逾時期限時，請留出足夠的時間執行下列操作：

  • 讓 Cloud Healthcare API 處理要求。
  • 判斷錯誤是否源自服務或用戶端。

您可以重試某些錯誤，但其他錯誤無法重試，且會在多次重試後持續存在。舉例來說，如果要求資料的格式不正確，伺服器會傳回 400 Bad Request 狀態碼。您必須修正資料，要求才會成功。

如要處理這些情況，您需要規劃最終錯誤狀態。

如要進一步瞭解重試邏輯和逾時，請參閱「重試失敗的要求」。

處理多個層級的錯誤

中介軟體與 Cloud Healthcare API 互動時，請在用戶端和中介軟體中實作重試邏輯和逾時設定。如果用戶端遇到錯誤，且超過重試限制，您必須能夠判斷錯誤是在用戶端、中介軟體，還是底層 Cloud Healthcare API 服務發生。在規劃最終錯誤狀態時，這點尤其重要。

請考量下列情境：

  1. 中介軟體在傳送要求時，會收到來自 Cloud Healthcare API 的 500 Internal Server Error 錯誤。
  2. 中介軟體層會重試要求五次，直到達到上限為止，然後停止重試。
  3. 用戶端會收到最終 500 Internal Server Error 錯誤。

請務必瞭解，這項錯誤源自 Cloud Healthcare API，而非中介軟體。為簡化偵錯作業，請在傳回給用戶端的錯誤中提供這項資訊。

下圖顯示中介軟體 Proxy 在將用戶端的要求轉送至 Cloud Healthcare API 時，收到 500 Internal Server Error 錯誤的情況。用戶端和 Proxy 都會實作錯誤處理和重試功能。

用戶端/中介軟體/伺服器堆疊中錯誤處理位置的圖表。
圖 1. 您需要實作重試邏輯和逾時的層級為 Client 和 Proxy。

圖 1 顯示以下步驟：

  1. 用戶端會透過中介軟體 Proxy 將有效要求傳送至 Cloud Healthcare API。
  2. Proxy 會將要求轉送至 Cloud Healthcare API。
  3. Cloud Healthcare API 會傳回 500 Internal Server Error 錯誤給 Proxy。Proxy 會重試要求五次，直到達到重試限制為止。

  4. Proxy 會將最終錯誤狀態 500 Internal Server Error 傳回給用戶端。

    您可以參考先前的建議，讓 Proxy 將下列錯誤傳回給用戶端，藉此對最終錯誤狀態進行偵錯：

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

    新增 Cloud Healthcare API 傳回錯誤的其他資訊。

有時，用戶端或 Proxy 會在重試次數上限過後收到 500 Internal Server Error 錯誤，而無法再次重試。在這種情況下，可能需要人為介入來診斷錯誤是來自 Proxy 還是 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 是一項可擴充且效能優異的服務，但要求延遲時間仍可能因下列原因而有所不同：

  • 即使要求之間的差異很小，也可能會導致額外的處理時間。
  • 類似要求的延遲時間可能不同。舉例來說，如果有兩個類似的要求會將記錄新增至資料儲存空間，其中一個要求超過會觸發額外工作 (例如分配更多儲存空間) 的門檻，這兩個要求的延遲時間可能會不同。
  • Cloud Healthcare API 會同時處理多個要求。用戶端傳送要求的時間 (以秒的十分之一為單位)，可能會與 Cloud Healthcare API 負載較平常更重的時間重疊。
  • 如果 Cloud Healthcare API 實體資源 (例如磁碟) 正在處理多項要求，則必須先完成排隊的作業，才能處理其他要求。
  • 有時，Cloud Healthcare API 會重試伺服器端的錯誤，這可能會增加用戶端的延遲時間。
  • 在地區或多地區位置的不同資料中心中，可能會有多份資料副本。如果要求是在多個資料中心之間轉送 (無論是原始要求或重試)，延遲時間可能會增加。

使用百分位數延遲時間進行規劃

您可以分析要求的百分位數延遲時間，以便因應延遲時間增加的情況。以下範例說明第 50 百分位數延遲時間和第 99 百分位數延遲時間：

  • 第 50 個百分位數的延遲時間是要求中速度最快的 50% 所需的最大延遲時間 (以秒為單位)。舉例來說，如果第 50 百分位數的延遲時間為 0.5 秒，表示 Cloud Healthcare API 在 0.5 秒內處理了 50% 的要求。第 50 個百分位數的延遲時間也稱為「中位數延遲時間」。
  • 第 99 個百分位數的延遲時間是指，在最快的 99% 要求中，延遲時間的最高值 (以秒為單位)。舉例來說，如果第 99 個百分位數的延遲時間為兩秒，表示 Cloud Healthcare API 在兩秒內處理 99% 的要求。

如果您在 Cloud Healthcare API 只處理少數要求的情況下，分析一段時間內的百分比延遲時間，由於異常要求可能會造成很大影響，因此百分比延遲時間可能不具參考價值，也無法代表整體效能。

舉例來說，假設 Cloud Healthcare API 中的程序在 100 分鐘內處理 100 個要求。100 分鐘的第 99 個百分位數延遲時間會根據最慢的單一要求計算。使用單一要求的延遲時間評估功能，無法瞭解是否有效能問題。

在較長的時間 (例如 24 小時) 內收集更多要求樣本，可以進一步瞭解系統的整體行為。您可以使用這些範例，判斷系統如何回應大量流量。