如何以1.68美元/小時的成本獲取百萬TPS

Amazon EC2等云基礎設施已經在世界范圍內證明了它的價值，其易于擴展、即開即用、按時計費等特性更徹底地解放了開發人員的創造性；然而請不要忽略，虛擬化環境曾一度被認為是應用程序及數據庫的性能殺手。

盡管性能方面，云供應商一直在尋找著改善途徑，但作為用戶的我們，自己的性能優化手段也必不可少。在實體服務器上，Aerospike曾展示過百萬TPS的峰值，而現在，我們則將致力于提升云應用的性能，徹底打破云不等于高性能這個流言。

我們做過各種各樣的云實例對比，這里將展示的是基于C3.8xlarge，如何以每小時1.68美元的成本獲得每秒百萬事務數據庫的性能。

以下博文為譯文：

越高越好

這個報告記錄了大量Amazon EC2實例上的實驗，下面則是見證奇跡的時刻，如何調整參數和指令以得到如此等級的價格性能比。

除非另有說明，實驗將忠實執行以下設置：

• 單Aerospike內存NoSQL數據庫服務器運行在一個獨立的Amazon實例上。
• 1000萬個對象，每個對象大小在100字節（10 bins或者columns，每個大小10字節），我們盡可能的調整。讓對象體積保持足夠小，這樣就可以將所有的研究對象放到內存中。
• 使用具備Java基準工具的 Aerospike Java客戶端，客戶端進程使用非服務器實例模式。最大化客戶端負載，并將之并行連接到Aerospike服務器上，具體使用數量取決于所運行的服務器實例類型。
• 為了最大化Amazon基礎設施上的負載，在內存中使用了分布在整個key space上的100%讀負載。
• 我們使用 spot-Instances來節省成本，在性能測試期間Spot和按需實例的性能基本相同。

步驟1：選擇實例類型

在選擇實例時基本按照以下準則：可以內存支撐整個數據庫；可以支撐事務速率的網絡和CPU。

我們不考慮i2和hs1實例，因為盡管他們雖然具備高存儲能力，但是卻會限制應用程序的內存使用。

我們調研了大量的EC2實例類型：

R――內存密集

C――計算密集

M――R和C的平衡

T――1個入門級的主機

不同類型的實例擁有不同的網絡能力，因此我們調研了每個類型，并測試他們的最高帶寬限制，使用發包工具從盡可能多客戶端推送更大體積的包。經過調研后，結果如下：

Moderate（上限是100MBps）

High（范圍在300Mbps到1.8Gbps之間）

10 Gigabit（峰值在8.8 Gbps左右）

我們沒有考慮t1和m1.small，因為Amazon給它網絡性能標注為“Low”，這個主要鑒于在“Low”或者“Moderate”標注的實例上，網絡性能往往會成為實例瓶頸。此外，測試時M系列實例還不具備增大網絡的選項。

步驟2：選擇虛擬機

Amazon使用的是Xen，一個支持半虛擬化（PV）和全虛擬化的開源虛擬化平臺，同時Amazon還有硬件虛擬化選項。我們同時使用了兩個類型：

• Para Virtualized Machine。首先，我們選擇了c3.8xlarge。雖然它的成本很高，但是我們覺得仍然大有可為。開始時，我們在EC2-Classic網絡中使用了一個PV AMI；但是隨后我們發現，這些被標注10Gbps上限的機器只能獲得1.8 to 2.2 Gbps的能力，主機的速率被限制到每秒8.5萬包左右。而在測試了C3.2xlarge之后，我們發現這個主機仍然存在速度限制。再看CPU使用率，我們發現在半虛擬化主機中，嚴重負載下虛擬層的CPU使用率將達到恐怖的40%。使用這些主機，在Aerospike上我們可以獲得8.5萬TPS，速度限制再次出現。
• Hardware Virtualized Machine。在AWS的說明中，基于網絡加強實例的HVM會提供更高的網絡性能，用戶每秒將獲得更高的packets。而在根據我們的測試顯示，在沒有其他增項時，TPS足足增加了3倍。同等端配置中，使用具備網絡增強的c3.4xlarge，Aerospike可以獲得21.5萬的TPS。

鑒于同等價格的性能差異，對比PV實例，我們以后的測試將只是用HVM類型。

步驟3：Use Placement Groups

Placement Groups是同一個Availability Zone中實例組成的邏輯組，在Amazon Virtual Private Cloud（VPC）中使用Use Placement Group允許應用程序低延時共享資源，完全平分10 Gbps網絡。

我們使用Placement Groups來最大化性能，同時VPC是HVM實例的首要使用前提。

步驟4：Test Tenancy

我們分別測試了專用租用（dedicated tenancy）和共享租用（shared tenancy），在沒有發現明顯的差別后，我們果斷的選擇了共享租用。

步驟5：最小化CPU Stealing

在AWS上運行應用程序最大的隱患就是計算資源不可預知性，當CPU被過度使用時，比如一個線程突然間占用了太多的CPU，EC2則會結束這個線程的時間片。同時，在下一個時間片，Amazon只會給它分配較少的資源。這會導致應用程序吞吐量的跌宕起伏，這一點可以通過控制應用線程CPU。這樣一來，我們就可以保證應用程序擁有更穩定的吞吐率。

在我們的測試中，Aerospike完全可以避免CPU過用。這將給我們帶來可預知的性能，即使重度負載時，應用程序也很少受到CPU竊取監視影響（從0.2到0.7）。

步驟6：網絡

在實例類型、VN、Placement Groups、租用和調諧選定后，我們仍然不能確定TPS受限方面。著眼實例，我們發現系統因為單核上的interrupt（中斷）處理仍然存在瓶頸。每個NIC看起來只提供一個interrupt隊列，默認綁定到一個單核心。因此，我們需要一個更靈活的解決方案，我們嘗試了四種方法：

1. IRQ Distribution：我們嘗試強迫系統將irq分布到多個核心上（disable irqbalance + echo ffff > *smp_affinity），而隨后就發現它被綁定到一個獨立的核心上。因此，一個獨立的irq不能在多個核心上進行分配。

2. Interrupt Coalescing：在EC2上，Interrupt Coalescing對CPU利用率有些許提升，但是沒有轉化為更好的處理。

3. More NICs：在測試了這兩個途徑后，Elastic Network Interfaces（ENI）無疑是下一個必經之路。ENI讓用戶可以給實例增加多個（虛擬）NIC。單一的NIC峰值在25萬TPS左右，增加多個接口可以增加程序的響應性，在兩個實例上配置4接口和4客戶端，我們可以在單c3.8xlarge實例上獲得96萬的TPS。通過確保每個客戶端都推送到專用接口，從而可以利用所有的NIC和CPU。同時，使用具備私有IP的ENI并不會增加花費。

4. Receive Packet Steering：另一個簡單的途徑是使用RPS（“echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus”）將irp分配給多核心。這將避免使用多 NICs/ENIs，同時還避免了管理上的復雜度，并帶來多ENI差不多的TPS。配置RPS的單NIC可以將TPS推到80萬，通過跨4個核心的interrupt。

在測試過不同組合的NICs和RPS后， 通過一些Aerospike調優（比如適當的調整服務線程配置），我們可以達到非常高的性能――5個客戶端（C3.2xlarge）加一個運行在C3.8xlarge上的單節點Aerospike集群可以達到百萬的TPS，而花費僅僅是1.68美元每小時。

** DI = 按需實例

** RI = 預留實例

** All則是單實例給定類型的成本分析，3年和1年預留實例term計算都使用了重度負載（100%利用率）

NB：這些實例有時候體現著性能的好壞，這些數字都是一個月以上運行得出的結果。

* Core Bottleneck：我們嘗試多種不同的NIC和RPS組合，但通常情況下會存在一個大量的%hi，同時會有個1核心被阻塞，峰值期間CPU利用率只有50%。

總結

以上解決方案體現了Amazon EC2已經可作為高性能數據庫的一個選擇，在AWS上使用Aerospike你可以花費1.68美元每小時的價格獲得百萬TPS。

• 使用AWS Marketplace在VPC中來設置一個基于c3.8xlarge實例Aerospike HVM，并將之作為一個服務器。使用一個AWS Marketplace。
• 為服務器實例搭載4個額外的ENI，沒必要部署更多的Elastic IP。
• 運行afterburner.sh（cd /opt/aerospike/bin; sudo ./afterburner.sh）來最優每個Aerospike上的線程數量
• 使用AWS Marketplace來設置5個Aerospike c3.2xlarge實例，將這些使用了相同HVM和VPC的實例作為客戶端，同時它們被布置在相同的Placement Group中作為服務器。
• 保證security group擁有3000-3003 TCP Port用于節點間的通信，同時為了使用AMC，TCP Port 8081需要對互聯網開放。
• 給內存命名空間分配54GB的RAM（c3.8xlarge擁有60GB）
• 開啟Aerospike服務器
• 通過Java基準客戶端來加載數據

cd <java client>/benchmarks<br>./run_benchmarks-z 40 -n test -w I &nbsp;-o S:10 -b 10 -l 23 -k 10000000 -latency 5,1 -h YOUR_AWS_INTERNAL_IP

• 使用100%的讀負載來運行服務器，為每個客戶端指配獨立ENI上的私有IP。

cd <javaclient>/benchmarks<br>./run_benchmarks -z 40 -n test -w RU,100 &nbsp;-o S:10 -b 10 -l 23 -k 10000000 -latency 5,1 -h YOUR_AWS_INTERNAL_IP

• 通過5個客戶端，你可以獲得百萬TPS。

但是這僅僅是第一步，在下一篇文章中，我們將繼續評估 4個Amazon實例價格性能比。到時候，我們將在內存中使用1個4節點Aerospike集群，同時將加載5個不同的讀寫負載。

原文鏈接：http://highscalability.com/blog/2014/8/18/1-aerospike-server-x-1-amazon-ec2-instance-1-million-tps-for.html

如您需要了解AWS最新資訊或是技術文檔可訪問AWS中文技術社區；如您有更多的疑問請在AWS技術論壇提出，稍后會有專家進行答疑。 

訂閱“AWS中文技術社區”微信公眾號，實時掌握AWS技術及產品消息！

AWS中文技術社區為廣大開發者提供了一個Amazon Web Service技術交流平臺，推送AWS最新資訊、技術視頻、技術文檔、精彩技術博文等相關精彩內容，更有AWS社區專家與您直接溝通交流！快加入AWS中文技術社區，更快更好的了解AWS云計算技術。

                                                                                                            （ 譯者/薛童陽 責編/王玉平） 

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈