輻輳が起きたときのVPNの振る舞いは？
本題に戻ると、このような輻輳状態の場合に、VPNサービスがどのような動作をするかが問題となる。VPNサービスではトラフィックの中身の区別がつかないとする。
最初の例で出口のB拠点が1.5Mbpsしかないのに、A拠点から3Mbpsのトラフィックを送ってきたら、中身が音声だろうが基幹業務だろうが1.5Mbps以上は廃棄する。IPやイーサネットではパケットにその優先度を示す情報を付けることができる。
VPNサービスがそのパケットの優先度を認識できれば出口で優先度の低いトラフィックを廃棄される。
優先度の高いトラフィックを送ることができるため、こうした出口での優先制御を提供しているIP-VPNや広域イーサネットがある。もちろん、ほとんどのVPNサービスでこの機能は有料のオプションとなっている。
VPNサービスで2段階以上の優先度とそれぞれの最大帯域を割り振る
ここでA拠点から最も高い優先度を付けたトラフィックを、出口と同じ速度1.5Mbpsで送ってきたとする。すると低い優先度のトラフィックは全く流れなくなってしまう。実際に使うには、高優先度のトラフィックの帯域をある程度確保して、残りの帯域を低優先度のトラフィックで使えると都合がよい。
通常、VPNサービスでは2段階以上の優先度とそれぞれの最大帯域を設定できる。例えば1.5Mbpsのうち高優先度を192kbps、低優先度を残りの帯域と割り振る。高優先度のトラフィックが192kbpsに抑えられるので、残りの帯域を低優先度のトラフィックで利用することができる。こうした優先制御のサービスを利用すればVPNサービスでもまずは基本的なQoSが提供できる。
企業側であらかじめ高優先のトラフィック帯域を絞る
2番目の例ではどうだろうか。1.5Mbpsで接続されているC拠点にA拠点、B拠点からそれぞれ3Mbps、1.5Mbpsを送る場合に、同様に出口のC拠点で優先制御を掛けてQoSを提供しようとする。出口では高優先度の帯域を192kbpsに割り当てているとする。例えば高優先パケットをA拠点から128kbps、B拠点から128kbps送ったとすると、優先制御が働いて帯域は合計192kbpsで抑えられる。
ところが、もし192kbpsのうちA拠点からC拠点に128kbps、B拠点からC拠点に64kbpsを確保したいと考えても、VPNサービスの優先制御では送信元を区別できない。つまり、VPNサービスの出口での優先制御だけでは、拠点間ごとのトラフィックに対するQoSの要求に対応できないということだ。
そもそも、VPNサービスには拠点間を結ぶパスという概念はない。よって、このような複数の拠点間のQoSを実現するには、企業側であらかじめ高優先のトラフィックをA拠点からC拠点に128kbps、B拠点からC拠点に64kbpsと帯域を絞ってやる必要がある。
企業が拠点間のトラフィック帯域の優先度を設定する
結論からいえばVPNサービスを用いてQoSを実現するためには、企業側でトラフィックの優先度を付けて、さらに高優先のトラフィックに関してはあて先の拠点ごとに帯域を絞らなければならない。
実はこれは従来のフレームリレーやATMなどを用いた構成で使われてきたQoSと同じ考え方だ。ATMでは帯域幅が決まっている拠点間のパスを、企業側でさらに細かい優先度を持ったパスに分割し、高優先のパスのトラフィックを優先的に扱うと同時に帯域を絞っていた。しかし、パスの概念がなくフルメッシュの接続性を持つVPNサービスではこのあて先の拠点ごとの制御が非常に厄介である。
先の例では3拠点で構成されていたので、あて先の拠点を区別するために必要なルールは非常に少ない数で済む。A拠点からB、C拠点、同様にB拠点からA、C拠点、C拠点からA、B拠点の6個だ。ところが、拠点数が増えると膨大な数のルールを管理しなければならなくなる。具体的には拠点数をnとするとn×（n-1）個のルールが必要となる。30拠点あれば30×29で870個のルールと、それに加えて優先度も管理しなければならない。これは非常に手間が掛かり現実的なやり方ではない。
スター型でATMのパスをそのまま活用する
QoSの観点からこれを解決する簡単な方法は、高優先のトラフィックに関してVPNサービスの特徴である面、つまりフルメッシュの接続性を使わない構成を組む方法だ。広域イーサネットではユーザーはVLANタグを用いてVPNサービス内の構成を仮想的に分割できる。
例えば、高優先トラフィックを分割しVPNサービス上に仮想的にスター型の構成が組める。高優先トラフィックに関してはすべてトラフィックをセンタ拠点経由にして、ルールを減らすのだ。こうすれば従来のATMなどのパスを用いたQoSと同じことが実現できる。しかし、IP-VPNではユーザーがVPNサービス内を分割することができないのでこのような方法は使えない。
トラフィックをアプリケーション側でスター型にする
そこで別の方法を考えてみる。高優先トラフィックに対し、フルメッシュ構成を用いなければ、高優先のアプリケーションでフルメッシュのトラフィックを流さないようにするのと同じことになる。
例えば高優先にしたい基幹業務がサーバ〜クライアント型の通信であれば、サーバをセンタ拠点にのみ配置すれば、その他の拠点間でトラフィックは流れない。トラフィックをアプリケーション側でスター型にしてしまう方法だ。
通常、高優先トラフィックとされるVoIPはどうだろうか。VoIPは制御情報についてはサーバ〜クライアント型であるが、実際の通信はクライアント同士が直接トラフィックをやりとりする。よって、スター型の通信にすることができない。しかし逆に、A拠点からC拠点に2回線、B拠点からC拠点に1回線しか接続できないようにはできる。
これはフルメッシュの通信で、使用する帯域を絞ることで、VPNサービス網内に高優先トラフィックの輻輳が起こらないようにすることと等しい。よって、先の例のA拠点からC拠点に128kbps、B拠点からC拠点に64kbpsを確保できるようになる。VPNサービスではなく企業側が流すトラフィックそのもので実現できるのだ。
このようにVPNサービスを用いてQoSを実現するためにアプリケーションで解決できることは多い。VPNサービスがどんなQoSを提供しているかを知れば、企業側でQoSのために工夫できることはほかにもあるだろう。
通信事業者の負担になる帯域保障
ここまで、VPNサービス内での帯域保証がどうなっているかについては触れてこなかった。帯域保証されているかどうかは、QoSを設計する際に優先制御より重要な要素だ。VPNサービスでは接続するための線、つまりアクセス回線の帯域と、面である中継回線の帯域について考えなければならない。
ユーザーが選択できるアクセス回線の帯域については、完全に保証されているものと一部保証されているもの、あるいは保証されていないものがある。企業側はコストとQoSを考慮して最適な帯域とアクセス回線の種類を選ばなければならない。しかし、帯域保証していない回線を選択すればQoSの実現は難しいと考えられる。
次に、VPNサービス内の中継回線についてはどうだろうか。IP-VPN、広域イーサネットは基本的に帯域確保されている。帯域確保の方法は主に2種類ある。1つは完全に中継帯域を確保しているサービスだ。例えば10Mbpsのユーザーが10人いたら、中継回線の帯域幅として100Mbpsを用意するという方法だ。
もう一方は、中継回線の平均使用率などを監視して、ある値を超えたら中継回線の速度を増やす方法である。ユーザーにとっては前者がよいと思うかもしれないが、無駄な帯域確保は通信事業者の負担になる。あまり詳しく触れられないが、こうした負担は何らかの形でユーザーに跳ね返ってくるので、この方法の違いを気にしてVPNサービスを選ぶ基準にする必要はないだろう。
LAN内QoS
最後に視点を変えて企業内のLANのQoSを見てみる。
多くのユーザーはLANでもQoSを実現する努力をしているが、QoSの課題に対してWANとは違う考え方を持っているだろう。それはLANではまず帯域幅を増やすことを最初に行うことだ。優先制御などを用いてQoSを実現するにはルール設計などを含め非常に手間が掛かり、この手間が運用コストになる。LANでは機器に導入コストが掛かるが、線の運用コストはタダに等しい。LANのQoSを実現するためには、単純に100Mで足りなければ1Gにする方が安上がりなのだ。
帯域が月額料金に反映するVPNサービスを利用したWANでは同じやり方は難しい。しかし、QoSを実現する場合、月額料金が上がったとしてもVPNサービスの帯域を上げて解決した方が結果的に安上がりとなる場合もあることも忘れてはならない。
先に述べたとおりVPNサービスでQoSを実現するためには、送信元となるLANでも優先制御や帯域制御をしなければならない。これはLANで高機能だが高価な機器が必要ということを意味する。つまり、企業ネットワークで効率的なQoSを実現するためには、LANとVPNサービスを用いたWANの両方のコストを意識する必要があるといえる。
Copyright © ITmedia, Inc. All Rights Reserved.