皆様、こんにちは。
ネットワールド SEの目木です。
以前に公開したAmazon Workspacesの検証に引き続き、今回はAppStream 2.0を検証しました。利用した環境は前回構築した環境をそのまま流用していますので、そこへAppStream 2.0の環境を追加した際の大まかな流れについてご紹介していきたいと思います。
<過去の検証はこちら>
http://Amazon WorkSpaces検証 Part1：AWSベースの仮想デスクトップ基盤を探る
まず構築手順について確認する前に、少しだけAppStream 2.0の概要について整理しておきます。
AppStreamはデスクトップアプリケーションをSaaSライクに利用できる環境を整えることができるサービスであり、一般的には仮想アプリケーション配信と呼ばれる機能を提供します。
他社ソリューションで言えば、CitrixのVirtual Apps（旧称XenApp）、MicrosoftのRemoteAppなどに近い機能をもったものととらえて問題ないかと思います。
AWSと言えば、デスクトップ配信サービスであるAmazon Workspacesといったサービスもあり、おそらく画面転送経路となるStreaming Gatewayなどは同様のシステムを利用しているのではないかと思われますが、プロダクトの開発としては別サービスとなっているようです。
イメージ図としては以下のような感じでしょうか。
AppStreamで展開されるVMはプール形式で展開されており、ユーザがどのサーバに接続するのかはランダムであり、ユーザがサーバに対して行った変更もVMの停止時にリフレッシュされます。
実際の画面も見ながらもう少し情報を整理していきましょう。
以下はAppStreamの設定画面です。
仮想デスクトップ配信サービスとして、Amazon Workspacesがあったわけですが、AppStreamとは別物のサービスとして展開されています。
画面左側のメニューに見慣れない単語が並んでいますが、構成のためにはこれらの概念を理解しておくとよいかと思います。
概ね触った感触としては以下のようなイメージです。
- Stack（スタック）：利用可能なアプリケーションと利用者、および利用時の制御を紐づけて定義したもの
- Fleet（フリート）：展開に利用するイメージと展開後の利用方式を定義したもの
- Image（イメージ）：展開時に利用するマスタサーバの情報
- User Pool（ユーザプール）：AppStream組み込みの利用ユーザアカウントの一覧
これらの設定を進めていくにあたって、今回は以下の手順で構築を進めています。
- イメージを作成する（配信アプリケーションの定義込み）
- フリートを作成する
- スタックを作成する
- ローカルユーザの作成とスタックへの紐づけ
極力シンプルな状態で構成を進めておりますので、オプション項目については今回触れておりません。その点についてはご了承のほどお願いいたします。
それでは順番に見ていきましょう。
1．イメージを作成する
AppStream用のイメージはImage Builderを使用することで公開するアプリケーションも含めて調整することになります。
今回は大筋の流れを理解するために標準のWindows OSイメージをもとに「notepad++」を追加したマスターを作成して、アプリケーション公開として登録するところまで進めていきます。
では、実際の画面を見ていきましょう。
最初の画面は標準となるOSイメージの選択画面です。
ここではWindows Server 2022のイメージを選択しました。
次の画面では、Image BuilderとしてマスタVMのパラメータを決定します。
ここでの必須項目としては、管理上の表示名およびインスタンスタイプの定義になります。
このインスタンスタイプはImage Builderとして起動する際のサイズのようですので、少々小さいサイズを選択しても問題なさそうです。
【インスタンスタイプ一例】
|
汎用インスタンス |
vCPU |
メモリ (GiB) |
時間料金* |
|
stream.standard.small |
1 |
2 |
0.075USD |
|
stream.standard.medium |
2 |
4 |
0.10USD |
|
stream.standard.large |
2 |
8 |
0.20USD |
|
stream.standard.xlarge |
4 |
16 |
0.40USD |
|
stream.standard.2xlarge |
8 |
32 |
0.80USD |
|
コンピューティング最適化インスタンス |
vCPU |
メモリ (GiB) |
時間料金* |
|
stream.compute.large |
2 |
3.75 |
0.25USD |
|
stream.compute.xlarge |
4 |
7.5 |
0.50USD |
|
stream.compute.2xlarge |
8 |
15 |
1.00USD |
|
stream.compute.4xlarge |
16 |
30 |
2.00USD |
|
stream.compute.8xlarge |
32 |
60 |
4.00USD |
|
メモリ最適化インスタンス |
vCPU |
メモリ (GiB) |
時間料金* |
|
stream.memory.z1d.large |
2 |
16 |
0.45USD |
|
stream.memory.z1d.xlarge |
4 |
32 |
0.90USD |
|
stream.memory.z1d.2xlarge |
8 |
64 |
1.80USD |
|
stream.memory.z1d.3xlarge |
12 |
96 |
2.70USD |
|
stream.memory.z1d.6xlarge |
24 |
192 |
5.40USD |
※オンデマンドフリートでは、インスタンスにユーザーが接続し、アクティブなストリーミングセッションがある場合にのみ実行中とみなされます。
続けてネットワークの設定を行いますが、こちらもマスタとしての定義になります。
これらの設定をもとにマスタVMの作成が実施されたのち、アプリケーションのインストールを行っていきます。
Image Builder作成後の画面を確認すると右上に「Connect」とボタンがあるのが分かります。
こちらをクリックするとマスタVMへの接続が開始され、最初にどのユーザでログインするのか確認が入ります。
今回はアプリケーションのインストールを実行しますので、「Administrator」を選択しています。
ユーザ選択後、ログイン処理が実行され、ログイン後のデスクトップ画面が表示されました。
ここからのインストール手順は物理端末と同じですので、割愛します。
アプリケーションインストール後、あらかじめインストールされている「Image Assistant」を起動して、ユーザに公開するアプリケーションの情報を定義します。
流れとしては「Add App」⇒「.exeファイル選択」⇒ 詳細を確認、といった形です。
詳細部分については、AppStream上での表示名、実行ファイルのパス、アイコンのパス情報などが含まれますので、適宜パラメータを修正してアプリの登録を完了します。
以降、最適化のための設定画面がいくつか表示されますが、接続テストを行ううえでは不要でしたので、今回はデフォルトのままにて進めています。
最後に「Disconnect and Create Image」のボタンをクリックするとイメージの作成が実行されます。
イメージの作成が完了すると、Imageの一覧に情報が表示されるようになります。
以降のフリート設定にてこのイメージを選択することで、本イメージをもとにサーバの展開を進めることができるようになります。
2．フリートを作成する
フリートは作成したアプリケーションあるいはデスクトップ用のイメージをもとに展開、実行されるフリートインスタンス (ストリーミングインスタンスとも呼ばれます) を構成するための設定情報が含まれます。
設定項目としては以下のとおりです。
・名前（表示名）
・説明
・インスタンスタイプ
・ユーザセッション制御 ⇒ セッションタイムアウトを定義
・セッション容量 ⇒ マルチセッションとして展開した際の接続上限数
・ストリーミング設定 ⇒ デスクトップ配信 / アプリケーション配信
このほか、Auto Scalingなどの設定もこちらのページから行います。
次のページではイメージの選択画面が表示されますので、先ほど作成した「notepad++」のイメージを選択します。
続けて、ネットワークの設定として以下の内容を選択していきます。
・VPC
・Subnet
・セキュリティグループ
※ドメインユーザでの利用を考えるとオプション扱いのActive Directoryドメイン情報の登録が必要になりますが、今回は省略しています。
フリートの作成手順としては以上となります。
3. スタックを作成する
スタックは、関連付けられたフリート、ユーザーアクセスポリシー、ストレージ設定で構成されます。ユーザーに対してストリーミングアプリケーションを開始するためにスタックを設定します。
「スタックの詳細」ということで、以下のパラメータを入力します。
（オプションについては省略）
・名前
・フリート ⇒ 先ほど作成したフリートを指定
・Streaming Experience ⇒ TCP あるいは UDP
続けてストレージオプションについて定義します。
こちらは以下3種類のどこに格納できるようにするのかという内容です。
・Home folder（S3に格納）
・Google Drive for Google Workspace
・OneDrive for Business
AWS内にデータを納めるのであれば、Home folderのみで問題ないかと思います。
一方で、手元の端末含め別の環境にあるデバイスとデータを共有したいのであれば、Google DriveあるいはOneDriveとの連携も選択肢に入りそうです。
いずれにせよ、ローカルにデータが保存できない仕組みなので、ファイルサーバ等で保管場所を用意していないのであれば、こちらの機能は必要になってくるでしょう。
次は、ユーザ設定について見ていきます。
ざっとみたところ、クリップボードのリダイレクト制御、ファイル転送制御、プリンターリダイレクト、AD連携あたりが項目として見受けられます。
このあたりはGPOでの制御が必須であったAmazon Workspacesとも微妙に異なります。
転送方向についても片方向、双方向選択可能となっており、こちらの方がやや柔軟性があるように見受けられます。
以上で、スタックの作成およびフリートとの紐づけが完了しました。
4. ローカルユーザの作成とスタックへの紐づけ
AppStreamで利用可能なユーザ認証方式は、AppStream組み込みのユーザアカウントによる認証 あるいは SAML 2.0となります。
今回試すのは組み込みアカウントの方で、ユーザアカウントの作成およびスタックとの紐づけ手順を見ていきます。
必要な情報は、メールアドレスとユーザの姓名になります。
ユーザアカウント作成後はスタックとの紐づけを行います。
スタックとの紐づけを行うと同時に通知メールも出せますので、ここはチェックしたままとします。
受け取った通知メールにはログインページへのURLリンクが含まれていますので、こちらをもとにユーザはAppStream環境へアクセスすることができます。
初回ログイン時のパスワードは通知メール内に存在するものを使用し、初回ログイン完了後にパスワードを再設定します。
ログイン後の画面でアプリケーションをクリックして起動します。
アプリケーションが起動した画面が転送されてきました。
構成手順としては以上となります。
【まとめ】
今回はAppStream 2.0を検証してまいりました。
メーカードキュメントを確認しながら構成を進めていったところ、イメージの作成から展開までの作業時間としては1日程度で完了することができ、簡易的に実装可能なデスクトップ配信／アプリケーション配信サービスという印象を持ちました。
特徴をまとめると以下のような感じでしょうか。
・イメージの作成手順が容易
⇒エージェント等のインストールは不要で、マスタを選択、アプリのインストール、インストール済みアプリを選択してリスト化と作成の流れ自体は分かりやすい
一方で、変更時には都度マスタにログインしてImage Assistantから登録する必要があり、その点は少々手間
・プール型（揮発型）での展開要件に対応可能
⇒一時利用のためのVMであったり、他システムへの踏み台やクライアントアプリの展開用途として利用するのが便利
固定でユーザに払い出すのであれば、Amazon Workspacesを選択
・認証は組み込みユーザ あるいは SAML 2.0のみ
⇒ドメイン参加しなくても利用できる、という点が一時利用には便利
一般的な認証基盤であるADとの連携にもSAMLが必要、ということでこちらは準備も含め構成が少々複雑になる（信頼関係構成など、複雑なドメイン構造に対応しきれるか疑問が残った）
全体を通して導入までの手順はそこまで複雑ではないですが、細かい設定について確認しきれていない部分もありますので、そのあたりの検証は追ってご報告できればと思います。
今回の検証は以上となります。
最後まで読んでいただき、ありがとうございました。
