近年クラウド型サービスの導入が増えている中で、特に Office 365 を導入または検討されている企業が増えています。Office 365 を導入するメリットは色々考えられますが、常に最新バージョンの Office 製品をマルチデバイスで使うことができる点でしょうか。
メールやスケジュールといったグループウェア機能も使えますし、コスト的にメリットがあるようです。また、サーバーなどインフラの維持管理が必要ないことや、BCP 対策およびセキュリティ対策としても有効です。
このような理由から、今後も Office 365 ならびにその他のクラウドサービスの利用は拡大していくと考えられます。しかし一方で、導入後や運用時にトラブルが発生したというお話をよく伺うようになりました。
■ よくあるトラブルについて
社内のオンプレミス環境で利用していた Office システムを、インターネット上のクラウドサービスである Office 365 へ移行することで通信経路が変わり、今まで介在しなかったファイアウォールやプロキシサーバーを経由した通信が発生します。
また、メールプロトコルも POP や IMAP から HTTP ベースでの接続に変わり、セッションのタイミングや保持する時間などが変わります。
そのため、Office 365 を導入後、従来のネットワークでは問題にならなかった箇所が新たなボトルネックとなり、遅延や接続ができない、画面がフリーズするなどのトラブルが発生します。
多くの場合は、インターネット回線の帯域不足と、セッション数増加によるファイアウォールやプロキシサーバーの性能不足が原因です。
従来のインターネットへの通信に加え、Office 365 を導入したことにより発生するトラフィック量が上乗せされるため、インターネット回線の帯域不足が生じます。
トラフィック量が増加する要因は大きなファイルのメール添付やアップロード・ダウンロードであり、セッション数が増加するタイミングは予定表確認時やメール閲覧時です。
特に、予定表の確認は要注意で、例えば私が自分以外の人の予定を確認すると、その人数分のセッションを張ることになります。特定のグループのメンバー全員が、他のメンバー全員の予定を確認したとすると、それだけで大量のセッションとなってしまいます。
このように、遅延や接続できないトラブルが発生する可能性がある Office 365 環境においては、性能監視が重要です。では、どのような着目点で性能データを取得し、どのように管理すればよいのでしょうか。IBC が推奨する取得項目をご紹介します。
■ Office 365 環境における性能監視の着目点
まず、ファイアウォールとプロキシサーバーのリソース状況や稼働状況を可視化することが必要です。CPU 使用率やセッション数、機器によっては TCP Establish 数や Open 数といった項目を取得するとよいでしょう。
次に、インターネット回線における帯域状況の確認のために、トラフィック量を取得します。ネットワーク構成によっては、ファイアウォールではなくルーターのトラフィック量が対象になるお客様もいらっしゃると思います。
また、帯域不足や性能不足によって廃棄パケットが発生することがあるため廃棄パケットの有無と、HTTP や ICMP のレスポンスタイムを取得することが望ましいです。
その他、クライアント側でどのくらいのリクエストが発生しているかを表す TCP Open 数とトラフィック量も分析する上で参考となるデータです。
次に、各取得項目における 5 つの着目点をまとめます。
【セッション数における着目点】
- カタログスペックなどの上限値を確認し、上限値に対する割合を把握
…セッション数だけではその値がよいか悪いかの判断ができないため
- 上限値のデフォルト値に注意
…Linux ベース製品の場合、1 プロセスが同時にオープンできるファイルディスクリプタ数はデフォルト値 1024 となっている (Redhat 系 Linux の場合、ulimit コマンドで確認、チューニングが可能)
- セッション数が増減を繰り返すのではなく、ほぼ一定値となるような環境が望ましい
…新規セッションを張る際のスリーウェイハンドシェイク開始時に遅延が発生する
- クライアント側の観点で確認
… 1 クライアントあたりのセッション数は想定内かどうか
【CPU 使用率における着目点】
- CPU 使用率とセッション数との相関を確認
- ピーク時の負荷の程度を確認
- 機種固有のリミット値に注意
…リソースに余裕があるように見えても、機種によって上限が異なる
…ある一定値を超える同時セッション数は、処理できない可能性がある
【トラフィック量における着目点】
- インターネット回線の帯域使用率を確認
- ファイアウォールやプロキシサーバーのインターフェイスに対するトラフィック量を比較
…トラフィック量に差異がある場合は、途中で捨てられている通信が存在する
【インターネット回線における着目点】
- Office 365 へのレスポンスタイムを取得して、実際の応答時間を確認
…その他のサイトでも同様に遅延が発生していれば、LAN 内が原因の可能性がある
【廃棄パケットにおける着目点】
- 遅延の原因となる廃棄パケットの有無を確認
…発生している場合は CPU 使用率、セッション数、トラフィック量との相関を確認
このような着目点で取得した性能データを分析し、遅延や接続できない原因を突き止めていくことで、ICT インフラの安定稼働を実現することができます。
■ ユーザー事例
System Answer G2 のユーザー様で Office 365 をご利用されている企業の監視事例をご紹介します。下図のようにデータセンター集約型で、各拠点からデータセンターを経由してインターネットに抜ける構成です。
System Answer G2 でプロキシサーバーの CPU 使用率、TCP Open 数、TCP Establish 数を取得したグラフデータがこちらです。
おさらいになりますが、下記のポイントに着目しました。
- TCP 接続数の上限を確認した上で、TCP Establish 数の最大値 4,850 がどの程度の割合か
- 12 時頃にピークがあり、新規に接続するセッションが増加しているが、CPU 使用率は 8 % 程なので問題ない
- プロキシサーバーを分散しているため、もう 1 台と比較して負荷に偏りがないか
また、このユーザー様は Quality Analyzer Option もご利用いただき、各拠点からインターネットへの通信をデータセンターの L3 スイッチでミラーリングし、拠点ごとにトラフィックやコネクションの情報を取得しています。
System Answer G2 でネットワークインフラ全体の性能状況を可視化しつつ、Quality Analyzer Option でパケットをキャプチャし、フローデータや品質データを可視化することで、性能と品質双方の詳細な分析をすることができます。
各拠点におけるプロキシサーバーへのコネクション数の比較も容易におこなうことができます。名古屋拠点は社員数も少ないですが、その他の拠点に比べてコネクション数が少ないです。
また、本社 1 階と大阪拠点は同程度のコネクションですが、1 日の傾向が異なります。大阪では朝の 9 時頃はまったくコネクションがありませんが、その分、夕方から夜間にかけて多いことがわかります。
このように、拠点およびフロアごとにトラフィックやコネクションの傾向が把握できるため、社員数が増加した場合に、どのくらいセッションが増加するのか、ファイアウォールやプロキシに与える負荷はどのくらいになるかを予測することが可能です。
負荷状況を確認しながら段階的に対象ユーザーを増やしていくことで、安定した新しいサービスの導入ができるでしょう。
実際、Office 365 の導入後や運用時のトラブルをきっかけに、IBC が調査をさせていただくことが増えています。
今回ご紹介できなかった事例やノウハウも数多くあります。
現在 Office 365 の導入を検討されているお客様、または既に導入済みで何らかの問題を抱えていらっしゃるお客様は、是非一度ご相談ください。
by コンサルティング部 亀山 悟史
