スケーリングポリシー設計のベストプラクティス

スケーリングポリシーを組み合わせる

多くのカスタマーは、AppStream 2.0 の自動スケーリングの能力と柔軟性を高めるために、さまざまな種類のスケーリングポリシーを 1 つのフリートにまとめることを選択しています。例えば、スケジュールされたスケーリングポリシーを設定し、ユーザーが仕事を始めるのを見越して午前 6 時にフリートの最小値を増やし、ユーザーが仕事を停止する前の午後 4 時にフリートの最小値を減らすようにできます。このスケジュールされたスケーリングポリシーをターゲット追跡ポリシーまたはステップスケーリングポリシーと組み合わせて特定の使用率を維持し、使用量が急増した場合は日中にスケールインまたはスケールアウトすることができます。スケジュールされたスケーリングとターゲット追跡スケーリングを組み合わせることで、急に容量が必要になったときに、使用率レベルの急激な増加による影響を軽減できます。

スケーリングチャーンを回避する

ユースケースによってフリートのチャーン率が高くなる可能性があるかどうかを検討してください。チャーンは、多数のユーザーが短期間にセッションを開始し、その後終了したときに発生します。これは、多数のユーザーがサインオフする前に、フリート内のアプリケーションにわずか数分間に同時アクセスした場合に発生する可能性があります。

このような状況では、ユーザーがセッションを終了するとインスタンスも終了するため、フリートのサイズが希望するキャパシティをはるかに下回る可能性があります。ステップスケーリングポリシーでは、チャーンを相殺するほど迅速にインスタンスを追加できず、その結果、フリートが一定のサイズにとどまってしまうことがあります。

チャーンは、フリートの CloudWatch メトリクスを調べることで特定できます。フリートの保留中のキャパシティが 0 以外で、希望するキャパシティに変更がない (またはほとんど変更がない) 期間は、高いチャーンが発生している可能性が高いことを示しています。チャーン率が高い状況を考慮に入れるには、ターゲット追跡スケーリングポリシーを使用し、(100 — ターゲット使用率) が 15 分間のチャーン率を上回るようにたターゲット使用率を選択します。例えば、ユーザーの解約によって 15 分以内にフリートの 10% が終了する場合は、高いチャーンを相殺するためにキャパシティのターゲット使用率を 90% 以下に設定します。

最大プロビジョニング率を理解する

多数のユーザーを対象に AppStream 2.0 フリートを管理しているカスタマーは、プロビジョニング率の制限を検討する必要があります。この制限は、インスタンスを 1 つのフリートに、または AWS アカウント 内のフリートすべてに追加できる速度に影響します。

考慮すべき制限は 2 つあります。

• 単一のフリートの場合、AppStream 2.0 は 1 分あたり最大 20 インスタンスのレートでプロビジョニングします。

• 単一の AWS アカウント の場合、AppStream 2.0 は 1 分あたり 60 インスタンス (バーストは 1 分あたり 100 インスタンス) のレートでプロビジョニングします。

3 つ以上のフリートを並行してスケールアップする場合、アカウントのプロビジョニング率の制限はこれらのフリートで共有されます (例えば、6 つのフリートを並行してスケーリングすると、それぞれ 1 分あたり最大 10 インスタンスをプロビジョニングできます)。また、特定のストリーミングインスタンスがスケーリングイベントに応じてプロビジョニングを完了するまでの時間を考慮します。Active Directory ドメインに参加していないフリートの場合、通常 15 分です。Active Directory ドメインに参加しているフリートの場合、これには 25 分ほどかかることがあります。

これらの制限を考慮し、次の例について検討してみましょう。

• 1 つのフリートを 0 インスタンスから 1000 インスタンスにスケーリングする場合、プロビジョニングが完了するまでに 50 分 (1000 インスタンス/1 分あたり 20 インスタンス) かかり、エンドユーザーがすべてのインスタンスを使用できるようになるまでにさらに 15 ～ 25 分、合計 65 ～ 75 分かかります。

• 3 つのフリートを 0 インスタンスから 333 インスタンスに同時にスケーリングする場合、すべてのフリートがプロビジョニングを完了するまでに 17 分 (999 インスタンス/1 分あたり 60 インスタンス) かかり、エンドユーザーがこれらすべてのインスタンスを使用できるようになるまでにさらに 15 分、合計 32 ～ 42 分かかります。

複数のアベイラビリティーゾーンを使用する

フリートをデプロイするリージョン内の AZ を複数選択します。フリートに複数の AZ を選択すると、フリートはスケーリングイベントに対応してインスタンスを追加できる可能性が高くなります。CloudWatch メトリクス PendingCapacity は、大規模なフリートデプロイにおいてフリート AZ の設計がどの程度最適化されているかを評価するため、最初にチェックします。PendingCapacity の値が持続的に高い場合、水平スケーリングを (AZ 全体に) 拡張する必要性を示している場合があります。詳細については、「Amazon AppStream 2.0 リソースのモニタリング」を参照してください。

例えば、自動スケーリングがインスタンスをプロビジョニングしてフリートのサイズを増やそうとしたときに、選択した AZ のキャパシティが不足している場合、自動スケーリングは代わりにフリートに指定した他の AZ にインスタンスを追加します。アベイラビリティーゾーンと AppStream 2.0 設計の詳細については、本ドキュメントの「アベイラビリティーゾーン」を参照してください。

キャパシティ不足エラーのメトリクスをモニタリングする

「キャパシティ不足エラー」は AppStream 2.0 フリートの CloudWatch メトリクスです。このメトリクスは、キャパシティ不足により拒否されたセッションリクエストの数を指定します。

スケーリングポリシーを変更する場合、キャパシティ不足エラーが発生したときに通知する CloudWatch アラームを作成すると便利です。これにより、スケーリングポリシーをすばやく調整してユーザーの可用性を最適化できます。管理ガイドには、AppStream 2.0 リソースをモニタリングする詳細な手順が記載されています。