Home » Posts tagged "scaling"

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

Auto Scaling 的 Instance Protection,有點像是 mutex...

前幾天 AWS 放出來的新功能,可以針對 Auto Scaling 裡的機器設定保護 (避免關機):「New – Instance Protection for Auto Scaling」。

看提供的 pseudocode 可以了解想法,ProcessWorkUnit(Work) 是個需要跑比較長時間的 process,中斷掉的話會浪費掉 resource:

while (true)
{
  SetInstanceProtection(False);
  Work = GetNextWorkUnit();
  SetInstanceProtection(True);
  ProcessWorkUnit(Work);
  SetInstanceProtection(False);
}

也就是這些機器還是會被 Auto Scaling 計算在內,但關機不會動這些機器。這段範例有種以前上課學 mutexcritical section 的感覺...

Archives