Amazon EFS 的 IA Storage Class

Amazon EFS 一直找不太到好用的使用情境,因為 NFS 的關係所以大量 I/O 時的 latency issue 使得速度快不起來,而拿來堆 log 的成本又超級高...

最新推出的 storage class 則是透過提供低儲存成本的版本,解決了堆 log 這種使用情境:「New – Infrequent Access Storage Class for Amazon Elastic File System (EFS)」。

不過 EFS 不像 S3 可以直接選擇 storage class,是需要讓系統管理的:

開啟後 30 天沒有被碰過的檔案就會切過去:

Eligible Files – Files that are 128 KiB or larger and that have not been accessed or modified for at least 30 days can be transitioned to the new storage class. Modifications to a file’s metadata that do not change the file will not delay a transition.

而 latency 也會增加:

Files that have not been read or written for 30 days will be transitioned to the Infrequent Access storage class with no further action on your part. Files in the Standard Access class can be accessed with latency measured in single-digit milliseconds; files in the Infrequent Access class have latency in the double-digits.

us-east-1 為例子來說,Standard 是 USD$0.3/GB-month,而 IA 只要 USD$0.045/GB-month,但抓取時會有 USD$0.01/GB 的傳輸費用,可以看出價錢低不少。

不過文章裡沒提到什麼時候會把資料從 IA 跳回 Standard,可能得找機會問問看...

實際比較 Linode 的 Dedicated 主機與 AWS 的 c5.*

先前有提到 Linode 出了 Dedicated 主機:「Linode 推出 Dedicated CPU Instances」,現在找機會測試看看,拿了 Linode 的 Dedicated (4GB) 與 AWSc5.large 比較,同樣都是 2 vCPU 與 4GB RAM。

這邊用了 n-st/nenchOpenSSL 的 speed (包括了 aes、md5、rsa、sha1 與 sha256) 測試,我把結果都貼到這邊:「Linode (Dedicated 4GB) v.s. AWS (c5.large)」。

可以看到在 CPU 方面主要的差異是 Linode 用的是 AMD,而 AWS 用的是 Intel,所以就會有蠻多不同的數字表現...

如果仔細看 OpenSSL 的測試數據,可以看到不同演算法的差異還蠻大的,馬上可以想到的應該是硬體加速方式與 cache 架構差異造成的:

  • 在 cipher 類的測試我只測了 AES (目前的主流),小的 block (16/64/256 bytes) 時 AMD 會輸一些,但大的 block (1024/8192/16384 bytes) 反而會贏不少。
  • 在 hash 類的測試中,跑 MD5 時 Linode 則是輸一些,但 SHA1 反而是贏一些,然後 SHA256 時效能好到爆炸贏了一倍 XDDD
  • 在 public key 類的測試我測了 RSA,則是 Linode 輸的蠻慘的...

如果考慮到價位大約只有 AWS 的一半,應該是還不錯...

西班牙透過新法規限制 Uber 營業

包括 UberCabify 都受到新規範影響:「Ride-hailing companies suspend Barcelona services after new regulations」。

新規範限制乘客必須在上車前十五分鐘叫車:

The Catalan government ruled that ride-hailing services could only pick up passengers after a 15-minute delay from the time they were booked.

不是直接說你違法,而是用這個方式壓制隨叫隨到的服務... 這個方式應該會擴散到其他地區。

DynamoDB Autoscaling 的各種眉眉角角...

AdRollDynamoDB Autoscaling 的踩雷記錄,裡面有些資訊如果不是跳下去玩應該不會注意到 (魔鬼藏在細節裡的感覺):「Managing DynamoDB Autoscaling with Lambda and Cloudwatch」。

第一個提到的問題是 autoscaling 的觀察對象:

Ideally, the table should scale based on the number of requests that we are making , not the number of requests that are successful.

另外一個是 autoscaling 遇到完全不用的情況下不會 scale down,看起來是某種保護機制。但這使得平常只有拿來讀取的表格在跑完 batch job 後得自己處理 write scale down 問題:

Additionally, at the time of implementing this algorithm, the DynamoDB capacity could not be brought down automatically if the consumption was exactly zero, which can happen if you write to your table in batch instead of realtime, for example.

This meant that, when enabling autoscaling, tables that were read in realtime, but written to in batch, still needed manual intervention to bring the write capacity down after our jobs were done writing.

另外一個問題是 scale down 是有次數限制的:

Another interesting point that might bite users is that capacity decreases are an expensive operation for AWS, so they’re limited.

The number of decreases cited in the documentation can be achieved under very special conditions, since you need to have 4 decreases in the first hour of the day plus one for each of the remaining hours, for a total of 4 (first hour) + 23 (1 hourly) = 27.

後面就是自己研究什麼 algorithm 可以調整的更細,然後用 lambda 重寫... 最後省下 30% 的成本:

Here is where we detected our costs for our batch tables dropping to around 30% of the initial cost.

AdRoll 的規模應該是不小,所以為了省 30% 可以花不少力氣在上面...

Amazon 版的 OpenJDK 8 進入 GA

去年 11 月的時候 AWS 宣佈了要自己維護 OpenJDK 套件的計畫 Amazon Corretto:「AWS 決定花力氣支援 OpenJDK (Corretto 計畫)」,現在這個計畫的 OpenJDK 8 進入 GA (General Availability):「Amazon Corretto 8 Now Generally Available」。

之前有提到進入 GA 其中一個重點是提供 .rpm.deb 套件安裝,目前可以看到文件已經提供了,不過目前還只能手動下載安裝並更新:「Amazon Corretto 8 Installation instructions for Debian-based and RPM-based Linux distributions」。

與其他版本的差異可以在「Change Log for Amazon Corretto 8」這邊看到 AWS 修改的內容。

Kubernetes 的失敗案例

有人把 Kubernetes (通常縮寫成「K8S」) 的失敗案例 (轉移失敗、爛掉、...) 整理到 GitHub 上:「Kubernetes Failure Stories」,裡面有文章也有演講影片,然後也有重複的公司在不同時間點說明。

先來講 K8S 好了,如果要粗略的解釋 K8S 是什麼東西,我會說就像是架一組 AWS 服務起來,但是是基於 container 而非 VM。

拿 AWS 的詞彙來說,他在上面疊了一層 Amazon VPC (會對應到 Kubernetes 的 overlay network 與 CNI),然後也提供 AMI (透過 Docker Image) 與 EC2 (因為是比喻,這邊就拿 AMI + EC2 來對比),還有基本的 ELB (各種 NodePort、HostPort 與 Ingress) 與 Service Discovery。

比較特別的是 Pod 的概念,在一般的雲上不太會看到。

不過大致上你可以想像這是一個小型的 AWS,而試著去猜測管理一個小型的 AWS 會需要了解多少底層知識,加上 K8S 一直在發展,很多功能可能都還不成熟 (所以用起來會覺得設計很奇怪),然後上面整理出的失敗案例就不意外了... XD

如果你是自己有機房,或是用便宜的 VPS (像是 LinodeDigitalOceanVultr),那麼我覺得在上面堆 K8S cluster 還算合理,畢竟你可以透過 K8S 幫你整合不少以前得自己架設的服務。

但如果你是已經在 Cloud 上面,然後還想在上面跑 K8S cluster,我是覺得還是要有個理由 (不管是技術上或是政治上的)。如果只是因為 K8S 潮到出水而用的話,可能過一個月後你家就淹水了 XD

另外講一些題外話,因為最近弄 Kubernetes 的關係 (可以參考我的筆記「Kubernetes」),才能理解為什麼 Linode 這些 VPS 會推出 load balancer 與 block storage,算是後知後覺...

HiNet 對於 DNS flag day 的公告

先前提到了各大 Public DNS 服務將會在二月正式關閉對 EDNS 的 workaround,也就是 DNS flag day:「從二月開始不回應 EDNS 的 DNS server 將會無法查詢」,而 HiNet 也發出對應的公告了:「(DNS flag day) 部分Public DNS業者將於2019年2月1日執行EDNS符合性驗證」。

說明:一、 因應部分Public DNS服務(如Cloudflare 1.1.1.1、Google 8.8.8.8、IBM 9.9.9.9等)將於2019年2月1日執行EDNS符合性驗證(Extension mechanisms for DNS, DNS延伸機制),屆時如不支援EDNS協定之域名將造成Public DNS無法順利解析或解析反應變慢。 ( 參閱TWNIC 2019-01-23最新消息 https://blog.twnic.net.tw/2019/01/23/2286/ ) 二、 使用HiNet DNS服務(168.95.1.1與168.95.192.1)及HiNet代管DNS服務,皆可正常解析不受影響。 三、 若使用上述Public DNS服務,發生有部分域名無法解析情況,可改使用HiNet DNS服務,即可恢復正常解析。

一方面說明他們有處理他們自己的 DNS hosting,另外一方面順便推廣一下自家本來的 168.95.1.1168.95.192.1,但目前沒打算拿掉 DNS flag day 的 workaround XDDD

Twitter 搬上 Google Cloud

Twitter 要搬上 Google Cloud Platform 了,而 Google 直接把這個消息用最漂亮的 url 發佈:「Twitter migrates data to Google Cloud to keep the world tweeting」。

裡面也提到了一些數字,像是 Twitter 使用的空間:

To keep processing massive amounts of data 24/7, the social media platform was expecting to transfer over 300 petabytes of data storage to the cloud.

另外實際用 mtr 跑,看起來 twitter.com 前面還是 Twitter 自家機房的 proxy,所以應該是後面的架構搬上去?

NLB 也可以幫忙處理 TLS 了...

AWS 推出的新功能,讓 NLB (network load balancer) 可以直接做完 SSL offload:「New – TLS Termination for Network Load Balancers」。

而且 NLB 可以保留 source ip,不需要在 web server 上處理特殊的 header (像是 X-Forwarded-For 這類的 HTTP header)。這點倒是頗有趣...