# フリートのカスタマイズ
<a name="fleet-customization"></a>

## フリートタイプ
<a name="fleet-type"></a>

フリートを作成する場合、カスタマーはフリートタイプを選択する必要があります。フリートタイプごとに、ユーザーエクスペリエンス、コスト、メンテナンスの諸経費の面で異なるメリットがあります。選択したフリートタイプにかかわらず、各オプションは Windows と Linux の両方のプラットフォームタイプ、およびデスクトップビューまたはアプリケーションビューをサポートします。

カスタマーは次のフリートタイプから選択できるようになりました。
+  **常時オン** — ユーザーがアプリケーションに瞬時にアクセスできるようにします。アプリケーションをストリーミング中のユーザーがいない場合でも、フリート内の実行中のすべてのインスタンスに対して料金が発生します。
+  **オンデマンド** — ストリーミングコストを最適化するには、このフリートタイプを選択します。オンデマンドフリートでは、ユーザーのセッションの開始時間は約 1 ～ 2 分です。ただし、ストリーミングインスタンス料金は、ユーザーが接続しているときにのみ請求され、アプリをストリーミングしていないフリート内の各インスタンスには、時間単位の少額の料金がかかります。
+  **Elastic** — Elastic フリートはインストールが不要なアプリケーションに使用でき、仮想ハードディスク (VHD) から実行できます。Elastic フリートは WorkSpaces Applications イメージをサポートしておらず、スケーリングポリシーも必要ありません。課金されるのは、ストリーミングセッションの期間中のみ。

 

*表 2 – Amazon WorkSpaces Applications フリートのタイプ*


| フリートタイプ | どのようなときに使うか | ユーザーエクスペリエンス |  料金モデル | 注意事項  | 
| --- | --- | --- | --- | --- | 
|  **常時オン**  | ユーザーはセッションを開始するとすぐにアプリケーションにアクセスする必要がある。使用パターンが予測可能で、スケーリングポリシーによってコストを確実に管理できるため、フリートのキャパシティが過剰になることがない。 | アプリケーションへの即時アクセス | (セッションに使用されているかどうかに関係なく) フリートで使用可能なすべてのインスタンスに対して全額を支払う。 | カスタムイメージポリシーとスケーリングポリシーをサポートしている。 | 
|  **オンデマンド**  | フリートには相当な超過キャパシティを維持する必要がある。最もコストが最適化された環境が必要で、未使用のキャパシティに対して全額を支払うのは避けたい。ユーザーは、セッションの開始後、アプリケーションにアクセスできるようになるまで 1 ～ 2 分待つことができる。サイズの大きいインスタンスタイプを使用している。実行中のインスタンスの 1 時間あたりのコストは、停止したインスタンス料金よりもはるかに高くなる。 | ユーザーは、セッションを開始してからアプリケーションにアクセスするまで 1 ～ 2 分待機する。 | セッションがアクティブなストリーミングインスタンスに対してのみ全額を支払い、アイドル状態のインスタンスには 1 時間あたりの少額の料金を支払う。 | カスタムイメージポリシーとスケーリングポリシーをサポートしている。 | 
|  **Elastic**  | アプリケーションとその依存関係は最大 1.5 GB 未満である。ユーザーが Elastic フリートでセッションを開始するたびに、仮想ハードディスク (VHD) ファイルを Amazon S3 からセッションにダウンロードする必要がある。その結果、VHD ファイルが大きくなる (つまり、サイズが 1.5 GB を超える) と、エンドユーザーエクスペリエンスが低下する。アプリケーションはポータブルである。そのため、アプリケーションとそのすべての依存関係を VHD に配置し、VHD から起動できる。ドメインに参加したストリーミングインスタンスが必要ない (現在、Elastic フリートではドメイン参加はできません)。アクティブなセッションに対してのみ料金を支払いたい (つまり、フリートの未使用のキャパシティについては支払いを行わない)。ユーザーは、セッション開始後、アプリケーションにアクセスするまで 45 秒以上待つことができる。スケーリングは AWS に管理してもらいたい (管理対象のスケーリングポリシーがない)。 | セッションの開始後、ユーザーはアプリケーションにアクセスするまで 45 秒から 3 分待機する (待機時間は仮想ハードディスクのサイズによって異なる)。 | 課金されるのは、ストリーミングセッションの期間中のみ。Elastic フリートにはアイドル状態のインスタンスという概念がないため、未使用のインスタンスに対しては課金されない。 | カスタムイメージ (カスタマーがアプリケーションと共に VHD を提供) やスケーリングポリシーはサポートしていません。現在 `stream.standard.small`、`stream.standard.medium` インスタンスをサポートしています。ユースケースで別のインスタンスタイプが必要な場合は、AWS アカウントチームにお問い合わせください。 | 

![フリートタイプのユースケースと要件を示す図。](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/best-practices-for-deploying-amazon-appstream-2/images/use-case-and-requirements.png)


## フリートのサイズ設定
<a name="fleet-sizing"></a>

### 最小キャパシティとスケジュールされたスケーリング
<a name="minimum-capacity-and-scheduled-scaling"></a>

 WorkSpaces Applications フリートの規模を決定する際には、ユーザーエクスペリエンスとコストに直接影響する考慮事項がいくつかあります。**[最小キャパシティ]** に値を入力することで、WorkSpaces Applications インスタンスの数は、この値を下回ることがほとんどなくなります。WorkSpaces Applications セッションが終了した後、WorkSpaces Applications インスタンスの合計が **[最小キャパシティ]** 値を下回ると、新しいフリートインスタンスが開始されます。ここでも重要なのは、1 つの WorkSpaces Applications インスタンスは 1 つのユーザーセッションに直接マップされ、**[最小キャパシティ]** 値に直接影響することを覚えておくことです。

 **[最小キャパシティ]** に予想される同時実行数を超える値を入力すると、コストは増加しますが、ユーザーエクスペリエンスには影響しません。値が低すぎる場合、コストは減少しますが、リクエストの合計が利用可能なキャパシティを超えるとユーザーエクスペリエンスに影響します。このような状況では、管理者は「容量の不足不足」エラーが発生することに気付くでしょう。例えば、1 日の開始時に予想される接続数が予測可能な一定値であれば、`PendingCapacity` が `AvailableCapacity` になるのを待つのは、ユーザーの時間を効率的に使用していません。

 通常のオフピーク時間に対応できる最小キャパシティから開始し、[https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)を使用して、勤務日の開始前に最小キャパシティを効果的にリセットします。[最小キャパシティ] をオフピーク時間に戻すために、必ずスケジュールされたスケーリングポリシーをもう 1 つ作成してください。スケーリングポリシーとその実装方法の詳細については、このドキュメントの「[*フリートの自動スケーリング戦略*](fleet-auto-scaling-strategies.md)」セクションを参照してください。

### 最大キャパシティとサービスクォータ
<a name="maximum-capacity-and-service-quotas"></a>

 最大キャパシティには任意の値を設定すれば良いように思うかもしれませんが、適切に予測して設定すれば、リソースの総消費量とコストを最適化できます。入力された値が AWS アカウントの [https://docs.aws.amazon.com/appstream2/latest/developerguide/limits.html](https://docs.aws.amazon.com/appstream2/latest/developerguide/limits.html)よりも大きい値を入力しても有効であるように思えますが、自動スケーリングイベントがリソースを最大キャパシティにスケールしようと試みると、最大キャパシティの値が利用可能なサービスクォータを超えているため、起動に失敗します。組織の予想どおりに自動スケーリングが機能するようには、希望する最大キャパシティでサービスクォータをリクエストしてください。

 [最大キャパシティ] の値を設定する際のもう 1 つの重要な考慮事項は、コストです。詳細については、本書の「[*フリートタイプの選択によるコストの最適化*](cost-optimization.md#optimizing-costs-with-fleet-type-choice)」セクションを参照してください。