Office 365の利用者に動作が“重い”と苦情を言われたときにとるべき対策は?最新ルーターでSaaS時代のネットワーク管理を高度化せよ

Microsoft Office 365は、生産性の向上と管理工数の削減に貢献するクラウドサービスだ。ただ、SaaS型であるがゆえ、利用者の増加とともにITリソースの消費が増えることも確か。もし、Office 365を導入したものの、利用者にアプリの動作やネットワークが“重い”と苦情を言われたら、あなたならどうしますか――。そんなときは、一見クラウドサービスの導入に関係がないと思われがちなネットワークに原因が潜んでいるかも知れません。

» 2018年02月26日 10時00分 公開
[PR/@IT]
PR

Office 365を導入すると、なぜネットワークが“重く”なるのか?

 MicrosoftのSaaS(Software as a Service)型クラウドサービス「Microsoft Office 365」を導入する企業は年々増加傾向にある。

 その最大の理由として挙げられるのが、機能の豊富さだ。エントリーのOffice 365 Enterprise E1でも、メール、オンライン会議/インスタントメッセージング、Office Onlineなどが利用可能。上位のOffice 365 Enterprise E3/E5では、Officeアプリケーション、セキュリティ、コンプライアンス、分析、音声通信機能なども含まれているという大盤振る舞いだ。

 また、各サービスがPCへのインストールが不要なSaaSとして提供されるので、運用や維持管理コストの大幅削減が可能。Office 365 Enterprise E3/E5のOfficeアプリケーションもインターネット経由でダウンロード/インストールするため、各クライアントへ配布する手間もかからない。経営の観点では、メールやデータをクラウドで保管でき、大規模災害などが発生した場合でも短期間で復旧し、業務を再開できるというメリットは大きい。

 このように“良いことずくめ”に見えるOffice 365にも、見過ごされがちな“危険箇所”がある。導入前にきちんとアセスメントを実施して、適切な対策を講じておかないと、利用者から「これまでのOfficeと違って動作が遅い」「Office 365を導入したら、Officeと関係のないその他のインターネット接続まで遅くなった」といったクレームが発生しかねないのだ。

 この問題には複数の原因が考えられるが、最も疑わしいのはネットワークだ。PCにインストールして使うこれまでの“オンプレミス”のOfficeスイートと違い、Office 365はインターネットに強く依存している。SaaSとして提供されるOffice Onlineを利用するにはインターネットが欠かせないし、Office 365 Enterprise E3/E5に含まれる(インストール方式の)Officeアプリケーションも起動時にオンラインでの認証が行われる仕様になっている。

 それにもかかわらず、インターネットとの接続ポイントを本社やデータセンターに一本化するネットワーク構成のままでOffice 365を利用していると、インターネット通信によるネットワーク負荷の増大がいろいろなところに“ひずみ”として現れてくるのである。

“重い”の原因はセッション数と伝送データ量の増加にあり

 例えば、支社や支店、営業所から本社/データセンターまではVPN(仮想プライベートネットワーク)で結び、プロキシサーバやUTM(Unified Threat Management:統合脅威管理製品)などのセキュリティ機器を経由してインターネットに接続するネットワーク形態の場合(図1)――。使用するアプリケーションがオンプレミスのサーバ(またはローカルPC)で実行されることを前提にしたネットワーク設計になっていると、プロキシサーバやUTMのセッションテーブル数が十分でないことも多い。

図1 図1 典型的な企業ネットワークの構成。支社や支店、営業所から本社/データセンターまではVPNで結び、プロキシサーバやUTMなどのセキュリティ機器を経由してインターネットに接続する《クリックで拡大します》

 このようなネットワーク構成のままでOffice 365を全支店・全営業所に展開すると、Office 365の利用者数に応じて多数のセッションが生成されることになる。結果、セッションテーブルの枯渇によって「通信が遅い」「通信できない」といったトラブルが頻繁に発生することになるわけだ。特に危ないのは、多くの人がOutlookを開いてメールをチェックする始業直後の時間帯だ(図2)。

図2 図2 Office 365を利用する人の数に応じて多数のセッションが生成されるため、プロキシサーバやUTMのセッションテーブルが枯渇してしまう《クリックで拡大します》

 では、従業員数が少なく、PC台数もそれほど多くない企業の場合はどうか――。セッション数の急増によるトラブルは発生しないものの、その代わりに、データ伝送量の増加による帯域幅の逼迫が問題になってくる。過去のネットワーク設計時に見積もったデータ伝送量はOffice 365の通信を含まない数値なので、Office 365を使い始めると、他のインターネット接続がスローダウンする場面が増えてしまうのである(図3)。

図3 図3 PC台数が少なくても、Office 365との通信によってデータ伝送量が増え、帯域幅が不足することがある《クリックで拡大します》

 こうした“セッション数”と“データ伝送量”の急増に起因するネットワークのスローダウンや接続不可のトラブルを解決する方法は幾つかある。

 例えば、セッション数については、セッションテーブルの上限数が多いプロキシサーバやUTMに買い替えるという解決法がある。ただし、希望する上限数に合致するモデルがないと大きめのモデルを選択するしかなく、高い買い物となってしまう懸念がある。

 そこでお勧めしたいのが、「Office 365に関するパケットだけをプロキシサーバやUTMを迂回させる」という方法だ。この方法では、Office 365を導入してもセッションテーブルが急増することはないため、プロキシサーバやUTMの増強は不要となる。Office 365との通信は全てHTTP over SSL(HTTPS)ベースで暗号化され、接続先の正当性もデジタル証明書によって常に確保されているので、安全にネットワークを利用できる。

 データ伝送量の問題を解決するには、インターネット接続用の回線を増強するのが手っ取り早い。帯域幅を広げてもよいし、本数を増やしてもよいが、既存の設備を生かすことを重視するなら本数を追加した方がよいだろう。

 増設した回線と既存回線の使い分けは、ネットワーク側の負荷分散機能に任せてしまうこともできる。セッション数問題の解決策として紹介した「Office 365に関するパケットだけをバイパス側に流す」という方法を応用すれば、既存回線の使い方には手を付けずに、増設分の回線をOffice 365専用にすることも可能だ。

ポリシールーティングでOffice 365を別扱い

 では、「Office 365に関するパケットだけをプロキシサーバやUTMを迂回させる」あるいは「Office 365に関するパケットだけをバイパス側に流す」ための具体的な方法を紹介していくことにしよう。

 支社や支店、営業所などに必要となるのは、「URLオフロード」機能を搭載したルーター(NECの「UNIVERGE IXシリーズ」など)だ。URLオフロードは、通信の宛先を示すURLを手掛かりに、一部のパケットを別経路に振り分ける機能。この機能を利用して、Office 365専用のURLにアクセスするパケットをバイパスさせるのである。

●クラウドに最適なNECの高速アクセスルーター「UNIVERGE IXシリーズ」

 NECの「UNIVERGE IXシリーズ」は、Office 365をはじめとしたクラウドサービスの利用が進む企業での利用に最適な高速アクセスルーター。企業向けの小型ルーターとしては、最高クラスの転送性能と暗号化(IPsec)性能を実現し、ブロードバンド回線、ワイヤレス回線、光ファイバーなど、多彩な回線に対応する。

 最新機種の「UNIVERGE IX2106」は、シリーズ最量販の従来機種「IX2105」から価格(8万1000円、税別)を変えずに性能を2.5倍、セッション数も4倍に向上。企業のクラウドサービス利用拡大に対応する、高いコストパフォーマンスと信頼性を備えた小型高速アクセスルーターだ。

IX2105(従来機) IX2106(新機種)
IPv4転送性能 1.3Gbps 2Gbps
VPN性能 440Mbps 1.2Gbps
NAPTキャッシュサイズ 6万5535 25万
ALT ▲高いコストパフォーマンスと信頼性を備えた小型高速アクセスルーター「UNIVERGE IX2106」

 この他、データ伝送量の問題を解決する場合は、追加の回線も必要になる。設定方法は本社/データセンターに、プロキシサーバが設置されているかどうかによって異なる。

 プロキシサーバがない環境の場合は、「ポリシールーティング」(通常のルーティングテーブルは使用せず、リストに記載された条件に合致するパケットを自由にルーティングする技術)を使ってバイパスさせる。ポリシールーティングを制御するためのリストは、UNIVERGE IXシリーズが自動的に作成してくれるので、Office 365で使用する膨大なリストをいちいち設定する必要はない。Office 365が使用するIPアドレス とURLはXMLファイルで公開されているので(月に1〜2回程度更新)、UNIVERGE IXシリーズがこのXMLファイルを定期的にチェックしてリストを更新している(図4)。

図4 図4 Office 365が使用するIPアドレスとURLがXML形式のファイルに記録されている(本図は冒頭部とIPアドレス部)《クリックで拡大します》

 ここまでの準備が整っていれば、ルーターにデフォルトのルートを「本社/データセンターと支社/支店/営業所の間のVPN」に設定しておくだけで、パケットの振り分けが開始する。利用者側で行う作業は特にない(図5)。

図5 図5 「ポリシールーティング」機能でOffice 365通信をバイパス側に流し、他の通信はデフォルトルートの「本社/データセンターと支店/営業所の間のVPN」に送信する《クリックで拡大します》

プロキシ自動設定(PAC)ファイルでプロキシサーバを迂回

 本社やデータセンターに設置されているプロキシサーバを使用している場合は、ポリシールーティングだけでは解決できない。なぜなら、各クライアントPCは基本的に全ての通信をプロキシサーバ宛に行うため、ルーターではOffice 365宛の通信を識別することができないためだ。そこで、ポリシールーティングではなく、「プロキシ自動設定(PAC)」ファイルでパケットの振り分けを制御する。(NECが特許出願中)

【※】PAC:Proxy Auto-Config(プロキシサーバを自動選択する方法を定義したスクリプトファイル)



 この場合も、公開されているOffice 365で使用するIPアドレス/URLのXMLファイルの内容を基に、UNIVERGE IXシリーズがPACファイルを自動生成する。生成されたPACファイルには、Office 365宛の通信をプロキシ除外とする設定が書かれており、これによって各クライアントPCは、Office 365についてはプロキシサーバ宛ではなく、直接Office 365のURLへ通信する。つまり、プロキシサーバがあることによってOffice 365宛の通信を識別できなかった課題を解決できる。なお、別の目的で使われているPACファイルが既に存在する場合は、マージ(併合)しながら生成するので、既存のPACファイルの設定内容が失われることはない。作成されたPACファイルはDHCPの機能で自動配布されるので、クライアントPC側ではWebブラウザの設定で「設定を自動的に検出する」を有効化しておくだけでよい(図6)。

図6 図6 「Internet Explorer」またはWindows 10の「設定」を使って、PACファイルの自動検出機能を有効にしておく《クリックで拡大します》

 併せて、Office 365以外の通信が「Office 365用のバイパス」に紛れ込み、プロキシサーバを迂回してしまうのを防ぐためフィルターも、UNIVERGE IXシリーズが自動生成するようになっている。

 振り分けは、デフォルトのルートを「Office 365用のバイパス」に設定し、Office 365以外の通信はプロキシサーバを経由するように 「本社/データセンターと支店/営業所の間のVPN」にルーティングする。この設定によって、Office 365との通信はプロキシサーバやUTMを迂回できるようになる(図7)。Office 365との通信内容も「Syslog」に書き込まれるので、プロキシサーバ/UTMを経由していなくてもセキュリティ対策や監査用の証跡はしっかりと残すことができる。

図7 図7 プロキシサーバを使っている場合のバイパス方法。振り分けはプロキシ自動設定(PAC)ファイルで制御。デフォルトのルートを「Office 365用のバイパス」に設定し、Office 365以外の通信を「本社/データセンターと支店/営業所の間のVPN」にルーティングする《クリックで拡大します》

 なお、伝送量の問題がなくセッション数の問題だけが発生する場合であれば、オフロード用の回線を増やすことなく、VPNで利用している物理回線をそのままオフロード回線として使えることもある。物理回線としてフレッツ回線を使用しており、フレッツ・VPNワイドやInternet VPNを使っている場合がそれに当たる(図8)。

図8 図8 VPNと同じ物理回線を使って、オフロードが可能なケース《クリックで拡大します》

 また、データ伝送量問題を解決するために別回線を増設した場合は、既存回線と増設回線の2本を冗長化装備としても活用できる。「Office 365の導入に伴って回線増設が必要になった」では稟議が通らなくても、「事業継続性確保のために予備回線を追加し、普段はOffice 365用に使う」と申請すればスムーズに決裁を得られるのではないだろうか。

 さらに、URLオフロードを利用したバイパス処理は、Office 365だけでなく、その他の“重い”SaaS型クラウドサービスにも応用できる。例えば、Windows as a Service(WaaS:サービスとしてのWindows)化したWindows 10では、Windows Updateなどで大量のデータ伝送が頻繁に発生するようになった。この際にもパケットをバイパスさせれば、業務アプリケーション用の帯域幅を確保するのも容易だ。「Box」のようなファイル共有サービスを全社で使用している場合も、バイパス化の効果は大きい(UNIVERGE IXシリーズのURLオフロードは、「Box」のエコシステムソリューションに認定されている)。こうしたサービスをバイパスさせる必要性は今後も高まると予想され、NECではルーター単位で実現している機能をさらに発展させ、SDN(Software-Defined Networking)コントローラーからサービスを柔軟に制御できるよう強化していく考えだ。

※本記事に関連する資料をダウンロードいただけます。下記の「続きを読む」ボタンを押して会員登録もしくはログインのうえ、閲覧ください。

Copyright © ITmedia, Inc. All Rights Reserved.


提供:日本電気株式会社
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2018年3月26日

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。