幹壞事是進步最大的原動力
昨天把手上所有的 Amazon EBS 從 gp2 換到 gp3 了：「Amazon EBS 的 gp3 可以用在開機磁碟了」，今天早上來看一下狀態，整體看起來是還 OK，不過有些地方值得注意的，像是標題寫到的 latency。
我抓了跑 GitLab 的機器來看，可以很明顯看到讀寫的 latency 都變高了：
但 AWS 又有提到這些數字資料有經過轉換，看起來是 gp2 與 gp3 的數字意義本來就不一樣，所以他必須想辦法轉換，所以也有可能是因為這個轉換導致的？
This graph has had transformations applied to it and will differ from what is natively found in CloudWatch. Due to this some functionality is reduced.
不過其他的數字倒是沒什麼變化，系統的負荷量其實也還好，就先丟著跑...
可以先參考「Amazon EBS 推出了 gp3」這篇，但剛出來的時候大家都有發現無論是透過 web console 還是透過 awscli，boot disk 都沒辦法改成 gp3，可是在官方的文件上又說可以用 gp3，所以就有人在 AWS 的 forum 上發問了：「EBS GP3 Boot Volume Issues」。
直到剛剛發現已經可以改成 gp3 了... 一個一個手動改當然也是 OK，但對於有一卡車 EBS 要換的人來說鐵定得弄指令來換，這邊搭配了 jq 一起改：
aws ec2 describe-volumes | jq '.Volumes[] | select(.VolumeType == "gp2") | .VolumeId' | xargs -n1 -P4 env aws ec2 modify-volume --volume-type gp3 --volume-id
這邊是把 gp2 都改成 gp3，沒有考慮到空間大小的問題 (因為超過 1TB 時 gp2 給的 IOPS 會比較多)，另外 -P4 是平行四個 process 跑，改起來會快一些...
今年的 AWS re:Invent 又開始了，不過因為疫情的關係，這次是線上為主... 這邊先來整理一下 Amazon EBS 相關的更新。
首先是推出了新的 gp3 類型，也是 SSD 類：「New – Amazon EBS gp3 Volume Lets You Provision Performance Apart From Capacity」。
每 GB 單位成本比 gp2 低 20%：
Today I would like to tell you about gp3, a new type of SSD EBS volume that lets you provision performance independent of storage capacity, and offers a 20% lower price than existing gp2 volume types.
然後直接給你 3000 IOPS 與 125MB/sec，有需要更高的話可以「加購」：
gp3 is designed to provide predictable 3,000 IOPS baseline performance and 125 MiB/s regardless of volume size. It is ideal for applications that require high performance at a low cost such as MySQL, Cassandra, virtual desktops and Hadoop analytics. Customers looking for higher performance can scale up to 16,000 IOPS and 1,000 MiB/s for an additional fee. The top performance of gp3 is 4 times faster than max throughput of gp2 volumes.
但照「Amazon EBS volume types」這邊的列表可以看到，要注意 gp2 可以 burst 的 throughput (250MB/sec) 比 gp3 的 baseline (125MB/sec) 高。
也因為這樣，可以把一些 random access 比較多的 /data 這類的 EBS 換過去，但如果是要大量 sequential access 的也許就不適合了。
IOPS 的部份，1TB 以下的 gp2 換過去應該是沒什麼太大問題，因為在 gp2 的時候是 1GB 給 3IOPS，所以 1TB 以下的 gp2 都低於 3000IOPS。
轉移的部份可以在 AWS 的 console 上直接 migrate 到 gp3：
If you’re currently using gp2, you can easily migrate your EBS volumes to gp3 using Amazon EBS Elastic Volumes, an existing feature of Amazon EBS. Elastic Volumes allows you to modify the volume type, IOPS, and throughput of your existing EBS volumes without interrupting your Amazon EC2 instances.
像是這樣：
但照「Amazon EBS volume types」這邊的列表，gp3 可以是開機硬碟
Update：剛剛發現文件被修正了，看起來不能當開機硬碟...
不知道哪邊搞錯了，過幾天看看吧 XDDD
剛剛看到 Amazon EBS 的 Cold HDD (sc1) 大幅降價 40%：「AWS announces 40% price reduction for Amazon Elastic Block Store (EBS) Cold HDD (sc1) volumes」。
Cold HDD (sc1) 主要是拿來堆資料的，直接掛上來操作比起 Amazon S3 還是方便不少，這次的降價算是懶人的福音？
現在的「Amazon EBS pricing」頁面已經更新了，想要比較的話可以從 archive.is 上面的「Amazon EBS pricing」對比。價錢的部份從十一月九號自動生效：
Amazon EBS customers automatically benefit from this new lower price, which is effective starting November 9th, 2020.
Amazon EBS 保障 IO 效能的版本 Provisioned IOPS io1 進化了，推出了 Provisioned IOPS io2：「New EBS Volume Type (io2) – 100x Higher Durability and 10x More IOPS/GiB」。
目前先看了一下美國與新加坡的價錢，應該都還是一樣，看起來這次主要是功能性上的進步，有兩個比較顯著的改變。
第一個是每 GB 可以租用的 IOPS 數量上升了，io1 是 50 IOPS，在 io2 給到 500 IOPS；不過最大值不變，都還是 64k IOPS。這個看起來對於追求 IOPS 的人彈性增加不少，不過算了一下成本差距應該是還好，以最大的 64k IOPS 來算，光 IOPS 的費用就要 USD$4160/month，而最低的空間租量上，io1 租 1280 GB (USD$160/month) 與 io2 租 128 GB (USD$16/month) 在這個部分只能算零頭了...
第二個是持久性 (durability)，從 io1 的 99.9% 到 io2 變成 99.999% 了，這邊應該主要是受益於這十年 SSD 技術的進步。我猜本來的 io1 其實也拉高不少，只是 SLA 合約上沒有增加而已...
應該還是會守在 gp2 上，便宜大碗，不過效能的保證少了些，對於一般性的應用來說應該是夠用。
EBS 的 io1 推出了可以同時掛到 16 台 EC2 instance 的選項：「New – Multi-Attach for Provisioned IOPS (io1) Amazon EBS Volumes」。
先看支援的區域，傳統主力區域 (us-east-1 與 eu-west-1) 都支援了，而亞洲區這邊反倒是南韓先支援了：
Multi-Attach for Provisioned IOPS (io1) volumes on Amazon Elastic Block Store (EBS) is available today at no extra charge to customers in the US East (N. Virginia & Ohio), US West (Oregon), EU (Ireland), and Asia Pacific (Seoul) regions.
其中常用的目的是 HA：
Multi-Attach capability makes it easier to achieve higher availability for applications that provide write ordering to maintain storage consistency.
Heartbeat 類的應用應該可以用上這個東西，不過本來就可以透過 command line API 做到 detach & attach，用這個只是少了一個動作...
第二個想到的是，在實體機房的環境下，有些 filesystem (在「Shared-disk file systems」裡面可以翻到一些) 可以同時掛同一個 block storage (通常是透過 SAN)，現在在 AWS 上面也可以這樣搞了。
不過 io1 記得不便宜啊...
Amazon Elasticsearch Service 的新功能，使用 Amazon S3 當作第二級儲存空間 (UltraWarm)：「Announcing UltraWarm (Preview) for Amazon Elasticsearch Service」。
UltraWarm 需要不同的機器 (跑不同版本？)，機器的規格 (vCPU 與記憶體的比率) 接近 Memory Optimized 的版本，但是貴了不少，所以需要夠大的資料量才會打平回來...
拿 us-east-1 來看，SSD EBS 的空間成本就是 USD$0.135/GB，而傳統磁性硬碟是 USD$0.067/GB (不知道收不收 I/O 費用？)，但 storage 的價錢是 USD$0.024/GB。這邊值得一提的是 Amazon S3 是 USD$0.023/GB，看起來是直接包括了 API 的呼叫費用？
在「A web performance issue」這邊講到 Mozilla 的系統產生效能問題，後續的 trouble shooting 以及解決問題的方案。
這個系統跑在 AWS 上，在一連串確認後發現是 RDS 所使用的 EBS 的 IOPS 滿了：
After reading a lot of documentation about Amazon’s RDS set-up I determined that slow downs in the database were related to IOPS spikes. Amazon gives you 3 IOPS per Gb and with a storage of 1 Terabyte we had 3,000 IOPS as our baseline. The graph below shows that at times we would get above that max baseline.
然後大家對於解法都差不多，因為 Provisioned IOPS 太貴，所以直接加大空間換 IOPS 出來 (因為 General SSD 裡 1 GB 給 3 IOPS)：
To increase the IOPS baseline we could either increase the storage size or switch from General SSD to Provisioned IOPS storage. The cost of the different storage type was much higher so we decided to double our storage, thus, doubling our IOPS baseline. You can see in the graph below that we’re constantly above our previous baseline. This change helped Treeherder’s performance a lot.
然後再設警告機制，下次就可以提前再拉昇：
In order to prevent getting into such a state in the future, I also created a CloudWatch alert. We would get alerted if the combined IOPS is greater than 5,700 IOPS for 6 datapoints within 10 minutes.
不過 General SSD 的 IOPS 是沒有 100% 保證的，只有這樣寫：
AWS designs gp2 volumes to deliver 90% of the provisioned performance 99% of the time.
大多數的情況應該是夠用啦...
AWS 宣佈 EBS 的預設型態從 Standard 變成 GP2：「EBS default volume type updated to GP2」。
包括 web console 與 API 的預設值都改成 GP2：
The AWS console defaults to GP2 in all regions. On July 29th the default EBS volume type was updated in thirteen regions from Standard to GP2. Now AWS API calls for volume, image, and instance creation also default to GP2 in all regions.
GP2 是 SSD，所以可以提供比較低的 latency，而另外一個用 GP2 的好處是 i/o 的費用已經含在內了 (Standard 會另外收取費用)，對於成本估算會比較簡單一些，尤其是 i/o 量比較大的時候。
Hacker News Daily 上看到這則，分享了 AWS (他的前東家，超過八年) 的使用經驗：
This is how I use the good parts of @awscloud, while filtering out all the distracting hype.
?
1/25
— Daniel Vassallo (@dvassallo) July 25, 2019
除了可以在 Twitter 上看以外，也可以用 Thread reader 直接讀整條 thread，應該也還算清楚：「This is how I use the good parts of @awscloud, while filtering out all the distracting hype.」。
這邊的經驗談主要是在 web 與 app 相關的服務這塊：
My experience is in web- sites/apps/services. From tiny personal projects to commercial apps running on 8,000 servers. If what you do is AI, ML, ETL, HPC, DBs, blockchain, or anything significantly different from web apps, what I’m writing here might not be relevant.
3/25
— Daniel Vassallo (@dvassallo) July 25, 2019
有講到 AWS 的業務其實圍繞在 scalability 上發展，但這對 startup 可能反而是扣分，因為暴力法解反而可以大幅簡化架構換得 agile (而讓 startup 存活下來)。
另外從團隊的開發成本來看，這些 scale 的技術增加了開發成本，產生了很多開發上的限制，這些觀點也有點帶到「Premature optimization is the root of all evil」在講的事情：
Step 1: Forget that all these things exist: Microservices, Lambda, API Gateway, Containers, Kubernetes, Docker.
Anything whose main value proposition is about “ability to scale” will likely trade off your “ability to be agile & survive”. That’s rarely a good trade off.
4/25
— Daniel Vassallo (@dvassallo) July 25, 2019
最後的結論可以看到一些列表：
Conclusion: I like to seperate interesting new tech from tech that has survived the test of time. EC2, S3, RDS, DDB, ELB, EBS, SQS definitely have. If you’re considering alternatives, there should be a strong compelling reason for losing all the benefits accrued over time.
25/25
— Daniel Vassallo (@dvassallo) July 25, 2019
除了 DynamoDB 的意見不同外 (這邊提到的 DDB)，其他的我都可以接受...