コンテンツ配信コスト構造の変化を目指して

概要

JANOG34全体コンセプトは「混ざる、混ぜる」ということで、L3DSRと3rd party nexthopを混ぜた配信構成について紹介したいと思います。L3DSRはJANOG32でも紹介しました。今回は、BGPの3rd party nexthopを組み合わせた構成について紹介します。今回紹介する構成の肝は、「自分の網内を流れるトラフィックを減らすか」です。リクエストパケットはレスポンスパケットよりデータ量が大幅に小さい点、コンテンツ系ASはIXからトラフィックをあまり吸い込まない点の2つの特徴を利用した構成です。

応用例を考えると夢は大きく広がりますが、現実的に超えなければならない問題点も存在します。目的の構成の一歩手前の構成における効果と問題点、解決案を紹介します。特に解決案が正しいのか、もっと良い案は無いのかなど議論させていただければ嬉しいです。

発表者: 吉野純平 (株式会社ミクシィ)

資料: コンテンツ配信コスト構造の変化を目指して (吉野)

ログ: Q: 会場からの質問

A: 発表者からの回答/コメント

C: 会場からのコメント

A’: 発表後、発表者からの追加回答/コメント

C: BBIXのエンジニアと話した。特に問題ないとの認識。IX事業者として感知する話ではない。配信側と受け取る側と十分コミュニケーションが取れていれば問題ないと思います。UnknownUnicastもあまり問題ではないという認識。ぜひ商用でチャレンジしてください。

C: JPNAPは配信先とIX接続している人で調整してほしい。

mac aging timer : 5分

Unknown Unicast Flooding : 検知するモニタリング機構はもっている。

Macアドレスを維持する仕組みも持っていて、フルメッシュでPingしあう機構をもっているため、大規模な1つのL2-SWとして振舞えるようにしている。

[EUROIXの参考例(2例)]

LoNAP

mac aging timer : 2時間

Unknown Unicast Flooding : 対策している

macアドレスを維持する仕組みはもっていない。

AMS-IX

mac aging timer : 6時間

Unknown Unicast Flooding : 対策している

macアドレスを維持する仕組みをもっている。

サーバ直結に関して：DNS,NTP,route serverを直結している例もある。

A: Peerしていない同士の話が出たが、これはPeerしていないMacアドレス同士ということですか?

C: そういったケースはこれまでないので、詳しく決まっていないのが現状です。SDNではroute serverを介してPeerを張っていると、どことどこでPeerしているかがわかるので、不正なトラフィックを叩き落とすこともできる。この議論がSDN-IXでされているようなので、これにひっかかる可能性はあるかもしれません。

C: JPIXの場合

mac aging timer : 5分

Unknown Unicast Flooding : 他のホストを守る観点で、勝手にやってしまうのは難しい。他のPeer先にもネゴが必要。

サーバ直結 : あまりやってほしくない。

C: DIX-IEでSDN-IXをやる。仮想ルータのホスティングをやろうとしている。商用IXはもちろんネガティブになると思う。新しいことをしたいなら実験のIXでやれると思うので、是非相談してください。

C: サーバ直結の部分で、IXのIPアドレスを有効な利用ができないのでは? と思っている。アイボールから近いところから、コンテンツを流したいのか? 共用のCDNみたいなものがIXにあれば、今回の件はうれしいですか?

A: キャッシュサービスとして提供する自信がありますか? といったところがポイントだと思う。仕様にもよります。

A’: IPアドレスはおっしゃるとおり。サーバで10Gx4のLACP等でアドレス節約等出来るのか検証等必要になると思っています。今回はサーバを直接という話をしましたが、L3機能を持ったToRクラスの機器を使って集約することである程度節約できると考えています。

C: 先ほど商用IXはネガティブという話があったが、JPNAPはOKです。

Q: 仮に上位のIXが2つあり、配信サーバも2つに分散しているときは、ロードバランサはどう返すべきか考えるとCGNっぽくなるかなと思う。

A: ロードバランサのグルーピングバランス機能を使って、地域ごとにだし分けるようなイメージでやるのが解と考えている。アプリケーション制御で柔軟にできそうな気がしている。

Q: Peerしていない同士で、パケットを流すような構成といえるが、サーバがeBGPでPeerしない理由は?

A: 相手にとってPeer増やすのがめんどくさいと思われたり、さけた方がいいとおもってこの構成にしている。

C: みんなが合意してればOKということですね。

C: いろんなIXがある。IXにつないでる人たちが、どういうつなぎかたをしているか、運用のされ方を共有することが大事だと思っています。

C: こういう話を聞いた時に、TRILLとかパブリックパスとかの技術を使おうと検討しているのですかね?

C: JPNAPは常に検討していますし、プラットフォームで動かないこともある。色々考えてはいる。

Q: ルータポート単価が高いという話があったが。

A: ルータのポート単価が安くなるケースが多いが、1ポートだけ欲しい、といったニーズのときに新しく16ポートの機材はいらない。その時のことを考えると1ポートのIXを使たくなる。

A’: ルータポート単価の話は製品によります。効果が大きいのはこういうコストバランスの時だと考えています。ポート単価というよりも投資階段をどうするのか、設備でもって償却するのか、サービス利用するのかといった費用の払い方を選ぶための方法として考えられると良いと思っています。

C: peerしていない人たちとも情報共有することが必要。やる場合は、相互相談しましょう。

ハッシュタグ: このプログラムのハッシュタグは #lccdn です。Twitterなどでつぶやく際にお使い下さい。

→プログラムへ戻る