技術概要:Autoscale

概要

電源管理スキームの設計がうまくいかないと、クラウドコンピューティングのコストは、組織がユーザーをサポートするために必要なコストを 70% 以上増加させる可能性があります。クラウドベースのサービスは、多くの場合、従量制モデルを使用します。このモデルでは、コンピューティング時間、ネットワークスループット、ストレージ使用量、トランザクションに対して、組織が 1 秒おきに課金されることもあります。コストを最小限に抑えるために、組織はリソースをインテリジェントに利用、割り当て、割り当て解除する必要があります。これは、組織がリソースを無期限に割り当てられる従来のオンプレミスモデルとはまったく対照的です。仮想デスクトップ展開では、組織は数百または数千台の仮想マシンを永続的に割り当てるコストを考慮する必要があります。このアプローチでは、ソリューションは高価になりすぎて、実現可能になりません。

Citrix Virtual Apps and Desktopsサービスは、クラウドコストの削減に役立つ方法の1つとして、垂直負荷分散による自動スケールを使用しています。これらの機能により、組織は仮想デスクトップを最大限に活用し、使用傾向を特定し、それらの傾向をスケジュールおよび負荷ベースのルールに変換し、リソースを動的に割り当て/割り当て解除して、良好なユーザーエクスペリエンスを維持できます。

Citrix環境で自動スケールによって得られる主なメリットを以下に示します。

  • ハイブリッドマルチクラウド負荷分散 -リソースの場所でのみホストされているリソースまたは実行コストが高いリソースの選択的な電源管理をサポートします。オンプレミスインスタンスまたはリザーブドインスタンスは 24 時間 365 日稼働し続けることができます。クラウドベースのリソースやディザスタリカバリのユースケースへのオンデマンドバーストを可能にします。
  • サービス統合 -自動スケールはCitrix Cloudコンソールに統合され、追加のコンポーネント、アプリ、スクリプトを展開する必要がありません。数回クリックするだけで、UIから簡単に有効になり、デリバリーグループごとに構成できます。
  • サブスクリプション全体のサポート -Power はサブスクリプション全体でマシンを管理し、別のリージョンへのDRを可能にします。
  • スケジュールベースのスケーリング :ピーク時に定義された数のマシンの電源をオン状態に維持できます。このスケジュールは、週ごとに構成可能です。
  • バッファ容量 -平日の朝など、予想される同時ログオンタイムスロットの前に事前定義された数の仮想マシンをパワーオンして、すべてのユーザーが迅速かつ円滑にログオンできるようにします。バッファ容量は設定可能で、ピーク時とオフピーク時に個別に設定できます。
  • VDIサポート -単一セッションとマルチセッションの両方のデリバリーグループをサポートします。
  • ドレインモード — ユーザー数が少ない仮想マシンを分離し、新しいセッションを割り当てないため、ピーク時でもシャットダウンできます。
  • 動的プロビジョニング -Citrix Machine Creation Servicesを使用してマシンを作成および削除できます。これにより、マシンが不要になったときにディスクの割り当てを解除することで、ストレージコストを削減できます。
  • より多くの決定パラメータ -電源管理の決定ルールは、CPU、メモリ、ディスク使用率、セッション数の任意の組み合わせとしてカスタマイズできます。
  • Directorのレポート作成 :キャパシティプランニングと電源管理のコスト削減をモニタリングコンソールにレポートします。
  • 電源オフの遅延 — マシンの羽ばたきがオンの状態とオフ状態の間にならないようにします。パワーオンされたマシンのスイッチオフが可能になるまでの期間は、設定可能です。

コスト対エクスペリエンス

電源管理マシンがユーザーエクスペリエンスに与える主な影響は、要求されたセッションにユーザーを接続するのにかかる時間です。電源管理が積極的すぎて、セッションをホストしていないマシンがシャットダウンされると、(実行中のマシンからの)プールの容量が枯渇します。別のユーザーがセッションを要求し、パワーオンされたマシンに利用可能な容量がない場合、ユーザーはマシンの電源が入るまで待つ必要があります。待機はユーザーエクスペリエンスに悪影響を及ぼし、セッションの起動時間には数分かかります。シフトの開始時など、多くのユーザーが同時にログインする場合、同時に複数のマシンをパワーオンする必要があるため、起動時間がさらに長くなることがあります。

未使用のマシンをパワーオフすることによるコスト削減は、コンピューティングコストはゼロであり、ネットワークの入力/出力およびデータトランザクション(ストレージへの読み取りと書き込み)のコストを削減します。このシナリオでは、管理者は、ユーザーがセッションにすばやくログインできるようにするバランシング処理を実行する必要が生じます。同時に、使用されていないマシンを最適な数だけシャットダウンしてコストを抑えることができます。

コストと経験のバランスをとるために、Citrix は以下のテクノロジーを組み込んでいます。

  1. Autoscale
  2. 負荷分散アルゴリズム
  3. ゾーンの基本設定およびタグ付け

Autoscale

自動スケールは、展開の一部である仮想マシンの管理プロセスを自動化するために設計された一連の機能です。自動スケールは、Citrix環境でマシンを実行するためのコストを削減するように設計されています。

デリバリーグループには、アプリとデスクトップに同様の要件を持つユーザーが含まれます。ユーザーのグループには、多くの場合、同じ労働時間があります。たとえば、ロンドンオフィスの会社の人事部門などです。したがって、管理者はデリバリーグループレベルで自動スケールを構成します。 デリバリーグループのユーザーには、要求を処理できるマシン(マシンカタログ)のプール(マシンカタログ)で実行されているリソースが割り当てられます。 プール内のマシンのパワーオンとオフについて正確な判断を下すには、Autocale がデリバリーグループの容量を認識している必要があります。Autocaleでは、セッションリクエストを受け付けることができるホストを正確に表示するために、特定のデリバリーグループの容量を決定するときに、サービスに登録されているマシンのみが自動スケールに含まれます。

自動スケールを使用すると、管理者は次の 2 つの設定に基づいて電源管理を実行できます。

  1. スケジュールベースのスケーリング
  2. 負荷ベースのスケーリング

注:両方とも電源管理設定を定義するために組み合わせて使用されます。

Autoscale e-スケジュールと負荷ベースのスケーリング設定ダイアログ

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

労働時間が定義された一般的なオフィスでは、ピーク時とオフピーク時間が区別されます。管理者は、稼働時間および非稼働時間中に電源を入れるマシンの数を定義します。 通常、労働時間(平日の午前9時から午後5時など)は、需要を満たすために最小数のマシンをオンにする必要があります。稼働日が午前 9 時に開始する場合は、仮想デスクトップがすでに使用可能である必要があります。ユーザーがログオンを開始する前に、マシンを起動し、起動後のタスクを完了するためにいつかそれらを与えていることをお勧めします。したがって、稼働時間が始まる前 (この例では午前 8 時)、予想される負荷を処理するためにいくつかのホストが起動され、その結果、ユーザーは正のログオンエクスペリエンスを得ることができます。したがって、スケジュールは午前8時から午後6時まで設定されます。

作業時間が過ぎると(この例では午後5時)、ユーザーはログオフを開始します。管理者は、未使用のホストをシャットダウンしたい。午後6時頃、自動スケールがホストの電源オフを開始し、オフピーク使用に必要なホストの数だけが電源オンのままになります。これにより、24時間365日ホストのインベントリ全体を実行するのではなく、クラウド消費コストが大幅に削減されます。Citrix は、管理者に、これらの時間を30分単位で定義できる柔軟性を提供します。マルチセッションのデリバリーグループの場合、管理者は半時間ごとに実行ホストの最小数を個別に設定できます。プールされた単一セッションのデリバリーグループの場合、管理者は実行ホストの最小数を1日の時間ごとに個別に設定できます。管理者は、異なる曜日の労働時間を個別に設定できます。

注: ユーザーが特定のマシンに接続すると、スケジュールベースのスケーリングは、静的な単一セッションのデリバリーグループには適用されません。ユーザーが初めてログインしようとしている場合を除き、特定の時間に他のマシンを起動しても役に立ちません。

負荷ベースのスケーリング

負荷ベースのスケーリングにより、管理者はセッションをホストするために必要な場合に備えて、マシンの容量バッファを作成できます。容量バッファーは SafetyNet で、ユーザーエクスペリエンスに悪影響を与えることなく、予期しない使用量の増加をサポートします。容量バッファの適切な値(プール容量に対するパーセンテージ)を確認することは、使用状況とお客様の環境における負荷分散を理解することに基づきます。デリバリーグループで、セッションの総容量が100で、管理者が容量バッファを 10% と定義すると、ピーク時に10セッションを超えるスペア容量を維持するために必要なマシンの数がパワーオンされます。

ユーザーがログインすると、デリバリーグループの利用可能な容量が枯渇します。容量バッファの値を下回ると、プール内の別のマシンが起動され、容量バッファが定義した値を超えるようになります。反対側では、ユーザーがログオフを開始すると、負荷が最も少ないマシンはドレインモードになります。マシンがセッションをクリアすると、プールの容量が設定された容量バッファ値に減少するまで、マシンはシャットダウンされます。

Autoscale-貯蓄イラスト

注: 負荷ベースのスケーリングは、単一セッションデスクトップデリバリーグループでは使用できません。これは、各マシンの負荷がゼロまたはフルであるため、マシンでセッションが実行されているかどうかに基づきます。したがって、容量バッファーが単一セッションのデリバリーグループに設定されている場合、そのデリバリーグループ内のマシンの数に基づきます。

ドレインモード

容量バッファよりも多くのセッション容量がある場合、セッション数が最も少ないマシンはドレインモードになります。ドレインモードのマシンは、予備容量がある場合でも、新しいセッションを受け付けません。自動スケールは、マシン上のすべてのセッションをログオフしようとするため、マシンをシャットダウンできます。

注:デリバリーグループに予備容量がない場合、Autocale は、別のマシンを起動するのではなく、マシン上でセッションをドレインモードで起動します。

負荷分散アルゴリズム

Citrixでは、デフォルトで水平負荷分散アルゴリズムが採用され、クラウド内のマシンの電源管理が行われます。受信セッションは、ユーザーエクスペリエンスを最適化するために負荷分散されます。新しいセッションは、ロードが最も少ないマシンに割り当てられます。カタログ内の新しいマシンを起動すると、そのマシンの負荷は最小になり、負荷が最小でなくなるまで、後続のすべてのログオンに使用されます。

次の例では、デリバリーグループには6つのマシンがあります。容量バッファが 20% に設定されている場合、空き容量が 5 セッションを下回るとすぐに、新しいマシンの電源がオンになります。これで、新しいユーザーがログインすると、そのユーザーには新たに電源が入ったマシンが割り当てられます。次のユーザーには、最も負荷の少ないマシンが割り当てられます。次の図では、配布がどのように行われるかを確認できます。セッションが均等に分散されるため、いずれかのマシンがシャットダウンされる可能性が低くなります。たとえば、最初の5つのセッションのうちの1つがログオフすると、空き容量は5セッションまでになりますが、各マシンには少なくとも1つのセッションが実行されているためシャットダウンできません。

Autoscale-水平負荷分散

垂直負荷分散を使用すると、管理者は受信セッションが負荷分散され、電源が入っているマシン数が最小になるよう最適化されるように設定できます。セッションは、最大負荷のハイウォーターマークに達していない限り、最も負荷の高いマシンに割り当てられます。これにより、現在の負荷の稼働に必要な最小数のマシンだけがパワーオンされるため、コスト効率がはるかに高くなります。前述の例を考えてみましょう。最初の5つのセッションのうちの1つがログオフし、マシン1のセッション数が4に減少すると、空き容量は最大5セッションに戻ります。マシン3はシャットダウンできるようになり、追加コストを節約できます。また、新しいマシンが起動する代わりに、マシン1に新しいセッションが割り当てられます。さらに、ロードの少ないマシン上のセッションは、最初にログアウトとしてマークされます。

Autoscale-垂直負荷分散

管理者が、ユーザーの要求を処理するために必要なマシンの数が不明なシナリオを考えてみましょう。管理者は、デリバリーグループにマシンを過剰に割り当てることもあります。垂直負荷分散では、ユーザーの負荷に対して必要な数のマシンだけがパワーオンされます。容量バッファは、このシナリオで負荷を処理するために余分なマシンを使用できるようにするのに役立ちます。

ゾーンの優先度とタグの制限

ハイブリッド展開では、クラウドとオンプレミスのリソースがあります。ハイブリッド展開では、単一のデリバリーグループを異なるゾーンに分割できます。

  • プライマリ:生産資源使用率の優先場所。
  • セカンダリ:プライマリゾーンが完全に利用されたときに、資源の場所がタップされます。

たとえば、クラウドへのバーストシナリオでは、組織はオンプレミスのプライマリリソースを完全に利用します。追加の容量が必要な場合、セカンダリインスタンスはクラウドから消費されます。デリバリーグループは 2 つのカタログで構成されます。1 つはオンプレミスのリソースの場所用で、もう 1 つはクラウドの場所用です。

オンプレミスとクラウドベースのインスタンスを使用したハイブリッド展開

ハイブリッドデプロイモデルでは、オンプレミスのリソースがプライマリゾーンとなり、クラウドベースの従量課金インスタンスがセカンダリゾーンを構成しています。

Autoscale e-ゾーン優先ハイブリッド展開

リザーブドインスタンスおよび従量課金インスタンスを使用したクラウドデプロイ

クラウドのみのデプロイでは、リザーブドインスタンスはプライマリゾーンになり、セカンダリゾーンには、必要に応じて消費される従量課金制インスタンスが含まれます。

Autoscale-ゾーン優先クラウドのみの展開

ハイブリッド展開のコストを削減するには、ゾーンの優先度とタグ付けが重要です。プライマリインスタンスマシンは、前払い分として支払われます。これらのリソースの電源を切ることによるコスト削減は限られています。組織は、セカンダリインスタンスを使用する前に、まずこれらのリソースを使用します。

Citrix Virtual Apps and Desktopsサービスは、ゾーン設定オプションで複数のリソースの場所の使用をサポートします。管理者は、ゾーンプリファレンスを使用して、需要を満たすために最初に使用するリソースの場所と、セッションのデマンドがドロップしたときに最初に電源が切断される場所を定義します。プライマリゾーンの容量が十分に利用されると、セッション要求を処理するために、セカンダリブートとしてマークされたホストはセカンダリブートとしてマークされます。需要が低下すると、セカンダリゾーン(クラウドリソース)内のホスト(クラウドリソース)が最初にシャットダウンされ、最適なクラウド使用率が得られます。 これらの設定は、マシンカタログレベルで行われます。

Autoscale e-ゾーン設定構成

管理者は、ゾーン設定とともにタグ制限を使用して、デリバリーグループの特定のホスト(クラウドの場所)を電源管理するかどうか、Autocaleに知らせる必要があります。タグ制限は、Autocale によって電源管理されるホストを指定します。これらのホストは、バースト/ディザスタリカバリの負荷に対応するように設定されたホストです。

Autoscale-タグ付け

詳細については、「 [ゾーン設定とタグ](/ja-jp/citrix-virtual-apps-desktops/manage-deployment/tags.html#manage-tags-and-tag-restrictions)」を参照してください。 オートスケール制限を設定するには、こちらの指示に従ってください

スケジュールベースのスケーリングによる自動スケールによるコスト削減

注意: 結果は、各組織の使用状況および負荷特性によって異なります。独自のシステムでこれらのパターンを確認して、 環境に合わせて自動スケール設定を微調整します 。以下は、LoginVSI ロードによる内部テストに基づく結果です。

Autoscale でクラウドのコスト削減を測定するには、クラウドでマシンを実行するコストを判断する必要があります。 Azure Pricing Calculator を使用して計算された、米国西部での支払いの VM のサイズとコスト (このホワイトペーパーの執筆時点) は次のとおりです。

VM インスタンス 仮想マシンの仕様 月あたりのコスト 時間あたりのコスト 1 か月あたりのストレージコスト
D3_V2 4 vCPU\ 14 GB $367.92 $0.504 5.94ドル
D4_V2 8 vCPU\ 28 GB $735.84 1.008ドル 5.94ドル
F16 16 コア\ 32 GB $1264.36 $1.732 5.94ドル

月あたりのコスト計算では、マシンが月全体 (730 時間) 稼働していることを前提としています。ストレージコストは、マシンの電源がオンかオフかにかかわらず、月額固定コストです。

Autocaleでは、ユーザーの動作に合わせてマシンの電源がオンのままになる時間を短縮します。

Autocale によるコスト削減の可能性をよりよく判断するために、Citrix は LoginVSI 単一サーバーのスケーラビリティテストを以下のセットアップで実施しました。

  • Citrix Virtual Apps and Desktops 1902
  • Citrix Workspace アプリ 1903
  • Windows サーバー 2016 マルチセッション OS Azure VM
    • D3_V2
    • D4_V2
    • F16
  • LoginVSI ワークロード:ナレッジワーカー

これにより、仮想マシンインスタンスごとに次のユーザー負荷が発生しました。

Autoscale e-さまざまな Azure VM サイズに対するマシンごとのセッション

スケーラビリティ番号は、次の 3 つのシナリオにおけるサイジングガイダンスを提供するために使用されます。

シナリオ 1-ピーク時とオフピーク時間を定義した水平スケーリングオフピーク時-アクティブユーザーはゼロ

  • ピーク時のユーザー数:1,000 ユーザー
  • オフピーク時間あたりのユーザー数:0 ユーザー
  • 週末オフピーク時のユーザー数:0 ユーザー
  • ピークログオン時間:午前 9 時
  • ピークログオフ時間:午後 5 時
  • ピーク開始時間:午前 8:30
  • ピーク終了時間:午後5時30分
  • 1日有効:9時間
  • アクティブ/月:198時間
  • 負荷分散アルゴリズム:水平

このシナリオに基づいて、日中のアクティブなセッションは次のとおりです。

Autoscale e-シナリオ 1 アクティブセッショングラフ

オフピーク時間の開始後にすべてのマシンがシャットダウンされた場合、1 か月間にマシンがオンになる時間は 198 時間です。コスト削減の計算は次のとおりです。

ナレッジワーカー-マシンサイズ D3_V2 D4_V2 F16
VSImax-セッション/マシン 25 50 74
マシン不要 40 20 14
1 時間あたりの計算コスト (USD) 0.504 1.008 1.732
ユーザー数1000人の時間あたりのコスト(128 GBのディスクを含む) 20.48548 20.32274 24.36192
月あたりのコスト (100% オン) 14954.4 14835.6 17784.2
自動スケールを使用した月額コスト(198時間) 4229.28 4110.48 4884.26
コスト削減率 71.72 72.29 72.54

次のグラフは、このシナリオで Autocale によって電源管理されているときと、常に電源をオンにしたときのマシンの実行コストの違いを示しています。

Autoscale e-シナリオ 1 コスト削減グラフ

表から、常時電源をオンにしたマシンのコストは、Autocale によって電源管理されている場合のコストの 35% 以上です。このシナリオの管理者は、Autoscale を使用することで、コンピューティングコストの約 70% を節約できます。

シナリオ 2-ピーク時とオフピーク時間を定義した水平スケーリング。オフピーク時 — 10% のアクティブユーザー

  • ピーク時のユーザー数:1,000 ユーザー
  • オフピーク時間あたりのユーザー数:100 ユーザー (シナリオ 1 とは異なります)
  • 週末オフピーク時のユーザー数:0 ユーザー
  • ピークログオン時間:午前 9 時
  • ピークログオフ時間:午後 5 時
  • ピーク開始時間:午前 8:30
  • ピーク終了時間:午後5時30分
  • 1日有効:9時間
  • アクティブ/月:198時間
  • 負荷分散アルゴリズム:水平

このシナリオに基づいて、週のアクティブなセッションは次のとおりです。

Autoscale e-シナリオ 2 アクティブセッショングラフ

1 か月間にすべてのマシンが稼働する時間数は 198 です。また、マシンの10%(切り上げ)は、月の18日を掛けた余分な15時間で実行されることになります。コスト削減の計算は次のとおりです。

ナレッジワーカー-マシンサイズ D3_V2 D4_V2 F16
VSImax-セッション/マシン 25 50 74
マシン不要 40 20 14
1 時間あたりの計算コスト (USD) 0.504 1.008 1.732
ユーザー数1000人の時間あたりのコスト(128 GBのディスクを含む) 20.48548 20.32274 24.36192
月あたりのコスト (100% オン) 14954.4 14835.6 17784.2
自動スケールを使用した月額コスト(198時間) 4773.6 4564.8 5819.54
コスト削減率 68.08 68.62 67.28

次のグラフは、このシナリオで Autocale によって電源管理されているときと、常に電源をオンにしたときの、マシンの実行コストの違いを示しています。

Autoscale e-シナリオ 2 コスト削減グラフ

この表から、常時電源をオンにしたマシンのコストは、Autocale によってマシンの電源管理を行う場合のコストの 300% 以上になります。このシナリオの管理者は、Autoscale を使用することで、コンピューティングコストの約 68% を節約できます。1 か月あたりの自動スケールコストを前のシナリオと比較すると、D_V2 VM サイズの 1 か月あたりのオフピークコストは約 545 USD になりますが、大規模な F16 仮想マシンは、オフピーク時間では月あたり 935 ドルになります。このグラフは、同じ数のセッションに対して、小型マシンは全体的な費用対効果が高いだけでなく、需要が少ない場合のコストも低くなることを明確に示しています。

シナリオ 3-ピーク時をずらした垂直スケーリング。オフピーク時 — 10% のアクティブユーザー

  • ピーク時のユーザー数:1,000 ユーザー
  • オフピーク時間あたりのユーザー数:100 ユーザー
  • 週末オフピーク時のユーザー数:0 ユーザー
  • ピークログオン時間:午前 9 時
  • ピークログオフ時間:午後 5 時
  • ピーク開始時間:午前 8:30
  • ピーク終了時間:午後5時30分
  • 1日有効:9時間
  • アクティブ/月:198時間
  • 負荷分散アルゴリズム:垂直 (シナリオ 2 以外)
  • ログオン\ ログオフ率:1 時間ごとに 25%

このシナリオに基づいて、週のアクティブなセッションは次のとおりです。

Autoscale e-シナリオ 3 アクティブセッショングラフ

一日の初めに必要なマシンは少なくなります。計算にはマシン数と時間数を乗算するため、計算時間数は 1 日 1 時間、月の 22 時間ずつ減少します。説明したように、ユーザーはランダムなマシンからログオフされるため、稼働日の終了後に必要なマシン数が 10% に低下すると仮定します。コスト削減の計算は次のとおりです。

ナレッジワーカー-マシンサイズ D3_V2 D4_V2 F16
VSImax-セッション/マシン 25 50 74
マシン不要 40 20 14
1 時間あたりの計算コスト (USD) 0.504 1.008 1.732
ユーザー数1000人の時間あたりのコスト(128 GBのディスクを含む) 20.48548 20.32274 24.36192
月あたりのコスト (100% オン) 14954.4 14835.6 17784.2
自動スケールを使用した月額コスト(198時間) 3893.6 4214.4 5511.54
コスト削減率 73.96 71.59 69.01

次のグラフは、このシナリオで Autocale によって電源管理されているときと、常に電源をオンにしたときのマシンの実行コストの違いを示しています。

Autoscale e-シナリオ 3 コスト削減グラフ

この表から、常時電源をオンにしたマシンのコストは、Autocale によってマシンの電源管理を行う場合のコストの 300% 以上になります。最小のマシンでは、D3_V2 は 384% です。マシンのサイズが小さいほど、より大きな数のマシンをシャットダウンして、同じ負荷を処理できます。同様に、ユーザーがログオフを開始すると、シャットダウンする方が速く、セッションがゼロに達する時間が短くなります。

3 つのシナリオをすべて考慮し、コスト削減グラフを見ると、自動スケールが有効な場合は、マシンサイズが小さいほどコスト効率が高くなることは明らかです。

重要: Autosale がマシンをシャットダウンできるようにするには、ユーザーがマシンを切断またはログオフする必要があります。したがって、 デリバリーグループの自動スケール設定で切断タイマーとログオフタイマーを構成することを検討してください 。これにより、コスト削減率が高くなります。

監視

管理者は、[モニター]タブから、 AutoScaleで管理されるマシンの次のメトリックを監視できます 。タブには、デリバリーグループごとのリソースの消費量のグラフが表示されます。これらのグラフを使用して、デリバリーグループの実際の使用状況を把握し、管理者がカタログのサイズを正しく設定する際に役立ちます。次のグラフが表示されます。

  • マシンの使用量
  • 見積もり削減額
  • マシンとセッションのアラート通知
  • マシンの状態
  • 負荷評価傾向

節約額は、 自動スケール設定を構成するときに管理者が入力したマシンの 1 時間あたりのコストに基づいて計算されます。管理者が [すべてのデリバリーグループ] を選択すると、すべてのデリバリーグループの [推定節約額] の平均値が表示されます。

Autoscale-監視

概要

  1. 自動スケールにより、ユーザー経験値を犠牲にすることなく、より優れたコスト削減 (~ 300%) を実現できます。それはスケジュール/ロードベースの設定によって行われます
  2. より小さなサイズの仮想マシンを使用すると、水平負荷分散シナリオでのコスト削減が向上
  3. ゾーンの優先度とタグ付けを使用して、より多くのコスト削減を実現

参考文献:Autoscale の詳細については、 当社の技術文書を参照してください