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

モニタリング

ダッシュボードの使用

フリート使用率のモニタリングは、CloudWatch メトリクスとダッシュボードの作成により実行できる定期的なアクティビティです。または、AppStream 2.0 コンソールから [フリートの使用状況] タブを使用します。ユーザーの行動は常に予測できるわけではなく、需要が最初に評価した事前計画をも上回ることもあるため、フリートの使用状況を定期的にモニタリングします。CloudWatch の AppStream 2.0 メトリクスとディメンションの全リストは、AppStream 2.0 管理ガイドの「モニタリングリソース」に記載されています。

成長の予測

PendingCapacity で大規模なジャンプが発生するたびに、自動スケーリングイベントが発生します。ここで重要なのは、新しい AppStream 2.0 フリートインスタンスがユーザーセッションをホストできるようになるまでは、AvailableCapacity および PendingCapacity に逆相関があることを確認しておくことです。各 AppStream 2.0 フリートの InsufficientCapacityError に対して CloudWatch アラームを作成して、自動スケーリングが需要に遅れないように管理者に通知します。

需要がキャパシティを超え、InsufficientCapacityError メトリクス値が一般的である場合は、勤務日の開始時のスケジュールされたスケーリングポリシーにより、最小キャパシティの値を上げることを検討します。さらに、需要が満たされた後に最小キャパシティを引き下げる 2 つ目のスケジュールスケーリングポリシーも設定します。最小キャパシティの値を下げても、既存のセッションには影響しません。勤務日の終了前に最小キャパシティを下げると、ActualCapacity の値が下がり、スケールが意図したとおり効果的に機能するようになります。これによりコストが最適化されます。

需要が一貫して予測できない場合は、ターゲット追跡スケーリングポリシーを使用して、使用パターンを判断しながら、AppStream 2.0 フリートに需要を満たす十分な AvailableCapacity があることを確認します。ターゲット追跡はフリートの消費量の一定の割合を使用するため、引き続きモニタリングします。フリートインスタンスの総数が増えるにつれて、未使用のフリートインスタンスの総数も増えます。最大キャパシティを控えめな値に設定しない限り、これは無駄になる可能性があります。信頼性とコスト最適化のバランスをとるために、複数の種類のスケーリングポリシー (スケジュール管理やターゲット追跡など) を使用します。

ユーザー使用状況のモニタリング

ユーザー料金という形でコストが発生するため、固有のユーザーをモニタリングします。このユーザー料金のコストは、Image Assistant (RDS) のサブスクライバーアクセスライセンス (SAL) によるものです。固有のユーザーの評価は、認証が実行される IdP からのレポートまたは使用状況レポートを通じて実行できます。

使用状況レポートは S3 バケットに個別の .csv ファイルとして保存され、ダウンロードしてサードパーティのビジネスインテリジェンス (BI) ツールを使用して分析できます。レポートをダウンロードせずに AWS の使用状況データを分析したり、複数の .csv ファイルを連結せずにカスタムの日付範囲のレポートを作成することができます。例えば、Amazon Athena と Amazon QuickSight を使用して、AppStream 2.0 の使用状況データのカスタムレポートおよび可視化を作成できます。

アプリケーションイベントログと Windows イベントログの保存

AppStream 2.0 インスタンスセッションが完了すると、インスタンスは終了します。つまり、セッションで使用されていたアプリケーションと Windows のイベントログはすべて失われます。これらのアプリケーションおよび Windows イベントログを保持する必要がある場合、1 つの方法は、Amazon Data Firehose を使用してイベントログを S3 にリアルタイムに配信し、Amazon OpenSearch Service (OpenSearch Service) で検索することです。クエリが頻繁に発生しないことが予想される場合は、コストを最適化するために、Amazon OpenSearch Service を実行するのではなく、Amazon Athena を使用して検索します。

ネットワークと管理アクティビティの監査

まだセットアップしていない場合は、Amazon AppStream 2.0 を使用して AWS アカウント の AWS CloudTrail を設定するのがベストプラクティスです。特に AppStream 2.0 API 呼び出しを監査するには、appstream.amazonaws.com の値でのフィルタイベントソースを使用します。

VPC フローログを有効にして、カスタマーマネージドリソースへのアクセスを監査します。VPC フローログを CloudWatch Logs にパブリッシュすることで、監査が必要な場合にクエリを実行できます。

AppStream 2.0 のフリートが増えるにつれて、サブネット IP の割り当てのモニタリングが重要になります。describe-subnets CLI を実行して、フリートに割り当てられた各サブネットで使用可能な IP アドレスを報告することで、IP の割り当てについてレポートします。最大キャパシティで実行しているすべてのフリートの需要を満たすのに十分な IP アドレスのキャパシティが組織にあることを確認します。