フリートの自動スケーリング戦略

AppStream 2.0 インスタンスを理解する

AppStream 2.0 フリートインスタンスは、ユーザーとフリートインスタンスの比率が 1:1 です。つまり、各ユーザーは独自のストリーミングインスタンスを持っているということです。同時に接続するユーザーの数によって、フリートのサイズが決まります。

スケーリングポリシー

AppStream 2.0 フリートは、Application Auto Scaling グループで起動されます。これにより、使用状況に基づいてフリートをスケーリングして需要を満たすことができます。使用量が増えるとフリートはスケールアウトし、ユーザーが接続を解除するとフリートはスケールインします。これはスケーリングポリシーを設定することで制御されます。スケジュールされたスケーリング、ステップスケーリングポリシー、およびターゲット追跡スケーリングポリシーを設定できます。これらのスケーリングポリシーの詳細については、「Amazon AppStream 2.0 の Fleet Auto Scaling」を参照してください。

ステップスケーリング

これらのポリシーは、フリートのキャパシティを現在のフリートサイズまたは特定のインスタンス数に対するパーセンテージで増減します。ステップスケーリングポリシーは、Capacity Utilization、Available Capacity、または Insufficient Capacity Errors の AppStream 2.0 CloudWatch メトリクスによってトリガーされます。

ステップスケーリングポリシーを使用する場合、AWS では、固定数のインスタンスではなく、一定の割合のキャパシティを追加することを推奨します。これにより、スケーリングアクションがフリートの規模に比例するようになります。これにより、(フリートのサイズに対して追加したインスタンスの数が少ないことで) スケールアウトが遅すぎたり、フリートが小さいときにインスタンス数が多すぎる状況を回避できます。

ターゲット追跡

このポリシーでは、フリートに対するキャパシティの使用レベルを指定します。Application Auto Scaling は、スケーリングポリシーをトリガーする CloudWatch アラームを作成および管理します。これにより、指定されたターゲット値、またはそれに近い値にフリートを維持するためにキャパシティを追加または削除します。アプリケーションの可用性を高めるために、フリートのスケールアウトはメトリクスに比例して可能な限り高速に行われますが、スケールインはより緩やかです。ターゲット追跡を設定するときは、スケールアウトとスケールインが希望の間隔で行われるようにスケーリングのクールダウンを考慮してください。

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

スケジュールベースのスケーリング

これらのポリシーにより、時間ベースのスケジュールに基づいて希望するフリートキャパシティを設定できます。このポリシーは、ログインの動作を理解し、需要の変化を予測できる場合に有効です。

例えば、勤務日の最初に、100 名のユーザーが 午前 9 時にストリーミング接続をリクエストすることが予期されるとします。この場合、スケジュールベースのスケーリングポリシーを設定して、午前 8 時 40 分に最小フリートサイズを 100 に設定できます。これにより、フリートインスタンスを作成して勤務日の開始時に使用可能になることで、100 人のユーザーが同時に接続できます。その後、午後 5 時にフリートを少なくとも 10 人にスケーリングするようにスケジュールされた別のポリシーを設定できます。これにより、勤務時間外のセッションの需要が勤務時間中よりも少なくなるため、コストを節約できます。

本番環境におけるスケーリングポリシー

さまざまな種類のスケーリングポリシーを 1 つのフリートにまとめることで、ユーザーの行動に合わせた正確なスケーリングポリシーを定義できます。前の例では、スケジュールされたスケーリングポリシーをターゲット追跡またはステップスケーリングポリシーと組み合わせて、特定のレベルの使用率を維持できます。スケジュールされたスケーリングとターゲット追跡スケーリングの組み合わせにより、キャパシティがすぐに必要になったときに、使用率レベルの急激な増加による影響を軽減できます。

スケーリングポリシーによって必要なインスタンス数が変更されても、ストリーミングセッションに接続しているユーザーは、スケールインやスケールアウトの影響を受けません。スケーリングポリシーによって既存のストリーミングセッションが終了することはありません。既存のセッションは、ユーザーまたはフリートタイムアウトポリシーによってセッションが終了されるまで、中断されずに継続されます。

CloudWatch メトリクスで AppStream 2.0 の使用状況をモニタリングすると、スケーリングポリシーを時間の経過とともに最適化するのに役立ちます。例えば、初期設定時にリソースを過剰にプロビジョニングすることは一般的で、使用率が低い状態が長期間続くことがあります。あるいは、フリートのプロビジョニングが不足していると、キャパシティ使用率が高くなり、「容量の不足」というエラーが表示されることがあります。CloudWatch メトリクスを確認すると、スケーリングポリシーを調整してこれらのエラーを軽減するのに役立ちます。詳細および使用できる AppStream 2.0 スケーリングポリシーの例については、「Amazon AppStream 2.0 フリートをスケーリングする」を参照してください。