jQuery 官方在 2014 年的概況

在「jQuery Foundation 2014 Annual Report」這篇裡面有提到了 jQuery 在 2014 年的情況,其中 code.jquery.com 使用的頻寬這段還蠻有趣的:

If you need evidence that jQuery Foundation projects are used everywhere, look no further than our Content Delivery Network (CDN) powered by MaxCDN. The 290 billion requests in 2014 transferred nearly 11 petabytes of data. That, of course, does not include the requests for locally hosted copies of jQuery and to other CDNs such as Google, Microsoft, or CDNJS. No doubt the overall number of requests is in the trillions.

光是 code.jquery.com 每天的量平均就是 30TB,也就是平均流量 3Gbps?如果考慮到 Google 提供的平台更普及...

AWS Config 多支援三區...

AWS Config 是個稽核類的產品,把所有的操作行為記錄下來,供事後查詢,一開始只有最早的 us-east-1 有,而剛剛公佈了多支援 us-west-2、eu-west-1、ap-southeast-2 這三區:

Today we are adding support for the US West (Oregon), Europe (Ireland), and Asia Pacific (Sydney) regions, with support for others also on the drawing board.

不知道為什麼是這三區先上...

用 Amazon EC2 的 GPU instance 計算 MD5 collision

在「Create your own MD5 collisions」這篇教你用 Amazon EC2 的 GPU instance 計算 MD5 collision。

由於不是什麼正式的服務,文章裡介紹你用 Spot instance 開機器,會便宜不少。可以看到最後的結果:

在文後也把兩張圖都附上來讓大家確認,抓下來後也可以確認:

gslin@GSLIN-DESKTOP [~/tmp] [13:16/W3] md5sum *.jpg
253dd04e87492e4fc3471de5e776bc3d  plane.jpg
253dd04e87492e4fc3471de5e776bc3d  ship.jpg

屬於 chosen prefix collision 的攻擊。

Amazon 跨足 Email 市場

大清早就看到「Amazon WorkMail – Managed Email and Calendaring in the AWS Cloud」這個消息。

Amazon WorkMail 的價位是 USD$4/user (50GB 空間),包括了 mail 與 calendar 的功能:

或是加上 Amazon WorkDocs,需要 USD$6/user。

翻了一下 Google Apps for Work,是 USD$6/user (30GB 空間) 以及 USD$10/user (進階功能,加上無限空間)。

不過目前只支援 us-east-1 與 eu-west-1 兩個區域,而且是 Preview 狀態 (表示需要填單申請)。也許先測看看,好用的話就來等 ap-northeast-1?

DynamoDB 的 Online Indexing 與 Reserved Capacity

剛剛看到 DynamoDB 的新功能以及購買 Reserved Capacity 的計費模式:「Amazon DynamoDB Update – Online Indexing & Reserved Capacity Improvements」。

可以動態增加 Global Secondary Indexes 有點像是「總算可以 ALTER TABLE 了!!!」的感覺 XDDD

而 Reserved Capacity 好像是第一次把 Capacity 類的費用 commit 化?我記得 EBS 沒有這種計費...

昨天 (2015/01/27) 在高雄 K Square 的投影片

主題「KKBOX Innovation Chat #5 - 利用AWS開發及實作新創公司的基礎資訊建設」的投影片:(Startup IT infrastructure: Developing and Working with AWS)

在準備之前有問了 ericpi (主辦),主要是以 engineer 為主,然後次多的是學生。所以主題上偏技術一點。

而因為主題是 for startup,所以注重的方向與一般公司不太一樣。在舉例上面,主要是以 KKTIX 以及猜猜巧克力為主,對於 KKBOX 的著墨比較少。

現場 Q&A 很踴躍,用了不少時間在 Q&A 上,結果講完跟 ericpi 去吃飯時差點睡在餐桌上,回到家確認沒有緊急的事情就倒下去睡死了。

另外對不起現場聽眾的... 記得講到後面有點累,會發現講到一半「咦,這句中文怪怪的」,就重新再說一次,但好像還是怪怪的... (這代表應該有漏掉沒發現的部份)

對付最近 HiNet 到 CloudFlare 不穩定的情況

解法是透過 proxy.hinet.net:80 的 Proxy 服務避開,利用 Proxy 的 IP 出國優先權比較高至少能通。下面說明一下原因。

這可以解決不少網站不順的問題,像是 Stack Overflow 有用到 CloudFlare 的服務。

可以看一般家用的 IP 去 ping (2015/01/22 00:31):

--- www.cloudflare.com.cdn.cloudflare.net ping statistics ---
101 packets transmitted, 63 received, 37% packet loss, time 104589ms
rtt min/avg/max/mdev = 88.208/131.391/227.889/45.322 ms

即使是這個時間,CloudFlare 的品質仍然是爛到爆炸。

另外看這兩張圖,這是在 HiNet 機房端對 www.cloudflare.com.cdn.cloudflare.net 這個網域的 ICMP ping 的 latency 與 packet loss 記錄:

這是機房端的 IP 監控的資料,可以看到 latency 會飄高,但至少將 packet loss 維持在一定程度以下。這也是為什麼 proxy.hinet.net:80 可以避開這個問題。

另外我利用 HiNet 所配發的 PPPoE static IP 測試,也可以避開這個問題,所以 IP 分享器撥號時使用 PPPoE static IP 的方式也可以避開。

Amazon EC2 的 Auto Recovery

2015/01/12 先前在「Amazon EC2 Auto Recovery now available in the US East (N. Virginia) Region」這邊發表了,不過剛剛在「New – Auto Recovery for Amazon EC2」這邊看到消息。

重點在於偵測到問題時會重開機,並且保持原來的 instance id、IP address、Elastic IP address、EBS 以及其他外部設定:

The instance will be rebooted (on new hardware if necessary) but will retain its Instance Id, IP Address, Elastic IP Addresses, EBS Volume attachments, and other configuration details.

而被限制在比較新的硬體上,並且目前只有 us-east-1 有:

This feature is currently available for the C3, C4, M3, R3, and T2 instance types running in the US East (Northern Virginia) region; we plan to make it available in other regions as quickly as possible.

當時看到就覺得很實用了,後來在建立一些底層的 infrastructure 時,覺得其他區沒這功能頗難處理。有在 us-east-1 放機器的人可以測試看看。

建立 Amazon VPC 的 High Availability NAT 架構

Amazon VPC 的架構裡最讓人碎碎唸的一個架構:NAT instance。

Amazon VPC 分成 Public Network 與 Private Network。

前者的 Public Network,裡面的機器除了會有 Private IP 外,需要申請 Public IP (可以是隨機分配,也可以是 Elastic IP) 透過 Intenet Gateway (沒有 NAT 功能) 連外,這邊問題比較小,因為 Routing Table 設一下就好了,High Availability 以及 Scalablility 的問題 AWS 會自己解決掉。

後者 Private Network 因為需要自己架設 NAT instance,所以要自己處理 High Availability 以及 Scalability 問題,由於把機器丟在後面,前面用 ELB 是蠻常見的架構,AWS 一直沒推出 NAT service 讓人感覺很疑惑...

目前一般在處理 Private Network 的 HA NAT 架構是參考「High Availability for Amazon VPC NAT Instances: An Example」這篇文章,但這篇文章的作法有點複雜。

我可以接受有一些 downtime 時間以及一些小狀況,相對的,我想要換取極低的管理成本。

研究了一陣子,最後決定的作法是受到「An Alternative Approach to “HA” NAT on AWS」這篇的啟發,這篇也只講了很簡單的概念,實際上還是要自己研究。

目前是做在 us-west-2 (Oregon) 的 1b 與 1c 兩個 AZ 上。下面討論時就不說明這點了。

規劃的想法是 1b 與 1c 兩個 AZ 各建立一個 auto scaling group,透過 auto scaling 各跑一台 NAT instance 處理自己 AZ 的 NAT traffic (所以不是手動跑)。然後我不想要自己建 image 寫太多 hard code 進去,最好是現成的用一用就好 XD

所以有幾個重點:

  • NAT instance 拿現成的 amzn-ami-vpc-nat 使用,寫這篇文章時是用 2014.09 版。
  • 由於官方的 NAT instance 支援 userdata 在開機時執行指令,所以完全透過 userdata 指定需要的做動就好。
  • 由於 Amazon 官方給的 instance 有 aws 這隻工具 (aws-cli),而這隻工具在有掛上 IAM Role 時會去 http://169.254.169.254/ 上取得對應的 IAM Role 權限,所以都不需要寫太多 hard code 的東西進去。

機器開起來以後希望做幾件事情:

  • 把自己的 Source/Destination IP check 關閉。
  • 把傳進來的 Route Table 的 0.0.0.0/8 設成自己。這邊需要傳進來是由於 NAT instance 是跑在 Public Network 裡,我不會知道要改哪個 Route Table。

所以就有兩個重點,一個是 userdata,其中粗體是要修改的 route table id:

#!/bin/bash
ROUTE_TABLE_ID=rtb-1a2b3c4d
INSTANCE_ID=$(curl http://169.254.169.254/latest/meta-data/instance-id)
aws ec2 modify-instance-attribute \
    --region us-west-2 \
    --instance-id "${INSTANCE_ID}" \
    --no-source-dest-check
aws ec2 replace-route \
    --region us-west-2 \
    --route-table-id "${ROUTE_TABLE_ID}" \
    --destination-cidr-block 0.0.0.0/0 \
    --instance-id "${INSTANCE_ID}" || \
aws ec2 create-route \
    --region us-west-2 \
    --route-table-id "${ROUTE_TABLE_ID}" \
    --destination-cidr-block 0.0.0.0/0 \
    --instance-id "${INSTANCE_ID}"

最前面事先抓 instance_id,然後修改 Source/Destination 檢查,最後面的指令是先試著 ReplaceRoute,如果失敗就 CreateRoute (注意到 shell 的 || 操作)。

另外的重點是 IAM Role,這台機器對應的 IAM Role 權限要開三個:

{
  "Statement": [
    {
      "Action": [
        "ec2:CreateRoute",
        "ec2:ReplaceRoute",
        "ec2:ModifyInstanceAttribute"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

拿 t2.medium 測試,burst 可以到 200Mbps 左右,應該還算夠用?反正不夠用就自己挑其他機器開吧 XD

最後討論一下 Availability 的情況。這樣的架構可能會有七八分鐘的 downtime,也就是當 instance 掛了,被 auto scaling 重新拉一台新的起來。這邊不做 cross-zone NAT 是因為這樣比較簡單,這邊的 downtime 我還可以接受。

至於某個 zone 掛掉,應該 cross-zone NAT 趕快導到另外一區的問題... 整個 zone 都滅了就沒有這個問題啊 XDDD