Home » Posts tagged "scaling"

貴不少的 DynamoDB On-Demand...

DynamoDB 用起來比較困難的部份就是規劃 R/W capacity,所以 AWS 就推出了 DynamoDB On-Demand,直接計算用多少而不用規劃 R/W capacity:「Amazon DynamoDB On-Demand – No Capacity Planning and Pay-Per-Request Pricing」。

先講一下歷史,在 2014 的時候 Jeff Barr 就有在「Auto Scale DynamoDB With Dynamic DynamoDB」這邊提到開一台 t1.micro 在上面跑程式實做 DynamoDB 的 auto scaling。

另外在 2017 年的時候 AWS 自己推出了同樣的功能,就不需要開機器了,交給 AWS 的服務處理就可以了:「New – Auto Scaling for Amazon DynamoDB」。

所以就一般性的需求來說,其實目前的方案夠用:常態性的需求提昇,以及有預期性的活動時可以手動事前提昇。

目前想到唯一會炸掉的情境應該是突然被熱門媒體報導,而導致大量的 guest session 衝進來,而且架構上又沒有針對 guest session 用 cache 擋住 (Amazon DynamoDB Accelerator 也是個選項),導致壓力就全部到後端的 DynamoDB,而 auto scaling 機制需要時間看到量才會調整,在這段時間就有可能短時間倒站。

回來看這次的 On-Demand 提出來的價錢。以 us-east-1 的價錢來看:

Write request units$1.25 per million write request units
Read request units$0.25 per million read request units

而本來要自己規劃 R/W capacity 的價錢是 (這邊是 hourly):

Write capacity unit (WCU)$0.00065 per WCU
Read capacity unit (RCU)$0.00013 per RCU

由於不管是 On-Demand 還是本來的規劃,Read 價錢都是 Write 的 1/5,所以只要看 Write 一樣可以知道差距。

接下來把 On-Demand 的價錢換算成 3600 個 request units 就可以比較單價,是 $0.0045 (Write),大約是本來版本 6.92 倍的費用...

而且對於已經有規模的應用,這邊還沒算 Reserved Capacity 會有折扣的部份?

這個定價策略讓我想到 AWS Fargate 的情況... 如果你可以接受這個價錢,你可以平常就開五倍的 R/W capacity 在上面啊 XDDD

EC2 推出用 machine learning 協助 auto scaling 控制的功能...

AWSEC2 上推出了用 machine learning 協助 auto scaling 控制的功能:「New – Predictive Scaling for EC2, Powered by Machine Learning」。

最少給他一天的資料 (然後他會每天重新分析一次),接著會預測接下來的 48 小時的使用行為:

The model needs at least one day’s of historical data to start making predictions; it is re-evaluated every 24 hours to create a forecast for the next 48 hours.

所以是個學 pattern 然後預先開好機制等著的概念...

透過預測增加服務穩定性的概念... 如果本來就跑得好好的 (也就是靠 resource-based metric 觸發機器數量的方式跑得很好),就未必需要考慮這個方案了。

目前支援的區域中,東京不在列表內,不過其他常見的區域都支援了:

Predictive scaling is available now and you can starting using it today in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Singapore) Regions.

ALB 支援 Slow Start 了

這個功能在 ELB Classic 年代時有跟 AWS 提過,到 ALB 支援了 (總算...):「Application Load Balancer Announces Slow Start Support for its Load Balancing Algorithm」。

Application Load Balancers now support a slow start mode that allows you to add new targets without overwhelming them with a flood of requests. With the slow start mode, targets warm up before accepting their fair share of requests based on a ramp-up period that you specify.

然後時間可以設定,從 30 秒到 15 分鐘:

Slow start mode can be enabled by target group and can be configured for a duration of 30 seconds to 15 minutes. The load balancer linearly increases the number of requests sent to a new target in a target group up to its fair share during the slow start ramp-up window.

就之前的經驗來說,這在跑 PHP 的時候會很需要這個功能 (之前是在 F5 的設備上設定)。其他的語言因為性質不太一樣,可能不會這麼吃這個功能。

主要是因為 PHP 是在 request 進來時 compile 並且 cache。所以在機器剛起來時,儘量將 CPU 留給 opcache,把常用的頁面 compile 完並且放進 cache,而不是讓大量的連線灌進來,這樣對使用體驗不會太好... (要避免 CPU 吃滿 100% 很久,造成每個連線都很慢才跑完)

AWS 推出 Slow Start 後對 auto scaling 時的順暢度會好不少...

Fortnite 看起來沒上 Auto Scaling?(或是沒正確設好?)

Fortnite 遊戲的伺服器放在 AWS 上,看起來這波 Meltdown 的安全更新 (KPTI) 造成非常大的 overhead:

不過看起來出了問題:

We wanted to provide a bit more context for the most recent login issues and service instability. All of our cloud services are affected by updates required to mitigate the Meltdown vulnerability. We heavily rely on cloud services to run our back-end and we may experience further service issues due to ongoing updates.

最有可能的是把 AWS 當作一般的 VPS 在用,另外一種可能是有部份內部服務沒有 scale,造成上了 KPTI 後 overhead 增加,就卡住了...

Amazon Aurora 的 Serverless 與 Multi-master

Amazon Aurora 推出了兩包玩意,第一包是 Serverless,讓需要人介入的情況更少:「In The Works – Amazon Aurora Serverless」。

在 Serverless 的第一個重點是支援以秒計費:

Today we are launching a preview (sign up now) of Amazon Aurora Serverless. Designed for workloads that are highly variable and subject to rapid change, this new configuration allows you to pay for the database resources you use, on a second-by-second basis.

然後是極為快速的 auto-scaling:

The endpoint is a simple proxy that routes your queries to a rapidly scaled fleet of database resources. This allows your connections to remain intact even as scaling operations take place behind the scenes. Scaling is rapid, with new resources coming online within 5 seconds

這兩個組合起來,讓使用端可以除了在 Amazon EC2 上可以快速 scale 外,後端的資料庫也能 scale 了...

第二個是 Multi-master 架構:「Sign Up for the Preview of Amazon Aurora Multi-Master」。

Amazon Aurora Multi-Master allows you to create multiple read/write master instances across multiple Availability Zones. This enables applications to read and write data to multiple database instances in a cluster, just as you can read across Read Replicas today.

(話說我一直都誤以為 Aurora 是 R/W master...)

Anyway,這個功能不知道怎麼疊上去的... 不笑得會不會有嚴重的 distributed lock issue,反而推薦大家平常都寫到同一台 (像是 PXC 就會這樣)。

超越線性成長的資料庫架構

標題取自 Percona 的「Better Than Linear Scaling」。

其實是因為機器數量增加,而且有妥善規劃,使得 cache 的 hit rate 上升而讓整體效率變好 (也就是 1 + 1 > 2)。

不只在 database 上會發生,在其他系統上其實會有類似的情況,剛好看到覺得很懷念 XD

Auto Scaling 可以拉 EC2 Spot Instance 進來用了

Update:auto scaling 在 2012 就支援 spot instance 了:「EC2 Spot Instance Updates – Auto Scaling and CloudFormation Integration, New Sample App」,我一直有 auto scaling 不支援的印象... 這次是支援 EC2 Spot Fleets (i.e. 以 capacity 為主的架構,將兩台 c4.4xlarge 與一台 c4.8xlarge 當作是有相同 capacity 來喊價)。

AWSAuto Scaling 宣佈支援 Spot Instance 了:「New – Auto Scaling for EC2 Spot Fleets」。

雖然文章主要都是以 worker 之類的應用來做,但可以看到還是有說 web service:

Web Service – Scale web services based on measured response time and average requests per second.

我猜官方還是不建議這樣用,所以整篇文章都還是以 worker 類為主。應該是因為 web service 直接對使用者,用 Auto Scaling 不一定開的起來,反而有可能會爆炸 XD

用 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

Archives