帯域を知ろう - ユーザと開発者の視点から考える、テレワーク時代の帯域圧迫を防ぐアプローチ

テレワークの浸透によって「職場に行かず仕事をする人」が増えましたが、この“テレワーク”を実現するために必要なものは何でしょう？さまざまな意見があると思いますが、筆者はさしあたり以下の3つが必要になると考えています。

• 端末（PCやスマートフォン、タブレットなど）
• インターネットアクセスの手段
• VPN

テレワークのための「端末」で気をつけること

多くの人がテレワークにあたってはPCを使用していると思いますが、業務上必要な機密情報を含んだファイルを扱うPCは、どんなものでもよいというわけではありません。PCをテレワークに適した状態にするには、大きく2つの方法が考えられます。ひとつは、必要とされるセキュリティ設定を施したPCを用いて、PCの紛失や盗難に備える。もうひとつは、リモートデスクトップなどを用いて、会社の中に設置されているコンピュータにインターネット経由でアクセスする方法です。後者の場合、手元で操作するPC上に極力情報を残さないようにするなどの対応が必要になります。

筆者の経験では、トラブルが起きやすいのは、リモートデスクトップを用いたパターンです。通常はPC1台で完結する環境を、手元の端末と会社の中に設置したコンピュータの2つに分け、さらにその2つの間をインターネットでつないでいるーーシステムの構成要素が増えれば、トラブルが発生する確率が高くなるのは、ある種、必然でしょう。

このように、何らかの手段でセキュアな端末を用意することに加え、テレワークを実施するためには、会社の定めた業務環境を使うために「インターネットアクセス」が必要となり、さらに安全に業務環境を使うために「VPN」が必要となります。

業務環境に必要となる「VPN」

会社が準備した業務環境や社内システムを、インターネット経由で誰もがアクセスできる、ということはまずありません。必ずしも安全ではないインターネットを用いて、業務環境やシステムに安全にアクセスするためのしくみがVPNです。

VPNの実現方式にはいくつかあり、Windows標準で準備されているVPNのしくみや、オープンソースで開発されているVPNのしくみ、また、ネットワーク機器ベンダにより開発・販売されているVPNのしくみもあります。

昔からよく使われているのは、IPsecという通信規約をベースにしたVPNのしくみですが、他にもSSLにより保護された通信をベースにしたSSL-VPNというしくみもあります。

アクセスできるデータ量を指す「通信帯域」

インターネットやVPNへのアクセス可否の次に考えなければいけないのは、アクセスできる通信量である「帯域」です。

帯域とは、ある時間内にどれだけデータを送れるか、の指標であり、通信速度と言い換えることも可能です。なお、通信速度の場合はその性能は「速い」「遅い」と表現するのに対し、帯域の場合は「広い」「狭い」と表現します（厳密には帯域は、周波数帯の広さを示す言葉であり、速度として表現するのは誤用です。しかし、通信で使える周波数帯が広いと、通信速度が向上する傾向にあるため、慣例的に通信速度でも帯域という用語を用います）。当然ながら、帯域が広いほうが、一定の時間内に多量のデータを送ることが可能です。

帯域を使う、とはどのような状態か？

インターネットは、単一の会社が運営しているものではなく、複数のネットワークの集合体です。そして、インターネット経由で何らかのサービスを受けるために、いくつものネットワークを使用しているような状態になります。

たとえばですが、以下の図のように、複数のネットワークを経由して、ユーザ側のコンピュータからサービスまでデータが送り届けられます。

<

最終的にサービスを受ける際に使用できる帯域は、「ユーザ側のコンピュータからサービスを提供するコンピュータの間に存在する通信回線の間の帯域がどれだけあるか」で決まります。上の図の場合、ネットワークA、B、Cでどれだけの帯域を使えるか示していますが、ユーザとサービスの間で使用可能な帯域は、ネットワークBで使える帯域の10Mbpsになります。

ユーザ側のネットワークAとサービスを提供する側のネットワークCで、どれだけ使用可能な帯域が広くても、その間のネットワークBで使用可能な帯域が狭い場合、最も狭い帯域がサービスで使える最大の帯域になってしまいます。

ここでは説明を単純化するために、3つのネットワークだけを挙げていますが、実際にはさらに多数のネットワークが介在します。また、性能を最適化するために、途中経由するネットワークは、随時自動で変更されることも多いです。

また、「サービス」というように述べていますが、ここは最終的なアクセス先を指しており、VPNアクセスのためのゲートウェイもこの「サービス」にあたります。なお、VPNアクセスの場合、この先（図で示した「サービス」）からさらに、本来受けるべきサービスが控えています。

帯域が圧迫されると何が起こる？

また、帯域はなにも考えずに、無尽蔵に使えるわけではありません。なんらかの理由で多量のデータ転送を行い、帯域を多く使うことで、他のサービスで利用できる帯域を狭くしてしまう、といったことも有りえます。こうした事象を、「帯域を圧迫する」などと表現します。

では、帯域が圧迫されると何が起こるのでしょうか。実は、帯域の圧迫がどこで発生しているかによって、発生する事象は変わります。

ユーザ側帯域が圧迫される

これは、たとえばマンションなどで複数人で設備を共用している場合、発生しがちな事象で、ユーザ側でのインターネット接続速度に影響が出ます。この場合、ユーザが使用しているすべてのネットワークサービスの利用に影響が出てしまいます。

具体的には、「動画再生が途切れる、再生再開まで時間がかかる」「音声が途切れる」「データのダウンロードが遅くなる、途中でタイムアウトする」といった事象が考えられます。

特定のサービスだけが使えなくなるわけではないため、ユーザが問題解消を求める先は、通信サービスを提供する会社になる可能性が高いです。もちろん、特定のサービス提供者にクレームが向かう可能性もありますが、サービス提供者に解決できる事象ではないため、他のユーザには何の影響も出ていない旨を説明する必要があります。

サービス側帯域が圧迫される

これは、サービス提供側の想定を上回るユーザがサービスを利用した場合発生が想定されます。いざ発生してしまうと、当該サービスの提供そのものに影響が出ます。2020年5月に、あるメーカによるマスク販売時の初期に発生した問題は、この事象だと推測されます。

この場合は、帯域が圧迫されたネットワークを経由して提供されるすべてのサービスにおいて提供遅延、サービス不可になるなどの影響を受けます。また、懸念すべきは中途半端にサービスを利用できてしまうケースで、リトライを繰り返すユーザが発生させる通信により、さらにサービス側帯域を圧迫する、といった連鎖が起こりえます。当然ですがこうしたケースでは、ユーザからサービス提供者へのクレームが飛びます。

ここでは帯域が圧迫されることに起因したサービス提供遅延や提供不可の状態の話をしていますが、実際にこうした事態に至る要因は、ネットワーク以外の箇所に存在することも想定されます。サービスの適切な運用管理がなされていないと、原因の特定から対処までに時間を要するので注意が必要です。

途中経路の帯域が圧迫される

これは、ユーザ側でもなければサービス提供側でもない、たとえばインターネットサービスプロバイダ（ISP）側の設備に起因して、帯域が圧迫される（通信速度が遅くなる）ことがあります。その要因として、ここ最近のテレワークリモート授業の隆盛は無関係ではないでしょう。多くの人がインターネットを盛んに利用することでISP側の設備で発生している負荷が高くなり、速度低下が発生していることは容易に想像できます。この場合発生する事象およびクレームの向き先は、「ユーザ側帯域が圧迫される」場合に酷似します。

注目が集まるオンライン会議サービスを例に、帯域を考える

オンライン会議が、テレワーク実現のための重要な要素であることは、すでに多くの方が実感しているでしょう。遠隔でのミーティングを実施するシステムとして、WebEx¹、Zoom²、Microsoft Teams³、Google Meet⁴などが挙げられます。いずれのサービスにもセキュリティ面など、課題があることも事実ですが、設定などを工夫することで回避可能なものも多く、初期状態で安全に使えるものも多いです。いずれにしても、使用しているサービスの設定は、一度確認してみることをお勧めします。

さて、ここからはオンライン会議システムがどのように帯域を使用しているかを考えていきます。（文章では非常にわかりづらいですが）「Windowsのリモートデスクトップ」を使って職場のコンピュータにアクセスし、そこからさらにオンライン会議システムにつなぐ、といった使い方を前提にしてみます。整理してみると、いくつかの課題が見えてくると思います。

リモートデスクトップの利用により、必要な帯域が倍付に

通常、リモートデスクトップでは、遠隔のコンピュータから手元のコンピュータに画面イメージを送り、手元のコンピュータから遠隔のコンピュータに対して操作に係る情報を送ります。また、設定によって、遠隔のコンピュータ側で再生される音声を手元のコンピュータで再生したり、その逆に、手元のコンピュータで入力した音声を遠隔にあるコンピュータの音声入力にすることも可能です。

その他、手元のコンピュータで利用可能なデバイスを、リモートデスクトップ接続するコンピュータでも使えるようにすることも可能です。

最も単純なオンライン会議サービス利用ならば、手元のPCとサービス提供者の間で以下の図のようにデータの送受信が完結します。

サービスを享受するための通信がこのような状態で完結していれば、特段問題は起きないでしょう。しかし、遠隔のコンピュータ経由で外部のサービスを受ける際、たとえば、リモートデスクトップを利用する場合、リモートデスクトップクライアントとのやりとりが追加で発生し、問題が発生するリスクが高まります。

より具体的に動画・音声付きのオンライン会議に参加するケースを想定してデータの流れを考えてみます。以下にリモートデスクトップを用いてオンライン会議サービスを使い、手元の動画を会議参加者に共有する場合のデータの流れを例示します。システム構成やサービスによっては、必ずしも例示のとおりになるとは限りませんが、データを扱うフローをイメージできると思います。

1. 手元のコンピュータにある動画データ（例：カメラで撮影している動画データ）を遠隔のコンピュータに送信
2. 遠隔のコンピュータ内の動画データをサービスに送信
3. オンライン会議サービス上で再生された動画データが遠隔のコンピュータに送信される
4. 再生された動画データを遠隔のコンピュータから手元のコンピュータに送信

動画を受けるという状況だと、サービスを使うコンピュータに動画が送信され、さらにリモートデスクトップクライアントが動作するコンピュータに動画が送信されるということになり、特定のネットワークを同じようなデータが2回通ることになります。

このように、「結構な種類・大きさのデータが遠隔のコンピュータを通る」という構図が必要になるのです。動画だけでなく、音声や資料スライドなど、さまざまなデータが同様の経路を通っていることは言うまでもありませんし、他の参加者がなんらかのデータを共有する際も、同じように複雑なデータの送受信が発生しています。テレワーク時代に帯域が圧迫されるのは、ある意味で必然といえるでしょう。

帯域を圧迫しないために気をつけられること

では、帯域をできるだけ圧迫しないためには、どのような工夫ができるでしょうか。そのためには、大きく3つの考え方を理解する必要があります。

1. 手元のコンピュータ側の設定で、通信量を減らせる設定を施す
2. 途中で特定のポイントを通らないようにする
3. 通信量が増えがちな使い方をしない

これらの点について、少し詳しく説明を行います。

コンピュータの設定～使用する帯域を減らす観点から

前述の3つの考え方のうち、(1)を実現するにあたっては、たとえばリモートデスクトップサービスを使う際の設定が挙げられます。

たとえば、マイクロソフトが提供する情報には、リモートデスクトップを使う際の設定ポイントが挙げられています。

帯域をキーワードに上記資料をサマリーするならば、以下の3点を考慮する必要だと読み取れます。

• 通信帯域を多く必要とする効果を使わない
• ビットマップキャッシュを有効にする
• 通信データの圧縮を有効にする

ただし、それぞれの設定にメリット / デメリットはあります。

上記3点の設定をすべて有効にすることで、以下のようなデメリットが想定されます。

• 操作性が（若干）悪くなる
• 画面データが手元のコンピュータに残るため、セキュリティ上の懸念が出てくる
• 圧縮処理が追加されるため、CPU / メモリを多く消費する

これらはマイナス要因ではありますが、ネットワークの帯域が不足して操作自体できなくなることを考えると、ある程度トレードオフとも考えられます。

また、帯域に配慮すると、安全な情報管理の面で課題が出てくる可能性がありますが、取り扱う情報の重要性、漏洩リスクの多寡を考慮したうえで、必要に応じて使う / 使わないを柔軟に選択するのがよいといえます。

(2)通信経路の設定～途中で特定のポイントを通らないようにする

特定のポイントを通らないようにするとは、大げさなことではなく、たとえば「リモートデスクトップ経由でオンライン会議サービスを使用することは、可能な限り避ける」といった対処が考えられます。

そもそも、リモートデスクトップを経由して「どんなサービスを利用するか」は、検討を重ねた末に決定するのが重要です。

会議については、段取りや仕組みを見直すことも有効でしょう。たとえば「資料は事前に配布し、オンラインでは表示せず、手元で参照してもらう」というのも、見直し策のひとつにあたります。通信の品質の関係で、オンライン会議が成立しにくい場合には、オンライン会議システムは「あえて使わない」くらいのことをやったほうが、使用する帯域を抑制する観点からは推奨できます。

(3)通信量そのものへの配慮～通信量が増えがちな使い方をしない

単純な手ですが「通信量が増えがちな使い方とは何か？」を把握して、そうした使い方を極力避けるのも帯域への配慮としては有効です。

たとえば、オンライン会議サービスの中で一番通信量を増やす可能性があるのは「動画」です。リモートデスクトップを利用した接続では、通常は「書き換わった画面」の情報のみを送るようにしていますが、動画を再生しているということは、画面は常に何かが書き換わり、その情報は送信され続けます。また、動画の解像度が高ければ高いほど、書き換わる情報は多く、それはすべて通信量に反映されます。

一方で、音声は比較的通信量が低いコミュニケーション手段です。会話が成立する程度の音声品質であれば、筆者の経験では帯域を強烈に圧迫するということはないと考えます。（もちろん、コンサート中継レベルの高音質のデータを送ろうとすると、帯域は圧迫されるでしょう。しかし、通常のオンライン会議ではそうした音声品質は必要とされません）。

開発者が考えるべき、帯域を圧迫しない工夫

ここまでは、サービスを享受するユーザやシステム管理者側の視点で帯域を考えてきました。ここからは、Web開発者の視点で考えてみたいと思います。

説明するまでもなく、多種多様なWebアプリケーションが開発・利用されていますが、システム構成に応じて、帯域への気配りが必要になってきます。

動的コンテンツと帯域

動的コンテンツの提供などは、帯域を意識する必要があります。もっとも、動的コンテンツの中でも、ユーザのコンピュータに対し、非同期のテキストデータを送信するようなタイプのサービスならば、あまり神経質になりすぎる必要はないでしょう。ユーザーのコンピュータはブラウザ上にすでに読み込まれているプログラムやスクリプトなどを用いて当該データを処理・表示する、というプロセスならば、帯域はさほど圧迫しない可能性が高いからです。

一方で、サービス側で動的に画像を作成し、その画像をブラウザに送るようなサービスの場合には、帯域を圧迫する懸念があります。

静的コンテンツやスマホアプリと帯域

静的なデータやスクリプト類は、一度ユーザのコンピュータに読み込まれたら、サービス側で当該データやスクリプトが書き換えられない限りは、再読み込みは不要で、いわゆるキャッシュ可能なコンテンツです。以前は、SSL/TLS経由で取得したデータはキャッシュされないようになっていましたが、最近はWebサーバ側でのTLS化が強く推奨されるようになったこともあり、TLS経由で取得したデータであってもブラウザ側でキャッシュされるようになっています。

また、スマホアプリなどは、スマートフォン上に置いておけばよいものはスマートフォン側に置いておき、必要なデータをサービスから取得する、というつくりに（最初から）なっています。これもまた、帯域を圧迫させにくい構成と言えるでしょう。

帯域を消費しないWeb技術

その他、サービス提供において細部に工夫することも手です。例えば、Webページで使用する画像形式を、仕様が許せばSVGなどの軽量なフォーマットにしていくというのも、帯域を圧迫させないためには有効な手段と言えます。

ここまでをまとめると、以下の3点に集約されます。

• 手元のコンピュータ側で可能な処理は、手元のコンピュータにさせる
• Webアプリ / Webサイトのデータをキャッシュできるように、静的に作れるところは静的に作る
• なるべく軽量なデータ形式を採用する

サービス提供側で取れる、帯域不足の予防策＋α

サービス側で帯域が不足する事象は、ユーザ数が増えていることの証左でもあり、その点では喜ばしいでしょう。一方で、良好なサービス提供をされていない、とユーザが感じてしまう場合、サービスのブランド毀損や、信用低下などにもつながります。

こうしたリスクを避けるためには、本来、ユーザ数の見積もりや適正なシステム構築などが行われるべきです。しかしなにかのきっかけで急にサービスがよく使われるようになった場合は、たとえば以下のような対処を行うことで、帯域不足を回避することが可能になると考えます。

• すでに述べた、帯域を消費しない技術を採用する
• オンプレミスではなく、クラウド基盤上でのサービス提供を行う
  • さらにシステムの負荷分散を行える構成にし、帯域や性能が不足することのないよう備える
• コンテンツ配送ネットワーク（CDN）の利用を視野に入れる
• どうしても帯域を必要とするデータをやりとりする必要がある場合には、やりとりする先を絞る
  • たとえば、オンライン会議システムなどでは、発言した人の映像のみ有効にする、などのように工夫するまた、可能であれば、ユーザ間でやりとりすればよいデータは、ユーザ間で直接やりとりできるようにする（1対1の対話でかつカメラ画像をやり取りする場合などは、直接エンドツーエンドでやりとりできるようにする）

ただし、このような対処はやり方を間違えると、セキュリティ上の課題を抱えるリスクにもつながります。実施検討時には、適切な実装方法やリスク分析などもあわせて実施するよ必要があります。

もうひとつ、サービス提供側の帯域とは少し違う観点ではありますが、システム構成上、処理が集中する点をみきわめ、適切な対策を実施しておくことも良好なユーザ体験をするうえで重要であることも付記しておきます。

仮にサービス側、通信経路、ユーザ側すべてで帯域上の問題がない場合であっても、サービスを提供するシステムの中で処理が集中する点が性能不足だと、サービス提供に影響してきます。「ログインできない」「ログインできてもサービスの一部を利用できない」といった事象が発生するからです。

このようなケースを防止すべく、システム側の運用管理により、個別要素の性能を把握することが、帯域への配慮同様に重要なのです。

帯域不足は喫緊の課題だが、ユーザ / サービスそれぞれの工夫の余地がある

ここまで、通信における「帯域」の考え方と、帯域不足が発生する箇所、そして対処の仕方を駆け足で説明してきました。サービス側やユーザ側だけでは対処できない部分、早急な抜本的解決ができない部分がありますが、通信量を減らすような局所的な対応をユーザ / サービスそれぞれで実施することで、応急処置は可能です。

ただサービス運用を俯瞰したとき、帯域不足とはあくまで「課題のひとつ」にすぎません。サービス提供を行うシステムの基本構造が、そもそも性能問題を生じさせやすいような場合などは、帯域不足が解決しても他の課題に直面する可能性が高まります。

適切なユーザ体験を提供するために、サービス提供側は、帯域も含めた全体的な性能のバランスを取り、どこに課題が生じても対応できるだけの知見や要員を確保することが重要である、ということを述べて、本稿を終わります。

みやもと くにお @wakatono

某SIerに勤務する、どこにでもいる技術者。OSやネットワーク技術に興味を持ち，その延長でセキュリティ技術にも興味を持って、いろんな調査や研究を手がけてます。自分で思考を巡らしたり検証したり、というのももちろん好きで、あれこれやってます。もちろん他の人に迷惑はかけない範囲で……ですが。主な著書に『イラスト図解式 この一冊で全部わかるセキュリティの基本（刊：SBクリエイティブ）』、主な監訳書に『実践 Metasploit（刊：オライリー・ジャパン）』がある。博士（情報学）、技術士（情報工学）。
ブログ：wakatonoの戯れメモ

編集：馮富久（株式会社技術評論社）