Amazon S3 變成 Strong Consistency 背後的改善方式

看到 Hacker News 上的討論「Diving Deep on S3 Consistency (allthingsdistributed.com)」才想到該整理一下,原文的「Diving Deep on S3 Consistency」是 Amazon 的 CTO Werner Vogels 花了一些篇幅描述 Amazon S3 怎麼把 Eventually Consistent 變成 Strongly Consistent,當初 Amazon S3 公告時我也有寫一篇文章提到:「Amazon S3 現在變成 Strong Read-After-Write Consistency 啦...」。

Amazon S3 之所以會是 Eventually Consisient 是因為 Metadata Subsystem 的 cache 設計:

Per-object metadata is stored within a discrete S3 subsystem. This system is on the data path for GET, PUT, and DELETE requests, and is responsible for handling LIST and HEAD requests. At the core of this system is a persistence tier that stores metadata. Our persistence tier uses a caching technology that is designed to be highly resilient. S3 requests should still succeed even if infrastructure supporting the cache becomes impaired. This meant that, on rare occasions, writes might flow through one part of cache infrastructure while reads end up querying another. This was the primary source of S3’s eventual consistency.

如果要解決 Eventually Consistent,最直接的想法是拔掉 cache,但這樣對效能的影響太大,所以得在要保留 cache 的情況下設計,所以就想到用其他管道確保 cache 裡的資料狀態是正確的:

One early consideration for delivering strong consistency was to bypass our caching infrastructure and send requests directly to the persistence layer. But this wouldn’t meet our bar for no tradeoffs on performance. We needed to keep the cache. To keep values properly synchronized across cores, CPUs implement cache coherence protocols. And that’s what we needed here: a cache coherence protocol for our metadata caches that allowed strong consistency for all requests.

而接下來是設計一連串的邏輯確保每個 S3 object 的操作都有 serializability:

We had introduced new replication logic into our persistence tier that acts as a building block for our at-least-once event notification delivery system and our Replication Time Control feature. This new replication logic allows us to reason about the “order of operations” per-object in S3. This is the core piece of our cache coherency protocol.

後面又要確保這個 cache coherence 的 HA,最後要能夠驗證實做上的正確性,花的力氣比實做協定本身還多:

These verification techniques were a lot of work. They were more work, in fact, than the actual implementation itself. But we put this rigor into the design and implementation of S3’s strong consistency because that is what our customers need.

Amazon S3 算是 AWS 當初推出來的招牌,當時的 Amazon S3 底層的論文「Amazon's Dynamo」劇烈影響了後來整個產業 (雖然論文裡面是拿 Amazon 的購物車說明),這次的補充算是更新了原來論文的技術,告訴大家本來的 Eventually Consistent 是可以再拉到 Strongly Consistent。

GitHub 宣佈在 github.io 上抵制 FLoC

GitHub 的公告簡單明瞭,也不用你操作,直接在 github.io 上抵制 FLoC:「GitHub Pages: Permissions-Policy: interest-cohort=() Header added to all pages sites」,在「[Feature request] Set HTTP header to opt out of FLoC in GitHub Pages」這邊有些討論,另外在 Hacker News 上的討論也可以看一下:「GitHub blocks FLoC across all of GitHub Pages (github.blog)」。

不過不確定為什麼 custom domain 的就不加上去,可能微軟內部的法務團隊討論出來的結果?

All GitHub Pages sites served from the github.io domain will now have a Permissions-Policy: interest-cohort=() header set.

Pages sites using a custom domain will not be impacted.

Amazon EC2 的 t3/t3a/t4g 的 CPU credit 保留七天的限制

Twitter 上看到朋友提到 t3 系列的機器有保留七天的 CPU credit:

在「CPU credits and baseline utilization for burstable performance instances」這邊有提到,t3/t3a/t4g 的設計都是讓你可以塞 24h 小時的量:

這邊講的七天是這段:

CPU credits on a running instance do not expire.

For T2, the CPU credit balance does not persist between instance stops and starts. If you stop a T2 instance, the instance loses all its accrued credits.

For T3 and T4g, the CPU credit balance persists for seven days after an instance stops and the credits are lost thereafter. If you start the instance within seven days, no credits are lost.

開著的機器的 CPU credit 不會過期,只會到最大上限 (在同一篇文件裡面的表格有提到),t2 的機器關掉後 (stop) CPU credit 就會直接消失,而 t3/t3a/t4g 則在關掉後會保留七天。

之前沒注意到文件上的這點。

另外之前在測試自己架設 Sentry 時還測過 t3a.medium -> r5a.large -> t3a.medium 這樣換過去又換回來的情況,本來的 CPU credit 是可以繼續用的,看起來 CPU credit 不會因為 family type 改變就不見 (不過不確定這個是不是 undefined behavior...)。

試用 Cloudflare 的 Argo Tunnel

Cloudflare 宣佈讓大家免費使用 Argo Tunnel 了,也順便改名為 Cloudflare Tunnel 了:「A Boring Announcement: Free Tunnels for Everyone」。

Starting today, we’re excited to announce that any organization can use the secure, outbound-only connection feature of the product at no cost. You can still add the paid Argo Smart Routing feature to accelerate traffic.

As part of that change (and to reduce confusion), we’re also renaming the product to Cloudflare Tunnel. To get started, sign up today.

Cloudflare Tunnel 的功能就像 ngrok,在用戶端的機器上跑一隻 agent 連到 Cloudflare 或是 ngrok 的伺服器,這樣外部連到 Cloudflare 或是 ngrok 的伺服器後就可以透過這組預先建好的連線連上本機的服務了,常見的應用當然就是 HTTP(S) server。

本來是付費功能,一般使用者應該也不會需要這個功能,這次把這個功能免費丟出來的用意不知道是什麼...

不過既然都免費了,還是花了點時間測了一下,可以發現 ngrok 的設定比較簡單,Cloudflare 的 cloudflared 設定起來複雜不少,不過文件還算清楚,照著設就好。

Anyway,有些事情有了 Cloudflare Tunnel 就更方便了,像是有些超小型的 VPS 是共用 IPv4 address 而且沒有 IPv6 address 的,可以透過 cloudflared 反向打進去提供服務,同樣的,在 NAT 後面的機器也可以透過這個方法很簡單的打通。

順便說一下,現在的 blog.gslin.org 就是跑在 cloudflared 上面了,官方提供的 ARM64 binary 跑在 EC2t4g 上面目前看起來沒有什麼問題,而且比起本來 nginx 都是抓到 Cloudflare 本身的 IP,現在加上這兩行後反而就可以抓到真的使用者 IP address 了:

    set_real_ip_from 127.0.0.1;
    real_ip_header X-Forwarded-For;

跑一陣子看看效果如何...

AWS 對 Elasticsearch 的戰爭:OpenSearch

AWSElasticsearch 的戰爭繼續升溫,AWS 出來喊,搞了自己的 community 要跟本家 PK:「Introducing OpenSearch」,衍生出來的兩套軟體分別是 OpenSearch (對應 Elasticsearch) 與 OpenSearch Dashboards (對應 Kibana)。

Hacker News 上的討論「OpenSearch: AWS fork of Elasticsearch and Kibana (amazon.com)」裡面有些討論還蠻精彩的,其中這段:

One thing which surprised me: Elastic has a market capitalization of ~$11B.

I think that changes some of the more floaty ethical concerns. This is not a David vs Goliath situation. This is Goliath vs Super-Goliath.

雖然就公司市值比例來看,大約是 100:1 這個數量級的公司在打架 (AWS 的母單位 Amazon 大約在 USD$1T 的等級),但這其實這不是小蝦米被大鯨魚欺負的故事,而是大公司跟暴力超大公司之間的打架。

會怎麼演變其實猜不出來,但因為在 open source search engine 技術這塊的確缺乏其他像樣的競爭者,AWS 這樣丟資源進來未必是件壞事。

另外一方面,這件事情對商業公司在在 open source 的其他領域則是比較負面,很明顯的 Amazon 這樣玩對於其他以 open source 為基礎的商業公司處境就更嚴峻了。

Amazon EC2 Auto Scaling 支援 Warm Pools

EC2 推出的新功能:「Amazon EC2 Auto Scaling introduces Warm Pools to accelerate scale out while saving money」。

重點只有這個,這個作法是先把機器準備好,然後關掉放在 stopped 狀態:

Additionally, Warm Pools offer a way to save compute costs by placing pre-initialized instances in a stopped state.

理論上可以快到 30 秒:

Now, these applications can start pre-initialized, stopped instances to serve traffic in as low as 30 seconds.

不過考慮到就算是 stopped 的機器,啟動時還是得去確認有沒有新版程式... 目前可以理解的部份,應該是加快 EBS 的準備時間吧?

架了一台 News Server

前陣子跟朋友聊天的時候,才想到好像沒有公開提這件事情...

學術網路上的 news server 似乎都掛差不多了,就花了一些時間用 INN 架了一台 news server,然後找了兩個 peering 對接,給自己的 BBS 站台用:「newsfeed.hasname.com」。

一般目前比較常用的是 news.aioe.org,不過有限制每天最多只能發 40 則:

In order to avoid mass abuses, every IP address is authorized to post no more than 40 messages per day.

有架設 BBS 站又想要弄轉信的朋友可以來戳一下,需要有固定 IP address 就是了。

Amazon EC2 提供跨區直接複製 AMI (Image) 的功能

Amazon EC2AMI 可以跨區複製了:「Amazon EC2 now allows you to copy Amazon Machine Images across AWS GovCloud, AWS China and other AWS Regions」。

如同公告提到的,在這個功能出來以前,想要產生一樣的 image 得重新在 build 一份:

Previously, to copy AMIs across these AWS regions, you had to rebuild the AMI in each of them. These partitions enabled data isolation but often made this copy process complex, time-consuming and expensive.

有一些限制,image 大小必須在 1TB 以下,另外需要存到 S3 上,不過這些限制應該是還好:

This feature provides a packaged format that allows AMIs of size 1TB or less to be stored in AWS Simple Storage Service (S3) and later moved to any other region.

然後目前只有透過 cli 操作的方式,或是直接用 SDK 呼叫 API,看起來 web console 還沒提供:

This functionality is available through the AWS Command Line Interface (AWS CLI) and the AWS Software Development Kit (AWS SDK). To learn more about copying AMIs across these partitions, please refer to the documentation.

GitHub 的 API Token 換格式

GitHub 前幾天宣佈更換 API token 的格式:「Authentication token format updates are generally available」,在今年三月初的時候有先公告要換:「Authentication token format updates」。

另外昨天也解釋了換成這樣的優點:「Behind GitHub’s new authentication token formats」。

首先是 token 的字元集合變大了:

The character set changed from [a-f0-9] to [A-Za-z0-9_]

另外是增加了 prefix 直接指出是什麼種類的 token:

The format now includes a prefix for each token type:

  • ghp_ for Personal Access Tokens
  • gho_ for OAuth Access tokens
  • ghu_ for GitHub App user-to-server tokens
  • ghs_ for GitHub App server-to-server tokens
  • ghr_ for GitHub App refresh tokens

另外官方目前先不會改變 token 長度 (透過字元變多增加 entropy),但未來有打算要增加:

The length of our tokens is remaining the same for now. However, GitHub tokens will likely increase in length in future updates, so integrators should plan to support tokens up to 255 characters after June 1, 2021.

看起來當初當作 hex string 而轉成 binary 會有問題,不過就算這樣做應該也是轉的回來的。

回到好處的部份,這個作法跟 SlackStripe 類似,讓開發者或是管理者更容易辨識 token 的類型:

As we see across the industry from companies like Slack and Stripe, token prefixes are a clear way to make tokens identifiable. We are including specific 3 letter prefixes to represent each token, starting with a company signifier, gh, and the first letter of the token type.

另外這也讓 secret scanning 的準確度更高,本來是 40 bytes 的 hex string,有機會撞到程式碼內的 SHA-1 string:

Many of our old authentication token formats are hex-encoded 40 character strings that are indistinguishable from other encoded data like SHA hashes. These have several limitations, such as inefficient or even inaccurate detection of compromised tokens for our secret scanning feature.

另外官方也建議現有的 token 換成新的格式,這樣如果真的發生洩漏,可以透過 secret scanning 偵測並通知:

We strongly encourage you to reset any personal access tokens and OAuth tokens you have. These improvements help secret scanning detection and will help you mitigate any risk to compromised tokens.

AWS 推出 Amazon Route 53 Resolver DNS Firewall

長久以來的洞總算有比較好的方法補上了,AWS 推出了 Amazon Route 53 Resolver DNS Firewall:「Introducing Amazon Route 53 Resolver DNS Firewall」。

Route 53 Resolver 是 AWS 官方提供的 DNS Resolver,沒有特殊的設定的話通常會在 x.x.x.2 (/24 或是更大的網段),先前一直沒有辦法解決 data leak 的問題,也就是透過 DNS 把敏感資料從 private network 裡丟出去。

以前的作法是透過 security group 擋掉對 Route 53 Resolver 的流量 (或是透過 VPC 的 Firewall 擋),然後自己架設兩台 DNS resolver 過濾,現在 Route 53 Resolver 支援 DNS Firewall,提供 allowlist 與 blocklist 這兩個功能使用,總算是把這件事情解的比較乾淨了:

Route 53 Resolver DNS Firewall lets you create “blocklists” for domains you don’t want your VPC resources to communicate with via DNS. You can also take a stricter, “walled-garden” approach by creating “allowlists” that permit outbound DNS queries only to domains you specify. You can also create alerts for when outbound DNS queries match certain firewall rules, allowing you to test your rules before deploying for production traffic.

另外這次的 DNS Firwall 提供了兩組由 AWS 維護的清單讓人使用,包括了 malware 與 botnet:

Route 53 Resolver DNS Firewall offers two managed domain lists—malware domains and botnet command and control domains—enabling you to get started quickly with managed protections against common threats.

這樣省事多了...