Microsoft 365が遅い。クラウドサービス利用時の通信負荷の解消方法を徹底解説

2019年9月9日

Microsoft 365に象徴されるように、業務に必要なシステムをクラウド化する流れが広がりを見せています。場所やデバイスに縛られず、情報共有やコミュニケーションが活性化する――。自社で資産を持たないため、運用管理の手間を軽減できる――。様々なメリットをもたらす一方、「レスポンスが遅くなる」「つながらない」といった課題に頭を悩ませている企業も少なくありません。クラウドサービスにつながるネットワークの通信負荷の増大がその原因です。これを解消する具体的な対策を紹介しましょう。

【保存版】通信負荷解消レポート&
クラウドプロキシガイド 2冊セットで
ダウンロード（無料）

目次

「処理が遅い」「つながらない」はなぜ起こるのか？
通信遅延を解消する4つの方法
4つの方式の課題を克服する新たな選択肢が登場
【資料ダウンロード】通信負荷解消の4つの方式を更に詳しく比較
テレワーク拡大によって生まれた新たな課題

「処理が遅い」「つながらない」はなぜ起こるのか？

企業ビジネスにおけるクラウドサービスの利用が本格化する中、オンプレミスで運用していた業務システムをクラウド化する流れが加速しています。これを軸にビジネス変革や働き方改革を推進するのが狙いです。実際、コミュニケーション／コラボレーションプラットフォームとしてMicrosoft 365やG Suite、情報共有基盤としてBoxなどが広く利用されています。

一方でクラウドサービスの利用拡大と共に、新たな課題も顕在化しています。クラウドサービスはネットワーク越しにサービスを利用するため、インターネット回線やネットワーク機器に負荷がかかるとパフォーマンスが低下してしまうのです。その一例として、近年様々な企業で導入が進んでいるMicrosoft 365 のケースを見てみましょう。

一般に社内からのWebアクセスはプロキシサーバやファイアウォールなどで構成されるインターネットゲートウェイを経由します。プロキシサーバで処理する一般的なWebアクセスは数セッションですが、Microsoft 365の場合は使い方によっては30～40セッションに増え、プロキシサーバが処理しきれなくなるといった症状が出やすいのです。（図1）

しかも、メールやグループウェアの機能を提供するExchange Onlineは日常業務を支えるアプリケーション。利用する社内ユーザ数が多く、利用頻度も高い。コミュニケーションツールのMicrosoft Teamsなどを使うと、必然的にネットワークの接続時間も長くなります。

プロキシサーバが処理しきれなくなると、「レスポンスが遅い」「つながらない」などの悪影響を引き起こします。当然、Microsoft 365だけでなく、通常のWebアクセスも遅延してしまうため、このような現象が頻発すると業務が滞り、ビジネスがスムーズに回らなくなります。プロキシサーバの課題を解消することは、ビジネスを円滑に進める上でも重要な課題なのです。

（資料DL）【保存版】通信負荷解消レポート&クラウドプロキシガイドを差し上げます。
ダウンロード（無料）

通信遅延を解消する4つの方法

では、こうした通信遅延を解消するにはどうしたらいいのでしょうか。その方法は大きく4つあります。

1つめは「プロキシサーバ / 回線の増強」です。プロキシサーバの増強や、インターネットゲートウェイの帯域を増やす方法です。これまでのプロキシサーバが渋滞している道路だとすると、この方法は狭かった道路を拡幅するイメージ。増強によりキャパシティが拡大することで、より多くのセッションを処理できるようになります。ボトルネックとなっている部分を増強するため、抜本的な解決策と言えます。

しかし、新たににプロキシサーバやネットワーク機器を追加導入するためには、当然、相応のコストを見込んでおく必要があります。運用する機器も増大するため、その管理負荷も高まります。また、利用頻度の高まりや、クラウドサービスの機能追加によって予期せず、通常のWeb閲覧に影響を与えてしまう可能性もあります。帯域の設計や見直しを継続的に行う必要があり、手間とコストがかかるのが難点です。

2つめは「Proxy.pacによる除外」。各PCが接続するプロキシサーバを自動選択する方法を定義したProxy.pac（プロキシ自動設定ファイル）を変更する方法です。除外するURLをWebブラウザに設定することで、このWebアクセスがプロキシサーバを経由しないようにします。この除外URLに、Microsoft 365の接続URLを指定しておけば、プロキシサーバを経由しないWebアクセスが可能になり、通信負荷を軽減できるわけです。この方式は物理的なネットワーク構成に手を加えることなく実現できるのがメリットです。

しかし、Microsoft 365接続用のURLや宛先IPアドレスは固定されておらず、頻繁に更新されます。接続用URLや宛先IPアドレスの情報を事前に入手し、管理者による除外リストの更新作業が必要になります。対応に漏れがあると、構成次第では「つながらない」という事態に陥ったり、予期せずプロキシサーバを圧迫してしまうこともあります。日々の運用の手間は避けられないでしょう。

3つめは「負荷分散装置による振り分け」。社内LANとプロキシサーバの間に負荷分散装置を導入し、Microsoft 365への通信を振り分ける仕組みです。プロキシサーバのセッションを分散するという点では、Proxy.pacによる除外の方法と考え方は同じですが、こちらはそれを専用装置で行います。（図2）

負荷分散装置として専用装置を利用することによって、シンプルに振り分けを実現することができます。ただ、新たにアプライアンス機器を導入するため、初期費用が高額になりがちです。実装されるソフトウェアがバージョンアップした場合は、メンテナンス作業が必要となり運用面も考慮する必要があります。コストと運用の手間がネックになります。

4つめは「インターネットブレイクアウト（ローカルブレイクアウト）」という方法です。ソフトウェア制御が可能な「SD-WAN」の機能を利用して、Microsoft 365など特定のアプリケーションのみを各拠点から直接インターネットへ接続させます。これにより、インターネットゲートウェイへの一極集中を防ぎます。（図3）

インターネットブレイクアウト（ローカルブレイクアウト）は非常に合理的な方法ですが、こちらはSD-WANの導入が前提となります。SD-WAN用機器でアプリケーションの識別を行い、インターネットブレイクアウトを実現します。Microsoft 365の通信負荷対策以外にも管理の一元化や柔軟なネットワーク運用の実現など様々なメリットが期待できます。

ただし、SD-WAN用機器は非常に高価。また、各拠点にはWAN回線に加えて迂回用のブレイクアウト回線を引く必要があり、その分のコストもかかります。またブレイクアウト用にフレッツ回線を使用する場合は、回線混雑による通信遅延の心配もあります。せっかく通信を迂回させても、ブレイクアウト用回線がボトルネックとなり遅延してしまうリスクもあるので注意が必要です。

（資料DL）【保存版】通信負荷解消レポート&クラウドプロキシガイドを差し上げます。
ダウンロード（無料）

4つの方式の課題を克服する新たな選択肢が登場

このように4つの方式はメリットがある一方で、デメリットもあります。デメリットとして共通するのは「コスト」と「運用の手間」です。

運用面ではもう1つ、各方式に共通する重要な課題があります。公開されているMicrosoft 365接続用のURL情報の中には、Facebookなどのソーシャルサービスの情報も含まれています。単純にMicrosoft 365接続用のURL情報をすべて除外対象としてしまうと、この中に含まれるFacebookなどのソーシャルサービスもプロキシサーバを介さずにWebアクセスできるようになってしまうのです（図4）。つまり、プロキシサーバ上のWebフィルタリング機能などで該当のサイトへのアクセスを制御していても、システムの抜け穴になってしまうということです。

※2019年8月27日時点の情報です。最新情報はMicrosoft公式サイトをご覧ください。

企業のセキュリティポリシーとして、プライベートなソーシャルサービスの利用を禁止していても、それが必ず守られるとは限りません。会社の重要な情報や個人情報が外部に流出したり、ソーシャルサービスを介してマルウェアに感染する危険性が高まってしまいます。これを回避するためには、数多くのMicrosoft 365接続用のURL情報の中からFacebookなどのソーシャルサービスを探して外すという面倒な作業が必要になります。Microsoft 365接続用のURL情報はサービス拡充により頻繁に変更されるため、この作業は大変な手間です。

また業務で利用するクラウドサービスはMicrosoft 365だけとは限りません。他のクラウドサービスの利用が広がれば、通信負荷の高騰という同じ問題に直面します。今後の拡張性も視野に入れる必要があるでしょう。

そうした中、最近では負荷分散装置をフルアウトソースで利用できるサービスも登場しています。これなら新たな回線の敷設や機器購入、構築による高額な初期費用も不要です。フルアウトソースのサービスなので、機器の保守や運用の手間もかかりません。Microsoft 365のように頻繁に変わる接続用URL情報にも自動で追従してくれるため、対応漏れの心配もありません。オンプレミスで導入・運用する場合は、通信のMAX値を想定したキャパシティプランニングが必要ですが、サービス型ならユーザ数の増減など利用状況に合わせて柔軟にサイジングできます（図5）。

こうしたサービスの1つとして、IIJでは「IIJクラウドプロキシサービス」を提供しています。4つの方式に共通する「コスト」と「運用の手間」という課題をクリアし、サイジングも柔軟に行えます。分かりやすい直感的なインタフェースの管理画面も特長です。これを使えば、Microsoft 365接続用のURL情報の中からFacebookなどのソーシャルサービスを除外する編集作業も簡単に行えます。

Microsoft 365をはじめとするSaaSは、ビジネスに不可欠なツールとなっています。その通信にボトルネックがあると、業務が滞り、ビジネスに大きな影響を及ぼします。かといってオンプレミスの対策では「コスト」と「運用の手間」が大きなハードルになります。4つの方式に加えて、今後はIIJクラウドプロキシサービスのようなサービスを活用する方法のも有力な選択肢となるでしょう。