マネージド インスタンス グループを作成してその自動スケーリングを構成するには、次の手順を実行します。

1. メニューのCompute Engineセクションの [インスタンス グループ] ページに移動し、[インスタンス グループの作成] ボタンをクリックします。
2. [名前]フィールドにインスタンス グループ名を入力します。
3. [グループ タイプ] 設定で[マネージド インスタンス グループ]を選択します。
4. [自動スケーリング] ドロップダウン リストから [オン] オプションを選択して、インスタンス グループの自動スケーリングを有効にします。
5. [自動スケーリングポリシー] ドロップダウン リストから必要なスケーリング ポリシーを選択します。スケーリング ポリシーには、インスタンス グループのサイズを増減するためのルールが含まれています。システムは、ユーザーが定義したターゲット レベルでポリシーの基準となるメトリックを維持するために、グループからインスタンスを追加または削除するタイミングを決定します。次のポリシーのいずれかを選択できます。
   1. CPU 使用率: グループのサイズは、グループ内の仮想マシンの平均プロセッサ負荷を必要なレベルに保つために制御されます (CPU 使用率ポリシー ドキュメント)。
   2. HTTP 負荷分散の使用: グループのサイズは、HTTP トラフィック バランサーの負荷を必要なレベルに保つために制御されます (HTTP 負荷分散の使用ポリシー ドキュメント)。
   3. Stackdriver Monitoring 指標: グループのサイズは、Stackdriver Monitoring インストゥルメントから選択された指標を必要なレベルに保つために制御されます（Stackdriver Monitoring 指標ポリシー ドキュメント）。
   4. 複数のメトリック: グループのサイズを変更する決定は、複数のメトリック (複数のメトリック ポリシー ドキュメント) に基づいて行われます。

   このガイドでは、CPU 使用率ポリシーを使用して、Auto Scaling メカニズムを操作する原則を示します。 このポリシーを適用するには、必要な平均プロセッサの負荷レベルを [ターゲット CPU 使用率] フィールド (パーセンテージ) で指定します。 例 次の構成では、平均的な仮想マシン プロセッサの負荷を 60% レベルに維持するためのインスタンス グループ サイズの制御について説明します。

6. [インスタンスの最小数] フィールドにインスタンス グループの最小サイズを指定します (例: 2 つのインスタンス)。
7. [インスタンスの最大数] フィールドにインスタンス グループの最大サイズを指定します (例: 10 インスタンス)。
8. [冷却期間] フィールドに、新しく追加されたインスタンスからメトリック値を記録しない期間を指定します (例: 60 秒)。これは、新しいインスタンスを追加した後にリソース消費が急増する場合に必要になることがあります。クールダウン期間の要件 クールダウン期間は、インスタンスの初期化に必要な時間よりも長くする必要があります。
9. インスタンス グループのすべてのパラメータが正しく構成されていることを確認してから、[作成] ボタンをクリックします。

Auto Scaling グループが正常に作成されると、指定された数のインスタンスが自動的に起動されます。 グループ内で起動されたインスタンスの数を表示し、このデータ ポイントを Wallarm クラウドに接続されているフィルタリング ノードの数と比較することで、Auto Scaling グループが正しく作成されたことを確認できます。 これは Wallarm Console を使用して実行できます。たとえば、ノードをフィルタリングする 2 つのインスタンスが同時に動作している場合、Walarm コンソールは、対応する Wallarm ノードのこの数を [ノード]セクションに表示します。 これで、ロード バランサーの作成と構成に進むことができます。
投稿者: 08:05 Google Cloud で自動スケーリングを有効にする方法についてはコメントを受け付けていません。

Google Cloud で自動スケーリングを有効にする方法

Google Cloud Autoscaling の導入

Google Cloud プラットフォームは、負荷の増減に基づいてマネージド インスタンス グループからインスタンスを自動的に追加または削除できる自動スケーリング機能を提供します。Google Cloud Autoscaling は、アプリケーションが増加したトラフィックを適切に処理し、リソースの必要性が低いときにコストを削減するのに役立ちます。自動スケーリング ポリシーを説明するだけで、オートスケーラーは測定された負荷に基づいて自動スケーリングを実行します。

自動スケーリングの基本概念

自動スケーリングでは、次の基本的な概念とサービスが使用されます。

1. インスタンス テンプレート:
   

   インスタンス テンプレートは、VM インスタンスとマネージド インスタンス グループの作成に使用されるリソースです。マシンタイプ、ブートディスク イメージまたはコンテナ イメージ、ラベル、その他のインスタンス プロパティを指定します。その後、インスタンス テンプレートを使用して、マネージド インスタンス グループまたは個々のインスタンスを作成できます。インスタンス テンプレートは、インスタンスの構成を保存するための便利な方法です。後でそれを使用して、新しいインスタンスまたはインスタンスのグループを作成できます。同一の構成で VM インスタンスを作成します。

2. マネージド インスタンス グループ:
   

   マネージド インスタンス グループは、インスタンス テンプレートから作成された同種のインスタンスのグループです。オートスケーラーは、スケーリング ポリシーに基づいてマネージド インスタンス グループからインスタンスを追加または削除します。GCP Compute Engine にはマネージド インスタンス グループとアンマネージド インスタンス グループの両方がありますが、Google Cloud Autoscaling に使用できるのはマネージド インスタンス グループのみです。

3. 自動スケーリング ポリシーと目標使用率:
   

   オートスケーラーを作成するには、オートスケーラーがグループをスケーリングするタイミングを決定するために使用する、自動スケーリング ポリシーと目標使用率レベルを指定する必要があります。

次のポリシーを使用してスケーリングすることを選択できます

• 平均 CPU 使用率
• HTTP ロード バランシングの処理能力。これは、使用率または 1 秒あたりのリクエスト数に基づく場合があります。
• Stackdriver Monitoring の指標オートスケーラーは、ポリシーに基づいて情報を収集します。次に、それを目的のターゲット使用率と比較し、スケーリングを実行する必要があるかどうかを判断します。

Google Cloud 自動スケーリングの種類

1. CPU 使用率に基づくスケーリング:

   マネージド インスタンス グループの平均 CPU 使用率に基づいて自動スケーリングできます。オートスケーラーは、グループ内のインスタンスの CPU 使用率を収集し、スケーリングが必要かどうかを判断します。オートスケーラーが維持するターゲット CPU 使用率を設定すると、オートスケーラーはそのレベルを維持するように動作します。 オートスケーラーは、ターゲット CPU 使用率レベルを、インスタンス グループ内の時間の経過に伴うすべての vCPU の平均使用率の割合として計算します。合計 vCPU の平均使用率が目標使用率を超えている場合、オートスケーラーはさらに仮想マシンを追加します。たとえば、目標使用率を 0.75 に設定すると、オートスケーラーはインスタンス グループ内のすべての vCPU の平均使用率を 75% に維持しようとします。

2. 負荷分散の処理能力に基づくスケーリング:

   Compute Engine は、インスタンス グループ内の負荷分散をサポートします。インスタンスの負荷に基づいてスケーリングするオートスケーラーを設定することで、負荷分散で自動スケーリングを使用できます。 ロードバランサはバックエンド サービス全体に負荷を分散し、インスタンス グループ間でトラフィックを分散します。バックエンド サービスでは、インスタンス グループの負荷分散容量を、グループの最大 CPU 使用率、1 秒あたりの最大リクエスト数 (RPS)、または 1 秒あたりの最大リクエスト数として定義できます。インスタンス グループが処理能力に達すると、バックエンド サービスは別のインスタンス グループへのトラフィックの送信を開始します。 オートスケーラーをロード バランサーにアタッチすると、オートスケーラーはマネージド インスタンス グループをスケーリングして、負荷分散処理能力の一部を維持します。 たとえば、マネージド インスタンス グループの負荷分散処理能力がインスタンスあたり 100 RPS であり、目標使用率レベルを 0.8 または 80% に維持するために負荷分散ポリシーを使用して自動スケーリングを作成したとします。次に、オートスケーラーは、インスタンスごとに 80 RPS を維持するために、マネージド インスタンス グループに対してインスタンスを追加または削除します。

3. Stackdriver Monitoring 指標に基づくスケーリング:

   メトリクスに基づいて自動スケーリングを設定できます。指標は、Stackdriver Monitoring サービスによって提供される標準指標、または作成したカスタム Stackdriver Monitoring 指標のいずれかです。Stackdriver 指標を使用して自動スケーリングを定義するには、次の 2 つの方法があります。

   • インスタンスごとの指標: グループ内の各インスタンスのデータを個別に提供します。これらの指標は、マネージド インスタンス グループ内の各インスタンスのデータを提供します。オートスケーラーが動作するには、少なくとも 1 つの実行中のインスタンスからの指標が必要なため、インスタンス グループは 1 インスタンスのサイズ未満にスケーリングできません。
   • グループごとの指標: グループごとの指標では、インスタンスごとの使用率データを使用しない標準またはカスタム指標による自動スケーリングが可能です。代わりに、インスタンス グループは値に基づいてスケーリングされます。値はグループ全体に適用され、グループで使用可能な作業量またはグループのビジー状態に対応します。このグループは、そのグループ メトリック値の変動と、定義した構成に基づいてスケーリングします。

探す

免責事項

このブログで提供されるすべてのコンテンツは、情報提供のみを目的としています。Tudip Technologies は、このサイト上の、配布、リンク、ダウンロード、またはアクセスされる情報またはコンテンツの正確性、信頼性、完全性、適合性、または有効性について保証を提供せず、表明も行いません。Tudip Technologies は、この情報のエラー、省略、または遅延、またはこのサイト上の情報の表示または使用に起因する損失、傷害、または損害について責任を負いません。すべての情報は現状のままで提供され、改善を行ったり、エラーや脱落を修正する義務はありません。このサイトには、他のウェブサイトへのリンクが含まれている場合があります。Tudip Technologies は、これらの Web サイトに関していかなる保証も約束もせず、必ずしもそれらのコンテンツを支持または承認するわけではありません。ブログのいかなる部分も変更することはできません。Tudip Technologies の明示的な許可なしに、このブログの一部を別の作品に含めること (印刷、電子、またはその他の形式を問わず)、またはリンク、フレーミング、またはその他の方法で別の Web サイトにブログの一部を含めることは禁止されています。このサイトは、違法または違法な目的で使用することはできません。Tudip Technologies は、独自の裁量により、いかなる種類の通知もなしに、このサイトに投稿されたものを削除する権利を留保します。このサイトを使用することにより、あなたは、いかなる資料への依存もあなたの単独の責任であることを認めるものとします. Google Cloud で巨大なマーキー キャンペーン サイトを管理していた頃、Twitter や TV チャンネルなどでのマーケティング キャンペーンによるトラフィックの急増に耐えられるように、ウェブ層が自動的にスケーリングできるようにする必要がありました。自動スケーリングのステップ バイ ステップ ガイドAWS の記事は数十件ありますが、Google Cloud に関する同様の記事は見つかりませんでした。しかし、Google Cloud のドキュメントは、AWS のドキュメントに次ぐ素晴らしいものです。忙しいウェブサイトの自動スケーリングを既に構成し、実際に動作していることを確認したので、それを文書化することは将来誰かを助けると考えました. 以下は、Google クラウドで自動スケーリングを構成する方法を説明する最小限のコメント付きの一連のスクリーンショットです。

Image のインスタンスを準備する

オートスケーラーでは、特定の条件が満たされたときにインスタンスを動的にスピンできるイメージを使用できる必要があります。この例では、自動スケーリング用の単純な Apache/PHP サーバーを検討し、それに応じてイメージを準備します。

• お好みのインスタンスタイプを起動
• Apache、PHP、およびその他の必要なパッケージをインストールします
• コードをデプロイして動作するかどうかをテストする
• インスタンスが起動時に特定のタスクを実行する必要がある場合は、起動スクリプトを追加します。たとえば、最新のコードを git リポジトリからプルして、起動時にデプロイすることができます。

これらがすべて完了したら、インスタンス設定に移動し、インスタンスの削除時に [ブート ディスクの削除] オプションを無効にします。はい、このインスタンスを削除して、そこからイメージを作成します。 ここで、インスタンスを起動するブートディスクを削除せずに、このインスタンスを削除します。 このディスクから新しいイメージを作成します。 イメージが作成されているかどうかを確認します。

インスタンス テンプレートの作成

これまでのところ、インスタンスをスピンできるブートディスクがありますが、Google Cloud はスピンしたいインスタンスの種類を認識していません。サイズ、タイプは？ここでインスタンス テンプレートが介入します。必要に応じてインスタンス テンプレートを作成する必要があります。 GCE コンソールで、[インスタンス テンプレート] ページに移動します。[新しいインスタンス テンプレートの作成] をクリックします。インスタンス テンプレートに次の情報を入力します。

• 名前
• マシンタイプ
• ブートディスク (これは前のステップで作成したものです)
• トラフィックを許可します。必要に応じて、HTTP/HTTPS またはその他のもの。
• 他の Google Cloud サービスと通信する場合は、API アクセスを許可します
• テンプレートを作成する

インスタンス グループを作成する

Google Cloud には、マネージド グループまたは非マネージド グループのインスタンス グループがあります。Compute Engine の場合、共通の特性を持ち、特定の条件に応じてスケーリングできるマネージド インスタンス グループが必要です。インスタンス グループはインスタンス テンプレートに依存しており、テンプレートは既に処理されています。では、インスタンス グループを作成しましょう

ロードバランサーを作成する

通常、スケールアウトは負荷分散に依存するため、これには負荷分散が必要です。それでは、先に進んで構成しましょう。Google Compute のロードバランサーは、基本的な AWS ELB または Azure ロードバランサーと比較して桁違いに進んでいます。これについては後で詳しく説明します。この記事では、Network Loadbalancer を使用します — 次 – それはそれについてです。アプリケーションは、構成方法に応じてスケールアップおよびスケールダウンされます。これが役に立ったことを願っています！ 自動スケーリングは、AWS や Google Cloud Platform などの多くのクラウド プロバイダーが提供する機能であり、ネットワーク内の新しいサーバーの作成と削除を自動的に処理し、さまざまな負荷に合わせてアプリケーションをスケーリングできるようにします。

オートスケーリングとは?

ロード バランサーの背後に 2 つのサーバーがあり、どちらもトラフィックの半分を均等に処理しているとします。より多くの需要を処理する必要がある場合は、別のサーバーを追加します。ただし、この需要は周期的であることが多く、負荷が高くなると毎日ピークに達するため、これを手動で処理するのは面倒です。 自動スケーリングは、名前が示すように、自動的に処理します。サーバーのコピーを最初から起動するために使用される事前構築済みのテンプレートを定義します。ネットワークが所定の負荷量 (たとえば 70% の CPU 使用率) に達すると、Auto Scaling が新しいインスタンスを起動して問題を解決します。落ち着いたら、数またはインスタンスを縮小します。 もちろん、このテンプレートの設定は簡単ではありませんが、GCP にはコンテナをマシン イメージとして使用できるなど、これを簡単にするためのツールがあります。 Auto Scaling を使用すると、任意の量の需要に合わせてスケールアップできますが、不要になったときにスケールダウンすることでコストを節約することもできます。従来のサーバー ホスティングでは、ピーク需要に備えて計画を立てる必要があります。サーバーがピーク トラフィックを処理できない場合は、より優れたサーバーが必要です。ただし、これは通常、お金の無駄です。アプリケーションの負荷がピークに達していない時間外は、必要以上の料金を支払うことになるからです。 1 つまたは 2 つのサーバーしか使用していない場合でも、Auto Scaling を設定すると、ネットワークがトラフィック アクティビティのスパイクを処理するのに役立ち、高可用性ネットワークにとって便利な機能です。

マネージド インスタンス グループの設定

GCP 管理コンソールから、[Compute Engine] > [インスタンス グループ] を選択します。 新しいインスタンス グループを作成し、[新しいマネージド インスタンス グループ] を選択します。 このグループを複数のゾーンにわたって生成するように設定できます。これは、高可用性に適しています。ただし、各インスタンス グループは 1 つのリージョンに固定され、この設定は永続的です。サーバーを配置する予定の他のリージョンごとに、追加のインスタンス グループを作成する必要があります。 もちろん、サーバーに配置するデータと、Auto Scaling グループの新しいノードを起動する方法を定義するために、インスタンス テンプレートをセットアップする必要があります。すでにお持ちの場合は、ここで選択してください。そうでない場合は、設定に関するガイドをお読みください。 その下に、Auto Scaling の設定があります。既定のモードでは自動スケールアップとスケールダウンが行われますが、スケールインを無効にして、ネットワークのスケールアップのみを行うことができます。使用するメトリックを Auto Scale に設定することもできます。これは、デフォルトで CPU 使用率が 60% に設定されています。 クールダウン期間は基本的に、新しいサーバーがロードされるまでにかかる時間です。サーバーがすべてをセットアップするのに 1 ～ 2 分かかる場合、セットアップ中に GCP がこれらの指標を調べないようにする必要があります。予想外に高い CPU 使用率。 インスタンスの最小数と最大数を変更して、それぞれパフォーマンスを確保し、コストを制限することもできます。 最後の機能は自動修復です。これは、各インスタンスで実行されているサービスに対して定期的にヘルス チェックを実行します。インスタンスが動作し始めた場合、簡単に置き換えることができます。ロード バランサーがある場合、トラフィックは自動的にルーティングされますが、自動修復なしではインスタンス自体は修正されません。この機能を有効にすることをお勧めします。 「作成」をクリックすると、最小数のインスタンスが作成されます。Compute Engine コンソールから個別に管理するか、インスタンス テンプレートを管理してグループ全体の設定を編集できます。 次を読む

• › すべてのデバイスで Google からサインアウトする方法
• › イベント計画に Microsoft Excel テンプレートを使用する方法
• › Instagramでフォロワーを削除する方法
• › 天文学者が地球に最も近いブラックホールを発見 (まだ遠い)
• › Windows 11 タスクバーにポップアップ ヒントを表示する準備をする
• › AMD の新しい RX 7000 GPU は本当に良くて本当に安い

従量課金制のインフラストラクチャでトラフィックが増加すると、不安になりますか? 特に Google Cloud Platform 環境で運用している場合はそうすべきではありません。仮想マシン (VM) と Kubernetes クラスターに向かうトラフィックを管理できます。 このブログを見て、「これってどういうこと？」決して恐れるな。それが、現在進行中の GCP 101 シリーズのすべてです。Google Cloud Platform と、組織に適したクラウド環境を構築するために使用できるすべての機能について、しっかりと紹介しています。 最近、Google Compute Engine を使用して、物理サーバー上の VM でアプリを実行する方法について説明しました。次に、関連する機能である自動スケーリングと、それがトラフィック パターンとクラウド予算を最大限に活用するのにどのように役立つかを見ていきます。 自動スケーリングは、計算能力を動的に追加することでアプリがトラフィックの増加を効率的に処理できるようにするツールですが、トラフィックとリソースの需要が少ない期間に容量とコストを削減することもできます。 Google Compute Engine はマネージド インスタンス グループ (MIG)、またはテンプレートと呼ばれる同じ API リソースから作成された一般的な VM インスタンスのコレクションを使用して、アプリケーションへのトラフィックと需要に基づいてインスタンスを自動的に追加または削除します。MIG は、同じアプリケーションに対して信頼性の高い可用性とパフォーマンスを提供する複数の同一の VM です。これらは 1 つのエンティティとして管理されるため、自動スケーリングを使用するのに最適なシナリオです。 同様に、マネージド Kubernetes サービスである Google Kubernetes Engine (GKE) と、コンテナ化されたアプリケーションをデプロイするためのフルマネージド コンピューティング プラットフォームである Cloud Run はどちらも、ワークロードの需要に基づいてノードまたはコンテナ インスタンスの数を自動的にサイズ変更する自動スケーリングをサポートしています。詳細については、進行中の Kubernetes 101 シリーズを参照してください。 負荷分散について言えば、これも方程式の重要な部分です。これは、最も近い VM または MIG 内で最も利用可能な容量を持つ VM へのトラフィックのルーティングと分散を処理します。 ロード バランシングは、ヘルス チェックを使用して MIG 内の異常な VM を検出して削除したり、再び使用可能/正常になったインスタンスを追加したりするのにも役立ちます。

Google Cloud での自動スケーリングの仕組み

最も基本的なレベルで自動スケーリングを開始するには、CPU ターゲット リソースの使用率レベルを決定する必要があります。これは、VM とコンテナー インスタンスを維持するレベルです。 50%、75%、またはその他のレベルのいずれであっても、到達したいパーセンテージを自問してください。 これを決定したら、目標使用率レベルを中心とした自動スケーリング ポリシーを作成する必要があります。 自動スケーリングは、MIG を継続的に監視し、作成したポリシーに基づいて使用状況情報を収集します。 実際の使用率をターゲットと比較して、指定したレベルにできるだけ近い CPU 使用率レベルを維持するために、どのグループをスケールアップまたはダウンする必要があるかを判断します。これは、VM インスタンスを MIG に追加または削除して、目的の使用率レベルを維持することによって行われます。 自動スケーリングを設定して、使用率または 1 秒あたりのリクエストに基づいて処理能力の負荷を調整することもできます。インスタンスの処理能力は、バックエンド サービス、バックエンドの接続に使用される一連の値、およびさまざまなディストリビューションおよびセッション設定を通じて定義します。これについては、今後のブログで詳しく説明します。

Google Cloud での自動スケーリングの利点は何ですか?

リソースの需要とトラフィックに基づいて VM を追加または削除できるため、アプリケーションのワークロードに適したタイミングで適切な量のリソースを使用する、復元力があり費用対効果の高い Google Cloud インフラストラクチャを構築できます。 このインテリジェントで動的なスケーリング ツールは、予算と比較して実際の支出を抑えるのに役立ち、予期しないスパイクが発生した場合でも、支出を削減し、従量課金制のサプライズを排除します。アプリのワークロードを処理するために、常に適切な数の Google Compute Engine インスタンスを利用できるようにすることができます。