Amazon Virtual Private Cloud (VPC)

Amazon Web Services 推出 Amazon Virtual Private Cloud:「Introducing Amazon Virtual Private Cloud (VPC)」。

於是現有的企業或是網站,可以利用 IPSec 將內部網路串接到 Amazon Web Services 內部,而不用像以前每台機器都要用 OpenVPN 打洞。

最直覺的想法是,企業可以直接把內部網站搬到 Amazon Web Services 上面,節省不少管理與設備的成本。

對一般小網站的 MySQL 資料庫備份,變得更容易全自動化處理:在 EC2 上建立 EBS 跑 MySQL slave server,並且定時以 FLUSH + snapshot 另外再留存。

對於中國大陸的公司來說,透過 IPSec 的幫助,可以變成公司穿越 GFWVPN 啊 XDDD (不過仔細想了以後發現有點貴,自己租 dedicated hosting 跑 IPSec 會比較便宜)

Amazon EC2 的 Reserved Instances 降價

Amazon EC2 的 Reserved Instances 降價了:「Lower Pricing for Amazon EC2 Reserved Instances」,關於 Reserved Instances 的意義可以參考『Amazon EC2 推出「年租不可抵」制度』這篇文章。

以最小台的為例,本來是 USD$325/year,現在變成 USD$227.5/year,另外加上 USD$0.03/hour 的費用。本來是六個半月 (~6.45) 以上才打平,現在變成四個半月 (~4.51) 就打平了。

我是希望 FreeBSD 趕快在上面出現...

jQuery 提供的 code.jquery.com 重導至 Google's AJAX Libraries API

jQuery 的官方 Blog 公告了 jQuery 之前所提供的 code.jquery.com 將重導至 Google's AJAX Libraries API 所提供 jQuery:「code.jquery.com Redirected to Google Ajax APIs」。

我記得之前是放在 Amazon CloudFront 上面,不支援 gzip (這點對於 JavaScript framework/library 很傷),而且在亞洲非 PoP 國家 (HK 與 JP) 的連線品質其實並沒有很好,另外一個重點應該是因為太燒錢。

另外要提到的一點是 HiNet 與 Google 台灣機房直接連線了,不確定是不是海纜斷線的權宜之計 (把本來導去其他地區的 Google 流量導回國內,減少國際頻寬的壓力),或是之後就會連著... 肯定的是這次直連的數據會在 HiNet 內部被評估。

如果 HiNet 與 Google 台灣機房的 peering 是永久性的,另外一個可能的衝擊是台灣機房設 YouTube 的 cache server,這樣一來台灣其他 video hosting 就差不多不用玩了 XD

網路隱私權問題

Bruce Schneier 的 blog 看到「Flash Cookies」這篇才想到要紀錄 Firefox 要裝哪些套件才能維持一定的隱私。

首先是 Firefox 3.5 內建的 Privacy 設定,先選擇 "Use custom settings for history" (這樣才能自訂),把 "Accept cookies from sites" 的 "Keep until" 改成 "I close Shiretoko" (我用的版本叫做 "Shiretoko",你在自己的電腦應該會看到 "Firefox")。接著設定 Exceptions,把常去而且會需要以 cookie 登入的站台設到白名單。

然後是安裝 RefControl,預設設定成 Block 或是 Forge 都可以,避免 Referer 透漏資訊。有很多站台 (尤其是中國大陸的) 因為 Referer 檢查過嚴格而無法使用時可以另外手動加上網域設為 Normal。

接著裝 BetterPrivacy,在關閉 Firefox 時清掉 Flash 內的 Local Shared Object (類似 cookie 的功能)。

MySQL MMM 的情況

MySQL Master-Master 架構常被用在 SQL query 相依性低的情況,像是 counter 常使用的 INSERT INTO ... ON DUPLICATE KEY UPDATE a = a + 1 不會因為 out-of-order 而造成問題。而 MySQL MMM 算是其中一套寫得比較好的 MySQL Master-Master 架構管理工具。

不過,用 GoogleMySQL MMM 會找到幾個網頁:

就目前看起來,MMM1 新版會在 Google Code 上更新,而 MMM2 新版可以在獨立網址站上找到。在 MMM 的 Google Group 上也有人提出類似的問題,所以遲早會解決 (吧)...

FCC 調查 Apple 拒絕 Google Voice 登錄到 iPhone 上的事件

Slashdot 的「FCC Probing Apple, AT&T Rejection of Google Voice」這篇文章看到的,原報導在 ComputerWorld 的「FCC probes Apple's rejection of Google Voice for iPhone」。

關於 Apple 拒絕 Google Voice 應用程式登錄到 iPhone 上的事情,可以在「Google應用程式 吃蘋果閉門羹」、「蘋果拿喬 Google二度碰壁」這兩篇看到。

果然 FCC 就介入調查了 (不愧是萬惡的 Google),分別給 Apple 與 AT&T 各一封公文表示「關切」(在這裡可以下載 FCC 的 PDF 公文)。

又是大公司之間利用政府機關鬥法了 XD

Update:結果 Google 的 CEO Eric Schmidt 離開 Apple 董事會了:「Dr. Eric Schmidt Resigns from Apple’s Board of Directors」,這算是前戲嗎?

Distributed Key-Value Database

這篇是因為在 PIXNET 內講了 n 次,決定寫成文字,至少之後新人進來可以說「就看這篇」,避免整套系統都需要重新講一次。

對了,補充一下,PIXNET 還是有缺人,參考「缺人找人」這篇的內容,如果有想問的細節,可以寫信問我。

資料庫

RDBMS 提供了很多而且很豐富的操作方式,但當資料量愈來愈大時,會遇到單台機器的網路頻寬有限以及空間有限。這時候一定得走向多台的架構。

Replication

最容易解決的情況是「讀取的 query 比寫入的 query 多」,可以用 database replication 解決,這也是 Web 1.0 網站常見的解法之一 (另外一種常見的解法是使用靜態檔案,或是 reverse proxy cache),同步將資料複製到多台。

Memcached

接下來會發現當 slave 過多時會造成每台記憶體內重複 cache 相同的元素,也就是說,有二十台 slave,每台都有 SELECT * FROM `user` WHERE `name` = 'gslin' 的結果其實很浪費資源。不過這個問題可以用 memcached 或是 hash selection 解決。

Sharding

在 Web 2.0 的環境裡,User generated content 成為主流,當寫入的 query 超過單台可以負荷的量時,replication 的架構就不是很適合了,因為每個寫入的 query 在其他台 slave 上也會被執行。在商用資料庫的領域通常是使用 cluster 架構,在 open source 領域的 MySQL cluster 也是 cluster-based solution,不過用的單位還不是很多,而且 overhead 還蠻重的。

比較常見的解法是 sharding:依照 id,把資料拆散到各台。像是 Flickr 就是這樣使用。

但 sharding 就會少了很多 RDBMS 可以用的特性 (JOIN 與 transaction),在寫 application server 或是 library 的時候得花功夫多下幾次 query,並且注意資料的正確性。

上面這些方法在 2005 年 Brad Fitzpatrick (LiveJournal founder、memcached 作者) 的投影片「LiveJournal's Backend: A history of scaling」都有提到。

Sharding 是一個解法,但有不少缺點:

  • 需要 application server 或是 library,否則 3rd party 程式得清楚知道 sharding 的架構,才會知道資料要到哪個 cluster 找。
  • 無法隨意使用 JOIN 及 transaction。如果真的要 JOIN,設計時要想辦法把需要 JOIN 的資料放在同一台 database server。如果要跨機器 transaction 得透過 2PC 甚至 3PC (看需求),或是類似的 distributed transaction protocol,效能會比起同一台機器差很多。
  • 設計 schema 時必須注意當一個 cluster 愈來愈大時要 rebalance,或是更進一步,在一開始設計時就考慮到資料搬移的問題。

Key-Value Database

後來就有不少人注意到,Web 2.0 網站很多時候不需要 transaction,而 JOIN 也會儘量避免。透過多次 SELECT 拉資料,或是 denormalize 以提高效能的方式還蠻常見。(JOIN 保證 atomic,而且會因為 query analyzer enginer 在沒有正確分析的情況下會有大量的 random access,比多次 SELECT 耗資源)

另外一個是財務層面上的問題,一開始寫的時候通常也都只有一組 database server,不太可能一次就買兩組 database server。當成長到需要 sharding 時通常寫 code 的人已經不只一個人,一定有人偷懶使用 JOIN 或是其他無法 sharding 的程式。這時候會發現需要「重寫」而非「改寫」。

於是就有人開始思考,如果我放棄 RDBMS 的 JOIN 與 transaction,放棄到只剩下 key-value 的架構,是不是有辦法可以發展一套 distributed database system 可以取得 "incremental scalibility" 的特性 (白話的說就是「加機器就可以增加承載量」),再想辦法看看在這個系統上還可以加什麼功能。

也就是說,這樣的系統一開始可能只有兩台小台的機器 (為了 HA),同時跑 Web 與 Database,當網站愈來愈大的時候我把這些小機器拉到前端跑 Web,或是轉為開發機使用,本來的 Database 買 15KRPM SAS (為了 cache miss 的 seek time 與 latency) 與 64GB RAM (還是為了 cache hit 降低 latency)。

所以在 distributed key-value database 先有基本的功能:

  • GET(key)
  • SET(key, value)
  • DELETE(key)

有了這三個功能,至少你可以把本來在 RDBMS 裡很大一部份放到 Key-Value Database 裡。以 Blog 來說,可以把所有的標題及內文部份放到 Key-Value Database 內,大幅減少 RDBMS 的 cache 負擔。

或者,key 是 path + filename,value 是檔案內容,當作一個 filesystem 在用。(也就是 Amazon S3)

這樣對於前端寫程式的人就會簡單許多。整個 Key-Value Database 是一朵可以無限擴充的雲,前端程式不需要設計或是修改程式碼就可以一直發展。如果當作 Filesystem 就不用擔心 disk 滿了之後加機器需要停機。

在這個想法下,就有許多單位投入資源往 distributed key-value system 發展。經過這些年的發展,分散式資料庫主要有三個問題要解決,而且也被證明這三個問題無法同時解決 (被稱為 CAP theorem,參考 Brewer's Conjecture and the Feasibility of Consistent Available Partition-Tolerant Web Services, 2002 這篇原始論文,或是參考比較簡單易懂的說明「Brewer's CAP Theorem」):

  • Consistent
  • Availibility
  • Partition Tolerance

所以分散式資料庫得在這三個條件內取捨。目前比較熱門的 Distributed Key-Value Database 主要都是把 Consistent 放寬到 "Eventally Consistent",只保證資料「遲早會一致」,這些 Database 包括了 HBase (Yahoo!)、Cassandra (Facebook) 這兩套 Java-based 分散式資料庫。

要瞭解這兩套系統的架構,一般建議從「Amazon's Dynamo」這篇開始看,看完後再看這兩套系統的系統架構介紹,以及 mailing list 的討論。

這兩套除了基本的 Key-Value 外,還多了 Column 的觀念,彈性會比 Key-Value 好一些。Yahoo! 與 Facebook 都拿這個系統當 Search Engine 使用。

另外有一些比較單純的分散式系統,只有 Key-Value 而沒有 Column 的,在「My Thoughts on NoSQL」這篇文章裡對 CouchDBRedis 自稱 distributed 的嘴炮批評了不少。另外「Anti-RDBMS: A list of distributed key-value stores」介紹了很多。

大致上是這樣。

瀏覽器的佔有率

Digg 的 Blog 上看到「Much Ado About IE6」這篇文章,提到目前瀏覽器佔有率的事情 (尤其是 IE6)。

Digg 的使用者者中,IE6 佔了 10% visitor 以及 5% PV,所以他們已經在規劃何時要放棄 IE6 support。

我翻了六月 PIXNET 全站的情況 (用 Google Analytics),以 visitor 來看,IE 佔了 83.09%,IE6 佔了 IE 的 48.66%,所以大約佔全部的 40.43%。以 PV 來看,IE 佔了 83.91%,IE6 佔了 IE 的 46.98%,大約佔全部的 39.42%。

這個數字離不支援還早得很...

Update:六月 PIXNET 全站的瀏覽器分佈,overall >1% 的部份。(by Visitor)

Internet Explorer - 83.09% (6.0 - 48.66%,7.0 - 48.58%,8.0 - 2.74%)
Firefox - 13.47% (3.0.11 - 46.78%,3.0.10 - 38.50%)
Chrome - 1.63%
Safari - 1.27%

Google Apps 畢業,Openfind 推出郵件解決方案

Google Apps is out of beta (yes, really)」與「Openfind-解決方案-中小企業郵件解決方案-輕鬆郵」。

中間有一些小插曲,像是 Google Apps (Standard) 的連結不見,造成大家猜測是不是要趁著轉入正式版拿掉,最後又把連結放回去 (不過只有英文版的放回去,繁體中文版的還是拿掉了):「Google Apps Standard Edition: still free」。

另外一邊是 Openfind 推出「輕鬆郵」,提供 closed-source 版本的 server 軟體,有 100 accounts 限制,主要是給對於郵件系統放到 3rd-party 有疑慮的公司,但自己建制不敷成本的單位使用。網站上不能直接下載,需要填表...

另外一個重點是 GPL violation,這套免費版的防毒軟體使用 ClamAV (參考「常見問題」內的 Q4),不過 Openfind 已經明確表示他不會提供 source code 了 (看介接方式才會知道感染多大塊),這點就看誰拿到 binary 後去跟他們要...