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

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

[Loki Jorgenson，TechTarget]

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

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

QoSとは何か

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　極めて単純化すれば、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の導入に成功するには、下記の要件を満たすインプリメンテーションでなければならない。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

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

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