単一テナントノードで VM ワークロードを実行する場合は、まず、単一テナントノードをデプロイする方法を決める必要があります。特に、必要なノードグループの数と、ノードグループが使用するメンテナンス ポリシーを決める必要があります。
ノードグループ: 適切な数のノードグループを選択するには、可用性とリソース使用率を比較検討する必要があります。ノードグループ数を少なくすると、リソース使用率とコストを最適化できますが、ゾーンは 1 つに制限されます。ノードグループを複数のゾーンにデプロイすると、可用性が向上しますが、リソース使用率が低下する可能性があります。
自動スケーリングとメンテナンス ポリシー: 実行するオペレーティング システムとソフトウェアのライセンス要件によっては、ノードの自動スケーリングとメンテナンス ポリシーの選択がライセンス費用と可用性に影響を与える可能性があります。
単一テナントノードの使用方法を適切に判断するには、要件を慎重に検討する必要があります。
要件の評価
次のセクションでは、必要なノードグループの数と、ノードグループが使用するメンテナンス ポリシーを決める前に考慮すべき要件について説明します。
BYOL（お客様所有ライセンスの使用）とコアごとのライセンス
Compute Engine でお客様所有ライセンスの使用（BYOL）を使用する場合、単一テナントノードにより、これらのライセンスのハードウェア要件または制約を解決できます。
Windows Server などの一部のソフトウェアとオペレーティング システムは、物理 CPU コア単位のライセンスで使用が許可されています。このため、仮想マシンの基礎となるハードウェアを変更できる頻度に上限を定義できます。ノードの自動スケーリングとデフォルトのメンテナンス ポリシーを使用すると、ライセンスの許諾期間よりも頻繁にハードウェアが変更されることがあります。この場合、ライセンス料金が増加する可能性があります。
コアごとの BYOL を最適化するには、次のベスト プラクティスを検討してください。
インフラストラクチャ コストとライセンス コストのバランスを取る: Compute Engine で BYOL ワークロードを実行する場合の総費用を計算するには、インフラストラクチャ コストとライセンス コストの両方を考慮する必要があります。インフラストラクチャの費用を最小限に抑えると、ライセンスのオーバーヘッドが増加する可能性があります（その逆の場合もあります）。たとえば、コア数の多いノードタイプを使用すると、特定のワークロードでコストとパフォーマンスの点で最善の結果を得ることができますが、ライセンス料金がコア単位で設定されている場合は、追加のライセンス費用が発生する可能性があります。
BYOL ワークロードと BYOL 以外のワークロードに別々のノードグループを使用する: ライセンスが必要なコア数を制限するには、1 つのノードグループに BYOL ワークロードと BYOL 以外のワークロードが混在させず、別々のノードグループを使用します。
複数の異なる BYOL ライセンス モデル（Windows Server Datacenter や Standard など）を使用する場合、ノードグループをライセンス モデルで分割すると、ライセンスのトラッキングが容易になり、ライセンス費用を削減できます。
CPU のオーバーコミットとコア /メモリ比率の高いノードタイプを使用する: ノードタイプによってソケット、コア、メモリの比率が異なります。コア / メモリ比率の高いノードタイプを使用して、CPU のオーバーコミットを有効にすると、ライセンスが必要なコアの数を減らすことができます。
スケールインの自動スケーリングを避ける: ノードグループの自動スケーリングは、現在の需要に基づいてノードグループを自動的に拡張または縮小します。ノードグループの拡大と縮小が頻繁に発生する場合、VM を実行するハードウェアの変更頻度が高いことを意味します。
物理マシン間で許可されているライセンス移動よりも頻繁にハードウェアを変更すると、実際に使用しているコア数よりも多くのライセンスが必要になることがあります。
物理マシン間での移動頻度に制限がある場合、自動スケーリングを無効にするか、スケールアウトのみの自動スケーリングを構成することで、ライセンス費用の超過を避けることができます。
デフォルトのメンテナンス ポリシーを使用しない: デフォルトのメンテナンス ポリシーを使用すると、VM の可用性を最適化できますが、ハードウェアの変更が頻繁に行われる可能性があります。ハードウェアの変更を最小限に抑えてライセンス費用を最適化するには、ノードグループ内での移行またはインプレース再起動のメンテナンス ポリシーを使用します。
コアごとのライセンスが不要なワークロードの場合は、次のベスト プラクティスを検討してください。
- デフォルトのメンテナンス ポリシーを使用する: ライブ マイグレーションとデフォルトのメンテナンス ポリシーを使用すると、インプレース再起動ポリシーよりも可用性が向上します。また、ノードグループ内での移行メンテナンス ポリシーで追加のインフラストラクチャ コストが発生しません。
管理
ワークロードが複数ある場合や、単一テナントノードで実行する必要がある開発ワークロードと本番環境ワークロードの両方がある場合は、次のベスト プラクティスを考慮してください。
開発環境と本番環境に別々のノードグループを使用する: 別々のノードグループを使用すると、環境を別のノードから分離して、次のような状況を回避できます。
- 開発用 VM は、CPU、ディスク、ネットワーク リソースを過剰に消費することで、本番環境 VM のパフォーマンスに影響する場合があります（ノイジー ネイバー）。
- 開発用ワークロードは、ノードグループの容量を使い果たして、新しい本番環境 VM の作成を妨げる場合があります。
各環境のノードグループの数を制限する: 複数のノードグループを実行している場合、各ノードグループを最大限に活用できないことがあります。使用率を最適化するには、各環境のワークロードを組み合わせて、少数のノードグループでスケジュールします。
ノードグループの管理に専用のプロジェクトを使用する: 環境ごとに、ノードグループを管理するための専用のプロジェクトを作成します。次に、ワークロードを含むプロジェクトとノードグループを共有します。
このアプローチでは、ワークロードごとに個別のプロジェクトを使用してアクセス制御を簡素化するとともに、ワークロード間でノードグループを共有することでリソースの使用を最適化できます。
ノードグループを個々のプロジェクトと共有する: ノードグループを組織全体と共有する代わりに、個々のプロジェクトとのみ共有します。プロジェクトを個別に選択すると、環境を分離できます。また、ノードグループに関する情報を他のプロジェクトに開示する必要がなくなります。
内部費用のアトリビューションのプロセスを確立する: ノードグループの実行費用は、ノードグループを含むプロジェクト内で発生します。この費用を個々のプロジェクトやワークロードに帰属させる必要がある場合は、単一テナント VM の使用量を追跡し、このデータを使用して内部費用のアトリビューションを行うことを検討してください。
対象
ワークロードによって可用性の要件が異なる場合があります。アプリケーション レイヤで高可用性を実現する必要がある場合もあれば、インフラストラクチャ レイヤに実装する必要がある場合もあります。
クラスタ化アプリケーション: ワークロードの中には、レプリケーションやロード バランシングなどのクラスタリング手法を使用して、アプリケーション内に高可用性を実装しているものがあります。
このようなワークロードの例としては、Active Directory ドメイン コントローラ、SQL Server フェイルオーバー クラスタ インスタンスと可用性グループなどがあります。また、IIS で実行され、ロード バランシングされているクラスタ化アプリケーションもこれに含まれます。
通常、VM の大部分が利用可能である限り、クラスタ化アプリケーションは個々の VM が停止しても実行を維持できます。
クラスタ化されていないアプリケーション: クラスタリング機能を実装していないワークロードでは、VM 自体で可用性の維持が必要になる場合があります。
このようなワークロードの例としては、レプリケートされないデータベース サーバーやステートフル アプリケーション サーバーなどがあります。
個々の VM の可用性を最適化するには、今後のノード メンテナンス イベントの際に VM のライブ マイグレーションが行われるようにする必要があります。
ライブ マイグレーションは、デフォルトのメンテナンス ポリシーとノードグループ内での移行メンテナンス ポリシーでサポートされますが、インプレース再起動メンテナンス ポリシーを使用している場合にはサポートされません。
ミッション クリティカルでないアプリケーション: バッチ ワークロード、開発 / テスト ワークロード、その他の優先度の低いワークロードの場合、特別な可用性要件はありません。これらのワークロードでは、ノードのメンテナンス中に個々の VM が使用不能になることを許容できる場合があります。
ワークロードの可用性の要件を満たすには、次のベスト プラクティスを検討してください。
異なるゾーンまたはリージョンのノードグループを使用して、クラスタ化ワークロードをデプロイする: 単一テナントノードとノードグループはゾーンリソースです。ゾーンの停止から保護するには、複数のノードグループを異なるゾーンまたはリージョンにデプロイします。クラスタ化アプリケーションの各インスタンスが別のゾーンまたはリージョンの異なるノードで実行されるように、ノード アフィニティを使用して VM をスケジュールします。
2 つ以上のノードグループでデフォルトまたはインプレース再起動のメンテナンス ポリシーが使用されている場合は、重複しないようにメンテナンスの時間枠を構成します。
クラスタ化アプリケーションの複数のインスタンスを単一ゾーンで実行する必要がある場合は、アンチアフィニティを使用して、VM インスタンスが別のノードまたはノードグループにスケジュールされるようにします。
高可用性を必要とするクラスタ化されていないワークロードに対して、インプレース再起動メンテナンス ポリシーを使用しない: インプレース再起動メンテナンス ポリシーでは、基盤となっているノードでメンテナンスが必要になると VM がシャットダウンされます。このため、高可用性を必要とするクラスタ化されていないワークロードのノードグループには、これ以外のメンテナンス ポリシーを使用してください。
マネージド インスタンス グループを使用してワークロードの復元力と可用性を高める: マネージド インスタンス グループを使用してワークロードの健全性をモニタリングし、必要に応じて VM インスタンスを自動的に再作成することで、デプロイメントの復元力と可用性を向上させることができます。マネージド インスタンス グループは、ステートレス ワークロードとステートフル ワークロードの両方に使用できます。
パフォーマンス
ワークロードによってパフォーマンス変動に対する感度が異なる場合があります。特定の社内アプリケーションやテスト ワークロードでは、1 日を通して一貫したパフォーマンスを維持するよりもコストの最適化のほうが重要になります。外部向けのアプリケーションなどのワークロードでは、リソース使用率よりもパフォーマンスが重要になります。
単一テナントノードを最大限に活用するには、次のベスト プラクティスを検討してください。
パフォーマンスに依存しないワークロードに専用のノードグループと CPU のオーバーコミットを使用する: CPU のオーバーコミットを使用すると、単一テナントノードの VM 密度を高め、必要な単一テナントノードの数を減らすことができます。
CPU のオーバーコミットを使用するには、CPU のオーバーコミットをサポートするノードタイプを使用する必要があります。ノードグループで CPU のオーバーコミットを有効にすると、単一テナントノードごとに追加料金が発生します。
CPU のオーバーコミットに適したワークロードに専用のノードグループを使用し、このノードグループでのみ CPU のオーバーコミットを有効にすると、CPU のオーバーコミットの費用対効果が最も高くなる可能性があります。パフォーマンス重視のワークロードを実行する必要があるノードグループでは、CPU のオーバーコミットを無効にしておきます。
CPU のオーバーコミットとコア / メモリ比率の高いノードタイプを使用する: CPU のオーバーコミットを有効にすると VM 間でコアを共有できますが、メモリを共有することはできません。CPU コアあたりのメモリが比較的多いノードタイプを使用することで、メモリが制限要因になることを回避できます。
- パフォーマンス重視のワークロードにノードの自動スケーリングを使用する: パフォーマンス重視のワークロードでさまざまなリソースのニーズに対応できるように、自動スケーリングを使用するようにノードグループを構成します。
デプロイ パターン
単一テナントノードの最適な使用方法は個々の要件によって異なります。以下では、個々の要件に合ったアーキテクチャを特定する際の出発点となるパターンをいくつか紹介します。
異なるパフォーマンス要件が存在する場合に複数のノードグループを使用する
パフォーマンスを重視するワークロード（顧客向けアプリケーションなど）とパフォーマンスの影響を受けないワークロード（内部アプリケーションなど）が混在している場合、異なるノードタイプを使用する複数のノードグループを使用できます。
- 1 つのノードグループは、CPU のオーバーコミットと、vCPU とメモリの比率が 1:8 のノードタイプを使用します。このノードグループは、パフォーマンスに影響されないワークロードに使用します。
- 2 つ目のノードグループは、CPU のオーバーコミットなしで、vCPU とメモリの比率が 1:4 のコンピューティング最適化ノードタイプを使用します。このノードグループは、パフォーマンスを重視するワークロードで使用します。また、オンデマンドでスケールアップまたはスケールダウンされるように構成します。
コアごとのライセンスのワークロードがクラスタ化されている場合にマルチゾーンの高可用性を使用する
コアごとのライセンスのクラスタ化ワークロードを実行していて、ハードウェアの変更を最小限に抑える必要がある場合は、メンテナンスの時間枠が重複しない複数のノードグループを使用して、可用性とライセンスのオーバーヘッドのバランスを取ります。
- 複数のゾーンまたはリージョンに複数のノードグループをデプロイします。
- すべてのノードグループで再起動メンテナンス ポリシーを使用します。一度に複数のノードグループがメンテナンス関連で停止しないように、ノードグループで重複しないメンテナンスの時間枠を使用します。
- クラスタ化ワークロードを実行する VM インスタンスは、アフィニティ ラベルを使用します。これにより、各クラスタノードは異なるゾーンのノードグループにスケジュールされます。
コアごとのライセンスのワークロードが混在する場合にマルチゾーンの高可用性を使用する
コアごとのライセンスを使用していて、クラスタ化されていないワークロードが存在していない場合は、異種のメンテナンス ポリシーを使用して前のパターンを拡張できます。
- プライマリ ノード グループはゾーン
aにデプロイされ、クラスタ化されたワークロードとクラスタ化されていないワークロードの両方を実行します。ハードウェアのメンテナンスによる停止を最小限に抑えるために、ノードグループではノードグループ内で移行メンテナンス ポリシーを使用します。 - 1 つ以上のセカンダリ ノード グループが追加のゾーンまたはリージョンにデプロイされます。これらのノードグループでは再起動メンテナンス ポリシーを使用しますが、メンテナンスの時間枠は重複しません。
- クラスタ化ワークロードを実行する VM インスタンスは、アフィニティ ラベルを使用します。これにより、各クラスタノードは異なるゾーンのノードグループにスケジュールされます。
- クラスタ化されていないワークロードを実行する VM インスタンスでは、プライマリ ノードグループにデプロイされるようにアフィニティ ラベルを使用します。
セカンダリ ノード グループでクラスタ化されたワークロードをスケジュールするだけで、再起動メンテナンス ポリシーによる一時的な停止が全体の可用性に及ぼす影響を最小限に抑えることができます。同時に、プライマリ ノード グループのみにノードグループ内で移行メンテナンス ポリシーを使用し、ライセンスとインフラストラクチャのオーバーヘッドを制限します。
次のステップ
- 単一テナントノードについて学習する。
- 単一テナント VM の CPU をオーバーコミットする方法を学習する。
- お客様所有ライセンスの使用（BYOL）について学習する。