JANOG3 Log 13:00 パネルセッション Proxy Cacheを透かして見た風景 〜 透過型 Proxy Cache による影響 〜 司会： 矢萩 茂樹　インテリジェントテレコム パネリスト： 鍋島 公章 NTT Peter Danzig Network Appliance R. Vasudevan CacheFlow 富田 隆一 Alteon Networks Japan 但し、本logは後半部分 logger: 森信 拓(NTT国際通信)，廣海 緑里(AT&T Jens) ----------------------- セッション： パネルセッション Proxy Cacheを透かしてみた風景 〜透過型Proxy Cacheによる影響〜 時間: 13:00-14:30 司会: 矢萩 茂樹(インテリジェントテレコム) パネリスト: 鍋島 公章(NTT) Peter Danzig(Network Appliance) R. Vasudevan(CacheFlow) 富田 隆一(アルテオンネットワークス) 席順: 左から(敬称略) 鍋島(N) 富田(T) Vasudevan(V) 矢萩(Y) Danzig(D) <-------- ここから後半（富田氏、鍋島氏、矢萩氏、Q&A） 【Cachingを支えるL4Switching技術 アルテオンネットワークス(富田)】 - Proxy Cache ブラウザはキャッシュサーバへリクエストを送る方式 - クライアントに 必ずproxyの設定。単一のキャッシュにしか直接リクエストが送れない (障害が有った場合はそこでアクセスできなくなる)。 その時はブラウザの設定変更が必要。 複数のCache Clusterを使った場合は、一つのCacheしか使っていないの で、複数のCache Clusterを使った場合は、一つのCacheしか使っていな いと、コンテンツの重複が問題。 ICPを使用していればコンテンツの重複は起らないが、遅延が起る。 - Transparent Proxy Cache ブラウザはオリジナルサーバにリクエストを送る(ブラウザの設定不要)。 全てのユーザトラフィックはキャッシュサーバがモニターする。 Cache対象の時Cache Serverが対応する。 対象外のトラフィックも通過するので負荷が高まる。 キャッシュサーバが停止した場合、ユーザにはわからないので本当に ユーザのアクセスが止まってしまう。 ユーザは設定の必要がない キャッシュサーバがHTTP 80ポートへのアクセスをモニタして自分へ向け るキャッシュサーバが停止すると全トラフィックがとまる、アクセス経 路が失われる（回避策はある） - Transparent Proxy Cache/Web Cache Redirection Switch(L4SW) クライアントとキャッシュサーバの間にswithをいれる - WCR SW(Web Cache Redirection Switch)。 ユーザの設定は不要。 L4SWがHTTPと判断したパケットのみをProxy Cacheに送る(Redirection する) サーバと比べるとSwitching能力が高いので、遅延も少なくなると思わ れる。 Packet Filtering機能もASIC化されているので高速に行う事が出来る。 最大の利点としては、Cache ServerをClusteringした場合、クライア ントは複数のキャッシュにヒットする事が可能。 複数のローカルキャッシュにオブジェクトを分散し、効率をよくする。 (宛先アドレスを基にキャッシュサーバに割り振る) よって、全てのキャッシュサーバが停止した場合でも、クライアントは アクセス不能にはならない。 キャッシュサーバにKeepaliveパケットをL4SWがサーバに送っているた め続け、サーバ停止の場合は、no cacheでダイレクトに取りに行く。 - Web Cache Redirection Switchの最適化を目指して - パフォーマンス WCR機能に特化された機器(専門化)。 - ヒット率の向上 HTTPアドレス宛先を見て分配する工夫。 - ユーザの要求に答えられる必要がある。 - セッション数のカウントにより少ないところにバランス。 - サーバの能力値を設定してコネクション数をバランス（ダウンの回避)。 - パケットの中身を変更するような機能も高速に出来なくてはいけない。 - Filterも設定可能。 SWとしてはポート単位でCPUを持って分散処理が出来るような構造が望ま しい ヒット率を高める為には、 - サーバの負荷を下げる。 - 遅延を少なくする。 - コンテンツのあるキャッシュへリクエストを導く。 コンテンツを割り振るようなアルゴリズムをキャッシュアレイに提供。 セッション数が少ない所にパケットを持っていくようなアルゴリズムで 負荷を下げる。 最大コネクション数 キャッシュのTCP Session最大数をSWで記録し、Monitoringする事より、 その閾値を超えた場合はCache Serverに渡さないような仕組。 SW自体のフェイルオーバ機能を考える必要がある(SWのRedundancy) 運用性を高める TCP Sessionの最大数をサーバ毎に設定可能。 フィルタをかける事に依ってSWでキャッシュしないような設定する事 も出来る。 特定のアプリケーションだけキャッシュしないような設定も行う事が 出来る。 FTP,Stream系などへの拡張(SWで)。 まとめ 資料を参照のこと 【Transparent Cachingによる影響とその考察(鍋島)】 - ProxyとTransparentの違い - キャッシュの利点 Internet全体が幸福になる。ISPは皆入れているべきだ。 - 問題 -広告屋が嫌がる。 -Internet(WEB)の視聴率調査に使われている。 -サンプリングによる視聴率調査が正式に動き出せば，広告屋もキャッシュを目の 敵にはしなくなり、ヒット数競争の終焉になる。 -下手に運用されて、サーバのパフォーマンス不足がある場合はその ISPの管理者をいじめるべき匿名性が出て来てしまう（ソースアドレス が見えなくなる） -HTTP_X_FOWARDED_FORを見るべきである。 -IP Address以外の認証を考えるべき -Proxy Serverでアクセス履歴が残るのでプライバシーの問題がある Transparent運用側の利点 全トラフィックをキャッシュ可能(お客様設定不要) トラフィックを落としたいところだけ落とせる。(国際線) ルータの負荷軽減（トラフィックフィルタ。 問題点 L4SWを使えばいいんだけど、 ルータでやるとルータの負荷があがる 意図しないのに80番ポートがキャッシュに行ってしまうので、知らな いうちにCacheをたくさん使ってしまう事になってしまう。(多段Cacheに なってしまう) →Latencyが増える可能性がある ユーザ側の利点 設定が不要。 ユーザ側の問題点 何もしないでも使われてしまう(プライバシーの問題)。 stream系データをキャッシュしてしまうこともあるかも。 80番ポート以外を使っているアプリケーションが困る。 会社などでは社員がどんなものをみているかわかるからいいかも？ 現状 米国ではL4SWの登場と共に結構使われている。 Netcacheのユーザリストの通り。 日本ではまだまだ。ユーザサイトでは使っている所もあり。 日本の傾向 ユーザサイドの導入は避けられない。 ISPサイドではまず中小ISPから使っていくだろう(T1X1ぐらいだと PC-SquidでOKだろう) 中小ＩＳＰが導入してコスト削減? T1数本ならL4 SW,Squidのクラスタリング 実は大手ISPが扱うトラフィックが多いので効果がとても大きい。 広告屋や世論との戦いが予想される。 【透過型Proxy Cacheによる影響(矢萩)】 一部にいれてみてどうだったかというテストベッド発表 L4switchによるポートリダイレクトとproxy cacheサーバを導入。 導入、運用ともに問題ないという事が確認できた。 影響の少ない海外経路の一部に入れてみた。 Cache Server,L4 SWはすべて二重化 Pre-fetch Onにしてヒット率向上を考えた。 海外線が複数があるが、一本の海外線の所にL4、Cacheを突っ込んだ。 そのルータのプロトコル比率(WWW67%ぐらい) 測定結果 Serverd From Cache 59%。 Loaded From Server 36.4%→結構ヒットしている？ 実際のトラフィックに対するCacheによる効果としては、帯域減少率は 18.7% 最大34.3% 最悪0.3% 午前9時から翌日午前2時まではおおむね良好。 午後2時から午前8時までは不調→ロボットによる効果？(あまり見に行か ない所を見に行っている) Non-cache Dataの内訳(CGI26.4%、Pragma No-cacheは1.1%)。 導入する嬉しさ 海外サイト、遅いサイトは高速になる。 使用帯域が少し節約できる(Pre-fetch On)。 L4 SWの耐障害性。 L4 SWの自動復旧機能(CiscoのPolicy Routingとは違う) 問題点1 透過串ざし問題。 Crackerが超えてWWW Chatあらしを行った場合、透過Proxyのアドレスが 登録され、そこから行われたように見える。苦情はすべて透過Proxy管理 者にいく。ログが膨大である為、やってられない。 問題点2 顧客とのポリシーミスマッチ問題。 高速より直接見に行きたい場合がある。 Routing変更により、当該ユーザのSessionは透過型を通らない様に 設定できると嬉しい 問題点3 Port80をHTTP以外に使っている問題。 ユーザアプリケーション。 Stream系を80番使って行っている場合もある。 考える必要のある点 - オンラインネットワークでの稼動実績と課題 ユーザ、カスタマーとのコンセンサスが必要では? スケール? - Contents Providerとの共存 - Streaming via HTTP - 他のプロトコルデータへの対応は？ 質問コーナー 1. (Y) Transparent Cacheについて不安があったと思うが、アメリカではどのように ユーザ及びカスタマとのコンセンサスを得たのか？ (V) 1998年3月から導入されだしたが利点を示した所懸念事項についての意見は あまり聞かれなくなった。 (Y)具体的な利点は何か？ (V)数字ではなくて、End Userの意見である。Cacheサーバを停止した所ユーザか の問い合せが続出した。 (P)その通り。 (P)先程帯域節約率は30%ぐらいと有ったが、現在の技術では50%まで行っている。 (V)30%という数字はSquidでの経験値から来ているのではないのか？ 2. (Y)スケーリングはどうか？最終的な可能性は？ (P)ギガビットクラスの帯域にも対応可能だが、新しい構造のL4 SWは必要かと思 う。 現状では日本からの国際トラフィックは300Mぐらいとの事なので、そのクラス のトラフィックだったら米国で実績がある。 CiscoのWCCPは光で構築されたNWにも対応している為、WCCPとL4 SWを組み合わ せて使えるようになれば興味深いと思う。 (V) バックボーンにCacheを入れても言いが、Edgeにおいて階層的にCacheを入れ るとより帯域を効果的に利用する事が出来るのではないか。 3. (Y) Content Providerとの共存は？何ヒットにつきいくらという視聴率調査との 共存は。 (N) 無視してもいいと思う。 実際にNon-CacheとCache有での環境で実験してみたが、ヒット数はIMS等 飛んでくるので2倍ぐらいしか変わらない。 きちんとした数値を指標として公開すればいいと思う。 (P) NetGravityはInternet広告とProxyが共存できる方法を示したInternet DraftをWWW上に公開しているので見て欲しい。 (V) 長期的に考えるとContent ProviderもCacheの存在は利点であり、気づいてく れ始めている。今後の広告掲載のあり方も変わってくるだろうと思われる。 1年も立たないうちに理解され、標準になると思う。 4. (Y) 80番ポートを使ったHTTP以外のものや他のプロトコルに対する解決策 (P) ベンダとも話し合いを持っていて、認識は持っている。 1年以内に他のプロトコルをCacheする製品を出荷するだろうと思っている。 (Stream系、NNTP等) (V) Stream系は非常に重要なサービスで、技術仕様が公開されればそれにも マッチした製品が作られるだろう。 5. (会場A)透過型キャッシュを現実に利用しているが、一番有効なのはnetscapeのロ ーカルキャッシュだと思う。(中央集中型よりローカルに近い所の方が効果的) 講義で使うときなどは確かにヒット率は上がるが、それ以外は効果ない。 キャッシュとキャッシュの間にボトルネックがある。どういう分野、構造で 導入するべきか? (Y) サービスの一つの選択肢として行い、市場がどう評価するか見るべきでは。 (N) 多段Cachingについては効果は疑問だが、2段ぐらいだと効果はあると考える。 お客様にも大小があって、自組織に1つしか持っていない場合は、ISPが持っ ていると嬉しい。ISPにも導入すべきだ。 6. (会場B)HousingをやっているISPやエンドユーザがCacheを使う事は納得している が、その中間のISPがCachingする事にはそのISPのユーザ外の事でもあり、疑 問を感じている。アメリカではどの様な議論が行われていたのか？ (P) CopyrightとOwnership問題の解決は技術的より政治的に行われた。 米国では政府からキャッシュはCopyrightに抵触しないと見解が出ている。 (V)Store and Forwardの問題はNNTPとかから問題になっていたと思うが、 現在は誰も気にしない。 7. (会場C)HTTPSのデータもCachingするのか？ (P) HTTPSはCachingできない。 IPベースのAuthenticationはもともとHTTPでは考えられていなかった。 -----------------------