Amazon S3 推出新的種類:Standard - Infrequent Access Storage

Amazon S3 推出了新的種類:「AWS Storage Update – New Lower Cost S3 Storage Option & Glacier Price Reduction」。

原先只有「Standard」、「Reduced Redundancy Storage」以及「Glacier Storage」三種,現在多了一種「Standard - Infrequent Access Storage」。

首先是計價模式,儲存的單價變便宜很多,但存取是要另外收錢的:

$0.0125 / gigabyte / month (one and one-quarter US pennies), with a 30 day minimum storage duration for billing, and a $0.01 / gigabyte charge for retrieval (in addition to the usual data transfer and request charges).

拉資料的費用相當的貴啊一個月拉兩次就超過 Standard Storage 的價錢了,所以這個「Infrequent」的要求其實頗嚴苛的...

另外空間的部份以 128KB 為最小單位在計價的:

Further, for billing purposes, objects that are smaller than 128 kilobytes are charged for 128 kilobytes of storage.

所以綜合起來看,Infrequent Access Storage 的設計上是拿來堆資料備份,但希望拉資料時很快就可以拉出來。其實就是 Google Cloud StorageNearline 的想法,一樣有存取另外收費的項目。不過 Nearline 有說平均的 latency 是三秒:

但 IA 好像是跟 Standard 相同等級?至少文章裡沒有提到...

LinkedIn 的工程師分析 TCP Anycast 技術的穩定性與效能

LinkedIn 的工程師測試了 TCP Anycast 技術的穩定性以及效能:「TCP over IP Anycast - Pipe dream or Reality?」。

由於 stateless 再加上一個封包就傳的完的情況下,Anycast 技術被用在 DNS 上已經很長一段時間了,目前大多數 CDN 業者也都有用 Anycast 技術加快 CDN 的回應速度。

但 TCP 因為 stateful,如果 router 上採用的方式有問題,那麼就會導致封包可能會送到不同節點,這會是個嚴重的問題。不過很早之前,幾乎所有的骨幹 router 都已經支援 flow-based load balancing policy:

Most routers now do a per-flow load balancing, meaning packets on a TCP connection are always sent over the same path, but even a small percentage of routers with per-packet load balancing can cause the website to be unreachable for users behind that router.

所以 LinkedIn 的人試著測試 TCP Anycast 技術的穩定性:

So, to validate the assumption that TCP over anycast in the modern internet is no longer a problem, we ran a few synthetic tests.

測試的方式是設定 web server,讓下載速度不快,然後設了好幾個點並且放出對應的 routing,用 Catchpoint 服務監控,如果不穩定的話,應該就會收到 RST 中斷連線:

We configured our U.S. PoPs to announce an anycast IP address and then configured multiple agents in Catchpoint, a synthetic monitoring service, to download an object from that IP address. Our web servers were configured to deliberately send the response back slowly, taking over a minute for the complete data transfer. If the internet was unstable for TCP over anycast, we would observe continuous or intermittent failures when downloading the object. We would also observe TCP RSTs at the PoPs.

而好消息是,測試起來相當穩定:

But even after running these tests for a week, we did not notice any substantial instability problems! This gave us confidence to proceed further.

所以也因此可以看到 CacheFlyCloudFlare 兩家採用 TCP Anycast 技術:

[S]ome popular CDNs have also started using anycast for HTTP traffic.

由於穩定性的部份沒問題,所以接下來就是討論效率。

Anycast 是基於 routing 而決定要怎麼走,目標是希望可以透過 routing 取得 latency 最低的點。但實務上會把成本考慮進去,有可能會走到比較遠的點。在測試中可以發現北美的部份 Anycast 表現的比 GeoIP 好,但離開北美就掉很多:

所以 LinkedIn 決定用「Regional Anycast」,先用 GeoIP 決定要丟到哪個洲,而每個洲共用一個 Anycast 位置,這個方法讓效能提昇不少,全球在分配時 sub-optimal 的比率從 31% 降到 10% (i.e. 沒有分配到最好的點的比率):

上面主要是讀 LinkedIn 文章的心得,後面就是感想了。

TCP Anycast 用 CDN 上其實是相當吃虧的技術,由於 routing 的掌控權不再自己手上,有很多重要的手段是沒辦法做到的。

首先是當對外流量已經滿載時,不能切換到其他機房的機器,這邊講的「對外流量」不是 CDN 本身而已,而是中途任何的線路滿載都算,像是 HiNet 對 CloudFlare 香港機房的情況就很明顯。

另外在被 DDoS 時,由於沒辦法導流,在被攻擊時幾乎只剩下 clean pipe 類的解法,而同時間其他用戶會因為流量大量流入機房而一起被波及到。GeoIP 的方式彈性就大很多。

當然,還是有可以列出來的好處。主要是對於需要有固定 IP 應用來說 (像是 firewall 設定需求),TCP Anycast 滿足了這點。

只能說不同市場有不同的產品線在供應啦,不同的情境下有不同的需求...

Facebook 的「Augmented Traffic Control」模擬網路環境

Facebook 推出 Augmented Traffic Control,模擬網路環境:「Augmented Traffic Control: A tool to simulate network conditions」。

可以測這五種變數:

  • bandwidth
  • latency
  • packet loss
  • corrupted packets
  • packets ordering

Facebook 的成果是 Python + Django 寫的前端管理界面,實際運作還是透過 Linuxiptables

也有提供 Vagrant 的操作方式讓人「試用」,主要是讓人在本機上就可以用吧?

把 SSH 換成 Mosh

Mosh 是一個取代 SSH (OpenSSH) 的工具,官方網站上是這樣介紹:

Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.

Mosh 最大的特性是透過 UDP 加密傳輸 (AES-128 OCB mode),而且不綁定 IP address 後設計出這些特性:

  • 筆電休眠後再打開電腦就可以直接連上。
  • 登入 VPN 造成 IP 改變後也沒關係。

另外 Mosh 模擬了 local echo 機制,就算在 latency 偏高的網路下也還是可以感覺到不錯的反應速度。

不過是到了 1.2 之後支援 --ssh 這個參數才變得好用,在 client 端只要這樣跑 (假設 ssh port 在 1234):

mosh --ssh="ssh -p 1234 -v" gslin@server.example.com --server="env LANG=en_US.UTF-8 mosh-server"

Mosh 就會用 ssh 登入後自動執行 mosh-server 取得 shared key 給 mosh-client 用。如果本來就有使用 public key 機制的話就跟原來沒差了 :p

預設吃 port 60000-61000 其中的一個 UDP port,所以記得開 firewall...