開発およびテストワークロードの自動スケール戦略
開発およびテストワークロードは、通常のデスクトップとは異なる動作をします。これらは、CPU と RAM の需要が高く、サインインパターンが変動し、コールドスタートやパワー不足のホストに対する耐性が低いことがよくあります。そのため、最適な自動スケール戦略は、通常、最も積極的なものではありません。それは、バーストに対して十分な容量を維持しつつ、アイドル期間中の無駄を減らす戦略です。
このアプローチを使う理由
単一の自動スケールパターンは、すべてのエンジニアリングワークロードに適していません。共有の QA およびテストユーザーは、プールされた弾力性の恩恵を通常受ける一方、パワーユーザーや永続的な開発者ワークステーションは、ハイバネーション、適切なサイズへの調整、ストレージ最適化を備えた個人用デスクトップからより多くの恩恵を受けることが多いです。これらのワークロードを分離することで、すべてのユーザーを1つのホストプールに強制するよりも、通常はより良いパフォーマンスとコスト管理が得られます。
推奨戦略
まず、適切なホストプールを選択してください。
ユーザーがホストを共有でき、主な目的が弾力性とコスト管理である場合は、プールされたデスクトップを使用してください。
ユーザーが専用のマシン、永続的なカスタマイズ、またはワークステーションのような動作を必要とする場合は、個人用デスクトップを使用してください。
環境に両方のタイプのユーザーがいる場合は、それらを別々のホストプールに分割し、それぞれを個別に最適化してください。
プールされた開発およびQAワークロードの場合
ほとんどの共有エンジニアリングワークロードでは、推奨パターンとして、主要な作業ウィンドウ前に少量の基本容量を確保し、利用が増加する段階でユーザーを広く分散させ、ピーク需要が安定した後により積極的に統合することが挙げられます。計画されたシャットダウンウィンドウの前にはローリングドレインを使用し、オフアワーや予期しないアクセスをサポートするために接続時にVMを電源オンを使用するべきであり、唯一の準備戦略として機能すべきではありません。
出発点として、フリンジ時間中に小さなウォームベースラインを維持することは、プールを完全にコールド状態にするよりも効果的であることがよくあります。これにより、サインインの遅延が減少し、低需要の期間中にNerdio Managerスケールダウンすることが可能になります。
個人用デスクトップの場合
専用の開発者ワークステーションでは、共有ホストの弾力性からアイドルリソースのコスト削減に焦点を移すべきです。個人用デスクトップは、通常、休止状態やスケジュールに基づく電源操作、定期的な VM の適切なサイズへの調整、セッションホストVMが使用されていないときの停止中のディスクの最適化で最適化されます。
一般的なワークロードパターン
予測可能なエンジニアリングスケジュール
ほとんどのユーザーが一定の時間に働く場合、業務開始前に小さなキャパシティを確保し、主要な時間帯にスケールアウトし、需要が減少した後にスケールインします。これは、通常の業務時間に使用する開発チームや少数の早朝または遅いユーザーに適しています。
突発的な開発およびテスト活動
使用が不規則な場合、例えばQA検証、リリーステスト、または短期間のコンピュートバーストの場合は、非常に小さなウォームベースラインを維持し、接続時にVMを電源オンを使用して長期アクセスを行います。これらの環境では、オートスケール設定を実際のサインイン時間とホストパフォーマンスと照らし合わせて慎重に検証し、過度の集約を避ける必要があります。
パワーユーザーと専門の開発者
ユーザーが重いツールチェーン、カスタムローカルサービス、または個別のワークステーション構成を実行する場合、個人用デスクトップがより適していることが多いです。このような場合、コスト管理は、共有ホストの密度からではなく、インテリジェントに電源を切ったり休止状態にしたり、ディスクコストを最適化することから来ます。
重要な考慮事項
接続時にVMを電源オンすることは便利ですが、完全な戦略ではありません。
接続時にVMを電源オンは、ユーザーが接続したときにセッションホストを電源オンにし、ホストがすでに稼働していない場合に機能します。これは、オフ時間のアクセスや小規模な周辺ワークロードに役立ちます。ただし、突発的または同時サインインのある環境では、これに依存するだけでは、いくつかのウォーム容量を維持するよりもユーザーの準備が遅れる可能性があります。
自動スケールとストレージ最適化を組み合わせる
コンピュートコストは、総支出の一部に過ぎません。ストレージコストは、セッションホストVMが停止しているときでも続きます。Nerdio Managerは、停止したセッションホストVMのOSディスクタイプをより安価なストレージティアに自動的に変更し、起動前にディスクを高性能ティアに戻すことができます。これは、プールされたホストプールと個人用ホストプールの両方に適用され、正しく構成されている場合に大幅なコスト削減を提供できます。
注意: Azure 接続時にVMを電源オンがセッションホストVMをNerdio Managerの外で起動する場合、ディスクパフォーマンスの変更は自動的に発生しない可能性があります。その場合、ユーザーが接続する前にホストがすでに実行中のディスクタイプを使用しているように、事前に設定を構成する必要があります。
地域のキャパシティが制限されている場合は、Azure Capacity Extenderを使用してください。
Azureリージョンで好ましいセッションホストVMサイズが頻繁に利用できない場合、Azure Capacity Extenderは、代替のセッションホストVMサイズを順番に使用することで、ホストの作成、自動スケール、自動拡張、および自動修復操作の失敗を防ぐのに役立ちます。フォールバックサイズを選択する際は、一貫性のないユーザーのパフォーマンスを避けるために、リソースプロファイルが類似しているオプションを選択してください。
ベストプラクティス
共有の弾力的なエンジニアリングワークロードには、プールされたデスクトップを使用してください。
専用のパワーユーザーには、個人用デスクトップを使用してください。
完全にコールド状態にするのではなく、フリンジ時間中に小さなウォームベースラインを維持してください。
オフ時間のアクセス用として、接続時に VM を開始するを利用してください。ただし、バーストチーム向けの唯一の予備プランとしないでください。
自動スケールとOSディスクの最適化を組み合わせて、コンピュートとストレージの無駄を減らしてください。
大きく異なるユーザープロファイルは、全員に妥協した設定を適用するのではなく、個別のホストプールに分けてください。
サマリー
ほとんどの開発およびテスト環境では、最適な自動スケール戦略はバランスが取れているものです。ユーザーエクスペリエンスを守るために十分なキャパシティを確保し、ワークロードの共有が可能な場合はプールされたデスクトップを、データの永続性が求められる場合は個人デスクトップを使用してください。また、自動スケールとストレージ最適化、フォールバックキャパシティ計画を組み合わせてください。このアプローチは、完全に静的な設計や過度に積極的なスケールインモデルと比較して、通常、高いパフォーマンスと低いリソースの無駄を実現します。
コメント (0件のコメント)