CloudFront 在北美增加了一堆節點...

CloudFront 在北美增加了一堆節點:「Amazon CloudFront announces ten new Edge locations in North America, Europe, and Asia」。

北美一口氣增開了八個,提升了 40% 的 capacity:

Amazon CloudFront announces ten new Edge locations, adding to our global presence. Eight of the new Edge locations are in North America: Houston, Texas (our first location in this city), Chicago, Illinois, Newark, New Jersey, Los Angeles, California, and Ashburn, Virginia. We also added an Edge location in Berlin, Germany, as well as one in Tokyo, Japan.

With this launch, CloudFront will increase its request processing capacity by up to 40%, on average, in the North American cities.

另外不怎麼意外的又增加了東京...

AWS 給 EBS 用的 Data Lifecycle Manager 在東京可以用了?

先前在「Amazon EBS Snapshot 支援 Lifecycle Management」這邊提到 AWS 設計了 Data Lifecycle Manager,讓 EBS 磁碟可以自動產生 snapshot 並且管理保留份數,可以當作某種備份機制。

七月公告當時只開放了少數幾區:

Availability – Data Lifecycle Manager is available in the US East (N. Virginia), US West (Oregon), and Europe (Ireland) Regions.

剛剛發現在東京也已經可以用了?但好像沒看到有公告提過... 設下去看看會不會動好了。

HTTP/3 (QUIC) 的反面看法

這篇整理了 HTTP/3 (QUIC) 的反面看法,算是常見的疑慮都列出來了:「QUIC and HTTP/3 : Too big to fail?!」。

其實大多都是使用 UDP 而導致的問題:

  • 因為 UDP 導致 firewall 可能沒開,以及可能會需要等 timeout 走回 TCP 的問題。
  • 因為 UDP 變成很多事情在 userland 處理,而導致的 CPU 使用率比使用 TCP 的 TLS 1.2/1.3 高很多。
  • 因為 UDP 導致 amplification attack 的安全性問題,以及對應的 workaround 產生的頻寬議題。
  • 由於 UDP 會需要自己控制擁塞,等於是在 UDP 上面又重做了一次 TCP congestion algorithm,而且因為重作所以得考慮與 TCP 搶資源的公平性。

整篇文章算是整理了一般對 HTTP/3 的疑慮,之後如果有進展的話,可以再拿出來當 checklist 再確認有哪些有改善...

EC2 開始陸續推出支援 100Gbps 網路的機器

AWS 開始陸陸續續在推出有 100Gbps 能力的 EC2 instance 了:「New – EC2 P3dn GPU Instances with 100 Gbps Networking & Local NVMe Storage for Faster Machine Learning + P3 Price Reduction」。

從「Amazon EC2 Instance Types」這邊可以看到先前只有 c5n.18xlarge 有支援 100Gbps 網路,現在推出的 p3dn.24xlarge 是第二個支援的...

另外是 P3 系列的降價消息,比較奇怪的是從 2018/12/06 開始生效,而不是從月初開始。另外區域與條件也有一些複雜,有常在用的人可以翻一下說明...

WordPress 5.0 的編輯界面大改...

WordPress 升級到 5.0 後發現完全不會用新的編輯器了 (我是自己編 html 習慣了),去官方的 forum 上看一下有沒有其他人抱怨 (以及解法),看到「READ THIS FIRST WordPress 5.0 Master List」這篇公告。

公告裡提到可以裝「Classic Editor」這個 plugin 把舊的 editor 弄回來寫文章,而且這個 plugin 至少維護到 2022 年:

Classic Editor is an official WordPress plugin, and will be maintained until at least 2022.

本來打算要 downgrade 回舊版... 目前看起來還可以撐一段時間。

Ubuntu 撥 HiNet PPPoE 時會因為 MTU 而導致有些網站連不上

之前用 HiNet 固定制 (不需要 PPPoE,直接設 IP 就會通的那種),跑起來順順的也沒麼問題,最近剛好合約滿了就打算換成非固定制 (需要撥 PPPoE 才會通),結果換完後發現有些網站常常連不上 (不是一直都連不上),但只要設了 proxy.hinet.net (今年年底要停止服務了) 或是改從 cable 線路出去就正常。

測了不少設定都沒用 (像是改 tcp timestamp 設定,或是 sack 之類的設定),後來發現 MTU 的值不太對,用 ifconfig 看發現我的 ppp01500 而不是 1492,直接先 ifconfig ppp0 mtu 1492 改下去測,發現本來不能連的網站就通了...

(補充一下,我看了 Windows 的設定是 1480,所以也沒問題,但不知道怎麼算的...)

查了一下 MTU 相關的問題,發現在「wrong mtu value on dsl connection」這邊有討論到。裡面提到的 workaround 是到 /etc/NetworkManager/system-connections/ 裡找出你的 PPPoE 設定檔,然後在 ppp 區域的裡面寫死 mtu 參數:「mtu=1492」(這邊的 1492 是從 1500 bytes 扣掉 PPPoE 的 8 bytes 得出來的),不過我測試發現在修改設定檔時會被改回來,加上測試發現沒用,只好自己寫一個 /etc/network/if-up.d/pppoe-mtu 惡搞了:

#!/bin/sh -e

if [ "$IFACE" != "ppp0" ]; then
        exit 0
fi

/sbin/ifconfig ppp0 mtu 1492

放進去後要記得 chmod 755

從 ticket 上面看起來還是沒有解 (2009 年就發現了),看起來 PPPoE 不是絕對多數而且又有 workaround,短期應該不會修正...

Amazon EBS (gp2) 提昇效能...

AWS 宣佈提昇了 Amazon EBS (gp2) 的效能:「Amazon EBS Increases Performance of General Purpose SSD (gp2) Volumes」。

本來上限是 10k IOPS,現在提升到 16k IOPS 了。另外最大傳輸速度也從 160 MB/sec 提升到 250 MB/sec:

Today we are announcing a 60% improvement in performance of General Purpose SSD (gp2) Volumes from 10,000 IOPS to 16,000 IOPS and from 160 MB/s to 250 MB/s of throughput per volume.

應該還是維持 3 IOPS per GB 的設計,但這對於想要用 gp2 堆效能的人來說算是好消息,可以用更大的空間堆出更多 IOPS 了... (像是「Percona 的人接受 AWS 的建議,重新測試了 Percona XtraDB Cluster 在 gp2 上的效能...」這篇)

Vault 出 1.0 版,整合雲上面的 HSM 服務

看到「HashiCorp Vault 1.0」這則消息,Vault 要出 1.0 不是什麼新聞,重點是他把跟 Cloud Auto Unseal 的功能放出來了:

In Vault 1.0, we are open sourcing Cloud Auto Unseal, allowing for all users of Vault to leverage cloud services such as AWS KMS, Azure Key Vault, and GCP CKMS to manage the unseal process for Vault.

可以看在 AWS 上的作法:「Auto-unseal using AWS KMS」。

這樣在雲上的服務可以再降低風險...

AWS 的推薦演算法服務:Amazon Personalize

AWS 把推薦演算法包成服務拿來來賣,叫做 Amazon Personalize:「Amazon Personalize – Real-Time Personalization and Recommendation for Everyone」。

把後面的演算法隱藏起來,只要給使用者的評價資料就可以了,像是文章裡的範例:

userId,movieId,rating,timestamp
1,2,3.5,1112486027
1,29,3.5,1112484676
1,32,3.5,1112484819
1,47,3.5,1112484727
1,50,3.5,1112484580

可以看出來這個使用者對 2,29,32,47,50 這些 movieId 在不同的時間點都給了 3.5 分的評分。

然後經過一連串的 API 操作 (有些參數可以調整,但主要是叫 AWS 運算,並且建立 real-time 的服務),就可以看到推薦哪些其他的 item 了:

$ aws personalize-rec get-recommendations --campaign-arn $CAMPAIGN_ARN --user-id $USER_ID --query "itemList[*].itemId"
["1210", "260", "2571", "110", "296", "1193", ...]

而從 Pricing 的頁面可以看到支援 real-time data 與 batch data:

DATA INGESTION
You are charged per GB of data uploaded to Amazon Personalize. This includes real-time data streamed to Amazon Personalize and batch data uploaded via Amazon S3.

這其實是很多網站都很需要的功能...

AWS Lambda 可以直接掛進 ALB 了...

AWS 這次對 Lambda 還發表了不少功能,除了前面提到透過 Layout 支援其他語言以外 (e.g. Ruby),這邊要再提到另外一個重要的功能。

這次是 ALB 可以直接呼叫 lambda function 了:「Lambda functions as targets for Application Load Balancers」。

以前還得靠 API Gateway 整半天 (因為版本設定),現在直接用 ALB 接就可以了?而且 ALB 這邊有規劃對應的 quota:

There is no change to the hourly price of ALB. The load balancer capacity units (LCUs) of ALB now include 0.4 GB per hour of data processing to AWS Lambda targets.

這樣就更接近 serverless 了...

Archives