読者です 読者をやめる 読者になる 読者になる

FUJILOG

見た、聴いた、触れたこと。 動かしたもの、書いたもの。 ウェブとリアルの備忘録です。

Akamai勉強会Log

Akamai勉強会】2009/12/15 at Yahoo!Japan本社


"1000万人の視聴を支えたアカマイ、インターネットの裏側"

アカマイのこと:

1998年にMITからスピンアウト
・仕組みの完成までに5年要した。
・初めはキャッシュサーバとして活躍した

Akamaiの由来
・Aから始まる社名にしたい
・MITで流行したハワイ語から命名

商用ウェブが不安定というのは考え物だったので、信頼性をサービスにという視点で考えた。













ISP間のコストの扱い方は難しい。
・デフォルトサーバの選び方。
・通常はBGPの経路に従う(しかし、ISPはコスト優先設計)。

経路が長くなるとパケット損失も起こりうる→信頼性低下にもつながる。


接続の遅延の解決策は帯域ではない。
→走る車の速さ(レイテンシー)に喩えて説明

分裂型ネットワークによる配信基盤の必要性













Akamai社情報
・クライアント3000社
・20000件のドメイン管理
・キャッシュ9M Hit
・2Tbps帯域
・1000万クライアントへの同時ストリーミング可能


2008年頃までは帯域 1Tbps程度
2010年目処にサーバ台数を倍にする予定(投資額を倍にも)
※なお、Akamai本社はデータセンターを持たない


増設の背景:

運用拠点の監視(負担増)とウェブのリッチ化(動画HD化)

HTTPリクエストを短時間に何回返せるか。
水平方向にスケールアウトする施策。
→サーバ1台のさばける量ではなく、系全体を考えて最適化する。


パフォーマンス課題
・キャッシュヒット率
・戦略的な選択がある
※サーバをばらまいてキャッシュ化すると、コストが高くつく。額を押さえるなら中央集権型。


キャッシュヒット率次第で階層を変えられる。
→ヒット率を10〜20%にすることでサーバロードOFFで負荷分散。

活性監視を互いにする(リージョン)

Overlay Routing:早いパスを選択する。

SSLの証明書は自ら取得してEdgeサーバを置く。

配信方法
・静的オブジェクト配信
・静的+動的のハイブリッド利用
・ストリーミング配信


顧客元Akamai化する前のサーバ=オリジンサーバ
オブジェクト配信をサイト配信へ切り替え

User-Agent -> Root Servers -> Customer DNS -> Akamai Root Server/Edge Server -> Origin Serverとする。

Video On Demand
スケーラブルかつ信頼性高いLiveStreaming

Primary Ex User -> Primary Entry point -> IR node -> Live flash Streaming Server -> End User

Akamaiと違法コンテンツについて→基本的にはデータ消さない

配信実績
24Mbps:86%
700Kbps:7%
数百帯域:6%

アクセス地域
USA:39%
メキシコ:14%
カナダ:7%

日本:4%


HTTP利用したストリーミングサービス
AmazonFMS


→以降デモ


【FAQ】
Q:Dynamic Mapping はどうしてる?
Aレコードを乗せて返す手法とは想像するが…

A:Akamaiに一番近いところを探すのには、クライアント寄りのIP見ている。

大雑把にIP見て絞り込み、次に容量負荷を見て空いているサーバを割り当てる。

東京のユーザ、大阪のDNSサーバなら大阪を見に行く。
自動的に障害状況を判断して、クライアントへURL発行する。
そのURL遷移でユーザのIPを把握する。


Q:他社のCDN屋さんとの関連は?

米国Lime Light社、韓国CD Network、米Level3とあるが、Akamaiの世界シェアは70%。

LimeLight社は自社ISP持っている。

他のISPさんと如何にPeeringするかが鍵。

Akamai社の強みは「SSL配信とOptimization策」


Q:サービスの提供価格は?

規模にはよるものの、一般には月1000万円から。
1年以上の契約を想定。
(※契約年数が長ければ、単価は下がるが長期でも2年契約の顧客が大半。これは何年も継続するWebサービスが少ないことにも起因)

営業としては月150万円程いただきたい。
コスト面は応相談。
スイッチルータ減らせるかや、システムの運用安定性の向上など。

なお、長期展望にもとづくため、財務体質が赤字のところへは取引できない。
YouTubeは昔はダメだったが今は取引可。

月100万円の規模感は、SONYPlayStation、NintendoのWiネットワークに相当。


Q:リアルタイムトラフィックが来たときの対応は?

P2PならAkamaiはダウンロード型サービスを提供する。
Client Server Delivery


Q:Akamai Cloud Front(ACF)について、技術的には競合では?

ACFはS3での個人ユース、キャッシュのみ使用。
Akamaiエンタープライズ


Q:IPv6対応は?

R&D部門で対策、1〜2年後には対応予定。


Q:サイト単位で配信は?

PHPやShellスクリプトの処理はサーバ側。
URL返されるなら、URLごとにキャッシュしてしまう。
基本は動的コンテンツをスルーする。


Q:諸々にドメイン名の使い分けは?

用途ごとに。
・Edge Suite.net
・Edge key.net
・Edge fes.net
・Akadns
etc…


Yahoo!オークション裏話(ヤフオクにおけるAkamai活用法)】R&D部門 武藤さん

ヤフオクの歴史
2000年8月〜 テスト
2000年9月〜 サービス開始

帯域:2Gbps/sec
hits 60000/sec(ページ数ではなく、コンテンツ数)

2002〜2003年 社内CDNプロダクト開発開始
2009年7月 移管完了(Akamai卒業)


社内移管の為、画像配信の効率化
㈰画質調整
㈪無駄なコンテンツをCDNから除去
㈫ブラウザキャッシュの利用










昔:画像配信の特徴

・1商品11サイズ、サイズ毎に画像ファイルを用意していた
・全画像をCDN経由で配信していた
(→URLは固定、TTLを短くして時間を短縮化で改善したが…)
Akamai使ってもOriginServerの中で狂っていた


教訓:Akamaiは使うべきところで、使うこと。

Akamaiの長所
・ピークコントロール
・安定性

台風の天気、9.11のニュースなどの突発的高負荷時でも、AkamaiにTopページを渡せば、ノンストップで処理できた。


【最後に…】
Akamaiには監視センターから、ボタン一つでクライアント先のServer配信方法を変更できる仕組みがある。

OverHTTP:
HTTP上をラップして、コンテンツを配信。
FlashSilverLightは同サーバ上で処理する。
サーバ台数はキャパシティプランニング。
突発的な人気コンテンツに対して予測して負荷対策。

5600台のサーバはすべて同時に制御できる。
全世界には4カ所。
・ボストン(ケンブリッジ
・サンマテオ(シリコンバレー
バンガロール(インド)…ここは24時間稼働
・米国政府専用(場所非公開)…数百〜数千のDoS攻撃に耐えた実績あり

インターネット帯域消費はUSAが圧倒的に多い。

Akamaiのホームページは技術情報の宝庫なので、要参照のこと。。


以上。

ネットワーク業務を主に担当したことがなかった為、いずれの話題も新鮮です。
Akamaiを通じてインターネットの裏側を知る良い機会でした。