將 Autoscaler 工具部署至 Cloud Run 函式

自動調整工具可提供彈性，並可因應現有運作和應用程式團隊之間的責任分工。您可以將設定 Spanner 執行個體自動調度資源的責任集中到單一作業團隊，也可以將這項責任分派給與這些 Spanner 執行個體所服務應用程式較為密切的團隊。

本文件是一系列文章的一部分，其他文章如下：

本系列文章適用於想降低營運負擔，並將 Spanner 部署成本降至最低的 IT、營運和網站可靠度工程 (SRE) 團隊。

本頁面將介紹三種方法，讓您根據需求將資源調整工具部署至 Cloud Run 函式：

  • 每個專案的部署拓撲圖。自動配置器基礎架構會部署在需要自動調度資源的 Spanner 專案中。我們建議獨立團隊使用這個拓樸圖，因為他們想自行管理自動配置器設定和基礎架構。每個專案的部署拓樸也是測試自動調度資源功能的好起點。
  • 集中式部署拓撲。自動配置器工具會部署在一個專案中，並管理不同專案中一或多個 Spanner 執行個體。我們建議使用這個拓樸圖，適用對象是管理一或多個 Spanner 執行個體的設定和基礎架構，同時將 Autoscaler 的元件和設定保留在集中位置的團隊。在集中式拓樸中，除了設定自動調整大小專案外，您還需要設定第二個專案，在本教學課程中稱為應用程式專案。應用程式專案會保留應用程式資源，包括 Spanner。
  • 分散式部署拓撲。大部分的自動配置器基礎架構會部署在一個專案中，但部分基礎架構元件會部署在不同專案中，並在這些專案中自動調整 Spanner 執行個體。我們建議將這個拓樸結構用於擁有多個團隊的機構，這些團隊擁有 Spanner 執行個體，但只想管理其執行個體的自動配置器設定參數，而其他自動配置器基礎架構則由中央團隊管理。

無伺服器架構，可輕鬆部署及管理

在這個模型中，自動調整工具只使用無伺服器和低管理 Google Cloud 工具建構，例如 Cloud Run 函式、Pub/Sub、Cloud Scheduler 和 Firestore。這麼做可降低執行 Autoscaler 工具的成本和營運負擔。

透過內建的 Google Cloud 工具，調整大小工具可充分利用身分與存取權管理 (IAM) 進行驗證和授權。

設定

自動配置器工具會透過 Cloud Scheduler 中定義的設定管理 Spanner 執行個體。如果需要以相同間隔輪詢多個 Spanner 例項，建議您在同一個 Cloud Scheduler 工作中設定這些例項。每個執行個體的設定會以 JSON 物件表示。以下是使用一個 Cloud Scheduler 工作來管理兩個 Spanner 例項的設定範例：

[
  {
    "projectId": "my-spanner-project",
    "instanceId": "my-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "NODES",
    "minSize": 1,
    "maxSize": 3
  },
  {
    "projectId": "different-project",
    "instanceId": "another-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "PROCESSING_UNITS",
    "minSize": 500,
    "maxSize": 3000,
    "scalingMethod": "DIRECT"
  }
]

Spanner 執行個體可在不同的 Cloud Scheduler 工作上設定多個設定。舉例來說，執行個體可以有一個自動配置器設定，使用線性方法進行一般作業，但也可以有另一個自動配置器設定，使用直接方法進行排定的批次工作負載。

Cloud Scheduler 工作執行時，會將 Pub/Sub 訊息傳送至 Polling Pub/Sub 主題。此訊息的酬載是相同工作中所有已設定例項的設定物件 JSON 陣列。如需完整的設定選項清單，請參閱 Poller README 檔案。

專案拓撲

在每個專案拓樸部署作業中，每個專案都會包含需要自動調整的 Spanner 執行個體，並且各自部署自動配置器元件。我們建議將這個拓樸圖用於想自行管理自動配置器設定和基礎架構的獨立團隊。這也是測試自動配置器工具功能的好起點。

下圖顯示每個專案部署作業的概略概念視圖。

概念上的專案部署。

上圖所示的個別專案部署作業具有下列特性：

  • 兩個應用程式 (應用程式 1 和應用程式 2) 各自使用自己的 Spanner 例項。
  • Spanner 執行個體 (A) 位於各自的應用程式 1 和應用程式 2 專案中。
  • 獨立的自動配置器 (B) 會部署至每個專案，用於控制專案內執行個體的自動調整資源配置作業。

每個專案部署作業有下列優缺點。

優點：

  • 最簡單的設計：每個專案拓撲是三種拓撲中最簡單的設計，因為所有自動配置器元件都會與正在自動調整大小的 Spanner 執行個體一併部署。
  • 設定：排程器參數的控管權屬於擁有 Spanner 例項的團隊，這讓團隊可以更自由地根據需求調整自動配置器工具，而非集中式或分散式拓樸。
  • 基礎架構責任明確劃分：每個專案拓樸圖的設計會明確劃分自動配置器基礎架構的責任和安全性，因為 Spanner 執行個體的團隊擁有者也是自動配置器基礎架構的擁有者。

缺點：

  • 更多整體維護作業：每個團隊都負責 Autoscaler 設定和基礎架構，因此可能很難確保公司內所有 Autoscaler 工具都遵循相同的更新規範。
  • 更複雜的稽核作業：由於每個團隊都具有高度控管權，因此集中式稽核作業可能會變得更複雜。

如要瞭解如何使用個別專案拓樸圖設定自動配置器，請參閱個別專案部署的逐步指南。

集中式拓撲

如同個別專案的拓樸結構，在集中式拓樸結構部署中，自動配置工具的所有元件都會位於同一個專案中。不過，Spanner 例項位於不同的專案中。這項部署作業適合團隊在單一位置部署 Autoscaler 工具，藉此管理多個 Spanner 執行個體的設定和基礎架構。

下圖概略說明集中式專案部署的概念：

概念上的集中式專案部署。

上圖所示的集中式部署作業具有下列特性：

  • 兩個應用程式 (應用程式 1 和應用程式 2) 各自使用自己的 Spanner 例項。
  • Spanner 執行個體 (A) 位於各自的應用程式 1 和應用程式 2 專案中。
  • 自動配置器 (B) 已部署至個別專案，用於控制應用程式 1 和應用程式 2 專案中 Spanner 執行個體的自動調度資源功能。

集中式部署有下列優缺點。

優點：

  • 集中式設定和基礎架構：單一團隊控管排程器參數和自動調度器基礎架構。這種做法在受到嚴格管制的產業中相當實用。
  • 整體維護工作減少：與個別專案部署作業相比，維護和設定作業通常較不費力。
  • 集中式政策和稽核：您可能會更容易指定和實施跨團隊的最佳做法。稽核作業可能會更容易執行。

缺點：

  • 集中設定：即使要求變更的團隊擁有 Spanner 例項，自動配置器參數的任何變更都必須經過集中團隊的核准。
  • 潛在的額外風險：即使自動調度資源基礎架構的設計是以高可用性為目標，但集中式團隊本身仍可能成為單一故障點。

如要瞭解如何使用集中式拓樸圖設定自動配置器，請參閱集中式部署的逐步指南。

分散式拓撲

在分散式拓樸圖部署中，需要自動調度資源的 Cloud Scheduler 和 Spanner 執行個體會位於同一個專案中。Autoscaler 工具的其他元件則位於由中央管理的專案中。這項部署作業是混合型部署。擁有 Spanner 執行個體的團隊只會管理其執行個體的自動配置器設定參數，而中央團隊則會管理其他自動配置器基礎架構。

下圖顯示分散式專案部署的概略概念視圖。

概念性的分散式專案部署。

上圖所示的混合型部署具有下列特性：

  • 兩個應用程式 (應用程式 1 和應用程式 2) 使用各自的 Spanner 例項。
  • Spanner 例項 (A) 同時位於應用程式 1 和應用程式 2 專案中。
  • 將獨立的 Cloud Scheduler 元件 (C) 部署至各專案：應用程式 1 和應用程式 2。
  • 其餘的自動配置器元件 (B) 會部署至個別專案。
  • 自動配置器工具會使用各專案中獨立 Cloud Scheduler 元件傳送的設定，自動調整應用程式 1 和應用程式 2 專案中的 Spanner 執行個體。

轉送器函式

Cloud Scheduler 只能將訊息發布至相同專案的主題，因此對於分散式拓樸，您需要使用名為「轉寄函式」的中介元件。

轉寄函式會接收從 Cloud Scheduler 發布至 Pub/Sub 的訊息，檢查其 JSON 語法，並轉寄至 Polling 函式 Pub/Sub 主題。主題可以屬於 Cloud Scheduler 以外的專案。

下圖顯示轉送機制使用的元件：

轉寄機制。

如上圖所示，Spanner 執行個體位於名為「Application 1」和「Application 2」的專案中：

  1. Cloud Scheduler 與 Spanner 執行個體位於相同專案中。

  2. (2a) Cloud Scheduler 會將訊息發布至應用程式 1 和應用程式 2 專案中的轉寄主題。

    (2b) 轉寄函式會讀取轉寄主題中的訊息。

    (2c) 轉寄函式會將訊息轉寄至位於 Autoscaler 專案中的 Polling 主題。

  3. Polling 函式會讀取輪詢主題中的訊息，並繼續執行程序，如「Polling」一節所述。

分散式部署有下列優點和缺點。

優點：

  • 應用程式團隊可控管設定和排程：Cloud Scheduler 會與正在自動調度資源的 Spanner 執行個體一併部署，讓應用程式團隊更能控管設定和排程。
  • 營運團隊控管基礎架構：自動配置器工具的核心元件會集中部署，讓營運團隊控管自動配置器基礎架構。
  • 集中維護：Scaler 基礎架構集中管理，減少額外負擔。

缺點：

  • 較複雜的設定：應用程式團隊需要提供服務帳戶，才能寫入輪詢主題。
  • 可能產生額外風險：即使基礎架構的設計以高可用性為考量，共用基礎架構仍可能成為單一故障點。

如要瞭解如何使用分散式拓樸圖設定自動配置器，請參閱分散式部署的逐步指南。

後續步驟