Catherine Watson
2012 年 9 月 11 日午前 8 時 47 分

この記事は、Office Web Apps の Senior Program Manager である Nick Simons が書いています。

2010 年の夏、私たちは Office Web Apps を発表しました。これは Word、PowerPoint、Excel、そして OneNote のブラウザー ベースのバージョンです。これまでは、これらの製品は SharePoint アプリケーションのセットとして提供されていたため、ユーザーは、Office Web Apps を SharePoint サーバーにインストールしていました。

その時点では、SharePoint との密接な統合が最善のアプローチと考えられていました。SharePoint は、Office Web Apps の構想における重要な柱であり、現在も変わりないことに疑う余地はありません。そして SharePoint では、Office Web Apps のような統合アプリケーションを対象として明確に定義されたモデルが構築されています。しかし、Office Web Apps の次期バージョンを計画し始めてみると、このように SharePoint と密接に組み合わされたアーキテクチャーでは、私たちの中核となる目標の一部が実現し難いことがわかってきました。

私たちは、設定やキャパシティ プランニングを単純化し、複数のファームを対象とするフェデレーションを可能にしたいと考えていました。また、Lync のような新たなパートナーからの統合の要望も取り入れたいと考えました。最終的に、Office 365 と内部設置型の両方のユーザーから多数の意見を伺い、SkyDrive のユーザーが日常的に享受しているのと同様の機能向上が望まれていることを理解しました。

これらの目標を達成するために私たちは最初の段階に戻り、現在および将来において Office Web Apps を他の製品とどのように統合していくかについて考え直しました。そして、Office Web Apps を特定のパートナーのテクノロジーから切り離す新しいモデルを作成しました。このモデルでは SharePoint などのファイル ホストにかかるコーディングの負荷が比較的軽くなり、同時に Office Web Apps を完全に別のサーバーで実行できるようになりました。

この新しいスタンドアロン サーバー製品が Office Web Apps Server です。

別のタイプのサーバーを導入するという考えは、複雑さが増して管理者に負担がかかると思われるかもしれません。しかし、スタンドアロンにすることで、次のようなメリットが生まれます。

1. 設定が簡潔になる

2. アップグレードや保守作業を SharePoint から完全に切り離すことができる

3. 複数の SharePoint ファームと 1 つの Office Web Apps Server ファームを統合できる

4. Exchange、Lync、およびサードパーティの他の製品を Office Web Apps と統合できる

5. Web ベースのユーザーと内部設置型のユーザーに対して、基本的に同時に新機能や機能改善を提供できる

SharePoint 2010 で動作する以前の Office Web Apps と、Office Web Apps Server を使用する新しい製品とを比較すると、そのメリットが実際に見えてきます。

Office の以前のバージョンでは、典型的な Office Web Apps の導入形態は次のようなものでした。

 

 

Office Web Apps の以前のバージョンは、各ファームの各マシンにインストールする必要があったことに注目してください。さらに、Office Web Apps の規模拡張は、SharePoint 全体の規模拡張に縛られていました。また、Office Web Apps を更新するには、すべての SharePoint ファームにあるすべてのマシンでコードを更新する必要がありました。

Office Web Apps Server を使用すると、導入形態は次のようになると考えています。

 

 

ご覧のように、Office Web Apps Server のファーム 1 つで、複数の SharePoint 2013 ファームのほか、Lync 2013 と Exchange 2013 (Outlook Web Access) にもサービスを提供できます。さらに、Office Web Apps ファームを使用して、URL または UNC でアクセスできるあらゆる Word、Excel、PowerPoint ファイルを表示できます。

新たな統合モデルについての簡単な概要

以下では、Office Web Apps が SharePoint などのファイル ホストと高いレベルで統合されている仕組みについて説明します。ここで説明する内容は、後ほどネットワークとセキュリティの要件を理解するのに役立ちます。

まず、定義をいくつか説明します。

Office Web Apps Server – Office Web Apps の機能をホストに提供します。この記事全体で説明するものです。

ホスト – Office Web Apps Server から提供されるサービスを利用して、Web ブラウザーでファイルを表示します。たとえば、SharePoint Server 2013、Lync Server 2013、Exchange Server 2013 はすべてホストに該当します。

クライアント – ブラウザーや同様のソフトウェアが該当します。

この新しい統合モデルの鍵となっているのは、Office Web Apps がホストとの通信に使用する新しいパブリック API です。この API を WOPI (Web application  Open Platform Interface) と呼びます。Office Web Apps Server は、WOPI API を使用してファイルを取得し、操作します。Office Web Apps Server を WOPI アプリケーションと呼ぶこともあります。ホストは WOPI アプリケーションから送られる WOPI リクエストを理解する必要があります。

WOPI は HTTP/HTTPS を使用する RESTful API です。このことは特に、ホストと Office Web Apps Server との間を行き来するすべてのトラフィックが標準の HTTP/HTTPS ポートを通過することを意味します。また、Office Web Apps Server が可能な限り状態非依存であることも意味します。この性質によって、ネットワークの停止からハードウェアの完全な故障に至るまで、さまざまな障害から回復する機能が高まっています。

WOPI が動作する仕組みを理解するために、サリーというユーザーが SharePoint でホストされているファイル test.docx を表示するという簡単なシナリオを見ていきましょう。この機能の仕組みは次のとおりです。

1. サリーが test.docx が保存されているドキュメントライブラリに移動します。

2. サリーがドキュメント ライブラリでファイル名をクリックします。

3. SharePoint によってブラウザーが特別な SharePoint のページに誘導されます。ここでは、Office Web Apps Server (および他の WOPI アプリケーション) へリクエストを出すことができます。この SharePoint ページを WOPIFrame.aspx と呼びます。

4. WOPIFrame.aspx には、インラインフレーム (http://dev.w3.org/html5/spec/the-iframe-element.html) が記述されており、これによって Office Web Apps Server のページに移動します。このページを WordViewer.aspx と呼びます。WordViewer.aspx に対する HTTP リクエストには、次のような重要な情報が含まれています。

Office Web Apps Server が test.docx を取得するために使用する URL。これを WOPI エンドポイントと呼びます。

ファイルの名前。実際には WOPI エンドポイントとファイル名を組み合わせて、WOPI Source と呼ぶパラメーターにしたものです。

Office Web Apps が WOPI Endpoint に渡すことができるサリーの資格情報を表す文字列。これをアクセス トークンと呼びます。
セキュリティ上の理由から、アクセス トークンではサリーに特定の 1 ファイルに対するアクセス権だけを付与します。悪意を持った人物がこのアクセストークンを盗み取った場合でも、これらの人物はこの 1 ファイルに対してサリーの振りをすることができるだけです。もちろん、これも悪いことであるため、アクセストークンを SSL で保護することが重要です。

5. Office Web Apps Server が、WOPI Source とアクセス トークンを使用して SharePoint から test.docx を入手します。

6. WordViewer.aspx によって、WOPIFrame.aspx のインラインフレームに test.docx が表示されます。

次の図は、ブラウザー、SharePoint、および Office Web Apps Server の間のデータの流れを表しています。

 

Office Web Apps Server ファームの設定

この場合のサーバー ファームには、共有サーバーで実行されている 1 台の仮想マシンから、数十台のデータセンター クラスのサーバーで構成されるファームまで、任意のものを利用できます。基本的な設定とメンテナンスの方法は、あらゆる場合において同じです。ファームを作成するための厳密な前提条件や手順の説明は、もちろん製品に添えられていますので、ここでそのマニュアルの内容を述べるようなことはしません。ここでは、スペースが許す範囲で、関係することをお話ししたいと思います。

ハードウェア

まず、マシンが必要です。複数の SharePoint ファームを利用する 80,000 人のユーザーのニーズに対応するファームを 1 つ設定する場合を考えてみましょう。この場合、私たちは、次の機能を備えたサーバーが 4 台必要になると考えます。

すべての必要条件を満たした Windows Server 2008 R2 または Windows Server 2012

8 コア

8 GB の RAM

適切な容量のハード ドライブ (60 GB 以上)

また、ロード バランサーも必要になります。私たちは Microsoft に 10 台のマシンによるファームを構築し、F5 BIG-IP ハードウェア ロード バランサーを他の複数のサーバー製品と共有しています。この構成は極めて良好に動作していますが、他の適切なロードバランシング ソリューションでも効果を発揮すると思われます。私たちが強くアドバイスしたいことは、適切に動作するロード バランシング ソリューションを使用するということです。パフォーマンスに関しては、特定のセッションに対するすべてのリクエストを同じサーバーで処理できるかどうかが非常に重要になります。

ネットワーク

ここでは、皆さんが、内部ネットワークとインターネットの両方から Office Web Apps にアクセスできるようにしたいと考えているとします。その場合は、ファームに対して内部と外部両方の DNS を設定する必要があります。あるいは、外部の DNS だけを設定し、内部の DNS ルールを使用して内部のリクエストをプライベート ネットワーク上に留めることも可能です。私ならばそうするでしょう。
しかし、皆さんのネットワークは皆さんが適切と思われる方法で設定してください。私たちが必要とするのは次のことです。

クライアント (通常は Web ブラウザー) がファームに対してリクエストを行える必要があります。この場合、通常の HTTP リクエストまたは HTTPS リクエストをそれぞれポート 80 とポート 443 経由で発行します。

Office Web Apps ファームにあるマシンは、ファイルホスト (SharePoint など) のサービスに対してリクエストを発行します。これらのリクエストも HTTP または HTTPS でそれぞれポート 80 または 443 を使用します。これが Office Web Apps のマシンが表示および編集するファイルに対して行う動作です。

ファイル ホストが、Office Web Apps Server ファームからロードバランサーを経由して情報を直接要求しなければならない場合があります。この場合も HTTP リクエストまたは HTTPS リクエストをそれぞれポート 80 とポート 443 で発行します。

Office Web Apps Server ファームにあるすべてのマシンは、ポート 809 を使用して互いに通信する必要があります。理想的には、これらのマシンをプライベート サブネットに配置して、他のマシンからはファームへの参加やトラフィックの傍受ができないようにします。これができない場合には、よりオープンなネットワークでファームを保護するのに役立つ機能が Office Web Apps Server に組み込まれていますが、この機能についてここでは言及しません。詳細については、「Security planning for Office Web Apps Server Preview (Office Web Apps Server プレビューのためのセキュリティ計画)」を参照してください。

これらのネットワーク ルートは正しく設定することが重要です。Office Web Apps は比較的シンプルですが、通信チャネルがオープンの場合にしか動作しません。

セキュリティ

先に述べたとおり、ファイルを表示または編集するための最初のリクエストには、ユーザーの資格情報がアクセス トークンの形で含まれています。そして、このアクセストークンは、Office Web Apps からホストに送られるすべてのリクエストに含まれます。プライベートネットワークを使用していて、そのネットワークにアクセスする全員を信用できる場合を除き、このトラフィックはすべて SSL で保護する必要があります。そしてその後も SSL を使用する必要があります。
SSL を設定するには、証明書を作成して、これを各 Office Web Apps Server マシンまたはロード バランサーに置く必要があります。SSL をロードバランサーで終端することを選択した場合は、使用できる Office Web Apps Server で特別な設定が必要です。これについて簡単に説明します。

Office Web Apps Server の設定

ハードウェアとネットワーク インフラストラクチャーの準備はすべて完了しました。次は実際に Office Web Apps Server ファームを作成します。まず、Office Web Apps Server とその言語パックをすべてのマシンにインストールします。これらのマシンに他のソフトウェアはインストールしないでください。SharePoint も、Exchange も、何もインストールしないでください。ハードウェアを共有したい場合は、仮想マシンを使用してください。

これが完了したら、次の Windows PowerShell をファーム内の 1 台目のマシン (これを Server1 と呼びます) で実行します。この Windows PowerShell では、皆さんが次のような設定を行うと想定しています。

・      外部 DNS だけを https://officewebapps.contoso.com という URL で設定している。これにはどのような URL も設定できます。

・      Office Web Apps Server ファームを、ファイルの表示だけでなく編集にも対応するよう設定しようとしている。
これは、皆さんの組織が編集用の適切なライセンスを所有している場合にのみ設定できます。ここではライセンスについては詳しく説明しませんが、Office Web Apps での表示は無料ですが、編集機能は無料でないことのみお伝えしておきます。詳細については、「Plan Office Web Apps Preview (Used with SharePoint 2013 Preview Products) (Office Web Apps プレビューについての計画 (SharePoint 2013 プレビュー製品を使用する場合))」を参照してください。

・      SSL をロード バランサーで終端させている。

ここで、Windows PowerShell を次のように実行します。

              New-OfficeWebAppsFarm -ExternalURL "https://officewebapps.contoso.com" -EditingEnabled -SSLOffloaded

この時点で、マシン 1 台による Office Web Apps Server ファームができています。

これが完了したら、Server2 に移動します。このサーバーで、次のように実行します。

              New-OfficeWebAppsMachine -MachineToJoin "Server1"

これで、マシン 2 台によるファームが構築できました。この手順を、Server3 と Server4 でも繰り返します。

SharePoint への接続

この段階で、皆さんの Office Web Apps ファームは計画通りに構築されています。しかし、まだどのホストにも接続されていません。SharePoint ファームをこの Office Web Apps Server ファームに接続するには、SharePoint ファームのいずれかのサーバーで Windows PowerShell のコマンドプロンプトを開いて、次のコマンドを実行してください。

              New-SPWopiBinding -ServerName "officewebapps.contoso.com"

また、次のコマンドを実行して、皆さんが Office Web Apps Server ファームの外部 URL を使用することと、この場合に HTTPS を使用することを SharePoint ファームに伝える必要があります。

              Set-SPWopiZone -Zone "external-https"

これで完了です。SharePoint ファームのドキュメント ライブラリに移動して、Office ファイルを思いのままに作成、表示、編集してください。これ以上の設定は必要ありません。

最後に、SharePoint から Office Web Apps Server ファームへの接続を切断したい場合は、次のコマンドを実行してください。

              Remove-SPWopiBinding -All

この時点で SharePoint ファームのドキュメント ライブラリに移動すると、Office Web Apps の痕跡はなにもありません。

1 つの Office Web Apps ファームに、任意の数の SharePoint ファームを接続することができます。そして、Exchange や Lync を Office Web Apps ファームに接続する場合にも同じことが言えます。詳細については、「Exchange Server 2013:Office Web アプリケーション サーバーの統合」および「Deploying Office Web Apps Server and Lync Server 2013 (Office Web Apps Server と Lync Server 2013 の導入)」を参照してください。

Office Web Apps Server の更新プログラムの入手方法

私たちは当初より Office Web Apps の更新プログラムを頻繁に提供するよう努力しています。しかし、更新プログラムは内部設置型のユーザーにのみ Service Pack の形で提供してきました。Office Web Apps Server 2013 のリリース後は、更新プログラムの提供頻度をさらに高めていく予定です。Office Web Apps Server の更新は非常に簡単であるため、管理者が管理可能であると考えています。

Office Web Apps Server ファームにあるマシンを更新するには、ロードバランサーとファームからマシンを切り離す必要があります。しかし、この処理はユーザーにほとんど影響を及ぼさないため、管理は可能です。
4 台のマシンによるファームの場合は、基本的にはまず 2 台のマシンを切り離して更新します。次に、この 2 台のマシンを使用して新しいファームを作成し、ロード バランサーを元のファームの 2 台ではなくこの 2 台を対象にするように変更します。この後、残りの 2 台を更新して、これらを新しいファームに追加し、ロードバランサーがこれらのマシンも対象にするようにします。

マシンをファームから切り離すと、一部のユーザーで一時的な中断が生じることがありますが、Office Web Apps によって復旧されます。これは、ファームが 1 台のマシンでのみ構成されている場合を除き、すべての場合に当てはまります (理由は明白です)。

Office Web Apps Server の詳細情報

Office Web Apps Server に関する他の資料は、次のサイトで参照できます。
• Office Web Apps プレビューライブラリ (TechNet)
• Exchange Server 2013: Office Web アプリケーション サーバーの統合
• Deploying Office Web Apps Server and Lync Server 2013 (Office Web Apps Server と Lync Server 2013 の導入)
• Office Web Apps Setup and Deployment Forum (Office Web Apps の設定と導入に関するフォーラム)

Nick Simons
Senior Program Manager - Office Web Apps