Tag: auto

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

AWS 在 EC2 上推出了用 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.

Aurora Serverless MySQL 進入 GA

AWS 宣佈能 auto-scale 的 Aurora Serverless MySQL 進入 GA：「Aurora Serverless MySQL Generally Available」：

不過目前開放的區域有限：

Aurora Serverless for Aurora MySQL is available now in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland).

以秒計費，但低消是 5 分鐘：

You pay a flat rate per second of ACU usage, with a minimum of 5 minutes of usage each time the database is activated.

以 us-east-1 的價錢來看，每個 ACU 是 USD$0.06/hour，而每個 ACU 大約是 standard instance 的價錢：

1 ACU has approximately 2 GB of memory with corresponding CPU and networking, similar to what is used in Aurora Standard instances.

但這沒看懂，是 db.t2.small 還是 db.t2.medium？另外比較是全速還是 small 的 20% 或 medium 的 40%？這部份也許還要再問看看才知道...

storage 與 I/O 的費用則是相同，倒是不用比較這塊... 再來不知道有沒有推出 Reserved ACU 的計畫，光是一年付清就差蠻多的。

要不要換過去其實還是要看看使用的量，以及可以接受的成本來決定...

EC2 的 Dedicated Instance 也支援 Auto Recovery 了...

所以除了一般的 EC2 instance 可以設定 Auto Recovery 外，實體機的 Dedicated Instance 也可以設定了：「Amazon EC2 Auto Recovery is now available for Dedicated Instances」。

不過能用架構做 High Availability 還是用架構做會比較好 (像是透過 ELB 擋在前面提供服務)，Auto Recovery 因為是透過 CloudWatch 偵測 (目前最短的偵測時間應該是 10 秒一次)，再加上要等新機器接手，還是會有明顯的 downtime。

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 時的順暢度會好不少...

HTTPS Everywhere 改變更新 Ruleset 機制，變成定時更新...

HTTPS Everywhere 是我很喜歡的一個套件，裡面有 Ruleset，會將 Ruleset 表內認定有支援 HTTPS 網站的 HTTP request 都改成 HTTPS，這可以降低被攔截的風險。像是網站雖然有 HSTS 但第一次連線時走 HTTP 的情況，以及網站本身有支援 HTTPS 但沒有設定 HSTS 時，在網址列上誤打 HTTP 版本的情況。

先前版本的 Ruleset 是隨著軟體更新時，包在軟體內一起更新。這樣的缺點是更新速度比較慢，但好處是不需要伺服器端，而且隱私性也比較高。而現在 EFF 決定還是要推出線上更新的版本，以加速 Ruleset 更新的速度：「HTTPS Everywhere Introduces New Feature: Continual Ruleset Updates」。

We've modified the extension to periodically check in with EFF to see if a new list is available.

而頻寬的部份由 Fastly 贊助：

If you haven't already, please install and contribute to HTTPS Everywhere, and consider donating to EFF to support our work!

如果對這點有疑慮的，也還是可以關掉 auto updater 避免洩漏資訊給 EFF 或是 Fastly。

Amazon ECS 的 Service Discovery

AWS 宣佈了 Amazon ECS 也支援 Route 53 提供的 Service Discovery 了：「Introducing Service Discovery for Amazon ECS」。

也就是說現在都整合好了... 比較一下先前需要自己包裝起來套用的方式會少不少功夫：

Previously, to ensure that services were able to discover and connect with each other, you had to configure and run your own service discovery system or connect every service to a load balancer. Now, you can enable service discovery for your containerized services with a simple selection in the ECS console, AWS CLI, or using the ECS API.

AWS 在 2016 年的時候有寫一篇「Service Discovery for Amazon ECS Using DNS」在講怎麼透過事件的觸發配合 AWS Lambda 把服務掛上去或是移除掉：

Recently, we proposed a reference architecture for ELB-based service discovery that uses Amazon CloudWatch Events and AWS Lambda to register the service in Amazon Route 53 and uses Elastic Load Balancing functionality to perform health checks and manage request routing. An ELB-based service discovery solution works well for most services, but some services do not need a load balancer.

現在看起來都可以改用 Auto Naming API 了...

Amazon Route 53 的 Auto Naming API 可以指到 CNAME 位置了

Amazon Route 53 的 Auto Naming API 可以拿來跑 Service Discovery (參考先前的「用 Amazon Route 53 做 Service Discovery」這篇)，當時是 A/AAAA/SRV record，現在則可以註冊 CNAME 了：「Amazon Route 53 Auto Naming Announces Support for CNAME Record Type and Alias to ELB」。

最直接的影響就是 ELB 的部份了，透過 ELB 處理前端的話，覆載平衡以及數量限制的問題就會減輕很多 (之前是靠 Round-robin DNS 打散，而且限制一次最多回應五個 record)：

Beginning today, you can use the Amazon Route 53 Auto Naming APIs to create CNAME records when you register instances of your microservices, and your microservices can discover the CNAMEs by querying DNS for the service name. Additionally, you can use the Amazon Route 53 Auto Naming APIs to create Route 53 alias records that route traffic to Amazon Elastic Load Balancers (ELBs).

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 Route 53 做 Service Discovery

Amazon Route 53 的新功能，可以解決以前自己要建立 Service Discovery 服務的工作：「Amazon Route 53 Releases Auto Naming API for Service Name Management and Discovery」。官方的文件在「Using Autonaming for Service Discovery」這邊。

不過目前有些限制，一個 namespace (domain name) 目前只能有五個服務：

DNS settings for up to five records.

然後 DNS 回應時，最多回八個 record：

When Amazon Route 53 receives a DNS query for the name of an instance, such as backend.example.com, it responds with up to eight IP addresses (for A or AAAA records) or up to eight SRV record values.

回應八個 record，但應該是可以註冊超過八個吧... (i.e. 每次都回不一樣)

自建服務 (像是 Cassandra 或是 ScyllaDB) 可以直接用這個服務掛上去，就不用自己架 Consul 了。

目前支援了這四區，亞洲不在這波提供範圍：

Amazon Route 53 Auto Naming is available in US East (N. Virginia), US East (Ohio), US West (Oregon), and EU (Ireland) regions.

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 就會這樣)。