本記事は、Nutanix Xi Frame Advent Calendar 2018の20日目分としての投稿になります。
https://adventar.org/calendars/3239
本記事の内容は、この日付時点の情報（一部Frame開発バージョンを含む）に基づいています。そのため、今後新しいバージョンが提供された場合に，当該記載と矛盾が生じる場合がありますのでご注意ください。
#はじめに
迂闊にも勢いでNutanix Xi FrameのAdvent Calendarにエントリしてしまったので、あまり需要がないけど「○×やってみた」系をお一つお届けします。既にタイトルで結果が分かる出オチ感満載ですが、少しお得なFrameの解説も併せてお届けします。
Frameは、デスクトップのインフラストラクチャとしてAWSやAzureなどのパブリッククラウドのインスタンスや仮想マシンをそのままネイティブに利用すること、それを制御・管理するためのコンソールを提供し、オンプレミスのVDIのような非常に複雑な設定が不要で、非常にシンプルにデスクトップを短時間で提供できることなどが特徴です。AWSやAzureなどのパブリッククラウドのインスタンスや仮想マシンをそのまま利用すると言うことはGPU付きのインスタンスもそのままデスクトップとして利用できることを意味します。
だったらゲームを動かしてみたくなるじゃないかということで、往年のMMORPGであるFFXIを動かしてみようと言うのが今回の趣旨です（FFXIを選択したのは、単純に筆者がFFXIの休眠プレイヤーだからと言うだけなんですが…）。
#FrameにFFXIをインストールしてみる
さっそくFFXIをインストール・・・の前に、まずは簡単にFrameってどうやって動いているんだっけ？と言うところのFrameの仕組みについておさらいをしておきます。
##Frameで利用するデスクトップの正体
Frameの基本的な仕組みについては、既にNutanix Xi Frame Advent Calendar 2018の12月8日分で紹介されていますが、もう少しFrameのデスクトップの実態について解説してみます。
現時点で、FrameではAWSとAzureのいずれかの環境が利用可能ですが、今回、本記事で利用する環境はAWSとなります。そしてFFXIを利用する関係上、Windowsマシンとなるのですが、FrameはAmazon WorkSpacesを利用する訳ではなく、実態としては単純にAWS上でWindowsのAMIを利用したインスタンスを利用する形になります。Frameが提供するデスクトップは、実際にはFrameがカスタムしたWindowsのAMIを利用し、Windows Serverベースのイメージ＋デスクトップエクスペリエンスを組み合わせたものとなります。
BYOD方式で利用する場合などでは、FrameはFrameの管理者がAWSやAzureのインスタンスや仮想マシンタイプをFrameのインスタンスタイプとマッピングしておいたものが利用者に提供され、ユーザーは、起動時に予めFrame管理者が設定したFrameのインスタンスタイプを選択してデスクトップを利用することになります。例えばt3.mediumやg3s.xlargeのインスタンスタイプを選択可能と設定してあり、かつユーザーにインスタンスタイプの選択を許可している場合には、ユーザーには直接的にAWSのインスタンスタイプは表示されませんが、いずれかのタイプの仮想マシンを選択すると、実質的にAWSのt3.medium又はg3s.xlargeのインスタンスを選択して利用することとなります。
つまるところ、AWSを利用する場合でもAzureを利用する場合でも、予め管理者が設定したリージョンやインスタンスタイプの制約や特性引き継ぐことになる（例えばいAWSのインスタンスタイプを例にとると、EBSのタイプやディスクサイズ、CPU、I/O等の各種リソースのクレジット、リージョンによっては選択できないインスタンスタイプや仮想マシンタイプがある、など）ため、Frameのデスクトップの利用形態に応じて適切なインスタンスや仮想マシンのタイプを設定しておく必要があります。
##Frameで利用するデスクトップの確認
さっそくFrameで起動したデスクトップを見ていきます。最初は何も考えずに、Frameのデスクトップを起動してみます。ここで紹介する環境では、Frame管理者が1種類のインスタンスのみを利用可能としているため、インスタンスタイプの選択はできません。
起動してきたデスクトップでwinverを叩いてみます。そうすると、このインスタンスがWindows Serverで動いていることがわかります。
また、通常であれば、例えばAWSのコンソールでパブリックなFQDNやIP、ホスト名を含む様々なインスタンスに関する属性情報や付帯情報などを見ることはできますが、Frameはサービスとして提供されるため、その辺の情報をユーザー知ることはできません。しかし今回のようにAWSであればお馴染みのインスタンスメタデータをひっぱることで、それらを知ることが可能です。
そんな訳で、さっそくブラウザにhttp://169.254.169.254/latest/meta-data/を入力していきます。AWS上で動いているため、インスタンスメタデータで確認可能な一覧が表示されます。
インスタンスタイプの確認のためhttp://169.254.169.254/latest/meta-data/instance-typeをブラウザに入力してみます。そうすると、このインスタンスはg2.2xlargeであることがわかりました。
次にpublic-hostnameを見てみます。これによりFrameのデストップのインスタンスパブリックホスト名がわかりました。
パブリックホスト名ったところで、試したくなるのがRDP接続です。さっそく手元の端末でリモートデスクトップクラウイアントを起動して接続してみます。
そもそもAWSのWindowsインスタンスではRDP接続する際にはKey-Pairを利用しパスワードを復号するなどして接続しますが、Frameは独自の接続方式（HTML5クライアントでWebSocketを利用したH.264ベースの独自画面転送方式を利用した形で提供）のas a Serviceであり、実際に接続を試してみると、セキュリティグループによるRDPのアクセス遮断、又はインスタンスへの直接的なInternetGatewayの接続を行わないなど、なにかしらの方法でユーザーやFrameが提供するVPCには直接接続させずに、ブラウザによる、セキュアに限られた環境からのみアクセスを許容してることがわかります。
##FFXIインストール前にDirectXの確認
さて、寄り道しまくりですが、さっそくインストールのほうを開始してみます。その前に一応、FFXIの動作要件であるDirectXの確認をしておきます。既にこのインスタンスはG2インスタンスであることが分かっているので、あまり心配はしていませんが、念のためdxdiagで確認しておきます。
FFXIはDirectX8.1以降に対応なので、まずDirectXの対応状況を確認します。今回の環境では、DirectXが11となっており、基準をクリアしていることが確認できます。
またDirectDrawアクセラレータやDirect3Dのアクセラレータも確認してみると、いずれも有効になっており、利用可能なGPUはGRIDのK520であることもわかりました（ここまでで間違い無く動作できるとの予感でした）。
と、ここまで書いておいて、こちらの環境が諸事情により時間切れで利用できなくなったため、もう1つ用意した環境で続きを試すことになりました。もう1つの環境はWindows Server 2012 R2ベースではなくWindows Server 2016ベースの環境です。インスタンスタイプも、G2と少し古いインスタンスタイプから新しいG3タイプのインスタンスでg3s.xlargeとなっています、そして、DirectXは12に、GPUはM60になっています、FFXIを試してみた！のためだけにインスタンスのヒドい無駄づかいですね豪華ですね。
##FFXIインストール前にFrameのインスタンス解説
FFXIの公式ページからソフトウェアをダウンロードして展開しインストールを開始します。本来だとFrameでユーザーが共通的に利用するアプリケーションを展開する際には、Frameの管理者が利用するコンソールからソフトウェアのインストールを行うのですが、今回はユーザー側のデスクトップにインストールを行っています。
ここで、もう1つFrameの仕組みをご紹介しておきます。先ほど「Frameの管理者が利用するコンソール」と「ユーザー側のデスクトップ」と言う言葉が出てきましたが、Frameの基本的な運用を含めて、この2つの違いについて解説しておきたいと思います。
Frameは、ユーザーに展開するデスクトップイメージの元となるSandboxと呼ばれるFrame管理者がマネージ可能な、謂わばVDIで言うところのゴールドイメージ又はマスタイメージに相当するものを操作（例えばユーザーが共通的に利用するOS上の設定やオフィスアプリケーションや業務アプリケーションをインストール）することでFrameが提供するデスクトップのベースイメージを作成し、それらをコピーしてユーザーに利用してもらう形となります。
もちろん、ユーザーとして利用する環境でも提供されるデスクトップのOS管理者権限でログインできるので、ソフトウェアのインストールを行うことは可能ですが、あくまで、ユーザーが利用している環境はFrame管理者が作成したベースイメージのコピーとなります。何度もお伝えしているとおり、Frameはパブリッククラウドをネイティブに利用していてるので、使った分だけの課金で済む仕組みを採用しています。Nutanix Xi Frame Advent Calendar 2018の12月3日分でも紹介されていますが、そのメリットを活かすため、基本的にFrameの思想では永続的なデスクトップの存続を考えていません。
Frameでは、ユーザーがアプリケーションを実行するためのインスタンス(VM)の展開および割り当てはオンデマンドで行われます。
もう少し詳しく言うと、基本的に、アプリケーションへの接続をリクエストした時点でインスタンスのデプロイが行われ、ユーザーに割り当てられます。また、アプリケーションの利用を終了(あるいは何もせずに放置)すると時間経過をトリガーに、インスタンスの削除が行われます。
ユーザーごとにクラウド上のインスタンスが固定的に割り当てられたり、毎回同じインスタンスへ接続されたりするわけではありません。(逆にオンプレミスのVDIだとこちらの利用方式もよくあります)
ユーザーとしてFrameにログインをしてデスクトップを利用し、その際にソフトウェアのインストールを行っても、そのデータはFrameのログアウトを含む利用終了によりインスタンスの削除（AWS的にはTerminateされる）と共に消えてしまいます。そのため、本来であれば「ベースイメージ側」をいじる訳ですが、今回はFFXIを一時的にインストールするだけなので、ユーザー側のデスクトップで作業を行っています。
##FFXIインストール前にFrameのアプリケーション公開について解説
Frameの管理者が管理するベースイメージとなるSandboxは、アプリケーション形式（exeやmsiインストーラー等でインストールされたアプリケーション）のソフトウェアインストールが行われると、それを検知して、それらをFrameのユーザーへの公開可能なアプリケーションの一覧に加えることができます。公開可能なアプリケーションの一覧への追加をFrame用語でOnboardと言います。そして、Onboardされた公開可能アプリケーションの一覧とは別に、それらのアプリケーションを実際にユーザーに公開（ユーザーが起動可能でかつ利用できるようにする）するかを設定可能です。
これはFrameはデスクトップのみの利用だけではなく、Citrix Virtual Apps（旧名称：XenApp）のようなアプリケーションのみを利用させるモードで利用させたり、特定のユーザーには許可するアプリを設定したりする場合に利用します。ただし、Citrix Virtual AppsがUnityモードのような形で利用するのに対して、Frameはブラウザの中でアプリケーションが描画されて動作します。そのためブラウザの中にはWindowsデスクトップは表示されず、アプリケーションのみが開かれるイメージになります。
通常のデスクトップモードでPowerPointを起動させた場合と、アプリケーション単体を起動した場合の違いを見てみます。以下は、通常のデスクトップモードでPowerPointを起動させた場合です。
それに対して、Launchpadからデスクトップではなく、アプリケーションを起動する場合は、Launchpadから、PowerPointを選択します。なお、Launchpadで見えているPowerPointをはじめとするアプリケーションは、Frameの管理者がユーザーに対して公開可能と設定しているアプリケーションになります。
そうすると、以下のような画面になります。ご覧のようにWindowsデスクトップにあったスタートメニューやタスクバーは一切見えず、PowerPointのみがブラウザの中に開いている様子がわかります。
##インストール完了と起動
さて、全然本題に入らないまま解説が続きましたが、今度こそ本当にインストールを行っていきます。とても懐かしい画面です。
FFXIのインストールがひととおり終わったので、いよいよFFXIを起動します！満を持してFFXIを起動すると・・・ハイきましたアップデートです・・・そうですね、忘れてましたアップデートがあります。パブリッククラウド上のデスクトップであろうと、手元にある物理デスクトップPCであろうと、平等にアップデートの時間はとても掛かるので、ひたすら完了するまで待ちます。
そして、アップデートも完了してPlay Online viewerが再起動して、この画面までやってきた時点で気分は最高潮に達していました。いざヴァナ・ディールへいざ旅立たん。
Oh...旅立ちに失敗しました。。。
##原因と対策
原因と対策と言っても、ここからはFrameには直接的に関係のないトラブルシュートになります（いや、最後は結局、Frameにも関連するんだけどね）。
###原因
新しい環境ではDirectX 12の環境で、DirectXやDirectDraw、Direct3Dの対応も問題ない環境でしたが、Windows 8.1以降のWindows OSではFFXIの起動に際して、DirectPlayの有効化が必要でした。Windows 8.1やWindows 10ではWindowsの機能の有効化または無効化からレガシーコンポーネントを選択してDirectPlayを有効化する必要があり、Windows Serverでも役割と機能の追加もしくはPowerShellのInstall-WindowsFeature等でDirect Playを有効化する必要があります。
###対策
通常のAWSのAMIで提供されているWindows Serverイメージの場合、Direct Playの有効化は問題なく可能なのですが、Frameで提供されているカスタムWindows Serverイメージでは、残念ながらDirect Playは追加することができませんでした。
正確には、Frameが提供しているWindows Serverイメージで提供されるデスクトップのWindows自体にDirect Playのバイナリが入ってないようで、Direct Playの有効化操作時に「代替ソースパスを指定して下さい」と指示され、そのままインストールを行っても有効化に失敗します。
ならばと、Windows ServerのISOをダウンロードし、sourcesフォルダからinstall.wimを指定してみたものの弾かれ、さらにはdismコマンドでDirect Playを追加したwimイメージを作成しとうと目論見ましたが、こちらもあえなく失敗に終わり、結局FFXIのインストールまではこぎ着けたものの、起動することはできませんでした。
#まとめ
ここまで、FFXIをインストールするとお題を使いながら微妙にFrameの以下の仕組みについて解説してきました。
- Frameで利用されるインスタンスや仮想マシンタイプ
- Frameの管理者のSandbox操作とユーザー利用の違い
- ベースイメージ及びアプリケーションのインストールとOn-board
いかがでしたでしょうか、やってみた系をしつつ、Frameの中身についてそれっぽい解説をしてきました。AWSやAzureを知っていると、よりFrameの仕掛け、仕組みが理解できたり、想像できたりして、楽しめるかと思います。もちろん、FrameのユーザーとしてログインしてFrameのデスクトップの利用開始と終了を繰り返すことで、インスタンスガチャも可能です。
#POST SCRIPT
最後に、Frameでは起動できなかったのが悔しくて（と言うより、ひさびさに休眠状態を解除するのに再課金したのに起動できないのはセツナイので）自分の家のPCでひさびさにFFXIにログインしてみました。
ログイン後の心境です。
やんごとなき事情により数年ぶりにFFXIを起動・・・どこまでなにやってたか、倉庫キャラに何を預けていたか何も覚えてないし、メインキャラのジョブがなんでそーなってんのかも全然わかんないｗ
— 鼻からミルク a.k.a hana(ry (@hanakara_milk) 2018年12月13日