High Availability and High Performance Server Side

By Triton Ho@Mar's Potato

High Availability and High Performance Server Side


關於 Triton Ho

● Mars' Potato公司建立者之一●擁有面對各式各樣的火星爛系統的救火經驗●喜歡資料庫●喜歡貓●出沒於 Hong Kong Linux User Group


重點

● 24*7系統不等於真的連一分鐘 down time都不會有●你會不會問一個人：「請問你死了嗎？」●因為你不知道一個組件是太忙而未能即時回答你。你必須等待一段時間才知道它是真的掛掉了。

●如果這是關鍵組件（像 master database），這段短時間還是會引起 down time

●再貴的電腦都有掛的一天，絕對別相信組件不會掛，而是要準備掛掉後的災難控制。（ Defense-in-depth）

●紙和筆永遠是最可信的朋友。全面電子化的香港海關依然可以用傳真方式的報關。（沒事別亂用）


繼續重點

● Think Big, Be Small，你應該為你的架構保留未來性。但是別在開始階段便建立能支持一百萬人的系統

● 當你的系統有一百萬人在線，你肯定有足夠金錢來租到強大的伺服器（以及找高手來幫忙）

● 正確的 RESTful設計，和正確的資料庫結構（ database schema）最最影響系統效能

● 工程師時薪遠比 CPU貴！在系統初期階段， scale-up（改用更貴伺服器）一般比scale-out（使用能把工作分散到多台伺服器）更具成本效益

● 正確架設的 Postgresql，配合正確的 API和系統架構，能支持同時在線５萬人中型系統，別輕易使用各式各樣的 NoSQL● Facebook初期也是使用 MySQL, Instagram初期使用

PostgreSQL


Basic Architecture

Client ApplicationServer Database


Scale-out on Application Server

Client

StatefulApplication

Server

Database

StatefulApplication

Server

StatefulApplication

Server

StatefulApplication

Server

HAproxy

HAProxy Load Balancing:Source IP / URL Parameter

StatefulApplication

Server


問題在那裡？

●因為 Application Server（之後簡稱 AS）是有狀態（因為用上了 Java的 HttpSession，或是 PHP的Session）●如果一個客戶端的連線在 AS1建立了 Session，那這客戶端之後的通訊必需只能由 AS1負責。因為其他Server沒有這客戶端的 Session Data

●分流器（ Load balancer）必須記錄每一個客戶端對應的 AS，大幅吃掉吃掉分流器的 CPU和 RAM（價值百萬的分流器便是用在這種地方）

●要是 AS1掛掉，在那裡的 Session會全部掛掉


引起更多問題的解決方案

● 方案一：讓 AS之間建立溝通渠道，並且建立後備 AS。讓所有 Session都拷貝到後備 AS上● 新問題一：這台後備 AS將會存放全部的 Session，這台

AS的 CPU和 RAM很快會成為系統瓶頸● 方案二：建立多於一台後備 AS，例如： (AS1, 3, 5)拷貝到後備 AS-standby1 ， (AS2, 4, 6)拷貝後備 AS-standby2● 新問題二：你的 Load Balancer的 failover rule設定將會非常好玩


Scale-out on Application Server

Client

StatelessApplication

Server

Database

StatefulApplication

Server


Server


Server

HAProxy

HAProxy Load Balancing:Round Robin


Server

Redis DB


Stateless AS好處

●因為 AS是 Stateless，任何一台 AS掛掉都無傷大雅●在 RESTful世界中，掛掉的 AS手上的工作，客戶端會自動重做

●分流器可以隨便把工作派到任何一台 AS，而無需知道之前的通訊歷史。分流器可以用便宜很多的電腦

●系統可根據使用量動態加／減ＡＳ數量


為什麼 Redis

●根據 RESTful要求， AS必須 Stateless的，所以必須找一個地方存放 Session

● Session都是短生命期，而且生命期內經常改動的數據，不同 Session之間沒任何關聯性，不適合放在主資料庫

●否則，不管主資料庫是 Postgresql，MySQL還是Oracle，主資料庫管理者都肯定把你五馬分屍

● Redis把資料都放在 RAM，一定比放在 SSD/HDD的主資料庫更快

● Redis比memcached支援更多功能，除了存放短期數據，還可以用作：●簡單版的 Message Queue Server●簡單版的 Explicit Locking Server


HA on database

Client


Server

Database(Master)


Server


Server

HAProxy

HAProxy Load Balancing:Round Robin


Server

Redis DB(Master)

Redis DB(Slave)

pgpool

pgpool

pgpool

pgpool

Database(replica)

Database(replica)


資料庫 HA重點

●同一機箱內的 HDD / SSD是好兄弟，不求同年同月同日生，但會同年同月同日死● RAID 1只保護到單一硬碟故障，對於小動物闖入機箱／電源故障／在機房打翻泡麵的工程師引起的全硬碟掛掉， RAID 1無能為力

●不過還是需要 RAID 1●強烈不建議 RAID 0和 RAID 5

●所以，主資料庫需要有後備資料庫來支援，以及定期的DVD／磁帶備份


pgpool重點

●一個 AS與資料庫之間的中間件（ middleware）●讓軟件層不用知道底層資料庫的狀態下，自動把READ-ONLY交易給後後備資料庫來處理，把READ+WRITE交易給主資料庫來處理

●建議與 AS放到同一台伺服器內。不管那台伺服器上的 AS還是 pgpool掛掉，一律當作二者都掛掉而不工作派到這台伺服器


同步與非同步備份

●同步備份＝在資料庫處理 commit時，必須先等待資料也送到後備資料庫，才向客戶端回答「成功了」●好處一：所有 committed transaction一定不會流失●好處二：不會 incoherent data problem（詳見接下來的

0.5秒悲劇）●壞處：很慢，特別是主資料庫和後備資料庫不是放在同一地方時


0.5秒的悲劇

●主角絕對不是我！●某豬哥工程師在系統中向女生說：「我愛你，你也愛我嗎？」，在等待回應時，豬哥還定下了每秒自動重新載入

●女生回答「我也愛你耶！」，豬哥也看到了●然後豬哥再重新載入網頁時，「我也愛你耶！」的狀態不見了！

●豬哥以為女生刪掉訊息玩弄他的感情，把電腦砸掉也把把女生聯絡刪掉

●其實只要再次重新載入，那段訊息便會重新出現


0.5秒的悲劇原因

●因為系統在使用非同步備份，同時讓後備資料庫處理 READ-ONLY的要求

●女生回答「我也愛你耶！」時，最新資料只存在於主資料庫，還未傳送到後備資料庫

●豬哥看到「我也愛你耶！」，資料是來自主資料庫

●之後 0.5秒豬哥看不到訊息，資料來自後備資料庫


如何避免 0.5秒的悲劇

●告白請當面進行。（你收過發錯目標的好人卡嗎？）●方案一：高關注度數據只使用主資料庫來讀取，不使用後備資料庫

●方案二：使用同步備份（不建議）●方案三：使用 HTTP的 conditional GET●方案四：把短期性，高關注度數據不放在主資料庫，放到 Redis


HA on load balancer

Client


Server

Database(Master)


Server


Server

HAProxy1

DNS Load Balancing:Round RobinHAProxy Load Balancing:Round Robin


Server

Redis DB(Master)

Redis DB(Slave)

pgpool

pgpool

pgpool

pgpool

Database(replica)

Database(replica)

HAProxy2

HAProxy1


分流器 HA

●避免 single point of failure●分流器的網絡效能有上限● OS中能同時開啟的 TCP/IP通道有上限●所以，使用 round-robin DNS，讓一個網絡域名背後有多於一個 IP


Sharding on Short Term DB

Client


Server

Database(Master)


Server


Server

HAProxy1

DNS Load Balancing:Round RobinHAProxy Load Balancing:Round Robin


Server

Redis DB1(Master)

Redis DB1(Slave)

pgpool

pgpool

pgpool

pgpool

Database(replica)

Database(replica)

HAProxy2

HAProxy1

Coherent Short Term DB

Redis DB2(Master)

Redis DB3(Master)

Redis DB2(Slave)

Redis DB3(Slave)


Sharding on Short Term DB

● Sharding只應天上有，人間能得幾回聞●工程師的時間成本比 CPU的貴上太多（雖然主管從來不這麼想）

●未用上 64GB / 128GB RAM的伺服器前， Sharding不合成本效益

●要是你公司的伺服器最多只能使用 8GB RAM ，請認真思考要轉換跑道

●動態增減 Shard是超級痛苦● Consistent hash會有大幅幫助，但是還是很痛


Add Reporting Module

Client


Server

Database(Master)


Server


Server


Server

Redis DB1(Master)

Redis DB1(Slave)

pgpool

pgpool

pgpool

pgpool

Database(replica)

Database(replica)

Production database

HAProxy1


Redis DB2(Master)

Redis DB3(Master)

Redis DB2(Slave)

Redis DB3(Slave)

HAProxy2

ETL engine

ReportingDB

Internal Reporting

Server


Asynchronous API and Server Push

Client


ServerDatabase(Master)


Server


Server


Server

Redis DB1(Master)

Redis DB1(Slave)

pgpool

pgpool

pgpool

pgpool

Database(replica)

Database(replica)

Production database

HAProxy1


Redis DB2(Master)

Redis DB3(Master)

Redis DB2(Slave)

Redis DB3(Slave)

HAProxy2

MQ server1

Asynchronous Job Server Farm

Job Server

Job Server

Job Server

Job ServerLong

PollingServer

LongPollingServer

RabbitMQ Cluster

MQ server2

MQ server3


非同步 API例子

●你在玩暗黑破壞神時，老媽叫你做家務●你忙於跟 Azmodan戰鬥，回答「指令收到了」●五一小時後，你終於有空做家務，在你做完家務後，你回答「做完了」

●看吧，連三歲小孩都懂得應用 Asynchronous API和 Server Push（謎之聲：喂！）


非同步 API重點

● 一些需要大量時間的 API request，你可以在收到工作後立即回答「收到了」給客戶端，然後再慢慢處理。這樣，客戶端便不會在等待期間誤會連線斷掉。

● 非同步工作可以丟到後端 job server，讓 AS保留更多 CPU處理即時性 Request

● 傳統 HTTP是 Request-Reply的，伺服器沒法主動告知客戶端工作進度● 別在客戶端每三秒問一下：「工作做完了嗎？」，這是浪費

CPU和網絡數據的行為（雖然現實中的主管會這麼做）

● 所以你需要 Long-Polling機制


Long-Polling重點

●不建議用 AS來處理●因為會持續吃掉一個 TCP/IP通道●因為會吃掉一個 AS worker thread（註： tomcat原始設定是 200）

●遇上 cracker發出大量 Long-polling攻擊，會讓所有 AS的 worker thread全被吃掉

●所以，使用像 node.JS這樣的 Server來專門處理 Long-Polling


High Availability and High Performance Server Side演講結束

Technology

High Availability and High Performance Server Side