最新消息
Oct 7, 2020

五個原因,告訴你為什麼線上活動負載失敗?

1. 使用 One Time Password(OTP)、以email方式做OTP


一次性密碼(One Time Password,OTP)是網路服務常見的一種雙重身份驗證,又稱雙因素身份驗證 (2FA,Two-Factor Authentication),相信大家都熟悉類似的畫面:
截圖 2020-10-07 上午11.14.11.png


這種方式是現在主流採用的安全措施,由於單一密碼強度太低,因此添加第二層保護來確保帳戶安全性更堅固。然而,水能載舟亦能覆舟,當你今天要使用在超大流量的網路活動時,2FA 就是一把雙面刃,大流量的風險可能使它反咬你一口!


A. 2018、2019年時,各國瘋搶購 iPhone XR、iPhone 11,當時 Apple推出iReserve系統,讓消費者需要獲得SMS OTP認證碼,才可以進入系統搶購。19年9月11日,Apple官方發表會後,隔日不到早上8:00, 中國京東平台顯示,iPhone11預約人數達到304421人,iPhone11 Pro達到494992人。記得當時很多人都抱怨因為收不到SMS而搶iPhone失敗相當氣惱,顯然 SMS系統的throughput是有限的,幾十萬封SMS根本無法同時送出。


B. 2020年7月,台灣為了振興藝文產業所發行的 「藝fun券」,超過200萬人抽中資格,當天許多中獎者登入APP領獎時,卻發現系統大出包,網友紛紛上PTT抱怨等了將近三小時。


截圖 2020-10-07 上午11.26.19.png




其實,原因是官方使用簡訊發送驗證碼,超出負荷量釀成伺服器壅塞,導致根本是連收都收不到,不然就是輸入驗證後頻頻顯示「驗證失敗」,被迫緊急增加硬體設備。




截圖 2020-10-07 上午11.31.09.png


C. 以上都是採用簡訊方式,那麼用Email-OTP 會不會比較好呢?答案是不會,有興趣的人可以看看2019年底 香港除夕大抽獎,就是採用 Email-OTP 一樣延遲了很久,畢竟Email-OTP 是比SMS-OTP還更難控制的。


總之SMS OTP 在大流量使用上有一定的上限,超載的流量尖峰都可比擬為「人肉版的DDoS」!

2.忽略監控的重要性

應用程式效能監控(Application Performance Management,APM)是支援線上任務的重要因素。當活動運行,透過具體數據與圖表,協助保持系統穩定執行、IT部門在客戶支援功能上的時間和金錢也變得可控。


A.「監控」的重要性在於,讓你在發生災難前排除問題,以及確切知道「問題來自什麼?」,有個明確方向找出原因,就能預防及優化處理,記住:「找出發生問題的原因」與「解決問題本身」一樣重要。


應用程式效能監控(APM),可以幫助監控生態系統中發生的事件,讓你及時做出對應的反應,其功能可能包含:


追踪運行緩慢的區域
知道花了多少時間在數據庫的要求上
視覺化數據庫
數據庫調用響應時間和吞吐量


B. 提供10個APM服務方案,以供參考:


1. SolarWinds
2. WhatsUp Gold
3. Loggly
4. Elastic Observability
5. nSpectrum
6. Splunk
7. Dynatrace
8. Datadog
9. AppDynamics
10. Synthtic Monitoring


3.第三方服務拖累了你


第三方 HTTP 請求 (Third-Party HTTP Requests)是為了獲取額外的資源而連接到其它的伺服器下載,如果有網路延遲或是對方伺服器忙碌都會影響網頁效能。


什麼是第三方服務? 舉電商為例,他是部署在電商網站上的基於雲端的技術,目的是為線上消費者提供更好的購物者體驗。 第三方供應商的服務器和用戶的瀏覽器之間傳輸數據和內容:用戶評論、廣告、推薦等等,都是由第三方JavaScript交付內容的常見例子。
但是,根據 YOTTAA 分析報告〈2018 eCOMMERCE 3RD PARTY TECHNOLOGY INDEX〉,網站延遲的原因中竟有 75% 由第三方服務造成,也就是說這些為了幫助你提供更完善的工具,同時也是造成用戶體驗倒退的原因之一。


4.你使用一般的數據庫


我們在〈RedSo的新產品-NoQ〉這篇文章中有提過,大流量系統難在於數據庫。為了防止錯誤,數據庫在寫入的時候必須確保同一時間只有一個寫入,同時由於數據量大,亦有資訊保安的問題。然而就算前端可以同時顯示資料給一百萬人閱覽,在下訂單要寫入數據庫時,依然會遇到其他瓶頸。將數據庫做Sharding分片化是其中一個方法,但遇上幾萬人同時搶購同一產品,單一產品的庫存更新還是非常不易的。


Fred Hebert 《Learn You Some Erlang for Great Good!》書中將網站與流量做了有趣的比擬:看看下圖,我們的系統就是這個水槽,而網站流量是流進的水。


截圖 2020-10-07 下午3.31.20.png


當進水量大於排水量,數據輸入越來越快,出口就無法即時處理所有數據,通常這時候我們會想到增加一個緩沖存儲臨時數據,但隊伍持續的超載到達上限還是會導致系統崩潰。開發人員此時會開始一連串步驟,從一一檢視到擴大系統,可是最根本的問題可能是存在於「出水口」,例如數據庫,外部服務API,磁盤速度,帶寬或常規I / O限制,頁面調度速度(分頁速度),CPU限制等。開發人員應該做的是阻止再輸入,即反壓(back-pressure)或者暫時丟棄數據,即卸載(load-shedding)。


5.擴展系統很容易?你可能需要想一想


延續上段所講,通常在決定擴展系統之前,會做相當耗時的檢查,例如查看堆疊追蹤(堆棧軌跡)、排隊隊伍、數據庫慢速查詢、以及調用的API等,因為擴展是需要付出代價的,也是最後不得已的選擇。這個動作並不表示網站所有部分可以安穩的一起擴展, Hartley Brody 認為,一些複雜的背後機制其實會令保持性能有所困難:


添加新功能需要更長的時間
代碼可能更難測試
查詢和修復錯誤更令人沮喪
使本地環境和生產環境相匹配更加困難


所以除非真的不得已,盡量選擇其他更簡單又快速的方式處理問題是最好的,沒有人喜歡自找麻煩。


綜合以上五個原因,你可以怎麼做?


1.與虛擬排隊系統對接,如 RoomQ,暫時卸載過多流量到虛擬等候室中安置,並且隨時依據目標網站容量變化,將可負荷人流引導回去;


2.直接租用超大容量系統,最好是連超過一百萬流量都能掛保證穩固順暢的 NoQ Flash