全球6大數據中心，日均10億日誌場景下的高可用實踐

嘉賓 | 張磊、姜冰

寫在前面

近幾年互聯網服務安全事故的頻發，使得越來越多的企業及開發者意識到數據備份、災備等重要性，高可用性、高容災性及高可擴展性的系統和架構建設工作也被更多地置於重心。

在這個過程中，基於公有雲提供的基礎設施實現高可用已成為多數技術團隊的選擇。

而面對跨區域 + 高可用需求時，許多開發者卻犯了難，一方面業務場景的不同對架構設計提出了不盡相同的需求，基本上沒有可完全複製的架構模版；另一方面是納入考慮的因素在不斷增多，數據延遲、成本開銷、物理隔離、快速的恢復能力……如何能在加法的基礎上做好減法，對技術團隊創新能力提出了更高要求。

對此，InfoQ 專訪了 FreeWheel 架構師張磊及 FreeWheel 首席工程師姜冰，探討在服務全球 6 個數據中心，日均產生近 10 億廣告投放展示日誌的場景下，做好跨區域高可用的實踐之道。

跨區域、高可用性實踐背景

數據處理平台提出的多維挑戰

作為美國 Comcast 旗下領先的視頻廣告管理和投放平台，FreeWheel 的數據來自於全球 6 大數據中心（美國東西海岸各兩個、歐洲兩個），每天產生 10 億左右的廣告投放展示日誌，新增超過 3TB 的數據，並且有至少 18 個月的數據可以隨時滿足查詢尋求。

在數據應用對實時性和可靠性要求逐漸增加的情況下， FreeWheel 根據其自身數據特點和應用需求，採用了一套以 Kafka，Hadoop 和 HBase 為核心的 Lambda 處理架構。

其中，各個數據中心的廣告伺服器實時地將廣告數據傳輸到本地 Kafka 集群。中心化的 Kafka MirrorMaker 將多數據中心的數據聚集到一個全局的 Kafka 集群。流式處理框架會從全局 Kafka 集群消費數據，處理之後一方面寫回 Kafka（為下游的各類實時應用服務）；一方面寫入 HBase，並由 Hadoop 離線作業將 HBase 的內容聚合轉換成 Parquet 文件寫入 HDFS。構建於 Presto 之上的 OLAP 服務會同時查詢 HBase 和 HDFS，對外提供數據的實時或批量查詢（整體架構見下圖）。

FreeWheel 數據處理系統架構圖

FreeWheel 部署的這一套數據處理系統，很好地實現了預期的設計目標。但過往幾年裡，隨著數據量的不斷增長和業務變化的需求，這種模式面臨了如下挑戰：

可擴展性：越來越多的數據產品接入到新的數據平台，對數據處理和查詢服務的擴展性提出了嚴苛的要求。而在自建的數據中心，受限於規劃和整體容量，很難根據需求靈活地擴展。 同時，在「超級碗」這樣大型賽事的直播帶來流量瞬時波動的場景下，傳統的數據中心也很難滿足對容量的彈性需求。

高可用性：雖然像 Hadoop 這樣的大數據基礎設施本身可以保證一定程度的高可用性，但在遇到數據中心整體性故障時，依然會對服務造成影響。

開發和測試效率：大數據平台開發和測試中，基於真實環境的集成測試和性能測試可以覆蓋單元測試和回歸測試的盲區，這需要經常啟停一些基礎組件甚至整套端到端服務。但在自有數據中心裡，受到資源限制，很難做到及時滿足需求，因而也降低了開發和測試的效率。

理論上，上述挑戰中的一部分可通過在另一個自建數據中心裡再部署一套數據處理系統解決或緩解，但考慮到規劃、擴容所需時長以及問題根治性等因素，在 2016 年底，FreeWheel 決定與 AWS 合作，將數據平台和數據處理系統部署到雲端。

選型過程並不複雜，FreeWheel 主要從成熟程度、數據監管、可用區（AZ）數以及原生服務的數量與廣度等方面考量，最終選擇了 AWS 作為雲服務商。

基於 AWS 原生服務的使用權衡

整體上，FreeWheel 在 AWS 上也部署了一套 Kafka MirrorMaker，同步所有數據中心的數據，再將數據處理平台基本原樣搬到了 AWS 上。

但如何權衡是直接使用像 Kinesis、DynamoDB 這樣的 AWS 原生服務，還是自己維護 Kafka、HBase 等基礎設施？ FreeWheel 也有一些思考。

張磊對此總結了兩點。一是從平台需求出發。AWS 許多原生服務在某種程度上的確能帶來開發和維護成本的降低，但對於基礎數據平台這類數據量極其龐大並且對穩定性要求很高的業務， AWS 的原生服務能不能滿足需求，能滿足需求的情況下成本是不是可控，這些都會是最終影響選型的因素。二是需要考慮開發者自身對技術的把控。AWS 的原生服務很多時候對使用者來說還是黑盒。當大家需要花大量時間去了解這些服務的內部運作原理，限制和故障處理時，不一定能降低時間和運維成本。

涉及到具體權衡與改造，姜冰也舉例講解了何時該選擇自身維護：

以 AWS 原生服務 Amazon EMR 和 Amazon Kinesis 為例，映射到 FreeWheel 的數據處理系統中相應的是 Hadoop Cluster 和 Kafka。基於 FreeWheel 以 7*24 小時流計算為主的業務類型，如果直接使用 EMR 及 Kinesis，將面臨如下問題：

原生服務開放程度較弱，因而開發者缺乏更多的機會維護和管理自身集群。例如從對外兼容性上看，Kafka 下游接了多樣的開源解決方案，與 Spark、Flink 等有天然集成，但 Kinesis 是閉源的託管服務，下游集成由 AWS 主導，日誌記錄的更新和變化將受制於 AWS 內部研發；

EMR 適合批處理的工作模式，在全天候不間斷的運行狀態下，基於 AWS 基礎計算和存儲資源自建的 Hadoop 集群能夠提供更好的可用性，從而更好地應對流處理場景。

在上述場景下，FreeWheel 並沒有主動選擇 EMR 或 Kinesis 原生服務，而是從成本、性能、開放程度、規模化和容錯管理等維度與自身維護做了對比實踐。但張磊也提到，在一般的使用場景下，對於 AWS 的原生服務，比如 RDS，Athena 等，FreeWheel 會鼓勵並儘可能地使用， 這樣才能更有效地滿足高可用需求，並降低總體開發維護成本。

截至目前，經過測試和調整，FreeWheel 已逐步把面向客戶的的所有產品都遷移到 AWS 環境中，目前自有數據中心裡只有極少數對內的服務在運行。而最終它們也都會遷移到 AWS 環境中。

高可用實踐需求及實現方案解析

高可用性設計目標

一個完整的全系統高可用性設計通常會涉及五大層面：基礎設施、伺服器、數據、應用程序、系統服務。

在基礎設施層，FreeWheel 更多的是將 AWS 視為一項服務。雖然 AWS 會充分保證其基礎設施的穩定性，FreeWheel 還是會在所有的服務都可能出問題這一假設下指導設計。伺服器層也是如此。

數據層，如果該數據存在於 FreeWheel 自身系統，其通常會藉助於像 Kafka、HBase 的天然多副本能力，即設置多個副本提供數據容災。

應用程序層，FreeWheel 一般會將它做到無狀態，從而更容易實現快速恢復和高可用，無論是水平擴展還是垂直擴展都更方便。

服務層，FreeWheel 採用的是 Failover（故障轉移）機制。即應用伺服器設置多台，彼此之間通過心跳聯繫。資料庫、緩存、應用伺服器等任何位置出現瓶頸就只需增加處理能力。目前，對於伺服器的對等可替換性，主要有三種類型：Active-Active（雙主）、Active-Standby（主備）以及單 Active。

在雙主模式下，FreeWheel 通常會通過先綁定 Amazon ELB，再註冊到 Amazon Route 53 的方式，從而實現自動對應用無感知訪問。

對於主備模式，FreeWheel 通常會將相應的信息註冊到 ZooKeeper，由 ZooKeeper 實現 Failover 的分散式協調服務，從而實現 Master 的選舉和對外服務發現。

對於單主模式，一般是一些離線任務，FreeWheel 會將其綁定在 ASG（Auto Scaling Group）中，出現問題時可以自動擴展重試。

高可用的整體實現方案

無論是跨 Region（區域）還是跨 AZ（可用區），數據交換都將產生一定的成本開銷。面對著龐大數據量和跨區域 / 可用區間的數據延遲，在 AWS 多可用區實踐過程中，FreeWheel 針對數據平台對於高可用的需求及 AWS 自身高可用實踐經驗，採用了多種定製方式——主要對 Hadoop-HBase、Kafka、Zookeeper 及數據處理部分實現了不同的高可用解決方案。

Hadoop-HBase 多可用區

在設計之初，FreeWheel 就試圖平衡了成本、性能和可用性之間的關係。但是類似資料庫系統中的 CAP 理論，這三者很難同時得到滿足。例如，AWS 上很多及其類型和存儲類型都不盡相同。為了提升 HBase 性能需要採用 instance store 這類本地 SSD 存儲方式，而相應的弊端也隨之產生：一旦掛載這個 instance store 這個實例出現異常，相應的存儲就會丟失。尤其是當其真實宿主機發生大面積故障時，可能導致數據的徹底丟失。

因此，FreeWheel 也需要對 HBase 在多個可用區上實現高可用。

對於存儲模塊，FreeWheel 選擇兩個可用區來部署，通過 HDFS Storage Policy 介面，實現數據塊副本數在主可用區和次可用區的分布。 對於無狀態的數據應用優先部署在與 Hadoop/HBase 主可用區同側，並支持在次可用區快速部署。應用和數據優先同側的策略，可以有效降低數據應用的因為跨可用區帶來的數據延遲，並降低可用區之間網路傳輸的成本開銷。藉助 AWS 提供不同存儲介質的 IOPS 和持久化特點，實現針對不同業務的工作負載靈活選擇存儲節點配置，並實現業務之間的物理隔離（原理如下圖）。

其中，隔離思路主要是基於不同的工作負載選用不用的 EC2 實例或 EBS 實例。這樣也可根據自身的業務特點，在 AWS 中選擇不同的硬體、實例類型或 EBS 類型來滿足需求。此外，FreeWheel 也可以在 AWS Hadoop 上實現一組機器的上線及下線，而且只把具有某一類標籤的機器上、下線，而不影響到其他數據。

Kafka 多可用區

Kafka Topic 內每個 Partition 有多個副本，多可用區部署，需保證在不同可用區的副本個數的劃分。姜冰提到，在正常情況下每個 Partition 里可設置多個副本，如果要保證高可用，意味著需要將多個副本同時被部署到同一可用區上，但同時，這樣做的弊端是無法保證可用區級別高可用，如果一個可用區宕機將導致整個 Partition 不可用。

於是，考慮到跨可用區帶來的數據延遲以及成本開銷，FreeWheel 針對數據應用和規模實現了不同的策略。

一種策略是，對於用於數據處理流程的 Kafka Topic，在次可用區僅部署 Partition 副本中的 Follower。應用程序和 Kafka 主可用區同側，讀寫數據的流量全部在同一可用區完成，這樣在主從可用之間，僅有 Leader 和 Follower 之間的網路傳輸開銷。在主可用區發生故障時，從可用區的 Follower 切換成 Leader 對外提供服務（原理如下圖）。

在這種情況下，Kafka 消費者只會在同一可用區消費，從而避免跨可用區間因網路傳輸帶來的成本消耗，同一可用區間的延遲性也大大降低。

而對於以在線服務為主的數據，為了提供更強的高可用和更快速的恢復能力，Kafka 採用 3 可用區對等部署的方案，無差別的對外提供服務：每一個 Partition 的 Leader 和 Follower 以公平的策略隨機分配到不同的可用區，在 AWS 出現可用區級別的故障時，Kafka 藉助 Leader 和 Follower 之間的切換，保證服務的高可用（原理如下圖）。

放在 FreeWheel 的具體業務場景中，為保證廣告主預算與廣告競價間反饋迴路的可用性高且延時性低，避免出現廣告超量投放或投放價格與預算偏差等問題，FreeWheel 即需採用上述第二類這種解決方案。

Zookeeper 多可用區部署方案

Zookeeper 集群是由 1 個 leader 和若干個 follower 組成，這些節點被部署到 3 個 AWS 可用區。應用通過名字註冊服務將主工作服務（Active）註冊到 Zookeeper。在可用區發生故障時，應用 Active／Standby 角色根據 Zookeeper 名字服務狀態變化進行切換，並註冊最新的 Active 服務到 Route53（原理如下圖）。

數據處理高可用部署方案

目前 FreeWheel DIP（Data Ingestion Pipeline）架構由兩部分組成，一是流處理工作類型，二是上下游以小時為級別的批處理工作類型。

流處理消費一次來源於 Kafka，同時會和 HBase 交互，所以就流處理來說，如果能解決數據和狀態高可用，其本身是屬於一條無狀態的數據處理流水線。反觀，這也是為什麼 FreeWheel 會花更多功夫在 Kafka、Hadoop-Hbase 和 Zookeeper 高可用部署上的原因，從而進一步確保流式數據處理狀態和高可用。

流式處理主要通過 Hadoop YARN 部署，採用 ASG 做擴展 / 收縮，以及採用 ASG 綁定同一 YARN 隊列的方式來保證高可用性。

對於批處理工作類型的解決方案，FreeWheel 也有比較好的 Failover 方案應對異常狀況下的自我修復。總的來說，利用分散式的天然架構，FreeWheel 可以通過監控措施很快地對其進行恢復。

高可用實踐之切換部署

因為通過對有狀態數據（諸如 Kafka、HBase、Zookeeper）實現多可用區，從底層向上的各個業務可形成自我恢復的能力，即使在發生故障時，也已能在極端的情況下為用戶無縫提供完整服務。

當跨可用區級別切換時，FreeWheel 更多貫徹的是 DevOps 理念，即不用專職的運維人員，通過監控和腳本自動化的工具和方式保證服務高可用。目前在 FreeWheel 內部受重視的一種模式是監控和報警的代碼化，即通過相應的框架實現監控和報警，用代碼做管理，而非以往那種在站點上做簡單配置的方式。

對於監控和報警，FreeWheel 用到的主要工具包括 Datadog 及開源工具如 TerraForm（類似於 AWS CloudFormation）和 SaltStack 等。

Datadog 的工作方式是在每一台需要監控的伺服器上運行它的 Agent。FreeWheel 主要用 Datadog 實現 EC2 級別監控，這樣可以基於機器類型、用途等，分門別類對其服務進行監控，一是實現系統級別（如 CPU、內存、磁碟、網路 I/O）的相關監控，二是實現基於 應用級別的監控。

另外，TerraForm 會應對啟動資源、擴展 / 回收和許可權配置之類的場景，從而實現 AWS 資源配置。SaltStack 實現配置的冪等性管理，並針對機器 tag 進行分散式調用和部署檢查。

當可用區級別需切換時，目標是希望能做到讓用戶無感知。但目前如果需從主區域切換至備用區域情況下，FreeWheel 當前的設計方案是允許有一定（分鐘級別）的宕機時間。因為在一般情況下，一個區域 3 個或 3 個以上的可用區（FreeWheel 只會使用有至少 3 個可用區的區域）已經足夠保證高可用性。當整個區域出現整體性故障時，允許有一定的宕機時間是綜合成本和需求的整體考慮。

高可用實踐收效及未來規劃

張磊在採訪中提到，伴隨著高可用實踐，FreeWheel 也獲得了業務的高彈性。對於「超級碗」及世界盃這類大型體育賽事開始時，整個架構會有更好的擴展能力應對突發流量，幫助其在 AWS 上實現高度的動態擴展性。

未來，FreeWheel 一方面會嘗試將一部分系統走向容器化，比如 Data Ingestion Pipeline。當然，對於 HBase、Hadoop 如何更好地結合 K8S 或利用 Amazon EKS 等工具，FreeWheel 還需要下一階段的調研及實驗。

另一方面，針對更大範圍的高可用、數據安全等問題，FreeWheel 還將持續探索怎樣在平衡性能和成本的條件下多個區域提供服務和快速的災難修復的能力。

受訪嘉賓

張磊，FreeWheel 架構師，現負責公司數據平台和數據產品的整體技術把控。

姜冰，FreeWheel 首席工程師，現全面負責大數據平台的架構和研發工作。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！