從 AWS 遷移至 Google Cloud：從 AWS Lambda 遷移至 Cloud Run

Last reviewed 2024-10-21 UTC

Google Cloud 提供工具、產品、指南和專業服務，協助您將無伺服器工作負載從 Amazon Web Services (AWS) Lambda 遷移至 Google Cloud。雖然 Google Cloud 提供多項服務，可用於開發及部署無伺服器應用程式，但本文著重於遷移至 Cloud Run，這是無伺服器執行階段環境。AWS Lambda 和 Cloud Run 有許多相似之處，例如自動資源佈建、雲端服務供應商的調整，以及按用量計費的定價模式。

本文件可協助您設計、實作及驗證將無伺服器工作負載從 AWS Lambda 遷移至 Cloud Run 的計畫。此外，這份指南也提供指引，協助您評估這類遷移作業的潛在效益和程序。

本文是從 AWS 遷移至Google Cloud 的多部分系列文章之一，其中包含以下文件：

如要進一步瞭解如何為您的業務邏輯挑選合適的無伺服器執行階段環境，請參閱「選取受管理的容器執行階段環境」。如需 AWS 與 Google Cloud 服務之間的完整對應表，請參閱比較 AWS 和 Azure 服務與 Google Cloud 服務。

針對這項遷移至 Google Cloud的作業，建議您按照「遷移至 Google Cloud：開始使用」一文所述的遷移架構進行。

以下是遷移流程圖。

列出四個階段的遷移路徑。

您可以透過一系列的迭代作業，從來源環境遷移至 Google Cloud 。舉例來說，您可以先遷移部分工作負載，再遷移其他工作負載。針對每個個別遷移疊代作業，您都必須遵循一般遷移架構的各個階段：

  1. 評估及探索工作負載和資料。
  2. 規劃並建立 Google Cloud基礎。
  3. 將工作負載和資料遷移至 Google Cloud。
  4. 最佳化調整 Google Cloud 環境。

如要進一步瞭解這個架構的各個階段，請參閱「遷移至 Google Cloud：入門指南」。

如要設計有效的遷移計畫，建議您驗證計畫的每個步驟，並確保您有復原策略。如要驗證遷移計畫，請參閱「遷移至 Google Cloud：驗證遷移計畫的最佳做法」。

遷移無伺服器工作負載時，通常不只是將函式從一個雲端服務供應商移至另一個。由於雲端應用程式仰賴相互連結的服務網，因此從 AWS 遷移至 Google Cloud 可能需要將依附的 AWS 服務替換為 Google Cloud 服務。舉例來說，假設您的 Lambda 函式會與 Amazon SQS 和 Amazon SNS 互動，如要遷移這個函式，您可能需要採用 Pub/Sub 和 Cloud Tasks 來實現類似的功能。

遷移作業也是讓您徹底檢查無伺服器應用程式架構和設計決策的絕佳機會。透過這項審查，您可能會發現以下機會：

  • 運用 Google Cloud 內建功能進行最佳化：瞭解Google Cloud 服務是否提供獨特優勢，或能更符合應用程式需求。
  • 簡化架構：評估是否可以透過合併功能或在Google Cloud中以不同方式使用服務，來簡化流程。
  • 提高成本效益：評估在 Google Cloud上提供的基礎架構中，執行已重構應用程式時的潛在成本差異。
  • 提高程式碼效率：在遷移程序中重構程式碼。

有策略地規劃遷移作業。請勿將遷移作業視為重新部署 (升遷和轉移) 作業。您可以利用遷移作業，提升無伺服器應用程式的整體設計和程式碼品質。

評估來源環境

在評估階段，您必須確定將來源環境遷移至 Google Cloud時的需求和依附元件。

評估階段是您能否成功遷移的關鍵。您必須深入瞭解要遷移的工作負載、工作負載的要求和依附元件，以及您目前的環境。此外，您還必須知道要從何踏出第一步，以成功規劃並執行 Google Cloud遷移作業。

評估階段包含下列工作：

  1. 建立工作負載的完整清單。
  2. 根據工作負載的屬性和依附元件將其編目。
  3. 訓練並教導您的團隊使用 Google Cloud。
  4. 在 Google Cloud上建立實驗和概念驗證。
  5. 計算目標環境的總持有成本 (TCO)。
  6. 選擇工作負載的遷移策略。
  7. 選擇遷移工具。
  8. 定義遷移計畫和時程。
  9. 驗證遷移計畫。

如要進一步瞭解評估階段和這些工作，請參閱「遷移至 Google Cloud：評估及探索工作負載」。以下各節皆以該文件中的資訊為依據。

建立 AWS Lambda 工作負載清單

如要定義遷移範圍，您必須建立清單並收集 AWS Lambda 工作負載的相關資訊。

如要建立 AWS Lambda 工作負載的清單，建議您採用 AWS API、AWS 開發人員工具和 AWS 指令列介面，實作資料收集機制。

建立清單後，建議您收集清單中每個 AWS Lambda 工作負載的相關資訊。針對每項工作負載，請著重於有助於預測潛在摩擦力的部分。此外，請分析該工作負載，瞭解遷移至 Cloud Run 前，可能需要如何修改工作負載及其依附元件。建議您先收集每個 AWS Lambda 工作負載的下列方面資料：

  • 用途和設計
  • 原始碼存放區
  • 部署構件
  • 叫用、觸發條件和輸出
  • 執行階段和執行環境
  • 工作負載設定
  • 存取權控管和權限
  • 法規遵循和監管要求
  • 部署和作業流程

用途和設計

收集工作負載的用途和設計相關資訊，有助於找出合適的遷移策略。這項資訊也有助您瞭解是否需要在遷移前修改工作負載及其依附元件。針對每個工作負載，我們建議您執行下列操作：

  • 深入瞭解工作負載所提供的特定用途，並找出與其他系統、資源或程序的任何依附元件。
  • 分析工作負載的設計和架構。
  • 評估工作負載的延遲要求。

原始碼存放區

如果您需要重構 AWS Lambda 工作負載以便與 Cloud Run 相容，建議您先盤點 AWS Lambda 函式的原始程式碼。建立這份清單時，您必須追蹤程式碼集，這類資料通常會儲存在 Git 等版本管控系統，或是 GitHub 或 GitLab 等開發平台中。原始程式碼的清單對於 DevOps 程序 (例如持續整合和持續開發 (CI/CD) 管道) 至關重要，因為在遷移至 Cloud Run 時，這些程序也需要更新。

部署構件

瞭解工作負載所需的部署構件是另一個有助於您瞭解是否需要重構 AWS Lambda 工作負載的元件。如要找出工作負載需要的部署構件，請收集下列資訊：

  • 用於部署工作負載的部署套件類型。
  • 任何包含額外程式碼的 AWS Lambda 層，例如程式庫和其他依附元件。
  • 工作負載所依賴的任何 AWS Lambda 擴充功能。
  • 您設定用來指定版本和別名的限定詞。
  • 已部署的工作負載版本。

叫用、觸發條件和輸出

AWS Lambda 支援多種叫用機制，例如觸發事件，以及不同的叫用模式，例如同步叫用和非同步叫用。針對每個 AWS Lambda 工作負載，建議您收集以下與觸發事件和叫用作業相關的資訊：

  • 叫用工作負載的觸發條件和事件來源對應項目。
  • 工作負載是否支援同步和非同步叫用。
  • 工作負載網址和 HTTP(S) 端點。

AWS Lambda 工作負載可與其他資源和系統互動。您必須瞭解哪些資源會使用 AWS Lambda 工作負載的輸出內容，以及這些資源如何使用這些輸出內容。這項資訊有助於您判斷是否需要修改可能依賴這些輸出的任何項目，例如其他系統或工作負載。針對每個 AWS Lambda 工作負載，我們建議您收集其他資源和系統的以下資訊：

  • 工作負載可能會傳送事件的目的地資源。
  • 接收非同步叫用動作資訊記錄的目的地。
  • 工作負載處理事件的格式。
  • AWS Lambda 工作負載及其擴充功能如何與 AWS Lambda API 或其他 AWS API 互動。

為了運作，AWS Lambda 工作負載可能會儲存持續性資料，並與其他 AWS 服務互動。針對每項 AWS Lambda 工作負載，建議您收集以下關於資料和其他服務的資訊：

  • 工作負載是否存取虛擬私有雲 (VPC) 或其他私人網路。
  • 工作負載儲存永久性資料的方式，例如使用暫時性資料儲存空間和 Amazon Elastic File System (EFS)。

執行階段和執行環境

AWS Lambda 支援多種工作負載執行環境。為正確將 AWS Lambda 執行環境對應至 Cloud Run 執行環境，建議您針對每個 AWS Lambda 工作負載評估下列項目：

  • 工作負載的執行環境。
  • 工作負載執行的電腦處理器指令集架構。

如果您的 AWS Lambda 工作負載是在特定語言的執行階段環境中執行，請針對每個 AWS Lambda 工作負載考量下列事項：

  • 特定語言的執行階段環境類型、版本和專屬 ID。
  • 您對執行階段環境所做的任何修改。

工作負載設定

為了在將工作負載從 AWS Lambda 遷移至 Cloud Run 時設定工作負載，建議您評估如何設定每個 AWS Lambda 工作負載。

針對每個 AWS Lambda 工作負載，收集下列並行性和可擴充性設定的相關資訊：

  • 並行控制項。
  • 可擴充性設定。
  • 工作負載執行個體的設定，包括可用的記憶體量和允許的最大執行時間。
  • 工作負載是否使用 AWS Lambda SnapStart、保留並行處理或佈建的並行處理，以便縮短延遲時間。
  • 您設定的環境變數，以及 AWS Lambda 設定的環境變數，以及工作負載依附的環境變數。
  • 標記和屬性存取權控管。
  • 用於處理例外狀況的狀態機器。
  • 使用容器映像檔的部署套件所需的基本映像檔和設定檔 (例如 Dockerfile)。

存取權控管和權限

在評估過程中，我們建議您評估 AWS Lambda 工作負載的安全性需求，以及這些工作負載的存取控制和管理設定。如果您需要在 Google Cloud 環境中實作類似的控管措施，這項資訊就非常重要。針對每項工作負載，請考慮下列事項：

  • 執行角色和權限。
  • 工作負載及其層用來存取其他資源的身分與存取權管理設定。
  • 其他帳戶和服務用來存取工作負載的身分和存取權管理設定。
  • 治理控制項。

法規遵循和法規要求

針對每個 AWS Lambda 工作負載，請務必瞭解其法規遵循和法規要求，方法如下：

  • 評估工作負載必須遵循的法規和監管規定。
  • 判斷工作負載目前是否符合這些要求。
  • 判斷是否有任何未來需要滿足的需求。

法規遵循和監管規定可能與您使用的雲端服務供應商無關，且這些規定可能也會影響遷移作業。舉例來說，您可能需要確保資料和網路流量維持在特定地理區域 (例如歐洲聯盟 (EU)) 的範圍內。

評估部署和作業流程

請務必清楚瞭解部署和作業程序的運作方式。這些程序是準備及維護實際工作環境和在其中執行的工作負載的做法中，不可或缺的部分。

您的部署和作業程序可能會建構工作負載運作所需的構件。因此，您應收集各個構件類型的相關資訊。例如，構件可以是作業系統套件、應用程式部署套件、作業系統映像檔、容器映像檔或其他項目。

除了定義構件類型之外，請考慮如何完成下列工作：

  • 開發工作負載。評估開發團隊建構工作負載的程序。舉例來說，您的開發團隊如何設計、編寫程式碼及測試工作負載？
  • 產生要在來源環境中部署的構件。如要在來源環境中部署工作負載，您可能會產生可部署的構件，例如容器映像檔或作業系統映像檔，或者您可能會透過安裝及設定軟體，自訂現有構件，例如第三方作業系統映像檔。收集您產生這些構件的相關資訊，有助於確保產生的構件適合在Google Cloud中部署。

  • 儲存成果。如果您產生的構件儲存在來源環境的構件登錄中，就必須在 Google Cloud 環境中提供構件。您可以採用下列策略來達成這點：

    • 建立環境之間的通訊管道：讓來源環境中的構件可從目標Google Cloud 環境存取。
    • 重構構件建構程序：完成來源環境的次要重構，以便在來源環境和目標環境中儲存構件。這種方法會在您必須在目標 Google Cloud環境中實作構件建構程序之前，先建構構件存放區等基礎架構，以便支援遷移作業。您可以直接實作這項做法，也可以先建立溝通管道，再實作這項做法。

    在來源和目標環境中都提供構件，可讓您專注於遷移作業，而無須在目標 Google Cloud 環境中實作構件建構程序。

  • 掃描並簽署程式碼。在建構過程中，您可能會使用程式碼掃描功能來防範常見的安全漏洞和意外曝露的網路，並使用程式碼簽署功能，確保環境中只執行可信任的程式碼。

  • 在來源環境中部署構件。產生可部署的構件後，您可能會在來源環境中部署這些構件。建議您評估每個部署程序。這項評估有助於確保您的部署程序與 Google Cloud相容。這也有助您瞭解最終重構程序所需的努力程度。舉例來說，如果您的部署程序只適用於來源環境，您可能需要重構這些程序，以便指定 Google Cloud 環境。

  • 插入執行階段設定。您可能會為特定叢集、執行階段環境或工作負載部署作業，注入執行階段設定。設定可能會初始化環境變數和其他設定值，例如機密資料、憑證和金鑰。為確保您的執行階段設定注入程序可在 Google Cloud上運作，建議您評估如何設定在來源環境中執行的工作負載。

  • 記錄、監控和分析。評估您用來監控來源環境健康狀態、感興趣的指標，以及如何使用這些程序提供的資料的記錄、監控和剖析程序。

  • 驗證：評估您如何在來源環境中進行驗證。

  • 佈建及設定資源。為準備來源環境，您可能已設計及實作佈建及設定資源的程序。舉例來說，您可能會使用 Terraform 搭配設定管理工具，在來源環境中佈建及設定資源。

完成評估

從 AWS Lambda 環境建立清單後，請按照「遷移至 Google Cloud：評估及探索工作負載」一文所述，完成評估階段的其他活動。

規劃及建立基礎

在規劃和建構階段，您會佈建及設定基礎架構，以便執行下列工作：

  • 在 Google Cloud 環境中支援工作負載。
  • 連結來源環境和 Google Cloud 環境，完成遷移作業。

規劃和建構階段包含下列工作：

  1. 建立資源階層。
  2. 設定 Google Cloud的 Identity and Access Management (IAM)。
  3. 設定帳單資訊。
  4. 設定網路連線。
  5. 強化安全性。
  6. 設定記錄、監控和快訊功能。

如要進一步瞭解這些任務，請參閱「遷移至 Google Cloud：規劃並建立基礎」一文。

遷移 AWS Lambda 工作負載

如要將工作負載從 AWS Lambda 遷移至 Cloud Run，請執行下列操作：

  1. 設計、佈建及設定 Cloud Run 環境。
  2. 如有需要，請重構 AWS Lambda 工作負載，使其與 Cloud Run 相容。
  3. 重構部署和作業程序，以便在 Cloud Run 上部署及觀察工作負載。
  4. 遷移 AWS Lambda 工作負載所需的資料。
  5. 驗證遷移結果的功能、效能和成本。

為協助您在遷移期間避免問題，並估算遷移所需的努力程度，建議您評估 AWS Lambda 功能與類似的 Cloud Run 功能有何差異。比較 AWS Lambda 和 Cloud Run 的功能時，兩者可能看起來很相似。不過，兩個雲端服務供應商在功能設計和實作上的差異，可能會對您從 AWS Lambda 遷移至 Cloud Run 的過程造成重大影響。這些差異可能會影響設計和重構的決策，如後續章節所述。

設計、佈建及設定 Cloud Run 環境

遷移階段的第一步，是設計 Cloud Run 環境，以便支援您從 AWS Lambda 遷移的工作負載。

為了正確設計 Cloud Run 環境，請使用您在評估階段收集的各個 AWS Lambda 工作負載資料。這類資料可協助您執行下列操作：

  1. 選擇合適的 Cloud Run 資源來部署工作負載。
  2. 設計 Cloud Run 資源設定。
  3. 佈建及設定 Cloud Run 資源。

選擇合適的 Cloud Run 資源

針對要遷移的每個 AWS Lambda 工作負載，請選擇合適的 Cloud Run 資源來部署工作負載。Cloud Run 支援下列主要資源：

  • Cloud Run 服務：這類資源會代管容器化執行階段環境、公開不重複的端點，並根據需求自動調整底層基礎架構的資源配置。
  • Cloud Run 工作：執行一或多個容器，直到完成為止的資源。

下表概要說明 AWS Lambda 資源如何對應至這些主要的 Cloud Run 資源：

AWS Lambda 資源 Cloud Run 資源
會因事件而觸發的 AWS Lambda 函式，例如用於網站和網路應用程式、API 和微服務、串流資料處理作業，以及事件導向架構的事件。 可透過觸發事件叫用的 Cloud Run 服務。
已排定執行的 AWS Lambda 函式，例如背景工作和批次作業的函式。 執行至完成的 Cloud Run 工作。

除了服務和工作之外，Cloud Run 還提供其他資源，可擴充這些主要資源。如要進一步瞭解所有可用的 Cloud Run 資源，請參閱「Cloud Run 資源模型」。

設計 Cloud Run 資源設定

在您佈建及設定 Cloud Run 資源之前，請先設計相關設定。某些 AWS Lambda 設定選項 (例如資源限制和要求逾時) 與類似的 Cloud Run 設定選項相當。以下各節將說明 Cloud Run 可用於服務觸發事件和工作執行作業、資源設定和安全性的設定選項。這些部分也會強調與 Cloud Run 相似的 AWS Lambda 設定選項。

Cloud Run 服務觸發事件和工作執行作業

服務觸發事件和工作執行作業是遷移 AWS Lambda 工作負載時，需要考量的設計決策。Cloud Run 提供多種選項，可觸發並執行 AWS Lambda 中使用的事件導向工作負載。此外，Cloud Run 也提供可用於串流工作負載和排程工作的工作選項。

遷移工作負載時，通常建議先瞭解 Cloud Run 提供的觸發事件和機制。這項資訊有助於您瞭解 Cloud Run 的運作方式。接著，您可以根據這些瞭解，判斷哪些 Cloud Run 功能與 AWS Lambda 功能相近，以及在重構這些工作負載時，可使用哪些 Cloud Run 功能。

如要進一步瞭解 Cloud Run 提供的服務觸發事件，請參閱以下資源：

如要進一步瞭解 Cloud Run 提供的工作執行機制，請參閱以下資源：

如要瞭解哪些 Cloud Run 叫用或執行機制可與 AWS Lambda 叫用機制相提並論，請參閱下表。針對您需要佈建的每個 Cloud Run 資源，請務必選擇正確的叫用或執行機制。

AWS Lambda 功能 Cloud Run 功能
HTTPS 觸發條件 (函式網址) HTTPS 叫用
HTTP/2 觸發事件 (使用外部 API 閘道部分支援) HTTP/2 叫用 (原生支援)
WebSocket (使用外部 API 閘道支援) WebSocket (原生支援)
不適用 (不支援 gRPC 連線) gRPC 連線
非同步叫用 Cloud Tasks 整合
排定的叫用 與 Cloud Scheduler 整合
以專屬事件格式提供的事件觸發條件 以 CloudEvents 格式以事件為基礎的叫用
Amazon SQS 和 Amazon SNS 整合 Pub/Sub 整合
AWS Lambda 步驟函式 工作流程整合
。
Cloud Run 資源設定

為了補充您為觸發及執行已遷移的工作負載所做的設計決策，Cloud Run 支援多種設定選項，可讓您微調執行階段環境的多個面向。這些設定選項包括資源服務和工作。

如先前所述，您可以先瞭解 Cloud Run 提供的所有設定選項，進一步掌握 Cloud Run 的運作方式。有了這些知識，您就能比較 AWS Lambda 功能與類似的 Cloud Run 功能，並決定如何重構工作負載。

如要進一步瞭解 Cloud Run 服務提供的設定，請參閱下列資源：

如要進一步瞭解 Cloud Run 提供的工作，請參閱下列資源：

如要瞭解哪些 Cloud Run 設定選項與 AWS Lambda 設定選項相似，請參閱下表。針對每個需要佈建的 Cloud Run 資源，請務必選擇正確的設定選項。

AWS Lambda 功能 Cloud Run 功能
已佈建並行 執行個體數量下限
每個執行個體的預留並行處理量
(並行處理資源池會在 AWS 帳戶中的 AWS Lambda 函式之間共用)。		 每項服務的執行個體數量上限
不適用 (不支援，一個要求對應至一個執行個體) 每個執行個體的並行要求
不適用 (取決於記憶體配置) CPU 分配方式
可擴充性設定 服務的執行個體自動調度功能
工作並行處理
執行個體設定 (CPU、記憶體) CPU 和記憶體限制
執行時間上限 服務要求逾時
工作任務逾時
AWS Lambda SnapStart 啟動時 CPU 效能強化
環境變數 環境變數
暫存資料儲存空間 記憶體內磁碟區掛接
Amazon Elastic File System 連線 NFS 磁碟區掛接
不支援 S3 磁碟機掛載 Cloud Storage 磁碟機掛載
AWS Lambda 工作負載中的 AWS Secrets Manager 密鑰
工作負載網址和 HTTP(S) 端點 自動指派的網址
Cloud Run 與 Google Cloud 產品的整合
持續性工作階段 (使用外部負載平衡器) 工作階段相依性
限定詞 修訂版本

除了上表列出的功能外，您還應考量 AWS Lambda 和 Cloud Run 在執行環境中提供執行個例的方式有何差異。AWS Lambda 會為每個並行要求提供單一例項。不過，Cloud Run 可讓您設定執行個體可服務的並行要求數量。也就是說，AWS Lambda 的佈建行為等同於在 Cloud Run 中將每個執行個體的並行要求數上限設為 1。將並行要求數量上限設為大於 1 可大幅節省成本，因為執行個體的 CPU 和記憶體會由並行要求共用，但只會收取一次費用。大多數 HTTP 架構都是為了並行處理要求而設計。

Cloud Run 安全性和存取權控管

設計 Cloud Run 資源時，您也需要決定遷移工作負載所需的安全性和存取控管機制。Cloud Run 支援多種設定選項，可協助您保護環境安全，並為 Cloud Run 工作負載設定角色和權限。

本節將說明 Cloud Run 提供的安全性和存取權控管機制。這項資訊可協助您瞭解已遷移的工作負載在 Cloud Run 中的運作方式，以及在重構這些工作負載時可能需要的 Cloud Run 選項。

如要進一步瞭解 Cloud Run 提供的驗證機制，請參閱下列資源：

如要進一步瞭解 Cloud Run 提供的安全性功能，請參閱下列資源：

如要瞭解哪些 Cloud Run 安全性和存取控制機制與 AWS Lambda 中的機制相似，請參閱下表。針對您需要佈建的每個 Cloud Run 資源，請務必選擇正確的存取權控管和安全性功能。

AWS Lambda 功能 Cloud Run 功能
使用 AWS 身分存取權和管理功能控管存取權 使用 Google Cloud的 IAM 控管存取權
執行角色 Google Cloud的 IAM 角色
權限範圍 Google Cloud的IAM 權限和自訂目標對象
管理控制項 機構政策服務
程式碼簽署 二進位授權
完整的虛擬私有雲存取權 精細的 VPC 出口存取權控管

佈建及設定 Cloud Run 資源

選擇 Cloud Run 資源來部署工作負載後，請佈建及設定這些資源。如要進一步瞭解如何佈建 Cloud Run 資源，請參閱以下文章：

重構 AWS Lambda 工作負載

如要將 AWS Lambda 工作負載遷移至 Cloud Run，您可能需要重構這些工作負載。舉例來說，如果事件導向工作負載接受含有 Amazon CloudWatch 事件的觸發事件，您可能需要重構該工作負載，讓它接受 CloudEvents 格式的事件。

以下幾項因素可能會影響您為每個 AWS Lambda 工作負載所需的重構作業量：

  • 架構：請考量工作負載的架構設計方式。舉例來說，如果 AWS Lambda 工作負載將商業邏輯與存取 AWS 專屬 API 的邏輯明確區隔，相較於兩種邏輯混合的工作負載，可能需要較少的重構。
  • 冪等性：請考量工作負載是否對輸入內容具有冪等性。相較於需要維護已處理輸入內容狀態的工作負載，輸入內容同質性的工作負載可能需要較少的重構作業。
  • 狀態：請考量工作負載是否為無狀態。與維持狀態的工作負載相比，無狀態工作負載可能需要較少的重構。如要進一步瞭解 Cloud Run 支援的資料儲存服務，請參閱「Cloud Run 儲存空間選項」。
  • 執行階段環境。請考量工作負載是否會對其執行階段環境做出任何假設。針對這類工作負載，您可能需要在 Cloud Run 執行階段環境中滿足相同的假設，如果無法對 Cloud Run 執行階段環境做出相同假設，則需要重構工作負載。舉例來說，如果工作負載需要特定套件或程式庫，您必須在將要代管該工作負載的 Cloud Run 執行階段環境中安裝這些套件或程式庫。
  • 設定插入。請考量工作負載是否支援使用環境變數和機密資料來注入 (設定) 其設定。相較於支援其他設定注入機制的情況，支援這類注入機制的情況可能需要較少的重構工作。
  • API：考量工作負載是否會與 AWS Lambda API 互動。與這些 API 互動的負載可能需要重構，才能使用 Cloud API 和 Cloud Run API。
  • 錯誤回報：請考量工作負載是否使用標準輸出和錯誤串流來回報錯誤。相較於使用其他機制回報錯誤的工作負載，這類工作負載可能需要較少的重構。

如要進一步瞭解如何開發及最佳化 Cloud Run 工作負載，請參閱下列資源：

重構部署和作業程序

重構工作負載後，您可以重構部署和作業程序，以便執行下列操作：

  • 請在 Google Cloud 環境中佈建及設定資源，而非在來源環境中佈建資源。
  • 請建構及設定工作負載，並在 Google Cloud中部署，而非在來源環境中部署。

您在前述評估階段收集了這些程序的相關資訊。

您需要考慮的這些程序重構類型，取決於您設計和實作這些程序的方式。重構作業也取決於您希望每個程序的最終狀態為何。舉例來說，請參考以下情況：

  • 您可能已在來源環境中實作這些程序，並打算在 Google Cloud中設計及實作類似的程序。舉例來說，您可以重構這些程序，以便使用 Cloud Build、Cloud Deploy 和 Infrastructure Manager。
  • 您可能已在來源環境以外的其他第三方環境中實作這些程序。在這種情況下，您需要重構這些程序，以便將目標設為 Google Cloud 環境，而非來源環境。
  • 結合上述方法。

重構部署和作業程序可能相當複雜，且可能需要大量心力。如果您嘗試在工作負載遷移期間執行這些工作，工作負載遷移作業可能會變得更複雜，並且可能會使您面臨風險。評估部署和作業程序後，您可能會瞭解其設計和複雜度。如果您認為需要花費大量心力才能重構部署和營運程序，建議您考慮將這些程序重構為個別專屬專案。

如要進一步瞭解如何在 Google Cloud上設計及實作部署程序，請參閱：

本文件著重於部署程序，說明如何產生要部署的構件，並在目標執行階段環境中部署這些構件。重構策略在很大程度上取決於這些程序的複雜度。以下列出可能的一般重構策略：

  1. 在 Google Cloud上佈建構件存放區。舉例來說，您可以使用 Artifact Registry 儲存構件和建構依附元件。
  2. 重構建構程序，以便在來源環境和 Artifact Registry 中儲存構件。
  3. 重構部署程序，以便在目標Google Cloud 環境中部署工作負載。舉例來說，您可以先在 Google Cloud中部署少部分工作負載，並使用儲存在 Artifact Registry 中的靜態構件。接著，您可以逐步增加在 Google Cloud中部署的工作負載數量，直到所有要遷移的工作負載都已在Google Cloud上執行為止。
  4. 重構建構程序，只將構件儲存在 Artifact Registry 中。
  5. 如有需要，請將要部署的舊版構件從來源環境中的存放區遷移至 Artifact Registry。例如，您可以將容器映像檔複製到 Artifact Registry。
  6. 不再需要時，請停用來源環境中的存放區。

為方便在遷移期間因意外問題而進行最終回溯作業，您可以在遷移至 Google Cloud 的過程中，將容器映像檔儲存在 Google Cloud 的現有構件存放區中。最後，您可以將來源環境停用，並重構容器映像檔建構程序，只在Google Cloud 中儲存構件。

雖然這對遷移作業的成功與否不一定至關重要，但您可能需要將舊版構件從來源環境遷移至 Google Cloud上的構件存放區。舉例來說，如要支援將工作負載回溯至任意時間點，您可能需要將較舊版本的構件遷移至 Artifact Registry。詳情請參閱「從第三方註冊資料庫遷移映像檔」。

如果您使用 Artifact Registry 來儲存構件，建議您設定控管機制，以便保護構件存放區，例如存取控管、資料外洩防護、漏洞掃描和二進位授權。詳情請參閱「控管存取權並保護構件」。

重構作業程序

在遷移至 Cloud Run 的過程中，建議您重構作業程序，以便持續有效地監控 Cloud Run 環境。

Cloud Run 可整合下列運作服務：

遷移資料

在這個程序的早期評估階段，您應該已經判斷出要遷移的 AWS Lambda 工作負載是否會依賴或產生 AWS 環境中的資料。舉例來說，您可能已判斷需要將資料從 AWS S3 遷移至 Cloud Storage，或是從 Amazon RDS 和 Aurora 遷移至 Cloud SQL 和 AlloyDB for PostgreSQL。如要進一步瞭解如何將資料從 AWS 遷移至Google Cloud，請參閱「從 AWS 遷移至 Google Cloud：開始使用」一文。

如同重構部署和營運程序，將資料從 AWS 遷移至 Google Cloud 可能相當複雜，且需要付出大量心力。如果您嘗試在遷移 AWS Lambda 工作負載時執行這些資料遷移工作，遷移作業可能會變得複雜，並可能使您面臨風險。分析要遷移的資料後，您可能會瞭解資料的大小和複雜度。如果您認為遷移這類資料需要大量心力，建議您考慮將資料遷移作業納入獨立專案。

驗證遷移結果

驗證工作負載遷移作業並非一次性的事件，而是一項持續進行的程序。從 AWS Lambda 遷移至 Cloud Run 前、期間和後，請持續專注於測試和驗證。

為確保遷移作業順利完成，並確保效能最佳化且中斷時間最短，建議您採用下列程序驗證從 AWS Lambda 遷移至 Cloud Run 的工作負載：

  • 開始遷移階段前，請重構現有的測試案例，以便考量目標 Google Cloud 環境。
  • 在遷移期間，請驗證每個遷移里程碑的測試結果，並進行徹底的整合測試。
  • 遷移完成後，請進行下列測試：
    • 基準測試：在 AWS Lambda 上建立原始工作負載的效能基準，例如執行時間、資源使用率，以及不同負載下的錯誤率。在 Cloud Run 上複製這些測試，找出可能指出遷移或設定問題的差異。
    • 功能測試：建立並執行測試案例，涵蓋這兩種環境中的各種輸入和預期輸出情境，確保工作負載的核心邏輯保持一致。
    • 負載測試：逐步增加流量，以便在實際情況下評估 Cloud Run 的效能和可擴充性。為確保遷移作業順利進行，請解決錯誤和資源限制等差異。

最佳化 Google Cloud 環境

最佳化是遷移作業的最後階段。在這個階段，您會重複執行最佳化工作，直到目標環境符合您的最佳化需求為止。每個疊代步驟如下：

  1. 評估目前的環境、團隊和最佳化循環。
  2. 建立最佳化需求和目標。
  3. 最佳化環境和團隊。
  4. 調整最佳化循環。

您可以重複執行這個程序，直到達成最佳化目標為止。

如要進一步瞭解如何最佳化 Google Cloud 環境，請參閱「遷移至 Google Cloud：最佳化環境」和「Google Cloud 架構良好的架構：效能最佳化」。

後續步驟

貢獻者

作者：

其他貢獻者：