Tag: auto

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

官方支援 DynamoDB 的 Auto Scaling 了

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

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

終於啊...

利用隱藏的 form input 加上自動完成功能取得敏感資料

anttiviljami/browser-autofill-phishing 這邊示範了怎麼用隱藏的 form input 與自動完成功能取得敏感資料。在這邊可以看到示範 (把 POST 丟到 httpbin 上看 response)。

想法不算困難，但好像也不是很好防... 關掉 autofill 是比較簡單的解法 (我是裝好瀏覽器就會關掉，不過好像很多人都喜歡用這個功能)，所以這個問題就丟回給這些 browser vendor 想了 :o

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 來喊價)。

AWS 的 Auto 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

Shazam 新功能對隱私的攻擊性

Shazam 的新功能可以直接在背景辨識 (叫做 Auto Shazam)，這比 Siri 還具有侵略性：「Shazam’s new feature on Android has convinced me to ditch SoundHound for identifying songs」。

看作者超開心的是怎樣... 來看看 Android 上要怎麼鎖 :o

用 Lambda 做 DynamoDB 的 Auto Scaling

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

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

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