AWS 東京第二個 AZ (Availability Zone) 今天啟用...

開張不到一個月的 AWS Japan 今天宣佈啟用第二個 Availability Zone:「Adding a Second AWS Availability Zone in Tokyo」,第一個 AZ 是在 2011/03/02 宣佈啟用:「Amazon Web Services 東京!」。

好快的速度... 是因為全世界對亞洲的需求嗎?

AWS RDS 的 INSERT 效能...

PerconaBaron SchwartzAWS RDS 能提供最大台的 database (68GB memory + 26 ECUs) 上測試 insert 的效能:「MySQL on Amazon RDS part 1: insert performance

數字是 Per Minute,換算成常用的 Per Second 要記得除以 60。大約是 4k~5k 40k~50k queries/sec 的數量。這個效能不知道能不能算「好」...

Amazon Web Services 東京!

AWS Japan

AWS 公告了對日本的 Support:「Announcing AWS Support in Japanese」,並公告了新增東京的 Region:「Announcing the AWS Asia Pacific (Tokyo) Region」。另外「Amazon Web Services (日本語)」的網頁也同步啟用。

相較於之前的新加坡 Region,主要是對南亞與印度地區的幫助比較明顯,日本與韓國到新加坡與美西比起來並沒有太大差異。但這次在日本設點後,AWS 在亞洲的強度就好很多...

品質的部份就要繼續觀察了。另外,不論是頻寬還是租用 EC2 的價位上都比新加坡再貴了一些,不過都還是可以接受的程度,可以觀察日韓兩國的 VPS 被衝擊的狀況...

AWS API 的認證方式

Amazon Web Services 有提供很多服務,有的早在「雲端風潮」前就有,有的是最近才推出的。把 AWS Documentation library 每個服務的 API 認證方式看完一遍後,只能苦笑對使用 AWS API 的人致敬...

有幾個心得與感想:

  • 文件雖然套用同一組模板 (用 frame 切開,左邊索引,右邊內容),但其中的寫法並沒有統一。理論上每個 API 都會有的 API 簽名環節在不同的文件裡可能會在不同的章節出現。
  • 認證的方式不一致:
    • 早期的服務很亂,大多都是以 SOAP 為基礎的 API,尤其是跟錢有關的這塊特別明顯 (因為 Amazon 很早就 API 化)。
    • 一開始出來的 S3 使用的是 REST 概念,簽名的值放在 HTTP Header 內,欄位名稱是 AuthorizationCloudFront 是 S3 的延伸,所以認證方式與 S3 相同。
    • 但與 S3 同時期推出的 EC2,以及後來大多數的服務,都是以 GET 為基礎。這時候兩套系統的 API 設計邏輯就不同了。
    • 最近出的 Route53,又再引入了 REST 概念,但欄位名稱為 X-Amzn-Authorization,要放的簽名格式又改變了...

這也是為什麼沒有一套 library 可以一直吃遍 AWS 服務的關係,API 的設計讓人感覺頗疲倦... XD

AWS 的 Elastic Beanstalk...

這相當於 Amazon 跳下來自己做 Java 版的 Heroku:「AWS Elastic Beanstalk: A Quick and Simple Way into the Cloud」(CTO Werner Vogels 的文章)、「Introducing AWS Elastic Beanstalk」。將整套 Amazon Web Services 的技術整合起來,變成 PaaS:「AWS Elastic Beanstalk」。

由於是 Java,所以用 Java 實做的 PHP5 又被拿出來玩了:「PHP on AWS Elastic Beanstalk」:

在 Google Search 上面可以看到一些站台了:

分析 Y Combinator 的 Startup 所使用的服務...

在 HN (Hacker News) 上看到的分析資料 (文章是 ReadWriteWeb 的):「The Services Used By Y Combinator Startups [Infographic]」,文章裡面分析了 Y Combinator「旗下」的 startup 所使用的服務。

統計資料在「Y Combinator」這邊,另外有「Quantcast Top 100」的資料也可以看看,這邊就不提 Quantcast Top 100 的情況了。

網站主機的部份,可以看到是 Amazon Web ServicesRackspace Cloud 兩家雲端服務最大,如果把同屬於 Rackspace 下的 Slicehost 一起併進去算的話就幾乎相同了。不過自己 hosting 的部份也不少...

E-mail 服務的部份以 Google Apps 過半,接下來就是自己 hosting。畢竟 Gmail 真的太好用...

DNS hosting 的部份最大一塊是自己 hosting,而 GoDaddy 有一定的比率倒是沒什麼意外... 而 DNS registrar 的部份當然是 GoDaddy 過半 XD

接近一半的 startup 沒有 SSL,如果有的大多數也都是跟 GoDaddy 買。然後有不少人是買 Wildcard SSL Certificate...

不過還是要講,重點在於挑自己熟悉而且穩定的技術,並不是用了雲端就什麼都不用學。

Amazon Web Services 成長的一些故事...

Quora 上有人提問 Amazon 為什麼會作雲端計算,也就是「Amazon Web Services」這項服務:「How and why did Amazon get into the cloud computing business?」。

然後大魚就上鉤了,Amazon 的技術長 Werner Vogels 親自回答這個問題... 後面那段提到了本來沒有預期會有這麼大的量,而 AWS 所使用的量在公開兩個月後就超過 Amazon.com 本身,於是雲端神話就此開始...

EC2 上的 FreeBSD 8.2-RC1...

Colin Percival 前陣子公佈了 EC2 上跑 FreeBSD 9.0-CURRENT 的 ami,當時測試覺得太慢了:「在 AWS EC2 上跑 FreeBSD」,昨天他在 Twitter 上提到把 FreeBSD 8.2-RC1 也 porting 上去了

FreeBSD 8.2-RC1 is now available on EC2 as ami-d29b6abb. http://www.daemonology.net/freebsd-on-ec2/ #merrychristmas

實際測試以後發現 8.2-RC1 還是很慢,跑 portsnap fetch 要等半個小時,跑 portsnap extract 也要再等半個小時,看起來是因為 EBS 的速度太慢?如果是這樣的話就得等非 t1.micro 的版本了 (因為 t1.micro 只能用 EBS 跑)。

以目前進度來看,8.2-RELEASE 會是第一個支援 EC2 的 production 版本?

在 AWS EC2 上跑 FreeBSD

Amazon Web Services 的官方網誌上提到了 Colin PercivalFreeBSD 9-CURRENT 放到 AWS EC2 上跑:「FreeBSD on Amazon EC2」。他的網誌也提到這件事情了:「Announcing FreeBSD on EC2」,計畫的頁面在:「FreeBSD on EC2 status」。

花了幾個小時玩,發現用 t1.micro 跑 9-CURRENT 的速度真是太慢了。就算考慮到 9-CURRENT 裡面有很多 debugging code,不過這個速度實在沒辦法測什麼東西... 在乾淨的系統裡編 mtr (WITHOUT_X11=yes) 編一個小時編不完啊 XD

等 backport 回 8-STABLE 後再來玩一次看看吧...

VM Import:把 VMware Image 直接丟到 AWS EC2 上面跑...

又是一個邪惡的功能,直接把 VMwareVMDK 檔丟上 AWS EC2 上跑:「VM Import - Bring Your VMware Images to The Cloud」。

這個服務不另外收費,僅就 S3EBS 與 data transfer 的費用收費而已,不過公告裡提到目前只支援 Windows Server 2008 SP2:

You can start importing 32 and 64 bit Windows Server 2008 SP2 images right now (we support the Standard, Enterprise, and Datacenter editions).