本頁將探討客戶代管部署作業最常見的架構模式，並說明實作這些模式的最佳做法。如要有效使用這個頁面，您應熟悉系統架構概念和做法。
工作流程策略
確認自行代管是實作 Looker 的可行選項後，下一步就是詳細說明部署作業的服務策略。
- 進行評估。列出預定及現有工作流程的候選清單。
- 列出適用的架構模式。從確定的候選工作流程著手，找出適用的架構模式。
- 優先選擇最合適的架構模式。根據最重要的工作和結果調整架構模式。
- 設定架構元件並部署 Looker 應用程式。實作主機、第三方依附元件和網路拓撲，建立安全的用戶端連線。
架構選項
專屬虛擬機器
其中一個選項是在專屬虛擬機器 (VM) 中，以單一執行個體的形式執行 Looker。單一執行個體可以垂直擴充主機並增加預設執行緒集區，以處理高需求工作負載。不過，管理大型 Java 堆積的處理負擔會導致垂直擴充受到效益遞減法則的限制。一般來說，這對小型到中型工作負載而言是可以接受的。下圖顯示在專屬 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 叢集
在多個 VM 中以執行個體叢集的形式執行 Looker，是一種彈性模式，可享有服務容錯移轉和備援的優勢。水平擴充可提高總處理量，不會導致堆積膨脹和垃圾收集成本過高。節點可選擇專屬工作負載，因此可根據不同的業務需求，量身打造多種部署選項。叢集部署作業至少需要一位熟悉 Linux 系統，且有能力管理元件的系統管理員。
標準叢集
在大多數標準部署作業中，相同服務節點的叢集就已足夠。叢集中的所有節點都採用相同設定，且都位於同一個負載平衡器集區。在這個設定中，節點處理 Looker 使用者要求、算繪工作、排定工作、API 要求等的機率不會有任何差異。
如果大部分要求都來自執行查詢並與 Looker 互動的 Looker 使用者，就適合採用這類設定。如果排程器、Renderer 或其他來源發出大量要求，就會開始發生故障。在這種情況下，指定特定服務節點來處理排程和算繪等工作，會很有幫助。
舉例來說，使用者通常會安排在週一早上執行資料傳送作業。如果使用者在週一早上嘗試執行 Looker 查詢，而 Looker 正在處理排定要求的待處理事項，使用者可能會遇到效能問題。增加服務節點數量後，叢集會為所有 Looker 功能提供相應的輸送量提升。
下圖說明使用者、應用程式和指令碼對 Looker 提出的要求，如何在叢集 Looker 執行個體之間達到負載平衡。
優點
- 標準叢集可盡量提高整體輸送量，且叢集拓撲的設定最少。
- Java VM 在 64 GB 的分配記憶體門檻會發生效能下降問題，因此水平資源調度比垂直資源調度更有回報。
- 叢集設定可確保服務備援和容錯移轉。
最佳做法
- 每個 Looker 節點都應託管在專屬的 VM 中。
- 負載平衡器是叢集 Ingress 點，應為第 4 層負載平衡器。這個伺服器應設有較長的逾時時間 (3,600 秒)、配備已簽署的 SSL 憑證，並設定為從 443 (https) 轉送通訊埠至 9999 (Looker 伺服器監聽的通訊埠)。
- 建議部署作業的儲存空間每 GB 有 2 個 IOPS。
開發/預先發布/正式版
如果您的用途是盡可能確保內容對使用者維持正常運作，建議您使用不同的 Looker 環境，將開發工作和分析工作分開。這個架構會將實際工作環境變更限制在獨立的開發和測試環境中，盡可能維持實際工作環境的穩定性。
如要享有這些優點，您必須設定互連環境，並採用健全的發布週期。開發/預先發布/正式發布部署作業也需要開發人員團隊，他們必須熟悉 Looker API 和 Git，才能管理工作流程。
下圖說明 LookML 開發人員 (在開發例項上開發內容)、品質保證 (QA) 測試人員 (在 QA 例項上測試內容)，以及使用者、應用程式和指令碼 (在正式版例項上使用內容) 之間的內容流程。
優點
- LookML 和內容驗證會在非正式環境中進行，確保模型邏輯的任何修改內容，都能在提供給正式環境使用者前經過徹底審查。
- 在實際工作環境中啟用前，可以個別測試執行個體層級的功能，例如實驗室功能或驗證通訊協定。
- 您可以在非正式環境中測試資料群組和快取政策。
- Looker 生產模式測試與負責為使用者提供服務的生產環境無關。
- 您可以在非正式版環境中測試 Looker 版本，有充足的時間測試新功能、工作流程變更和問題，再更新正式版環境。
最佳做法
- 在至少三個獨立執行個體中，隔離同時發生的各種活動：
- 開發例項：開發人員可使用開發環境提交程式碼、進行實驗、修正錯誤，以及安全地犯錯。
- QA 執行個體：也稱為「測試」或「暫存」環境，開發人員會在其中執行手動和自動測試。QA 環境複雜，可能會耗用大量資源。
- 正式版執行個體：為顧客和/或商家創造價值。實際執行環境的曝光度很高，因此不應有任何錯誤。
- 維持有記錄且可重複的發布週期工作流程。
- 如有需要為大量開發人員和 QA 測試人員提供服務，可以將開發和/或 QA 執行個體叢集化。無論是保留為獨立 VM 或 VM 叢集，開發和 QA 執行個體都須遵守先前各節中展示的相同架構考量事項。
高排程處理量
如果應用情境需要高排程資料傳送總處理量，並確保資料能及時可靠地傳送，建議您在設定中加入叢集，並提供專門用於排程的節點集區。這項設定有助於確保網頁和內嵌應用程式快速回應。如要享有這些優點，請設定節點，並使用自訂啟動選項和適當的負載平衡規則，如下圖所示，並如本選項的「優點」和「最佳做法」部分所述。
優點
- 為特定函式專用節點，可將資源劃分給排程，與開發和臨時分析函式分開。
- 使用者可以開發 LookML 及探索內容，不必占用負責提供排定資料傳送服務的節點週期。
- 大量使用者流量會導向一般節點，但不會妨礙排程節點服務的排定工作負載。
最佳做法
- 每個 Looker 節點都應託管在專屬的 VM 中。
- 負載平衡器是叢集 Ingress 點，應為第 4 層負載平衡器。這個伺服器應設有較長的逾時時間 (3,600 秒)、配備已簽署的 SSL 憑證，並設定為從 443 (https) 轉送通訊埠至 9999 (Looker 伺服器監聽的通訊埠)。
- 從負載平衡規則中省略排程器節點，以免這些節點處理使用者流量和內部 API 要求。
- 建議部署作業的儲存空間每 GB 有 2 個 IOPS。
高算繪處理量
如果使用案例需要高算繪報表輸送量，建議您設定叢集，並使用專門用於算繪的節點集區。在 Looker 中，算繪 PDF 檔案或 PNG/JPEG 圖片是相對耗用資源的作業。算繪作業可能會耗用大量記憶體和 CPU，而 Linux 在記憶體不足時可能會終止執行中的程序。由於無法預先判斷算繪工作的記憶體用量，因此啟動算繪工作可能會導致 Looker 程序遭到終止。設定專屬的算繪節點，可讓算繪工作達到最佳調整效果，同時維持互動式和內嵌應用程式的反應速度。
如要享有這些優點，請按照下圖所示，設定具有自訂啟動選項和適當負載平衡規則的節點，並參閱這個選項的「優點」和「最佳做法」一節。此外，由於 Looker 的算繪服務會依附於共用 CPU 時間和記憶體的第三方 Chromium 程序，因此算繪節點可能需要比標準節點更多的主機資源。
優點
- 為特定函式指派節點，可將用於算繪的資源與開發和臨時分析函式區隔開來。
- 使用者可以開發 LookML 及探索內容，不必從負責算繪 PNG 和 PDF 的節點取得週期。
- 大量使用者流量湧入一般節點，不會妨礙由算繪節點處理的算繪工作負載。
最佳做法
- 每個 Looker 節點都應託管在專屬的 VM 中。
- 負載平衡器是叢集 Ingress 點，應為第 4 層負載平衡器。這個伺服器應設有較長的逾時時間 (3,600 秒)、配備已簽署的 SSL 憑證，並設定為從 443 (https) 轉送通訊埠至 9999 (Looker 伺服器監聽的通訊埠)。
- 從負載平衡規則中省略算繪節點，這樣節點就不會處理使用者流量和內部 API 要求。
- 在算繪節點中為 Java 分配相對較少的記憶體，讓 Chromium 的程序有較大的記憶體緩衝區。請將 40% 到 50% 的記憶體分配給 Java，而非 60%。
- 非算繪節點的記憶體壓力風險已降低，因此可增加 Looker 專用的記憶體量。建議您改用較高的百分比，例如 80%，而非預設的 60%。
- 建議部署作業的儲存空間每 GB 有 2 個 IOPS。