コスト最適化 - Amazon AppStream 2.0 をデプロイするためのベストプラクティス

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

コスト最適化

コスト最適化は、不必要なコストを回避することに焦点を当てています。主なトピックには、お金が使われている場所を理解し、管理すること、そして最も適切かつ正しい数のリソースタイプを選択することが含まれます。経時的な支出とビジネスニーズに合わせたスケーリングを分析します。以下の AppStream 2.0 リソースでは従量制料金が発生します。

  • 常時オンのフリートインスタンス

  • オンデマンドのフリートインスタンス

  • オンデマンドの停止インスタンスの料金

  • Image Builder インスタンス

  • ユーザー料金

最新の料金情報については、Amazon AppStream 2.0 料金表の AWS ウェブサイトを参照してください。

コスト効率に優れた AppStream 2.0 デプロイの設計

AppStream 2.0 デプロイの計画と設計における最初のステップは、シンプルな価格設定ツールを使用して、使用量に関連する AWS 料金のベースラインを見積もることです。ユーザーの総数、1 時間あたりの実際の同時使用量、インスタンスタイプ、フリート使用率を入力すると、価格設定ツールがユーザー 1 人あたりの価格を見積もります。また、常時オンフリートの代わりにオンデマンドフリートを使用した場合の削減見込み額も表示されます。

カスタマーは、ユーザーのストリーミングニーズを満たすためにプロビジョニングしたインスタンスに対してのみ支払いを行う AppStream 2.0 の価格モデルを好みます。このモデルは、既存のアプリケーションストリーミング環境とは異なります。これらは通常、負荷の低い夜間、週末、休日であっても、ピーク時のキャパシティをプロビジョニングすることが基本となっています。Amazon AppStream 2.0 価格設定ツールは、AppStream 2.0 の使用に関連する AWS 料金の見込み額を提供するだけで、適用される可能性のある税金は含まれていません。実際の料金は、AWS サービスの実際の使用状況など、さまざまな要因によって異なります。

AppStream 2.0 価格設定ツールは、Microsoft Excel または OpenOffice Calc のスプレッドシートとして提供され、フリートに関する基本情報を入力できるほか、使用パターンに基づいてオンデマンドフリートと常時オンフリートの AppStream 2.0 環境のコストの見込み額を提供します。過去または予想される使用傾向に基づいてコストをシミュレートできます。Elastic フリートにはこれらの機能が組み込まれているため、管理者は使用量の予測、スケーリングポリシーやイメージの作成、管理を行う必要がありません。Elastic フリートと Amazon Linux 2 で実行されているインスタンス (すべてのフリートタイプ) には、ストリーミングセッションの時間 (秒単位) に対して課金されます (最低 15 分)。

インスタンスタイプの選択によるコストの最適化

フリートインスタンスと Image Builder インスタンスでは、アプリケーションに合わせてさまざまなインスタンスファミリーとタイプを選択できます。

エンドユーザーテスト — 次のステップでは、AppStream 2.0 フリートをパイロットユーザーのグループにロールアウトして、選択したインスタンスタイプを検証するためのテストを行います。パイロットユーザーに、メモリ、CPU、グラフィックに関するメトリクスをキャプチャして、通常のワークフローと負荷の高いワークフローをすべてテストするように依頼し、ベースラインのパフォーマンスメトリクスをキャプチャできるようにすることが重要です。パイロットグループには、複数のユーザーエクスペリエンスからアプリケーションをテストしていることを確認するために、アプリケーションを使用するさまざまなユーザーロールを含める必要があります。ユーザー受け入れテストを実施することで、ストリーミングセッションのエクスペリエンスに関するフィードバックを収集できます。スタックの作成または更新時には、カスタムフィードバック URL を使用するオプションがあります。ユーザーは、アプリケーションストリーミングのエクスペリエンスについて [フィードバックを送信] リンクをクリックすると、この URL にリダイレクトされます。パフォーマンスのボトルネックがある場合は、Windows のパフォーマンス指標を使用してリソース制限について分析してください。例えば、現在のフリートインスタンスタイプ stream.standard.medium がリソース制約を示している場合、そのインスタンスタイプを stream.standard.large にアップグレードします。逆に、パフォーマンスメトリクスにより、リソースの使用率が低いことが多いと分かった場合は、インスタンスタイプをダウングレードすることを検討します。

フリートタイプの選択によるコストの最適化

新しい AppStream 2.0 フリートを作成する場合、開発者はフリートタイプを常時オンまたはオンデマンドのどちらかを選択する必要があります。価格の観点からインスタンスタイプを選択する際には、AppStream 2.0 がフリートインスタンスをどのように管理するかを理解することが重要です。常時オンフリートでは、フリートインスタンスは実行状態のままです。そのため、ユーザーがセッションをストリーミングしようとしても、フリートインスタンスはいつでもストリーミングセッションを開始できる状態になっています。

オンデマンドフリートの場合、フリートインスタンスは起動後も停止状態のままになります。停止したインスタンス料金は、実行中のインスタンス料金よりも低くなるため、コスト削減に役立ちます。オンデマンドフリートインスタンスは停止状態から起動する必要があります。ユーザーはストリーミングセッションが使用可能になるまで約 2 分待つ必要があります。

自己完結型で Amazon Simple Storage Service (Amazon S3) バケットに保存された仮想ハードドライブにインストールできるアプリケーションには、Elastic フリートが適しています。Elastic フリートでは、1 秒あたりの請求がストリーミング中のみのため、ユースケースによってはコストをさらに削減できる可能性があります。料金は、フリートを作成するときに選択したインスタンスタイプ、サイズ、オペレーティングシステムによって異なります。

エンドユーザーが営業時間中にフリートインスタンスを必要とする場合は、同じストリーミングセッションを維持する方が適しています。これは、フリートインスタンスは 1 時間ごとに課金され、新しいストリーミングセッションが開始されるたびに、別のフリートインスタンス料金が発生するためです。

表 10 — AppStream 2.0 フリートタイプの比較

フリートタイプ

利点

考慮事項

常時オン

ストリーミングセッションの待ち時間を短縮できる

ユーザーは、インスタンスを停止状態に保つオプションがないため、時間単位のインスタンス料金を支払います。

オンデマンド

インスタンスが停止状態のままになるためコストを節約できる

ストリーミングセッションの待ち時間が長期化する

Elastic

秒単位の課金は、仮想ハードディスクにインストールできるアプリケーションの使用パターンが散発的なユースケースに役立つ場合があります。

アプリケーションの仮想ハードディスクのサイズが大きくなると、ストリーミングインスタンスへのマウントにかかる時間が長くなる可能性があります。

AppStream 2.0 はフリートの使用状況をモニタリングし、ユーザーの需要を満たすようにフリートのキャパシティを自動的に調整して、可能な限り低いコストで実現します。キャパシティの調整は、現在の使用率またはスケジュールに基づき、定義したスケーリングポリシーを基に行われます。フリート使用状況のメトリクスを定期的に見直して、フリートスケーリングポリシーに高レベルの予備キャパシティがないことを確認します。

スケーリングポリシー

フリート自動スケーリングでは、ユーザーのログインを待つリソースを過剰にコミットする必要がないため、フリートリソースを最適化できます。管理者は、ユーザーの需要に合わせて、さまざまな使用状況に基づいてフリートのサイズを調整できます。CloudWatch AppStream 2.0 フリートメトリクスまたはサードパーティのモニタリングツールを使用して、ユーザーのアクティビティを把握し、予想される使用状況に基づいて AppStream 2.0 フリートを拡張または縮小するスケーリングポリシーを設定します。ユーザーログは、実際の使用状況を把握するために不可欠なメカニズムです。この分析情報を使用して、自動スケーリングに基づいてフリートのサイズを動的に変更することができます。

多くの場合、AppStream 2.0 フリートは最大ユーザー数に基づいて作成されており、夜間や週末など、1 日の異なる時間帯に合わせて調整されることはありません。多くの場合、ストリーミングアプリケーションの同時ユーザー数は、特にユーザーがリモートで柔軟に作業できる場合、ユーザーの総数よりも少なくなります。使用パターンを予測する際には、これらの要素を考慮に入れることが重要です。過大に評価すると AppStream 2.0 インスタンスをプロビジョニングし過ぎることになり、コストが増加します。最適な構成を実現するには、必要に応じて、1 つ以上のスケジュール済みのスケーリングポリシーをスケールアウトポリシーと組み合わせます。

スケーリングポリシーの実装について詳しくは、「Amazon AppStream 2.0 フリートのスケーリング」を参照してください。

ユーザー料金

ユーザー料金は、ユーザーが AppStream 2.0 フリートインスタンスからアプリケーションをストリーミングするたびに、各 AWS リージョン のユーザー 1 人あたり、1 か月ごとに請求されます。AppStream 2.0 ユーザーには、異なるユーザー ID を生成するのではなく、一貫したユーザー ID を用意します。Image Builder に接続するとき、ユーザー料金は請求されません。

学校、大学、および特定の公共機関によっては、Microsoft RDS SAL ユーザー料金を 1 ユーザーにつき 1 か月あたり 0.44 USD の割引を受けることができます。資格要件については、「Microsoft ライセンス条項およびドキュメント」を参照してください。

Microsoft ライセンスモビリティをお持ちの場合は、独自の Microsoft RDS クライアントアクセスライセンス (CAL) を Amazon AppStream 2.0 で使用できる場合があります。お持ちのライセンスの対象であれば、毎月のユーザー料金は発生しません。既存の Microsoft RDS CAL ライセンスを Amazon AppStream 2.0 で使用できるかどうかの詳細については、「AWS ライセンスモビリティガイダンス」を参照するか、Microsoft のライセンス担当者に相談してください。

Image Builder の使用

AppStream 2.0 Image Builder インスタンスは、時間単位で課金されます。Image Builder インスタンスの料金には、コンピューティング、ストレージ、およびストリーミングプロトコルで使用されるすべてのネットワークトラフィックが含まれます。実行中のすべての Image Builder インスタンスには、該当する実行インスタンス料金が課金されます。この料金は、管理者が接続していない場合でも、インスタンスタイプとサイズに基づきます。

コストを最適化するためのベストプラクティスとして、使用していないときは Image Builder インスタンスをシャットダウンします。CloudWatch イベントルールを使用して、Lambda 関数を呼び出して Image Builder のインスタンスを停止するなど、毎日のジョブをスケジュールできます。

AppStream 2.0 イメージは、AppStream 2.0 マネージドイメージ更新を使用して最新の状態に保つことができます。この更新機能では、最新の Windows オペレーティングシステムの更新とドライバーの更新、および最新の AppStream 2.0 エージェントソフトウェアが提供されます。この方法を使用してイメージを更新すると、マネージドサービスプロセスの一環として Image Builder が自動的に起動および停止されます。