Tag: latency

Amazon S3 推出加速功能

Amazon S3 推出了新的加速功能，並且向更多地區提供 AWS Import/Export Snowball 服務：「AWS Storage Update – Amazon S3 Transfer Acceleration + Larger Snowballs in More Regions」。

其中的 Amazon S3 Transfer Acceleration 只要把本來的 BUCKET_NAME.s3.amazonaws.com 或是帶有地區的 BUCKET_NAME.s3-region.amazonaws.com 變成 BUCKET_NAME.s3-accelerate.amazonaws.com 就可以了，他會透過 CloudFront 的節點做 proxy，並且透過 AWS 內部最佳化過的網路傳輸。

由於這是定位為 Amazon S3 的服務，而實際測試後也確認不會有 cache：他的目的在於降低 latency 而加速，而不是 cache 加速，所以大量 GET 相同內容的部份應該還是用 CloudFront 會比較好。

再來是費用的部份增加相當多，第一筆要收的是 CloudFront 的費用，再來才是計算 Transfer Acceleration 的費用：

Transfer Acceleration pricing is in addition to Data Transfer pricing.

從 Internet 進 CloudFront 再進 Amazon S3 的要收 USD$0.04/GB (透過在美國、歐洲或是日本的 CloudFront 節點) 或 USD$0.08/GB (透過其他 CloudFront 節點)。

另外要收的是從 Amazon S3 一路傳到 Internet 的部份，USD$0.04/GB。如果是傳到其他 AWS region 的話，也是 USD$0.04/GB。

不過他有效能保證條款 (雖然掌控全不在自己)，AWS 會持續監控有沒有比較快，如果沒有的話系統會 bypass 回原來的 Amazon S3：

Each time you use Transfer Acceleration to upload an object, we will check whether Transfer Acceleration is likely to be faster than a regular Amazon S3 transfer. If we determine that Transfer Acceleration is not likely to be faster than a regular Amazon S3 transfer of the same object to the same destination AWS region, we will not charge for that use of Transfer Acceleration for that transfer, and may bypass the Transfer Acceleration system for that upload.

我本來以為會是在 DNS 層 bypass 回本來的 region，結果發現是 307 redirect 重導回 Amazon S3 上，效能上應該還是會差一些...

可以看出這個架構的特性主要還是用在上傳的部份，而且用在網路不穩定的環境下很重要 (像是電信網路上的行動裝置)，因為 latency 的減少會對於 packet loss 造成的 retry 有很大的幫助。

下載的部份應該會比本來 Amazon S3 快 (因為 Amazon 本身會加速)，但由於沒有 cache，除非有特殊需求，不然建議不要這樣規劃。

另外一個是 AWS Import/Export Snowball 推出的新硬體，以及新區域。

新硬體是 80TB 的版本，本來只有 50TB 的版本：

The original Snowball appliances had a capacity of 50 terabytes. Today we are launching a newer appliance with 80 terabytes of capacity.

而新區域包括了 AWS GovCloud (US)、US West (Northern California)、Europe (Ireland) 以及 Asia Pacific (Sydney) 這三區：

Today we are making Snowball available in four new Regions: AWS GovCloud (US), US West (Northern California), Europe (Ireland), and Asia Pacific (Sydney). We expect to make Snowball available in the remaining AWS Regions in the coming year.

其中 80TB 版本只在這三區生效，其他區可以選擇 50TB 或是 80TB 版本：

If you are transferring data in or out of the US East (Northern Virginia), US West (Oregon), US West (Northern California), or AWS GovCloud (US) Regions using Snowball you can choose the desired capacity. If you are transferring data in or out of the Europe (Ireland) or Asia Pacific (Sydney) Regions, you will use the 80 terabyte appliance.

日本還是沒進場...

PCIe 的 SSD 與 SATA 的比較

LogicMonitor 的人比較了 PCIe SSD 與 SATA SSD，他們在意的重點是 read/write latency 非單純的 throughput：「Device Utilization of PCIe and SATA SSDs」。

文章裡講得很長，把他們找原因的過程寫出來，從 latency 的影響改變到 queue service 的變化：

後來換成 PCIe SSD 後 write latency 從 1.8ms 掉到 0.02ms 左右，大約是兩個零的差距。

另外文章裡也提到了 fio 這個測試工具，找時間來測試看看，熟悉一下...

nginx 的 TCP Fast Open

在「Enabling TCP Fast Open for NGINX on CentOS 7」這邊看到 nginx 對 TCP Fast Open (TFO，RFC 7413) 的支援早在 1.5.8 就有了，而 Linux Kernel 也是 3.7 之後就全面支援了。

TCP Fast Open 利用第一次連線後產生的 TCP cookie，在第二次連線時可以在 3-way handshake 的過程就開始傳輸，藉此大幅降低 latency。

設定方法不難，先在 kernel 設定 net.ipv4.tcp_fastopen=3，再加上 fastopen=number 就可以了，像是這樣：

listen 80 fastopen=256

不過目前 NGINX Mainline 上的版本好像沒有編進去，暫時沒辦法測...

ScyllaDB：用 C++ 改寫相容於 Cassandra 的系統

Scylla 是出自希臘神話，維基百科對應的連結：「斯庫拉」、「Scylla」。而在 ScyllaDB 官網副標題寫著：

Fully compatible with Apache Cassandra at 10x the throughput and jaw dropping low latency

JVM 的 GC 老問題在 Cassandra 中帶來的 latency 不穩定本來就是個痛苦的問題，要花很多力氣去調整，而用 C++ 改寫等於是自己處理這一塊。

這帶來的效能提昇可以從各種測試結果看出來，像是單機的測試：「Scylla vs. Cassandra benchmark」，以及多機的測試：「Scylla vs. Cassandra benchmark (cluster)」(可以參考下圖)。

而 Latency 的改善也是極為明顯：「Latency benchmark」。

其中另外一個重要的技術是 Intel 的 DPDK，可以大幅降低現有 Linux Kernel 在網路架構上的損耗：「Dedicated fast network stack for modern hardware」。

很有趣的專案，好久沒碰 Cassandra 了...

在 LAN 裡把 TCP timestamps 關閉擠出頻寬

由於 TCP timestamps 會使得封包多 12 bytes，關掉後可以在 LAN 裡面擠出頻寬，是個小孩子不要亂學的方法：「Save Some Bandwidth By Turning Off TCP Timestamps」。

文章裡是在 10Gbps 網路上測試，看測出來的圖片也只是一點點 (不到 1%)，但仍然是有提昇：

Results show that it's reasonable to turn off timestamps on 10GE interfaces, but keep in mind that it should be performed only in low latency networks.

沒必要就不要亂動 :o

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 Storage 中 Nearline 的想法，一樣有存取另外收費的項目。不過 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.

所以也因此可以看到 CacheFly 與 CloudFlare 兩家採用 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 寫的前端管理界面，實際運作還是透過 Linux 的 iptables。

也有提供 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...