Exchange Server 2016 のアーキテクチャ

対象: 新Office365 Office 365 Enterprise, Office 365 Business, Office 365 Education

(この記事は 2015 年 5 月 5 日に Office Blogs に投稿された記事 Exchange Server 2016 Architectureの翻訳です。最新情報については、翻訳元の記事をご参照ください。)

Exchange Server 2016 は、Exchange Server 2013 で導入されたアーキテクチャ (英語)をベースに構築されています。2013 に引き続き、あらゆる展開規模のニーズに対応できるようにアーキテクチャを改善することを目指しています。

ビルディング ブロック アーキテクチャ

Exchange Server 2016 では、単一のビルディング ブロックを使用して、クライアント アクセス サービスと、あらゆるエンタープライズ メッセージング環境に必要な高可用性アーキテクチャを提供します。

図 1: ビルディング ブロック アーキテクチャ

私たちマイクロソフトは、製品機能を改善し、アーキテクチャとその展開を単純化するべく、取り組みを続けています。その中で、クライアント アクセス サーバー (CAS) のロールを除外し、メールボックスのロールにクライアント アクセス サービスを追加しました。CAS ロールがなくなっても、機能、バージョン管理、ユーザー パーティション、地理的アフィニティの面で、システムは疎結合を維持しています。

新しいメールボックス サーバーのロールには、次のサービスが含まれます。

1. プロトコル要求を正しい宛先エンドポイントにルーティングするロジックの提供
2. データの処理、レンダリング、保存を行うすべてのコンポーネントとプロトコルのホスティング

クライアントは、メールボックス サーバーのバックエンド エンドポイントに直接は接続しません。クライアント アクセス サービスに接続し、ユーザーのメールボックスを含むアクティブなデータベースをホストするメールボックス サーバーに (ローカルまたはリモートのプロキシ経由で) ルーティングされます。

メールボックス サーバーをデータベース可用性グループ (DAG) に追加すると、高可用性ユニットが形成されます。このユニットは 1 つ以上のデータセンターに展開可能です。Exchange Server 2016 の DAG には、次のような機能拡張が実施されています。

1. DAG の作成時に DatabaseAvailabilityGroupIpAddresses が不要になりました。既定の設定では、管理アクセス ポイントなしでフェールオーバー クラスターが作成されます。これは推奨されるベスト プラクティスです。
2. 再生ラグ マネージャーは既定で有効に設定されています。
3. ディスク待ち時間によって、時間差データベース コピーの再生に遅延が発生することがあります。アクティブ ユーザーはこの影響を受けません。
4. Exchange Server 2013 と比べて、データベースのフェールオーバー回数が 33% 少なくなっています。

CAS のロールを排除しても、サーバー間の通信に影響はありません。サーバー間の通信は引き続きプロトコル レイヤーで行われるため、すべてのサーバーを効果的に個別管理することができます。メールボックス接続では、使用するプロトコルはアクティブ データベース コピー固有のプロトコル インスタンスによって提供されます。

図 2: Exchange Server 2016 におけるサーバー間の通信

今回のアーキテクチャの変更は、ロード バランサーの設定には影響を及ぼしません。プロトコルという視点から見ると、次のような処理が実行されます。

1. クライアントが、負荷分散対象の仮想 IP アドレスに対して名前空間の名前解決を実行します。
2. ロード バランサーが、負荷分散対象のプールに存在するメールボックス サーバーの 1 つにセッションを割り当てます。
3. メールボックス サーバーが Active Directory にアクセスしてこの要求の認証およびサービスの検出を実行します。これにより、次の情報が取得されます。
   1. メールボックスのバージョン (今回の場合は Exchange Server 2016 のメールボックスを想定します)
   2. メールボックスの位置情報 (データベースの情報や ExternalURL の値など)
4. メールボックス サーバーが、要求を「プロキシ転送」するか、または (同一フォレスト内の) インフラストラクチャの他のメールボックス サーバーに「リダイレクト」するかを決定します。
5. メールボックス サーバーがアクティブ マネージャーのインスタンスにクエリを発行し、該当するデータベースのどのメールボックス サーバーでアクティブ コピーをホストするかを決定します。
6. メールボックス サーバーが、アクティブ コピーをホストしているメールボックス サーバーに要求をプロキシ転送します。

手順 6 で使用されるプロトコルは、クライアント アクセス サービスへの接続で使用されるプロトコルに依存します。クライアント要求が HTTP を使用する場合は、サーバー間でも HTTP プロトコルが使用されます (ただし、自己署名証明書を使用した SSL でセキュリティが確保されます)。クライアントが IMAP または POP プロトコルを使用する場合は、サーバー間でも IMAP または POP が使用されます。

ただし、テレフォニーの要求の場合は特殊で、メールボックス サーバーは、手順 6 で要求をプロキシ転送するのではなく、ユーザーのデータベースのアクティブ コピーをホストしているメールボックス サーバーに要求をリダイレクトします。これは、テレフォニー デバイスではリダイレクトがサポートされていて、メールボックス サーバーのユニファイド メッセージング サービスとの SIP セッションおよび RTP セッションを直接確立する必要があるためです。

図 3: クライアント プロトコル接続

Exchange Server 2016 には (RTM 版でも)、エッジ トランスポート サーバー ロールが提供されます。Exchange Server 2013 のエッジ トランスポート サーバー ロールのすべての機能は、Exchange Server 2016 でも利用できます。

クライアント アクセス サーバーのロールを廃止した理由

Exchange Server 2016 では、過去数回のリリースにわたって改良されてきたビルディング ブロック アーキテクチャをさらに進化させました。このアーキテクチャにおいては、Exchange 環境内のすべてのサーバー (エッジ トランスポート以外) のハードウェアや設定、その他の条件が、まったく同じになります。こうして統一されることにより、ハードウェアの注文をはじめ、パフォーマンス管理やサーバー管理が容易になります。

Exchange Server 2010、Exchange Server 2013と同じく、ロールのコロケーションをベスト プラクティスとしてお勧めします。コスト面から、CPU およびディスクに対してバランスの取れたアーキテクチャにすることが全体的な目標です。別々のサーバー ロールを使用すると、実際に使用するよりも多くの CPU、ディスク、メモリ リソースを購入することになるため、長い目で見てコストが高くなります。たとえば、クライアント アクセス サーバー ロールだけをホストするサーバーがあるとします。多くのサーバーでは、所定の数のディスクを非常に低コストで追加できるようになっています。このディスク数と実際に展開して使用するディスク数が一致していれば、基本的に追加コストはかかりません。しかし、展開したサーバー ロールが実際に使用するディスク数が所定の数を下回る場合は、ほとんど使用しないか、まったく使用しないディスク コントローラーのために出費することになります。

このアーキテクチャは、環境内の物理 Exchange サーバーの台数を減らせるように設計されています。物理サーバーの台数が減ると、以下に挙げるようなさまざまな点からコストを削減できます。

• 通常、運用コストのほうが設備投資よりも高くなります。1 台のサーバーが稼働終了するまでにかかる管理コストは、そのサーバーを購入した際の費用を上回ります。
• Exchange サーバー ライセンスの購入数を減らせます。このアーキテクチャで必要となるのは、Exchange サーバー 1 台分とオペレーティング システム 1 つ分のライセンスだけです。複数のロールを使用する場合は、複数の Exchange サーバー ライセンスと複数のオペレーティング システム ライセンスが必要になります。
• 展開するサーバーの数が減ると、他のインフラストラクチャにも徐々に波及効果が現れます。たとえば、物理サーバーの展開数が減ることで、Exchange インフラストラクチャのために必要なラックやフロアのスペースが縮小し、電力コストと冷却コストを削減できます。

このアーキテクチャでは、すべてのメールボックス サーバーがクライアント アクセスを処理するため、シングルロール サーバーを展開するよりも多くの数のサーバーに負荷を分散できます。

• より多くの物理マシンに負荷を分散することにより、スケーラビリティが向上します。障害が発生したときでも残りのサーバーの負荷は少ししか増えないため、実行中のその他の処理には影響が及びません。
• このソリューションは耐障害性が高く、クライアント アクセス ロール (またはサービス) の障害が多数発生してもサービスを提供し続けることができます。

アーキテクチャの主な機能強化

Exchange Server 2016 のアーキテクチャには、サーバー ロールの統合以外にも、検索やドキュメント共同作業など、多くの機能強化が実施されています。

検索の機能強化

オンプレミス環境の課題の 1 つに、以前のリリースのデータベース コピーによって複製されたデータの量があります。Exchange Server 2016 では、アクティブ コピーとパッシブ コピー間の帯域幅の要件が 40% も削減されています。これは、ローカルの検索インスタンスが、ローカルのデータベース コピーからデータを読み取れるようになったことで実現されました。この変更の結果、パッシブ検索インスタンスは、インデックスを更新するためにアクティブ検索インスタンスと連携する必要はなくなりました。

さらに、検索結果が返されるまでの時間も短くなりました。特に OWA のようなオンライン モードのクライアントで応答時間が大幅に短縮されています。時間短縮が達成されたのは、ユーザーが検索キーワードを入力する前に、複数の非同期ディスク読み取りが実行されるようになったためです。複数の非同期ディスク読み取りによってキャッシュに関連情報が書き込まれると、オンライン モード クライアントでは 1 秒以下で検索結果が返されます。

ドキュメント共同作業

Exchange の以前のリリースでは、OWA に Office ドキュメントと PDF ドキュメントのプレビュー機能が含まれていたため、再現度の高いクライアントは必要ありませんでした。SharePoint でも、Office Web Apps サーバーを使用して、同様のプレビュー機能が実装されています。Office 365 でも Office Web Apps サーバーを活用してこの機能を実現しました。これにより、Office スイート全体で一貫したドキュメントのプレビュー機能と編集機能を利用することができます。

Exchange Server 2016 では、Office Web Apps サーバーを使用して、OWA 向けにリッチ ドキュメントのプレビュー機能および編集機能を提供しています。これは Office Server スイート全体で同一のエクスペリエンスを実現するために必要な変更ですが、Office Web Apps サーバーを使用しない環境では複雑性が増すというトレードオフが生じます。

次世代の Office Web Apps サーバーは Exchange とのコロケーションをサポートしません。このため、別のサーバー ファーム インフラストラクチャを展開する必要があります。このインフラストラクチャには一意の名前空間が必要です。また、ロード バランサー レベルでセッション アフィニティを保持する必要があります。

Exchange は制限なしの名前空間モデルをサポートしていますが、Office Web Apps サーバーには、各サイト復元データセンターのペアごとに制限付き名前空間が必要です。ただし、Exchange の制限付き名前空間モデルの場合とは異なり、Office Web Apps サーバーはデータセンターをアクティブ化しているときには名前空間の変更を要求しません。

図 4: Office Web Apps サーバー接続

拡張性

Office 365 に用意されている Mail (英語)、Calendar (英語)、Contacts (英語)の REST API は、Exchange Server 2016 でも利用できます。これらの REST API では、使い慣れた構文が使用されているので、Exchange でのプログラミングが容易になります。この構文はオープン性 (JSON、OAUTH、ODATA をサポートするオープンな規格) と柔軟性 (ユーザー データへのアクセスを細かく厳密に制御) を意識して設計されています。開発者は API を使用して、Web、PC、モバイル デバイスなど、あらゆるプラットフォームから接続できます。.NET、iOS、Android、NodeJS、Ruby、Python、Cordova、および CORS 向けの SDK が用意されており、1 ページの JavaScript Web アプリで使用することが可能です。

では Exchange Web サービス (EWS) はどうなるのでしょうか。EWS を使用するすべての既存アプリケーションは Exchange Server 2016 でも使用できますが、マイクロソフトでは現在 REST API と Office 拡張性モデル対応アプリという新たなプラットフォームに力を注いでいます。EWS への投資を大幅に抑えることで、単一の最新型 API への投資にリソースを集中させられるようになります。現在パートナーが EWS を活用しているほぼすべてのシナリオは、今後この API で実現されます。

Outlook 接続

Exchange Server 2013 Service Pack 1 で導入された MAPI/HTTP は、Outlook の接続の新しい標準です。Exchange Server 2016 でも、既定で MAPI/HTTP が有効になっています。Exchange Server 2016 で���さらに、この接続モデルのユーザーごとの制御機能と、プロトコル (と Outlook Anywhere) を外部クライアントにアドバタイズするのかどうかの制御機能が導入されます。

Exchange Server 2013 との共存

Exchange Server 2013 の CAS ロールは、コンテンツの処理やレンダリングを実行しない単なるインテリジェント プロキシです。このアーキテクチャの基本理念により、後続のバージョンと共存可能であるというメリットがもたらされました。Exchange Server 2016 を導入するときも、名前空間を変更する必要がありません。Exchange Server 2013 クライアント アクセス インフラストラクチャは、アクティブ データベース コピーをホストしている Exchange Server 2016 サーバーに、メールボックス要求をプロキシ転送することができます。つまり、名前空間を新しいバージョンに移行するタイミングをユーザーが決定できるのです。それだけではありません。ロード バランサー プールに Exchange Server 2013 と Exchange Server 2016 を共存させることができます。このため、1 対 1 のスワップが可能です。Exchange Server 2016 サーバーを追加したら、Exchange Server 2013 サーバーを削除できます。

トポロジの要件

Exchange Server 2016 は、Windows Server 2012 R2 および Windows Server “10” のオペレーティング システムでのみサポートされます。

Active Directory の観点から、Exchange Server 2016 には以下の要件があります。

• Windows Server 2008 R2 以降の Active Directory サーバー
• フォレストの機能レベルまたはドメインの機能レベルが Windows Server 2008 R2 以上

Exchange Server 2016 は Exchange Server 2010 SP3 RU11* および Exchange Server 2013 CU11* とのみ共存可能です (* 変更の可能性あり)。

推奨されるアーキテクチャ

Microsoft Ignite のセッション (英語)で、Exchange Server 2016 向けの推奨アーキテクチャ (PA) をご紹介しました。PA は、Exchange Server 2016 にとって最適と思われる展開アーキテクチャを実現するために Exchange エンジニアリング チームが策定した推奨されるベスト プラクティスです。Office 365 で展開するアプローチと非常によく似ています。

Exchange Server 2016 の PA は、Exchange Server 2013 の PAと非常によく似ています。データセンター ペアに対称型の DAG が展開され、DAG 内のすべてのサーバーにアクティブ データベース コピーが分散されます。データベース コピーは JBOD ストレージにディスクごとに 4 つずつ展開されます。そのうちの 1 つは時間差データベース コピーです。クライアントは、サイト復元データセンターのペアに均等に分散される統一された名前空間に接続します。

ただし、以下のとおり Exchange Server 2016 PA 固有の特徴もあります。

1. Exchange の制限なし名前空間モデルは、セッション アフィニティを利用しないレイヤー 7 構成内のデータセンターに負荷分散されます。
2. Office Web Apps サーバー ファームは各データセンターに展開されます。各ファームに一意の名前空間 (制限付きモデル) が割り当てられます。セッション アフィニティはロード バランサーによって管理されます。
3. DAG は管理アクセス ポイントなしで展開されます。
4. 一般的なデュアルソケット サーバー ハードウェア プラットフォームには、20 ～ 24 個のコア、最大 196 GB のメモリ、バッテリ バックアップ対応の書き込みキャッシュ コントローラーがあります。
5. すべてのデータ ボリュームは ReFS でフォーマットされています。

リリースが近付いてきましたら、Exchange Server 2016 の推奨アーキテクチャに関するさらに詳しい記事を公開する予定です。

まとめ

Exchange Server 2016 では、以前のバージョンの Exchange で導入された各機能に引き続き重点を置いています。具体的には、サーバー ロール アーキテクチャの複雑さを軽減し、推奨アーキテクチャと Office 365 の設計原則に従い、Exchange Server 2013 との共存機能を改善しています。

これらの変更は、可用性や耐障害性を保持しながら、Exchange の展開を単純化します。中には、PA に沿って展開することで、従来よりも可用性と耐障害性を向上できるシナリオもあります。

Ross Smith IV
Office 365 カスタマー エクスペリエンス担当
主任プログラム マネージャー