しばたです。
先日より Amazon AppStream 2.0のうちWindows Server環境において1つのインスタンスを複数ユーザー(セッション)で利用するマルチセッション構成を組むことが可能になりました。
AWSからのアナウンスはこちらになります。
AppStream 2.0アーキテクチャの根深いところを変える変更の割にはドキュメントの更新があっさり目だったため、本記事では現時点で分かる点について解説していきます。
機能詳細
従来AppStream 2.0はアプリケーションを公開するインスタンスを利用者が占有し都度使い捨てるアーキテクチャとなっており、「1インスタンス : 1セッション」のシングルセッション構成となっています。
今回の更新によりFleetにおいて「1インスタンス当たりの最大セッション数」を設定できる様になり、「1インスタンス : nセッション」のマルチセッション構成を採ることができます。
マルチセッション構成によりインスタンス利用の集約率を上げることが可能となりコスト効率を上げることが可能になります。
前提条件
マルチセッション構成を採るための前提条件は以下の通りです。
- 本日時点において利用可能なOSはWindows Server 2019環境のみ
- Windows Server 2016以前やLinux環境ではマルチセッション不可
- フリートの種類は「Always-On」または「On-Demand」であること
- Elastic Fleetsではマルチセッション不可
- OSイメージは最新(2023-06-12以降)のものであること
ドキュメントには記載が無かったのですがWindows Server 2016環境でFleetを作ろうとしたら「不適切なプラットフォーム」な旨のエラーで怒られました。 Windows Serverと言えども全てのOSが対象ではないのでご注意ください。
The AppStream 2.0 image 'AppStream-WinServer2016-06-12-2023' does not support Multi-Session because it uses platform 'WINDOWS_SERVER_2016'. To resolve this issue, choose an image that uses one of these platforms: [WINDOWS_SERVER_2019].
また、利用可能なOSイメージの詳細については以下のドキュメントをご覧ください。
ベースイメージが最新であるのに加えOS内部のAppStream 2.0 Agentのバージョンも新しいものである必要があります。
最大セッション数の目安
AWSの設定上は1インスタンス当たり最大50セッションが上限になっています。
とはいえ実際の上限は利用用途とインスタンスのスペックにより決まり50セッションに至る前に性能限界を迎えることがほとんどでしょう。
AWSとしては以下のドキュメントでセッション数の目安を出しています。
細かい点はドキュメントで確認いただきたいですが、ざっくり
- 軽作業 : 1vCPUあたり4セッション上限
- ほどほどの作業 : 1vCPUあたり2セッション上限
- 重作業 : 1vCPUあたり1セッション上限
といった感じです。
制限事項
将来的にどうなるかは分かりませんが、本日時点においては以下の制限があります。
- Google DriveおよびOneDriveの利用は出来ません
- ローカルデバイスでの印刷はできません
- Active Directory環境に対するスマートカードによるサインインはできません
利用料金
マルチセッション環境におけるインスタンスの利用費はセッション数ではなく実際に起動しているインスタンス数に応じた金額となります。
Multi-session instances are charged on an hourly basis, regardless of the number user sessions running per instance.
1インスタンス当たりで利用するセッション数が増えれば増えるほど費用面ではお得になる形です。
ただしRDS SALのライセンス費用はシングルセッション構成とマルチセッション構成で異なり、本日時点で以下の通りとなっています。
- シングルセッション構成のRDS SALライセンス費用 : 1ユーザーあたり 4.19 USD/月
- マルチセッション構成のRDS SALライセンス費用 : 1ユーザーあたり 6.42 USD/月
利用形態でRDS SALの費用が変わるのはかなり珍しいですね。
AppStream 2.0のライセンス費は一般的なRDS CAL/SALの費用からするとかなり格安で6.42USD/月でも正直安い方だと思います。
試してみた
ここからは実際に機能を試していきます。
今回は私の検証用AWSアカウントの東京リージョンで新規に環境を作っていきます。
VPC等のネットワーク環境は事前作成済みの状態から始めます。
1. イメージ作成
今回は機能を試すだけなので、AWSが提供するベースイメージをそのまま使います。
本日時点で最新のWindows Sever 2019イメージはAppStream-WinServer2019-06-12-2023なのでこれを採用します。
実際の運用においてはこのベースイメージからさらに公開アプリケーションの導入を行うと良いでしょう。
2. Fleet作成
次にFleetを作成します。
今回はOn-Demandタイプを選択します。
フリート名やインスタンスタイプなど特に制限ないので適当に選択しています。
設定の内Fleet Capacity欄に「Multiple user Sessions」のチェックが増えており、これをチェックするとマルチセッション構成となります。
マルチセッション構成の場合はキャパシティ関連の内容が独自のものとなり、
- Maximum sessions per instance → 1インスタンス当たりの最大セッション数
- Minimum user sessions for fleet → Fleet全体での最低セッション数
- シングルセッション構成の Minimum capacity 相当
- Maximum user sessions for fleet → Fleet全体での最大セッション数
- シングルセッション構成の Maximum capacity 相当
を設定する必要があります。
今回はマネジメントコンソールに表示されている初期値をそのまま採用します。
Viewの設定はOS内部の調査をしたいので「Desktop」とし、その他パラメーターは初期値のまま「次へ」進みます。
イメージは前述の通りAppStream-WinServer2019-06-12-2023を選びます。
その他ネットワーク設定などは環境に応じた内容としFleetを新規作成します。
出来上がった結果はこんな感じになります。
マルチセッション構成の場合、利用状況を表すメトリクスはUserSessionが付くセッション数ベースの値になります。
それぞれシングルセッション構成のメトリクスと対になると考えると良いでしょう。
| シングルセッション構成 | マルチセッション構成 | 備考 |
|---|---|---|
| PendingCapacity | PendingUserSessionCapacity | マルチセッション構成時はPendingCapacityは記録されない模様 |
| AvailableCapacity | AvailableUserSessionCapacity | |
| InUseCapacity | - | 対応するメトリクス無し |
| ActualCapacity | ActualUserSessionCapacity | |
| DesiredCapacity | DesiredUserSessionCapacity |
また、スケーリング設定の単位もインスタンス数からセッション数に変わります。
(スケールアウトの設定例。セッション数単位になっている)
3. Stack作成など
Stack作成およびユーザーとの紐づけは従来通りの手順なので割愛します。
ただ、「制限事項」で説明した様にマルチセッション構成では一部機能が利用できないため、マネジメントコンソールのUI上でも非表示になります。
(マルチセッション構成の場合はGoogleDrive、OneDriveの設定が非表示になる)
4. 動作確認
ここから最初のユーザーでFleetインスタンスに接続します。
OSにログインした状態だけみればシングルセッション構成となんら変わりありません。
ただ、ログインユーザーを確認してみるとAS2-[ランダムな値]となっておりPhotonUser固定だったシングルセッション構成とは異なっていました。
ユーザー情報の詳細を取るとこんな感じです。
# マルチセッション構成ではPhotonUserの代わりに AS2-ランダム値 なユーザーが作られる
PS C:\Users\AS2-14615c127224aaaf> Get-LocalUser | Select-Object Name, SID, LastLogon
Name SID LastLogon
---- --- ---------
Administrator S-1-5-21-3291951778-205218670-2880196307-500 6/9/2023 9:01:40 PM
AS2-14615c127224aaaf S-1-5-21-3291951778-205218670-2880196307-1009 10/29/2023 2:07:50 AM
DefaultAccount S-1-5-21-3291951778-205218670-2880196307-503
Guest S-1-5-21-3291951778-205218670-2880196307-501
WDAGUtilityAccount S-1-5-21-3291951778-205218670-2880196307-504また、リモート接続のモードもコンソールセッションを使っていたシングルセッション構成とは異なりリモートデスクトップセッションを使う様になっています。
# query session コマンドでセッション情報を取得
PS C:\Users\AS2-14615c127224aaaf> query session
SESSIONNAME USERNAME ID STATE TYPE DEVICE
services 0 Disc
console 1 Conn
>dcv-udp#0 AS2-14615c127224aaaf 2 Active
dcv-udp 65536 Listen
rdp-tcp 65537 Listen加えてリモートデスクトップセッションを使う都合RDSHとRD Licenseingの機能が追加インストールされていました。
ただし、ライセンスサーバーの指定などは未設定のままで、あくまでもNICE DCVがRDPの機能を補助的に使っているだけの様です。
PS C:\Users\AS2-14615c127224aaaf> Get-WindowsFeature -Name RDS*
Display Name Name Install State
------------ ---- -------------
[ ] Remote Desktop Connection Broker RDS-Connection-Broker Available
[ ] Remote Desktop Gateway RDS-Gateway Available
[X] Remote Desktop Licensing RDS-Licensing Installed
[X] Remote Desktop Session Host RDS-RD-Server Installed
[ ] Remote Desktop Virtualization Host RDS-Virtualization Available
[ ] Remote Desktop Web Access RDS-Web-Access Available
[ ] Remote Desktop Licensing Tools RDS-Licensing-UI Available今度はこの状態で二人目のユーザーで接続を追加してみます。
今回の設定は「1インスタンス当たり最大2セッション」なので同じインスタンスに接続されます。
(接続先のホスト名 EC2AMAZ-F0CV56R とIPアドレス 10.0.11.203 が同一)
二人目のローカルユーザー名は一人目のものとは異なりこれにより環境の分離を実現しています。
再度ローカルユーザーの詳細を取得するとこんな感じで2ユーザーいることが分かります。
# AS2- で始まるユーザーが2人に増えている
PS C:\Users\AS2-0bf8900be37242e8> Get-LocalUser | Select-Object Name, SID, LastLogon
Name SID LastLogon
---- --- ---------
Administrator S-1-5-21-3291951778-205218670-2880196307-500 6/9/2023 9:01:40 PM
AS2-0bf8900be37242e8 S-1-5-21-3291951778-205218670-2880196307-1010 10/29/2023 2:27:50 AM
AS2-14615c127224aaaf S-1-5-21-3291951778-205218670-2880196307-1009 10/29/2023 2:07:50 AM
DefaultAccount S-1-5-21-3291951778-205218670-2880196307-503
Guest S-1-5-21-3291951778-205218670-2880196307-501
WDAGUtilityAccount S-1-5-21-3291951778-205218670-2880196307-504当然ユーザープロファイルも別々で他ユーザーの領域にはアクセスできません。
こんな感じでマルチセッション構成が実現されています。
余談
ここまでで一通りの機能を試しました。
最後にいくつか気になった点について余談として解説します。
余談1. ログアウトするとユーザーは削除される
2ユーザー同時に利用している状態から最初のユーザーをログアウトさせると当該ローカルユーザーとユーザープロファイルが削除されます。
(ログアウト後に最初のユーザー AS2-14615c127224aaaf が削除された様子)
これにより不要なデータを残すことなくFleetインスタンスを再利用する様になっています。
余談2. ローカルユーザーIDは完全ランダムでは無い
本記事を書くまでに何度か環境を作り直して動作確認しているのですが、AS2で始まるローカルユーザー名は常に同一でした。
具体的なアルゴリズムなどは非公開ですが、ユーザープールのユーザー名をキーとする何らかのハッシュ値で決まる模様です。
ちなみにS3に設定されるユーザーIDとは別の値でした。
余談3. 同一ローカルユーザーが作られてもSIDは別
Fleetインスタンス利用の都度ローカルユーザーの作成と削除を行うことは、同一名称のローカルユーザーを何度も作り直す可能性があるという事になります。
Windows OSにおいてはローカルユーザーを増やす都度SIDはインクリメントされますので、厳密には都度別々のユーザーが作られている扱いとなります。
とはいえAppStream 2.0の利用においてローカルユーザーの名称やSIDの違いが問題になることはまず無いでしょう。
# これまでの例でいえば 相対識別子 (10xxの部分) が随時インクリメントされる
S-1-5-21-3291951778-205218670-2880196307-10xx余談4. スケーリングの詳細について
残念ながら現時点においてFleetインスタンスをスケールさせる際の詳細についてドキュメントが全然ありません。
概要レベルであれば以下のドキュメントだけ存在します。
このため予想になるのですが、実際に動作確認をした感じだとAWS内部的にはFleetインスタンス毎のセッション利用率を持っている様に見受けられました。
新規セッションが接続する際は極力集約率を上げる様にFleetインスタンスを選ぶ様です。
そして起動するFleetインスタンス数はDesiredUserSessionCapacity値の変化から導出されるDesiredCapacityの値で決まる仕組みの様です。
# 必要なFleetインスタンス数は切り上げで算出
DesiredCapacity = ROUNDUP(DesiredUserSessionCapacity / 1インスタンス当たりの最大セッション数)また、仕組み上既存セッションの再配置は不可能なはずなので、長時間利用するセッションが残る場合はスケールダウンしたくても出来ないケースが起きると思われます。
この辺の挙動については公式な情報が増えたら確認してみたいです。
終わりに
以上となります。
AppStream 2.0のコスト面を気にする方にとっては待ち望んでいた更新だと思います。
現時点ではまだ制約がありますが、アプリケーションの種類によっては問題無くマルチセッション構成を採れるものもあるでしょうし変更を検討しても良いかもしれませんね。
2
