Google Cloud 提供工具、產品、指引和專業服務，協助您將無伺服器工作負載從 Amazon Web Services (AWS) Lambda 遷移至 Google Cloud。雖然 Google Cloud 提供多種服務，可供您開發及部署無伺服器應用程式，但本文著重於遷移至無伺服器執行階段環境 Cloud Run。AWS Lambda 和 Cloud Run 都有類似之處，例如自動佈建資源、由雲端供應商調整資源配置，以及按用量計費的收費方式。
本文可協助您設計、實作及驗證從 AWS Lambda 遷移無伺服器工作負載至 Cloud Run 的計畫。此外，這項工具也提供指引，協助評估這類遷移作業的潛在效益和程序。
本文是從 AWS 遷移至Google Cloud 系列文章的一部分，包含下列文件：
- 開始使用
- 從 Amazon EC2 遷移至 Compute Engine
- 從 Amazon S3 遷移至 Cloud Storage
- 從 Amazon EKS 遷移至 Google Kubernetes Engine
- 從 Amazon RDS 和 Amazon Aurora for MySQL 遷移至 MySQL 適用的 Cloud SQL
- 從 Amazon RDS 和 Amazon Aurora for PostgreSQL 遷移至 PostgreSQL 適用的 Cloud SQL 和 PostgreSQL 適用的 AlloyDB
- 從 Amazon RDS for SQL Server 遷移至 Cloud SQL for SQL Server
- 從 AWS Lambda 遷移至 Cloud Run (本文)
如要進一步瞭解如何為業務邏輯挑選合適的無伺服器執行階段環境，請參閱「選取受管理容器執行階段環境」。如要全面瞭解 AWS 和 Google Cloud 服務的對應關係，請參閱比較 AWS、Azure 服務與 Google Cloud 服務。
如要進行這項遷移作業，建議您按照「遷移至 Google Cloud：開始使用」一文所述的遷移架構操作。 Google Cloud
以下是遷移流程圖。
您可能會從來源環境遷移至 Google Cloud ，並進行一系列的疊代作業，例如先遷移部分工作負載，再遷移其他工作負載。針對每個個別的遷移疊代作業，您會遵循一般遷移架構的階段：
- 評估及探索工作負載和資料。
- 規劃並奠定 Google Cloud的基礎。
- 將工作負載和資料遷移至 Google Cloud。
- 將 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遷移作業。
評估階段包含下列工作：
- 建立鉅細靡遺的工作負載清單。
- 根據工作負載的屬性和依附元件將工作負載編目。
- 訓練並教導您的團隊使用 Google Cloud。
- 在 Google Cloud上建立實驗和概念驗證。
- 計算目標環境的總持有成本 (TCO)。
- 為工作負載選擇遷移策略。
- 選擇遷移工具。
- 定義遷移計畫和時程。
- 驗證遷移計畫。
如要進一步瞭解評估階段和這些工作，請參閱「遷移至 Google Cloud：評估及探索工作負載」。以下各節的內容皆以該文件為依據。
建立 AWS Lambda 工作負載清單
如要定義遷移範圍，請建立清單並收集 AWS Lambda 工作負載的相關資訊。
如要建立 AWS Lambda 工作負載的清單，建議您根據 AWS API、AWS 開發人員工具和 AWS 指令列介面，實作資料收集機制。
建立清單後，建議您收集清單中每個 AWS Lambda 工作負載的相關資訊。針對每個工作負載，著重於有助於預測潛在摩擦的層面。此外，請分析該工作負載，瞭解在遷移至 Cloud Run 前，可能需要修改工作負載及其依附元件的方式。建議您先收集每個 AWS Lambda 工作負載的下列資料：
- 用途和設計
- 原始碼存放區
- 部署構件
- 叫用、觸發條件和輸出內容
- 執行階段和執行環境
- 工作負載設定
- 存取權控管和權限
- 法規遵循和監管要求
- 部署和作業程序
用途和設計
收集工作負載的用途和設計相關資訊，有助於找出合適的遷移策略。這項資訊也有助於您瞭解是否需要在移轉前修改工作負載及其依附元件。建議您針對每個工作負載執行下列操作：
- 深入瞭解工作負載的特定用途，並找出與其他系統、資源或程序的任何依附元件。
- 分析工作負載的設計和架構。
- 評估工作負載的延遲要求。
原始碼存放區
清查 AWS Lambda 函式的原始碼，有助於重構 AWS Lambda 工作負載，確保與 Cloud Run 相容。建立這項清單時，需要追蹤程式碼集，這類程式碼集通常儲存在 Git 等版本管控系統，或 GitHub 或 GitLab 等開發平台。原始碼清單對持續整合和持續開發 (CI/CD) pipeline 等 DevOps 程序至關重要，因為遷移至 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 環境，完成遷移作業。
規劃和建構階段包含下列工作：
- 建立資源階層。
- 設定 Google Cloud身分與存取權管理 (IAM)。
- 設定帳單資訊。
- 設定網路連線。
- 強化安全性。
- 設定記錄、監控和快訊功能。
如要進一步瞭解各項工作，請參閱「遷移至 Google Cloud：規劃及建構基礎」。
遷移 AWS Lambda 工作負載
如要將工作負載從 AWS Lambda 遷移至 Cloud Run，請執行下列操作：
- 設計、佈建及設定 Cloud Run 環境。
- 視需要重構 AWS Lambda 工作負載，使其與 Cloud Run 相容。
- 重構部署和作業程序，在 Cloud Run 上部署及觀察工作負載。
- 遷移 AWS Lambda 工作負載所需的資料。
- 從功能、效能和成本方面驗證遷移結果。
為避免遷移期間發生問題，並協助您評估遷移所需的工作量，建議您比較 AWS Lambda 功能與類似的 Cloud Run 功能。比較 AWS Lambda 和 Cloud Run 功能時，您可能會發現兩者十分相似。不過，這兩家雲端供應商的功能設計和實作方式有所不同，可能會對您從 AWS Lambda 遷移至 Cloud Run 造成重大影響。如以下章節所述，這些差異可能會影響您的設計和重構決策。
設計、佈建及設定 Cloud Run 環境
遷移階段的第一步是設計 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 資源 |
|---|---|
| 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 提供的服務觸發條件，請參閱下列資源：
- HTTPS 叫用：傳送 HTTPS 要求來觸發 Cloud Run 服務。
- HTTP/2 叫用： 傳送 HTTP/2 要求來觸發 Cloud Run 服務。
- WebSockets： 將用戶端連線至 Cloud Run 上執行的 WebSocket 伺服器。
- gRPC 連線：使用 gRPC 連線至 Cloud Run 服務。
- 非同步叫用： 使用 Cloud Tasks 將工作加入佇列，由 Cloud Run 服務以非同步方式處理。
- 排定叫用時間： 使用 Cloud Scheduler 依排程叫用 Cloud Run 服務。
- 以事件為基礎的叫用： 建立 Eventarc 觸發條件，在CloudEvents 格式的特定事件發生時，叫用 Cloud Run 服務。
- 與 Pub/Sub 整合： 從 Pub/Sub 推送訂閱項目叫用 Cloud Run 服務。
- 與 Workflows 整合： 從工作流程叫用 Cloud Run 服務。
如要進一步瞭解 Cloud Run 提供的作業執行機制，請參閱下列資源：
- 隨選執行： 建立工作執行作業，直到完成為止。
- 排定執行時間：依排程執行 Cloud Run 工作。
- 與 Workflows 整合： 從工作流程執行 Cloud Run 工作。
下表列出與 AWS Lambda 叫用機制類似的 Cloud Run 叫用或執行機制，方便您參考。針對您需要佈建的每個 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 Step Functions | 工作流程整合 |
Cloud Run 資源設定
為了補充您為觸發及執行遷移工作負載所做的設計決策，Cloud Run 支援多種設定選項，可讓您微調執行階段環境的各個層面。這些設定選項包括資源服務和工作。
如先前所述，如要進一步瞭解 Cloud Run 的運作方式，請先瞭解 Cloud Run 的所有設定選項。瞭解這些概念後，您就能比較 AWS Lambda 和 Cloud Run 的類似功能，並判斷如何重構工作負載。
如要進一步瞭解 Cloud Run 服務提供的設定，請參閱下列資源：
- 容量：記憶體限制、CPU 限制、CPU 分配、要求逾時、每個執行個體的並行要求上限、執行個體下限、執行個體上限，以及 GPU 設定。
- 環境： 容器埠和進入點、 環境變數、 Cloud Storage 磁碟區掛接、 記憶體內磁碟區掛接、 執行環境、 容器健康狀態檢查、 密鑰，以及 服務帳戶
- 自動調度資源
- 處理例外狀況： 處理 Pub/Sub 失敗狀況，以及 處理 Eventarc 失敗狀況
- 中繼資料： 說明、 標籤和 標記
- 流量放送： 自訂網域對應、 自動指派的網址、 Cloud CDN 整合，以及 工作階段親和性
如要進一步瞭解 Cloud Run 提供的工作，請參閱下列資源：
- 容量： 記憶體限制、 CPU 限制、 平行處理和 工作逾時
- 環境： 容器進入點、 環境變數、 Cloud Storage 磁碟區掛接、 記憶體內磁碟區掛接、 密鑰和 服務帳戶
- 處理例外狀況： 重試次數上限
- 中繼資料：標籤和標記
下表列出與 AWS Lambda 設定選項對應的 Cloud Run 設定選項，方便您瞭解。針對需要佈建的每個 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 提供的安全性功能，請參閱下列資源：
- 使用身分與存取權管理 (IAM) 控制存取權
- 個別服務身分
- 整合 Google Cloud Armor
- 二進位授權
- 客戶管理的加密金鑰
- 軟體供應鏈安全性
- 輸入限制設定
- VPC Service Controls
下表列出與 AWS Lambda 提供的安全性和存取權控管措施類似的 Cloud Run 措施，方便您瞭解。針對您需要佈建的每個 Cloud Run 資源，請務必選擇適當的存取控制項和安全防護功能。
| AWS Lambda 功能 | Cloud Run 功能 |
|---|---|
| 使用 AWS 身分存取權管理控管存取權 | 使用 Google Cloud's IAM 控管存取權 |
| 執行角色 | Google Cloud的 IAM 角色 |
| 權限界線 | Google Cloud's 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 工作負載，請參閱下列資源：
- 一般開發提示
- 為 Cloud Run 最佳化 Java 應用程式
- 為 Cloud Run 最佳化 Python 應用程式
- 負載測試最佳做法
- 工作重試和檢查點最佳做法
- 使用 Nginx 進行前端 Proxy
- 透過 Cloud CDN 和 Cloud Run 提供靜態資產
- 瞭解 Cloud Run 區域備援
重構部署和營運程序
重構工作負載後，請重構部署和作業程序，以執行下列操作：
- 在 Google Cloud 環境中佈建及設定資源，而不是在來源環境中佈建資源。
- 建構及設定工作負載，並部署至 Google Cloud，而非部署至來源環境。
您已在本程序稍早的評估階段收集這些程序的相關資訊。
您需要為這些程序考量的重構類型，取決於您設計及實作這些程序的方式。重構作業也取決於您希望每個程序最終達到什麼狀態。舉例來說，你可以嘗試下列做法：
- 您可能已在來源環境中實作這些程序，並打算在 Google Cloud中設計及實作類似程序。舉例來說，您可以重構這些程序，改用 Cloud Build、Cloud Deploy 和 Infrastructure Manager。
- 您可能已在來源環境以外的其他第三方環境中實作這些程序。在這種情況下，您需要重構這些程序，以 Google Cloud 環境為目標，而非來源環境。
- 結合上述做法。
重構部署和作業程序可能相當複雜，需要投入大量心力。如果您嘗試在工作負載遷移期間執行這些工作，工作負載遷移作業可能會變得更加複雜，而且您可能會面臨風險。評估部署和作業程序後，您可能已瞭解這些程序的設計和複雜程度。如果您預估需要大量心力才能重構部署和作業程序，建議您考慮將這些程序重構作業納入獨立專案。
如要進一步瞭解如何在 Google Cloud上設計及實作部署程序，請參閱：
本文著重於部署程序，這些程序會產生要部署的構件，並將構件部署至目標執行階段環境。重構策略很大程度上取決於這些程序的複雜程度。以下列出可能的重構策略：
- 在 Google Cloud上佈建構件存放區。舉例來說，您可以使用 Artifact Registry 儲存構件和建構依附元件。
- 重構建構程序，將構件儲存在來源環境和 Artifact Registry 中。
- 重構部署程序，在目標Google Cloud 環境中部署工作負載。舉例來說，您可以先在 Google Cloud中部署一小部分工作負載，並使用儲存在 Artifact Registry 中的構件。然後逐步增加在 Google Cloud中部署的工作負載數量，直到所有要遷移的工作負載都在Google Cloud上執行為止。
- 重構建構程序，只將構件儲存在 Artifact Registry 中。
- 如有必要，請將舊版構件從來源環境的存放區遷移至 Artifact Registry，以便部署。例如，您可以將容器映像檔複製到 Artifact Registry。
- 不再需要來源環境中的存放區時，請將其停用。
為方便在遷移期間發生非預期問題時進行回溯，您可以在遷移至 Google Cloud 的過程中，將容器映像檔同時儲存在目前的構件存放區 Google Cloud 。最後，在來源環境停用程序中，您可以重構容器映像檔建構程序，只在Google Cloud 中儲存構件。
雖然這可能不是遷移作業成功的關鍵，但您可能需要將舊版構件從來源環境遷移至 Google Cloud的構件存放區。舉例來說，如要支援將工作負載回復至任意時間點，您可能需要將舊版構件遷移至 Artifact Registry。詳情請參閱「從第三方登錄檔遷移映像檔」。
如果您使用 Artifact Registry 儲存構件，建議您設定控管機制，確保構件存放區安全無虞，例如存取控管、防止資料外洩、漏洞掃描和二進位授權。詳情請參閱「控管存取權及保護構件」。
重構作業程序
遷移至 Cloud Run 時，建議您重構作業程序，以便持續有效地監控 Cloud Run 環境。
Cloud Run 與下列作業服務整合：
- Google Cloud Observability，為工作負載提供記錄、監控和快訊功能。如有需要，您也可以取得 Cloud Run 工作負載的 Prometheus 式監控或 OpenTelemetry 指標。
- Cloud 稽核記錄提供稽核記錄。
- Cloud Trace 提供分散式效能追蹤功能。
遷移資料
在此程序稍早的評估階段，您應該已判斷要遷移的 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 環境
最佳化是遷移的最後階段。在這個階段，您會反覆執行最佳化工作，直到目標環境符合最佳化需求為止。每次疊代的步驟如下：
- 評估目前的環境、團隊和最佳化迴圈。
- 建立最佳化需求和目標。
- 將環境和團隊調整至最佳狀態。
- 調整最佳化迴圈。
重複這個程序，直到達成最佳化目標為止。
如要進一步瞭解如何最佳化 Google Cloud 環境，請參閱「遷移至 Google Cloud：最佳化環境」和「Google Cloud 架構完善的架構：效能最佳化」。
後續步驟
- 瞭解其他 AWS 遷移至 Google Cloud 的歷程。
- 瞭解如何比較 AWS 和 Azure 服務與 Google Cloud。
- 瞭解何時應尋求遷移作業的相關協助。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。
貢獻者
作者：
- Marco Ferrari | 雲端解決方案架構師
- Xiang Shen | 解決方案架構師
其他貢獻者：
- Steren Giannini | 產品事業群經理
- James Ma | 產品經理
- Henry Bell | 雲端解決方案架構師
- Christoph Stanger | 策略雲端工程師
- CC Chen | 客戶解決方案架構師
- Wietse Venema | 開發人員關係工程師