功能介紹
LDAP（輕量型目錄存取協定）是普遍使用的目錄資訊來源，最早於 1993 年制定。它常用於各種應用情境，包括管理 Linux 執行個體的使用者／群組資訊，以及控制 VPN 和舊版應用程式的驗證。
傳統上，公司的 LDAP 伺服器是在內部運行。通常是 Microsoft 的 Active Directory 的一部分，或是開放原始碼 OpenLDAP 專案的部署。如今，SaaS 供應商已提供 LDAP 支援，其中包括 Foxpass。Foxpass 是第一家從零開始建置多租戶、以雲端為核心的 LDAP 實作的雲端 LDAP 供應商。
LDAP 通常具有下列基本操作：bind、search、compare，以及 add。建立 Transmission Control Protocol (TCP) 連接後，應用程式必須先透過傳送使用者名稱和密碼來bind。成功繫結 後，用戶端會向 LDAP 伺服器發出命令。通常，這是搭配篩選器使用的 搜尋 命令。TCP 連接會持續保持，直到用戶端或伺服器任一方中斷連接。
Foxpass 的 LDAP
在 Foxpass，我們的 LDAP 服務是建構於適用於 Python 的熱門事件導向服務框架 Twisted 之上。此服務託管於 AWS 的 ECS 平台上，並在數十個容器（節點）上執行。由於 LDAP 連接是持續性的，叢集必須能夠維持數十萬個同時 TCP 連線。
我們將客戶的資料保留在 RAM 中。原因有好幾個：首先，這個 資料集相對較小，即使對大型客戶來說也是如此。其次，LDAP query language 可搜尋任意欄位（這點很重要，因為 Foxpass 支援自訂欄位）。這表示傳統的 RDBMS 系統無法建立有效的索引，因此我們必須將資料轉換為不同的記憶體內表示方式。第三，將資料保留在 RAM 中可實現最快的回應時間：延遲通常約為 100ms（見圖 a）。
這種方法的一個缺點是快取失效。當客戶的資料發生變更時（例如新增或刪除使用者），LDAP 節點必須從我們的主要 RDBMS 重新整理其資料。在我們先前的架構中，這是一項相對昂貴的操作；當每個節點重新整理同一家公司的資料時，可能會導致 LDAP 延遲明顯升高，並增加後端儲存的負載。
延遲敏感度挑戰
如上所述，由於延遲需求，每個容器都會將客戶的所有資料儲存在記憶體中（見圖 a）。資料會在請求到達節點時按需擷取（如果尚未存在），之後只要該客戶至少還保有一個連接，就會持續保留。
由於傳入的連接請求可能會落在任何容器上（透過負載平衡器），因此負責處理查詢的容器也會載入並儲存該客戶的所有資料。隨後，容器會向 redis pubsub 服務註冊，以接收失效訊息。當公司的資料更新時，系統會將失效訊號廣播至接收節點，這些節點會清除該公司的資料快取，並前往資料庫重新擷取該公司的資料。
隨著我們持續成長並將新客戶加入系統，這也為擴展 LDAP 服務帶來了以下挑戰：
客戶（M）在所有節點（N）上的所有資料在失效時都需要重新載入。雖然實際上並非每個節點都會承載來自每位客戶的連接，但在最糟情況下，為了重新整理資料，會對資料庫發出 MxN 次呼叫。隨著新增的客戶越多（M），DB 擷取次數可能會增加為 N 倍。這也意味著，為了不讓資料庫機器負載過重，需要額外的 DB reader 執行個體來處理激增的請求。
由於所有客戶（M）的資料都儲存在多個節點（N）的記憶體中，因此所有節點的記憶體用量都會隨著客戶數量（M）增加而持續成長。這也表示，容器的記憶體需求必須增加，以容納記憶體中的所有資料，進而提高整體基礎架構成本。
上述挑戰非常明確，因此我們傾向於將客戶資料分散到各個節點，而不是在每個節點上複製所有資料。這讓我們採用了分散式快取管理解決方案。
分散式快取管理
我們在 LDAP 服務中導入了智慧路由層；如果連線落在的容器未承載客戶資料，該層就會將請求轉送至承載該客戶資料的節點。為了達成這一點，我們將路由層的設計需求縮小至以下幾項：
隨著節點新增，客戶需要能夠動態分配到各個節點。
隨著節點縮減、擴充及發生節點故障，客戶資料需要能夠動態分散。
可針對特定客戶增加或減少分割區數量，避免流量不均而壓垮任何單一節點。
我們導入了 Apache Helix，將資源分散到各個執行個體。Helix controller 是 helix 生態系統的 大腦，會在新增或移除節點或客戶時，跨節點做出資源指派決策。我們將 Apache Helix 控制器與 Rest 伺服器容器化，並部署到 ECS 上。Helix 控制器依賴 Zookeeper 來監聽叢集變更。我們已實作出在 ECS 上部署 Zookeeper 的可靠方式，因此現在 Helix 和 Zookeeper 的整個基礎架構都在 ECS 上執行。
每個 LDAP 節點都會與 Zookeeper 互動，以註冊自身並參與叢集。每個 LDAP 執行個體都會作為 Helix 參與者啟動，並在 Helix 控制器的協調下，參與客戶到節點指派的叢集。當 LDAP 節點即時建立新客戶時，該客戶的分割區數量（每個分割區代表一個承載資料的節點）會依據使用者數量決定。
透過這項整合，我們的 LDAP 節點能感知叢集中發生的事件（例如新增客戶時，或可用節點集合發生變更時）。
有了這項叢集感知能力後，我們 LDAP 服務中的路由層便可在節點與客戶之間提供對應關係。現在每個傳入連線都會先經過路由層，以判定該連線必須被路由到哪個節點。藉由此，客戶的資料會被指派到特定節點（見圖 b）。
路由層代管一個快取，其中包含客戶和節點的路由資訊。路由層會識別任何客戶到節點指派的變更，並在偵測到變更時立即更新。如此一來，每個 LDAP 節點都能在客戶對節點的變更一發生時立即得知。
透過上述快取管理解決方案，已解決 延遲敏感性挑戰 一節中提到 的可擴充性挑戰：
我們現在已有客戶分布在各個節點。每個節點只會承載部分客戶，並且在收到 pubsub invalidates 時，只負責擷取部分客戶的資料。這可大幅減少對 DB 的讀取次數，無需再新增 DB 讀取節點來處理大量的 DB 讀取需求。LDAP 叢集現在的 DB 讀取次數比以前減少了 75%。
我們也提升了記憶體使用效率，因為我們不需要在所有節點（N）的記憶體中儲存所有客戶（M）資料。此架構可在不增加執行個體大小的情況下，提供水平擴充的能力。現在每個 LDAP 節點的記憶體消耗量都比以前少 40%。
目前的挑戰
透過上述實作方式，其中一項挑戰是各節點接收到的 TCP 連接數量並不平均。這種分配不均會導致某些節點（熱點節點）的 CPU 使用率高於其他節點。但與之前相比，各節點的整體平均 CPU 使用率仍維持不變。
致謝
感謝整個團隊。特別感謝 Bryan Bojorque 協助我們完成 Helix 和 Zookeeper 叢集的容器化與建置，並將這些叢集的指標資料成功導入 Datadog。
升級安全性
您的網路是否受到保護，免於未經授權的使用者存取？按這裡，了解 Foxpass 如何協助避免代價高昂的安全錯誤：
