QoSの隠れたコスト：ロキ・ジョーゲンソンのネットワーク入門

一見QoSの方がオーバープロビジョニングよりコストが掛からないように見えるが、場合によっては高くつくかもしれない。

[Loki Jorgenson，TechTarget]

　Quality of Service（QoS）は良いアイデアだと言う人は、その値札を見ていないのだろう。驚くほどのことではない。というのも、たいていの場合、値札はなかなか見つからない所に隠されているからだ。だからといって、QoSを使用することについて慎重に考えなくてもいいということにはならない。あなたの会社では、ROI（投資利益率）分析をせずにプロジェクトを推進したことがないだろうか。きっとそのプロジェクトはうまくいかなかったに違いない。それなのになぜ今日、費用便益分析を行わずにQoSを導入しようとするのだろうか。ベンダーが導入を勧めたからだろうか。

　これまで業界は、QoSのROIという問題に真正面から取り組んでこなかった。そういった分析が必要かどうかさえもはっきりしないのが実情だ。宣伝文句や政治的思惑――「ネットの中立性」に関してまだ混乱している人は、askaNinja.comの明快な説明（残念ながら英語のみ）を読むといい――に惑わされ、QoSの本質を誤解している人は少なくない。昨今の金もうけ主義的な風潮を考えれば、これは驚くようなことではないのだろう（「The QoS scam」参照）。

QoSとは何か

　まず、QoSとは「何でないか」という問題に答えるとしよう。

・スループットや容量を増やす手段ではない
・総合的なパフォーマンスを改善する手段ではない
・障害のあるネットワークやパフォーマンスが低いネットワークを修正する方法ではない
・特定のアプリケーションの動作を改善するスイッチのようなものではない
・エンドユーザーのQoE（Quality of Experience：エクスペリエンス品質）とは違う

　次は逆に、QoSとは何かを考えてみよう。

・パケットを非均一的に扱う手段である
・下手をすると、ネットワークパス（経路）の総合容量が減少する
・うまくいけば、優先アプリケーションからはネットワークが「がら空き」に見える
・基本的に、ネットワークパス上のすべてのデバイスがサポートしなければならないエンド・ツー・エンド型メカニズムである
・エンドユーザーのQoEに対する支配的影響要因がネットワークである（つまり、ネットワークが鎖の中で最も弱い環である）場合、QoEに大きな影響を与える可能性がある
・ネットワーク容量に制約があり、費用効果に優れた代替手法がほかに存在しないのであれば、ベストなソリューションである

　極めて単純化すれば、QoSは高速道路に例えることができる。すなわち、QoSにおける優先サービスは、高速道路のHOVレーン（相乗りしている車両だけが利用できる専用車線）に相当するわけである。HOVレーンを走る車は、ほかの車線の渋滞に巻き込まれることはないが、高速道路が空っぽの場合に出せる速度よりも速く走ることはできない。つまり、高速道路そのものに問題が発生し、1台の車しか走っていなくても速度を落とさなければならない状態になれば（路面凍結、霧、路面のくぼみなど）、HOVレーンといえどもQoEを改善したり最高速度を速くすることはできない。

通常左端のHOVレーンは渋滞しない(左図）が、問題が起きれば渋滞する（右図）

　QoSに代わる主な手法がオーバープロビジョニングである。これは、平均使用率またはピーク使用率に比べて相対的に過剰な容量を提供するというものだ。高速道路の比喩で言えば、これは個々の車両が実質的に1台だけで走っているように感じられるまで車線を増やすようなものだ。この場合もやはり、各車両のエクスペリエンスは、高速道路が完全に空っぽの状態のとき以上には良くならない。オーバープロビジョニングは、コンピュータのCPUやディスク容量、車のサイズや馬力、劇場の座席数、駐車場のキャパシティなど、多くの身近なリソースで一般的に用いられている。こういったリソースはすべてピーク容量に基づいて割り当てられており、利用がピーク時を大きく下回るときは通常、特に管理をしなくてもきちんと機能する。

　　1車線に1台になるくらい車線を増やす

費用便益のアンバランス

　オーバープロビジョニングに対する批判は、確実にコストが掛かるというものである。追加容量を配備すると、ある程度の設備投資コスト（CAPEX：Capital Expenditure）と設備維持コスト（OPEX：Operation Expenditure）を伴う。これらのコスト（特にOPEX）は決裁の対象となり、求める結果を実現するための代替手段が「QoSをオンにする」だけであれば、オーバープロビジョニングという手法が却下されるケースが多い。

　しかしながら、「QoSをオンにする」という選択肢は、必ずしも十分に検討した上で採用されているわけではないようだ。例えば、QoSの導入に関連して発生する隠れたCAPEXとOPEXは多数存在する。また、導入に成功するための要件は明確に示されていないことが多い。そして、配備のプロセスで遭遇した障害は確実にROIを侵食する。

　QoSの導入に成功するには、下記の要件を満たすインプリメンテーションでなければならない。

・エンド・ツー・エンド（衛星経由でのリンクやワイヤレス接続といった特殊ケースは除く）

・堅牢で信頼性が高いこと

・さまざまなタイプのアプリケーションパフォーマンスの向上につながること

・複数の業者のドメインにまたがる契約でサポートされていること

・シンプルで拡張性があること

　QoSの利用が限定されているような特殊なケースでは、QoSを効果的にセットアップし、管理することができる。しかし、それが1人の技術者で扱えないほど規模が拡大すると、壊れやすくなる。ToS（Type of Service）／DSCP（Differentiated Services Code Point）ビットを尊重しないデバイスが1台でもあれば、サービスのエンド・ツー・エンド・チェーンが断ち切られてしまうのだ。複数の業者のドメインが関係している場合には、業務契約と技術的実装の両面で高度な連携が必要となる。

　QoSをきちんと実現するのは、決して簡単なことではない。QoSはボタンを押すだけといったような「スイッチ」ではない。ネットワーク、使用するアプリケーション、そしてユーザーの要求に対応している必要があるのだ。単一のターンキーソリューションのようなものは存在しない。QoSのチューニングには、ネットワークの勘所をおさえた賢い技術者の高度なテクニックが要求されるのだ。

　では、どんな潜在コストがあるのだろうか？