Office 365 移行のパフォーマンスとベスト プラクティス

オンプレミスのメール組織から Microsoft Office 365 にデータを移行するには、多くの方法があります。Office 365 への移行を計画する場合に共通の課題となるのは、データ移行のパフォーマンスをいかに向上させ、かつ移行速度をいかに最適化するかということです。

注: このトピックに記載されているパフォーマンスに関する情報は、専用サブスクリプション プラン用の Office 365 サービスには適用されません。 専用プランの詳細については、「Office 365 専用プラン サービスの概要」を参照してください。

この記事の内容

Office 365 へのメール移行の概要

複数のメール アカウントを Office 365 に移行する方法」に記載されているように、Office 365 では、メール、予定表、連絡先のデータを既存のメッセージング環境から Office 365 に移行する、いくつかの方法をサポートしています。

Office 365 のネットワークとパフォーマンスの詳細については、「Office 365 のネットワーク計画とパフォーマンスのチューニング」を参照してください。

よく使用される移行方法

移行方法

説明

リソース

インターネット メッセージ アクセス プロトコル (IMAP) 移行

Exchange 管理センター または Exchange 管理シェルを使用して、ユーザーのメールボックスの内容を IMAP メッセージング システムからユーザーの Office 365 メールボックスに移行できます。 これには、Gmail や Yahoo Mail などの Microsoft 以外のホスティング メール サービスからのメールの移行が含まれます。

IMAP メールボックスを Office 365 に移行する

一括移行

一括移行を使用すると、すべてのオンプレミス メールボックスが数日で Office 365 に移行されます。 メール組織全体を Office 365 に移動して、Office 365 でユーザー アカウントを管理することを計画している場合は、一括移行を使用します。 1 回の一括移行を使用すると、最大 2,000 個のメールボックスをオンプレミス Exchange 組織から Office 365 に移行することができます。 ただし、メールボックスの推奨数は 150    です。 150 を超えると、パフォーマンスが低下します。 また、オンプレミス Exchange 組織のメール連絡先と配布グループも移行されます。

Office 365 への一括移行

段階的な移行

最終的に組織のメールボックスのすべてを Office 365 に移行することを計画している場合は、段階的な移行を使用します。 段階的な移行を使用すると、数週間から数か月かけて、オンプレミス メールボックスを何回かに分けて Office 365 に移行します。

Office 365 への段階的メール移行について知っておくべきこと

ハイブリッド展開

ハイブリッド展開によって、充実した機能の利用、および既存のオンプレミス Exchange 組織に対する管理制御をクラウドにまで拡張することができます。ハイブリッド展開は、オンプレミス Exchange Server 2013 または Microsoft Exchange Server 2010 と Office 365 の間で、統一された Exchange 組織のルック アンド フィールを実現します。さらに、ハイブリッド展開を Office 365 組織に完全に移行するための中間ステップとして使用することもできます。

Exchange Server 2013 のハイブリッド展開

サード パーティを利用した移行

サード パーティから入手できるツールは数多くあります。 これらのツールでは、独自のプロトコルやアプローチを使用して、IBM Lotus Notes や Novell GroupWise などのメール プラットフォームからメールを移行します。

サード パーティ プラットフォームから Exchange に移行する場合に利用できるサード パーティの移行ツールとパートナーを以下に示します。

  • Binary Tree プラットフォームに依存しないメッセージング移行/共存ソフトウェアのプロバイダーです。IBM の Lotus Notes/Domino と Exchange および SharePoint をベースとするオンプレミスおよびオンラインのエンタープライズ メッセージング/コラボレーション環境の分析、共存、移行を実現する製品を提供しています。

  • BitTitanOffice 365 への移行ソリューションのプロバイダーです。

  • Dell 移行前の分析やユーザーおよびアプリケーションの完全な共存を含む、オンプレミスおよびホスト型の移行/共存ソフトウェアのプロバイダーです。 オンプレミスの Exchange、IBM Domino、Novell GroupWise、Zimbra、その他の環境から、Office 365 および SharePoint Online に移行するためのすべての機能が用意されています。

  • MetalogixOffice 365 および SharePoint Online への移行ソリューションのプロバイダーです。

  • SkyKick オンプレミスの Exchange、Gmail、POP3、IMAP、Lotus Notes を Office 365 に移行するための、自動移行ソリューションのプロバイダーです。 エンドツーエンドの移行ツールにより、移行プロジェクトの販売、計画、移行、管理、およびオンサイトの各フェーズでパートナーを支援します。

  • TransVaultOffice 365 への移行ソリューションのプロバイダーです。

移行方法ごとのパフォーマンス

以下の表では、メールボックスとメールボックス データを Office 365 に移行する場合のさまざまな移行方法ごとに観測されたパフォーマンス結果を比較しています。これらの結果は、内部テスト、およびお客様が行った実際の Office 365 への移行に基づいたものです。

注: 移行の実施方法や時期には違いがあるため、実際の移行速度はこれより遅い場合もあれば、速い場合もあります。

移行方法

Office 365 ユーザー調整

Office 365 の移行サービス調整

Office 365 のリソース正常性ベースの調整

1 時間あたりのクライアントごと (該当する場合) の観測された平均スループット

IMAP 移行

×

はい

10 ~ 14 GB (同時実行数: 20)

一括移行

×

はい

10 ~ 14 GB (同時実行数: 20)

段階的な移行

×

はい

10 ~ 14 GB (同時実行数: 20)

ハイブリッド移行

×

はい

10 から 14 GB (同時移動数 20 でオンプレミスの Exchange 2013 または 2010 CAS (Microsoft Exchange Mailbox Replication サービス (MRSProxy サービス)) ごと)1

サード パーティ製 MAPI による移行

いいえ

4 ~ 12 GB (同時実行数: 20) 2

サード パーティ製 Exchange Web サービスによる移行

×

はい

5 ~ 10 GB (同時実行数: 20) 3

クライアント アップロード (Outlook .pst ファイルから)

いいえ

0.5 GB

11 つのメールボックスを移動する場合に観測されるスループットは、0.3 から 1.0 GB/時の範囲です。一時エラー発生時の停止時間を 2% 未満、ネットワーク待ち時間を 100 ミリ秒未満に保持できるネットワークでは、1000 MB/時を超えるメールボックスあたりのスループット速度を実現できます。さらに多くのメールボックスを同時に移行すると、より高いデータ移行速度を実現できます。オンプレミスの CAS (MRSProxy サービス) サーバーがハードウェアの容量限度に達している場合、ネットワーク帯域幅が不十分な場合、またはネットワークの遅延が大きすぎる場合には、1 つのメールボックスの移動のスループットが遅くなります。サーバーを追加するか、ネットワーク接続を一時的に向上させて、移行の速度を上げることを検討してください。

21 つの MAPI を移行する場合に観測されるスループットは、0.1 ~ 0.5 GB/時の範囲です。 より多くの移行を同時に実行すると、より高いデータ移行速度を実現できます。 オンプレミス サーバーまたはネットワークが容量限度に達しているときには、1 つの MAPI の移行のスループットは遅くなります。

31 つの Exchange Web サービスを移行する場合に観測されるスループットは 0.2 ~ 0.5 GB/時の範囲です。より多くの同時移行を使用すると、より高速なデータ移行速度を実現できます。たとえば、20 件の移行を同時に実行すると、全体のスループットは 4 ~ 10 GB/時の範囲になります。オンプレミス サーバーまたはネットワークが容量限度に達しているときには、1 つの Exchange Web サービスの移行のスループットは遅くなります。

移行のパフォーマンス要因

メールの移行には、移行のパフォーマンスに影響する可能性がある共通の要因がいくつかあります。

一般的な移行パフォーマンス要因

以下の表は、移行パフォーマンスに影響を与える一般的な要因の一覧を示しています。 詳細については、個別の移行方法に関するセクションで説明します。

要因

説明

データ ソース

移行するデータをホストするデバイスまたはサービス。 ハードウェア仕様、エンド ユーザー ワークロード、バックエンド保守作業に伴うさまざまな制限がデータ ソースに適用されます。

Gmail では一定時間に抽出可能なデータ量が制限されています。

データの種類および密度

お客様のビジネスはそれぞれユニークなため、メールボックス内のメール アイテムの種類および各種類の割合は大きく異なります。

それぞれに 10 MB の添付ファイルが付属する 400 アイテムが保存された 1 つの 4 GB メールボックスは、アイテム数が 100,000 未満の 1 つの 4 GB メールボックスよりも移行に時間がかかりません。

移行サーバー

多くの移行ソリューションでは、中継機能を担う移行サーバーまたはワークステーションを使用して移行を実行します。

お客様が、ハイブリッド展開用の MRSProxy サービスやクライアント PC の非ハイブリッド移行をホストするために、低パフォーマンスの仮想マシンを使用していることはよくあります。

移行エンジン

移行元サーバーからデータを取得する役割があるデータ移行エンジンは、必要に応じてデータを変換します。 続いて、ネットワーク経由でデータを転送して、Office 365 メールボックスにデータを挿入します。

MRSProxy サービスには、固有の機能および制限があります。

オンプレミス ネットワーク アプライアンス

エンドツーエンド (データ ソースから Exchange Online クライアント アクセス サーバーまで) のネットワーク パフォーマンスが移行のパフォーマンスに影響します。

オンプレミス組織でのファイアウォールの構成および仕様。

Office 365 サービス

Office 365 には、移行の負荷を管理するためのビルトイン サポートおよび機能が備わっています。

ユーザー調整ポリシーには既定の設定があり、全体的な最大データ転送レートを制限します。

ネットワークのパフォーマンス要因

このセクションでは、移行中のネットワーク パフォーマンスを向上させるためのベスト プラクティスについて説明します。 移行中のネットワーク パフォーマンスに対する影響のうち最も大きいものは、サード パーティのハードウェアおよびインターネット サービス プロバイダー (ISP) に関連するため、一般的な説明にとどめます。

Exchange Analyzer を使用して、Office 365 とのネットワーク接続についてより深く理解してください。サポート/回復アシスタントで Exchange Analyzer テストを実行するには、次の場所にアクセスします。高度な診断 > Exchange Online > Exchange Online のネットワーク接続の確認 > はい。サポート/回復アシスタントの詳細については、「Office 365 用サポート/回復アシスタントで Outlook と Office 365 の問題を解決する」を参照してください。

要因

説明

ベスト プラクティス

ネットワーク キャパシティ

メールボックスを Office 365 に移行するのにかかる時間は、ネットワークの利用可能キャパシティおよび最大キャパシティによって決まります。

  • ネットワークの利用可能キャパシティを特定して、最大アップロード キャパシティを判断します。

  • ISP に問い合わせて、割り当て済みの帯域幅を確認し、一定時間に転送可能な合計データ量などの制限の詳細について把握します。

  • ツールを使用して実際のネットワーク キャパシティを評価します。 オンプレミスのデータ ソースから Microsoft のデータセンター ゲートウェイ サーバーまでのエンドツーエンドのデータ フローを必ずテストしてください。

  • ネットワーク キャパシティに影響する可能性があるその他のネットワークに対する負荷 (バックアップ ユーティリティや定期保守など) を特定します。

ネットワークの安定性

ネットワークが高速であれば常に移行が速くなるとは限りません。 ネットワークが安定していない場合は、エラー修正が発生するためデータ転送の時間が長くなります。 移行の種類によっては、エラー修正が移行のパフォーマンスに大きく影響する場合があります。

多くの場合、ネットワークのハードウェアおよびドライバーに関する問題がネットワークの安定性に関する問題を引き起こします。 ハードウェア ベンダーと協力してネットワーク デバイスを理解し、ベンダーが提供する最新の推奨ドライバーおよびソフトウェア更新プログラムを適用してください。

ネットワークの遅延

侵入検出機能がネットワーク ファイアウォールで構成されていると、大幅なネットワークの遅延を引き起こすことが多く、移行のパフォーマンスに影響します。

Office 365 メールボックスへのデータの移行は、インターネット接続に依存します。 インターネットの遅延は、移行全体のパフォーマンスに影響します。

また、同じ会社内のユーザーが、地理的に離れた場所にあるデータセンターにクラウド メールボックスを所有している場合もあります。 お客様の ISP によって、移行のパフォーマンスが異なる可能性があります。

  • 使用する可能性があるすべての Microsoft データセンターとの間のネットワーク遅延を評価して結果が一定であることを確認します (これで、エンド ユーザーに対する安定したパフォーマンスを保証しやすくなります)。ISP と協力して、インターネット関連の問題に対処してください。

  • Microsoft データセンター サーバーの IP アドレスを許可一覧に追加するか、ネットワーク ファイアウォールからのすべての移行関連トラフィックをバイパスします。 Office 365 の IP 範囲の詳細については、「Office 365 の URL と IP アドレスの範囲」を参照してください。

環境内での移行について詳しく分析するには、移動分析に関するブログ投稿 (英語) を参照してください。 この投稿には、移動要求の分析に役立つスクリプトが含まれています。

Office 365 の調整

Office 365 では、セキュリティおよびサービスの利用可能時間を保証するのに役立つ、さまざまな調整メカニズムが使用されます。 次の 3 種類の調整が移行のパフォーマンスに影響する可能性があります。

  • ユーザー調整

  • 移行サービス調整

  • リソース正常性ベースの調整

注: Office 365 のこれら 3 種類の調整は、すべての移行方法に影響を与えるわけではありません。

Office 365 ユーザー調整

ユーザー調整は、ほとんどのサード パーティ製移行ツールおよびクライアントのアップロードによる移行方法に影響を与えます。 これらの移行方法では、RPC over HTTP プロトコルなどのクライアント アクセス プロトコルを使用して、メールボックス データを Office 365 メールボックスに移行します。 これらのツールは、IBM Lotus Domino や Novell GroupWise などのプラットフォームからデータを移行する場合に使用されます。

ユーザー調整は、Office 365 における最も制限の厳しい調整方法です。 ユーザー調整は個別のエンド ユーザーに対して動作するようにセットアップされるため、アプリケーション レベルで使用すると調整ポリシーを超過しやすく、データ移行の速度が遅くなります。

Office 365 の移行サービス調整

移行サービス調整は、すべての Office 365 移行ツールに影響を与えます。 移行サービス調整では、Office 365 移行ソリューションにおける移行の同時実行およびサービス リソースの割り当てが管理されます。

移行サービス調整は、次の移行方法を使用して実行される移行に影響を与えます。

  • IMAP 移行

  • Exchange の一括移行

  • 段階的な Exchange の移行

  • ハイブリッド移行 (ハイブリッド環境における MRSProxy サービス ベースの移動)

移行サービス調整の例として、単純な Exchange の移行および IMAP 移行中に同時に移行されるメールボックス数の制御があります。 既定値は 10 です。 つまり、どの時点においてもすべての移行バッチから移行されるメールボックスの数は最大で 10 です。 移行バッチで同時に移行するメールボックスの数は、Exchange コントロール パネルまたは Windows PowerShell で増やすことができます。 この設定を最適化する方法の詳細については、「Office 365 での移行バッチの管理」を参照してください。

Office 365 のリソース正常性ベースの調整

すべての移行方法は利用可能時間の調整により管理されます。 ただし、前のセクションで説明した他の種類の調整と比べれば、この Office 365 サービスのための調整が Office 365 の移行に与える影響は限定的です。

リソース正常性ベースの調整は、最も消極的な調整方法です。エンド ユーザーおよび重大なサービス操作に影響を与える可能性があるサービス利用可能時間の問題を防ぐために実行されます。

エンド ユーザーのパフォーマンスが影響を受ける可能性があるレベルまでサービスのパフォーマンスが低下した場合は、パフォーマンスが回復してサービスが調整のしきい値未満のレベルに戻るまでの間、ハイブリッド移行がキューに登録されます。

Exchange 移行統計レポートからの例を次に示します。サービス調整しきい値を超えたときに記録されたエントリが示されています。

  • 2012/01/25 12:56:01 AM [BL2PRD0410CA012] コピーの進行状況: 723/1456 メッセージ、225.8 MB (236,732,045 バイト)/416.5 MB (436,712,733 バイト)。

    2012/01/25 12:57:53 AM [BL2PRD0410CA012] データベース 'NAMPRD04DG031-db081' (エージェント MailboxDatabaseReplication) の DataMoveReplicationConstraint が満たされないため、メールボックス '/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' の移動が停止しています。 失敗の理由: データベース edbf0766-1f2a-4552-9115-bb3a53a8380b は、制約 SecondDatacenter を満たしていません。 利用可能な正常なデータベースのコピーがありません。 2012/01/25 1:27:53 AM まで待機します。

    2012/01/25 12:58:24 AM [BL2PRD0410CA012] 要求は再開し、続行します。

    6/30/2017 00:03:58 [CY4PR19MB0056] サーバーが正常な状態にないかまたは要求の調整状態 'StalledDueToTarget_DiskLatency' の予算制限により、大幅な遅延をきたしたため、ジョブを放棄します。

ソリューションとプラクティス   

同様の状況が発生した場合は、Office 365 サービスが回復するまで待機します。 詳細については、Office 365 ポータルのサービス正常性に関するセクションを参照してください。

非ハイブリッド展開での移行のパフォーマンスの要因およびベスト プラクティス

このセクションでは、IMAP による移行、一括移行、段階的な移行の各方法に影響する要因について説明します。 また、移行のパフォーマンスを向上させるためのベスト プラクティスも示します。

要因 1: データ ソース

次の表では、現在のメール組織の移行元サーバーによる移行への影響、および移行への影響を軽減するためのベスト プラクティスについて説明します。

チェックリスト

説明

ベスト プラクティス

システムのパフォーマンス

データ抽出は、リソースを集中的に使用するタスクです。 最適な移行のパフォーマンスを実現するには、移行元システムに十分なリソース (CPU 時間やメモリなど) が必要です。 多くの場合、移行時の移行元システムは、通常のエンド ユーザーの負荷で限界近くまでキャパシティを利用しています。 システム リソースが不足している場合には、移行によって追加の負荷がかかると、エンド ユーザーに影響を与える可能性があります。

パイロット移行テスト時に、システムのパフォーマンスを監視します。 システムがビジー状態の場合は、移行の速度が遅くなったり、サービスの利用に問題が発生したりする可能性があるため、特定のシステムに集中した移行をスケジュールしないことをお勧めします。 可能であれば、ハードウェア リソースを追加すると移行元システムのパフォーマンスを高め、タスクやユーザーを移行に関係のない他のサーバーに移動してシステムの負荷を軽減します。

詳細については、次のトピックを参照してください。

複数のメールボックス サーバーが存在するオンプレミス Exchange 組織から移行する場合は、複数のメールボックス サーバーに均等に分散された移行ユーザーの一覧を作成することをお勧めします。 個別のサーバーのパフォーマンスに基づいて、この一覧をさらに微調整し、スループットを最大化できます。

たとえば、サーバー A のリソースの利用可能時間がサーバー B よりも 50% 長い場合は、同じ移行バッチにおいてサーバー A からのユーザー数を 50% 多くするのが適切です。 他の移行元システムに対しても、同様のプラクティスを適用できます。 勤務時間後、週末、祝日など、サーバー リソースの利用可能時間が最大になるときに移行を実行します。

バックエンド タスク

移行時に実行されている他のバックエンド タスク。 移行は勤務時間後に実行するのがベスト プラクティスなので、オンプレミス サーバーで実行中の保守タスク (データのバックアップなど) と競合することがよくあります。

移行中に実行される可能性がある他のシステム タスクを確認します。 データの移行は、リソースを大量に消費する他のタスクが実行されていないときに実施することをお勧めします。

注意   オンプレミス Exchange を使用しているお客様にとって一般的なバックエンド タスクには、バックアップ ソリューションや「Exchange ストアの保守」があります。

調整ポリシー

一定時間にシステムから抽出可能なデータ量および抽出速度に対して特定の制限を設定する調整ポリシーを使用して、メール システムを保護するのが一般的です。

メール システムで展開されている調整ポリシーを確認します。 たとえば、Google Mail では、一定時間に抽出できるデータの量が制限されています。

Exchange のバージョンによっては、(IMAP 移行で使用される) オンプレミス メール サーバーへの IMAP アクセスや、(Exchange の一括移行や段階的な Exchange の移行で使用される) RPC over HTTP プロトコル アクセスを制限するポリシーが存在します。

Exchange 2013 組織の調整設定を確認するには、Get-ThrottlingPolicy コマンドレットを実行します。 詳細については、「Exchange ワークロード管理」を参照してください。

IMAP 調整の詳細については、「IMAP メールボックスを Office 365 に移行する」を参照してください。

RPC over HTTP プロトコルの調整の詳細については、以下の記事を参照してください。

要因 2: 移行サーバー

IMAP 移行、一括移行、段階的な移行は、クラウドから開始されるデータプル型の移行方法であるため、専用の移行サーバーは必要ありません。ただし、インターネットに接続するプロトコル ホスト (IMAP や RPC over HTTP プロトコル) は、メールボックスおよびメールボックス データを Office 365 に移行するための移行サーバーとして機能します。したがって、前のセクションで現在のメール組織のデータ移行元サーバーについて説明した移行のパフォーマンス要因とベスト プラクティスは、インターネット エッジ サーバーにも適用されます。Exchange 2007、Exchange 2010、および Exchange 2013 組織では、クライアント アクセス サーバーが移行サーバーとして機能します。

詳細については、次のトピックを参照してください。

要因 3: 移行エンジン

Exchange の IMAP 移行、一括移行、および段階的な移行を実行するには、Exchange 管理センター の移行ダッシュボードを使用します。このツールは、Office 365 移行サービス調整の対象となります。

ソリューションとプラクティス   

お客様は、Windows PowerShell を使用して移行の同時実行数 (同時に移行するメールボックスの数など) を指定できるようになりました。既定値は 20 メールボックスです。移行バッチを作成した後は、次の Windows PowerShell コマンドレットを使用して、この数を最大で 100 まで増やすことができます。

Set-MigrationEndPoint <Identity> –MaxConcurrentMigrations <value between 1 and 100>

詳細については、「Office 365 での移行バッチの管理」を参照してください。

注: すべての接続を処理するのに十分なリソースがデータ ソースにない場合は、同時実行数を大きくしないでください。最初は 10 程度の小さい数から始めます。エンド ユーザーのアクセスに問題が発生しないようにデータ ソースのパフォーマンスを監視しながらこの数を徐々に増やします。

要因 4: ネットワーク

検証テスト   

移行方法に応じて、次の検証テストを実行できます。

  • IMAP 移行   移行元メールボックスに事前にサンプル データを設定します。 次に、インターネット (オンプレミス ネットワークの外部) から Microsoft Outlook などの標準的な IMAP メール クライアントを使用して移行元メールボックスに接続し、移行元メールボックスからすべてのデータをダウンロードするのにかかる時間を確認して、ネットワークのパフォーマンスを測定します。 他に制約がない場合、このスループットは、Office 365 の IMAP 移行ツールを使用した場合のスループットと同様の数値になるはずです。

  • Exchange の一括移行および段階的な移行   移行元メールボックスに事前にサンプル データを設定します。 次に、インターネット (オンプレミス ネットワークの外部) から RPC over HTTP プロトコルを使用して Outlook で移行元メールボックスに接続します。 キャッシュ モードを使用して接続していることをご確認ください。 移行元メールボックスからすべてのデータを同期するのにかかる時間を確認して、ネットワークのパフォーマンスを測定します。 他に制約がない場合、このスループットは、Office 365 の簡易 Exchange 移行ツールを使用した場合のスループットと同様の数値になるはずです。

注: Exchange の実際の IMAP 移行、一括移行、または段階的な移行では若干のオーバーヘッドが発生しますが、実際のスループットはこれらの検証テストの結果に近似した数値になるはずです。

要因 5: Office 365 サービス

Office 365 のリソース正常性ベースの調整は、ネイティブ Office 365 の簡易移行ツールを使用した移行に影響します。 「Office 365 のリソース正常性ベースの調整」のセクションを参照してください。

Office 365 サービスでの移動要求

移動要求の状態情報の取得の概要については、「移動要求のプロパティの表示」を参照してください。

オンプレミス Exchange 2010 内とは異なり、Office 365 サービスでは、移行キュー、および移行に割り当てられたサービス リソースがテナント間で共有されます。 この共有は、移動プロセスの各段階での移動要求の処理方法に影響します。

Office 365 には、2 種類の移動要求があります。

  • オンボード移動要求   お客様の新規の移行は、オンボード移動要求とみなされます。 これらの要求には通常の優先度が設定されます。

  • データセンター内部移動要求   これらはデータセンターの運用チームによって開始されたメールボックス移動要求です。 これらの移動要求には遅延が発生してもエンドユーザー エクスペリエンスには影響しないため、低い優先度が設定されます。

"キューに登録済み" および "処理中" の状態にある移動要求で考えられる影響および遅延

  • キューに登録済みの移動要求   この状態は、移動がキューに登録されており、Exchange Mailbox Replication サービスによって処理されるのを待機していることを示します。 Exchange 2003 の移動要求の場合、この段階ではユーザーは引き続きメールボックスにアクセスできます。

    次の 2 つの要因によって、Mailbox Replication サービスによって処理される要求が決定されます。

    • 優先度   キューに登録済みの移動要求では、高い優先度の移動要求が低い優先度の移動要求よりも前に処理されます。 これで、データセンター内部移動要求の前に、必ず顧客移行移動要求が処理されるようになります。

    • キュー内の位置   移動要求の優先度が同じ場合は、早くキューに登録された要求が優先的に Mailbox Replication サービスによって処理されます。 同時に複数のお客様がメールボックスの移行を実行する可能性があるため、新規の移動要求が処理される前にキューにとどまる場合があります。

      多くの場合、メールボックス要求が処理前にキュー内で待機する時間は、移行計画時に考慮されません。 このことは、計画したすべての移行が完了するのに十分な時間が割り当てられない原因となります。

  • 処理中の移動要求   この状態は、移動がまだ実行中であることを示します。 オンライン メールボックス移動である場合、ユーザーはメールボックスにまだアクセスできます。 オフラインでメールボックスを移動する場合、ユーザーのメールボックスは使用できません。

    メールボックス移動要求の状態が "処理中" になると、優先度は関係なくなります。新しい移動要求は、高い優先度が設定されている場合でも、既存の処理中の移動要求が完了するまでは処理されません。

ベスト プラクティス

計画   前述のように、Exchange 2003 ユーザーはハイブリッド移行中にメールボックスにアクセスできなくなるため、Exchange 2003 を使用しているお客様は、通常、移行をスケジュールする時刻および移行に必要な時間に注意を払う必要があります。

一定時間に移行するメールボックス数を計画する場合は、次の点を考慮します。

  • 移動要求がキュー内で待機する時間を含めます。 次の式を使用してこの計算を行います。

    (移行するメールボックスの合計数) = ((合計時間) - (平均待ち時間)) * (移行スループット)

    ここで、移行スループットは 1 時間に移行できるメールボックスの合計数です。

    たとえば、メールボックスを移行するために 6 時間の時間枠があるとします。 平均待ち時間が 1 時間で、移行スループットが 1 時間あたり 100 メールボックスの場合、6 時間で 500 のメールボックスを移行できます。式は、500 = (6 - 1) * 100 となります。

  • キュー内にとどまる時間を抑えるために、当初計画した時刻よりも早めに移行を開始します。 メールボックスがキューに登録されている場合でも、Exchange 2003 ユーザーは引き続きメールボックスにアクセスできます。

待ち時間の特定    Microsoft はお客様の移行スケジュールを管理していないため、待ち時間は常に変化します。

発生する可能性がある待ち時間を特定するために、実際の移行を開始する数時間前にテストの移動をスケジュールできます。 その後、実際に要求がキュー内にとどまった時間に基づいて、移行を開始すべき時刻および一定時間内に移動できるメールボックス数をより正確に推定できます。

たとえば、計画した移行を開始する 4 時間前にテストの移行が完了したとします。 テストの移行の待ち時間は約 1 時間だったことを確認します。 この場合、すべての移行が時間内に終了するように、最初に計画した時刻よりも 1 時間早く移行を開始することを検討する必要があります。

Office 365 の移行に対応するサード パーティ製ツール

サード パーティ製ツールは、そのほとんどが、Google Mail、IBM Lotus Domino、Novell GroupWise などの Exchange が関与しない移行シナリオで使用されます。 このセクションでは、実際の製品や移行ツールではなく、サード パーティ製の移行ツールで使用される移行プロトコルに重点を置いて説明します。 以下の表に、Office 365 の移行シナリオでサード パーティ製ツールに適用される要因の一覧を示します。

要因 1: データ ソース

チェックリスト

説明

ベスト プラクティス

システムのパフォーマンス

データ抽出は、リソースを集中的に使用するタスクです。 最適な移行のパフォーマンスを実現するには、移行元システムに十分なリソース (CPU 時間やメモリなど) が必要です。 多くの場合、移行時の移行元システムは、通常のエンド ユーザーの負荷で限界近くまでキャパシティを利用しています。 システム リソースが不足している場合には、移行によって追加の負荷がかかると、エンド ユーザーに影響を与える可能性があります。

パイロット移行テスト時に、システムのパフォーマンスを監視します。 システムがビジー状態の場合は、移行の速度が遅くなったり、サービスの利用に問題が発生したりする可能性があるため、特定のシステムに集中した移行をスケジュールしないことをお勧めします。 可能であれば、ハードウェア リソースを追加し、システムの負荷を軽減して、移行元システムのパフォーマンスを高めます。 タスクやユーザーを移行に関係のない他のサーバーに移動すると、システムの負荷を軽減できます。

詳細については、次のトピックを参照してください。

複数のメールボックス サーバーが存在するオンプレミス Exchange 組織から移行する場合は、複数のメールボックス サーバーに均等に分散された移行ユーザーの一覧を作成することをお勧めします。 個別のサーバーのパフォーマンスに基づいて、この一覧をさらに微調整し、スループットを最大化できます。

たとえば、サーバー A のリソースの利用可能時間がサーバー B よりも 50% 長い場合は、同じ移行バッチにおいてサーバー A からのユーザー数を 50% 多くするのが適切です。 他の移行元システムに対しても、同様のプラクティスを適用できます。

勤務時間後、週末、祝日など、システム リソースの利用可能時間が最大になるときに移行を実行します。

バックエンド タスク

通常は、その他のバックエンド タスクが移行時に実行されます。 移行は勤務時間後に実行するのがベスト プラクティスなので、オンプレミス サーバーで実行中の他の保守タスク (データのバックアップなど) と競合することがよくあります。

移行中に実行される他のシステム タスクを確認します。 リソースを大量に消費する他のタスクが実行されない、データ移行専用のクリーンな時間枠を設けることをお勧めします。

オンプレミスで Exchange を使用しているお客様にとって一般的なタスクは、バックアップ ソリューションです。 詳細については、「Exchange ストアの保守」を参照してください。

調整ポリシー

一定時間内に特定の移行方法を使用してシステムから抽出できるデータ量および抽出速度に対して特定の制限を設定する調整ポリシーを使用して、メール システムを保護するのが一般的です。

メール システムで展開されている調整ポリシーを確認します。 たとえば、Google Mail では、一定時間に抽出できるデータの量が制限されています。

Exchange のバージョンによっては、(IMAP 移行で使用される) オンプレミス メール サーバーへの IMAP アクセスや、(Exchange の一括移行や段階的な Exchange の移行で使用される) RPC over HTTP プロトコル アクセスを制限するポリシーが存在します。

IMAP 調整の詳細については、「IMAP 移行を最適化するためのヒント」を参照してください。

RPC over HTTP プロトコルの調整の詳細については、以下の記事を参照してください。

Exchange Web サービス調整の構成方法の詳細については、「Exchange 2010: クライアント調整ポリシーについて」を参照してください。

要因 2: 移行サーバー

Office 365 移行用のほとんどのサード パーティ製ツールは、クライアントから開始され、Office 365 にデータをプッシュします。 これらのツールでは、一般的に移行サーバーが必要です。 これらの移行サーバーには、システムのパフォーマンス、バックエンド タスク、移行元サーバーの調整ポリシーなどの要因があてはまります。

注: 一部のサード パーティ製移行ソリューションは、クラウドベースのサービスとしてインターネット上にホストされ、オンプレミス移行サーバーを必要としません。

ソリューションとプラクティス   

移行サーバーを使用する場合の移行のパフォーマンスを向上させるには、「要因 1: データ ソース」のセクションで説明したベスト プラクティスを適用します。

要因 3: 移行エンジン

サード パーティ製移行ツールで使用される最も一般的なプロトコルは、Exchange Web サービスおよび RPC over HTTP プロトコルです。

Exchange Web サービス   

Exchange Web サービスは、大きなデータ バッチをサポートし、優れたサービス指向の調整を行うため、Office 365 への移行ではこのプロトコルの使用をお勧めします。 Office 365 において、Exchange Web サービスを使用する移行 (偽装モードで使用された場合) では、ユーザーに割り当てられた量の Office 365Exchange Web サービスのリソースは使用されず、割り当てられたリソースのコピーが以下のように使用されます。

  • 同じ管理者アカウントによる Exchange Web サービスの偽装呼び出しはすべて、その管理者アカウントに対する割り当てとは別に計算されます。

  • 偽装セッションごとに、ユーザーの実際の割り当てのシャドウ コピーが作成されます。 この特定のセッションのすべての移行がこのシャドウ コピーを消費します。

  • 偽装に基づく調整はユーザー移行セッションごとに別々に行われます。

ベスト プラクティス   

  • EWA 偽装を使用したサード パーティ製移行ツールを使用するお客様の移行のパフォーマンスは、他のテナントによる Exchange Web サービス ベースの移行およびサービス リソースの使用と競合します。 そのため、移行のパフォーマンスは場合によって異なります。

  • お客様は、可能な限り Exchange Web サービス偽装を使用したサード パーティ製移行ツールを使用する必要があります。これらのツールは、通常、RPC over HTTP プロトコルなどのクライアント プロトコルを使用した場合に比べて、より高速で効率的なためです。

RPC over HTTP プロトコル   

従来の多くの移行ソリューションでは、RPC over HTTP プロトコルが使用されています。 この方法は、完全に Outlook などのクライアント アクセス モデルに基づいています。また、Office 365 のサービスはアプリケーションではなくユーザーによる使用を前提としてアクセスを調整するため、スケーラビリティおよびパフォーマンスが限定されます。

ベスト プラクティス   

  • RPC over HTTP プロトコルを使用する移行ツールでは、移行サーバーを追加し、複数の Office 365 管理ユーザー アカウントを使用して、移行のスループットを上げるのが一般的です。 このプラクティスでは、それぞれの管理ユーザーが Office 365 ユーザー調整の対象となるため、並行してデータを挿入でき、より高いデータ スループットを実現できます。 多くの企業のお客様は 20 ~ 30 GB/時の移行スループットを実現するために 40 台以上の移行サーバーをセットアップする必要があったという報告があります。

  • 移行ツールの開発フェーズでは、メッセージを移行するのに必要な RPC 操作の数を考慮することが重要です。 このことを説明するため、お客様がメールボックスを Office 365 に移行するために使用した 2 つの (サード パーティ企業によって開発された) サード パーティ製移行ソリューションについて、Office 365 サービスが記録したログを収集しました。 サード パーティ企業によって開発された 2 つの移行ソリューションを比較しました。 また、各移行ソリューションにおける 2 つのメールボックスの移行を比較し、Outlook の .pst ファイルのアップロードとも比較しました。 結果は次のとおりです。

    方法

    メールボックスのサイズ

    アイテム数

    移行時間

    合計 RPC トランザクション数

    平均クライアント待ち時間 (ミリ秒)

    AvgCasRPCProcessingTime (ミリ秒)

    ソリューション A (メールボックス 1)

    376.9 MB

    4,115

    4:24:33

    132,040

    48.4395

    18.0807

    ソリューション A (メールボックス 2)

    249.3 MB

    12,779

    10:50:50

    423,188

    44.1678

    4.8444

    ソリューション B (メールボックス 1)

    618.1 MB

    4,322

    1:54:58

    12,196

    37.2931

    8.3441

    ソリューション B (メールボックス 2)

    56.7 MB

    2,748

    0:47:08

    5,806

    42.1930

    7.4439

    Outlook

    201.9 MB

    3,297

    0:29:47

    15,775

    36.9987

    5.6447

    クライアントおよびサービスの処理時間は近い数値ですが、ソリューション A ではデータの移行により多くの RPC 操作を必要としています。 それぞれの操作でクライアント待機時間およびサーバー処理時間がかかるため、ソリューション A はソリューション B や Outlook と比較して、同じデータ量の移行にもより長い時間がかかります。

要因 4: ネットワーク

ベスト プラクティス   

RPC over HTTP プロトコルを使用するサード パーティ製移行ソリューションでは、次の方法で移行のパフォーマンスを推測できます。

  1. 移行サーバーから RPC over HTTP プロトコルを使用して Outlook で Office 365 メールボックスに接続します。 接続にキャッシュ モードを使用していないことをご確認ください。

  2. サンプル データを含む大きな .pst ファイルを Office 365 メールボックスにインポートします。

  3. この .pst ファイルをアップロードするのにかかる時間を計って、移行のパフォーマンスを測定します。 他に制約がない場合、移行のスループットは、RPC over HTTP プロトコルを使用したサード パーティ製移行ツールを使用した場合のスループットと似た数値になるはずです。 実際の移行時にはオーバーヘッドが発生するため、スループットは若干変動する可能性があります。

要因 5: Office 365 サービス

Office 365 のリソース正常性ベースの調整は、サード パーティ製移行ツールを使用した移行に影響します。 詳細については、上記の「Office 365 のリソース正常性ベースの調整」を参照してください。

スキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×