インターネットの急速な発展にともない、ネットワークを通じてさまざまなサービスが今日提供されている。それにともないサーバーへの負担は大きくなる一方であり、それを回避するため、同一のファイルを置いたミラーサーバーが利用されている。
さて、利用者にとって、どのミラーサーバーをどのような根拠で選べばよいのだろうか?まず、考えられるのは、サーバー側で提供している情報を人間が主観的に判断して選択する方法である。例えば、サーバーがアメリカと日本にある場合、日本からは日本にあるサーバーを選ぶ方が良いと考えられる。しかし、過去のマイクロソフトのサーバーのように、日本からアクセスしてもアメリカのサーバーの方が良かったというような事例もあり、必ずしもそのような判断が有用であるとは言い切れない。また、東京からアクセスする場合、京都のサーバーと大阪のサーバーのどちらが良いかなど判断が必ずしも容易でない場合もある。
一方、従来しばしば行われてきた方法としては、目的のサーバーまでダミーのパケットを飛ばし、往復の時間を計る方法がある。インターネットに接続しているコンピュータなら必ず持っている ICMP Echo というサービスを利用して往復時間を計測するソフトウェアに ping というものがある。さらに ping の考え方を進めたものとして traceroute というソフトウェアがある。コンピュータがインターネットに情報を送信する際、情報を中継するルーターの個数の最大数をあらかじめ指定できる。(通常この値は TTL=Time ToLive と呼ばれる)指定したルーターの個数を越えたところで中継しようとしたルーターからエラーメッセージが返されるが、これを利用して利用者側のコンピュータからサーバーまでいくつのルーターが中継するかを調べることができる。これらの手法は大まかな情報しかつかめない。実際、ファイルをダウンロードする場合にかかる時間に影響するのは、サーバーの能力や、途中のネットワークの性能である。真壁知、大田耕平、加藤寧、Glenn MANSFIELD、根元 義章たち[1]は次のような手法によりミラーサーバーの選択法を提案している。
まず各ミラーサーバーより定期的にコンテンツの転送を行いスループットの変化を測定する。そして選択を行う各時刻からさかのぼる一時間以内のスループットの平均と標準偏差を動的に比較し、サーバー間のスープットの逆転を判別し各時刻での最高の値を示すサーバーを選択する手法である。このようにすれば確かに良い結果が得られるが、一方で次のような指摘もできる。従来の研究では定期的に各サーバーからコンテンツを転送してサーバーのスループットを測定することは常にサーバーに接続している必要がありサーバーに負担をかけることになる。また測定されたスループットは特定の場所からの計測であり、そこから選択されたサーバーは計測場所のみに有効であり、他の場所にいる利用者が必ずしも正しいサーバーを選択できるわけではない。つまり、ミラーサーバーに大きな負担をかしてる割りに得られる情報は限定したものである。
本研究ではサーバーの負担を減らし、利用者側に適切なミラーサーバーを選んでもらう手法として、サーバーが利用者に対してネットワークに関する情報を提供することを考える。これは一番最初に紹介した位置情報に似ているが、ネットワークの負荷情報など、よりリアルタイムでネットワークの利用に密接な情報の提供を考える。
この情報提供の方法として、従来ネットワークの管理手法として利用されてきたSNMP[2]というプロトコルを応用する。SNMP (Simple Network Management Protocol) は，TCP/IP プロトコル群で標準化されたネットワーク管理プロトコルであり、ネットワークに接続された機器類をネットワーク経由で監視することができる。SNMPに対応する機器類には、その機器の管理情報が格納されている管理情報ベース（MIB：Management Information Base）が用意されており、ルーターならばトラフィック量の情報などが格納されている。監視したい機器がある場合このMIBにアクセスするわけだが、アクセスするためのインタフェイスとしてSNMPではSNMPエージェントとよばれるインタフェイスを使いUDPを使ってデータのやり取りを行っている。実際のデータのやりとりは、監視するホストでSNMPマネージャーというソフトを使用し、SNMPエージェントと通信しSNMPに対応する機器類内にある情報を取得する。SNMPを使うことで，ネットワーク上のネットワーク機器の情報を1か所で管理でき、負荷もきわめて小さくてすむ。
SNMP はこのようにネットワークの管理手法として利用されてきたが、これを利用した情報提供を行うシステムも存在する。MRTG(The Multi Router Traffic Grapher )[3]はSNMPを使用してルーター上の ネットワークのトラフィックを監視するツールである。SNMPだけでネットワークのトラフィック量を知ろうとしてもトラフィック量の合計値しかデータを持っていないのが、MRTGを応用することにより各時刻の平均トラフィックおよびトラフィックの最大値を簡単に調べることができる。
以上をふまえて、新しいミラーサーバーの選択方法として過去のトラフィック量のデータから各サーバーの転送能力を推測し、現在のトラフィック量との差により各サーバーの比較を行うものである。また比較の値が同じ場合は過去のデータより予想トラフィックを導きこれを比較し、利用者に適切なミラーサーバーを選択できるようにするものである。
以下、2ではネットワークのプロトコルおよびアプリケーションについて述べる。3ではミラーサーバーの選択方式の提案、４では実験をもとにその特徴を明らかにする。５では提案手法の有用性を評価する。
本章では本研究で重要なネットワークのプロトコルやアプリケーションについ て説明する。
SNMP は1988年に開発されたネットワーク監視プロトコルであり、 RFC 1157 [2]で規定されている。
SNMP はネットワーク管理データベースに情報を要求して情報を取得したり、情報を格納したりできる。ここでは、SNMPについての説明は本研究において重要な部分のみのを説明する。
ネットワーク管理モデルはSNMPと管理対象となるルータやブリッジなどの管理対象ノード、実際の管理を行うネットワーク管理ステーション、管理対象ノードの情報を記録するためのデータベースの構造を定義する管理情報ベース(MIB: Management Information Base)からなる。
管理対象ノードにはエージェント (agent) と呼ばれるプロセスがあり，管理対象の状況をモニタリングし，MIB に記録している。エージェントは，ネットワーク管理ステーションからの SNMP によるリクエストを処理する。複数のネットワーク管理アプリケーションがおかれているネットワーク管理ステーションでは、管理を実行するプログラム (マネージャー) があり，SNMP を用いて管理対象ノードに対する問い合わせや操作を行っている（図1）。
またSNMPの特徴としてコミュニティーという概念がある。これは変数の値の設定やトラップを受けつけるかどうかなどのアクセス制御に使われる。SNMP ではコミュニティごとに変数の参照及び変更の可否を設定できる。エージェント側とマネージャー側のコミュニティー名は必ず同じでなければならない。
エージェントとマネージャーがSNMPを使って管理情報のやり取りを行う場合、管理情報が定義されていなければならない。管理情報のひとつの単位を管理対象オブジェクトと呼ぶ。この管理対象オブジェクトの集合がMIBである。以下ににMIBの構造を示す。
図2はMIBの構造である、MIBは1つの大きな木構造を形成しており空間を定義している各管理対象ノードは関連する部分だけを持てば良い。この木構造は対象の種類ごとにまとめられている．MIB は iso.org.dod.internet.mgmt.mib-2 のようにドットで区切られているラベル(もしくは番号)で表現する。この表現がオブジェクト識別子(OID:Object Identifier)であり、オブジェクトを一意に表すものである。
MIB に独自の空間を定義して利用したい場合は、private 以下の空間を使えば良い。しかし勝手に使われたのでは一貫性が保てなくなってしまうのでOIDの衝突を避けるために enterprises の1レベル下を登録制にしている。たとえば、iso.org.dod.internet.private.enterprises の次のレベルとして， Cisco は 9 を，3Com は 43 を節の番号として利用している．このような仕組みになっているため，各企業は衝突のなしに，それ以下のOIDを自由に使えるようになる。
SNMPの命令はSimpleという名前の通りGet Request, Get-Next Request, Set Request,Get Response, TRAP という5つのオペレーションしかない。マネージャー側がエージェント側の情報を知りたい場合、指定したMIBのOIDを送り、そのOIDに格納されている情報を得るわけだが、OIDが完全にわかっている場合はGet が使われる。これに対して Get-Nextは木構造の適当な部分を指定すると，その木構造を幅優先で参照した時その次に参照されるオブジェクトの値を返す。TRAPはシステムが上がった，リンクが上がった/落ちたといった事象を捕らえマネージャー側に通知するものである。
SNMP によりネットワークの流量を取得する手順を説明する。まずネットワークの流量の情報を格納しているOIDを知らなければならない。ネットワークの流量のOIDはipOutRequest(OID:.1.3.6.1.2.1.4.10.1.0)である。次にSNMPでの情報のやり取りはUDPのポート番号161が使用される。OIDとポート番号が決まれば後はマネージャーからエージェントへ命令を送るだけである。OIDが完全にわかっているのでマネージャー側はGet Request命令をエージェント側に送る。命令を受け取ったエージェントはコミニュティ名を調べ、同一であれば指定されたOIDに格納されているデータをマネージャーに返す。
またエージェント側でコミュニティ名の確認をしているが、二重のセキュリティとしてマネージャー側のIPによる確認をすることもできる。エージェント側で定義されていないIPからのアクセスがあった場合は送られてきた命令は実行されないようになっている。
SNMP には Ver.1,2,3があるがSNMP v1では、マネージャとエージェントのやりとりに「コミュニティ名」をパスワードとして用いる。しかし、このコミュニティ名はそのままネットワークを流れるため、盗聴に対して無防備である。
このためSNMPv2以降では、この点について暗号化などの対策およびメンテナンス活動の容易さを採っている。
MRTGは1994年により開発されたネットワーク監視ツールである。
MRTGは、SNMPを使用してルーター上のトラフィックカウンターを読み取る Perl スクリプトと、トラフィックデータを収集して監視しているネットワークのトラフィックをグラフにする高速なCのプログラムで構成されている。これらのグラフはどんなWebブラウザからでも読めるように、WEBページに埋め込まれる。実際の MRTG の表示の例を示す(図3)。この例においてAの部分は入力側の転送速度を表し、Bの部分は出力側の転送速度を表している。また横軸は時間を表し、縦軸は転送速度を表している。
MRTGは日ごとの詳細なグラフに加えて、それぞれ過去7日間、4週間、12ヶ月のトラフィックを視覚化する。これは、MRTGがルーターから収集してきた全てのデータをログとして保持するため可能となっている。ログファイルの内容以下のようになっている。
最初の行はMRTGが取得した最新のトラフィックカウンタの値である。左から時刻、incoming bytes カウンタの値、outgoing bytes カウンタの値となっている。時刻はUNIXのタイムスタンプとなっており、1970年を起点とした秒数である。二行目以降は次の5つの数値からなっている。
最大値については、同じインターバルで測定したすべての値をもとに計算され、例えば現在(行)のインターバルが1時間で、アップデートを5分毎に行っているなら、その1時間の間に観測された5分間ごとの転送速度の中での最大値となる。
このログは自動的に整理されるため、時間の経過とともに肥大することがないだけでなく、過去2年間におけるトラフィックに関するデータを保持する。これらの作業はすべて効率的に行われるので、200を超えるネットワークリンクを比較的低スペックのUNIXで監視することができる。
MRTGはトラフィックの監視だけに限らず、あらゆるSNMP変数を監視することが可能である。また、他の外部プログラムを使用して、MRTGで監視されているデータを集約することもできる。システムの負荷や、ログインセッション、モデムの空き状況などをMRTGを使用して監視することもできる。MRTGを使って複数のデータを1つのグラフにまとめることもできる。
研究用のプログラムの開発はJAVAで行いJava(TM) 2 SDK,Standard Edition Version 1.3.0[4]を使用した。
ミラーサーバーに置くプログラムはMRTGのログより最大出力転送量を求め、現在の出力転送量との差を求めた空き転送幅の値と、5分後の予想空き転送幅の値を求めた値を返すプログラムである。このプログラムをOID:.1.3.6.1.4.1.2021.300.101.1としてMIBに実装する。サーバー側のデータの流れを図5に示す。
ユーザー側のプログラムはミラーサーバー側のプログラムの返す値をSNMP経由で取得し実際にサーバーの選択とログの記録を行うプログラムである。JAVAでSNMPを扱うためWesthawk's JAVA SNMP stack[5]を使用している。ユーザー側のデータの流れ図6に示す。
本研究で提案するミラーサーバー選択方式は次の通りである。
1. ミラーサーバーでは SNMP と MRTG をインストールし、外部からネットワークト
ラフィック量の統計ログを参照できるようにしておく。
2. 利用者は統計ログを取得し、計算により適切なミラーサーバーを選択する。
これらについて順に説明する。
ミラーサーバーに SNMP サーバーをインストールする。そして、情報提供サーバーには MRTG と SNMP クライアントとサーバーをインストールし、 ミラーサーバーのトラフィックを監視するように設定する。(図7は設定ファイルの例である)
さらに、情報提供サーバーは以下のような手順で情報を、SNMP 経由で取得
できるようにする。
1. MRTGによってSNMPエージェントから各ミラーサーバーのトラフィック量を調べ ログ情報を取得する。
2. ログの中で５番目のカラム、出力側の転送速度の最大値の中から最も値の大きいものを選び、そのサーバーの最大転送量とする。
3. 求めた最大転送量の値からから現在の出力側の転送速度の平均値（ログ中の二番目のカラム）を引き、その値を空き転送幅とする。
4. 5分後の予想転送速度を求める。
5. 5 分後の予想トラフィック量を最大転送量から引き、これを予想空き転送幅とする。
6. 利用者からリクエストがきたら、SNMP経由で各ミラーサーバーの空き転送幅と予想空き転送幅の値を送信する。
手順1〜5は各ミラーサーバーごとに行われるものである。
1.SNMP経由でサーバーの情報を取得する。（OID:.1.3.6.1.4.1.2021.300.101.1）
2.取得した情報から、まず空き転送幅の最大のサーバーを選択する。
3. 空き転送幅の値が同じ場合は予想空き転送幅の最大のサーバーを選ぶ。
ミラーサーバー、情報提供サーバー、利用者の関係図を図8に示す。
今回のミラーサーバの選択の基準はサーバーのトラフィックである。トラフィックの計測にはSNMPとMRTGを使いMRTGのログからサーバーの平均出力転送の値を最大出力転送の値から引いたものを空き転送幅としている。例として図9のようなトラフィックのサーバーがあるとする。Traffic_aはサーバの稼動中の最大トラフィックである。これをサーバーの最大出力転送値とする。次にTraffic_ｂは平均出力転送値である。Traffic_ｂの時間帯の空き転送幅はTraffic_a-Traffic_bとなる。
現在の時刻t0のトラフィックをxを基準として、5分前t-1のトラフィックをx-1、10分前t-2のトラフィックをx-2として差分を求める。
一階差分:f [t-1,t0]=(x0-x-1)/(t0-t-1)
f [t-2,t-1]=(x-1-x-2)/(t-1-t-2)
二階差分:f [t-2,t-1,t0]=f [t-1,t0]-f [t-2,t-1]
これによりニュートンの補間公式によって
f(t)=f [t0]+f [t-1,t0]t-0+f [t-2,t-1,t0]t-0t+1
となり、5分後t+1の予想トラフィックf(1)は
f(1)=f [t0]+f [t-1,t0]+2f [t-2,t-1,t0]
で求めることができる。
よって、予想空き転送幅は、最大転送量-f(1)で求められる。
この方式の場合、最大転送量の値が近いミラーサーバー同士の場合、サーバーを選択する場合に予想空き転送幅を用いるのはトラフィックが反転するときだけである。しかし各ミラーサーバーのトラフィックの最大転送量が異なる場合は図10のようになる。
L1,L2はサーバーの最大転送量を表しL3は一定時間内のServerBのトラフィックの最高値との差でありこれが空き転送幅となる。
ServerA,Bはトラフィックの反転がおこっているが、トラフィックの反転時の空き転送幅は常にServerAの方が大きいのでServerAが選択される。この方式の場合ServerBが選択されるのはServerAの空き転送幅がL3より小さい場合である。
図10ではP1からP2の時間内でServerBの空き転送幅がServerAより大きくなるのでServerBは選択される。P1、P2の時点では空き転送幅が同じになるので変動率によりサーバーの選択が行われる。P1の時点でServerAのトラフィックは増加し、ServerBのトラフィックは減少しているのでServerBが選択され、P2の時点では逆にServerAが選択されることとなる。
この方式の利点はSNMPとMRTGを使うことによりサーバーにほとんど負荷を与えることなく計測ができ、さらにクライアント側が常に接続する必要がない事である。また変動率によりサーバーの利用率予想ができるようになっていることである
今回考えたサーバーの選択方法を実際に実験により検証する。実験機材はサーバーPC２台、クライアントPC２台、ハブ１台である。SNMPはNET-SNMP[6]を使い、プログラムはJAVAで作成しJDKを用いた。ネットワーク構成図を図11に示す。
まず２台のサーバーに負荷を与えなければならないので、5M、10M、15M、20Mのデータを用意し、クライアントから一定時間おきにランダムにファイルをDownloadするプログラムを作成し２台のサーバーにそれぞれ異なる負荷がかかるように設定した。
今回の実験はネットワーをQOS[7]を使い出力側転送量を１Ｍに制限し、２台のサーバーの転送能力を同じにした場合と、出力側転送量を一方を１M、もう一方を２Mにしてサーバーの転送能力を変えた設定で行った。計測時間はそれぞれ約６時間である。
図12はサーバーS1,S2のトラフィックの計測結果である。転送能力がまったく同じサーバー同士と仮定するため、最大転送幅を500Kbyte固定にしてある。そのためサーバーS1とS2のトラフィック量の逆転が何度もおこっていることがわかる。最大転送幅が同じということはトラフィックの逆転時に選択されるサーバーも変化するということである。選択されたサーバーを示したものが図13である。
図13はプログラムが選択したサーバーをS1とS2のトラフィックと比較したものである。最大転送速度が同じなので常にトラフィックの低いサーバーが選択されているのが分かる。注目すべき点はトラフィックの逆転する時である。実験では２０分後にS1,S2サーバーのトラフィックがほぼ同じ値を示している。予想空き回線幅を比較するとS2の予想空き回線幅のほうが計算の結果S1より大きくなっている。
これにより予測としてS2サーバーは空き回線幅が増加すると考えられるためS2が選択されていることがわかる。
図14はサーバーS1が出力側転送量を2M,サーバーS2が１Mに制限してトラフィックを測定したものである。実際の最大転送速度はグラフからは読み取れないがS1が約710K,S2が470Kとなっている。これは実験をする前の段階でMRTGがログに記録した値であり、転送量の制限も実験に限らず設定はそのままにしてあったことから現時点での最大転送速度として信頼できる値である。図14をみてみるとS1のトラフィックがほとんどの場合において高いことが分かる。しかしS1とS2の最大転送速度が異なることから、トラフィック量を見るだけでは必ずしも選択すべきサーバーは分かるわけではない。実際に選択されたサーバーを図15に示す。
図16はミラーサーバーの空き回線と予想空き回線の値の一部をグラフ化したものである。 計算結果から知りたいのは、そのサーバーのトラフィック量が上がるのか下がるのかである。図16をみると、空き転送幅と予想空き転送幅の値は時間によっては大変異なる値を示しているが、空き転送幅の増減と比例していることが分かる。予想空き転送幅の値より予測したいのはトラフィックが増加するのか、減少するのかである。よって空き転送幅の値が同じ場合、予想空き転送幅の大きい方を選択することによってミラーサーバーの選択が可能であることが分かる。
インターネット上にいくつもあるミラーサーバーから最適なサーバーを選択する場合、ネットワークやサーバーなどの負荷を考慮しなければならない。本研究では、これらの変化する状況を把握するためミラーサーバーのトラフィックをSNMPとMRTGにより測定し、そのログをもとに動的にサーバーを選択する方式を提案した。トラフィックは時間の経過ごとのサーバーの利用状況を知るだけでなく転送性能を予測するデータとしてみることができる。そのため、トラフィックのログのなかから最大値を求め、これを最大転送幅と仮定し現在のトラフィックの値から引いた値を空き転送幅としてサーバー間で比較を行った。また、比較する空き転送幅が同じ場合、５分後の空き転送幅の値を過去のトラフィックデータの差分により求めこれを比較することによって空き回線幅の大きいサーバーを選択する手法を示した。
実験では、実際にこの方法でのミラーサーバーの選択を行い、その有効性を示した。
今後の課題として、今回おこなった実験は実際にWEB上で稼動しているサーバーではなく、研究室内のサーバーを使い故意に負荷を与え計測したものとなっているため実際の多くの人が利用するミラーサーバーでの有効性を調べる必要がある。しかしSNMPといういままでネットワークの監視に使われてきたプロトコルを応用し、サーバーの選択に使えるということは実証できた。また多くのネットワーク機器にSNMPは使われており、この計測方法を取り入れやすいことはたしかである。
[1]真壁知、大田耕平、加藤寧、Glenn MANSFIELD、根元義章、「ネットワークの負荷変動を考慮した動的なミラーサーバー選択方式」 、電子情報通信学会論文誌 B Vol. J84−B No.3 pp.435-442、2001年3月
[2]J. Case、M. Fedor、M. Schoffstall、J. Davin、「RFC1157」、http://www.faqs.org/rfcs/rfc1157.html、1990年5月
[3]Tobias Oetiker、Dave Rand、「 The Multi Router Traffic Grapher」、http://www.mrtg.jp/、1994
[4]Sun Microsystems、「JAVATM 2 PLATFORM,STANDARD EDITION」、http://java.sun.com/j2se/、1997年
[5]Westhawk provides software、「Westhawk's JAVA SNMP stack」、http://www.westhawk.co.uk/resources/snmp/index.html、2001年9月1日
[6]Wes Hardaker、「The NET-SNMP Project Home Page」、http://net-snmp.sourceforge.net/
[7] 井之上 和弘、「raffic control Mini-Howto」、http://www.linux.or.jp/JF/JFdocs/traffic-control.html、1999年11月9日