# 6-1 Cluster-Based Scalable Network Services

## 1. Introduction
* Network Services挑戰
* Scalability
* Availibility: 儘管碰到故障也要24x7
* Cost effectiveness
* 提出一個用於建構network serviece的分層framework，使用cluster 來滿足以上三個挑戰
### 1.1 Validation: Two Real Services
* 兩個實際應用的network service system
* TranSend
* Inktomi
### 1.2 Advantages of Clusters
* 相比單一大型機器，用cluster有三個優勢：
* Scalability:
* 高度平行
* 運算能力遠高單一大型機器
* High Availability:
* node獨立性，有獨立的bus, power supply, disk, etc
* Commodity Building Blocks
* 優勢在成本及性能比，技術都可以保持在技術前沿。
* 大型機器對於購買安裝升級更加繁瑣，切只能由單一供應商支持，當出現困難時更加難也獲得幫助
### 1.3 Challenges of Cluster Computing
* Administration
* 管理多個節點的複雜性
* Component vs. System Replication
* 專注於組件級別的複製而不是整個系統的複製
* 每個component有明確的功能責任，並且可以與同類型的component互換
* Partial Failures
* 需要處理部分故障，在子系統故障時也能生存
* Shared State
* cluster沒有共享狀態，能最小化cluster之間的共享狀態需求，則可以減少複雜性
### 1.4 BASE Semantics
* ACID語意:
* 強調原子性，一致性，隔離性，持久性
* 提供最強語意，但是成本及複雜性高
* 不保證可用性
* BASE語意:
* 強調高可用性
* 舊數據的容忍性
* 軟狀態：可以通過額外的計算或文件I/O重新生成，用以提升係能，數據不是持久的
* 近似答案：用舊數據或是不完整的軟狀態快速提供的近似答案，可能比慢速提供的精確答案更有價值
* 主要操作為BASE數據，用以極大簡化了容錯和可用性的實現，並允許優化，這在ACID下是不可能的
## 2. Cluster-Based Scalable Service Architecture
:::info
* 提出一種可擴展的網路服務的系統架構，利用集群計算的優勢
* 將內容(功能)與實現分離
* 無狀態工作模組的組合來建構模型
* 透過詳細測量來驗證性能以及可靠性
:::
### 2.1 Proposed Functional Organization of an SNS
* 可擴展網路服務SNS的結構
* Front Ends
* 提供外部世界的接口
* 處理傳入的請求
* 維護許多同時未完成的請求的狀態來最大化系統吞吐量，並且可以為了可擴展性和可用性進行複製
* Worker Pool
* 緩存和實現實際服務的的特定服務模塊(數據轉換/過濾，聚合等)
* Customization Database
* 存用戶配置文件，允許大規模訂製請求處理
* Manager
* 在工作模塊之間平衡負載，並在負載波動或者出現故障時生成額外的工作模塊
* 必要時可以將工作分配給溢出池中的機器
* Graphical Monitor
* 支持追蹤和可視化系統行為，異步通知錯誤
* System-Area Network
* 低延遲高bandwidth
* 防止隨著系統規模擴大連成瓶頸
### 2.2 Separating Service Content From Implementation: A Reusable SNS Support Layer
:::danger
SNS
:::
* 分層軟體模型允許層支籤相互隔離
* 允許reuse
* 分三層：
* 主要貢獻為SNS層的重用性，以及在在TACC層增加簡單無狀態的building blocks，並組合在Service層

以下說明SNS層的特性：
#### 2.2.1 Scalability
* SNS架構中的組件會被複製來處理fault tolerance以及達到高可用性，以及高擴展性
* 組件之間都相對獨立，這樣所需的額外資源負載會成線性關係
#### 2.2.2 Centralized Load Balancing
* manager會從worker拿資訊來平衡，並定期傳輸給前端來根據提示來schedule
* 選擇集中式而非分散式負載平衡是為了更容易實施和理解負載平衡策略的行為
* 集中式設計使實現和推理平衡策略更加容易而不易行程性能瓶頸
#### 2.2.3 Prolonged Bursts and Incremental Growth
* example: Pathfinder登入火星後，其網站在四天內服務超過2.2億次點擊
* 為了吸收這些突發流量，架構中會和外設計一個溢出池，其通常worker不會運行，管理者可以在突發期間根據需求來啟動worker，並在結束後釋放
#### 2.2.4 Soft State for Fault Tolerance and Availability
* Soft state: SNS組件依賴週期性的消息刷新緩存的soft state來建構穩健性
* 組建之間會使用process對等容錯，進行監控和重啟
* 重啟後，組建通過接收其他組建的broadcast來重建其soft state
* 使用timeout的機制來容錯，以推斷無法檢測的故障模。若timeout可以自動恢復，管理者會執行必要操作，否則SNS層會報告故障，由service層決定如何處理
#### 2.2.5 Narrow Interface to Service-Specific Workers
* 為了讓新服務能夠重用所有設施，管理者和前端會提供一個narrow API
* worker stub
* 提供機制讓worker報告負載數據和運行故障
* 隱藏容錯和負載平衡的複雜性，使worker code可專注於服務內容
* manager stub
* 調度獨立於負載平衡和容錯機制，可用相同的worker
### 2.3 TACC: A Programming Model for Internet Services
:::danger
TACC
:::
* 在做transformation, aggregation, caching, customization
* transformation: 對數據作操作像是轉碼，過濾等等
* aggregation: 從多個資料收集數據來做特定處理
* caching: 儲存transformation或aggregation後的結果
* customization: 可以根據配置來進行customize
*
## 3. Service Implementation
:::danger
TranSend的case study
:::
### 3.1 TranSend SNS Components
* TranSend由前端，負載平衡管理者，容錯機制，用戶配置文件數據庫，緩存節點，特定數據類型的蒸餾器和圖形監控工具組成
### 3.2 HotBot Implementation
* 與TranSend的worker不同的點是HotBot worker節點是不可互換的
* 節點故障則其他節點自動接管數據責任，並能保持100%數據可用性，性能會稍微下降
### 3.3 Summary
* TranSend實現很符合該篇論文之架構，而HotBot略有不同。兩個的成功經驗都證明了該架構的有效性，並透過分成架構簡化實現和提高了系統的可擴展性和容錯能力。
## 4. Measurements of the TranSend Implementation
### 4.1 HTTP Traces and the Playback Engine
* UC Berkerly的25000用戶中收集約20萬條HTTP請求，其中包括GIF, HTML, JPEG最常見
* 大多Web大小小於1MB, 但大多字節為大型內容(3-12KB)
* TranSend目標是透過蒸餾這些大型內容來減少用戶傳輸速度
* Playback Engine: 為了用來進行壓力測試，可以精細實施負載量
### 4.2 Burstiness
* 觀察結果：
* 24hr內：觀察到明顯的 24 小時週期，同時疊加了較短時間尺度的突發。
* 3.5小時和3.5分鐘內：揭示了更細粒度的突發。
* 架構設計：
* 溢出池：用來應對突發流量，先前提過
* 兩種管理溢出池的方式：
* 根據平均期望利用率
* 根據的特定百分比
### 4.3 Distiller Performance
* 測試方式：透過計算約100000個項目的蒸餾延遲，來測量蒸餾器的性能
### 4.4 Cache Partition Performance
* 緩存性能分析：
* 平均緩存命中時間：27毫秒
* 未命中懲罰時間：100毫秒內
* 緩存模擬：
* 用戶數量會大大影響命中率，與數量單調增加，但超過一定數則成長趨向平緩
* 緩存大小：對於8000用戶，6GB緩存空間提供了56％命中率
* 前端瓶頸：
* 高度未命中的懲罰會有額外大量發送請求和用TCP在frontend node, client, cache中連接，會造成額外開銷
### 4.5 Self Tuning and Load Balancing
* TranSend使用蒸餾器的隊列長度作為負載平衡的指標
* 當蒸餾器負載超過threshold, 管理者會生成新的蒸餾器來吸收負載，吸收時會暫停幾秒來穩定
### 4.6 Scalability
* 目標：在增加負載和資源時能可擴展，線性增長
* 實驗：
* 一開始的實例：前端＋蒸餾器＋數個緩存分區
* 持續增加負載直到某個組件飽和
* 添加更多資源直到飽和消除，紀錄資源增加及負載增加關係
* 重複以上步驟直到資源用盡或添加更多資源不再帶來線性增長
* 實驗結果：
* 24 請求/秒：單個蒸餾器飽和，管理者自動生成新的蒸餾器。
* 87 請求/秒：以太網段飽和，需要生成新的前端。
* 159 請求/秒：系統中的所有機器均被佔用，無法進一步測試。
* 線性增長：
* 蒸餾器能夠處理大約每秒 23 個請求。
* 100 Mb/s 以太網段能夠處理大約每秒 70 個請求。
* 數據庫：
* HotBot 的 ACID 數據庫能夠處理每秒約 400 個請求，顯著高於 HotBot 的負載。
* 內部網絡：
* 10 Mb/s 交換以太網接近飽和時，管理通信受影響。
* 總結：TranSend 在負載增加和資源擴展方面展示出良好的線性增長，系統的可擴展性主要受限於共享或集中管理的組件，如用戶配置文件數據庫、管理者和內部網絡
## 5, 6. Conclusion
* 提出分層架構
* 透過兩個case study: TranSend, HotBot來展現分層架構在可擴展性，高可用性，容錯性。
* 性能測試來表明可以有效處理負載和突發流量，緩存效率也有效的提升性能
* 能通過動態生成和調整蒸餾器來應對動態的負載變化，及透過溢出池面對突發流量
* 透過軟狀態及自動恢復機制，快速恢復來面對故障管理
* 未來研究：在不同網路拓墣下能進一步提升性能，服務擴展