マネージド インスタンス グループ(MIG)の自動スケーリングを構成して、負荷の増減に応じて仮想マシン(VM)インスタンスを自動的に追加または削除できます。ただし、アプリケーションの初期化に数分以上かかる場合は、リアルタイムの変化に応じてインスタンスを追加しても、アプリケーションの容量をすぐに増加できないことがあります。たとえば、負荷が大幅に大きくなった場合(ユーザーが最初に朝目覚めたときなど)、一部のユーザーが新しいインスタンスでアプリケーションを初期化している間に遅延を経験することがあります。
予測自動スケーリングを使用すると、初期化時間が長く、ワークロードが日単位または週単位の周期で定期的に変動する場合に、アプリケーションのレスポンス時間を改善できます。
予測自動スケーリングを有効にすると、Compute Engine は MIG の履歴に基づいて将来の負荷を予測し、負荷が到来するときに新しいインスタンスを提供できるように、予測された負荷の前に MIG をスケールアウトします。予測的な自動スケーリングなしでは、オートスケーラーは、リアルタイムで観測された負荷の変化に基づき、反応的にグループをスケールすることしかできません。予測自動スケーリングを有効にすると、オートスケーラーは、リアルタイム データと過去のデータだけでなく、現在の負荷と予測した負荷の両方にも対応します。詳細については、予測自動スケーリングの仕組みと予測自動スケーリングがワークロードに適しているかどうかの確認をご覧ください。
準備
- このガイドのコマンドラインの例を使用する場合は、Google Cloud CLI をインストールするか、Cloud Shell を起動します。
- オートスケーラーの基礎知識を確認します。
-
まだ設定していない場合は、認証を設定します。認証とは、Google Cloud のサービスと API にアクセスするために ID を確認するプロセスです。ローカル開発環境からコードまたはサンプルを実行するには、次のいずれかのオプションを選択して Compute Engine に対する認証を行います。
Select the tab for how you plan to use the samples on this page:
Console
When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud
-
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
- Set a default region and zone.
- 予測自動スケーリングは、スケーリング指標として CPU 使用率を使用する場合にのみ機能します。Cloud Load Balancing または Cloud Monitoring の指標はサポートされていません。
- Compute Engine が予測を生成するまでに、3 日間の CPU ベースの自動スケーリング履歴が必要です。
- 予測は、週単位および日単位の負荷のパターンに基づいています。Compute Engine は、月単位、年間、または 1 回限りのイベントを予測しませんし、10 分未満の負荷のパターンも予測しません。スケジュール ベースの自動スケーリングを使用して、1 回限りまたは他の負荷のパターン用の容量をリクエストできます。
- アプリケーションの初期化には時間がかかる場合です。たとえば、初期化期間を 2 分超に設定する場合です。
- ワークロードは、日単位または週単位のサイクルによって変動すると予測されます。
Cloud Console で、[インスタンス グループ] ページに移動します。
リストで既存の MIG の名前をクリックして、グループの概要ページを開きます。
[編集] をクリックします。
自動スケーリング構成が存在しない場合は、[自動スケーリング] で [自動スケーリングを構成] をクリックします。
[自動スケーリング モード] で [オン: グループに対してインスタンスを追加および削除します] を選択して、自動スケーリングを有効にします。
このグループでオートスケーラーが作成するインスタンスの数の最小値と最大値を指定します。
[自動スケーリング シグナル] セクションで、[CPU 使用率] の指標がまだ存在しない場合は 1 つ追加します。
- [シグナルを追加] をクリックします。
- [シグナルタイプ] プルダウンで、[CPU 使用率] を選択します。
- 設定する CPU 使用率の目標値を入力します。この値はパーセント値として扱われます。たとえば、75% の CPU 使用率を指定するには「
75
」と入力します。 - [予測オートスケーリング] で [可用性重視で最適化] を選択して、予測自動スケーリングを有効にします。
- 代わりに、予測アルゴリズムを無効にして、リアルタイム オートスケーラーのみを使用する場合は、[オフ] を選択します。
- [完了] をクリックします。
[初期化期間] で、新しいインスタンスでアプリケーションの初期化に要する時間を指定します。この設定により、予想される負荷よりも前にスケールアウトするように予測オートスケーラーに通知するため、負荷が到来したときにアプリケーションが初期化されます。
[保存] をクリックします。
optimize-availability
: 予測アルゴリズムを有効にするnone
(デフォルト): 予測アルゴリズムを無効にする- 予測自動スケーリングが有効。
- ターゲットの CPU 使用率が 75%。
- インスタンスの最大数を 20 に設定。
- 初期化期間(
--cool-down-period
)を 5 分に設定。この設定により、予想される負荷の 5 分前にスケールアウトするように予測オートスケーラーに通知するため、負荷が到来したときにアプリケーションが初期化されます。 OPTIMIZE_AVAILABILITY
: 予測アルゴリズムを有効にするNONE
(デフォルト): 予測アルゴリズムを無効にする- リージョン MIG の場合:
regionAutoscalers.insert
メソッドを呼び出す - ゾーン MIG の場合、
autoscalers.insert
メソッドを呼び出す - リージョン MIG の場合:
regionAutoscalers.patch
メソッドを呼び出す - ゾーン MIG の場合、
autoscalers.patch
メソッドを呼び出す - 予測自動スケーリングが有効。
- ターゲットの CPU 使用率が 75%。
- インスタンスの最大数を 20 に設定。
- 初期化期間(
coolDownPeriodSec
)を 5 分に設定。この設定により、予想される負荷の 5 分前にスケールアウトするように予測オートスケーラーに通知するため、負荷が到来したときにアプリケーションが初期化されます。 Cloud Console で、[インスタンス グループ] ページに移動します。
CPU ベースの自動スケーリングが構成されている既存の MIG をクリックします。グループの概要ページが開きます。
[編集] をクリックします。
[自動スケーリング] セクションの [自動スケーリング シグナル] で、[CPU 使用率] セクションを展開し、[予測オートスケーリングで可用性を最適化できるかどうかをご確認ください] をクリックします。
この表は、過去 7 日間のデータをもとに、1 日あたり使用された VM の数と、次の行で 1 日あたりの過負荷になった VM の数を示しています。
- 現在の自動スケーリング構成: オートスケーラーの構成に基づいたオートスケーラーの過去 7 日間のパフォーマンスが表示されます。
- 予測自動スケーリングを [可用性重視で最適化] に設定: 予測自動スケーリングを有効にした場合に過去 7 日間にオートスケーラーが示したであろうパフォーマンスが表示されます。
Cloud Console で、[インスタンス グループ] ページに移動します。
CPU ベースの自動スケーリングが構成されている既存の MIG をクリックします。グループの概要ページが開きます。
[モニタリング] をクリックして、グループに関連するグラフを表示します。
最初のグラフでタイトルをクリックし、[予測自動スケーリング] を選択します。このビューには、グループの実際のサイズと予測サイズが表示されます。
別の期間を選択してより多くの履歴を表示するか、需要が増大する期間にズームインして、負荷を予測する前に予測自動スケーリングがグループサイズに与える影響を確認できます。
- 予測されるスケーリング指標の将来的な値
- スケーリング指標の現在の値
- スケーリング指標の過去の変動性を含む、過去のトレンドの信頼性
- 構成済みのアプリケーションの初期化期間(初期化期間とも呼ばれます)
- 予測を適用します。予測は数分おきに常に再計算されるため、最新のデータが反映されるように調整されます。新しいパターンの調整の正確なタイミングは、とりわけ、新しいパターンの再現可能度と、新しいパターンと過去の予測との間の差の大きさによって異なります。
- リアルタイムのデータを優先します。指標のリアルタイム値に基づいてオートスケーラーが推奨するインスタンスの数は、常にグループの目標使用率を満たすのに十分です。リアルタイムのシグナルの現在の値が予測よりも大きい場合は、シグナルの現在の値が予測よりも優先されます。そのため、予測自動スケーリングが有効にしている MIG は、そうしていない MIG よりも常に可用性が高くなります。
- オートスケーラーの管理について学習する。
- オートスケーラーの決定方法について確認する。
- 複数の自動スケーリング信号を使用してグループをスケールする方法を確認する。
REST
このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
詳細については、Google Cloud 認証ドキュメントの REST を使用して認証するをご覧ください。
料金
予測自動スケーリングは無料です。ただし、可用性を最適化するために予測自動スケーリングを有効にすると、MIG が使用する Compute Engine リソースに課金されます。
制限事項
適切なワークロード
予測自動スケーリングは、ワークロードが次の基準を満たしている場合に最適に機能します。
サービスの初期化に長い時間がかかる場合、ユーザーはスケールアウト イベント後に、サービスのレイテンシ(新しい VM がプロビジョニングされているものの、まだ機能していない)を経験することがあります。予測自動スケーリングは、アプリケーションの初期化時間を考慮し、予測された使用量の増加前にスケールアウトして、目標使用率に十分な数のインスタンスが確実に機能するようにします。
予測自動スケーリングがグループに及ぼす影響を事前に確認するには、予測自動スケーリングがワークロードに適しているかどうかの確認をご覧ください。
予測自動スケーリングの有効化と無効化
CPU 使用率に基づいてスケールする場合、予測自動スケーリングを有効にできます。 CPU ベースの自動スケーリングの設定の詳細については、CPU 使用率に基づくスケーリングをご覧ください。
MIG にオートスケーラーの履歴がない場合、予測アルゴリズムがオートスケーラーに影響を与えるまでに 3 日ほどかかることがあります。この間、グループはリアルタイム データのみに基づいてスケーリングを行います。3 日後、グループは予測を使用してスケーリングを開始します。過去の負荷が収集されると、予測オートスケーラーは負荷パターンをより詳細に把握し、予測を改善します。Compute Engine は、MIG の負荷の履歴を最大で 3 週間使用して、機械学習モデルにフィードします。
Console
gcloud
MIG のオートスケーラーを設定または更新するときは、
--cpu-utilization-predictive-method
フラグで次のいずれかの値を設定します。グループで CPU ベースの自動スケーリングがまだ有効になっていない場合は、有効にする必要があります。
set-autoscaling
コマンドを使用すると、グループの自動スケーリング ポリシーを最初から構成できます。たとえば、次のコマンドは、次の設定で自動スケーリングを構成する方法を示しています。gcloud compute instance-groups managed set-autoscaling MIG_NAME \ --cpu-utilization-predictive-method optimize-availability \ --target-cpu-utilization 0.75 \ --max-num-replicas 20 \ --cool-down-period 300
グループで CPU ベースの自動スケーリングがすでに有効になっている場合は、
update-autoscaling
コマンドを使用して予測アルゴリズムを有効にします。gcloud compute instance-groups managed update-autoscaling MIG_NAME \ --cpu-utilization-predictive-method=optimize-availability
REST
オートスケーラーを作成または更新するときに、リクエストの本文に
predictiveMethod
フィールドを含めて次のいずれかの値を指定します。グループに既存の自動スケーリング構成がない場合は、以下のようにします。
グループにすでに自動スケーリング構成がある場合は、以下のようにします。
グループで CPU ベースの自動スケーリングがまだ有効になっていない場合は、有効にする必要があります。
たとえば、次のリクエストは既存のオートスケーラー リソースにパッチを設定し、CPU ベースの自動スケーリングを次の設定で有効にします。
PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/autoscalers/ { "name": "AUTOSCALER_NAME", "target": "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/MIG_NAME", "autoscalingPolicy": { "cpuUtilization": { "utilizationTarget": 0.75, "predictiveMethod": "OPTIMIZE_AVAILABILITY" }, "maxNumReplicas": 20, "coolDownPeriodSec": 300 } }
予測オートスケーラーが有効かどうかの確認
MIG の現在の自動スケーリング構成を表示するには、MIG のプロパティの取得をご覧ください。
予測自動スケーリングの構成
ターゲット使用率、インスタンスの最小数と最大数、初期化期間を構成する方法については、CPU 使用率に基づくスケーリングをご覧ください。これらのオプションを構成すると、予測オートスケーラーは、リアルタイム オートスケーラーと同じように、グループの最小および最大の範囲内で、設定した目標使用率レベルですべてのインスタンスを維持するように動作します。
初期化期間の設定を使用して、アプリケーションの初期化にかかる時間を考慮してください。この設定は、予測オートスケーラーが、予測される負荷の増加に先立って新しいインスタンスを開始するタイミングに影響を与えます。これにより、負荷が到来したときにアプリケーションがサービスを提供できるようになります。
予測自動スケーリングがワークロードに適しているかどうかの確認
予測自動スケーリングによってアプリケーションの可用性が改善するかどうかを確認するには、グループの現在の CPU ベースの自動スケーリング構成と予測自動スケーリングのパフォーマンスを比較します。比較を行うために予測自動スケーリングを有効にする必要はありません。
予測自動スケーリングに適したワークロードの詳細については、適切なワークロードをご覧ください。
過負荷の確認
自動スケーリングされた MIG は、平均 CPU 使用率が目標値を超えると過負荷になります。自動スケーリング構成によって、過去 7 日間に VM のオーバーロードが発生したかどうかを確認し、予測自動スケーリングによって過負荷を軽減できるかどうかを確認するには、以下の手順を完了します。
「1 日あたりの使用 VM 数」は費用のプロキシとして使用できます。たとえば、毎日の過負荷な VM 数を減らすために、予測オートスケーラーが VM をより早く作成し、より長く実行すると、追加料金が発生することがあります。
予測自動スケーリングのモニタリングとシミュレーション
Cloud Monitoring を使用してグループのサイズの履歴を可視化できます。モニタリング グラフには、自動スケーリングが時間とともにグループをスケーリングした様子が表示され、また、予測自動スケーリングが、有効にした場合に、グループをスケーリングした様子も示されます。
予測自動スケーリングが無効になっているグループでは、このツールを使用することで、予測自動スケーリングを、有効にする前にシミュレーションできます。
予測自動スケーリングの仕組み
予測オートスケーラーは、指標の履歴の傾向に基づいてスケーリング指標を予測します。予測は数分ごとに再計算され、これにより、オートスケーラーは予測を直近の負荷の変化にすばやく適応できます。予測オートスケーラーが予測を提供するには、それぞれのサービスの使用パターンを確定するために、少なくとも 3 日間の履歴が必要です。Compute Engine は、MIG の負荷の履歴を最大で 3 週間使用して、機械学習モデルにフィードします。
予測オートスケーラーは、以下を含む多くの要因に基づいて使用率目標の達成に必要な VM の数を計算します。
このような要因に基づいて、予測オートスケーラーは予想される需要より前にグループをスケールアウトします。
図 1:予測自動スケーリングがある場合とない場合の機能を提供する VM の比較。
図 1 では、青色の線が VM の需要の増加を示しています。黒色の線はオートスケーラーのレスポンスを示しています。より多くの VM が追加されています。ただし、初期化時間が長いアプリケーションの場合、灰色の線は、追加された VM は提供の準備が完了するまでに追加の時間がかかるため、需要を満たすのに十分な機能を提供する VM がないことになる可能性を示しています。予測自動スケーリングを有効にすると、予測される需要の増加とアプリケーションの初期化時間の長さを考慮して、オートスケーラーは早く VM を追加して応答し、十分な数の VM が機能を提供することになります。初期化期間を設定することで、どれだけ前に新しいインスタンスが追加されるかを構成できます。
リアルタイムの使用状況データ
予測オートスケーラーは、過去のデータに基づいて将来のすべての変更パターンを確定できないため、リアルタイム データでもシームレスに動作します。たとえば、予期せぬニュース イベントが、履歴のみに基づいて予測できなかった使用量の急増の原因となったことがあります。このような予測できない負荷の変化を処理するために、予測オートスケーラーは次のように応答します。
図 2.予測が実際の CPU 使用率にどう適応するかを示す 2 つのグラフ。
図 2 では、黄色の点線が t1 での予測を示しています。しかし、実際の CPU 使用量は、青の実線で示されているとおり、予測とは異なります。左側のグラフでは、実際の CPU 使用率は予測よりも高くなっています。右側のグラフでは、実際の CPU 使用率は予測よりも低くなっています。青い点線は、調整された予測を示しています。
短期間の予測できない急増
短い、予測できないピークはリアルタイムで処理されます。オートスケーラーは、指標の現在の実際の値に基づいて、構成されているターゲットでの使用率を維持するために、少なくとも必要最低限の数のインスタンスを作成します。ただし、次の図に示すように、これらのインスタンスは事前に作成されません。
図 3.短時間の予想外の急増により、オートスケーラーがリアルタイムで対応します。
図 3 では、青色の実線は実際の CPU 使用率を示しています。CPU 使用率の予期外の急増は予測できませんでした。オートスケーラーは常にリアルタイム データを監視するため、急増に対応できるようにインスタンスが追加されます。黒色の実線は、急増に応じた VM のオートスケーラーの事後対応を示します。グレーの実線は、サービス提供中の VM の数を示しています。アプリケーションの初期化時間のため、灰色の線は黒色の線より遅れます。このシナリオでは、グループが一時的に過負荷になります。
急激な下落
使用量の予想外の変化のもう 1 つのタイプは急激な下落です。たとえば、アプリケーション スタックの部分の障害によって下落が生じます。その場合、インスタンスの数は最初は予測に従います。ただし、時間が経つにつれて予測より低い使用率に予測が調整されるので、スケールインになります。この調整の正確なタイミングは、パターンが過去に発生した頻度、急落が持続する時間、急落の大きさなど、さまざまな要因によって変わります。
図 4.急落によって、予測オートスケーラーが予測を変更します。
図 4 では、黄色の点線が t1 での予測を示しています。しかし、実際の CPU 使用量は、青の実線で示されているとおり、予測よりも低くなっています。青い点線は更新された予測を示しています。予測は、予測使用量の減少が観測されると自動的に調整されます。これにより、オートスケーラーは標準の安定化期間に沿ってインスタンスを削除します。
過去のデータ
予測オートスケーラーが予測を開始するには、少なくとも 3 日間の負荷の履歴が必要です。履歴データがない新しい MIG の場合、Compute Engine は、十分な履歴データが使用できるまで、リアルタイム データを反応的に使用して、スケーリングします。3 日後、Compute Engine は追加の使用状況データを収集するため、予測は改善します。
新しい MIG を作成し、アプリケーションを削除してアプリケーションを更新する場合(たとえば、Blue/Green デプロイなど)、新しい MIG で、予測自動スケーリングが予測の生成を再開できるまで、3 日間の負荷の履歴データが必要です。MIG 全体の負荷の履歴を保存して、新しい MIG を作成するときに予測をすぐに開始できるようにする場合は、お問い合わせいただき、限定公開プレビューに参加するための手順をリクエストしてください。
次のステップ
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2024-12-05 UTC。
-