使用 Speech-to-Text 進行實際工作環境即時語音轉錄的架構

本指南說明使用 Google Cloud 技術 (包括 Speech-to-TextGoogle Kubernetes Engine (GKE)) 來提供高可用性且有彈性的即時語音轉錄功能。Memorystore。本指南主要對象為開發人員和架構人員,並假設您有 Kubernetes 和 GKE 的基本知識。如果您需要快速簡介,請參閱 GKE 總覽

如要實作這個架構的實作,請參閱相關教學課程

簡介

將廣播音訊轉錄為文字有許多用途。 媒體機構可以即時轉錄音訊,為直播產生字幕。即時通話或會議的轉錄內容可能會進一步幫助失聰參與者。會議和活動時,主辦人可以安排即時轉錄稿內容,以便在會議中顯示文字。

現今使用許多即時轉錄解決方案都需要技術方面的專業人士和專業軟體, 由於程序仰賴人類運算子,因此很難調度語音轉錄工作。也就是說,您通常只能針對少數直播或活動執行轉錄作業。

Speech-to-Text 支援即時轉錄。您可以將音訊串流傳送至 Speech-to-Text,然後即時傳回一筆文字轉錄稿。使用 Speech-to-Text 時,媒體機構可以自動化並擷取現有的轉錄程序,減少依賴人力操作人員的範圍,並增加轉錄活動的範圍。

品質、延遲時間和一致性的考量因素,取決於依賴轉錄功能的使用者。如果現場直播或活動中包含轉錄稿,則必須特別注意這點。經常發生延遲或掉落的情況,不但可能帶來負面的使用者體驗,也會讓使用者感到 and 折。因此,任何轉錄解決方案都必須提供高品質的文字轉錄稿。但它也必須具備高可用性和彈性,如此故障與中斷可能導致導致語音轉錄傳送作業中斷。本指南說明應用程式架構,以滿足可用性高、即時性語音轉錄等關鍵需求。

架構

在 Google Cloud 中建構可用於實際工作環境的語音轉錄應用程式架構

本架構包含下列功能:

  • 三個應用程式微服務:
    • Ingestor 實作加密編譯演算法。這項服務會使用來源音訊串流。
    • Transcriber 實作加密編譯演算法。這個服務會呼叫 Speech-to-Text 和 emits 轉錄結果。
    • Reviewer 實作加密編譯演算法。這項服務會在網路應用程式中顯示轉錄內容以供審查。
  • GKE 託管應用程式微服務,在地區 GKE 叢集中跨越多個區域。跨地區部署應用程式微服務。
  • Memorystore for Redis - 做為快速中繼儲存空間。這項功能部署在高可用性設定中。
  • 負載平衡器會向網際網路公開應用程式功能,以便執行下列操作:
    • 提供可將來源音訊串流導向的 IP 位址。
    • 提供審查者網頁應用程式。

規定和建議摘要

本節列舉了提供即時轉錄的應用程式需求範例,以及解決需求的建議。除非另有註明,我們將在後續章節中深入探索建議做法。

需求 建議
架構應該要有彈性,而且鬆散。 將應用程式設定為一組獨立的容器化微服務。使用 GKE 管理及自動化調度管理微服務。
架構必須在單一地區中提供高可用性。 使用地區 GKE 叢集跨區域備援應用程式微服務。
應用程式必須提供穩定的 IP 位址以供擷取。 Ingestor 服務部署為 LoadBalancer 類型的 Kubernetes 服務
應用程式必須提供機制,讓真人營運人員審查轉錄內容。 提供可以即時顯示轉錄內容的網路應用程式。(本文件未詳細說明)。
音訊必須即時轉錄。 使用 Speech-to-Text 串流辨識要求。
應用程式應維持單一與 Speech-to-Text 的有效連線。 使用主要選手選擇單一 Transcriber Pod 做為主要執行個體。
端對端語音轉錄必須在低延遲時間中執行。 使用 Memorystore for Redis 快速取得記憶體內部中繼儲存空間。
轉錄稿應與語音辨識情境 (例如已知的網域詞彙) 搭配使用。 使用語音調整功能為 Speech-to-Text 提供字詞和詞組提示。
應用程式應能處理多個並行音訊串流 (頻道)。 為每個管道部署不同的 Transcriber 執行個體。 建議您跨頻道共用其他應用程式資源。
應用程式應從故障復原失敗,盡可能避免對轉錄內容造成乾擾。 使用領先者、備援部署及負載平衡器來協助提升彈性。測試失敗情形,藉此測試應用程式的彈性。

將應用程式設計為容器化微服務

將應用程式設計為鬆散且獨立的元件或服務是架構的最佳做法。採用鬆散設計的設計可讓您分別管理每項服務的生命週期。服務可以由不同的團隊建立及管理。每個團隊都可以選擇最適當的技術,而不受到其他團隊的選擇。這些好處是微服務架構模式的核心。

微服務架構通常會將服務封裝成容器。容器非常適合服務型應用程式,因為您可以在每個容器中執行健康狀態檢查、將每個服務限制於特定資源,並讓各版本分別啟動及停止。將應用程式建構成一組容器,藉此改善效率、可攜性和一致性。

決定將應用程式分割為微服務的方式和位置有時是一項複雜的決定。不過,對這個轉錄應用程式而言,您必須明確注意某些責任,如下表所示。

微服務 說明
Ingestor 使用來源音訊串流並寫入中繼儲存空間。

音訊可能會透過第三方軟體和網域專屬通訊協定傳送,也可能經過加密。因此,在擷取元件之外,設計和擷取擷取元件是很合理的做法。
Transcriber 使用擷取的音訊、呼叫 Speech-to-Text,並將轉錄結果寫入中繼儲存空間。

Transcriber 服務是應用程式的核心。負責管理與 Speech-to-Text 連線,以及處理轉錄結果。
Reviewer 構成轉錄內容,並在網路應用程式中顯示。

一般來說,媒體機構需要人工作業,才能監看產生的轉錄內容。為了協助這項要求,Reviewer 網路應用程式可能會先修改轉錄內容,再傳送至下游播送。

使用 GKE 託管應用程式微服務

GKE 是託管容器化應用程式的好選擇。首先,GKE 叢集採用 Kubernetes 技術,提供下列好處:

  • Kubernetes 提供雲端原生平台,讓您不必管理和連結鬆散的容器化應用程式。
  • Kubernetes 可讓您以宣告的方式管理叢集,使您的設定受到版本控制,並可輕鬆複製。
  • Kubernetes 為開放原始碼,可提供可攜性。

其次,GKE 是提供進階叢集管理功能的全代管服務,包括:

  • 針對叢集的節點執行個體數量自動調整資源配置
  • 自動升級叢集的節點軟體。
  • 與其他 Google Cloud 服務整合,包括負載平衡器、虛擬私人雲端網路、資料庫,以及記錄與監控
  • 在單一地區提供跨地區備援功能的地區叢集,進而提高可用性。

如要進一步瞭解如何在實際工作環境中使用 GKE,請參閱準備實際工作環境的 GKE 環境指南。

以備援方式部署應用程式微服務,以提升可用性

轉錄中斷且間歇性傳送的內容可能會幹擾使用這些功能的使用者。應用程式必須能夠承受服務中斷或錯誤,才能達到可靠的語音轉錄功能。

可用性是測量系統啟動時間的指標。在 Google Cloud 中,高可用性通常是透過將應用程式服務部署至多個區域來達成高可用性。如果服務存在於多個區域,則較能將特定區域服務中斷。

相較於部署至單一地區,將應用程式部署至多個地區可提供更好的可用性。但是,多地區的應用程式會增加其他限制,例如需要複製資料,而且可能需要特別設計與管理。針對這個轉錄應用程式,將應用程式部署至單一地區中的多個區域,可提供足夠的可用性。

使用地區 GKE 叢集設定

GKE 提供選項,讓您叢集的資料分散於地區內的區域。選項如下:

  • 單一區域叢集。所有叢集節點都在單一區域中。在同一個區域中正在執行一個控制層 (Kubernetes 主要執行個體)。單一區域叢集不適合轉錄應用程式,因為您希望應用程式在整個區域提供。
  • 多區域叢集。叢集節點分佈在地區內的兩個或更多區域。主要區域中有一個 Kubernetes 控制層。
  • 地區叢集。叢集節點分佈在地區內的兩個或更多區域。地區叢集含有多個控制層備用資源,並在該地區的多個區域中執行。

Transcriber 服務使用 Kubernetes 領導者 (稍後討論) 來協助管理 Speech-to-Text 的通訊。領先者需要與 Kubernetes 控制層進行互動。為了充分發揮主要選舉程序的效益,請務必在多個區域中提供控制層。因此,地區叢集對轉錄應用程式而言是穩固的選擇。

跨區域部署應用程式微服務

地區 GKE 叢集含有在特定地區的多個區域中執行的控制節點,以及控制層的備用資源。只要使用 Kubernetes Deployment 物件,您就能以備援方式部署微服務的多個備用資源,而 Kubernetes 預設會在} 節點。

Deployment 代表多組相同的 Pod。Deployment 是由 Kubernetes Deployment 控制器代管。如果備用資源失敗或沒有回應,控制器會自動取代備用資源。透過這種方式,Deployment 可協助確保應用程式微服務可以有一或多個執行個體處理要求。

您可以建立部署,且每個微服務至少具有兩個備用資源:IngestorTranscriberReviewer。這樣一來,每個微服務就能在多個區域中備援。

使用負載平衡服務提供音訊擷取的穩定 IP 位址

來源音訊串流可能源自於包含專用硬體和軟體的內部部署基礎架構。語音轉錄應用程式應提供穩定的目標 IP 位址,以便用於傳送音訊。如此一來,來源基礎架構就不需要經常重新設定。但 Deployment 中的 Pod 會隨時變更,而其 IP 位址會變更。如要將穩定版 IP 位址指派給 Deployment,您必須建立 Kubernetes 服務

Kubernetes Service 物件可讓您將一組 Pod 公開為單一資源。Service 會接收單一穩定的 IP 位址,用戶端可使用該 Pod 來存取 Pod。服務類型可控管服務如何對內部和外部流量公開。例如,當您建立 LoadBalancer 類型的 Service 時,GKE 會自動在您的專案中建立相關聯的 Google Cloud 負載平衡器。如要瞭解如何將不同類型的負載平衡與您服務搭配使用,請參閱 GKE 網路總覽

應用程式部署在單一地區,且可能需要支援使用 HTTP 以外通訊協定傳送的音訊串流。因此,外部地區 TCP/UDP 網路負載平衡器對於 Ingestor 服務而言是個很好的起點。此負載平衡器有一個可從外部存取且穩定的外部 IP 位址,且該位址可在可用的 Ingestor Pod 之間分配流量。

使用串流辨識功能即時轉錄音訊

Speech-to-Text 使用串流辨識要求支援即時轉錄。串流辨識會透過 Speech-to-Text 建立雙向的 gRPC 串流;您在要求串流中傳送音訊,然後在回應串流中以非同步方式接收轉錄結果。

下列指南可協助您從 Speech-to-Text 取得最佳結果:

  • 使用用戶端程式庫,簡化與 Speech-to-Text 的互動。舉例來說,用戶端程式庫會匯總 gRPC 通訊,讓您專心處理業務邏輯。
  • 如要進一步瞭解如何取樣來源音訊及編碼,請按照最佳做法建議和最佳化指南進行。
  • 設定交錯結果標記。這項功能會指示 Speech-to-Text 傳回暫定轉錄內容,而不必等候結果。這很適合用來連續進行音訊串流。
  • 請測試各種可能適用於您用途的其他設定選項。例如自動標點符號字詞層級信賴度說話者分段標記 101}可能會提供額外的實用資訊。(部分語言版本可能不支援這些功能。如需您所用語言適用的功能資訊,請參閱支援的功能頁面)。

使用主要備用資源處理 Speech-to-Text 與有狀態的互動,以便有效進行容錯移轉

使用 Speech-to-Text 建立的雙向串流連線為有狀態,因為在收到後續音訊區塊時,Speech-to-Text 傳回的暫時轉錄結果可能會隨之改變。因此,音訊資料應以單一長時間連線傳送。

然而,為了提高可用性,Transcriber 服務的 Pod 會在該地區的多個區域之間備援。因此,您需要配置機制,將其中一個 Pod 指定為主要 Pod,或稱為「領導者」。只有主要 Pod 會取用佇列中的音訊資料,並將其傳送至 Speech-to-Text;其他 Pod 做為容錯移轉的熱待命。這稱為領導者選舉模式。

Kubernetes Go 用戶端提供勝出的導入實作與範例,說明使用方式。候選程序會爭取由 Kubernetes 控制層代管的鎖具。其中一個程序取得鎖定,並在一段特定時間內成為領導品牌。領導者會持續傳送活動訊號,以更新其排名,而其他求職者也會定期嘗試成為領導品牌。如果領導者沒有在定義的時間範圍內更新其位置,則其中一位另一位被選擇的待開發客戶可以取得鎖定。

在這個應用程式中使用主要選舉項目,有助於在發生失敗或服務中斷時,將語音轉錄延遲降到最低。使用主要選舉時,如果其他領導者失敗,其他 Pod 正在等待繼續轉錄,因此您不需要等待 Kubernetes 部署新的 Pod。

領導者的投票設定消耗較多的叢集資源,而非單一 Pod 設定,因為非前置的 Pod 通常沒有閒置。不過,針對易受延遲時間影響的轉錄應用程式,您必須支付額外的費用。

主要選舉邏輯可在每個 Transcriber Pod 中部署為補充容器。這有助於區分領導者的邏輯邏輯和核心轉錄邏輯。

如要進一步瞭解使用 Kubernetes 的領導者,請參閱 Kubernetes 網誌的使用 Kubernetes 和 Docker 進行簡易領導者選舉

使用 Memorystore 快速中繼儲存空間

將應用程式部署到一組鬆散的微服務,讓您的架構具有更大的彈性。不過,這也表示您需要一個機制,才能將資料從一個圖層傳遞到另一個圖層。

如為即時轉錄用途,處理延遲和順序是關鍵需求。由於語音轉錄是即時產生,因此請務必快速移動應用程式中的資料,並將任何可能會引發語音轉錄延遲情形降到最低。此外,也要按照正確的順序處理音訊片段,否則轉錄內容可能不完整或不正確。

Memorystore for Redis 提供快速的記憶體內建儲存空間,適合需要即時資料處理的使用案例。對轉錄應用程式而言, Memorystore 是絕佳的選擇,原因如下:

  • :資料會儲存在記憶體中,而非磁碟上。與磁碟互動可比在磁碟上互動更有效率。
  • 彈性:Redis 提供實用的資料結構和指令,協助您儲存和處理資料。此外,還有 Redis 用戶端程式庫
  • 開啟: Memorystore for Redis 與開放原始碼 Redis 完全相容。
  • 全代管:Premium 是全代管服務,讓您能專注在應用程式上,無須費心管理基礎架構。
  • 高可用性標準級的 Memorystore for Redis 執行個體會自動跨區域複製,並監控健康狀態。另外還具備快速的容錯移轉功能。詳情請參閱高可用性說明文件。

使用 Memorystore for Redis 做為可靠的佇列

Redis 清單常做為排序佇列。針對這個轉錄應用程式,系統會假設接收的是原始音訊資料。因此,Ingestor 服務可以將音訊資料寫入已命名的佇列,而 Transcriber 服務可以從佇列取用。Redis 所提供的指令可讓 Transcriber 服務有效率地封鎖,直到佇列中有資料為止。

由於 Speech-to-Text 以非同步的方式傳回串流結果,您必須謹慎選擇失敗時的語音轉錄損失。舉例來說,您可以使用第二個 Redis 佇列暫時暫時傳送到傳送至 Speech-to-Text 的音訊最後 N 秒。如果發生失敗,且選擇新的 Transcriber Pod 勝出,新領導者會先讀取第二個佇列,然後重新將先前收到的音訊傳送到 Speech-to-Text,然後再處理主要佇列。RedisBRLLPUSH 「命令」是一種從統一清單中讀取內容並加入清單的常用方法,可靠的佇列用途。請注意,這種方法可能會重複轉錄片段。語音轉錄的下游消費者必須管理任何可能的重複項目。(本文說明如何管理可能的重複作業)。

評估 Pub/Sub 做為 Memorystore 的替代方案

Pub/Sub 是可擴充、可用性高且耐用的事件擷取和傳送系統。Pub/Sub 提供低延遲的非同步訊息傳遞,將寄件者和接收方拆分。 Pub/Sub 通常用於從應用程式的某個部分傳送事件和資料。

您可以使用 Pub/Sub 做為轉錄應用程式的替代方案。例如,不要將擷取到的音訊資料儲存在 Redis 中,並在稍後讀取 Transcriber 服務,而是改用 Pub/Sub 將音訊發布至已使用的訂閱由「Transcriber」服務提供。

Pub/Sub 提供下列功能:

  • 全域可用性
  • 極為高擴充性
  • 使用跳轉功能可輕鬆地重新傳送訊息,對應用程式復原而言很實用
  • 無伺服器部署模式,讓您用多少付多少

但是 Pub/Sub 也具有以下限制:

  • 我們無法保證郵件傳送順序。
  • Pub/Sub At-Least-After Delivery 功能可能會傳送多次訊息,代表可能發生重複情形。
  • Pub/Sub 將訊息寫入儲存空間,因而增加延遲時間。

視您的用途而定,您也許可以忽略或處理上清單中的限制,而 Pub/Sub 可能有好處。您必須評估這兩種技術,以決定哪種方式最適合您的情境。

使用語音調整功能為 Speech-to-Text 提供轉錄提示

按照本文件所列的規範,Speech-to-Text 就能提供準確的結果。如要進一步提高轉錄準確率,您可以使用語音調整,為 Speech-to-Text 提供其他背景資訊。

透過語音調整功能,將語音轉錄要求傳送至 Speech-to-Text 時,您必須加入提示字詞和詞組清單做為提示。這些提示可協助 Speech-to-Text 辨識音訊資料中指定的詞組。例如,如果您的直播影片串流是由某人說出天氣相關,包括與天氣相關的常見字詞,可能有助於改善語音轉錄的精確度。

在實際工作環境中,您可能會想要建立可隨需求擷取的字典字典。舉例來說,如果您的應用程式正在監控電視天氣廣播,應用程式可以擷取先前建立的天氣字詞字典。不過,如果廣播的相關動作與高爾夫球場相關,應用程式可以擷取高爾夫球場字詞的字典和玩家的名稱。

但如果是進階用途,字典就能即時更新。受過訓練的人工審查員可即時監控輸出轉錄內容並即時修改字典。Transcriber 服務會監聽字典變更事件的通知,並擷取並使用已更新的字典來連線至 Speech-to-Text。

為每個來源音訊串流建立個別的轉錄器部署作業

播送者通常會執行多個頻道,而且可能想要同時對多個頻道產生轉錄稿。每個管道都代表不同的來源音訊串流。您的應用程式必須維持與 Speech-to-Text 的連線,才能轉錄每個聲道。有幾個方法

方法之一就是直接在 Transcriber 邏輯中管理一組管道。這種做法能簡化 GKE 叢集,因為叢集中只有一個 Transcriber 部署。不過,這種方法會增加語音轉錄邏輯的複雜性,因為必須維護和管理一組有效的管道和連線。這種做法也可讓您每個管道使用不同的設定 (例如不同的提示字典或不同的優先順序),因為所有管道都在單一部署中作業。

建議您為每個管道建立專屬的 Transcriber Deployment。這麼做可簡化應用程式邏輯,因為每個 Transcriber 執行個體會管理 Speech-to-Text 的單一串流連線。這種做法有下列優點:

  • 彈性:建立部署作業,讓每個管道有不同的設定。例如,相較於標準管道,進階頻道可提供更多的叢集資源。
  • 隔離:您可以將每個轉錄管道視為不同的實體。
  • 資源效率:與管理單一大型 Deployment 相比,Kubernetes 在叢集資源上更能發布多個較小的 Transcriber Deployment。

使用標籤或命名空間,依管道為資源分組

Kubernetes 提供一些功能,能將相關資源分組。您可以使用這些功能來為每個聲道區隔叢集資源,如下所示:

  • 標籤是鍵/值組合,會附加至 Kubernetes 叢集中的物件,例如 Pod。您可以使用標籤來整理及選取部分物件。
  • 命名空間是一種分割叢集資源的方法。您可以將 Namespace 視為 Kubernetes 叢集中的虛擬叢集。一個 Kubernetes 叢集中可以有多個 Namespace,且這些命名空間彼此邏輯是各自獨立的。

透過標籤和命名空間,您可以部署針對特定管道設定的個別 Transcriber 執行個體。標籤可讓你輕鬆快速地將資源分組。命名空間可提供更正式的區隔。如果你想控制每個管道使用的叢集資源,或是由不同的團隊管理,就很適合使用這個方案。

跨來源音訊串流共享資源

如前一節所述,為每個來源音訊管道建立一個不同的 Transcriber 執行個體。視語音轉錄應用程式的需求而定,您也可以為每個管道建立專屬的 IngestorReviewer Deployment。如果符合以下任一限制,這個方法可能會相當複雜:

  • 您需要在整個應用程式中,為個別管道設定高度隔離。舉例來說,每個頻道是由獨立的團隊負責管理。
  • Ingestor 服務使用的是無法輕鬆處理多個串流的第三方軟體。
  • Reviewer」應用程式為每個管道自訂行為。

但是,選擇鬆散的架構的優點之一,就是可以為各項服務選擇不同的資源調度和部署策略。如果上文所列的限制不適用,在多個管道之間共用 IngestorReviewer 服務可能不太容易。例如,在單一部署中處理多個管道的好處如下:

  • Kubernetes Service 可公開多個通訊埠,且每個管道可指定不同的通訊埠。之後,IngestorReviewer 服務就能各自提供單一負載平衡器,進而讓每個頻道都使用單一外部 IP 位址。進而降低成本與管理負擔。
  • 同樣地,我們也建議您將應用程式公開的外部 IP 位址數量降到最低。
  • 您可以使用自動調度資源功能,為部署在網路並離線的要求,調整 Deployment 的資源配置。

共用 Memorystore for Redis

共用資源的相同註意事項也適用於 Redis 的 Redis。為每個管道建立個別的 Memorystore 執行個體,將管道分開。但會增加費用及管理管理負擔。

Redis 是專為高總處理量而設計,因此為每個管道建立專屬的 Memorystore 執行個體可能不是資源的有效使用。如果您有清除管道的需求,可以在 GKE 叢集中執行 Redis 來代替 Memorystore。在此方法中,您會為叢集中的每個管道建立 Redis 部署。不過,您必須自行管理 Redis,要以高可用性設定操作 Redis 可能會相當困難。如要進一步瞭解如何在 Kubernetes 中執行 Redis,請參閱範例:使用 Redis 部署 PHP 留言板應用程式

如先前所述, Memorystore for Redis 專為高效能而設計,且單一執行個體應能提供多個並行管道。另請注意, Memorystore for Redis 可視需要進行資源調度,以新增或移除容量。透過這種方式,您可以在各個管道之間共用單一記憶體存放區,並視需求增加或縮減執行個體。如果您要在多個管道之間共用 Memorystore 執行個體,則可使用管道 ID 做為 Redis 金鑰的前置字串。

導入失敗測試,藉此恢復應用程式彈性

對生產轉錄應用程式而言,彈性是關鍵需求。如果故障或服務中斷,您的應用程式應可快速繼續執行轉錄,將轉錄作業降到最低。

本文所述的架構包含幾項功能,以提高彈性:

  • Transcriber 服務會使用主要選舉期間,如果目前的領導人發生錯誤,可有效容錯移轉至熱待命 Pod。
  • 應用程式會利用 Redis 可靠的佇列功能,將故障時的資料遺失降到最低。
  • 此架構包含具有相關聯負載平衡器的 Kubernetes Service。Google Cloud 負載平衡器包含健康狀態檢查,可驗證基礎運算節點是否健康狀態良好。
  • 應用程式服務會跨區域備援部署,以協助防範區域故障。
  • 每個應用程式服務都是 Kubernetes Deployment,可讓您指定所需的 Pod 備用資源數量。如果 Pod 當機或遭到刪除,Kubernetes 會自動重新建立 Pod,以滿足您設定的備用資源數量。
  • 標準級的 Memorystore for Redis 執行個體會自動跨區域複製,並監控健康狀態。並具備快速的自動容錯移轉功能。

雖然無法針對可能發生的所有錯誤或服務中斷進行測試,但您還是可以導入失敗並檢查結果,藉此進一步瞭解您的應用程式。測試故障與復原時,請務必定義目標和期望。針對某些用途,系統可能會接受某些層級的語音轉錄損失。其他用途可能設有最低要求,以盡量減少轉錄損失。因此,您可以提前定義復原目標,以協助您評估目標的達成進度。

失敗模式的完整討論不在本文件的討論範圍內。以下各節說明可執行應用程式的恢復測試的一些基準測試。

刪除 Kubernetes Pod

如要在應用程式中導入故障,其中一種方式就是從 GKE 叢集刪除 Kubernetes Pod,這是 Chaos 工程的一種。簡單的方法是編寫自訂指令碼,每隔一段時間就隨機刪除 Pod。此外,有許多第三方工具還可針對 Kubernetes 叢集執行 Chaos 測試。刪除 Pod 時,您必須以實際方式測試每項應用程式服務的行為。

執行 Memorystore 手動容錯移轉

Memorystore for Redis 標準級執行個體會透過複製和自動容錯移轉功能來提供高可用性。為了容許區域故障情形,主要和備用資源位於同一地區內的不同區域。當主要 Redis 執行個體故障時會發生容錯移轉。

Memorystore 容錯移轉會對應用程式造成下列影響:

  • 當主要執行個體容錯移轉至備用資源時,與 Memorystore for Redis 的現有連線均會遭到捨棄。不過在重新連線時,系統會使用相同的連線字串或 IP 位址,將您的應用程式自動重新導向至新的主要執行個體。
  • Memorystore for Redis 服務會將備用資源升級為主要執行個體,但是 Memorystore for Redis 執行個體暫時無法使用。

如要測試在這些條件下的行為,您可以啟動手動容錯移轉。容錯移轉通常會導致資料遺失。您應該衡量損失程度,並判斷哪一種用途最適合自己的用途。

後續步驟