Office365 のサービス監視

による投稿 2018年4月4日
2018年5月10日

「うちのインフラ環境はMicrosoft Office 365に対応しているのか?」 「自社インフラではなくクラウド上で稼働するO365のネットワークパフォーマンスを監視し、全社員に完璧なユーザーエクスペリエンスを確保するにはどうすればよいのか?」これらは、Exchange OnlineやSharepoint Onlineを含むOffice 365製品群を採用した多くの担当者から寄せられる悩みの質問です。

自社所有ではないネットワークやデータセンターに依存しているため、SaaSアプリケーションの監視は難題です。従来のネットワーク監視ツールと技術(SNMPやフローなど)はすべて、自社所有のインフラのみを監視対象としています。Microsoftのルーターをポーリングしたり、データセンターからフローデータを取得したり、Exchange Onlineサーバーに独自の監視エージェントをインストールすることはできません。では、対象サービスのインフラとネットワークを所有していない場合、どのようにシステムを管理できるのでしょうか?

ネットワーク事業者は、伝統的にインターネットと外部サービスをブラックボックスと呼んできました。なぜなら、自社インフラとの境界外では可視性がゼロだったからです。ますます重要なITアプリケーションが自社データセンターの外に移行される中、これは黙認できるアプローチではありません。アクティブモニタリング技術とアプリケーション層データとネットワーク層データの組み合わせにより、ThousandEyesはSaaSの世界で生き残るだけでなく、勝ち組になるために必要な「ネットワークインテリジェンス」を提供します。シンプルなベストプラクティスの推奨事項により、適切なOffice 365展開の準備、必要なパフォーマンの設定、障害解決時のナビゲートや、優れたエンドユーザーエクスペリエンスの確保が可能となります。

Offce365のアーキテクチャ

Microsoft Office 365は、ポータルの下に集約された共通の外観と操作性を持ったアプリケーションの集まりです。しかし、これらのアプリにはいくつか共通点はありますが、時に全く異なる方法でサービス提供されることもある個別のアプリケーションです。

図1:Microsoft Office 365のアーキテクチャ
図1:Microsoft Office 365のアーキテクチャ

マイクロソフトは、世界中のほとんどのISPとピアリング接続を持つデータセンターとIPバックボーンのグローバルネットワークを持っています。 Office 365のアプリケーション群は、インターネット経由で配信されるよう最適化されており、Microsoftはできるだけユーザーに近い場所からのサービス提供を目指しています。企業ユーザーの場合、Office 365導入時の最初の決定事項の1つは、すべてのOffice365トラフィックをWAN経由で集めて、自社のセキュリティスタックを通した後、インターネットに送信するか。またはVPNトンネルを使用し、支店から直接最寄りのマイクロソフトのPoPに接続するかです。

マイクロソフトでは、ほとんどのアプリケーションの提供に2層のCDNアーキテクチャを使用しています。ユーザセッションは、通常、エニキャストDNSロードバランシングの「ブレイン」によって決定されるエッジデータセンター(サービスフロントドアと呼ばれる)で終端されます。ここでの目標は、ユーザーとMicrosoftエッジとの間のネットワークの待ち時間を最小限に抑えることで、SSLハンドシェイクのような時間のかかる作業は妥当な時間枠内で行われます。ここから、エッジサーバーは実際のアプリケーションが存在するさらに別のデータセンターに接続をプロキシします。 Exchange Onlineの場合、メールボックスサーバーの場所は一般的に動的ですが、Sharepoint Onlineではすべてのクライアントデータが集まるデータセンター・リージョンが固定されています。

これにより、興味深い違いが見られます。たとえば、図2に示すThousandEyes Service Health Dashboardでは、Exchange OnlineとSharepoint Onlineのアプリケーション応答時間の違いを確認できます。 Exchange Onlineの応答時間は、世界中で均等に分散されますが、SharePoint Onlineは、バージニア州アシュバーンのプライマリデータセンターから遠ざかるにつれて悪化します。私たちの最近のOffice 365モニタリングベストプラクティスのWebセミナーでは、これらの詳細についてお話ししています。ビデオでデモをご覧ください。

図2:Office 365監視ダッシュボード
図2:Office 365監視ダッシュボード

何を監視すべきか?

Office 365のアプリケーションには、独自のURLと配信アーキテクチャがあります。したがって、各アプリケーションを個別に監視することが重要です。いくつかは論理的にグループ化できます。たとえば、Liveアプリはすべて共通のプラットフォームでホストされ、ホスト名を共有します。ただし、Sharepoint Online、Exchange Online、OneNote、Azure Active Directory(AD)はすべて個別のURLです。

また、アプリ全体のパフォーマンスにAzure ADの影響を忘れないでください。 ThousandEyesが繰り返すすべてのテストは、以前にキャッシュされたデータがないクリーン状態から開始します。アプリケーションがこの要求を受け取ると、それに沿って送信される認証トークンはありません。したがって、アプリケーションはこの要求をAzure AD(またはその他の設定済みのIdentityプロバイダ)にリダイレクトします。デフォルトでは、ThousandEyes HTTP Serverテストはリダイレクトに従うように設定されていますが、これは簡単に無効にすることができます。主にネットワークのパフォーマンスとアプリケーションのパフォーマンスの調査には、簡単なHTTP サーバテストを実行します。ただし、トランザクション全体を測定する場合は、サービスアカウントを使用してログインを実行し、Office 365製品群の複数のアプリケーションにアクセスするトランザクションテストを設定できます。

図3:Office 365向け推奨テスト
図3:Office 365向け推奨テスト

Office 365のパフォーマンスをどのようにベンチマークしますか?

クラウドには一定した稼働状態はなく、常に状態変化しています。したがって、パフォーマンス測定の特定のベンチマークを定義することはできません。その代わりに、社内の別ユーザーや、同じ都市にいる他のユーザーとあなたが体感しているパフォーマンスを比較するアプローチがあります。

これを実現するには、ThousandEyesエンタープライズ・エージェントを主要なオフィスに配置し、同じ都市のクラウド・エージェントとのパフォーマンスと比較します。図4は、サンフランシスコの本社にあるエンタープライズ・エージェント(SF-Office-1)とサンフランシスコ市内のクラウド・エージェントとの比較を示しています。

図4:Exchange Onlineのパフォーマンスのベンチマーク
図4:Exchange Onlineのパフォーマンスのベンチマーク

これら2つのパフォーマンス値の推移が多かれ少なかれほぼ一致していることが想定されます。運が良ければ、同じ都市にいる仲間よりも優れたパフォーマンスが得られるかもしれませんが、これらの値の推移が大きく異なり、パフォーマンスが悪化し始めると、その要因を理解する必要があります。

応答時間が遅くなるのは、DNS解決の問題からネットワークの遅延、アプリケーションの待機時間までのさまざまな要因によって引き起こされる可能性があります。これらの要因すべてがそれぞれ異なる企業・組織・グループやベンダーによって管理されている可能性があるため、その要因を理解することが重要です。問題がISPによって引き起こされたネットワーク遅延の場合、Microsoftのサポートチケットはあまり役に立ちません。逆に、アプリケーション待ち時間の遅延の場合、ISPがOffice 365のパフォーマンス問題を解決することはできません。可視化により、Office 365の効果的な運用プロセスを構築することができ、MTTT(平均切り分け時間)とMTTR(平均復旧時間)を削減し、ヘルプデスクのコストを最小限に抑えるための鍵となります。

図5:OutlookのHTTP サーバ応答時間グラフ
図5:OutlookのHTTP サーバ応答時間グラフ

障害発生時のトラブルシューティング

アプリケーション層とネットワーク層のデータを組み合わせた可視化データが、Office 365のパフォーマンス上の問題の根本原因を特定するのに役立ちます。今までのように、問題の範囲を特定するために、ユーザーからの不確定な問い合せや主観的なデータに頼り推測する必要はありません。 たとえば、図6では、短期間のHTTP サーバ停止が発生しています。この停止は、特定箇所(ドイツ、ベルリン)からの100%のネットワークパケットロスと関連しています。 ThousandEyes のパス可視化機能は、このパケット損失の原因をMicrosoftネットワークの一時的なエラーとして特定します。 このエラーが速やかに解決されない場合には、スナップショット機能の共有リンクをマイクロソフトのサポートチケットに添付することにより、迅速に問題解決することができます。マイクロソフト社にインシデントに関連する実用的なデータを提供することにより、問題切り分け時に要する時間を大幅に短縮でき、この運用フローはすべての関係者にメリットもたらします。

図6:アプリケーション停止の根本的な原因
図6:アプリケーション停止の根本的な原因

クラウド対応のためのライフサイクル

クラウドには一定した稼働状態はなく常に変化しています。 Office 365環境では、刻々と変化する稼働状態や、自分では制御できないネットワークやアプリケーションを考慮する新しいアプローチが必要です。 ThousandEyesは、定常的な監視を実行するライフサイクルのアプローチを継続することを推奨しています。テストユーザーに展開する前に、まずはOffice 365アプリケーションを監視して準備を整えます。展開時の明確な成功基準を設定し、関係するすべてのチームとベンダー間で新しいエスカレーションプロセスを構築します。問題の速やかな検知により優れたユーザーエクスペリエンスを確保するため、アプリのパフォーマンスの継続監視によりベンチマークし、エンドユーザーが体感するサービスレベルの指標を監視します。

図7:クラウド対応ライフサイクル
図7:クラウド対応ライフサイクル

ThousandEyes の15日間無料トライアルでOffice 365アプリケーションの監視を試してみませんか? 世界中の150以上の都市に配置されたクラウド・エージェントにアクセスし、今までわからなかったパフォーマンスに関する疑問へ答えがすぐに見つかるでしょう。また、御社内にエンタープライズ・エージェントを設置すれば、社内からOffice 365やその他クラウドまでのサービスレベルが可視化され、エンドポイント・エージェントの利用では、エンドユーザーからの実アクセスを直接理解することもできます。

詳細については、Office365モニタリングのベストプラクティス・ウェブセミナーのビデオをご覧ください。