雲應用程式的容量測試

專案越大越應該進行容量測試。 2008年，英國西斯羅機場開放了新修建的航站樓，即5號航站樓。 該航站樓專案耗資43億英鎊，但是沒有比這個專案更龐大的專案了。 但是5號航站樓開放首日的效果並不理想,包括人為因素和技術因素在內的多種狀況導致了當天34架航班被取消，這成了接下來幾日英國媒體競相炒作的熱門話題。 容量不足的行李處理系統、痛苦等待的旅客等各種問題都是媒體關注的焦點。

雲計算龐大的資源能否説明我們在面對向西斯羅機場5號航站樓這樣的大專案上實現更精確的容量需求模型設計呢？ 造成34架航班取消以及數千旅客痛苦憤怒的原因很多，但這對西斯羅機場的整體影響並不大，這也算是它的成功之處吧。 而企業能否在雲計算中要求擁有更好的容量管理工具呢？

我希望在應用程式真正公開運行前就能知道程式所需的容量。 就好像在飛機飛行前都要進行測試，避免飛上天空突然翅膀折斷一樣。 因此我要在容量測試中搞清楚以下三個問題：

此類工具除了可以測試系統容量，還可以測試其它任務，比如壓力測試、性能監控，以及容量管理等。 有些公司利用開源工具如multi-mechanize, Selenium以及JMeter 開發了適合自己的容量測試控管，其它公司則直接從雲測試控管供應商，如Soasta, Loadstorm以及Cloudsleuth處購買相應的產品。 而我當初曾使用過很多命令列工具，如lshw, top, tcpdump, df和ab。

任何雲應用都是建立在多個技術層之上的。

雲供應商所能控制的層級，即硬體、網路和超級監管程式等，是對使用者隱藏以及使用者無法測量的。 一條鎖鏈的強度，取決於鎖鏈中最薄弱的那個環節，而在雲架構中，這個鏈條很長環節很多，比如光纖、PDU、路由器、交換器、負載平衡、代理伺服器等等。

AWS 主控台可以説明我們監控CPU使用率，磁片讀寫情況，網路流量情況等，而且這些功能都是免費的。 雖然對於更高級的監控，這款免費工具無法提供，但是對於新手來說，這個工具已經夠用了。 對於更複雜的監控需求，AWS提供了Cloudwatch服務可以實現。

技術堆疊的虛擬機器層包括了磁片、CPU和記憶體。 而通過作業系統，這些設備都可以被監控，並且監控資料可以被系統監控工具獲取並進行分析處理。 而頂層，即應用層也是一樣的。

我相信雲服務供應商肯定會提供足夠的冗余容量。 不過這方面的具體資料我無法提供，因為沒有哪個供應商會將自己的系統架構資料細節拿出來與大家分享。 但是我相信未來兩年，這些資料將會逐步透明，因為未來將會有越來越多的雲服務供應商出現，企業向雲平臺遷移的速度也會達到高峰，服務水準將成為關鍵因素。 未來雲服務的價格將出現下滑，虛擬機器與物理主機的比例將進一步提升。

對於虛擬機器的測量方法，可能不如雲供應商的物理主機測試的那麼精准，因為虛擬機器背後還有各種監管機制。 這些監管程式會根據需求隨時調整各個虛擬機器的資源配置情況。 這就好像是空管中心面對大量的飛機和數量有限的跑到所作的工作一樣。

如果我的應用程式經常閒置，而另一個話務中心服務相當繁忙，那麼CPU資源和網路頻寬資源，肯定不會分配給我。 如果我的存儲需求極低，而某個使用者需要存儲幾十個G的資料，那麼物理磁碟空間肯定也是分配給那個使用者的更多。 而由於系統時鐘是在虛擬的時間中工作，並不是即時的，因此由於監管程式導致的延遲、錯誤讀取或其它小問題都會影響到我上述的對於雲服務的測量方案。