AWS 推出 CloudWatch Metric Streams

AWS 推出了 CloudWatch Metric Streams,把 CloudWatch Metric 的資料往 Kinesis Data Firehose 裡面丟:「CloudWatch Metric Streams – Send AWS Metrics to Partners and to Your Apps in Real Time」。

其中一個賣點是即時性比用 API 去拉好很多:

In order to make it easier for AWS Partners and others to gain access to CloudWatch metrics faster and at scale, we are launching CloudWatch Metric Streams. Instead of polling (which can result in 5 to 10 minutes of latency), metrics are delivered to a Kinesis Data Firehose stream.

格式上可以是 JSON 或是 Open Telemetry

When you set up a stream you choose between the binary Open Telemetry 0.7 format, and the human-readable JSON format.

另外一個賣點是價位,每千次 $0.003:

Pricing – You pay $0.003 for every 1000 metric updates, and for any charges associated with the Kinesis Data Firehose. To learn more, check out the pricing page.

另外算一下 Kinesis Data Firehose 的價錢,是以資料量的大小計費,不過最小計價單位是 5KB (一筆應該是不會到),單價是 $0.029/GB (us-east-1) 或是 $0.037/GB (ap-southeast-1),算了一下跟 CloudWatch Metrics Streams 比起來只是零頭...

之前如果要自己拉出來的話是透過 API call 抓,每 1000 次是 USD$0.01,這個方法相較起來便宜不少,不過數量多的時候還是一筆費用 (而且有不少 metrics 是一分鐘更新一次)。

如果只是要備份起來或是跑分析的話,也許先前用 API 拉的作法可能還是比較好?一個小時拉一次對於備份與分析應該都很夠了,而 alarm 的機制還是掛在 CloudWatch 上。

這次產品的定位看起來是要把 ecosystem 做起來:

We designed this feature with the goal of making it easier & more efficient for AWS Partners including Datadog, Dynatrace, New Relic, Splunk, and Sumo Logic to get access to metrics so that the partners can build even better tools.

EC2 總算支援透過 Serial Console 操作了...

以往 Amazon EC2 的機器爛到開不起來時只能「看」到 Console 的輸出,然後要把 root volume 掛到其他機器上修正,接著再掛回來 (然後沒修好就要再重複...),現在總算可以透過 EC2 Serial Console 來操作了:「Troubleshoot Boot and Networking Issues with New EC2 Serial Console」。

不過裡面有一些限制,首先機器必須是基於 AWS Nitro System,這個部份在「Amazon EC2 Instance Types」這邊可以翻到是不是 Nitro,比較新的 family type 應該都是 (像是 t3/t3a/t4g 都是 Nitro,但 t2 不是):

EC2 Serial Console access is available for EC2 instances based on the AWS Nitro System. It supports all major Linux distributions, FreeBSD, NetBSD, Microsoft Windows, and VMWare.

另外是支援的區域目前只有幾個主力區域,不過公司在用的主力區 (新加坡) 也進去了,之後遇到問題的時候可以測試看看:

  • US East (N. Virginia), US West (Oregon), US East (Ohio)
  • Europe (Ireland), Europe (Frankfurt)
  • Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Singapore)

Twitter 上看到有些人有提到「總算啊...」之類的感想...

AWS 推出 X2gd 機種,針對記憶體再提供更便宜的方案

AWS 推出了 X2gd 機種,用 ARM 的 CPU,然後給更少顆,disk 也更小,但換來的就是價錢更低:「New Amazon EC2 X2gd Instances – Graviton2 Power for Memory-Intensive Workloads」。

把兩個用 ARM 的主機拿出來看看 us-east-1 的價錢,第一個是這次的 x2gd.medium,只有 1 vCPU + 59 GB SSD,但有 16 GB RAM,現在的價錢是 $0.0835/hr。

另外一個 r6g.large 則是 2 vCPU + 16 GB RAM,然後 EBS only,則是 $0.1008/hr。

再來是 Intelx1e.xlarge,這邊是 4 vCPU + 12 GB RAM + 120 GB SSD,單價也差不多,不過記憶體少了點,$0.834/hr。

另外 Intel 也有 r5.large,2 vCPU + 16 GB RAM + EBS only,$0.126/hr。

最後一個是 AMDr5a.large,跟 Intel 的 r5.large 也很像,2 vCPU + 16 GB RAM + EBS only,$0.113/hr。

這次推出的 X2gd 機種提供了只要記憶體的極端選擇,而且依照先前的經驗,Graviton2 真的很快,1 vCPU 未必會不夠用... 至少我 blog 的 PHPMariaDB 都是跑在 t4g 上面,看起來比之前放在 VPS 上快不少 :o

Amazon EFS 推出 One Zone 版本

Amazon EFS 提供 One Zone 的版本,用較低的可靠度提供更低的價錢:「New – Lower Cost Storage Classes for Amazon Elastic File System」。

價錢大約是 53 折,不過要注意不在同一個 AZ 時使用會有頻寬費用:

Standard data transfer fees apply for inter-AZ or inter-region access to file systems.

目前想的到的是 /net/tmp 這類的用途,資料掉了也就算了,考慮到可靠度,其他的用途好像暫時想不到...

AWS 大阪區開放

AWS 大阪區開放給大家使用了,而且有標準的三個 AZ 可以用:「AWS Asia Pacific (Osaka) Region Now Open to All, with Three AZs and More Services」。

大阪區因為之前就已經有機房 (附加在東京區),所以對應的 routing 看起來不算太差,但也沒有特別好... 剛剛測了一下從 HiNet 光世代過去的 latency,分別是 35.5ms (東京的 ap-northeast-1) 與 34.6ms (大阪的 ap-northeast-3)。

另外測了其他的 ISP,有些上日本的點是以東京為主,反而會多繞了一圈,大阪區的 latency 會比較高。

不過如果放遠來說,東京大阪的直線距離大約是 400km,光纖的傳輸速度大約是光速的 2/3,所以單趟大約差了 2ms,如果有機會最佳化的話應該有機會擠出 4ms 出來?

然後是 EC2Pricing 頁面,上面還是寫 Asia Pacific (Osaka-Local),無法確定是新資料還是舊資料,但以往的慣例應該是更新了...

對照文章裡有提到支援的機器,目前看起來還沒有很齊,像是目前都還沒有 AMDARM 架構的機器,另外也沒有 GPU 類型的機器:

The Asia Pacific (Osaka) Region supports the C5, C5d, D2, I3, I3en, M5, M5d, R5d, and T3 instance types, in On-Demand, Spot, and Reserved Instance form. X1 and X1e instances are available in a single AZ.

就支援的類型隨意挑了幾個 instance type 比較,翻了一下價錢看起來跟東京的一樣。

整體看起來,如果是有考慮到異地的需求是可以考慮,另外如果是新的服務的話也可以考慮看看 (畢竟各 ISP 應該有機會再把 latency 壓出來),但既有的服務應該不需要急著搬...

DigitalOcean 送出 Form S-1

Hacker News Daily 上看到的消息,DigitalOcean 送出 Form S-1:「d898181ds1.htm」,在 Hacker News 上也有不少討論:「DigitalOcean S-1 (sec.gov)」。

這個消息跟 2020 年年初的裁員也可以交叉看一下:「DigitalOcean 裁員」,另外在 TechCrunch 上也有報導:「DigitalOcean’s IPO filing shows a two-class cloud market」。

Hacker News 上蠻多人在抱怨 DO 的產品,像是機器的效能,操作界面的穩定性,還有客服的反應... 不過這些跟 IPO 倒是沒什麼關係,重要的是每年的營業額有做出來:

Per its S-1 filing, DigitalOcean generated $203.1 million in 2018 revenue, $254.8 million in 2019 and $318.4 million in 2020. The company closed 2020 out with a self-calculated $357 million in annual run rate.

自己用的話應該還是偏好 VultrLinode...

把 AWS 的 Billing 資料接進 Grafana 上...

Twitter 上看到 Grafana 的帳號提到了一篇把 AWS Billing 資料接進 Grafana 上的文章:

這個想法還頗不賴的,有些東西剛好可以交叉比對拉出來...

ALB 支援 Sticky Session

又是一個以為很久前就已經支援,但實際上沒支援的功能...

ALB 支援使用 cookie 實現 sticky session 功能:「Application Load Balancer now supports Application Cookie Stickiness」。

使用者的 session 通常會使用 cookie 記錄,而如果有多台 server 提供服務時,session 裡的資訊就需要找一個 shared session storage 放,以確保使用者在連到不同的 server 時都還是可以讀到對應的 session,比較傳統的方案就是直接把 session 塞進資料庫,後來發展出 memcached 或是 Redis 可以用。

但有些買來的軟體並沒有考慮到這點 (常常都是內部系統),導致前面放 load balancer 時,必須想個辦法記錄使用者使用後端的哪台機器,這樣就可以在後端不支援 shared session storage 的情況下,還是可以讓應用正常運作。

透過 cookie 實做的 sticky session 算是蠻常見的作法,只是以為早就有了...

把 blog 從 t4g.small 降到 t4g.micro

我在「把 blog 搬到 t4g.small 上」這邊有提到把這個 blog 搬到 Amazon EC2t4g.small 上 (2GB RAM + 20% CPU credit),跑了一陣子把 CPU usage 拉出來看:

當初估大約要 20% 的 CPU credit,結果發現 CPU credit 大概用 5% 就夠了。另外記憶體的部份大約要給 1GB,這個量可以看出來一些沒在用的 process 會被丟到 swap:

              total        used        free      shared  buff/cache   available
Mem:          952Mi       380Mi        79Mi       110Mi       492Mi       368Mi
Swap:         511Mi       152Mi       359Mi

把條件綜合起來計算,就往下降一階變成 t4g.micro 了 (1GB RAM + 10% CPU credit)。

另外新機種比較不用擔心淘汰速度,就看了一下 Reserved Instances 的價錢,一年 USD$44,三年 USD$84,看起來只要有用兩年就算是 OK,直接買三年解決掉...

把 blog 搬到 t4g.small 上

算了一下成本還可以接受 (機器 + 空間 + 流量),就把 blog 搬到 AWSt4g.small (ARM) 上,理論上頁面的速度應該會快不少,過幾天等穩定性沒問題後就來買 RI...

x86-64 轉到 ARM 上面,主要是 Percona Server 目前沒有提供 ARM binary 的 apt repository,所以就改用 MariaDB 了。

其他的倒是都差不多,目前的 Ubuntu + nginx + PHP 沒什麼問題,跑一陣子看看...