Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

コンピューティングプロビジョニングを最適化する

単一のマシンタイプまたはゾーンに依存するようにワークロードを構成すると、需要の急増時に利用可能なリソースにアクセスする能力が制限される可能性があります。コンピューティングのプロビジョニングを最適化し、需要の急増時にワークロードを継続的に実行するには、柔軟な Compute Engine インフラストラクチャを設計する必要があります。インフラストラクチャの柔軟性により、1 つの固定構成ではなく、複数のゾーン、マシンタイプ、開始時間を指定できます。Compute Engine は、ユーザーが指定したオプションから自動的に選択するため、リソースの可用性を最大化し、費用対効果を高め、最新のハードウェアを安全に導入できます。

このドキュメントでは、インフラストラクチャの柔軟性の側面、そのメリット、ワークロードに適したアプローチを選択する方法について説明します。また、関連する Compute Engine の機能、設計上の考慮事項、導入手順についても説明します。このドキュメントは、コンピューティングインフラストラクチャを設計または管理するソリューションアーキテクト、インフラストラクチャオペレーター、クラウドエンジニアを対象としています。

インフラストラクチャの柔軟性

インフラストラクチャの柔軟性は、次の 3 つのディメンションで設計できます。

ロケーションの柔軟性（場所）: リージョン内の複数のゾーンに Compute Engine インスタンスを分散して、利用可能なリソースへのアクセスを最大化するか、レイテンシの影響を受けやすいワークロード用に利用可能な容量を持つ単一のゾーンを自動的に選択します。
マシンタイプの柔軟性（内容）: 互換性のあるマシンタイプのランク付けされたリストを指定します。これにより、ワークロードは必要に応じて代替を使用できます。
時間の柔軟性（タイミング）: すぐに開始する必要のないワークロードに対して、アクセラレータなどの需要の高いリソースのリクエストをキューに登録し、即時のプロビジョニングを要求しないようにします。

柔軟なインフラストラクチャの特典

柔軟な Compute Engine インフラストラクチャを採用すると、次のようなメリットがあります。

需要の急増時の容量管理を自動化します。ワークロードは、複数のマシンタイプとゾーンにわたってリソースを自動的に検索して使用します。このアプローチにより、優先ハードウェアが一時的に利用できなくなっても、スケーリングリクエストが成功します。
容量管理を簡素化します。使用可能なハードウェアを手動で検索する運用オーバーヘッドを削減できます。Compute Engine は、フォールバック設定に基づいてリクエストを自動的にリダイレクトし、運用のボトルネックを軽減します。
最新のハードウェアへの移行時の容量リスクを軽減します。最新のハードウェア世代を優先し、古い世代をフォールバックとして保持するようにデプロイを構成できます。この設定により、最新のマシンが使用できない場合でも、デプロイで古いマシンの容量を自動的にリクエストできるため、最新の需要の高いマシンを導入するリスクが軽減されます。
ベースライントラフィックとピークトラフィックの費用を最適化します。容量を予約できるのは、既知のベースライントラフィックのみです。予測不可能なスパイクを処理するには、マシンタイプのフォールバックを使用します。このアプローチにより、アイドル状態のバックアップ容量の費用を削減できます。コンピューティングフレキシブル確約利用割引（CUD）を使用すると、マシンシリーズとリージョン全体で割引範囲を維持することもできます。これにより、ワークロードがマシンシリーズまたはリージョンを切り替えるときにオンデマンド料金が発生するのを防ぐことができます。

柔軟性のディメンションの比較

ロケーションの柔軟性は、マシンタイプまたは時間の柔軟性と組み合わせることができます。ただし、マシンタイプの柔軟性と時間の柔軟性は、1 つのデプロイで互換性がありません。ハードウェアフォールバックオプションを選択するか、リソースが使用可能になるまでキューで待機する必要があります。

これらのオプションを評価するうえで、次の表は各柔軟性ディメンションの仕組みを比較したものです。特定のユースケースに適したアプローチについては、ワークロードの適合性と推奨事項をご覧ください。

	場所の柔軟性（どこで）	マシンタイプの柔軟性（内容）	時間の柔軟性（いつ）
可用性を向上させる仕組み	リージョン内の複数のゾーンにわたって利用可能なリソースへのアクセスを最大化します。	互換性のある代替マシンタイプにフォールバックすることで、使用できないリソースエラーが発生する可能性を減らします。	リクエストをキューに入れて容量が使用可能になるまで待機することで、需要の高いリソースを取得します。
プロビジョニングのタイムライン	即時	即時	キューに格納済み
プロビジョニング方法	選択したゾーンの可用性に基づいてコンピューティングインスタンスをプロビジョニングします。	選択したマシンタイプ全体での可用性に基づいてコンピューティングインスタンスをプロビジョニングします。	リクエストされた容量がすべて使用可能になると、コンピューティングインスタンスをプロビジョニングします。
マシンタイプのサポート	ゾーン間で 1 つまたは複数のマシンタイプをサポートします。	複数のマシンタイプを使用します。	単一のマシンタイプのみをサポートします。

ワークロードの適合性と推奨事項

インフラストラクチャの柔軟性を採用するかどうかは、ワークロードのアーキテクチャとパフォーマンス要件によって異なります。最適なアプローチを選択できるように、次の表に一般的なワークロードタイプにおすすめの柔軟性のディメンションと構成をまとめます。

ワークロードタイプ	柔軟性に関する推奨事項
ステートレスバッチ処理、分離されたハイスループットコンピューティング（HTC）	ロケーションとマシンタイプの柔軟性: 次のいずれかでインスタンスの柔軟性ポリシーを使用します。 `ANY` 分布形状のリージョンマネージドインスタンスグループ（MIG）最小カウントが構成され、部分的な充足が許可され、`ANY` 分布形状が構成されているリージョン一括コンピューティングインスタンスの作成これらのアプローチにより、ワークロードをさまざまなゾーンとマシンタイプにスケーリングして、リソースの可用性を最大化できます。
AI/ML のトレーニング、ファインチューニング、大規模なバッチジョブ	時間の柔軟性: Dynamic Workload Scheduler（DWS）を使用するプロビジョニングモデルを使用します。このアプローチでは、リクエストをキューに配置することで、即時のオンデマンドプロビジョニングを必要とせずに、アクセラレータなどの需要の高いリソースへのアクセスを改善します。
マイクロサービスとウェブフロントエンド	ロケーションとマシンタイプの柔軟性: `BALANCED` ターゲット分配形態とインスタンスの柔軟性ポリシーを使用して、リージョン MIG を使用します。予測可能な自動スケーリングのために、vCPU とメモリの数が一致するマシンタイプを選択します。また、修復時の更新を有効にして、再作成されたコンピューティングインスタンスが最新のインスタンスの柔軟性構成を使用するようにします。
高可用性データベース	ロケーションの柔軟性とマシンタイプの柔軟性: `BALANCED` ターゲット分配形態のリージョン MIG を使用して、高可用性を実現するためにレプリカを複数のゾーンに分散します。パフォーマンスプロファイルがほぼ一致するマシンタイプを選択して、レプリカ間のパフォーマンスのばらつきを防ぎます。注: 予約を使用して、決定論的なハードウェア要件の物理容量を確保します。
レイテンシが厳密に制限されたシステム	ロケーションの柔軟性: `ANY_SINGLE_ZONE` 分布形状のリージョン MIG を使用します。このシェイプは、リージョン内のすべてのゾーンを検索して十分な容量を見つけ、すべてのインスタンスを同じゾーンに配置して低レイテンシを維持することで、ロケーションの柔軟性を実現します。

柔軟な構成では、アプリケーションのパフォーマンスに影響する可能性のあるハードウェアのバリエーションが発生する可能性があります。柔軟性を重視した設計を行う場合は、リソースの可用性を最大化することと、一貫したパフォーマンスを維持することの間のトレードオフを評価します。ガイダンスについては、柔軟なインフラストラクチャを評価して導入するのセクションをご覧ください。

Compute Engine の柔軟性に関する主な機能

容量管理を自動化するには、インフラストラクチャの複数のレイヤにわたって柔軟性を実装します。Compute Engine には、場所、マシンタイプ、時間の柔軟性を実現する機能が用意されています。これらの機能は個別に構成することも、ワークロードの要件に合わせて組み合わせることもできます。

ロケーションの柔軟性機能

ロケーションの柔軟性機能は、リージョン内の複数のゾーンにコンピューティングインスタンスを分散することで、リソースの可用性を最大限に高めます。このメリットを最大限に活用するには、優先マシンタイプがすべてのゾーンで利用可能なリージョンを選択します。

ロケーションの柔軟性は、次のデプロイタイプに適用できます。

MIG: リージョン MIG は、インスタンスの作成時とメンテナンス時の両方でリアルタイムの容量を評価し、リソースが利用可能な場所にコンピューティングインスタンスをプロビジョニングします。インスタンスの修復中にゾーンの容量が不足すると、ANY または BALANCED シェイプを使用する MIG は、障害が発生したコンピューティングインスタンスを別のゾーンに自動的に再作成できます。最適な結果を得るには、ワークロードの目標に基づいてターゲット分布形状を構成します。
- ANY: 最大の可用性を実現するためにおすすめします。この形状を使用して、リソースの可用性を最大化します。このシェイプは、使用可能な容量があるゾーンにコンピューティングインスタンスを割り当て、未使用の予約を優先します。
- BALANCED: 高可用性におすすめします。この形状は HA ワークロードに使用します。コンピューティングインスタンスをゾーン間で均等に分散してゾーンの停止から保護しながら、リソースが使用可能なゾーンを優先します。
- ANY_SINGLE_ZONE: 低レイテンシに推奨されます。この形状は、厳密なレイテンシ境界に使用します。MIG 内のすべてのコンピューティングインスタンスを、利用可能なリソースが最も多い単一のゾーンに割り当てます。
詳細については、リージョン MIG についてをご覧ください。
非マネージドインスタンスグループ: これらのグループは、ロケーションの柔軟性をネイティブでサポートしていません。代わりに、regionInstances.bulkInsert API を使用してコンピューティングインスタンスを一括で作成します。この API では、ANY_SINGLE_ZONE ターゲット分配形態で最大 5,000 個のスタンドアロンコンピューティングインスタンスをプロビジョニングできます。このリクエストは、単一のゾーンにコンピューティングインスタンスを作成し、非マネージドグループに追加できます。スタンドアロンコンピューティングインスタンスの場合、Compute Engine はコンピューティングインスタンスの作成リクエストの間にのみ容量を評価してゾーンを選択します。

詳細については、非マネージド VM をグループ化するをご覧ください。
スタンドアロンコンピューティングインスタンス: ターゲット分配形態（ANY、BALANCED、ANY_SINGLE_ZONE）を指定してリージョン一括インスタンス作成リクエスト（regionInstances.bulkInsert API）を使用し、最小数を設定します。最小カウントを使用すると、完全な容量がすぐに使用できない場合にリクエストが完全に失敗するのではなく、可能な限り多くのコンピューティングインスタンスをプロビジョニングできます。スタンドアロンコンピューティングインスタンスの場合、Compute Engine はインスタンス作成リクエストの実行中にのみ容量を評価してゾーンを選択します。

詳細については、VM の一括作成についてをご覧ください。

マシンタイプの柔軟性機能

マシンタイプの柔軟性機能を使用すると、デプロイで代替マシンタイプの優先順位付きリストを使用できます。プライマリ選択が使用できない場合、Compute Engine は自動的にセカンダリマシンタイプにフォールバックします。この機能は、インスタンスの柔軟性ポリシーを定義することで構成します。このポリシーは、単一のインスタンス選択または複数のインスタンス選択のランク付けされたリストで構成されます。

インスタンスの柔軟性ポリシーは、次のデプロイタイプに適用できます。

MIG: インスタンスの柔軟性ポリシーを MIG に関連付けて、需要の急増時にグループが代替ハードウェアに自動的にフォールバックできるようにします。MIG が Spot VM を使用している場合、このポリシーは、推定稼働時間が長く、プリエンプションのリスクが低いフォールバックマシンタイプを自動的に優先します。詳細については、MIG のインスタンスの柔軟性についてをご覧ください。

重要: インスタンスの柔軟性ポリシーで指定したマシンタイプは、MIG のインスタンステンプレートで指定したマシンタイプをオーバーライドします。Compute Engine でテンプレートからマシンタイプをプロビジョニングする場合は、ポリシーのインスタンス選択に含める必要があります。
非マネージドインスタンスグループ: これらのグループはインスタンスの柔軟性ポリシーをネイティブにサポートしていないため、regionInstances.bulkInsert API を使用してインスタンスをプロビジョニングし、グループに追加できます。API リクエストで、インスタンスの柔軟性ポリシーを含め、単一のゾーン（locationPolicy.zones.zone）を指定するか、ANY_SINGLE_ZONE ターゲット分布形状を使用します。ANY_SINGLE_ZONE 形状を使用すると、使用可能なリソースが最も多いゾーンが自動的に選択されるため、ロケーションの柔軟性というメリットも得られます。スタンドアロンインスタンスの場合、Compute Engine はインスタンス作成リクエストの実行中にのみ柔軟性ポリシーを適用します。

コンピューティングインスタンスを一括作成する方法については、インスタンスの柔軟性を備えた VM を一括作成するをご覧ください。グループに追加する方法については、非マネージド VM をグループ化するをご覧ください。
スタンドアロンコンピューティングインスタンス: 独立したバッチ処理ジョブなど、インスタンスグループを必要としないワークロードの場合は、インスタンスの柔軟性ポリシーで regionInstances.bulkInsert API を使用してコンピューティングインスタンスをプロビジョニングできます。スタンドアロンインスタンスの場合、Compute Engine はインスタンス作成リクエストの実行中にのみ柔軟性ポリシーを適用します。

詳細については、一括作成された VM のインスタンスの柔軟性についてをご覧ください。

異なるマシンタイプ間でシームレスにスケーリングする

マシンタイプの柔軟性を構成すると、フォールバックマシンタイプのハードウェアアーキテクチャやディスク仕様が異なる場合があります。これらの仕様がインスタンス選択のマシンタイプと互換性がない場合、プロビジョニングが失敗する可能性があります。

仕様が互換性のないマシンタイプを使用するには、インスタンスの柔軟性ポリシーでプロパティのオーバーライドを定義する必要があります。これらのオーバーライドにより、Compute Engine が代替マシンタイプにフォールバックしたときに、その特定のハードウェアに必要な正しいブートイメージ、ディスクタイプ、プロセッサベースラインが自動的に適用されます。この機能により、デプロイをさまざまなマシンタイプにシームレスにスケーリングし、プロビジョニングの成功率を高めることができます。

詳細については、ディスクと CPU プラットフォームのオーバーライドの仕組みをご覧ください。

時間に関する柔軟性機能

時間柔軟性機能を使用すると、すぐに開始する必要のないワークロードは、すぐにプロビジョニングする必要がなく、アクセラレータなどの需要の高いリソースを待つことができます。

時間的柔軟性を実装するには、ワークロードの要件に応じて、DWS を使用する次の機能を使用します。

リソースが使用可能になるまで容量リクエストをキューに登録するには、Flex Start プロビジョニングモデルを使用します。
特定の計画された日時で将来の容量を予約するには、カレンダーモードの将来の予約を使用します。

柔軟なインフラストラクチャを評価して導入する

ロケーションまたはマシンタイプの柔軟性を構成する前に、選択したロケーションとマシンタイプが相互に互換性があり、ワークロードの要件と互換性があることを確認する必要があります。柔軟なインフラストラクチャを適切に設計して実装できるように、次のセクションでは、主な評価の考慮事項と段階的な導入戦略について説明します。

評価に関する考慮事項

柔軟なインフラストラクチャを評価する際の主な考慮事項は次のとおりです。

ロケーションの柔軟性: ワークロードを複数のゾーンに分散すると、ネットワークレイテンシに影響し、ゾーン間のデータ転送コストが増加する可能性があります。

詳細については、次のリソースをご覧ください。
- ゾーン内のコンピューティングインスタンス間のトラフィックのレイテンシデータを表示するには、レイテンシダッシュボードを表示するをご覧ください。 Google Cloud
- ゾーン間トラフィックに関連するデータ転送の費用を計算するには、 Google Cloud内の VM 間データ転送の料金をご覧ください。
マシンタイプの柔軟性: 代替マシンタイプにフォールバックすると、アプリケーションのパフォーマンスと費用にばらつきが生じる可能性があります。世代間のマシンタイプの柔軟性を実現するには、多くの場合、ディスクと CPU プラットフォームのオーバーライドを実装する必要があります。使用するマシンタイプがアプリケーションの技術的な前提条件を満たしていることを確認する必要があります。

詳細については、次のリソースをご覧ください。
- マシンシリーズ間の仕様を比較するには、マシンシリーズの比較をご覧ください。
- コンピューティングインスタンスの料金を表示するには、仮想マシンの料金をご覧ください。

導入戦略

新しいデプロイを設計するか、既存のデプロイを移行するかに応じて、次のように対応する戦略を選択します。

新しいワークロードの場合: 新しいデプロイを設計する場合は、インフラストラクチャ設計に柔軟性を取り入れることをおすすめします。ワークロードタイプに推奨される柔軟性のディメンションを特定するには、ワークロードの適合性と推奨事項のガイダンスに沿って操作します。次に、ワークロードを最もよくサポートするデプロイタイプを選択します。デプロイタイプとその柔軟性設定の詳細については、コアの柔軟性機能をご覧ください。
既存のデプロイの場合: 単一のゾーンまたはマシンタイプを使用するデプロイを柔軟なインフラストラクチャに移行する場合は、リスクを最小限に抑えるために、柔軟性を段階的に導入することをおすすめします。次のような段階的な導入戦略を使用できます。
1. ロケーションの柔軟性を追加します。ゾーンワークロードを、分配形態が BALANCED または ANY のリージョン MIG に移行します。EVEN 形状のリージョン MIG を使用している場合は、BALANCED に変更します。この変更は、スケールアウトする MIG にとって重要です。ゾーンの一時的な容量制約によって、スケールアウトオペレーションがブロックされることはありません。スタンドアロンコンピューティングインスタンスを作成する場合は、regionInstances.bulkInsert API を使用します。
2. 同じアーキテクチャを共有する代替マシンタイプを追加します。同じ CPU アーキテクチャとディスクサポートを共有するマシンタイプ（n2-standard-8 や n2d-standard-8 など）を指定するインスタンスの柔軟性ポリシーを関連付けます。
3. 異なる世代の代替マシンタイプを追加し、CUD を調整します。n4-standard-8 などの最新のマシン世代を組み込み、必要に応じてディスクのオーバーライドを使用します。また、コンピューティングフレキシブル CUD を使用して、フォールバック使用量の割引を適用します。

新規デプロイと増分移行の両方で安全かつ確実に導入できるように、次のロールアウトワークフローをおすすめします。

検証とベンチマーク。非本番環境で、選択したすべてのマシンファミリー、ディスクの組み合わせ、ゾーンにわたってアプリケーションをテストします。
本番環境での運用とスケーリング。インスタンスの柔軟性ポリシーまたはリージョン MIG の分配形態を、本番環境フリートのサブセットに段階的にロールアウトしてから、グローバルにスケーリングします。
モニタリングと最適化。フォールバック率、パフォーマンス指標、費用を継続的にモニタリングして、優先順位付きマシンタイプリストを調整します。MIG を使用して、マシンタイプとゾーン間のコンピューティングインスタンスのリアルタイム分布を追跡するには、MIG インスタンス分布モニタリングダッシュボードを使用します。手順については、MIG でインスタンスの分布をモニタリングするをご覧ください。

ベストプラクティス

柔軟なインフラストラクチャの効率と復元力を最大化するには、次のセクションで説明するベストプラクティスを使用します。

ロケーションの柔軟性に関するベストプラクティス

容量認識リージョン配置を使用します。リージョン MIG またはリージョン一括 VM 作成を使用してワークロードをデプロイします。BALANCED または ANY の分布形状を選択します。これらの形状を使用すると、Compute Engine はリージョン内のすべてのゾーンでリアルタイムの容量を評価し、リソースが使用可能な場所にコンピューティングインスタンスを自動的に配置できます。
複数のゾーンでマシンタイプをサポートするリージョンを選択する: 選択したマシンタイプがすべてのゾーンでサポートされているリージョンにワークロードをデプロイします。このアプローチにより、一時的な容量制限中にリクエストをルーティングする代替ゾーンの数が最大になり、ロケーションの柔軟性機能が確保されます。リージョンとゾーンの一覧については、使用可能なリージョンとゾーンをご覧ください。
Spot VM デプロイの可用性を確認します。デプロイで Spot VM を使用している場合は、複数のマシンタイプとロケーションで Spot VM のリアルタイムの可用性と推定稼働時間を確認します。使用可能な容量が多く、ワークロードに適した稼働時間があるリージョンまたはゾーンを選択して、プリエンプションのリスクを軽減します。詳細については、Spot VM の可用性を表示する（プレビュー）をご覧ください。

マシンタイプの柔軟性に関するベストプラクティス

マシンファミリー全体で分散する。単一のファミリー内の CPU コア（n2-standard-4 や n2-standard-8 など）のみが異なるポリシーは避けてください。ローカルの容量制約は、マシンファミリー全体に同時に影響する可能性があります。可用性を高めるには、複数のマシン世代とアーキテクチャ（n4-standard-8 や n2-standard-8 など）にまたがります。
新しいマシンタイプを採用し、古いマシンタイプをフォールバックとして使用します。最新のマシンファミリーを古いファミリーとともにインスタンスの柔軟性ポリシーに組み込んで、可用性を最大化します。
ディスクと CPU プラットフォームのオーバーライドを構成します。異なる世代のマシンタイプを混在させると、ディスクと CPU プラットフォームに違いが生じる可能性があります。柔軟性ポリシーでディスクと CPU プラットフォームのオーバーライドを定義して、インフラストラクチャがマシン世代間でシームレスにスケーリングされるようにします。たとえば、N4 インスタンスに Hyperdisk Balanced を構成し、N2 フォールバックに Persistent Disk を構成します。
小さいマシンタイプを優先します。ワークロードの適合性に応じて、vCPU とメモリの少ないマシンタイプを使用します。たとえば、n2-standard-64 などの単一のマシンタイプに依存するのではなく、ワークロードがそれぞれ n2-standard-16 マシンタイプを使用する 4 つのコンピューティングインスタンスにスケーリングできるかどうかを評価します。一般に、マシンタイプが小さいほど、リソースの可用性が高くなります。
パフォーマンスが同等のマシンタイプを選択します。vCPU とメモリのサイズが類似した代替マシンタイプを指定します。たとえば、インスタンスの柔軟性ポリシーで n2d-standard-8、n4-standard-8、n4a-standard-8 を組み合わせます。このアプローチにより、リソースの可用性を向上させながら、アプリケーションのパフォーマンスを一定に保つことができます。
MIG で修復時の更新を有効にします。デフォルトでは、MIG は元のマシンタイプを使用して障害が発生したコンピューティングインスタンスを修復します。このハードウェアが一時的に使用できない場合、修復は失敗する可能性があります。修復時に更新を有効にして、修復が柔軟性ポリシーで使用可能なマシンタイプに自動的にフォールバックされるようにします。詳細については、インスタンスの柔軟性と VM の修復をご覧ください。
フォールバックを使用して Spot VM を組み込みます。フォールトトレラントなワークロードの場合は、Spot VM とロケーションとマシンタイプの柔軟性を組み合わせます。Compute Engine が Spot VM をプリエンプトした場合、これらの柔軟性機能により、デプロイで代替のマシンタイプまたはゾーンを自動的に検索できます。この戦略により、標準プロビジョニングよりも低コストでワークロードのリソースの可用性を維持できます。

時間柔軟性のベストプラクティス

適切なワークロードをターゲットにします。開始時間が柔軟で、アクセラレータなどの需要の高いリソースを必要とするワークロードに時間的柔軟性を実装します。この要件には、小規模なモデルの事前トレーニング、モデルのファインチューニング、ハイパフォーマンスコンピューティング（HPC）シミュレーション、バッチ推論が含まれます。
タイムラインに適した機能を選択します。Flex Start プロビジョニングモデルを使用して、最大 7 日間実行される定義済み期間のジョブのリクエストをキューに登録します。最大 90 日以上、需要の高いリソースを取得するには、予約にバインドされたプロビジョニングモデルを使用します。
Flex Start VM の待機時間を最適化します。Flex Start VM の作成を試みる場合は、ワークロードを特定のゾーンで実行する必要がある場合は、長い待機時間を指定します。待機時間が長いほど、Compute Engine がリクエストされたリソースをプロビジョニングできる可能性が高くなります。スタンドアロン Flex Start VM を作成し、ワークロードがリージョン内の任意のゾーンで開始できる場合は、待機時間を 0 秒に指定します。リソースが使用できないため作成リクエストが失敗した場合は、別のゾーンで作成リクエストをすぐに試行します。

予約と割引をワークロードの柔軟性と一致させる

リソースの可用性と費用のバランスを取るには、確約利用割引（CUD）をワークロード用に選択した容量戦略に合わせます。

複数のマシンタイプにわたる安定した使用率: ワークロードが複数のマシンタイプをサポートし、使用率が安定している場合は、マシンタイプの柔軟性を構成し、コンピューティングフレキシブル CUD を使用します。マシンタイプの柔軟性により、プライマリ選択の容量が不足している場合に代替ハードウェアを使用することで、プロビジョニングの成功率が向上します。コンピューティングフレキシブル CUD は、Compute Engine がプロビジョニングする特定のマシンシリーズに関係なく、対象となるコンピューティング費用に適用される費用ベースの割引です。
トラフィックのピークがある安定したベースライン: ワークロードのベースラインは予測可能だが、予測不可能なスパイクが発生する可能性がある場合は、予約とリソースベースの CUD を使用して、予測可能なベースラインを確保します。トラフィックの急増に対処するには、マシンタイプの柔軟性を構成し、コンピューティングフレキシブル CUD を使用して代替フォールバックマシンをカバーします。インスタンスの柔軟性ポリシーで、次のように設定を割り当てます。
- 優先度が最も高い: リソースベースの CUD を使用する予約済みマシンタイプ
- 優先度の低いマシンタイプ: 代替マシンタイプとコンピューティングフレキシブル CUD を使用する
Compute Engine は、まずリソースベースのコミットメントを使用し、次にコンピューティングフレキシブルコミットメントを使用して、残りの対象使用量をカバーします。
厳密に固定されたハードウェアワークロード: ワークロードが単一のマシンタイプに依存している場合は、予約とリソースベースの CUD を使用します。予約は特定のハードウェアの容量を高いレベルで保証するため、ビジネスクリティカルなワークロードで検討する必要があります。リソースベースの CUD は、この定常状態の予測可能な使用量に対して割引を提供します。

詳細については、予約タイプを選択すると Compute Engine の確約利用割引（CUD）をご覧ください。

予約に関する設計上の考慮事項

戦略に予約が含まれている場合は、次の設計上の考慮事項を確認してください。

予約済みマシンタイプを優先します。マシンタイプの柔軟性を持つ予約を使用する場合は、予約済みマシンタイプをインスタンスの柔軟性ポリシーの最優先に追加します。この構成により、Compute Engine はオンデマンド容量よりも予約を優先します。
予約のスコープを評価します。一時的な容量制約に対応して予約を作成することは避けてください。ワークロードでリージョン MIG などのロケーションの柔軟性を使用している場合、Compute Engine はインスタンスをリージョン内の他のゾーンに分散することがあります。このシナリオで厳密なゾーン予約を行うと、未使用のアイドル状態のリソースが発生する可能性があります。

制限事項

柔軟なインフラストラクチャを設計する際は、次の一般的な制限が適用されます。制限事項の詳細については、各機能のページの制限事項セクションをご覧ください。

機能の非互換性: 1 つのデプロイでマシンタイプの柔軟性と時間の柔軟性を組み合わせることはできません。時間柔軟性を実現する機能は、リクエストごとに 1 つのマシンタイプ構成のみをサポートします。
初期作成時の柔軟性: 一括で作成されたコンピューティングインスタンスの場合、容量評価とインスタンスの柔軟性ポリシーは、最初のコンピューティングインスタンス作成リクエスト時にのみ適用されます。一括作成されたコンピューティングインスタンスは、修復中やインフラストラクチャのスケールアウト時に、代替ゾーンやマシンタイプに自動的にリダイレクトされません。
単一ゾーンへのデプロイ: ゾーン MIG は柔軟性機能をサポートしていないため、おすすめしません。単一ゾーン設計でマシンタイプの柔軟性を採用するには、リージョン MIG を作成し、1 つのゾーンのみを明示的に選択します。

次のステップ

MIG を使用してリージョン内の複数のゾーンに VM を分散する方法について説明します。
マネージドインスタンスグループでインスタンスの柔軟性を構成する方法を学習する。
インスタンスの柔軟性を備えた VM を一括作成する方法を学習する。
Compute Engine の CUD の詳細を確認する。