

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# アプリケーションオンボーディングガイドライン
<a name="onboarding-applications"></a>

WorkSpaces アプリケーションを通じてエンドユーザーがアプリケーションを使用できるようにする前に、アプリケーションが WorkSpaces アプリケーションクラウド環境で正しく動作していることを検証し、アーティファクトをレンダリングせずにアプリケーションをストリーミングできることを確認し、アプリケーションのリソースプロファイルに合わせてフリートを適切にサイズ設定します。このページには、ストリーミングする予定のアプリケーションごとに従うことができる構造化されたオンボーディングチェックリストが用意されています。マルチセッションを使用する場合は、同じホストで複数のバージョンのアプリケーションを実行する機能に特に注意する必要があります。[ネイティブアプリケーションモード](https://docs.aws.amazon.com/appstream2/latest/developerguide/feature-support-native-application-mode.html)を使用する場合は、アプリケーションでこのモードとの互換性の問題が発生していないことを確認する必要があります。

これらのガイドラインは、新しいアプリケーションをオンボーディングする場合も、別の配信モデルから既存のアプリケーションを移行する場合も適用されます。

## オンボーディングプロセスの概要
<a name="onboarding-overview"></a>

WorkSpaces Applications へのアプリケーションのオンボーディングには、2 つの並列トラックがあります。
+ **アプリケーションの互換性検証:** ユーザーが依存する機能全体で、ストリーミング環境でアプリケーションが正しく動作することを確認します。
+ **インスタンスのサイズ設定と容量計画:** アプリケーションの CPU、メモリ、GPU プロファイルと予想される同時ユーザー数に一致するインスタンスタイプとフリートスケーリングポリシーを選択します。

まず (Image Builder とパイロットフリートで) 互換性検証を完了し、その検証の測定値を使用してインスタンスのサイズ決定を行うことをお勧めします。

## パート 1: アプリケーションの互換性の検証
<a name="onboarding-compatibility"></a>

### 一般的な互換性
<a name="onboarding-general-compat"></a>

WorkSpaces Applications は、次の順序でストリーミングセッションを確立します。

1. ユーザーのクライアントがストリーミングインスタンスに接続します。

1. ユーザーはインスタンスのサーバーオペレーティングシステムセッションにログインします。

1. アプリケーションが開始されます。

1. ストリーミングセッションが開始され、クライアントに依存する環境設定 (クライアントディスプレイ解像度、DPI、クライアントタイムゾーン、プリンターなどのクライアントリダイレクトデバイスなど) が適用されます。

クライアント依存の環境設定はアプリケーションの起動*後に*適用されるため、起動時にこれらの値を 1 回だけ読み取るアプリケーションは、ユーザーの実際のクライアント設定に反応しません。以下を確認してください。
+ アプリケーションは、起動後に解像度、DPI、タイムゾーンの変更を表示するために読み取りまたはサブスクライブ**するか**、クライアントが接続する前にユーザー母集団に一致するデフォルトを使用してストリーミングインスタンスを設定します。
+ アプリケーションは、ユーザーのローカルタイムゾーンがストリーミングインスタンスのタイムゾーンと異なることを許容します。
+ クライアントがセッション中に切断して再接続しても、アプリケーションは失敗またはハングしません。

### マルチセッションの互換性
<a name="onboarding-multi-session-compat"></a>

マルチセッションフリートでアプリケーションを実行する場合は、Image Builder と 2 人以上の同時ユーザーを持つパイロットフリートで以下を検証します。
+ アプリケーションのライセンスは、単一のサーバーインスタンスでの同時マルチユーザーセッションを許可します。一部のアプリケーションのデバイス単位またはユーザー単位のライセンスでは、この設定を明示的に禁止しています。
+ ユーザープロファイル、アプリケーション設定、ユーザーデータはセッション間で分離されます。あるユーザーが行った変更が別の同時ユーザーには表示されないことをテストします。
+ ユーザー固有のデータは、 `%APPDATA%`や などの共有ディレクトリではなく`%LOCALAPPDATA%`、 などのユーザーごとの場所に書き込まれ`C:\Program Files`ます`C:\ProgramData`。
+ アプリケーションは、すべてのセッションで共有されるシステムサービスに依存していないか、そのようなサービスが複数の同時セッションを正しく処理できます。
+ アプリケーションには、シングルユーザー環境を引き受けるハードコードされたパスは含まれていません。
+ システムデバイスダイアログは、スキャナーやプリンターなど、現在のユーザーのリダイレクトされたデバイスのみを列挙します。サーバーに表示されるすべてのデバイスではありません。
+ ファイルを開いてダイアログを保存すると、現在のユーザーのマッピングされたクライアントドライブとリダイレクトされたフォルダが正しく解決されます。
+ アプリケーションのインストーラ、アップデーター、およびバックグラウンドプロセスでは、ユーザーがサインインしている間にインタラクティブな管理者アクセスは必要ありません。

**注記**  
マルチセッションフリートは現在、ウェブカメラ、[動的アプリケーションフレームワーク](https://docs.aws.amazon.com/appstream2/latest/developerguide/dynamic-app-framework.html)、[スマートカード認証](https://docs.aws.amazon.com/appstream2/latest/developerguide/active-directory-prerequisites-smart-card-authentication.html)をサポートしていません。これらの機能のいずれかが必要な場合は、単一セッションフリートを使用することをお勧めします。

### ネイティブアプリケーションモードの互換性
<a name="onboarding-native-app-mode"></a>

ネイティブアプリケーションモードでは、各リモートアプリケーションをユーザーのローカルデバイスで個別のウィンドウとしてストリーミングし、独自のタスクバーアイコンを使用します。クラシックモードで正しく動作するアプリケーションは、ウィンドウ管理、フォーカス、レンダリングの処理が異なるため、ネイティブアプリケーションモードでは動作が異なる場合があります。機能の概要については、[「ネイティブアプリケーションモード](https://docs.aws.amazon.com/appstream2/latest/developerguide/feature-support-native-application-mode.html)」を参照してください。

Image Builder とパイロットフリートのネイティブアプリケーションモードで以下を検証します。
+ **ウィンドウ表示:** ダイアログ、スプラッシュ画面、モーダルプロンプトを含むすべてのアプリケーションウィンドウが正しく表示され、操作できます。標準の Windows UI ツールキット (たとえば、カスタムレンダリングされたスプラッシュ画面や、メインウィンドウの前に表示される起動ダイアログ) を使用するのではなく、手動で描画されるウィンドウに特に注意してください。これらは互換性の問題がある可能性が高くなります。
+ **透明または非長方形ウィンドウ:** 透明エリアがあるウィンドウ、または丸いまたは非長方形の形状のウィンドウ (バルーンチップ、カスタムツールチップ、スキンウィンドウなど) がないか確認します。ネイティブアプリケーションモードでは正しくレンダリングされない場合があります。
+ **システムトレイ:** Windows 通知エリア (システムトレイ) を必要とするアプリケーションは現在、ネイティブアプリケーションモードではサポートされていません。アプリケーションでセカンダリ機能にのみトレイアイコンを使用している場合は、トレイが使用できないときにコアワークフローが引き続き機能することを確認します。
+ **DPI 対応:** ストリーミングセッションは、ローカルクライアントとは異なる解像度と DPI 設定で実行される場合があります。アプリケーションが DPI 対応でない場合、Windows 自体が出力をスケーリングするため、レンダリングがぼやけます。100% 以外の DPI スケーリング (たとえば、125% または 150% の高 DPI ラップトップ) を使用する少なくとも 1 つのクライアントでテストします。
+ **マルチウィンドウワークフロー:** 複数のアプリケーションウィンドウにまたがるワークフローをテストします (たとえば、メインウィンドウとモーダルダイアログを切り替える、または別々のウィンドウで開いた 2 つのドキュメントを切り替える）。フォーカスの移行とタスクバーのclick-to-activateまでが期待どおりに動作することを確認します。
+ **Alt\+Tab とタスクバーの動作:** Alt\+Tab を使用し、タスクバーアイコンをクリックして、アプリケーションと他のローカルアプリケーションの間で切り替えます。リモートアプリケーションは、無関係なリモートウィンドウを持たずにフォアグラウンドに来る必要があります。
+ **モーダルダイアログ:** リモートアプリケーションでモーダルダイアログが開いている場合、基になるリモートウィンドウはモーダルが無効になっていることを正しく示し、モーダルをクリックするとモーダルがフラッシュまたはアクティブ化されます。
+ **印刷ワークフロー:** アプリケーション内から印刷し、印刷ダイアログが表示されていること (メインウィンドウの背後に非表示になっていないこと）、リダイレクトされたプリンターが列挙されていることを確認します。一部のプリンタードライバーに表示される印刷ダイアログは、間違ったウィンドウにアタッチされる可能性があります。このような場合は、Microsoft Print to **PDF の代わりに DCV PDF プリンター**を使用することを検討してください。 ****
+ **ブラウザタブのドッキング:** ユーザーがネイティブアプリケーションモードでストリーミングセッション中に 1 つのブラウザウィンドウのタブを別々のウィンドウにドッキングまたはドッキング解除しようとすると、リモートストリーミングブラウザはローカルブラウザと同じように動作しません。タブが別々のブラウザウィンドウにドッキングされるまで、ユーザーは Alt キーを押す必要があります。ユーザーが頻繁なタブのドッキング解除に依存している場合は、この動作のユーザートレーニングを計画します。
+ **モード切り替え:** セッション中にユーザーがネイティブアプリケーションモードとクラシックモードを切り替えると、アプリケーションが引き続き機能することをテストします。

完全なデプロイの前に、パイロットユーザーグループを使用してネイティブアプリケーションモードの検証を開始し、アプリケーション固有の制限を文書化することをお勧めします。アプリケーションの動作とパフォーマンスはストリーミングモードによって異なる可能性があるため、クラシックモードでのテストはネイティブアプリケーションモードでのテストに代わるものではありません。

### ファイル処理とリダイレクト
<a name="onboarding-file-handling"></a>
+ マップされたクライアントドライブとリダイレクトされたフォルダとの間でファイルを開いて保存します。
+ アプリケーションが一時ファイルを使用する場合は、ユーザーごとの一時ディレクトリに書き込まれていることを確認します。
+ ユーザーがストリーミングセッションで処理される一般的なサイズより大きいファイルを扱う場合は、セッションのファイル転送メカニズムでラージファイルオペレーションをテストします。

### 印刷
<a name="onboarding-printing"></a>
+ ユーザーが使用するリダイレクトされたプリンタータイプ (ネットワークプリンター、Microsoft Print to PDF、DCV PDF プリンターなどの PDF プリンタードライバー、サードパーティーのリダイレクトされたプリンター) ごとに印刷をテストします。
+ ウェブコンテンツを埋め込むアプリケーション (Chromium ベースのビューなど) を含め、印刷ワークフローを持つ各アプリケーションからの印刷をテストします。
+ ネイティブアプリケーションモードで印刷ダイアログの動作を検証します (前のセクションを参照）。

### ローカルデバイスのやり取り
<a name="onboarding-local-devices"></a>
+ オーディオ入出力 (マイク、スピーカー、ヘッドセット）。
+ アプリケーションで使用される場合はウェブカメラ。
+ アプリケーションで使用される場合、USB デバイスリダイレクト。サポートされている[デバイスのリストについては、「USB デバイスリダイレクト](https://docs.aws.amazon.com/appstream2/latest/developerguide/feature-support-USB-devices-qualified.html)」を参照してください。
+ アプリケーションで必要な場合は、スマートカード認証。

### ネットワークパフォーマンス
<a name="onboarding-network-perf"></a>
+ 最悪の場合のユーザーを表すネットワーク接続 (往復時間が 100 ミリ秒のコンシューマーブロードバンド接続のリモートユーザーなど) でのアプリケーションの応答性を測定します。ストリーミングセッションは、ラウンドトリップ時間とパケット損失の影響を受けます。
+ アプリケーションが短時間のネットワーク中断とセッションの再接続を許容していることを確認します。

### マルチモニターのサポート
<a name="onboarding-multi-monitor"></a>
+ クライアント側で複数のモニターにまたがるワークフローをテストします。
+ アプリケーションがモニタージオメトリを読み取る場合は、ストリーミングインスタンスのレイアウトではなく、クライアントのモニターレイアウトを読み取ることを確認します。

### オーディオおよびビデオ機能
<a name="onboarding-audio-video"></a>

リアルタイムのオーディオビデオシナリオ (音声、ビデオ会議、コラボレーションツールがアプリケーションに埋め込まれている) では、フレームレートが高く、より大きなインスタンスタイプが必要になる場合があります。「[パート 2: インスタンスのサイズ設定と容量計画](#onboarding-sizing)」を参照してください。

### 検証環境
<a name="onboarding-validation-env"></a>

このセクションのチェックは、まず Image Builder で実行し、次に少数の代表的なユーザーグループを持つパイロットフリートで実行してから、イメージを完全なユーザーベースにロールアウトします。native-application-modeテストに依存しないでください。

## パート 2: インスタンスのサイズ設定と容量計画
<a name="onboarding-sizing"></a>

### インスタンスファミリーを選択する
<a name="onboarding-instance-family"></a>

アプリケーションのリソースプロファイルに基づいてインスタンスファミリーを選択します。ハードウェアの仕様と料金については、[WorkSpaces アプリケーションインスタンスファミリー](https://docs.aws.amazon.com/appstream2/latest/developerguide/instance-types.html)」と[WorkSpaces アプリケーションの料金](https://aws.amazon.com/appstream2/pricing/)」を参照してください。


| アプリケーションプロファイル | 推奨されるインスタンスファミリー | 
| --- | --- | 
| オフィス、ウェブブラウザ、ほとんどのline-of-businessアプリケーション | 汎用 | 
| コンピューティングバウンドアプリケーション (クライアント側の計算負荷が高い、ローカル分析) | コンピューティング最適化 | 
| メモリを大量に使用するアプリケーション (メモリ内の大規模なデータセット、メモリ内データベース) | メモリを最適化 | 
| DirectX、OpenGL、または OpenCL を使用したグラフィックスアプリケーション | Graphics G4dn、G5、または G6 ファミリー | 
| フレームhigh-frame-rateシナリオ向けのリアルタイムのオーディオビデオ | 選択したファミリー内のインスタンスサイズをスケールアップします。アプリケーションが GPU アクセラレーションも使用している場合は、Graphics ファミリーインスタンスを検討してください。 | 

各 WorkSpaces アプリケーションインスタンスには 200 GB の固定サイズの C ドライブがあり、各ユーザーセッション後に削除されます。ユーザーデータにはインスタンスローカルストレージに依存しないでください。永続化にはホームフォルダ、ファイル共有、またはプロファイル管理を使用します。

### 単一ユーザーのインスタンスのサイズ設定
<a name="onboarding-single-user-sizing"></a>

同時ユーザーのサイジングを行う前に、1 つのセッションでのアプリケーションのリソース使用量を測定します。
+ 選択したファミリー内で、アプリケーションの記述された最小要件を満たす最小インスタンスサイズの Image Builder をプロビジョニングします。
+ 単一のユーザーとしてサインインし、代表的なワークロードをエンドツーエンドで実行します。ストリーミングセッションで実行されるすべての依存関係 (バックグラウンド同期クライアント、セキュリティエージェント、プロファイル管理クライアントなど) を含めます。
+ Windows Performance Monitor または同等のツールを使用して、ピーク時および持続的な CPU 使用率、ピーク時および持続的なワーキングセット (プライベートバイト) メモリ使用率、ディスク I/O レート、および該当する場合は GPU 使用率とビデオメモリを測定します。
+ 通常のワークフロー中にピーク CPU が約 80% を超えるか、ピークメモリがインスタンス容量の約 75% を超える場合は、次のインスタンスサイズに移動します。
+ Windows Server オペレーティングシステム、WorkSpaces Applications エージェント、Amazon DCV、マルウェア対策、およびその他の管理エージェントのヘッドルームを残します。経験則は、単一セッションインスタンスの基本システムオーバーヘッド用に約 1 vCPU と 1 GB のメモリを予約することです。

### マルチセッションフリートのサイズ
<a name="onboarding-multi-session-sizing"></a>

マルチセッションフリートは、単一の Windows Server インスタンスで複数のユーザーを同時に実行します。インスタンスごとにサポートされる最大ユーザーは、アプリケーションのインスタンスサイズとリソースプロファイルによって異なります。
+ シングルユーザー測定 (前のセクション) から開始します。
+ アプリケーションの動作に基づいて同時実行乗数を適用します。主にアイドル状態のリソースプロファイルを持つアプリケーション (インタラクティブに使用されるオフィスアプリケーションなど) の場合、CPU とメモリの集計使用量を計画して、ユーザー数に合わせてほぼ直線的にスケールしますが、OS オーバーヘッドが共有されるため 20～30% 削減されます。常にアクティブなリソースプロファイルを持つアプリケーション (データ処理ツールや重いウェブアプリケーションを実行しているブラウザなど) の場合、縮小することなくほぼ線形のスケーリングを計画します。
+ インスタンスあたりの候補最大ユーザー数を次のように計算します。

```
max_users_per_instance = min(
    (instance_vcpus - 1) / peak_single_user_vcpus_under_concurrency,
    (instance_memory_gb - 1) / peak_single_user_memory_gb_under_concurrency
)
```
+ 実際のマルチセッションパイロットで候補値を検証します。同時ユーザーの候補数 (負荷生成ツールや実際のパイロットユーザーなど) を使用してテストを実行します。CPU 使用率 (ターゲットがピーク 80% 未満、持続が 70% 未満）、使用可能なメモリ (ターゲットがピーク時の合計の 15% 超）、ディスクキューの長さ (ターゲットが持続が 2 未満）、DCV セッションの応答性 (主観的 — セッションはインタラクティブですか?) をモニタリングします。
+ パイロットがこれらのターゲットのいずれかに失敗した場合は、インスタンスあたりの最大ユーザー数を 1 つ減らして再テストします。パイロットが快適に合格した場合、インスタンスあたりの最大ユーザー数を 1 つ増やして再テストしたり、ワークロードの急増に備えて余裕を残したりできます。

### フリートスケーリングを設定する
<a name="onboarding-fleet-scaling"></a>

インスタンスあたりの最大ユーザー数がわかったら、時間の経過とともに予想される同時ユーザー数に基づいてフリートスケーリングを設定します。完全なメカニズムについては、[「Fleet Auto Scaling for WorkSpaces Applications](https://docs.aws.amazon.com/appstream2/latest/developerguide/autoscaling.html)」を参照してください。このセクションでは、オンボーディングの一環として行う必要がある決定事項をまとめます。
+ **最小容量。**営業時間中に予想される同時ユーザー数をインスタンスあたりのユーザー数で割ったものに基づいて設定します。プロビジョニングにはインスタンスあたり数分かかるため、最小容量が 0 または値が低すぎると、ユーザーは平日の開始時にインスタンスの起動を待つ可能性があります。予測可能な午前のランプアップについては、**スケジュールされたスケーリングポリシー**を使用して、作業日が始まる前に最小容量を増やし、作業日が終了する前に減らします。
+ **最大容量。**ピーク時の同時ユーザー数と安全マージンを考慮した上限に設定します。ピークは通常、営業時間の平均の 1.2～1.5 倍ですが、これを正確に設定するために独自のトラフィックを測定します。
+ **ターゲット使用率。**予測不可能な需要を持つフリートの場合は、**ターゲット追跡スケーリングポリシー**を使用します。15 分以内に予想されるユーザー回転率 (解約) `100% - target utilization`を超えるターゲット使用率を選択します。たとえば、ユーザーの 10% が 15 分以内にセッションを開始および終了する場合、ターゲットを 90% 以下に設定してください。詳細については、ホワイトペーパーの[「スケーリングポリシー設計のベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/best-practices-for-deploying-amazon-appstream-2/best-practices-for-scaling-policy-design.html)」を参照してください。
+ **InsufficientCapacityError アラーム。**各フリートの `InsufficientCapacityError`メトリクスに Amazon CloudWatch アラームを作成して、自動スケーリングが需要に追いついていない場合に管理者に警告されるようにします。

### パイロットによるend-to-endの検証
<a name="onboarding-pilot"></a>

アプリケーションをすべてのユーザーにロールアウトする前に、少なくとも 1 営業日、10～50 人のユーザーでパイロット版を実行します。パイロット中:
+ パート 1 のアプリケーションの互換性検証結果が実際のユーザーワークロードで保持されていることを確認します。
+ 選択したインスタンスサイズが、インスタンスごとに観測されたピーク同時ユーザーをサポートしていることを確認します。
+ フリートスケーリングポリシーが`InsufficientCapacityError`、イベントなしでstart-of-dayのランプとend-of-dayランプダウンを処理することを確認します。
+ パイロットユーザーからセッションの応答性とアプリケーションの動作に関するフィードバックを収集します。

## オンボーディングチェックリスト
<a name="onboarding-checklist"></a>

このチェックリストを使用して、オンボーディングする各アプリケーションのステータスを追跡します。

**アプリケーションの互換性**
+ アプリケーションライセンスは、意図したデプロイ (シングルセッションまたはマルチセッション、同時ユーザー) を許可します。
+ 一般的な互換性チェックに合格します (アプリケーション起動後にクライアント依存の設定が適用されます）。
+ マルチセッション互換性チェックに合格します (マルチセッションフリートをターゲットにしている場合）。
+ ネイティブアプリケーションモードチェックの合格 (ウィンドウ、ダイアログ、トレイ、DPI、フォーカス、印刷、モード切り替え）。
+ ファイル処理とリダイレクトチェックは合格です。
+ ユーザーが使用するすべてのリダイレクトされたプリンタータイプに対して検証された印刷ワークフロー。
+ ユーザーが使用するすべてのデバイスに対して検証されたローカルデバイスインタラクション (オーディオ、ウェブカメラ、USB、スマートカード）。
+ マルチモニターワークフローが検証されました。

**インスタンスのサイズ設定と容量**
+ アプリケーションリソースプロファイルに基づいて選択されたインスタンスファミリー。
+ Image Builder で測定されるシングルユーザーリソースの使用。
+ マルチセッションパイロットで計算および検証されたインスタンスあたりの最大ユーザー数 (該当する場合）。
+ 設定されたフリートスケーリングポリシー (最小容量、最大容量、ターゲット使用率、またはスケジュールされたスケーリング）。
+ `InsufficientCapacityError` アラームが設定されました。

**パイロットとロールアウト**
+ 少なくとも 1 営業日、10～50 人のユーザーによるパイロット実行。
+ パイロットフィードバックのレビューとブロックの問題の解決。
+ エンドユーザートレーニング用に文書化されたアプリケーション (Alt キーを介したブラウザタブドッキングなどのネイティブアプリケーションモードの既知の動作を含む）。
+ ステークホルダーと合意したロールアウト計画。