客戶代管基礎架構架構模式

本頁將探討客戶代管部署作業最常見的架構模式,並說明實作這些模式的最佳做法。如要有效使用本頁資訊,您必須熟悉系統架構概念和做法。

工作流程策略

確認自架是實作 Looker 的可行方案後,下一步就是詳述部署作業要採用的策略。

  1. 進行評估。列出可能因部署或遷移至公用雲端而受益的預定及現有工作流程候選清單。
  2. 列出適用的架構模式。從確定的候選工作流程著手,找出適用的架構模式。
  3. 優先考量並選取最合適的架構模式。將架構模式與最重要的工作和結果保持一致。
  4. 設定架構元件並部署 Looker 應用程式。實作建立安全用戶端連線所需的主機、第三方依附元件和網路拓撲。

架構選項

專屬虛擬機器

其中一個選項是在專用虛擬機器 (VM) 中,以單一執行個體的形式執行 Looker。單一執行個體可透過垂直調度主機及增加預設的執行緒集區,為高負載工作負載提供服務。不過,管理大型 Java 堆疊的處理開銷會導致垂直縮放效益遞減。一般來說,這類機器適合用於小型至中型工作負載。下圖顯示在專屬 VM 中執行的 Looker 執行個體、本選項的優點最佳做法中醒目顯示的資料來源、本機和遠端存放區,以及 SMTP 伺服器之間的預設和選用設定。

這張圖表顯示在專屬 VM 中執行 Looker 與本機和遠端存放區、SMTP 伺服器和資料來源之間的預設和選用設定。

優點

  • 專屬 VM 易於部署及維護。
  • 內部資料庫會在 Looker 應用程式中代管。
  • Looker 模型、Git 存放區、SMTP 伺服器和後端資料庫元件可在本機或遠端設定。
  • 您可以將 Looker 的預設 SMTP 伺服器替換為自己的伺服器,以便傳送電子郵件通知和排定工作。

最佳做法

  • 根據預設,Looker 可為專案產生裸露的 Git 存放區。建議您設定遠端 Git 存放區,以便備援。
  • 根據預設,Looker 會從記憶體內的 HyperSQL 資料庫開始。這個資料庫方便又輕巧,但在大量使用時可能會發生效能問題。建議您在規模較大的部署作業中使用 MySQL 資料庫。建議在 ~/looker/.db/looker.script 檔案達到 600 MB 時,將檔案遷移至遠端 MySQL 資料庫。
  • Looker 部署作業必須針對 Looker 授權服務進行驗證,因此需要通訊埠 443 的傳出流量。
  • 您可以增加可用資源和 Looker 執行緒集區,藉此垂直擴充專屬 VM 部署作業。不過,一旦 RAM 達到 64 GB,就會出現邊際效益遞減的現象,因為垃圾收集事件是單執行緒的,且會暫停執行所有其他執行緒。節點配備 16 個 CPU 和 64 GB RAM,可在價格和效能之間取得良好平衡。
  • 建議您部署的儲存空間每 GB 有 2 個作業數 (IOPS)。

VM 叢集

將 Looker 做為跨多個 VM 的執行個體叢集執行,是一種靈活的模式,可利用服務容錯移轉和備援機制。水平可擴充性可提高總處理量,且不會發生堆積膨脹和過度垃圾收集成本。節點可選擇專屬工作負載,讓多個部署選項可依不同業務需求進行調整。叢集部署作業至少需要一位熟悉 Linux 系統且能管理元件的系統管理員。

標準叢集

對於大多數標準部署作業,只要有一個相同服務節點的叢集即可。叢集中的所有節點都以相同方式設定,且都位於同一個負載平衡器集區。在這個設定中,沒有任何節點會更可能或更不可能處理 Looker 使用者要求、轉譯工作、排程工作、API 要求等。

如果大多數要求直接來自執行查詢並與 Looker 互動的 Looker 使用者,就適合採用這類設定。當排程器、轉譯器或其他來源傳送大量要求時,就會開始發生問題。在這種情況下,指定特定服務節點來處理排程和轉譯等工作會很有幫助。

舉例來說,使用者通常會將資料提交作業排定在星期一上午執行。使用者在星期一早上嘗試執行 Looker 查詢時,可能會遇到效能問題,因為 Looker 會處理排定要求的積壓工作。叢集可透過增加服務節點數量,在所有 Looker 功能中提供成比例的吞吐量提升。

下圖顯示從使用者、應用程式和指令碼提出的 Looker 要求,如何在叢集 Looker 執行個體中保持平衡。

使用者、應用程式和指令碼向 Looker 提出的要求,會分散到叢集 Looker 執行個體中三個 Looker 節點的負載平衡器上。

優點

  • 標準叢集會以最少的叢集拓撲設定,盡可能提高整體效能。
  • 在 64 GB 的記憶體配置閾值下,Java VM 的效能會降低,這就是水平資源調度比垂直資源調度更有效率的原因。
  • 叢集設定可確保服務備援和容錯功能。

最佳做法

  • 每個 Looker 節點都應在專屬的 VM 中代管。
  • 負載平衡器是叢集輸入點,應為第 4 層負載平衡器。應設有長時間逾時 (3,600 秒)、配備已簽署的 SSL 憑證,並設為從 443 (https) 轉送至 9999 (Looker 伺服器監聽的通訊埠)。
  • 建議您部署的儲存空間每 GB 有 2 IOPS。

開發人員版/測試版/實際工作環境

如果用途是優先考量為使用者提供內容的最高可用時間,建議您使用不同的 Looker 環境,將開發工作和分析工作分開。這個架構會在隔離的開發和測試環境後方,限制實際工作環境的變更,以便維持盡可能穩定的實際工作環境。

要獲得這些優點,您必須設定相互連結的環境,並採用穩健的發布週期。開發/測試/正式版部署作業也需要一組熟悉 Looker API 和 Git 的開發人員,以便管理工作流程。

下圖顯示 LookML 開發人員在開發環境中開發內容、品質確保 (QA) 測試人員在 QA 環境中測試內容,以及使用者、應用程式和在實際工作環境中使用內容的腳本之間的內容流程。

內容會在開發人員執行個體上開發,在品管執行個體上測試,並由實際工作執行個體上的使用者、應用程式和指令碼使用。

優點

  • LookML 和內容驗證會在非正式環境中進行,確保模型邏輯的任何修改內容在正式發布前都能經過徹底審查。
  • 在實際工作環境中啟用前,您可以先個別測試單一執行個體的功能,例如 研究室功能驗證通訊協定
  • 您可以在非正式環境中測試資料群組和快取政策。
  • Looker 正式版模式測試與負責為使用者提供服務的正式環境分開。
  • Looker 版本可以在非正式環境中進行測試,讓您有充裕的時間測試新功能、工作流程變更和問題,再更新正式環境。

最佳做法

  • 將至少三個獨立例項中同時發生的各種活動分開:
    • 開發例項:開發人員會使用開發環境來提交程式碼、進行實驗、修正錯誤,並安全地犯錯。
    • QA 執行個體:也稱為測試暫存環境,是開發人員執行手動和自動化測試的環境。QA 環境相當複雜,可能會耗用大量資源。
    • 正式版:這是為客戶和/或企業創造價值的地方。實際工作環境是高度曝光的環境,因此應不含任何錯誤。
  • 維持有文件可供參考的發布週期工作流程
  • 如果需要為大量開發人員和品質確保測試人員提供服務,可以將開發人員和/或品質確保工作群組成簇。無論是獨立 VM 或 VM 叢集,開發和測試執行個體都必須遵循先前各節所述的架構考量。

高排程處理量

對於需要高排程資料傳送處理量,以及可靠且及時的傳送作業的用途,建議您在設定中加入叢集,並在其中建立專門用於排程的節點集區。這項設定有助於確保網頁和嵌入式應用程式的速度和回應速度。如要享有這些優點,您必須設定節點,並使用自訂的啟動選項和適當的負載平衡規則,如以下圖表所示,並參閱此選項的優點最佳做法章節。

Looker 叢集設定,其中包含專門用於排程的節點集區。

優點

  • 為特定函式專用節點,可將排程資源與開發和臨時分析函式分開。
  • 使用者可以開發 LookML 並探索內容,而不會影響負責處理排定資料傳送作業的節點。
  • 大量使用者流量會導向一般節點,但不會阻礙排程節點提供的排程工作負載。

最佳做法

  • 每個 Looker 節點都應在專屬的 VM 中代管。
  • 負載平衡器是叢集輸入點,應為第 4 層負載平衡器。應設有長時間逾時 (3,600 秒)、配備已簽署的 SSL 憑證,並設為從 443 (https) 轉送至 9999 (Looker 伺服器監聽的通訊埠)。
  • 從負載平衡規則中省略排程節點,以免這些節點為使用者流量和內部 API 要求提供服務。
  • 建議您部署的儲存空間每 GB 有 2 IOPS。

高算繪處理量

如果用途需要高報表算繪處理量,建議您設定叢集,並使用專門用於算繪的節點集區。在 Looker 中,算繪 PDF 檔案或 PNG/JPEG 圖片的作業相對耗用資源。算繪作業可能會耗用大量記憶體和 CPU,而當 Linux 處於記憶體壓力下時,可能會終止執行中的程序。由於無法事先判斷算繪工作使用的記憶體,因此啟動算繪工作可能會導致 Looker 程序終止。設定專屬的轉算節點,可妥善調整轉算工作,同時維持互動式和嵌入式應用程式的回應速度。

如要享有這些優點,您必須設定節點,並使用自訂的啟動選項和適當的負載平衡規則,如以下圖表所示,並參閱此選項的優點最佳做法。此外,由於 Looker 的轉譯服務需要與第三方 Chromium 程序共用 CPU 時間和記憶體,因此轉譯節點可能需要比標準節點更多的主機資源。

Looker 叢集設定,其中包含專門用於轉譯的節點集區。

優點

  • 為特定函式專用節點,可將轉譯資源分隔開來,以便進行開發和臨時分析函式。
  • 使用者可以開發 LookML 並探索內容,而不會從負責轉譯 PNG 和 PDF 的節點取得週期。
  • 將大量使用者流量導向一般節點,不會阻礙由轉譯節點服務的轉譯工作負載。

最佳做法

  • 每個 Looker 節點都應在專屬的 VM 中代管。
  • 負載平衡器是叢集輸入點,應為第 4 層負載平衡器。應設有長時間逾時 (3,600 秒)、配備已簽署的 SSL 憑證,並設為從 443 (https) 轉送至 9999 (Looker 伺服器監聽的通訊埠)。
  • 從負載平衡規則中省略轉譯節點,以免這些節點為使用者流量和內部 API 要求提供服務。
  • 在轉譯節點中,將相對較少的記憶體分配給 Java,以便為 Chromium 的程序提供較大的記憶體緩衝區。請不要將 60% 的記憶體配置給 Java,而是分配 40% 至 50% 的記憶體。
  • 非算繪節點的記憶體壓力風險已降低,因此可增加 Looker 專用的記憶體量。建議您改用 80% 等較高的數字,而非預設的 60%。
  • 建議您部署的儲存空間每 GB 有 2 IOPS。