みんなが知らずに使ってるAkamai

2009/4/27-1

アカマイ(株) ソリューションズ・エンジニア
国谷俊夫さん

Akamaiさんでのセミナーに参加してきました。個人的にはAkamaiさんと言えば「あまり一般的には知られていないけど使っていない人はほぼいない」企業というイメージがあります。あまりに内容が楽しかったので、セミナーで色々質問しまくって聞いてしまいました。想像以上に色々凄いと思いました。

ブロガーのyasuyukiさんが企画し、Akamaiさんにお願いして実現したプライベートセミナーでした。元々はyasuyukiさんがAkamaiさんのセミナーを聞いて「面白い」とtwitter上で囁きまくっていて、その後「プライベートなセミナーやったら来ますか？」とのオファーを頂きました。昔からAkamaiさんのCDN技術には非常に興味があったので「是非お願いします」とお願いしました。セミナー参加者募集はyasuyukiさんのブログとtwitter上で行われ、16人の参加者がいました(アカマイさんでネットの裏側勉強会(4/15)やります。)。

以下、Akamaiさんで聞いて来た話からAkamaiさんの技術等を要約してみました。 (以下、文中では敬称略)

何をしている会社か？

Akamaiは主にWeb閲覧の高速化とWebサーバの負荷軽減を実現するソリューションを世界的に提供しています。主な顧客は世界的に活動を行っている企業で、セミナーでは例えば以下のような表現が発表資料に含まれていました。

ゲーム業界上位５社のうち４社がアカマイをご採用いただいております
(WiiとPlaystationの画像、なので任天堂とSONYがアカマイを使っているということですね)

ポータルサイト上位７社のうち７社からアカマイをご採用いただいております
(Yahoo!Japanのスクリーンショットが表示されていました)

そして、以下のような情報も掲載されていました。

アカマイはウェブ・トラフィック全体の10％～20％を配信しています。

世界全体の2割(最大の場合)はアカマイに関連するWebトラフィックというのは凄いですね。一方で、アカマイがカバーしているのはアカマイ社にコンテンツ配信を依頼している顧客だけなので、世界で注目されるWebコンテンツの集中具合も凄いと思います。恐らくWindows Updateやウィルスソフトパターンファイル配信が大きなウェイトを占めているのだろうと邪推してみました。

Akamaiの語源

非常に日本語っぽい会社名ですが決して「赤米」という日本語ではありません。ハワイ語で「賢い」という意味の単語だそうです。 ABCに並んだ時に最初に来る事が重要という事で適切な単語を探していたら発見したそうです。

Akamaiはマサチューセツ工科大学(MIT)での研究からビジネス特許を取得し、Google社と同じ1998年に設立されたそうなのですが、当時MIT内にてハワイ語ブームがあり、ハワイ語辞書が手元にあったのでハワイ語から社名が生まれたそうです。

Akamaiの目指すところ

核攻撃が来たとしても自律的に再生できる冗長なネットワークとして設計されたインターネットは、冗長性を実現するために信頼性を犠牲にしています。そのため、インターネットでやり取りされるデータの到着は保証されませんし、到着までにかかる時間も予測が困難です。

CDN技術企業として注目される事が多いAkamaiですが、目指しているのは「インターネット全体の信頼性向上」であるようです。 Webの通信速度向上などは、信頼性向上のための活動の一部でしかないとのことでした。

とはいえ、現状でアカマイ社が実際に行われているビジネスの多くがWebだと思うので、ここでは主にWebでのCDN技術にフォーカスした解説文を書いています。

どうやっているのか？

どうやって世界の2割ものWebトラフィックを扱っているかですが、世界中のISP内にアカマイサーバを設置しているそうです。世界70カ国以上のISPやIXに、4万台以上のアカマイサーバが設置されていると発表資料に記述してありました。日本国内では、30拠点に約2000台のアカマイサーバが設置してあるようです。世界各地に設置してあるアカマイサーバは、ISP間に流れるトラフィックを軽減します。

CDNとは何か？

以下の例は非常に誇張していて正確ではないのですが、例えばアメリカにWebサーバがあるとします。このWebサーバにあるデータを日本から取得しようと思った時、3回別々の通信が日米間で行われます。

図１

しかし、以下の図のように日本にオリジナルWebサーバのコピーがあれば日本のユーザは近くにあるコピーからデータを取得すれば良くなります。これによって日米間のトラフィックは軽減され、ISPは回線にかかる費用を軽減できます。さらに、ユーザは自分の近くにあるデータにアクセスすることにより、高速にデータを取得できます。

図２

何故近くのデータを取得する方が速いか？

光の速さは有限であり、太平洋を越えるような通信をするとどうしてもデータ取得に一定の時間がかかってしまいます。 Webコンテンツを取得するときにはTCPが利用されますが、TCPは距離が離れれば離れるほどスループットは低下します(*1 最後のおまけに解説)。太平洋を渡らずに国内だけで全ての通信が完結すれば、ユーザへのレスポンスが高速化します。

負荷軽減

図１のような状態では、日本国内からのデータアクセスが減るので、オリジナルサーバへの負荷も軽減されます。世界各地から閲覧されるようなWebである場合、この負荷軽減は非常に重要な要素です。

Burst Trafficへの対応

例えば、Microsoft社のWindows Updateや、セキュリティソフトベンダーによるパターンファイル更新など、世界中から大量のアクセスがあるWebサイトはこのような負荷分散が必須になります。全体的な負荷分散やダウンロード速度向上という面もありますが、そのようなコンテンツはburstyなトラフィック特性を示すことが多いという理由もありそうです。 burstyとは急激にトラフィックが集中するという意味です。

特定の更新があって、世界中のコンピュータが同時に同じ更新ファイルをダウンロードした時の瞬間最大風速的トラフィックは恐らく凄いです。 Microsoft社がWindows Updateで新ファイルを公開した次の瞬間に世界中で国際間にある光ファイバがパンクしないのはアカマイ社があるからとも言えそうです。

４秒ルール？

表示に4秒以上かかると75％の顧客は購買意欲がなくなるという調査結果もあるようです。

「BBC NEWS : Websites face four-second cut-off」

Shoppers are likely to abandon a website if it takes longer than four seconds to load, a survey suggests.
The research by Akamai revealed users' dwindling patience with websites that take time to show up.
It found 75% of the 1,058 people asked would not return to websites that took longer than four seconds to load.

なお、BBCで取り上げられている「4秒ルール」の調査は行った会社はアカマイさんだそうです。

DNSによる最適サーバ選択

アカマイの最大の特徴はDNSを誤摩化す事によってユーザ側の環境に全く変更を加えずにCDN機能を実現できることです。具体的には、オリジナルサーバを持つ顧客企業が管理するDNSにCNAMEを一つ登録します。そのCNAMEは、アカマイ社の持つドメイン名が記述されます。

ユーザがDNSに問い合わせを行うと、最初にオリジナルサーバのドメイン名でのDNSに行き、次にアカマイ社のDNSへ問い合わせます。アカマイ社のDNSはユーザの最寄りのエッジサーバのIPアドレスを返答することによって、ユーザが近くからデータを取得できる状態を実現します。アカマイ社のDNSは、名前解決を要求しに来たユーザのIPアドレスから、ユーザの所属しているネットワークを知ります。

なお、上記図ではRoot Name ServerやユーザのISPにあるDNSは省略してあります。説明のために簡易化していますが、厳密には上記図は間違いなので、ご注意下さい。

キャッシュ

DNSによって名前解決が行われ、ユーザに示されたEdge Serverにデータがあれば、それがユーザに渡されます。

障害や災害などでデータセンターが利用できないときは、sorry page などを、NetStorageから取得することもあるようです。

前述した状況に当てはまらない場合はオリジンサーバからデータが取得されるようです。

EdgeSuite NetStorage

Akamai社の顧客はコンテンツを「NetStorage」にアップロードすることができます。 NetStorageにアップロードされたデータは筐体間ミラーと複数拠点間でのレプリケーションが自動的に行われます。ただし、AkamaiはコンテンツをCDN網へプッシュすることはなく、単にリクエストがきてからPULLします。

この仕組みはP2P的と言えばP2P的な部分を含んでいます。しかし、アカマイさんは「P2P」と表現されるのを非常に嫌うようです。確かに仕組みとしては類似しているのですが、世間的なP2Pという単語のイメージを考えれば当然と言えば当然だろうと思います。プレゼンでは、アカマイサーバ網はオーバーレイネットワークという呼ばれかたをしていました。

stable marriage algorithm

各ユーザにどのアカマイサーバを利用させるかを計算するときに、stable marriage algorithmが利用されるようです。実際にどのようなものかの詳細は教えて頂けませんでしたが、恐らくアカマイサーバの負荷とユーザまでの距離(もしくは遅延)や、パケットロス状況などを総合的に見て、順位付けを行っているのだろうと思います。

さらに、全体的な組み合わせを20秒毎に見直しているというのが驚きです。まあ、実際には安定しているときには設定は変化しないだろうとは思いますが、20秒毎に全体的な接続状況を見直せる体制があって、いざという時には瞬時に最適なアカマイサーバに切り替わるというのが凄いです。

stable marriage algorithmは安定結婚アルゴリズム、別名:合コンアルゴリズムと言うようです(参考 404 Blog Not Found:アルゴリズム - 合コンの効用を最大化する、stable marriage algorithmそのものに関しては小飼弾さんのブログ記事が非常にわかりやすいです)。

このstable marriage algorithmを利用しているという表現から「全アカマイサーバは他のアカマイサーバの存在を知っているのではないか」ということが予想できます。というのは、stable marriage algorithmは、N人の男性とN人の女性がお見合いをしたときに相手の組み合わせを発見するためのアルゴリズムだからです。ここら辺が、接続相手を発見するところから全部やらなければいけない一般的なP2Pと違う点なのかも知れません。まあ、でも、全アカマイサーバのリストを共有するための仕組みもあるだろうと思うので、広い意味ではP2P的な部分もあるのだろうと思います。

特許

アカマイ社が保持している特許のうち、最も基本的なものは「米国特許6108703」です。この特許はDNSを使って最寄りのキャッシュサーバへとユーザを誘導して、通信の負荷分散を行うというフレームワークそのものです。

Google Patent Search : 6,108,703 Global hosting system, F. Thomson Leighton et al

この特許の出願日が1999年5月19日です。アメリカでは出願日から20年特許が有効なので、この技術を超えるものが発明されない限りは2019年まではアカマイ社の強さは継続するのかも知れません。少なくとも、他の企業がDNSを利用した同様の手法を用いてCDN網を構築することはできません。

インターネットには様々な「ごまかし技術」というものが存在していますが、この特許で実現されているのも一種の「ごまかし技術」なのかも知れません。 DNSを利用する事によって、ユーザの環境を全く変更せずに負荷分散が出来るのは、既存の第三者が運営する様々な装置を全く変更せずに「ごまかしつつ」、本来の動作とは別の動作をするようなシステムを作り上げています。既存システムを変更しなくても良いというところに、この特許の強さと美しさがあるのだろうと思います。

アカマイサービスを購入する顧客

アカマイ社が提供するサービスを購入する顧客は以下のような条件がありそうです。

特定地域だけではなく世界に対して情報発信をしている
世界中から非常に多くの人々がWebサイトを見に来る
大きいデータファイルをやり取りすることがある
何かのきっかけでアクセスが集中することがある

もちろん、上記条件に限定されるわけではないのですが、上記条件を満たすような巨大企業にメリットが大きいサービスである気がします。例えば日本国内だけでサービスをするのであれば、国内の複数拠点にWebサーバを設置するだけでも何とかできるのかも知れません。しかし、世界中に高品質なWeb配信を行おうと思った場合、世界各所のデータセンターにサーバを設置する必要が出てきます。世界各所にサーバを設置するのは非常にコストがかかります。日本とアメリカだけならば何とかなるのかも知れませんが、多くの国がひしめき合うヨーロッパなどに対しても高品質にWeb配信を行うのは非常に大変です。

でも、そのような巨大企業だけで全世界のトラフィックの2割まで行く場合があるというのは凄いと思えます。

アカマイ社の顧客企業の発見方法

検索エンジンを使うとアカマイ社の顧客企業をある程度発見可能です。以下の検索キーワードで検索してみて下さい。（これは私が勝手に調べた方法でプレゼンで解説されていたわけではありません。ご注意下さい。）

akadns.net
edgesuite.net
akam.net

さらに、発見したそれらしきドメイン名を使ってDNSに問い合わせをしてみます。例えば、windowsの場合はコマンドコンソールから以下のようなコマンドを入力します。


C:\> nslookup www.microsoft.com
Name lb1.www.ms.akadns.net
Address: XXX.XXX.XXX.XXX
         XXX.XXX.XXX.XXX
Aliases: www.microsoft.com
         toggle.www.ms.akadns.net
         g.www.ms.akadns.net

MacosX,Linux,*BSDの場合は以下のようにします。


% dig mixi.jp
; <<>> DiG 9.3.4-P1 <<>> mixi.jp
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19980
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 8, ADDITIONAL: 8

;; QUESTION SECTION:
;mixi.jp.			IN	A

;; ANSWER SECTION:
mixi.jp.		600	IN	A	XXX.XXX.XXX.XXX
mixi.jp.		600	IN	A	XXX.XXX.XXX.XXX
mixi.jp.		600	IN	A	XXX.XXX.XXX.XXX
mixi.jp.		600	IN	A	XXX.XXX.XXX.XXX
mixi.jp.		600	IN	A	XXX.XXX.XXX.XXX

;; AUTHORITY SECTION:
mixi.jp.		86400	IN	NS	ns1-126.akam.net.
mixi.jp.		86400	IN	NS	aus1.akam.net.
mixi.jp.		86400	IN	NS	eur3.akam.net.
mixi.jp.		86400	IN	NS	eur5.akam.net.
mixi.jp.		86400	IN	NS	use4.akam.net.
mixi.jp.		86400	IN	NS	usw1.akam.net.
mixi.jp.		86400	IN	NS	asia9.akam.net.
mixi.jp.		86400	IN	NS	ns1-55.akam.net.

;; ADDITIONAL SECTION:
aus1.akam.net.        81396	IN	A	XXX.XXX.XXX.XXX
eur3.akam.net.        81396	IN	A	XXX.XXX.XXX.XXX
eur5.akam.net.        81396	IN	A	XXX.XXX.XXX.XXX
use4.akam.net.        156738	IN	A	XXX.XXX.XXX.XXX
usw1.akam.net.        81396	IN	A	XXX.XXX.XXX.XXX
asia9.akam.net.       81396	IN	A	XXX.XXX.XXX.XXX
ns1-55.akam.net.      81396	IN	A	XXX.XXX.XXX.XXX
ns1-126.akam.net.     81396	IN	A	XXX.XXX.XXX.XXX

それっぽいDNSが関わってれば、そのWebサイトを運営している会社はきっとアカマイ社の顧客ですね。

ISP間を流れるトラフィックを監視？？？

「アカマイはISP間を流れるトラフィックがわかる」という発言がプレゼン中で出て来たのですが、帰りの電車でこの表現の意味する所がどこか非常に気になりました。セミナー中に質問が出来なくて非常に残念だったのですが、個人的にはこの表現は誤解を招くのではないかと思いました。

恐らくISPはアカマイ社にトラフィック情報を生で渡したりしていません。本当の意味で「ISP間を流れるトラフィックを知る」にはBGPルータから流れるパケット数等に関する情報を得なければなりません。アカマイ社にそのような権限があるとは考え難いです。

私が個人的に思ったのは「アカマイサーバ同士の通信量を知っている」という話なのではないかと感じています。「このISPはアカマイサーバの台数が○台で容量的に足りなくなることが多いので隣のISPにあるキャッシュに問い合わせる事が多い」というような情報を元に、ISPに設置すべき最適なアカマイサーバの台数を推測してISPに提案しているという話なのでしょうか？

それとも、本当にISP間を流れる生トラフィックに関するstatisticsを得る権限を持ってるのでしょうか？

ISPにアカマイサーバを設置する

アカマイサーバを世界中のISPに設置してもらうという表現だけを聴くと非常に単純ですが、ここにも色々と複雑さがありそうです。

「コスト負担は誰がどうしているのか？」という質問をしたのですが、あまり直接的に言いたくないような雰囲気が一部含まれていました。流石に質問が直球過ぎだったと思います。

ISP同士のpeeringとか、tier1などの話と同様に、ここにも個々の力関係というものがあり、色々な要素で様々なものが決まって行く世界なのだろうと推測しています。

なお、アカマイサーバはAMD64 Linuxだそうです。

SSL対応

httpsでURLが始まる通信として良く知られているSSL対応も可能のようです。暗号化処理は非常に重いので、通信路暗号化処理が必要になるコンテンツの負荷分散が出来る事は重要です。

ただし、SSL対応をアカマイ社に依頼する場合、利用するアカマイサーバの数だけ証明書を発行しなければならなくなります。例えば、4万台のアカマイサーバがSSL負荷分散に使われる場合、4万個の証明書をオリジナルコンテンツを持つ企業はCAから4万個の証明書を発行してもらう必要があります。流石に普通の料金で4万個も証明書を発行してもらうと大変な値段になるので、コンテンツを持つ企業は適宜認証局を持つ企業と交渉をする場合もありそうです。認証局とアカマイ間で契約がある場合もあり、その場合はスムーズに事が運ぶそうです。

どのコンテンツをSSL対応を依頼するかどうかは顧客側が全て決定します。クリティカルな顧客情報がアカマイ社に漏れるような依頼をするクライアント(アカマイ社の顧客)はいないだろうと勝手に予想しています。

XMLで動作設定が可能

色々と細かい設定も出来るようです。例えば、任意のHTTP headerに対する挙動をXMLで記述するという事も可能なようです。

最初はこのような機能がどのように利用されるのかが良くわからなかったのですが、例えば携帯電話のためにUser Agent情報を見て振り分けたり、Accept-Languageがenかjaでredirectする先を変えたり、cookieをセットする事ができるとのことでした。確かに、そのような用途はありそうです。

何でも配信できる

個人的に凄いなぁと思った点の一つとして「配信は何でも出来ますよ。そもそもIPプロトコルレベルで自由でTCPでなくても良い」という説明が挙げられます。「ファイルフォーマットは何でもOK」ならば、まあそんなものだろうとも思うのですが、任意のIPプロトコルをCDN化って強烈だと思いました。

これって、もしかしてSCTP(Stream Control Transmission Protocol)を導入できちゃうって事ですかね？あと、例えばモバイルIPをCDN網で実現したりとかできちゃいます？「CDNのMVNO(Mobile Virtual Network Operator)」みたいな感じになるんですかね？

SLA 100％の凄み

さらに凄いのがISPレベルでの災害が発生したときのフェールオーバー機能です。 SureRoute機能と命名されているようです。

常に他のアカマイサーバとの通信状況などが把握され続けているので、ISPレベルでの障害が発生しても別のアカマイサーバとの連携が自動的に開始され、通信障害が回避されます。これによって、例えば特定のアカマイサーバ同士を繋ぐISPが落ちたとしても、違う経路から辿れるアカマイサーバとの通信が新たに行われます。

このようなCDNサービスを受けていないWebサーバであれば、どこかのISPが落ちた時に特定の地域が通信不能になります。しかし、アカマイサーバによるサービスを受けていると、そのような放射状に広がる通信障害は発生しにくくなるのだろうと思います。

光ファイバ切断事故

地中海海底ケーブル2本が切断されて、エジプト、インド、湾岸アラブ諸国で一般のインターネット通信が不安定になっても、アカマイ社の提供するサービスは安定してたと自慢してますね。

「2008年2月13日 - アカマイ、最近の海底ケーブル切断によるインターネット遅延について独自の見解を表明」

SLA 100％は自信の現れだと思う

このSLA 100％というのは非常にマーケティングに有効だと思いました。達成できなくて責められるリスクを取ったとしても「お金を払った分は何があっても保証します」と言い切れるというのは、かなりの自信の現れなんだろうと思います。自社システムにかなりの自信がなければ、恐らく100％とは言い切れないのだろうと思います。

IPv6

セミナーでIPv6に関して質問してみました。答えは「検討中」で実際に何かが出来上がっているわけではないとのことでした。

実際、色々と難しい問題がありそうです。

例えばIPv4とIPv6で通過するISPが違ってきたり、オリジナルデータが変わって来る可能性もあるので、単純にネットワーク層が変わるだけではなさそうです。細かい所ではアクセスログの扱いや、キャリアグレードNATへの対応などもあるかも知れません。

さらに、そもそもIPv6に対する需要がまだ無いというところも大きいです。 IPv6が語られる時にいつも登場するおなじみの鶏と卵問題です。

個人的に思ったのは、例えばアカマイサーバが4to6もしくは6to4的な働きをすれば、世界のIPv6化にとって非常に大きいのかも知れないということです。ただ、商業的にCDNを行っている事業体なので、やはり強いニーズが無ければIPv6化へと踏み切るのは難しいのだろうと思います。

ストリーミング

Webだけではなく、様々な動画の配信もできるという説明がありました。最近はFLVによる動画配信も多いようです。

ストリーミングはWebとは別の仕組みで動作しているようです。 ISPにおいてあるアカマイサーバのうちいくつかはOSごと切り替えが出来るようになっていて、リモートから再起動してWindowsにしたりLinuxにしたりできるようです。例えば、Windowsでしかストリーミングができない時などには状況に応じて必要な台数をWindowsに切り替えてしまうようです。

オバマ大統領の就任演説

米国時間2009年1月20日行われたバラク・オバマ大統領の就任演説は、東部標準時間午後12時15分頃のピーク時には700万フローのビデオストリームが視聴され、2Tbpsを超えるトラフィックが発生したそうです。

確かにみんな見てましたね。

最後に

今回のセミナーは非常に楽しかったです。参加者が終了後にひたすら「今日は楽しかった」と言っていました。今まで自分が知らなかった事を色々知れたり、知らない所で動いている「何か」の存在を意識できたのが良かったのかも知れません。

セミナーを開催して頂いた、Akamaiさん、そしてこの企画を立案して実現したyasuyukiさん、ありがとうございました！

なお、この文章は公開前にAkamaiさんに確認して頂き、了承を得て公開しています。また、文章執筆のために色々調べたのでプレゼンそのものとは全然関係が無い内容も結構色々入っています。ご注意下さい。

*1 おまけ：TCPスループットのモデル

TCPの性能は以下のような数式としてモデル化可能です(参考：Promoting the Use of End-to-End Congestion Control in the Internet, Sally Floyd and Kevin Fall, IEEE/ACM Transactions on Networking, 1999)。距離が大きくなれば通信速度が遅くなるのは以下のようにTCPによる要因もあります。しかし、だからといって必ずしもTCPが悪いわけではないのでご注意下さい。データ到着の信頼性が確保できないインターネットでの通信において仮想的に信頼性を確保する技術としてTCP以上のものはまだありません(少なくとも普及しているものとしては無い)。

上記式を見ると、スループットを表す「T」は右側の式よりも小さくなります。ということは、右側の式が大きくなるような条件であれば得られるであろう最大スループットは上昇し、逆に右側の値が小さくなるような条件であれば通信によって得られるスループットが降下します。

式右辺を考えたとき、MTUは通信中に大きく変化する事は少ないです。まあ、例えば通信中ずっと1400周辺の値になるぐらいで考えてみて下さい(1400という値は話を単純化するための嘘です)。通信中に最も変化するのがp(パケット喪失率)です。これは他の通信のトラフィック量などによって変化する事が多いです。

最後のRがパケットが行って返ってくるまでの時間です。距離が大きくなると、この「R」部分の値が大きくなります。そして、分母に入っているRの値が大きくなると、全体的なスループットも小さくなって行きます。

トラックバックURL : http://www.geekpage.jp/cgi-bin/tb.cgi?id=2009/4/27/1

トラックバック

[Network] 日本から OpenDNS を使っても無意味。Akamaiは逆効果。 [as flash as flex - horori.net]
最近、「インターネット接続の高速化と安全化をもたらすOpenDNS - SourceForge.JP Magazine」とか、「Mozilla Re-Mix: 安全・高速なWebサーフィンを実現する「OpenDNS」」といった記事がはてぶに登場したのですが、OpenDNSについて誤解する人がいると残念なので、本当の