2012 中華電信iPhone 5預購網站 為何還是塞爆？

中華電信iPhone 5預購網站一開放，許多訂購的民眾就開始大罵，因為網站瞬間塞爆，
根本無法預訂。到底iPhone 5預購帶來多大的挑戰呢？



從iPhone 5預購網站Google Analytics分析資料來看，12月5日當天，超過百萬人造訪
中華電信的iPhone 5預購網站，不重複訪客達到1,133,863人，當天累計的網頁瀏覽數
（Page View）超過千萬次。中華電信表示，這次預購網站的流量是往年的3倍以上。


2012年12月5日，iPhone 5在臺灣的預購日，許多人心�不禁猜測著，iPhone 5還有那
麼熱門嗎？這回預購網站會不會又秒殺塞爆？

早上8點還不到，中華電信的iPhone 5預購網站還沒開放申購，其實就已經開始出現瀏
覽網頁的人潮了。10點預購時間一到，網站一開放，彷彿歷史重演一般，許多人開始大
罵上不了站。難道這就是iPhone手機預購的傳統嗎？

iPhone魔咒？每逢預購必塞爆
許多想要購買手機的民眾開始在臉書、論壇或BBS上抱怨，大型論壇中抱怨申購網站塞
爆的討論，動輒引起數百甚至上千篇回應，痛罵無法登入預購網站，只能看到系統繁忙
的網頁；但是，也不乏有人預購成功，教大家開啟多個瀏覽器同時申請，就會增加成功
率。這到底是怎麼一回事？

根據中華電信提出的網站流量數據，9點時的網頁瀏覽人數已經超過10萬人，10點網站
開放預購作業後，40萬人次湧上網站訂購，流量瞬間塞爆網站。但中華電信表示，這次
預購網站雖然塞爆，但透過事先規畫的流量控制機制，網站仍然是正常運作，並沒有像
過去一樣當機。直到當天中午1、2點，預購網站的瀏覽人數才開始舒解，只剩下數萬人
次的連線。

其實不只預購期間，光是前一天中華電信在網站公告預購訊息，就已經出現連線反應遲
緩的塞爆現象。在預購日傍晚，開放查詢預購資訊時，也再度發生壅塞情況。

超過往年3倍的預購人潮

根據中華電信行動通信分公司提供的iPhone 5預購網站Google Analytics分析資料，12
月5日當天，iPhone 5預購網站就湧進了將近120萬人次，不重複訪客達到1,133,863
人，當天累計的網頁瀏覽量（Page View）超過千萬次，達到11,628,756次，遠遠超過
往年的規模。中華電信表示，iPhone 5預購的流量是往年的3倍以上，在10點開放網站
後的第一秒鐘，就有40萬人次。

蘋果的iPhone手機每次在臺上市都大受歡迎，預購網站年年塞爆。2010年8月底的
iPhone 4預購，同樣10點一開站就大塞車，半小時內申請人數達到8萬人，遠超過了原
本設計只能處理2萬人次的規模，導致半小時內完成訂購的人數只有一半，約1萬多筆。


2011年12月開賣的iPhone 4S，預購網站重演塞爆劇碼，持續了4、5個小時後才開始紓
解，不少民眾在論壇上抱怨，雖然成功進入預約網站，但填完資料後卻無法送出，導致
預約失敗。

到了2012年12月的iPhone 5預購，網站照樣塞爆，好像這是iPhone預購揮之不去的魔
咒。負責手機業務的中華電信行動通信分公司總經理林國豐表示，雖然這次iPhone預購
系統已經重新翻修架構，也擴充了數倍的容量，但是因為預購網站的瞬間流量太大，是
前一年iPhone 4S預購時的數倍，超過了中華電信預期的規模，所以立即採取一些管制
措施。

林國豐表示：「類似高速公路的閘道管制，在交流道閘道口限制能進入高速公路的車
輛，讓高速公路上的車輛可以暢行無阻。民眾以為高速公路動彈不得，其實是他們塞在
閘道口無法進入。同樣地，認為訂購網站塞爆的民眾，是因為他們被阻擋在訂購網站入
口外，不是網站作業當機。」他表示，這次iPhone 5預購網站沒有當機，開放預購十幾
分鐘後，網站訂購作業就開始順暢，第1個小時能完成預約的人數超過了10萬人。

不過，和iPhone 5預購網站Google Analytics分析資料上的數據比較，預購網站開放當
天10點時最大流量達到40萬人次，若只有10萬人成功進入網站完成預約，那麼也有數十
萬人次是被阻擋在外，從這些民眾的角度來看，就是服務無法使用，有此抱怨也是人之
常情。

雲端不能解決網站塞爆問題嗎？
網站塞爆是個老問題，熱門演唱會售票、過年或連假的火車訂票等，都經常發生網站塞
爆而無法作業的情況，iPhone預購更是年年塞爆。而最常聽到業者的回應，就是流量超
過預期，系統無法負荷這些老掉牙的理由。

過去的IT技術或許真的難以承載不可預期的網路爆衝流量，但是近幾年來，雲端運算技
術興起，許多跨國大型網站，如Google、Facebook、微軟、Amazon等，紛紛標榜透過雲
端運算承載超大型網路服務的彈性調度能力，才能夠提供服務給全球上億的網民。

但是，在臺灣卻屢屢發生網路塞爆的窘況，難道打著能按需求動態調整，快速擴充的雲
端運算，也無法解決這類預購網站塞爆的難題？

而這次iPhone 5預購塞爆的中華電信，或許其預購網站流量較同業高，但中華電信也是
標榜臺灣雲端運算的領頭羊，去年11月還推出了hicloud公有雲服務CaaS（Compute as
a Service），可以提供虛擬私雲（Virtual Private Cloud），由企業按實際需求動態
調整租用虛擬機器的規格，來滿足動態擴充的需求。難道雲端服務也無法滿足iPhone預
購網站流量爆增的問題？是雲端運算失靈了？還是iPhone 5預購網站沒有使用雲端運算
技術？

中華電信重新設計iPhone 5預購網站

中華電信iPhone 5預購網站建置團隊坦言，這次iPhone 5預購網站沒有使用雲端運算技
術，仍然採用傳統的實體伺服器來因應。

經過幾次塞爆經驗，中華電信早在前一年底就開始規畫iPhone 5預購網站的新架構，並
設計了新的預購作業流程。中華電信評估，iPhone 5預購網站的流量最多成長3倍，因
此以擴充3倍容量為目標來設計新網站。同時，中華電信在2012年中因轉播奧運而採購
了一批伺服器，他們評估這些伺服器可以承載預購網站需要的3倍容量需求，所以，最
後決定用這批實體伺服器來架設預購網站，而沒有採用自家的雲端服務。

中華電信表示：「雖然預估了3倍的需求，但實際的預購流量還是出乎意料之外，比原
先設計的容量還大。」

去年12月4日，中華電信在公布iPhone 5預購消息後，當天預購網站的點閱率就達到了
30萬人次，隔天開始預購時，單日瀏覽人數達到160萬人次，是去年iPhone 4S預購50萬
人次的3倍多，扣除重複使用者還有115萬人次，而10點鐘開賣的瞬間更達到40萬人次。


中華電信是以去年的3倍容量，也就是仍承載150萬人次為目標，但中華電信表示，即使
如此也無法在瞬間滿足40萬人次的需求，若要能即時處理40萬人次的交易，需要很高的
成本，所以，中華電信採取了作業分流的方式來疏導申辦流量。

就像是銀行窗口分流申辦的作法，遇到排隊的隊伍過長的時候，就加開窗口分散人潮，
來減少每一個用戶等待的時間。執行預購網站的伺服器就像是銀行窗口，中華電信預先
調派了數臺伺服器來負責執行預購網站的程式，遇到流量大增時，就增加分流的伺服
器。

但是，中華電信表示，若要讓40萬人都能在第一時間成功申辦，可能需要上百臺伺服
器，從成本來看不可能在這種短期的需求上這樣做，所以，中華電信是以用戶可以承受
的時間，來解決成本高的問題。

這個預購網站採用常見的三層式架構，包括了執行前端訂購網頁的網頁伺服器，執行預
購作業的AP應用伺服器，以及後端的資料庫，每一次申辦作業等於要經過3個運算節點
負責。

中華電信先預估可能的運算需求，來指派擔任不同功能節點的實體伺服器數量，並且另
外預留了一些實體伺服器，可以動態加載。因為這些實體伺服器事先都已經完成彼此實
體線路的介接，也透過負載平衡設備建立叢集。等到開始訂購的時候，就可以按實際情
況，動態調整負載平衡設備上的參數，來增加不同功能節點的實體伺服器數量。

訂購流程及網頁內容重新設計，分散伺服器負擔

為了減少預購作業的瓶頸，中華電信也調整了訂購作業的流程和網站內容的建置方式，
來分散前端網頁層和AP層的負擔。例如預購網站上所使用的靜態網頁內容──產品圖擋
或說明網頁等，以中華電信自家的CDN（內容傳遞）服務來分流，將這些靜態網頁改儲
存在各地機房，而不是儲存在預購網站上，減少對預購網站伺服器的負擔。

在訂購流程上，預購網站的首頁直接列出各種不同規格的手機，手機項目對應的連結會
將用戶導到不同的網站伺服器上，例如16GB黑色手機和32GB白色手機就是由不同的AP伺
服器執行，而AP伺服器還會透過負載平衡分散給多臺實體伺服器來執行。

透過這樣的架構，如果臨時發現要購買某一種規格的用戶量大增，比如說選16GB白色
iPhone的民眾爆增，就可以動態調用備用伺服器來分攤該產品的訂購作業，或者也可以
減少預購量較低的規格線，比如64GB購買民眾較少，就可以調用閒置的伺服器。

另外在AP應用程式的作業上，也增加了限時完成的設計。訂購的民眾必須在3分鐘內填
完申請資料，超過時間系統就會自動中斷作業，結束連線，以免連線被長時占用，而民
眾就會被重導到預購網站的首頁，重新選擇機型。中華電信解釋，因為伺服器可以承載
的同時連線數有上限，就像是有些餐廳會限制用餐時間1小時，是為了在下一個小時能
夠挪出空位來承接其他用餐顧客，以避免用戶長時間停留。

而且當網站伺服器或AP伺服器滿載時，前端網站會將部分民眾導向另一個網站上的服務
滿載通知網頁，建議用戶延緩上線。如此也是把流量分散到其他的網站。

因為在中華電信過去的預購經驗中，民眾看到服務滿載的網頁通知時，會長時間停留在
這個網頁上，不斷重新載入，若這個網站也是由預購網站的伺服器一起提供，則會造成
預購網站的流量大增，所以，中華電信這次改將服務中斷的通知放置在其他網站上，藉
由把流量引導至別的網站，來降低主要預購網站的負擔。

用戶行為影響流量變化，但行為難以預測
用戶的使用行為會影響AP層流量的變化，因為使用者填寫表單的行為難以預測，例如有
的人填寫表單需要停留很長的時間，有的人則很快就能完成，也有民眾會反覆登入或不
斷更新網頁，甚至用自動化程式填表。這些行為都會影響AP執行需要的時間和從AP到資
料庫間的流量變化，也就對AP伺服器和資料庫伺服器產生不同的負載影響。在中華電信
這次iPhone 5預購網站的架構中，後端資料庫雖然沒有分散到多臺伺服器上執行，但採
用Oracle資料庫搭配高階實體伺服器來執行。

另外，規畫實體伺服器用量時，中華電信並不是以一臺伺服器最大可承載量來估算，而
是會扣除彈性處理容量再來估算，例如一臺實體伺服器上限可以處理800個連線數，中
華電信會先以600個連線數來估算，若這個訂購流程需要承載3,000個連線數，就先規畫
5臺實體伺服器來執行。在這個訂購流程中，5臺實體伺服器總共可以有1,000個連線數
的動態容量，當爆增的連線數小於這個數值之前，也可以選擇不用增加實體伺服器來解
決，以增加動態調整時可選擇的策略。

不過，一臺AP伺服器即使同時上線的使用者人數相同，或連線數相同，也會因為使用者
的行為不同，而產生不同程度的負載。如果使用者行為複雜的用戶，其需求都集中在同
一臺伺服器處理，那麼該臺伺服器能處理的訂購量就越少。

而且這些使用者的行為年年不同，過去的資料也難以供隔年參考，所以，即使事先已藉
由壓力測試或情境模擬來預演，但中華電信仍是派駐專人現場監看，隨時調整策略。

備妥應變劇本，現場監控調整策略

為此，中華電信也設置了一個臨時監控中心，內有數十臺螢幕，每一臺前端網站、AP伺
服器和資料庫伺服器都有專責人員負責監控，每個人擁有多個監控螢幕，應該監控的參
數或數據都有專門的視窗來呈現，方便監控人員瀏覽。這些監控參數包括了同時上線的
使用者人數、同時上線的連線數、處理器使用率等等。

在預購網站開跑之前，中華電信預先設計了十來種情境，模擬預購網站可能的流量變
化，並設計了十幾套因應方式，以及對應該調整的參數值。預購開始後，監控中心的專
人是第一線人員，一旦他發現所監控的數據有異常變化，就會回報給第二線的IT總指
揮。IT總指揮的身旁已經準備好網站架構圖和因應方案的資料，一旦總指揮收到第一線
人員回報的異常資料，會在線上召集相關的人員，討論要採取哪一個方案，套用哪一組
參數，或者再進行哪些細部微調，決定好了就立即套用參數來調整網站流量動向。

動態調整時，需同時考量網站、AP應用程式和資料庫的承載量。若是AP開放過高的流
量，後端資料庫無法處理，就可能會造成系統出錯當機。所以，必須考量資料庫負載
量，搭配AP執行情況和網站進來的流量，相互配合調整。

因為這次iPhone 5預購流量超出了中華電信預估的3倍容量，在這樣的資源下，採取上
述這些動態調整來優化網站效能，仍然無法完全解決網站塞爆的情況。再加上預購網站
除了提供預購下單之外，當天下午6點時，還開放了資料查詢，讓民眾確認訂單，因為
資料查詢和受理填單都由同一支應用程式提供，而且查詢動作也會影響到資料庫的效
能，查詢功能開放後反而造成第二波網站壅塞變慢的情況。

另外，中華電信為了舒緩查詢流量的壓力，將原本這是要在隔天離峰時間才用簡訊發送
的預約單號，提前在預購當天晚上就先發送給顧客，但因為簡訊通的功能仍舊是由同一
支應用程式提供服務，這也增加了AP伺服器的負擔。

在這次iPhone 5預購網站塞爆事件中，中華電信最初對於網站容量的預估，決定了後續
的網站架構和因應作法。因為實際預購流量還是超出了中華電信的預期，導致因應措施
仍舊不足以完全解決塞爆問題。

從中華電信這次因應經驗中，也點出了這類臨時性網站爆量的議題，透過流程作業分流
搭配實體動態調整的方式，仍舊是無法解決瞬間流量的需求。若中華電信改用雲端服
務，就能徹底解決預購網站瞬間爆量的需求嗎？這個問題的答案，可以從中華電信數據
通信分公司實際用雲端平臺設計臺鐵元旦訂票的經驗中得知一二。