全球6大DC，日均10億日誌場景下的高可用實踐
開篇語
近幾年網際網路服務安全事故的頻發，使得越來越多的企業及開發者意識到資料備份、災備等重要性，高可用性、高容災性及高可擴充套件性的系統和架構建設工作也被更多地置於重心。
在這個過程中，基於公有云提供的基礎設施實現高可用已成為多數技術團隊的選擇。
而面對跨區域+高可用需求時，許多開發者卻犯了難，一方面業務場景的不同對架構設計提出了不盡相同的需求，基本上沒有可完全複製的架構模版；另一方面是納入考慮的因素在不斷增多，資料延遲、成本開銷、物理隔離、快速的恢復能力……如何能在加法的基礎上做好減法，對技術團隊創新能力提出了更高要求。
對此，InfoQ專訪了FreeWheel架構師張磊及FreeWheel 首席工程師姜冰，對話在服務部署於全球6個資料中心，日均產生近10億廣告投放展示日誌的場景下，如何做好跨區域高可用實踐。
跨區域、高可用性實踐背景
資料處理平臺提出的多維挑戰
作為美國Comcast旗下領先的視訊廣告管理和投放平臺，FreeWheel的資料伺服器來自於全球的6大資料中心（美國東西海岸各兩大DC、歐洲兩大DC），每天產生近10億的廣告投放展示日誌，累計產生超3TB的資料，並且有至少18個月的資料需要持久化。
隨著資料應用對實時性和可靠性要求的逐漸遞增， FreeWheel根據其自身資料特點和應用需求，也在內部採用了一套以Kafka，Hadoop和HBase為核心的Lambda處理架構。
其中，各個資料中心的廣告伺服器實時地將廣告資料傳輸到本地Kafka叢集，中心化的Kafka MirrorMaker接著會將多資料中心的資料聚集到一個全域性的Kafka叢集。流式處理框架會從全域性Kafka叢集消費資料，處理之後一方面寫回Kafka（為下游實時應用服務），一方面寫入HBase，並由Hadoop離線作業將HBase的內容聚合轉換成Parquet檔案寫入HDFS。OLAP服務會同時查詢HBase和HDFS，對外提供資料的實時或批量查詢（整體架構見下圖）。
FreeWheel資料處理系統架構圖
FreeWheel首先在6大DC部署了這一套資料處理系統，也很好地實現了設計目標。但隨著資料量的不斷增長和業務變化的需求，這種模式面臨瞭如下挑戰：
- 可擴充套件性：越來越多的資料產品接入到新的資料平臺，對OLAP服務的擴充套件性提出了嚴苛的要求。而在自建的資料中心，受限於規劃和整體容量，很難方便靈活地擴充套件。 同時，傳統DC在“超級碗”等大型賽事直播帶來流量瞬時波動的場景下，也很難滿足對容量的彈性需求。
- 高可用性：雖然像Hadoop這樣的大資料的基礎設施本身可以保證一定程度的高可用性，但在遇到資料中心整體性故障時，依然會造成服務的中斷。
- 開發和測試效率：大資料平臺開發和測試中，經常需要啟停一整套端到端服務或者元件。但在自有資料中心裡，受限於資源限制，很難做到及時滿足需求。因而也降低了開發測試的效率。
理論上，上述挑戰中的部分問題可通過在另一個數據中心部署一套資料處理系統解決或緩解，但考慮到規劃、擴容所需時長以及問題根治性等因素，FreeWheel決定直接投入AWS懷抱。
在選擇雲服務商上，FreeWheel的考量因素主要包括成熟程度、資料監管、可用區（AZ）數以及原生服務的數量等。基於這些考量和相應的測試，其首選了AWS。
基於AWS原生服務的使用權衡
首先，FreeWheel在AWS上也部署了一套Kafka MirrorMaker，同步所有資料中心的資料。然後，再將資料處理平臺基本原樣搬到了AWS上。
但如何權衡是直接使用AWS原生服務，還是自己維護Kafka、HBase等基礎設施？ FreeWheel也有一些思考。
張磊對此總結了兩點。一是需要從平臺需求出發 ，例如AWS許多原生服務某種程度的確能帶來開發和維護成本的降低，但對於基礎資料平臺這類業務，直接用其原生服務可能會帶來不確定性的增加，乃至反而帶來成本的擴增。二是需要考慮開發者自身的技術熟練程度 ，當大家需要花大量時間投入新系統內部運作原理的學習時，不一定能降低相對應的時間和運維成本。
涉及到具體權衡與改造，姜冰也舉例講解了何時該選擇自身維護：
以AWS原生服務Amazon EMR和Amazon Kinesis為例，對映到FreeWheel的資料處理系統中相應的是Hadoop Cluster和Kafka。基於FreeWheel以7*24小時流計算為主的業務型別，如果直接使用EMR及Kinesis，將面臨如下問題：
- 原生服務開放程度較弱，因而開發者缺乏更多的機會維護和管理自身叢集。例如從對外相容性上看，Kafka下游接了多樣的開源解決方案，與Spark、Flink有天然整合，但Kinesis是閉源的託管服務，下游整合由AWS主導，日誌記錄的更新和變化將受制於AWS內部研發。
- EMR適合批處理的工作模式，在全天候不間斷的執行狀態下，重構Hadoop Cluster更能應對流處理場景；
在上述場景下，FreeWheel並沒有主動選擇EMR或Kinesis原生服務，而是從成本、效能、開放程度、規模化和容錯管理等維度與自身維護做了對比實踐。但張磊也提到，在可接受的範圍內，對於AWS的原生服務能用的FreeWheel會盡量使用， 這樣才能更有效地滿足高可用需求，降低一定投入。
截至目前，經過測試和調整，FreeWheel已逐步把面向客戶的的所有產品都遷移到AWS環境中，目前自有資料中心裡只有極少數對內的服務在執行。而最終它也會把所有的服務都遷移到AWS環境中。
高可用實踐需求及實現方案解析
高可用性設計目標
一個完整的全系統高可用性設計通常會涉及五大層面：基礎設施、伺服器、應用程式、系統服務、區域。
在基礎設施層，FreeWheel更多的是將AWS視為一項服務， AWS在保證其基礎設施穩定性的同時，設計原則即是在假定問題出現情境下的指導設計。伺服器層也是如此。
資料層，如果該資料存在於FreeWheel自身系統，其通常會藉助於例如Kafka、HBase等天然的Replicate能力——設定多個Replicate提供資料容災。
應用程式層，FreeWheel一般會將它做到無狀態（Stateless），從而更容易實現恢復和實現高可用，無論是水平擴充套件還是垂直擴充套件都更方便。
服務層，FreeWheel採用的是Fail Over（故障轉移）機制。即任務伺服器設定多臺，彼此之間通過心跳聯絡，（資料庫、快取、任務伺服器等）任何位置出現瓶頸就只需增加伺服器。目前，對於伺服器的對等可替換性，主要有三種類型：Active-Active（雙主機）、Active-Standby（主備）以及單Active。
- 在Active-Active模式下，FreeWheel通常會通過先繫結Amazon ELB，再註冊到Amazon Route 53的方式，從而實現自動對APP無感知訪問。
- 對於Active-Standby模式，FreeWheel通常會將相應的資訊註冊到ZooKeeper，由ZooKeeper實現Fail Over的分散式協調服務，從而實現Master的選舉和對外服務發現。
- 對於單Active，一般是其內部ETL依賴於某種服務，FreeWheel會將其綁在AID或ELB中。
高可用的整體實現方案
無論是跨Region還是跨AZ，資料交換都將產生一定的成本開銷。面對著龐大資料量和跨Region（AZ）間的資料延遲，在AWS多可用區實踐過程中，FreeWheel針對資料平臺開源系統對於高可用的需求及AWS自身高可用實踐經驗，採用了多種定製方式——主要對Hadoop-HBase、Kafka、Zookeeper及流式處理Pipeline實現了不同的高可用解決方案。
1. Hadoop-HBase多可用區
在設計之初，FreeWheel就已平衡了成本、效能甚至可用性之間的關係。但其後續發現，AWS上很多及其型別和儲存型別都不盡相同，所以為提升HBase效能就採用了Instance Store這類本地儲存。而相應的弊端也隨之產生：一旦Instance出現異常，多臺EC2例項就會出現終止，尤其是當其在同一AZ裡維護時，即可能導致資料的直接丟失。
因此，FreeWheel也需要對HBase在多個AZ上實現高可用。
對於儲存模組，FreeWheel選擇兩個可用區來部署，通過HDFS Storage Policy介面，實現資料塊副本數在主可用區和次可用區的分佈。 對於無狀態的資料應用優先部署在與Hadoop/HBase主可用區同側，並支援在次可用區快速部署。應用和資料優先同側的策略，可以有效降低資料應用的因為跨可用區帶來的資料延遲，並降低可用區之間網路傳輸的成本開銷。藉助AWS提供不同儲存介質的IOPS和持久化特點，實現針對不同業務的工作負載靈活選擇儲存節點配置，並實現業務之間的物理隔離（原理如下圖）。
其中，隔離思路主要是基於不同的工作負載選用不用的EC2例項或EBS例項。這樣也可根據自身的業務特點，在AWS中選擇不同的硬體、例項型別或EBS型別來滿足需求。此外，FreeWheel也可以在AWS Hadoop上實現一組機器的上線及下線，而且只把相應keyboard上、下線，而不影響到其他資料。
2. Kafka多可用區
Kafka Topic內每個Partition有多個副本，多可用區部署，需保證在不同可用區的副本個數的劃分。姜冰提到，在正常情況下每個Partition裡可設定多個Replica，如果要保證高可用，意味著需要將多個Replica同時被部署到同一AZ上，但同時，這樣做的弊端是無法保證AZ級別高可用，如果一個AZ宕機將導致整個Partition不可用。
於是，考慮到跨可用區帶來的資料延遲以及成本開銷，FreeWheel針對資料應用和規模實現了不同的策略。
一種策略是，對於用於ETL流程的Kafka Topic，在次可用區僅部署Partition副本中的Follower。應用程式和Kafka主可用區同側，讀寫資料的流量全部在同一可用區完成，這樣在主從可用之間，僅有Leader和Follower之間的網路傳輸開銷。在主可用區發生故障時，從可用區的Follower切換成Leader對外提供服務（原理如下圖）。
在這種情況下，Kafka Consumer只會在同一可用區消費，從而避免跨AZ間因網路傳輸帶來的成本消耗，同一AZ間的延遲性也大大降低。
而對於以線上服務為主的資料，為了提供更快速的恢復能力，Kafka採用3可用區對等部署的方案，且無差別的對外提供服務：每一個Partition的Leader和Follower以公平的策略隨機分配到不同的可用區，在AWS出現可用區級別的故障時，Kafka藉助Leader和Follower之間的切換，保證服務的高可用（原理如下圖）。
放在FreeWheel的具體業務場景中，為保證廣告主預算與廣告競價間反饋迴路的可用性高且延時性低，避免出現廣告超量投放或投放價格與預算偏差等問題，FreeWheel即需採用上述第二類這種解決方案。
3. Zookeeper多可用區部署方案
Zookeeper Cluster是由1個leader和n-1個follower組成，這n個節點被部署到3個AWS可用區。應用通過名字註冊服務將主工作服務（Active）註冊到Zookeeper。在可用區發生故障時，應用Active／Standby角色根據Zookeeper名字服務狀態變化進行切換，並註冊最新的Active的服務到Route53（原理如下圖）。
4. Pipeline高可用部署方案
目前FreeWheel DIP（Data Ingestion Pipeline）架構由兩部分組成，一是流處理工作型別，二是上下游以小時為級別的批處理工作型別。
流處理消費一次來源於Kafka，同時會和HBase互動，所以就DIP來說，如果能解決資料和狀態高可用，其本身是屬於一條無狀態的資料處理Pipeline。反觀，這也是為什麼FreeWheel會花更多功夫在Kafa、Hadoop-Hbase和Zookeeper高可用部署上的原因，從而進一步確保DIP資料處理狀態和高可用。
FreeWheel DIP主要通過Hadoop YARN部署，採用AutoScaling Group做Scale Out/In以及採用AutoScaling Group繫結同一YARN佇列的方式來保證Pipeline的高可用性。
對於批處理工作型別的解決方案，FreeWheel也有比較好的Fail Over方案應對Crash或異常狀況下的自我修復。總的來說，利用Pipeline分散式的天然架構，FreeWheel可以通過監控措施很快地對其進行恢復。
感知故障層實踐經驗
當AZ級別需切換時，一般的終極目標是希望能做到讓使用者無感知。但目前如果需從主區域切換至備用區域情況下，FreeWheel當前的設計方案是讓使用者有感知，也就是針對這種場景允許有一定的宕機時間。
因為通過對有狀態資料（諸如Kafka、HBase、Zookeeper）實現多AZ，從底層向上的各個業務可形成自我恢復的能力，即使在發生故障時，也已能在極端的情況下為使用者無縫提供完整服務。
當跨AZ級別切換時，FreeWheel更多貫徹的是DevOps理念，即不用專職的運維人員，通過監控和指令碼自動化的工具和方式保證服務高可用。目前在FreeWheel內部受重視的一種模式是Moniter Alerts實現的Code化，即通過相應的框架實現Moniter Alerts，用Code做管理，而非以往那種在站點上做簡單配置的方式。
對於Moniter Alerts，FreeWheel用到的主要工具包括Datadog及開源工具如TerraForm和Salts等。
Datadog的工作方式是在每一臺需要監控的伺服器上執行它的Agent。FreeWheel主要用Datadog實現EC2級別監控，這樣可以基於機器型別、用途等，分門別類對其服務進行監控，一是實現系統級別（如CPU、Memory、Desk、網路I/O）的相關監控，二是實現基於 APB級別的監控。
另外，TerraForm（類似於AWS CloudFormation）會應對Launch資源、Scale Out/In和許可權配置之類的場景，從而實現AWS資源Config配置。Salts主要是針對分散式執行和跨機器的Poster Check。
高可用實踐收效及未來規劃
張磊在採訪中提到，伴隨著高可用實踐，FreeWheel也獲得了業務的高彈性。對於“超級碗”及世界盃這類大型體育賽事開始時，整個架構會有更好的Scale Out能力應對突發流量，幫助其在AWS上實現高度的動態擴充套件性。
未來，FreeWheel一方面會嘗試將這套系統走向容器化。當然，對於HBase、Hadoop如何更好地結合K8S或利用Amazon EKS等工具，FreeWheel還需要下一階段的調研及實驗。
另一方面，針對更大範圍的高可用、資料安全等問題，FreeWheel還將探索Pipeline或資料處理系統怎樣在多個Mutiple Region進行Launch，同時提供服務乃至提供快速的Disater Recovery（災難修復）的能力。
採訪嘉賓
張磊 FreeWheel架構師，現負責公司資料平臺和資料產品的整體技術把控。
姜冰，FreeWheel 首席工程師，現全面負責大資料平臺的架構和研發工作。