調低EBS 的磁碟大小

前言

最近收到AWS的個人帳單以後, 突然發現我帳單上的金額與我的想像有些落差, 也因為這樣子, 開始來對一下是哪些項目在吃錢…

大概對了一下, 發現主要的花費在EC2 instance 與 EBS 兩個項目上面, EC2 instance 這邊的花費就是題外話了, 但EBS這邊就慢讓我意外的… 細看了以後才發現當初不知道為什麼把使用的EBS 成 使用30GB, 但我實際上的使用也才6GB左右…
(雖然這也不是什麼大錢, 但每個月給它這樣扣也是覺得還不如把錢省下來去訂閱其他有用服務….)

第一次實驗

原本想說把root volume EBS 調低應該不是件難事, 結果沒想到AWS預設上是不支援這件是的, 它可以往上調高, 但不支援調低…

在網路上找了不少相關的教學文, 主要的作法都是, 大概都是…

  • 先建立一個較小的EBS volume
  • 再把這個新的 EBS volume 掛到我們的EC2上面以後, 做好格式化以及 rsync 的資料拷貝
  • 最後設定好 /boot 以後, 就可以把新的EBS volume來取代原有的 EBS root volume.
    (題外話, 要把EBS volume 設定為 EC2 上面的 /dev/sda1 才會成為那台EC2上的root volume)

第一次實驗結果

經由上述步驟的教學文實際嘗試以後, 都會卡再做出來的EBS volume是無法當成是原本這一台EC2的root volume, 它會直接讓那台EC2開不起來. (機器顯示 running, 但是ssh 連不到…)

上述的測試其實我參考了不少文章, 但最後卡的點都是一樣的, 做出來的 EBS volume是不能用的… (我這邊使用的EC2 t4g family, 不太確定跟ARM 版本的 grub-install 有關??? 也許今天使用的是x86的機器就可以? 之後有機會再來試試)

另一種Workaround的方式

因為上面測試也花了不少時間, 所以最後就自己做了一些流程上的調整如下:

  • 建立一台新的EC2, 並設定root volume為我想要的大小 (6GB), 並且OS的版本也是用與就機器一樣的 ubuntu 20.04
  • 接著, 將舊機器的EBS 掛到新的EC2機器上.
  • 透過 rsync 將舊的EC2 資料都複製到新的EC2上. (基本上除了 /boot, /tmp, /mnt, /dev以外, 都要sync 到新的EC2的對應資料夾)
  • 如果先前有設定route53, elastic IP 等等相關的設定, 最後都指定到這台新的EC2機器上.

最後靠這個方式成功把 EBS size降下來了, 不過靠這個方式比較像是duplicate出一台新的EC2, 而不是clone出一模一樣的機器…

Reference:

EBS 定價

最近主管告知了上個月的AWS帳單,EC2的帳單暴漲到了$2000!
主管提到了,這是他預期內的金額,不過提醒我要記得關閉最近測試開的那些機器與資源。當然,這金額對我來說是個非常意外的數字,之前的測試都是測試完以後我就馬上關掉機器了,每次測試時間最長也不超過3小時!

後來主管一路追查下去,原來我之前開了一堆io2的EBS,在測試完了以後也沒有刪除,而這些EBS應該就是造成帳單暴漲的原因!!!

這次的失誤,讓我知道以後要記得去看一下EBS是否有忘了刪掉的disk;不過也趁這機會好好研究一下EBS的計價方式:

EBS Volume Charges

AWS的這篇文章中提到的例子,可以看出只要EBS被provision以後,其provision的容量(GB)與IOPS都會被納入計價:

舉個例子,如果我在一台EC2上掛了一個100GB, 10000 IOPS的io2 EBS,則即使我只使用EBS上其中1GB做資料儲存,我一個月需要在EBS上付的金額為:

10000 IOPS * 0.065 USD + 100GB * 0.125 USD = 662.5 $USD

真的認真算下來,才知道io2的EBS計價那麼貴,這次真的是花錢好好的上了一課0rz

Reference

測試Cassandra

最近公司的某個專案可能會用到Cassandra,所以在真的用之前還是先來做個簡易的Benchmark,來看看它是否真的能符合我們的需求(主要是write heavey的情境)。

測試#1

測試情境

  • cluster nodes: AWS EC2 i3.large * 3
  • benchmark node: AWS EC2 c5.2xlarge.

測試 Query如下:

INSERT INTO status (id1 id2, id3, succeed) VALUES ($id1, $id2, $id3, false)

測試程式會不停的隨機產生上述Query,並寫進Cassandra cluster中,並觀察throughput如何:

測試結果

結果蠻不如預期的,目前在concurrent connection = 500的情況下,也只達到9xx左右的qps

Next

目前初步檢視了目前的cluster 設定,發現先前的測試EC2 node主要還是使用EBS gp2,其IOPS感覺只能到100 IOPS左右,再參考了這篇AWS的文章後,感覺可以照著這樣的設定再來測試一次看看。

測試#2

測試情境

沿續上次的測試,但重新設定Cluster 使用EC2 i3.large * 3,但這次則是mount了 NVME SSD (local instance store) 到Cassandra data folder ,並使用了一樣的測試程式與Query。

測試結果

一樣不如預期,qps 也還是只能打到9xx 左右,不過這次有觀察到Cassandra node的cpu 在測試期間都滿載。

Next

從上次的測試來看,cpu cores 必須要加大了,感覺目前是卡在cpu這邊。

測試#3

測試情境

沿續上次的測試,但重新設定Cluster 使用EC2 c5.4xlarge * 3,但這次則是mount了 NVME SSD(EBS io2) 到Cassandra data folder ,並使用了一樣的測試程式與Query。

CREATE INDEX succeed ON status (succeed);

測試結果

若沒有index 的情況下,insert qps 目前可以到 11xxx 左右;若加了index,則insert qps 目前可以到8xxx左右。

測試#4

測試情境

沿續上次的測試,但重新設定Cluster 使用EC2 c5.4xlarge * 8,但這次則是mount了 NVME SSD(EBS io2, iops=5000) 到Cassandra data folder ,並使用了一樣的測試程式與Query與測試#3中的index。

測試結果

加了index,則insert qps 目前可以到14xxx左右,這次觀察到cluster cpu 大概只有跑到50%左右,看來benchmark client 必須要升級了。

測試#5

測試情境

沿續上次的測試,這次升級了Benchmark client 使用c5a.8xlarge,測試cluster的部分則是使用前面測試所留下來的EC2 c5a.4xlarge * 8.

測試結果

這次觀察到即使在使用concurrent connection = 2000的情況下,cluster cpu 大概只有跑到70%左右,而整體的qps約在16xxx;

從這邊來看感覺又是卡在IOPS=5000的部分,目前每個cluster node 可以設定的EBS 為io2, IOPS=5000,IOPS設太高的話會在一開始無法同時開8個EC2 c5a.4xlarge

測試#6

測試情境

沿續上次的測試,這次試著再加了3 台 c5a.4xlarge到Cassandra cluster中,即是最後的cluster node 數量為

c5a.4xlarge * 10

測試結果

這次觀察在同一台機器,並且開啟2個benchmark 程式並使用concurrent connection = 2000的情況下,cluster cpu 大概只有跑到70%左右,而整體的qps約在20xxx;