這篇文章會分享第一次看到 Elastic Cloud Enterprise 架構的心得還有解釋一些比較特別的名詞。

Elastic Cloud Enterprise

Elastic Cloud Enterprise 是 Elastic Stack 雲端企業用的版本，提供了較完整的服務導向系統架構，還有完整的配置建議教學，減少了較沒經驗的工程師在增修了系統配置後反而更加不穩定的問題。

為什麼使用 Elastic Cloud Enterprise 而不自己管理?

• 減少部屬跟管理硬體架構的成本，像是管理網路、防火牆、硬碟狀況等等
• 用 docker 最大化硬體機台的使用率，隔離資源避免 Split Brains 這類問題
• 提供安全性、HA 的保證，減少因為一個服務沒處理好就整台機器掛掉的風險
• 能夠集中管理散布在各地的服務

ECE Features

• 服務都以 docker 容器的方式提供
• 透過多個 Availability Zones 做到 HA
• 透過 ZooKeeper 管理協調節點部屬的狀態
• 透過 API 或是網頁版 GUI 可以很方便的操作管理
• 支援離線安裝
• 系統還原或是快照功能

Roles and Runners

每台機器上會有一個 Runners 負責控管每一台機器，確保所有的容器都是正常健康運作的，Runner 會被給予多個角色，每個角色則會對應到不同的容器，有不同的權限及用途。

• Proxy Role，處理使用者請求，確保相關靜態資源的可存取狀態，協助不停機升級或擴充
• Allocator Role，負責把所有節點上的服務跑起來，負責產生新的容器並啟動節點
• Coordinator Role，負責 constructor，協調系統資源與排程
• Director Role，管理 ZooKeeper，只要被 assign 那台機器上面就會跑 Zookeeper 的服務，且服務不會因為角色移除而消失

系統架構

系統架構圖如下，可以看到每台機器上都會有一個 Runner，每個服務都會部屬在各自的 docker container 裡，幾個主要區塊如下

• Load balancers: 附載平衡負責導流
• Proxies: 監控每個 availability zones 是否健康，通常會在附載平衡後面接好幾個確保 Proxy 穩定
• Allocators: 管理節點上的站台服務，每個節點上服務的 CRUD
• Control Plane: 負責管理整個架構的核心
  • ZooKeeper，分散式系統中確保文件寫入一致性，用來存放 ECE 元件部屬狀態與所需的配置資訊維護像是 Proxy 的 Routing Table，會透過 STunnel 跟 ECE 元件們傳遞訊息溝通。
  • Director: 管理 ZooKeeper
  • Constructor: 排程與監控，當有相關狀態改變就要即時寫入 ZooKeeper，也負責分配節點到不同的 availability zones 確保服務可用性
  • Cloud UI and API: API 相關管理

系統架構圖

小結

過去的經驗有直接架過包含附載平衡的實體主機、用過 Azure App service 服務和虛擬機、Aws 開虛擬機搭配部分服務，底下分享一些使用過的優缺點跟心得。

• 若買過 MS 版權軟體，實體機買斷長期較便宜，花同樣錢雲端開到同規格會比較貴
• 雲端服務大多提供快照、快速恢復的功能
• 實體機較容易遇到道路施工挖電纜影響，以前就至少遇過兩次服務需要中斷一點時間的狀況
• DDoS 等攻擊實體機需要透過配置防範，雲端大多有整合相關服務
• 實體機擴充較不容易，雲端服務可幾分鐘內完成可擴充彈性大，早期就遇過硬碟最大才 2T，每過一段時間，資料庫都要定期移轉資料到其他機台的狀況
• 如果套用了一些雲端微服務，可能會造成系統架構更複雜難懂，按照教學用了不太懂的服務後帳單突然變很貴，我之前同事就遇過但還好一周內發現，寄信給 AWS 後有退款成功

會適合用實體機自建的狀況:

• 本來公司就有購買主機、相關版權，像之前公司有買高級 NAS，拿來架 WordPress 官網前面掛個 Cloudfare 其實很夠用
• 公司有 MIS、維運團隊、架構師

會適合用雲端服務的狀況:

• 團隊較小，產品還沒穩定營利前
• 第一次申請完全可以先只用免費的額度，早期 Azure 還有新創方案超便宜