Akamai 阻擋 DDoS 能力的上限

這應該是最近在看 DDoS 事件中比較重要的新聞了,從這次的事件知道 Akamai 沒有能力擋下某種 620Gbps 以上的 DDoS 攻擊,而這是攻擊者已經有能力「示範」出來的量:「Akamai kicked journalist Brian Krebs' site off its servers after he was hit by a 'record' cyberattack」。

The assault has flooded Krebs' site with more than 620 gigabits per second of traffic — nearly double what Akamai has seen in the past.

然後現在 Krebs on Security 的整個站台都轉移到 GoogleProject Shield 計畫上了,接下來就是時間的考驗了:「The Democratization of Censorship」。

Akamai 與 Microsoft Azure CDN 合作的方案進入 GA (General Availability)

先是在 Akamai 的網站上看到說明:「Microsoft Azure CDN from Akamai Enters General Availability」,另外裡面有提到 Microsoft 的公告:「Microsoft announces general availability of Azure CDN from Akamai」。

所以 Microsoft Azure 現在提供三個不同的 CDN 方案:

  • Azure CDN Standard from Verizon
  • Azure CDN Standard from Akamai
  • Azure CDN Premium from Verizon

其中 Standard 方案的價錢都相同,而 Verizon 的 Premium 方案大約是兩倍價錢,沒猜錯的話應該是 Verizon ACCELERATE?以前 EdgeCast 的 ADN 產品線?

北都數位 (TaipeiNet) 的網路

在住的地方拉了北都數位的 cable 與網路來用,首先是速度,30M 有跑滿,不知道用的人多了之後會如何:

線路 IP 反解看起來是走遠傳 SEEDNet,而實際 traceroute 也都是走遠傳的骨幹。

首先是 DHCP 的 DNS 設定頗糟糕,居然配出 HiNet 的 168.95.1.1:

螢幕快照 2016-01-22 15.11.18

然後測了老半天,遠傳看起來完全沒有 Akamai Edge?查了一堆站台,不是走香港、日本,不然就是 HiNet 的 Akamai Edge (即使我把 DNS 硬設為 SEEDNet 自己的 DNS resolver),這樣吃國際頻寬不會吃很兇嗎?

之後找時間來看看遠傳的行動網路如何好了,固網這塊感覺好慘...

Apple 使用 Limelight Networks...

好久沒看到 Limelight Networks 的新聞:「Apple’s Multi-CDN Strategy Adds Limelight Networks To The Mix」。

Dan Rayburn 發現 Apple 把 Limelight Networks 加入 Apple 的下載網路裡。之前用的是 Akamai,另外就是自己建的 CDN,現在加入 Limelight Networks 應該是成本考量:(因為在 Limelight Networks 的財報上有提出來,雖然不是直接講明 Apple)

On Limelight’s earnings call this week, the company mentioned they signed up some customers that they had to give a low price point to, which would impact margins in the short-term, before they expected the economics of scale to kick in.

不過 Limelight Networks 對 HiNet 的品質一直都不是很好,主要還是會導去香港機房,但看起來線路頗壅塞,就再看看吧...

關於各家 CDN 的選擇...

在使用 CDN 前,先考慮上 SPDYHTTP/2 (i.e. 全站 HTTPS),改善的效果跟 CDN latency 帶來的效益有得拼。尤其是 server 放在美國機房的情況,SPDY 與 HTTP/2 帶來的效能提昇是相當明顯的。

會寫這篇是因為這兩個禮拜意外被問到好幾次,所以來整理幾家如果讓我來選,我會選擇的 CDN。至少再被問到的時候可以直接從這邊開始說明。

下面的圖是從我家裡 HiNet 光世代測試的結果 (最後是走兩條電話線),所以會有個 10ms 的 latency 基底,如果要計算 latency 的效能影響請考慮進去。

Akamai

先講 Akamai

Akamai 的歷史很久了,再加上併購了不少公司,所以產品成熟度很夠,你要什麼產品都有提供,只要拿的出錢就可以。

KKBOX (敝公司) 用過 PMD、DSDDSA 三個產品,其中 PMD 與 DSD 只有保障服務可靠度 (availability),DSA 還有保障效能提昇 (performance)。早期是用 PMD + DSD,現在改用 PMD + DSA。

在功能面上,雖然 Akamai 是大公司,但各種新功能跟的蠻快的。主要就是為了 SPDY 以及之後預期會有的 HTTP/2 而選了 DSA,另外也剛好有效能提昇 SLA 需求而一併升級。

品質上來說,Akamai 在全球的點 (PoP) 夠密集 (差不多是有 ISP 機房就會放),當初會選擇 Akamai 是為了敝公司在泰國與馬來西亞兩個地區的用戶,而 PMD 在這兩個地區的品質都還不錯。

在台灣也有好幾個點,但除非你買的產品線等級夠高 (i.e. 合約有保證 performance,像是 DSA),不然平常不會分到台灣的點,以最近的情況來說是深夜才有機會指回台灣。

這是 Akamai DSD 的圖:

而這是 DSA 的圖:

可以看得出來 latency 的差異。

在 SLA 的部份,是目前少數有提供保證 100% availability SLA 的 CDN。

成本考量上,價錢是最硬的,但由於 CDN 這個領域競爭得很激烈,只要超過某一個 commit level 後有機會壓到跟 CloudFront 拼的價錢,也就是說,有經濟規模就有機會在台灣變成重點客戶而坐下來談價錢 (不確定多少,但 CloudFront 的第一個級距 10TB/month 應該是基本吧)。

另一方面,因為透過業務談價錢,會需要開會討論,所以對使用方的人力成本偏高。不過因為如此,台灣有 Akamai 辦公室與經銷商,稅務會比較好處理。(參考:「零壹科技正式代理Akamai 推展雲端優化服務解決方案」)

總結來說,適合已經有量,而且台灣是重要客群的公司。

EdgeCast

再來講 EdgeCast

EdgeCast 的功能比 Akamai 少很多,自從被 Verizon 買進去後就沒推出什麼比較有趣的產品了 (參考「Verizon 打算買下 EdgeCast...」),感覺上是電信公司買來補產品線的啦,所以也不用太期待之後會有什麼新產品推出來...

比較特別的是 EdgeCast 跟 HiNet 有合作 (參考「EdgeCast 與 HiNet 合作...」),所以也是少數在台灣有機房的 CDN 業者。在台灣的 PoP 據說是在高雄 HiNet 機房內:

另外 EdgeCast 有 Network Map 可以看在全球有哪些 PoP。

價錢上聽朋友說比 Akamai 低了不少,不過自己沒經手過無法確認。同樣是透過業務談,所以也有類似的人力與稅務優缺點。不過據說也可以直接 bypass 國內的業務,直接跟國外談,不過這樣搞境外稅務的問題就要自己解決了。

綜合來說,也是適合已經有量,由於沒有 SPDY 與 HTTP/2,就看 PoP 的點決定合不合用。

CloudFront

Amazon CloudFront 算是很多 startup 的第一嘗試,no commit 以及帳單在同一張可以省下不少功夫。

在 CloudFront 上分成三個不同等級的產品,通常下載用可以拿 Price Class 100 (只有北美與歐洲的 PoP),而真正要加速用的再拿 Price Class All 用。

而功能面上,CloudFront 的功能說不定還比 EdgeCast 多,不過還是沒支援 SPDY 或 HTTP/2,所以基本上是靠台灣的 PoP 在撐 latency 的。而台灣的 PoP 據說在內湖:

價錢在官網上就擺出來給大家看了,比較大的缺點是不同區域是分開算錢的,不過是可以找台灣的經銷商談 commit level 包價錢啦,不過價錢還是很難談。

綜合來說,適合 startup 用。

CloudFlare

CloudFlare 也是很多人問的一個選擇,不看流量價錢固定是賣點之一。

功能非常多,SSL certificate 涵蓋在所有產品內,另外也是目前少數支援 SPDY 的 CDN。技術上是走 Anycast 而非 GeoDNS dispatch。

HiNet 過去的品質爛到爆炸 (重點在於會 packet loss),也常常是被 DDoS 的目標。台灣其他的 ISP 過去大多都是到日本機房,但 HiNet 會到香港機房,而 HiNet 的這條線路相當壅塞:

主要還是靠 SPDY 的能耐硬是把效能撐到「堪用」的程度,而 CloudFlare 遇到 DDoS 時就慘了。

價錢也是公開的,但以商用水準的品質來說,已經低到及格線以下了...

綜合來說,自己玩玩的東西還可以啦,任何商業性質的網站都不應該單獨用 (與其他 CDN 服務動態偵測服務搭配著用還加減可以用用)。所以目前看到用最多的服務就是內容農場 (Content Farm) 在用,為了節省頻寬與伺服器的負荷,不太在意品質。

補充

最後補充在台灣有機房的 CDN 業者:(按照字母排,可能有漏)

KKBOX 徵人:平台營運處 (API Team)

索引:


續上篇的「KKBOX 徵人」,順便跟 Client Team 的同事徵文,等他寫完後也會貼出來讓大家知道 Client Team 目前找什麼人。

Server Team 這邊徵人的部份順著每個部門說明,這次先講平台營運處 (API Team)。

曲庫開發部

曲庫開發部,負責接唱片公司所提供的 API 以及 DDEX 資料,將這些資料半自動或是自動化整合到 KKBOX 的系統內。

另外這個部門在某些情況下,會需要寫程式特殊處理曲庫資料。舉例來說,前陣子金牌大風被華納音樂集團併購,這時候就有授權單位轉移的工作要做。

人工上架的系統也是這個部門開發,由公司另外的部門作業。

API 開發部

API 開發部,負責開發與維護 KKBOX 應用程式的 API。

平台開發部

平台開發部,負責系統建制。我用條列的方式試著列一些出來:(應該是列不完)

  • 搜尋引擎的設計與維運,目前現在是使用 Solr,正在研究翻新成 Elasticsearch
  • 與曲庫開發部合作,像是音檔轉檔與 DRM 機制。
  • 與 API 開發部合作,像是依照商業邏輯選擇使用我們自己租用的國際頻寬,或是使用 Akamai 供應音檔。
  • 各種通靈業務。

影音服務開發部

影音相關的研發,也是偏 Server Side 的部份。

找什麼樣的人?

不限於這些,可以是聯集也可以有其他技能:

  • 系統分析、系統設計 (SA & SD),包括了以上業務的分析與設計,主管會調度分配對應的項目。
  • Java 工程師 (以及資深工程師),目前主要是針對平台開發部的搜尋引擎。
  • PHP 工程師 (以及資深工程師),這邊提到的四個部門都有在找。
  • Full Stack Engineer,平台開發部與影音服務開發部都有找。

待續...

冨樫中...

CloudHarmony 的市占率統計 (CDN、DNS、Cloud Computing)

CloudHarmony 發表了他們對 CDN、DNS、Cloud Computing 市占率的統計數據:

CDN 的部份可以看出來 Akamai 仍然是稱霸整個市場,不過 CloudFlare 也不是小數字就是了...

DNS 的部份比較沒有那麼明顯,由於 CloudFlare 免費方案必須把 DNS hosting 指到他們家,所以 CDN 連帶影響到 DNS 的部份,看起來頗亂,比較明顯的是 Route53 一直在成長。

Cloud Computing 的部份不知道是怎麼估算的,跟另外從營收數字估算的是另外一種面貌。雖然 EC2 還是很大,不過你要說 Rackspace 有 EC2 的 1/3 大?hmmm...

查看各家 CDN 在各地的狀態

Cedexis 的「Real time data for real time decisions」蒐集了各家 CDN 在各地的連線資訊,包括了 response time、throughput 這些資訊,能夠解讀的話對於事前分析會很有幫助。

舉個例子來說,泰國地區 2014/10/20 的數字如下圖。

先從 latency 的部份開始看,可以看到 AkamaiCDNetworks 的速度分別是 52ms 與 63ms,可以合理猜測都是在泰國當地有 PoP 直接服務。而 LimelightCloudFront 要 98ms 與 111ms,看起來最少是新加坡或是香港?

而 availability 的部份也可以看出來國內線路的優勢,只要一跨國就不好維持。

這樣就可以針對需求而決定要找哪幾家 CDN 業者來談。在找 CDN 業者實際測試前,先看看這邊的資料會是很不錯的資訊,可以省下不少白工。

蘋果自家的 CDN

Apple 自家建立了 CDN 並且開始服務:「Apple’s CDN Now Live: Has Paid Deals With ISPs, Massive Capacity In Place」。

找了好久才找到 swcdn.apple.com 這個名稱,sw 不知道是不是指 switch 的意思?

從 blog 這台主機 (DigitalOcean 在 San Jose 的機房) 可以看到被指到 SFO 的 Apple CDN:

swcdn.apple.com.        3600    IN      CNAME   swcdn.apple.com.akadns.net.
swcdn.apple.com.akadns.net. 300 IN      CNAME   ussjc1.cdn-apple.com.akadns.net.

而如果從台灣查,則會導去 Akamai

swcdn.apple.com.        3282    IN      CNAME   swcdn.apple.com.akadns.net.
swcdn.apple.com.akadns.net. 300 IN      CNAME   swcdn.apple.com.edgesuite.net.

看起來還是用 Akamai 提供的 DNS 服務。而從導的情況看起來,符合原文作者 Dan Rayburn 的說明,目前只有歐美地區是走自家的 CDN:

Recently, Apple’s CDN has gone live in the U.S. and Europe and the company is now delivering some of their own content, directly to consumers.

量夠大就會這樣玩,應該是逐步繼續做?