AWS EC2/EBS 從星期四 21 日下午四點開始 (+8 時區)，到剛剛在「Service Health Dashboard」上看到宣佈恢復 (亮綠燈)，總共花了超過三天半的時間。有些人受到影響時間比較長，有些人比較短，我是在 24 號的凌晨恢復的，受到影響時間約兩天多。這幾天應該會有比較正式的說明...
手上本來沒打算這麼早設計 failover 機制的，現在都要拉到前面做了...
AWS EC2/EBS 用了三天半時間恢復...
Tag: cloud
這次的 AWS EC2/EBS 問題...
這次的 AWS EC2/EBS 問題讓很多站台掛掉 (可以看「Who is affected by EC2?」這個站台，在發文的現在 US-East 還是沒完全恢復)，但這次並不是每個使用 US-East 的站台都掛掉，像是 Netflix 因為一開始規劃就是「Cloud 也是會爛整片的」，所以服務並沒有中斷。在 Hacker News 上就有被提出來討論。
討論裡面也有投影片說明 Netflix 選 AWS 的原因是因為「來不及建立 Data Center」，但在建立時也同時注意到「Cloud 有可能會大規模爛掉」的情況而設計了很多機制防範：「Netflix in the cloud 2011」。
利用 AWS 在多個不同地點都有機房把架構在 AWS 上所能提供的 HA 機制發揮到極致，不過這是建立在「Cheaper than cost of being down」的想法上 (因為 Netflix 已經算是某類型的電子商務公司了)。
話說回來，繼續等美東機房恢復...
目前 AWS EC2 (美東機房) 出問題...
在 AWS 的「Service Health Dashboard」上可以看到美東機房從 PDT 1:41 AM (台灣時間是 4:41 PM) 開始介入，到現在五個多小時了...
下午本來要跑一堆東西，看起來得晚上做了，明天來凹一下老闆，下午再進公司好了... :o
Update：在 Service Health Dashboard 上面總算有初步的原因了：
8:54 AM PDT We'd like to provide additional color on what were working on right now (please note that we always know more and understand issues better after we fully recover and dive deep into the post mortem). A networking event early this morning triggered a large amount of re-mirroring of EBS volumes in US-EAST-1. This re-mirroring created a shortage of capacity in one of the US-EAST-1 Availability Zones, which impacted new EBS volume creation as well as the pace with which we could re-mirror and recover affected EBS volumes. Additionally, one of our internal control planes for EBS has become inundated such that it's difficult to create new EBS volumes and EBS backed instances. We are working as quickly as possible to add capacity to that one Availability Zone to speed up the re-mirroring, and working to restore the control plane issue. We're starting to see progress on these efforts, but are not there yet. We will continue to provide updates when we have them.
看起來還要再等等...
AWS 東京第二個 AZ (Availability Zone) 今天啟用...
開張不到一個月的 AWS Japan 今天宣佈啟用第二個 Availability Zone：「Adding a Second AWS Availability Zone in Tokyo」，第一個 AZ 是在 2011/03/02 宣佈啟用：「Amazon Web Services 東京！」。
好快的速度... 是因為全世界對亞洲的需求嗎？
Amazon Web Services 東京！
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 內，欄位名稱是
Authorization，CloudFront 是 S3 的延伸，所以認證方式與 S3 相同。 - 但與 S3 同時期推出的 EC2，以及後來大多數的服務，都是以
GET為基礎。這時候兩套系統的 API 設計邏輯就不同了。 - 最近出的 Route53，又再引入了 REST 概念，但欄位名稱為
X-Amzn-Authorization，要放的簽名格式又改變了...
這也是為什麼沒有一套 library 可以一直吃遍 AWS 服務的關係，API 的設計讓人感覺頗疲倦... XD
Google Apps 的 Uptime 計算方式調整 (對使用者有利的方向)
Google 改變了 Google Apps 對 Uptime 的計算方式：「Google Apps Removes Scheduled Downtime Clause From SLA; Gmail Had 99% Uptime in 2010」(TC)、「Destination: Dial Tone -- Getting Google Apps to 99.99%」(Google 官方新聞稿)。
之前的條款內允許 Google 將「排定的維護停機」排除在 downtime 計算外，現在 Google 決定拿掉這條例外條款。然後在文章下面故意提到 Microsoft 的服務：
Comparable data for Microsoft BPOS® is unavailable, though their service notifications show 113 incidents in 2010: 74 unplanned outages, and 33 days with planned downtime.
有興趣看新版 SLA 的人可以連結到英文版的頁面上：「Google Apps Service Level Agreement」。
PHP 的 Heroku
在「PHP Fog Raises $1.8 Million To Be The Heroku Of PHP」裡面提到兩家：PHP Fog 與 cloudControl。
兩者都是以 PHP 為底層語言基礎的平台。其中 PHP Fog 還沒開張，而 cloudControl 已經開張了，以歐洲的 EC2 為底層。
不過 cloudControl 選用 Bazaar 為版本管理系統，這點不知道是什麼考量... (PHP 是用 Subversion)
Windows Azure Platform 平台，其中 CDN 的部份的測試...
透過台灣微軟的幫忙，一個月前拿到了一組 Windows Azure Platform 的帳號測試，來寫一下感想好了。
在管理介面時會被提醒需要安裝 Sliverlight。沒有 Silverlight 的只能使用基本介面，同時也在登入時說明 2011 年初會把舊介面關閉：
抱歉，即使活動辦得很精彩，我還是沒興趣裝 Silverlight... 所以下面的測試都還是以基本版的測試為主。
能看的文件不多，而且要在登入後才能看 Help and Resources (這是 non-Silverlight 版本)
抓了 VSCloudServiceHelp.chm 後，打開來發現只有標題能看，每個章節都看不到內容：
實在是測不下去，收工...
分析 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 Services 與 Rackspace Cloud 兩家雲端服務最大，如果把同屬於 Rackspace 下的 Slicehost 一起併進去算的話就幾乎相同了。不過自己 hosting 的部份也不少...
E-mail 服務的部份以 Google Apps 過半，接下來就是自己 hosting。畢竟 Gmail 真的太好用...
DNS hosting 的部份最大一塊是自己 hosting，而 GoDaddy 有一定的比率倒是沒什麼意外... 而 DNS registrar 的部份當然是 GoDaddy 過半 XD
接近一半的 startup 沒有 SSL，如果有的大多數也都是跟 GoDaddy 買。然後有不少人是買 Wildcard SSL Certificate...
不過還是要講，重點在於挑自己熟悉而且穩定的技術，並不是用了雲端就什麼都不用學。