Tag: ebs

Amazon EBS 推出了 gp3

今年的 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 可以是開機硬碟，但是改不過去啊 XDDD

Update：剛剛發現文件被修正了，看起來不能當開機硬碟...

不知道哪邊搞錯了，過幾天看看吧 XDDD

Amazon EBS 的 Cold HDD (sc1) 降價 40%

剛剛看到 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 推出新的 io2 類型

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 推出可以同時掛到多台的選項

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 可以利用 S3 當作二級儲存空間了

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 的呼叫費用？

AWS 上用空間買 IOPS 的故事...

在「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 預設型態改為 GP2 (SSD)

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 量比較大的時候。

AWS Cloud 的用法

Hacker News Daily 上看到這則，分享了 AWS (他的前東家，超過八年) 的使用經驗：

除了可以在 Twitter 上看以外，也可以用 Thread reader 直接讀整條 thread，應該也還算清楚：「This is how I use the good parts of @awscloud, while filtering out all the distracting hype.」。

這邊的經驗談主要是在 web 與 app 相關的服務這塊：

有講到 AWS 的業務其實圍繞在 scalability 上發展，但這對 startup 可能反而是扣分，因為暴力法解反而可以大幅簡化架構換得 agile (而讓 startup 存活下來)。

另外從團隊的開發成本來看，這些 scale 的技術增加了開發成本，產生了很多開發上的限制，這些觀點也有點帶到「Premature optimization is the root of all evil」在講的事情：

最後的結論可以看到一些列表：

除了 DynamoDB 的意見不同外 (這邊提到的 DDB)，其他的我都可以接受...

Amazon EBS 的預設加密機制

EBS 有選項可以預設開加密了：「New – Opt-in to Default Encryption for New EBS Volumes」。

不算太意外的，這個選項要一區一區開：

Per-Region – As noted above, you can opt-in to default encryption on a region-by-region basis.

也不太意外的，無法完全公開共用：

AMI Sharing – As I noted above, we recently gave you the ability to share encrypted AMIs with other AWS accounts. However, you cannot share them publicly, and you should use a separate account to create community AMIs, Marketplace AMIs, and public snapshots. To learn more, read How to Share Encrypted AMIs Across Accounts to Launch Encrypted EC2 Instances.

然後有些服務有自己的 EBS 設定，這次不受影響。而有些底層其實是用 EC2 的服務 (然後開 EBS) 就會直接套用了：

Other AWS Services – AWS services such as Amazon Relational Database Service (RDS) and Amazon WorkSpaces that use EBS for storage perform their own encryption and key management and are not affected by this launch. Services such as Amazon EMR that create volumes within your account will automatically respect the encryption setting, and will use encrypted volumes if the always-encrypt feature is enabled.

AWS 給 EBS 用的 Data Lifecycle Manager 在東京可以用了？

先前在「Amazon EBS Snapshot 支援 Lifecycle Management」這邊提到 AWS 設計了 Data Lifecycle Manager，讓 EBS 磁碟可以自動產生 snapshot 並且管理保留份數，可以當作某種備份機制。

七月公告當時只開放了少數幾區：

Availability – Data Lifecycle Manager is available in the US East (N. Virginia), US West (Oregon), and Europe (Ireland) Regions.

剛剛發現在東京也已經可以用了？但好像沒看到有公告提過... 設下去看看會不會動好了。