アクセス - みる会図書館


検索対象: UNIX MAGAZINE 1999年9月号
53件見つかりました。

1. UNIX MAGAZINE 1999年9月号

連載 Cyber Kansai P「0 」 ect— 図 7 WWW アクセス数のキ多 サーバーごとのアクセス数 ( 単位 : 10 , 000 ) 2 , 000 1 , 500 のああ 1 , 000 500 0 アクセス総数 サーバー 1 サーバー 2 CV ( つマ 0 アクセス総数 ( 単位 : 10 , 000 ) 500 1 , 000 1 , 500 2 , 000 2 , 500 3 , 000 3 , 500 0 図 8 ReaISystem へのアクセス数の推移 0 10 , 000 20 , 000 30 , 000 40 , 000 50 , 000 アクセス数 - のああ にの 0 視聴時間 ( 単位 : 1 , 000 時間 ) 0 5 , 000 10 , 000 15 , 000 20 , 000 3 ② 3 3 0 0 0 0 3 0 0 0 0 0 0 ②① 試合数 表 1 RealSystem へのアクセスイ頃向 期間 : 1998 年 8 月 6 日 ~ 22 日 0 」 ( つ寸 l.n CD ト 0 図 9 8 月 21 日 ( ピークアクセス ) の同時アクセス数のキ多 ライブ十アーカイブ ライプ 総アクセス数 総期削 ピークアクセス アーカイプ 総アクセス数 総ネ期削慟 116 , 595 回 約 22 , 683 時間 ( 1 アクセスあたり約 700 秒 ) 699 同時アクセス ( 約 14Mbps) 期劵第 1 試合 ( 兵対明徳さ ) 11 : 00 頃 92 , 309 回 約 653 制 ( 1 アクセスあたり約 25 秒 ) アクセス数 800 1 0 200 300 400 500 600 700 100 週末には大きく落ち込んでいます。図 6 からは、試合と試 合のインターバルでアクセスが一瞬がくっと落ちる傾向が はっきり分かります ( 試合のない夜間や与朝は静かな様子 も見てとれます ) 。 ReaISystem 5.0 スプリッタサイトとしては、 media CONNECT と Hi-HO の合計 6 台て漣用しました。こちらのほうも、試 合が白熱するにつれてアクセス数が急ー E 昇しています俵 1 、図 8 ~ 9 ) 。 ReaIVideo のアクセス元ドメインは、逆引きを除けば co. jp か物「然トッフ。で、以下 or. jp 、 ac ・ jp 、 ne. jp の順で す。これらか、本のアクセスの大半を占ています 2 。 2 ・仕事や奐男虱こかなりの景を与えているのでは・・ UNIX MAGAZINE 1999.9 6 ライブ アーカイブ ノ 12 24 時間 運用結果と問題点 183 これほど大量のアクセスを受ける場合には、ネットワー 380 万 / 日 ( いすれも準々 : 刔という結果でした。 フィック、ヒット数は 3 , 200 万 / 日、ページアクセスは WWW サーバーからの送出は最大で約 40Mbps のトラ を集めたため、きわめて激しいアクセスになりました。 昨年の高校野球は好カードが続いて例年にない人気

2. UNIX MAGAZINE 1999年9月号

質値 (Quality Value) 0 による、要求なし " の指示 ( 3.9 節 ) ・ HTTP バージョン番号の使用と角い 3.1 節 ) ・文字セットのワイルドカード化 ( 14.2 節 ) ・ Cache-ControI モデルーの s-maxage の例の追加 ( 13 .4 、 14.8 、 14.9 、 14.9.3 節 ) ・ Cache-Control の max-age 命令の ) 芯答を日埆寉に定義 ( 14.9.3 節 ) ・コンテンツ長 0 ンヾイト列 (byterange) を適用できる機 構の導入 ( 14.16 節 ) ・サーバーが 206 応答内の必要なヘッダのみを送出でき るオ冓の導 . 入 ( 10.2.7 、 13.5.3 、 14.27 節 ) ・ 416 状態コードの導入 ( 10.4.17 、 14.16 節 ) その他の変更点としては、日Ⅲ御ヒのためのメッセージの 書換えなどがある。 RFC2617 HTTP Authentication. Basic and Digest Access Authentication HTTP 認証基本アクセス認証と要約アクセス認証 DS. 、」 . Franks 他 ( RFC2069 ) RFC2069 で規定された HTTP の基本アクセス認証 と、さらに安全生を考慮した要約アクセス認証を定義して いる。現在の状態は、、標準化の草稿 " である。 RFC2069 を置き換える RFC として 1999 年 6 月に公開された。 HTTP/I.0 で定義された基本アクセス認言正樹冓は、ユ ーサー名やパスワードがネットワーク上で平文のまま受け 渡されるため安全ではない。 RFC2617 では、この基本ア クセス認証欟冓のオプション要素の見直しなどをおこなっ ている。 RFC2617 で新たに加えられた要素はオプション であるが、強く推奨されている。 また、基本アクセス認証のパスワード送信部分をノ、ツシ ュ符号化した、、要約アクセス認証 " 機構を新たに定義し、 HTTP の全体的な認証フレームワークを形成している。 要約アクセス欟冓ではネットワークに送信するパスワード が符号化されるので、基本アクセス認証をそのまま使うよ りも安全なアクセスが可能になる。 セキュリティ関連 RFC2560 X. 509 lnternet Public Key lnfrastructure Online Certificate Status ProtocoI- OCSP 158 X. 509 インターネット公開鍵インフラストラクチャ・オン ライン証日艪熄プロトコル : OCSP PS. 、 M. Myers 他 CRL (Certificate Revocation List) を利用せすに電 子証明書の状態を決定するための OCSP (OnIine Cer- tificate Status Protocol) を定義している。現在の状態 は、、標準化へク是唱 " である。 1999 年 6 月に公開された。 RFC2585 lnternet X. 509 Public Key lnfrastructure Operational Protocols• FTP and HTTP インターネット X. 509 公開鍵インフラストラクチャ里 プロトコル : FTP と HTTP PS. 、 R. Housley 他 FTP (File Transfer ProtocoI) や HTTP を利用し て PKI (Public Key lnfrastructure) レポジトリから証 明書や CRL を入手する去を定義している。現在の状態 は、、標準化へク是唱 " である。 1999 年 5 月に公開された。 RFC2587 lnternet X. 509 Public Key lnfrastructure LDAPv2 Schema インターネット X. 509 公開鍵インフラストラクチャ LDAP 第 2 版概要 PS. 、 S. Boeyen 他 RFC2559 で定義された LDAP (Lightweight Di- rectory Access Protocol) v2 における PKIX ( X. 509 PubIic Key lnfrastructure) のサポートについて述べて いる。現在の状態は、、標準化へ窈是唱 " である。 1999 年 6 月に公開された。 RFC2587 では、 PKIX を LDAPv2 てサポートする ための必要最小限の規定を加えている。おもなものは、 ・ PKIX レポジトリとして重川している LDAP サーバー 上記の LDAP サーバーと通信する LDAP クライア で利用される、 PKI 情報に関する問合、追加、更新、削 除用の属性およびオプジェクト・クラスである。 RFC2612 The CAST-256 Encryption Algorithm CAST-256 暗号イヒアルゴリズム 旧 fo. 、 C. Adams 他 CAST-256 暗号化アルゴリズムについて言当している。 、、広報 " として 1999 年 6 月に公開された。 UNIX MAGAZINE 1999.9

3. UNIX MAGAZINE 1999年9月号

図 3 高校ホームページ イ 0 第事響旅り摎継きこ入り、ル ] おリー アト、スノ / “一 00 第 / p ・ ( ・勹、・トを 1 は 1 2 3 4 5 6 ラも計 : 京都第第第ので : 第 0 毎 幽当・、な第 : し 1 0 , 0 亶を - 3 打者 , 打数ま打本塁打率 s 本大 ~ 厂の 地方大会「・蔔 " " " 0 「 0 ー 0 連載 Cyber Kansai P「0 」 ect 図 5 大会最終週の MRTG のグラフ 容同 32.0 24.0 い 8.0 0.0 M ~ つ 1 外 - 4 ーこ、、を ( ) 行 , イト物 し 20 øiCtU ′・ & Sat Sun Mon Tue wed Thu Fri Sat 図 6 8 月 21 日 ( ピークアクセス ) の MRTG のグラフ 鉐 .0 27.0 9.0 、 0.0 M 8 回裏ハイライト・シーン 伍 62 0 ( 595 心 4 ・社中 1 書青中新 安打で、第をり、ら安打を馭ニ 第夏の甲子■第を 22 0 2 4 6 8 10 12 14 16 16 20 22 0 2 4 6 式を採用して、過去 6 時間にわたって 10 分ごとの変化 カ甘当屋できるように HTML を重加勺に作成しました。 代表校データ ! 物交、選手へのアンケートをもとに作成しました。 応メール 一般放送では難しく、インターネットの特徴であるイ ンタラクテイプ生を活かした試みです。視聴者から代 表校、選手への施援メールを募集し、即座にホームペー ジに掲載しました。 アクセス分析 ネットワークのトラフィック分析 ロ◆ アクセスは昼間だけで、試合と試合の合間にはやや落ち クリックすると MPEGI または RealVideo によるハ 込むというきわめて特徴的なトラフィック傾向が出ていま イライトシーンか再生されます。準々 : 刔劵からは、全試 す。 : 刔劵戦に近づくにつれてアクセス数カ喞びるのは当然 合を ReaIVideo 形式て保存しました。 ですが ( 図 5 ) 、横浜高校 ( 現・西武ライオンズ ) の松坂投 手か好投した試合でアクセス動向を観察していたところ、 本塁打、学校名、選手名などのキーワードの入力によ 秒単位で急激に増えていく様子がはっきりと分かりました り、作成されたハイライトシーンから検索できます。 ( 図 6 ) 。もちろん、 Web サーバーを収容していたスイッチ ・生中継 ング・ハプの、トラフィックを示すインジケータは常点 ReaIVideo を用いた生中継で、電話回線によるダイヤ 灯状態で、すさまじいと形容するはかはない状況でした。 ルアッフ。接続を考慮して、 20Kbps ( 映像 13.5Kbps 、 WWW 音声 6.5Kbps) の或にしました ( 図 4 ) 。さらに、ス プリッタを 6 カ所に配置して混雑の緩和を図りました。 期間中の総アクセス数は約 1 億 7 , 000 万件で、通常の 天気情報 サーバーや httpd ではとうていさはききれなかったでしょ 甲子園球場に天気センサーを設置し、温度、湿度、気 う。途中で Web サーバーを 2 台にし、 DNS ラウンドロ 圧、風畆丿囎悪雨量などの気象情報をほばリアルタイ ビンでアクセスを分散させました。図 7 を見ると、ほは半 ムで表示しました。気象予報士からの要望で、現在の数 分くらいに散っているのがよく分かります。 値のほか、象状冫足の変化を記載するために簡単な表形 会社や学オ交からのアクセスか圧倒的に多かったためか、 いお第らせ - は一 図 4 ReaIVideo による中継 EiIe 5 い Re 引 P 扈 y 、 K ” h 098 [ 工司ー ! 」一国回中 前を : み記 阯み日 0.0 ョ J 印 41 : 39 、 4 / 494 ? Pl&Ytng 20.0 Kbps 引 fiie 182 UNIX MAGAZINE 1999.9

4. UNIX MAGAZINE 1999年9月号

者については、過去の履歴をベースにすれば制御できる、 後者については、 HTTP であれば・可能だが、 FTP のよ うに往復の経路か違うと面倒である、という回答だった。 ・主記憶を用いた分散 WWW キャッシンクフ。ロキシー 西川記史 ( 日立製作所 ) 現在のキャッシュの間題は、高負 : 荷工竟でポトルネック になる点とヒット率ががらない点にある。ポトルネック になる一因は、ディスク I / 0 か遅いからである。あるキャ ッシュ・サーバーのディスク I / O を角財斤したところ、大き なデータを除くと IURL 勺 3KB で 100 回 / 秒の入出 力が発生していた。そこで、高負荷工竟においてはディス クでのキャッシュは限界であると考え、 Web キャッシュ に己慮を用いることを提案した。 Web トラフィックを角財斤した結果、 90 % 以のページ は 1 日 1 回以下のアクセスであった。そこで、高アクセ ス頻度のページのみをキャッシュすることにし、アナライ サによってログを分析し、キャッシュする URL をプロキ シー・サーバーに孑ヾするシステム構成をとった。大規模 ネットワークでの利用を想定して階層型構成にし、 10 日ぶ んのアクセスログを用いてシミュレーションを実施した。 プラウサでは 8MB のキャッシュを仮定し、プロキシー サーバーには Web キャッシュ用として主記應 64MB を 石何呆した。そのうえで、アクセス頻度にもとづくコンテン ツ邇尺をおこなうキャッシュ、単純なラウンドロピンによ るキャッシュ・システムを上交対象とした。 その結果、階層が - ド ( ューザー端末寄り ) のキャッシュ では 3 % 、上のキャッシュでは 6 % 程度のヒット率改善 がみられた。本でもヒット率は 1.2 イ部呈度改善されてお り、利用価値はある。 パネル言「キャッシュ技術、今そして未来」 コーディネータ : 鍋島公章 (NTT) ノヾネラー 石川智之 (TeaCup Communication) 秋山ゆかり ( プライスウォーターハウスコンサルタント ) 牧野二郵 ( インターネット弁護士 1 義幻 ・キャッシュ技術の動向 鍋島公章 はしめに、今回のワークショップを企回されオゴ咼島氏か ら、キャッシュ技術の動旬について説明があった。 152 キャッシュ・サーバーの性能で注目されるのはヒット率 だが、新たなプロトコルの開発によってもうすこし上がる であろう。キャッシュ・サーバーに蓄積されるデータは、 大では HTML ファイルなどのテキスト情幸ゞ大半を占 めるが、今後は映像などのストリームが中心になっていく だろう。そうなった場合、たとえは約 IMbps の或を消 費する VHS レベルの画置央像をキャッシュできるサー バーが必要になる。キャッシュやミラーなど、最適な情報 配置とそのナビゲーション技術はさかんに研究されている が、まだまた改善のせ也がある。 キャッシュに関連し、ヨーロッパでは情報の複製と著 イ雀カ墹題となっている、日本ではまた判例はないか注意 が必要である。また、山も丘はキャッシュされないコンテン ツも多くなっている。 ・掲カ反サービスにおけるプロキシー・サーバーへの期待 石川智之 TeaCup Communication(http://www.tcup.com/ は石川氏カ咽人て始めた掲カ反サービスで、現在はサーバ (Linux を使用 ) が 8 台、掲万財反の数が 15 万、 1 日の アクセス数が 250 万ページの規模に成長した。 掲カ反サービスは一殳に CGI を使っており、アクセス するたびに HTML ファイルの内容が変わる。したがっ て、キャッシュ・サーバー管理者からみるとキャッシュ の効果が下がるのカ貘俺点である。一方、掲カ反サーピス利 用者にとってのキャッシュ・サーバーは、アクセスのプロ キシー・サーバーとしての側面か重視されており、アクセ ス元を隠すための道具という認識か強いようだ。利用する 理由としては、匿名ならではの自由な情報交換、自己のプ ライバシー防衛、いたすら / 犯罪の 3 つが多い。 匿名性の需要は確実にあり、プロキシー・サーバーを経 由した迷惑行為に対して発信者を特定できるイ督はみは必要 だが、大ではまた整備されていない。 TeaCup では、発 信元 IP アドレスによりアクセスを拒否する機能を用意し、 掲カ財反管理者が 3 つのモードから選べるようにしている。 プロキシー・サーバー管理者に対しては、代理アクセス であってもアクセス元としての責任を感してはしい、ログ をタイムリーに提供できる体制を整えてほしいといった要 望があった。ログの保存期間については、間題が起きても、 すぐにプロキシー・サーバー管理者に叫各がいくわけでは ないので、 2 週間程度は保存しておくのか望ましい。 UNIX MAGAZINE 1999.9

5. UNIX MAGAZINE 1999年9月号

連載 /UNIX Communication Notes— 図 7 RSA 公開音号による認証の堋 $ slogin basecamp. aist—nara ・ ac ・ JP 0 Executing /usr/local/bin/sshl for sshl compatibility. Enter passphrase for RSA key ) suguru@portable.aist—nara. ac ・ JP Last login: Sat Ju1 24 07 : 08 : 24 1999 from ppp ・ isp. net ードによる認証 ( 図 5 ) と大きく違うのは、ローカルに置 かれている秘密鍵を復号するためのパスフレーズを入力し ている点である。これで、安全にアクセスできるようにな る。 ノート 9 /. ssh2 に置く identification や authorization よ どのファイル名は、 /etc/ssh2/ssh2-config と /etc/ssh2/ sshd2-config に言当されている。したがって、これらの設疋 ファイルを変更すれば、まったく違う名前にすることかできる。 SSHI り、この ~/. ssh/authorized-keys ファイルに複数の に複数の公け准建を指定する場合、 SSH2 のときとは異な としてコピーする。複数のホストからアクセスするため る identity. pub を ~/. ssh/authorized-keys ファイル 2. サーバー側では、クライアント側の公開鍵ファイルであ 1. クライアント側ではとくに設定の必要はない。 る。設定ガ去は、 SSH2 の場合とはは 1 司じである。 SSH 1.2.27 では、 RSA 公開鍵暗号による認証ができ 公開鍵を保存する。 3. サーバー側でのデーモンの設定を石忍する。 /etc/sshd-config ファイルに RSAAuthentication yes とⅱ当されているかを石忍する。もし、 RSAAuthentication no となっていたり、そもそも記がない場合は適切に する。 / ート 10 双 . 正 SSHI では、認証方式として (I)RSA 認証、 ( 2 ) ホス ト RSA 認証付き rhosts 認証、 (3)UNIX パスワー〔 (4)rhosts 言の 4 不鶤頁が用意されている。セキュリティ面を 考えると、 ( 3 ) と ( 4 ) の利用は勧められない。したがって、 PasswordAuthentication Ⅱ 0 RhostsAuthentication Ⅱ 0 と設定するはうがよい。 ( 2 ) のホスト RSA 認証付き rhosts 48 認証は単純な rhosts 認証よりも安全ではあるが、システムに 侵入された場合に踏み台にされる危険か高いため、 RhostsRSAAuthentication Ⅱ 0 のように、利用しない言置にしたはうがよい。 これで設定は終了である。 このように設定したうえでアクセスすると、図 7 のよ うになる。 SSH2 の場合と同様、クライアント側で RSA の秘密鍵を復号するためにパスフレーズの入力を求められ こで正しく入力すれば、ログインできる。 る。 設定ファイルについて SSH 1.2.27 と 2.0.13 では、サーバーとクライアント の設定ファイルでさまざまな設定ができる。より細かく設 定したいときはこれらのファイルをカスタマイズするとよ い。偂頭で述べたサーバー側での認証方式のはかに、一ド記 のような設定も可能である。 ・ホストの秘靆 / 公開鍵ペアとして使うファイル窈旨定 ・乱数生成のためのシード (seed) の値を設定している ファイノレク旨定 ・アクセス制御 ( ホスト名、 IP アドレス、ユーサー名、グ ループによるアクセス制御が可育 管理者は、この機能を利用して管理の手間を軽減でき る。もちろん、これらのアクセス制御がおこなわれて も、ユーサーレベルでの認証は実施されるのでセキュリ イスの指定 ・サーバーカ材妾続待ちをするネットワーク・インターフェ を受け付けるが、これも変史できる。 標準では、サーバーは TCP の 22 番ポートて寸妾続要求 接続受付けポート番号窈旨定 ・ root ログインの制限 ティ・レベルは低下しない。 UNIX MAGAZINE 1999.9 クエストだけを処理したい場合に便利である。 特定のネットワーク・インターフェイスから受信したリ

6. UNIX MAGAZINE 1999年9月号

0 連載 /UNIX Communication Notes— 図 8 SSH によるポート車医の冓 ホスト B ホスト A アプリケーション クライアント アプリケーション ポート N 号 SSH クライアント ポート X ポート 、 : OS が任意に割り当てるポート に、 TCP ポート番号 X でローカルからのポートアクセス ・通信路の暙号化に利用する暗号化方式の指定 を待つ。この場合、次のような利点がある。 標準では IDEA 暗号を使うが、それ以外にも DES 、 Triple DES (3des) 、 blowfish などが利用できる。 ・ネットワークを通過するデータはすべて SSH によって 最大同時処理コネクション数 暗号化されているため、盗聴によって情幸肋弱れる危険 これによって使用不能攻撃が防げる。 性がない。 アフリケーション・サーバーにはいっさい手を加えるこ 言岩田は、マニュアルページ ssh ( 1 ) 、 sshd ( 8 ) を : 参具 となく、安全にサービスか利用できる。 してはしい。 このような構造は、クライアント側の ssh を起動する 高度な使い方 ときのオフション指定で夫現できる。 ssh コマンドには、 SSH には、このほかにも強力な機能が数多く用意され 、、一 L " オプションがある。これは、 ている。なかでも、ポート転送 (port forwarding) は、 ー LIoc - 0 : 7 ℃ mo - ん ost : 7 ℃ rno カ e ー〃 0 置 暗号化機能のないインターネット・サーピスの通信路暗号 のように使う。図 8 の例でいえば、 化を見する、たいへんイリな機能である。 ポート中幻とは、簡単にいえば SSH のサーバーとクラ ssh —LX : A : N A イアントとのあいだに暗号化のためのトンネルを作る機能 として ssh コマンドを起動づ - ・れはよい。 である。通常のインターネット・サービスでは、サーバー側 以下のような状況で使う例をみていこう。 は特定の番号のポート (well-known ポート ) でコネクシ ホスト basecamp. aist-nara. ac. jp の sendmail に対・ ョンを受け付けるカ式を使っている。たとえば、 sendmail するアクセスで SSH によるポート中幻機能を使う。 は 25 番ポート、 Web サー ー (http) は標準で 80 番 ・ローカルのホストでは、ポート番号 3333 番でこのロに ポートを使う。一方、クライアント側では OS か割り当て アクセスできるようにする。 たポートを利用するため、クライアント側のポート番号は 実行時に決定される。 ます、図 9-a のように、 -L オフションでポート転送 図 8 は、 SSH の機能を用いたポート転送の様子を表し を指定して ssh を起動する。通常の ssh でリモートシ ステムにアクセスしたときと同しように、認証のためのパ ている。ます、ホスト A では、 TCP ポート番号 N で アプリケーション・サーバーか稼動している。このホス スフレーズ ( パスワード認証の場合はリモートホストの トで SSH のサーバーを不力しておく。 SSH サーバーは、 UNIX パスワード ) の入力をおこない、リモートシステム basecamp ・ aist-nara ・ ac. jp にログインする。 ローカルにサーバーへのアクセスをおこなう。クライアン このとき、クライアント側で netstat コマンドを使って ト側のホスト B では、 SSH クライアントがホスト A の TCP ポートの使用状況をみると、図 9 ー b のようになって SSH サーバーに接続し、暗号イし凾信路を提供するととも SSH ポートサーバー ポート 22 49 UNIX MAGAZINE 1999.9

7. UNIX MAGAZINE 1999年9月号

サイバー関西フロジェクト 士田ー、香取啓志、沖本忠久 甲子園 ' 98 はじめに UNIX MAGAZINE 1999.9 1 http://koshien.asahi.co.jp/ ( 8 月 1 日 ~ 31 日開言効 の場としても高い価値があります。 り、連続して大量のアクセスがあることから、実験・本正 盤は徐々に整備、増強されてきました。約 2 週間にわた インターネット利用者の急な増大とともに、これらの基 Ultra1 が 1 台という構成て漣用されていました。その後 トへの接続は TI (1.5Mbps) で、サーバーとして Sun ターネット中継を実施しています。当初は、インターネッ 朝日放送と CKP は、 1996 年から夏の高校野球イン 中継実験の概要 1 ネット中継の本嘯策を振り返ってみます。 今回は、アクセス数が急激に増加した昨年度のインター しています。 関西プロジェクト ) では、積構均にこの大イベントに協力 ネットでの生中継もおこなっています。 CKP ( サイノ レビ、ラジオはもとより、ハイビジョンや CS 、インター て第 80 回記念大会か開催されました。朝日旄では、テ 昨年は、 8 月 6 日から 8 月 22 日までの 17 日間にわたっ 々 : 期劵あたりを迎えていることでしよう 読まれるころには、高校野球で一一 - ・番白熱するといわれる準 セス件数も年を追うごとに増えています。皆さんがこれを ておこなわれています。毎年、新たな試みに羽馘し、アク インターネット中継は、 1996 年から朝日放送を中心とし る夏の甲子園高校野球 ( 全国高等物交野球選手権大会 ) の インターネット上の大規模イベントとしてよく紹介され コンテンツとしては、 1996 年当初は Web をベースに したものが中心でしたが、ストリーム技術の発達とともに RealVideo などのストリーム配信のニーズも高まってい ます。 夏の咼校野球中継では、医局ならではの映像を含めた さまざまなコンテンツカ甘是供されています。 1998 年の甲子園では、以下のような実験的耳目みがお ・選手情報、地区大会成績、天気など 3. その他の嬲叫青報 ・ハイライトシーン映像 (RealVideo 、 MPEGI) 2. オンデマンド・サービス ・ RealVideo による実況中継 ・試合情報窈是供 ( 得点、 SBO 、打者名、打率など ) ・試 , 大況の JPEG による擬似リアルタイム中継 1. リアルタイム・サービス —IX モテル (NSPIXP3) におけるイベント・トラフィ ー大容量 Web サーバーの構築・運用技術 ー大規模情幸財是供サーバーのアクセス挙動角斤 ・インターネット技術の実証実験 System G2/SMIL の利用 ) ーテレビ番組に似た情幸財是供 ( 重丿 CM の挿入、 Real- ステム ) ーコンテンツ生支術 ( インターネット向け簡易編集シ ーテレビとの融合 ( データの相利用、メディアイり 旄医技術の観点での実験 医と通信の融合 こなわれました。 ックのアクセスパターン本正 179

8. UNIX MAGAZINE 1999年9月号

キャッシュ・サーバー管理とプライバシーの「に関し ・インターネット・マーケティングから観た Web キャッ シュの ~ 来 秋山ゆかり ては、とくにログの扱いが重要である。キャッシュ・サー バーの管理者は、ログの内容について守秘義務がある。ロ インターネットをマーケティング・ツールとしてみた グの保管義務に関してはまた滸磊義がおこなわれている段階 とき、おもな利用形態は広告である。インターネットを使 だが、それよりもログに対するクラッキングに注意を払う う利点は、対象を絞り込んだマーケティングが可能になる べきであろう。管理者は、技術だけでなくモラルの面でも ことにある。 Web ページ上にノサーを配置する形態がよ 高い水準カ腰求される。 く知られているが、ほかにもメールやブッシュ技術を使っ 質題芯答では、たいへん活発な奇義カ咬わさ予定さ たものがあり、標純勺な料金体系も決まっている。 れていた終了時刻を 1 時間半もするほどだった。 キャッシュ・サーバーでは広告もキャッシュするため、 Web サーバーにおけるバナー広告へのアクセス数も減っ ☆ てしまう。夫第のアクセス数と Web サーバーでのアクセ 数 0 比は、、勺で 100 = 00 、著名なサイトでは、 00 = 0.15 Web アクセスに対するユーサーからの要求は厳しく、 さまざまな立場でキャッシュ技術に携わる方たちは、そ にもなる。しかし、キャッシュ・サーバーでのアクセス れに応えるべく積極的な姿勢で間題に取り組んでいるよう 数は Web サーバーの管理者には伝わらないため、広告主 です。今回のワークショップでは、その面で有意義な清報 は効果を測れす、マーケティングではキャッシュ・サー をお届けできたのではないかと思います。 ーは、邪魔者 " 扱いであった。だが、キャッシュされた ノヾ 最後になりましたが、会場を提供していだいた住商工レ ノサー広告もユーサーに見られているので、広告の効果は クトロニクス株式会社にお礼を申しあげます。 あるはずである。そこで、去も匠はキャッシュ・サーバーの つ勉強会のお知らせ 存在を前提とした料本系を組むなど、新たな広告評価基 準か作られつつある。 Web の、、ネ期思率 " を調査する会社も テーマ . もう IMAP から離れられない 出てきており、キャッシュ・サーバーとマーケティングに 講師 : 渡部直明 ( オレンジソフト ) 関する問題は鮹夬の方向に向かっている。 日時 : 8 月 25 日 ( 水 ) 18 : 30 ~ 20 : 30 今後は / サー広告の割合は下がるが、それでもインター 会場 : 丸正ホール・大会議室 ネットを利用したピジネスモテルは広告モデルが羽充にな 東京者辟万宿区四谷 3 ー 12 メい E ピル 6F ると予測される。かなり以前からあるキャッシュ・サー 地下鉄丸ノ内線四谷三丁目駅下陣徒歩 2 分 ーをいまさらなくすことはできないので、マーケティン 定員 : 80 名 ( 事前申込み定員 : 70 名 ) グとの共存関係を作る必要がある。 事前申込み方法 : Subject 行に help とだけ記したメール ・キャッシュの法的考察訌朝侖 を reserve@jus ・ or ・ jp 宛にお送りください。折り返し、 申込みガ去の田を自動」いたします。なお、事前申 現在、言儒義されているのは、キャッシュデータは著作者 の許可を得て置いているわけではなく、著イ料福の観点 込みクメ帝切は 1999 年 8 月 23 日 ( 必着 ) です。 内容 . 自身の運用経験にもとづいて、事例を挙げながら からみると避去ではないかという問題である。キャッシュ IMAP4 の機能、サーバーやクライアントについて説明 データ窈却勺な未付けか羽埆寉になっていないため、侖 します。すこしでも多くの方に、メールサーバーも進化 カ咄るまでにはまた相当な時間がかかるであろう。著作者 すべき時期にさしかかっていることを実感していただけ のイ頁を石呆し、ユーザーの利便性を損なわないようにす ればと思います。 ることか基本である。 対象 : 企業や大学などのメールサーバーの運用担当者、 もう 1 つの問題は、日本では閲覧が許されないような IMAP4 についての知識を得たい方。 情報 ( 猥褻情報や軍事情報など ) もユーサーがアクセスす れはキャッシュされてしまうという点にある。これにつ いては、翫意にその種のデータを保存しようとしないかぎ り、責任を問うことはできないと思われる。 ノヾ 153 UNIX MAGAZINE 1999.9

9. UNIX MAGAZINE 1999年9月号

少ないキャッシュ容量てデータを有俐用するために 会場からの「マルチキャストで HTCP を使った場合 データ置換えアルゴリズムを改良した。置換えアルゴリズ はどうか」という質問に対しては、マルチキャストでも復 ムに LRU (Least Recently Used) を適用し、丿ひ大学 路のバケット数は同しであるとの回答だった。 の Squid ( キャッシュ容量 20GB) のログを用いて、現 ・ WWW 代理サーバーのアクセスログからのページ単位 状のヒット率と LRU 適用後のヒット率のシミュレーショ 普天間智 ( 大阪府立大学 ) の角財斤手法の提案 ンをおこなった。分析の結果、キャッシュ容量 500MB WWW 上の同一ページに含まれるオプジェクトへのア ぐらいで Squid と同しヒット率カ材等られるが、利用率は クセス傾向を調査し、ユーサーの視点から WWW システ Squid 方式と上交して大差なく改善はみられなかった。ヒ ムを改善する手法を探った。 ット率以外の評価は、実装しないと実施できない。 ューザーの挙動を十ヾるために、代理サーバーのアクセ 会場からは、「完全な LRU の実装は大変なので、 Squid スログの角財斤にもとづき、ページ単位のアクセス傾向を分 の hashbucket を大きくするガ去をとったらどうか」と 析した。 HTML ファイル名をユニークな ID としてペー いう質問に対しては、「 hash bucket を小さくしているの ジを切り出し、 HTML ファイルを角財斤して埋め込まれて は芯間を考慮しているためであり、そのガ去は考えて いるオプジェクトを判定している。ページ単位で中幻する いない」との回答だった。今後の課題として、 LRU 以外 ように HTTP を改善すれは冲幻効率が上がる、プラウザ のアルゴリズムも検討したいとのことであった。 でページを表示する際にレイアウトを再計算できるように したほうがよいのではないか。 ・ Web におけるアプリケーション・ルーティング技術の ・投機的キャッシュ法における複数サーバー秀方式の 渺皀正浩 ( 東北インターネット・義会 ) 甫豊徳 (NTT) ネットワーク層によるトラフィック分散は運用コスト ルータの処理能力か 1 矼ヒし、バックポーン回線には余裕 が大きくなるわりに肋攤しく、アプリケーション層に が生じた一方、アクセス回線がポトルネックになってい よって缶卩したほうがよいのではないか。マルチホームの る。そこで、あらかじめキャッシュすべきコンテンツを 経路制御は難しいので、外部情報 ( 経路情報など ) と中継 決め、それを単位日判爿ごとに更新する、投機的キャッシュ 技術 ( プロキシーなど ) を組み合わせて最適な経路選択が 法 " を考案した。 できるようにすることが目的である。 具イ勺には、数日前のアクセス頻度データを用いてキャ 既存の竟 , 、、の景を最小限にするために、、、首振りサ ッシュするコンテンツを決めて実施した。対象外のデータ " を使用する。これはクライアントからリクエスト はキャッシュせす、サーバー上でデータか更新された場合 を受け、外部清報を参考にしてどちらのプロキシー・サー はキャッシュ・サーバーに通知がくることか則提である。 ーに医するかを決定する。この際、経路〕尺に使える 実験の結 1 日のデータ中幻量は 400MB 、その標準偏 外部情報は、プロキシー・サーバーから目的サーバーまで 差は 132MB となった。そして、普通のキャッシュ・サー の RTT 、過去の転却間、経路情報による距離、青勺ポ ーより高いヒット率カ等られること、使用したアクセス リシーである。 Squid 2.1P2 をベースに、 parent5# 尺を 履歴によってヒット率はかなり変わることが分かった。こ 重加勺におこなう部分を追加して実装する予定である。 の結果をもとに、キャッシュ構成ガ去を検詞すると効果が この手法には、ネットワーク層の間題に依存しない、過 あるのではないか。 去のログや RTT などの各種の情報を利用できるといった 会場からの「頻度データを 1 時間あるいは 1 週間単位 利点がある。一方、首振りサーバーのオーバーヘッドが気 でとったらどうか」という質問には「 1 日単位にするのが になるといった間題点もある。 もっとも結果がよかった」、「頻繁に変更されるようなコ ンテンツの場合はどのような結果になるか」という質問に 質題芯答では、「時間帯によって描商な経路が変わった は「今後の訝題としたい」との回答だった。 りする ( 昼休みだけ混んでいる経路など ) が、その場合は どう対処するのか」「 1 つのサーバーに複数のインターフェ ・ WWW キャッシュにおけるデータ置換えアルゴリズム イスを付けたほうが楽ではないか」という質問カ咄た。前 昜雄一・一、 ( 馗日大学 ) の研究 1 一口 ーノヾ ノヾ 151 UNIX MAGAZINE 1999.9

10. UNIX MAGAZINE 1999年9月号

法本告之 NEWS from (')))>Japan WebCache Workshop 報告 インターネットの普及と Web の利用者の急な増加に ともない、 Web 上のデータを有効に再利用するキャッシュ 技術の重要生か認識されつつあります。 jus では 4 月 23 日に、キャッシュに関する去辭斤の研究成果の発表や現状報 告、新たな研究課題などについての言侖や青報交換を目的 としたワークショップを開催しました。 このワークショップは 13 負 ) 研究発表とバネル・ディ スカッションから構成され、約 100 名が参加してのこ もった言義がおこなわれました。 以ード、プログラムの頂を追って内容を報告します。 松本英夫 (IIJ) Chair : 鍋島公章 (NTT) ・比中如勺大堋莫なプロキシー・サーバーの運用 セッション 1 UNIX MAGAZINE 1999.9 ャッシュを続けるかどうかを含めて検詞する必要がある。 み台にした不正アクセスに利用される危険生を考慮し、キ 今後は、運用コストの増大や、キャッシュ・サーバーを踏 48 % を占める。 れるファイルは全体の 3 % しかないが、トラフィックでは URL は 1 回しかアクセスされす、 10 回以 . E アクセスさ ダイの景強く受けていることが分かる。本の 7 割の 発生しており、 ISP のキャッシュ・サーバーはテレホー トラフィックの半分は午後 10 時 ~ 午前 3 時の 5 時間に IIJ では Squid を利用している。糸をみると、 1 日の した運用を可能にするといった点か挙げられる。 ト率を向ー E させ帯域削減の保を上げる、低コストで安定 は、導入によって応答性が悪くならないようにする、ヒッ キャッシュ・サーバーが導入されている。言 t 方針として 多くの ISP で、応答性の改善や帯域削減を目的として ッシュ・サーバー運用列の報告。 大手 ISP (lnternet Service Provider) におけるキャ ・ firewall 内の proxy/cache server によるリレー 一一條博 ( ケンウッド ) 企業内ューサー向けにキャッシュ・サーバーを提供した ときの効果を知るために、擬イ勺な環境を用意して性能測 定をおこなった。 インターネット接続には研究開発部門の回線を使用し、 キャッシュ・サーバーは一ド段プロキシー (Squid) 、ファイ アウォール (delegate) 、外部プロキシー (Squid) という 構成である。ここに netperf による擬似トラフィックをケ え、 webstone を用いて掟した。その結果、おおむね 30 ~ 50 % 程度のヒット率か碍られること、 OS (FreeBSD を使用 ) のチューニングや Squid の設定によりさらに効 果が上がることなどが分かった。 質鼬芯答のなかで、「企業内ユーザー向けのキャッシュ・ サーバーが遅いと、自分の PC を会社の電話経由で ISP に接続し、それをさらに LAN につなぐようなことをする 人力咄てくる。こういった風朝がひろまらないようにする ためにも、性能を系財寺する必要がある」という、考えさせ 149 ・サーバー ( 準公開キャッシュ ) において、複雑なキャ サーバーだけがアクセスできるように設疋されたキャッシ 網か構築できる。組内利用者と求した外部キャッシュ・ 糸目系測で Squid を叫秀させると、より大きなキャッシュ 大釜弘 ( 徳島大学 ) ・準公開 Squid 相互接続一刻爰システムの運用 験カ始められつつあるといった話も紹介された。 アジア地区で、衛星マルチキャストによるキャッシュ実 parent 接続を中心に再構成することを検討中である。 こで、 sibling 接続をやめ、 WIDE 対タ材妾続 NOC への のヒット率が低いために応答時間が遅くなっている。そ なりの差がある。 HTTP のヒット率は約 40 % だが、 ICP キャッシュ容量は、サーバーによって 10 ~ 256GB とか 2 ホップまでの NOC と sibling 接続をおこなっている。 構成は、各 NOC にキャッシュ・サーバーを設置し、 で運用しているキャッシュ・サーバーについての報告。 W4C (WIDE WWW Cache) ワーキング・グループ 川本芳久 ( 大坂大学 ) ・ WIDE CacheBone の言気と運用報告 られる言劼ゞあった。