Amazon RDS for PostgreSQL 可以掛 155 台 Read Replica

看到 AWS 推出的新「功能」,可以讓 Amazon RDS for PostgreSQL 的 read replica 掛到 155 台:「Amazon RDS for PostgreSQL supports cascaded read replicas for up to 30X more read capacity」。

作法是透過三層架構,每台機器可以堆五台 replica:

Amazon Relational Database Service (Amazon RDS) for PostgreSQL announces support for PostgreSQL 14 with three levels of cascaded read replicas, 5 replicas per instance, supporting a maximum of up to 155 read replicas per source instance.

需要 PostgreSQL 14.1 或是之後的版本:

Starting with Amazon RDS for PostgreSQL 14.1 and higher, read intensive workloads such as data analytics can now benefit from up to 155 cascaded read replicas that offer up to 30 times higher read capacity versus previous versions of PostgreSQL, thereby reducing the load on source instance.

我記得 Amazon RDS for PostgreSQL 的 replica 是 EBS block-level replication,這種搞法還蠻有趣的 XDDD

Fastly 觀察到因 COVID-19 產生的流量上升資料

因為 COVID-19 的關係,可以預期網路的流量一定會大幅提昇,但實際上是多少總是需要一些數據才能想像...

剛剛看到 Fastly 放出了他們觀察到因為 COVID-19 而產生的流量變化:「How COVID-19 is affecting internet performance」。

從 2020 年二月與三月相比,可以看到許多區域的流量都有大幅成長,尤其是重災區的義大利與英國,不過這邊沒有給與 2019 三月的比較 (YoY):

另外是這些流量成長的種類,可以看到 streaming、數位媒體與教育類的流量大幅成長:

在網路速度的部份,可以看到大多數的地區是下降的,但加州沒什麼影響,而日本反而是上升的,應該可以解讀為這兩個地區平常就有夠多的容量,所以真的有爆量而用到的時候反而不會是瓶頸?

接下來幾個月應該會更嚴峻...

EC2 提供短期 RI 選項...

Amazon EC2 推出了短期 RI 選項:「Amazon EC2 now offers On-Demand Capacity Reservations」。

最早的 RI 設計包括了「保證一定開的起來」與「折扣」,但後來 AWS 大概是發現大家都是要「折扣」而不是保證開的起來,所以就開放了只有 discount 的部份。把原來有保證一定開的起來的部份變成 Zonal Reserved Instances。

不過 Zonal Reserved Instances 最少要一年 (有對應的折扣),這次規劃的 On-Demand Capacity Reservations 可以隨時取消,但是就沒折扣了:

Previously in order to achieve a capacity reservation, customers had to leverage Zonal Reserved Instances and commit to that capacity for a minimum of one year. Now with On-Demand Capacity Reservations, customers can reserve the exact capacity they need, in the location they need, and can keep it only for as long as they need it.

不過費用計算上會組合已經買的 Regional RI,如果沒被用掉的話還是可以將對應的折扣拿進來用:

If you have Regional RI discounts, they will automatically apply to any matching Capacity Reservation. This gives you the flexibility to selectively add capacity reservations and still get the Regional RI discounts for that usage.

算是對需要「保證開的起來」的單位提供短期的彈性,實際上後面應該是去 spot instance 那邊踢一些機器出來?XD

AWS Lambda 可使用的記憶體空間從 1.5GB 變成 3GB

AWS 是說 AWS Lambda 可用的記憶體空間 double 啦,不過 3008MB 這個數字有點怪...:「AWS Lambda Doubles Maximum Memory Capacity for Lambda Functions」。

You can now allocate 3008MB of memory to your AWS Lambda functions. Previously, the maximum amount of memory available to your functions was 1536MB. Now, it's easier to process workloads with higher memory or denser compute requirements, such as big data analysis, large file processing, and statistical computations.

這個就真的全區都生效了,包括一般人不能註冊的 AWS GovCloud (US) 與中國區:

This feature is available in US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), AWS GovCloud (US), Canada (Central), South America (São Paulo), EU (Frankfurt), EU (Ireland), EU (London), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), and China (Beijing).

Amazon Aurora 可以 clone 了...

Amazon Aurora 可以 clone 複製資料庫了:「Amazon Aurora Introduces Database Cloning Capabilities」。

而且是 COW 架構 (Copy on write),所以複製出來的部份不需要額外付儲存費用,只有修改的部份才要付費,這點相當殺啊:

A cloning operation does not incur any storage charges. You will only be charged for additional storage space if you make data changes.

這對於「測試」這件事情變出不少變化可以用...

官方支援 DynamoDB 的 Auto Scaling 了

DynamoDB 可以透過 console 或是 API 調整 R/W 的 capacity,但一直都沒有全自動的機制這件事情為人詬病頗久。

以前都是自己用 AWS Lambda 或是其他架構判斷調整,現在官方直接提供了:「New – Auto Scaling for Amazon DynamoDB」。

終於啊...

用 Lambda 做 DynamoDB 的 Auto Scaling

AWS Lambda 可以跑 cron job 後應該就不怎麼意外出現了:「Autoscale DynamoDB provisioned capacity using Lambda」。

不像 EC2Auto Scaling,或是 ELB 自己會成長或縮小,DynamoDB 跟其他 AWS 服務不同,雖然可以 scale,但需要自己手動設定 capacity 伸縮。

於是就有人寫了程式 (也就是這個專案),判斷目前的 r/w 用量來決定策略... 有點像是我在處理自家 bandwidth 的搞法,達到某個警戒值就自動增加導去 CDN 的量,或是降低回來 :o

EC2 Spot Instance 可以用 Capacity 競標了

前幾天 AWS 的「New – Resource-Oriented Bidding for EC2 Spot Instances」這篇文章提到 EC2 Spot Instance 可以用 capaciy 競標了,也就是以「資源的總量」來飆,而非指定某種型態的 instance。

以文章裡的例子來說,假設要標 488 個單位的 capacity,那麼有可能出現:

  • 2 x r3.8xlarge
  • 4 x r3.4xlarge
  • 8 x r3.2xlarge
  • 16 x r3.xlarge
  • 32 x r3.large

也有可能出現混搭的版本:

  • 1 x r3.8xlarge and 2 x r3.4xlarge
  • 2 x r3.4xlarge and 8 x r3.xlarge
  • 8 x r3.xlarge and 16 x r3.large

對於某種 spot instance 價錢突然提高時,可以改用其他 instance 繼續執行,變得更有彈性...