JANOG3 Log 13:00 パネルセッション Proxy Cacheを透かして見た風景 〜 透過型 Proxy Cache による影響 〜 司会： 矢萩 茂樹　インテリジェントテレコム パネリスト： 鍋島 公章 NTT Peter Danzig Network Appliance R. Vasudevan CacheFlow 富田 隆一 Alteon Networks Japan 但し、本logは前半部分 logger: 西村 昌明(NetIRD)，畑谷 聡(ソニーコミュニケーションネットワーク) ----------------------- (矢萩) ・今回の内容 透過キャッシュの利点、問題点 ・透過キャッシュの概要 通常のキャッシュ(proxy) ユーザがproxyを設定 透過キャッシュ 強制的に80番ポートのトラフィックをキャッシュに送り込む 設定がいらない ・Peter B Danzig NetApp(NetCache) Harvest/Squid Projectのメンバー ・R Vasdevan CacheFlow ・L4スイッチを使った透過キャッシュ ・鍋島さん 透過キャッシュの影響 (Peter B Danzig) ・Rules of thhumb for Scaling Individual Cache Nodes ・透過キャッシュはすでに世界中で使われている ・既に使っている企業の実例(NetCacheユーザ) 小規模ユーザは8-10Mbps、大規模ユーザは350Mbps 数ヶ月前から実運用 ISP5社あればうち4社は透過キャッシュ ・キャッシュに必要な４つの指標 TCPコネクション数、ディスク、メモリ、CPU 1Mbpsあたりに必要なリソース TCPコネクション数→1Mbpsあたりにどのくらいのオブジェクトを転送できるか 4-10 sec/URL Littleの法則 N=λW W 平均フェッチタイム 4-10 sec/URL λ 1Mbpsでの1秒あたりのURL数 250URL/Mbps N = 2 x 25URL/Mbps x 10sec = 500conn/Mbps (2倍するのはinput/outputの2コネクション使用するから) cisco/cacheflowを見ても同じ値になっている 平均値、経験則なので環境によって変動する 混雑している場合にはもっとコネクションが必要 L4スイッチを使うとTCPコネクションを制限できる DoSアタックを避けることができる wccpはこの機能がないので、ISPには不十分 必要なディスクアーム数 1アームごとに3Mbpsサービスできる 完全に経験則に基づく ディスク装置を100%稼動させると故障率が高くなる 50%におさえましょう ディスクアクセスは完全にランダム 1ディスクあたり50-200オペレーション(SCSI) 50%以下に保つためには、25ops以下に保つのが目標 50URL/sec 1 diskあたりの50%での処理量 1ディスクあたり2-3Mbpsと考えるとよい ディスクスペース あまり心配する必要は無い 18GB/diskが現在の技術 9GB/day (1Mbpsの経験則) 18GBなので心配要らない メモリ キャッシュのメモリ TCPバッファ(1Mbpsあたり8MB-32MB、OS依存) バッファプール(TCPバッファと同程度) URL毎のステータス harvest/squidはたくさんのメモリが必要になる 20MB/1Mbps(NetCache) 25Mbpsの場合は0.5GB CPU hash table,url parsingなどにCPUパワーを使用する ローエンド製品で25Mbps(ISPでダイヤルアップユーザでの実測値) ベンチマークを参考にするのではなく、運用環境で測定したほうがいい (R.Vasdevan) ・Active Caching and its Benefits ・キャッシュは既に現実のもの あとはどれだけ速く世界に展開させるか ・キャッシュはオプションではなく、不可避なものになっている ・ISPの帯域の60-80%はHTTP 小規模ISPから大規模ISPまで ・オブジェクトのサイズ 平均値 13,000bytes 中央値 4,000bytes ・トップページには通常10以上のオブジェクトが含まれている ・ISPや企業にとって、キャッシュの利点 サービスの質 レスポンスタイム アベイラビリティ ピークロードに耐えること 帯域幅の有効利用 既に飽和しているのだから、節約ではない ・スケーリングのためにはデータをユーザの近くにもっていかなくては行けない ・ホスティング エッジにコンテンツを分散する 今日の解決はミラーリング ミラーリング　難しい キャッシング　簡単 ・クライアントサイド 昔はproxyキャッシュ 現在は透過キャッシュ ・データを近くに置く ページレスポンスタイムの向上 オブジェクトレスポンスタイムだけではない ・帯域幅を効率的に利用する ・アクティブキャッシングの技術 ・ヒット率を増加させる ・パイプライン ページレスポンスタイムの向上 ・非同期リフレッシュ(アダプティブリフレッシュ) ・ヒット率 リプレース方針がまずいとヒット率が下がる リクエストされる確率を予測してリプレース方針を決める オブジェクトのフェッチに要するコスト実績をトラッキング ヒット率と帯域幅削減効果はリニアではない ・パイプライン キャッシュはトップページの構造を見る トップページに含まれるオブジェクトがあれば先読み ・アダプティブリフレッシュ フレッシュなオブジェクトを提供できる確率を高める オブジェクトの変化率はバリエーションが大きい フレッシュさのチェックは非同期的に行われる アダプトアルゴリズムに基づいてチェック 多くのオブジェクトは半年経っても変わっていない 15分で変わる株価のようなオブジェクトもある 修正の確率と参照の確率を計算 リフレッシュに効率的にバンド幅を使える 97-98%のオブジェクトをフレッシュに保てる 帯域幅とフレッシュさにはトレードオフがある -----------------------