# 6.1 Cluster-Based Scalable Network Services
## Introduction
- 由於網路發展，許多服務都是透過網路來提供，然而在部屬上有幾點需要考慮
- 擴展性: 用戶數量變大時
- 可用性: 要24/7運作
- 成本: 拓展的經濟成本要便宜
- 比起使用高規格的一台電腦，使用由多個消費級電腦組成的叢集可以帶來上述三點的優勢
- 擴展性: 可以持續增加新的節點，而不用淘汰本來的設備
- 可用性: 部分結點失效，還是有其他結點在
- 成本: 使用的是一般消費級電腦，其零組件可以有多種選擇並快速更換
- 叢集運算相比單台高規電腦，還是有些劣勢
- 管理: 單台電腦叫好管理，而叢集會需要一些額外工具
- 部件層級複製 vs 系統層級複製: 使用叢集，可以把一個大服務拆成多個小服務給不同結點運作，單台電腦的話就可以直接從系統層級做複製，而使用叢集的方式需要則會複雜化複製的議題
- 部分失效: 單台電腦就只會有完全死去跟運作中，而多個小服務散佈於叢集的方式，則有可能發生某個小服務失效
- 分享狀態機的狀態: 單台電腦可以完全了解狀態機的運作狀況，然而使用叢集，多個結點會互相不知道對方的狀態。但在設計時，藉由避免或最小化對於狀態機的需求，可以降低這個問題帶來的影響
- 眾多的網路服務，作者拆分成兩種模式
- ACID
- 傳統事務資料庫的 ACID，為了保持 strong consistency，會有較高的 cost 跟複雜度，也沒保證其服務的可用性
- 情境如 網路交易 維護使用者資訊
- BASE (Basically Available, Soft State, Eventual Consistency)
- 不強求 strong consistency，主旨是為了最大化可用性，並保證 eventual consistency
- 可容忍 Stale data
- 會有 Soft state，可以快速響應使用者請求，我個人理解像快取
- 而為了可以快速響應使用者請求，會提供 Approximate answers
- 簡單區分的話，可以把所有服務分成 ACID 或 BASE 兩類，然而也有實際案例是兩者共有存在
- Yahoo! 把 soft state 的 資料庫歸類為 BASE，而對於使用者的設定歸類為 ACID

## Architecture
- 提出一種通用的 SNS (scalable network service) 架構
- FE (frontend): 將服務與外界互動的介面，在收到請求後，會透過 user profile db 拿取不同使用情境的客製化參數，傳遞給 worker 進行邏輯處理
- WP (worker pool): 包含快取和服務邏輯本身(資料轉換、資料跌帶等等)
- Customization Database (圖中的 user profile db): 儲存不同使用者配置的參數，連帶影響邏輯處理的過程
- 簡單例子像是許多網頁會記錄你偏好的背景色是深色還是淺色，此參數傳遞給 server 後，最終會呈現不同的樣子
- Manager: 處理 load balancing，創建新的 worker
- Graphical Monitor: 給管理員的系統監控
- System-Area Network: 整個 SNS 處在的環境，確保低延遲 高頻寬
- 透過職責分層，可以更好地重複利用相同部件，分成 3 層
- SNS
- 由 front ends, manager, SAN, and monitor 組成，旨在提供 scalability, load balancing, fault tolerance,和 high availability
- 由於各角色職責明確且各層互相獨立，因此可以以線性的方式增長某部件的可負載量
- FE 只負責將正確的客製化參數傳給 worker，並接收 worker 回傳的結果，如果是 error，就針對不同 error 做不同回復。FE 還會有一個 manager stub，主要是指派請求該交由哪個 wroker 處理
- Worker 本身會有一個 worker stub，會向系統提供 worker 狀態，使 manager 可以處理系統附載。因此真正的 worker code 只需專注於邏輯本身，體現出 worker 越簡單越好的本質
- 有一部分的機器屬於 overflow pool，以應付突發的請求數量
- 透過 process peer fault tolerance，假如一個部件的某個節點壞了，其餘同層集結點會去重啟他，但他重啟完後，會再去向其餘節點拿取資料回復
- TACC
- Transformation: 做資料轉換，如編碼，加解密
- Aggregation: 從多處收集資料並整理
- 舉例: 從多個網站收集當周活動的資訊，並整理出一份本周會有甚麼活動以及呈現各活動資訊的頁面
- Customization:　如前面提到 user profile db 的作用，這樣使 worker 可以根據不同參數，彈性地對不同請求有著不同回傳結果
- 舉例: 有一個 worker 是做相片壓縮，可以根據請求來源是網頁或是手機，傳給 worker 的壓縮參數就會不同，但是他還是可以正確地做壓縮，並回傳結果
- Caching: 可以儲存 transformation 的結果或是轉換過程的中介值
- 透過各部件的職責劃分，對於提供 Transformation 和 Aggregation 的 worker，他可以只需要專注其真正的邏輯本身就好，不用去管目前系統的資源使用情況或是請求指派邏輯等等，這給與了相當大的彈性以及擴展性

## Case Study
- 透過實際案例來了解 SNS 架構的優勢
- TranSend (做網站呈現，會需要壓縮圖像來做快速響應)
- Front Ends
- 就是前端網頁，有很多 node 去接請求，高度平行化
- 請求收到後，透過 user profile db 拿取參數，傳遞給 distiller (TranSend 的 worker)進行處理，並回傳結果。如果是 cache hit，也可以直接從 cache 回傳
- Load Balancing Manager
- 採用集中式管理，也就是一個 manager，比起分散式較好管理，也較好實作
- 檢查 distiller 還在不在，附載量高不高，需不需要開新的 distiller
- manager 與各部件之間透過 IP multicast group 交流，如此雙方不用一定要知道對方的卻切位置也可以交流
- manager stub 在收到新的請求後會交由 manager 決定給哪個 distiller，同時快取這個決定。也因為有快取，就算 manager 暫時失效，也還是可以持續交付請求
- worker stub 對請求做排隊，並時刻回傳 worker 狀態給 manager
- 假如所有 worker 節點都滿了，但還是有請求，manager 會啟用 overflow nodes 來暫時頂替
- Fault Tolerance and Crash Recovery
- 如前面提到，因為有了快取，manager 管理的資訊成了 soft state，不用特別額外紀錄失效的其間發生了甚麼事
- 透過 IP multicast group，worker 和 manager 互相可以知道對方是否還在，如果 worker 在取消註冊前不見，代表 worker 失效，可以將工作交由其他 worker 處理。如果 worker 發現 manager 無法溝通，代表 manager 失效，要去重新跟新 manager 註冊
- 各部件唯一要做的就是在得知對方失效時，要去重啟他
- User Profile Database
- 紀錄 user 的客製化參數
- 讀大於寫
- Cache Nodes
- 在 TranSend 叫做 Harvest
- manager stub 會將多個 harvest 當作一個虛擬快取，透過 hash 快速得知想要的資料在哪個快取節點上
- distiller 可以將其結果或是轉換的中介值塞進去，用以加快處理以及回復速度
- Datatype-Specific Distillers
- 我個人理解這邊就是介紹 worker
- 在前面有介紹過，受益於 SNS 架構，worker 只需專注於功能實現，因此可以透過各種SOTA技術達到目的
- Graphical Monitor
- 作者之前的論文有實作類似的工具，可以讓管理者遠端的監控整體系統的狀態
- 總結
- manager 管理的 load balancing data 都是 soft state，代表有可能是 stale 的，但也就是因為有快取，反而增加了容錯率。就算因為舊的快取導致請求導向失效的 worker，可以透過 timeout 機制，再轉發給其他 worker
- worker 本身也有快取一些資料，假如目前附載很高，worker 可以直接把快取的資料回傳，就算他是舊的也沒關係，因為她也是相近的結果 (Approximate answers)
- HotBot (搜尋引擎)
- HotBot 與 TranSend 在大部分元件都是採用相同運作方式，但還是有些不同
- Load Balancing
- 所有的搜尋資料分散在所有 worker 上，因此每次請求都會平行地找過所有 worker
- Failure management
- 不是像 TranSend 那樣使用 peer 的方式重啟部件，而是對節點的硬碟做 RAID，如此當某個節點就算壞了，也還是可以從其他結點拿資料

## 測試
- 這邊是對 TranSend 的架構測試，因為 TranSend 更加接近本篇論文的 SNS 架構
- 請求資料類型
- 透過監控，發現最常傳輸的是 GIF, HTML, JPEG。其中也可以看到大部分的資料都大於 1KB (視為大檔)，這也是正式 TranSend 的目的，要壓縮這些圖像來加快傳輸
- 1KB 以下的，不壓縮直接傳
- 突發流量
- 前面提到使用 overflow pool 來暫時頂替 hold 不住的流量，可以使用兩種規則來決定何時使用 overflow pool
- 一超過一定的附載量
- 可以承受高流量多少時間
- 而根據不同時間的請求流量圖，我們也可以判定在大部分時間要配置多少 worker 才足夠
- 快取效率
- hit rate 隨著快取變大而上升，但是在超過一定使用者基數而撞到瓶頸
- 使用者剛開始成長時，會受益於 cache，然而使用者越多，請求的東西越多樣，反而容易 miss
- front end node 跟 cache 之間是採用 TCP 連線，同時也要跟 client 保持 TCP 連線，其本身內部又有很多 thread 要同時處理請求，front end node 花了大部分的時間在 kernel，而如果又加上 cache miss，front end 的效能便會降低
- Self Tuning and Load Balancing
- Worker 本身會用 queue 使任務排隊，而當負荷超過門檻值，manager 便在開啟另一個 worker 分擔
- 在下圖的實驗證實了這點，不管是流量足部增長或是某個 worker node 突然死掉，附載平衡都有成功執行
- Scalability
- 透過壓力測試，測試系統擴展性，於每秒 25 請求以上會開始增加 worker node，於每秒 88 請求以上會開始增加 front end node，最終因為每秒 159 請求時已經沒有結點可以給與，資源耗盡
- 而隨著 node 變多，內部的共用元件也受其影響 (user profile db, manager, SAN)
- 經過測試，manager 出乎意料的可以處理非常多的 node 狀態資訊，高達高峰期的 3 倍。而 user profile db 也是相同結果，足夠處理大於高峰期的流量
- SAN 作為內部各元件的互相溝通的網路，隨著 node 變多，頻寬被占滿，開始有些資訊沒有正確傳遞給 manager。作者提供兩種解法: 可以考慮將狀態資訊跟請求資料使用兩種不同網路傳遞，或是用效能更好的網路替換

## Conclusion
- 提出 SNS 架構，講求部件高度重複使用，且職責分配明確
- Worker node 為 stateless，且可專注於邏輯本身，不需額外考慮系統層面的東西，如附載量，容錯率
- 第一個提出 BASE 概念的論文
- 透過 TranSend, HotBot 實際案例了解 SNS 架構的運作方式