仮想化技術の普及により、一つの物理サーバー上で複数の仮想マシン（VM）を稼働させることが一般的になりました。
しかし、システムの安定稼働や可用性を高めるためには、これらの仮想マシンをどの物理サーバーで動かすかを適切に制御する必要があります。
そこで重要となるのが、仮想マシンの配置を制御するための仕組みであるアフィニティルールです。
アフィニティルールを正しく理解し設定することで、システムの冗長性を確保したり、パフォーマンスを最大限に引き出したりすることが可能になります。
本記事では、アフィニティルールの基本的な仕組みから、具体的な種類、設定するメリット、運用の際の注意点まで詳しく解説します。
アフィニティルールの基礎知識
アフィニティルール（Affinity Rule）とは、仮想化プラットフォームにおいて、仮想マシンと物理ホスト、あるいは仮想マシン同士の配置に関する制約を定義するルールのことです。
「アフィニティ（Affinity）」という言葉には「親和性」や「密接な関係」という意味があります。
仮想化環境では、通常、リソースの負荷状況に応じて仮想マシンの配置が自動的に最適化されます。
しかし、特定の業務要件や技術的な制約がある場合、自動的な配置に任せるだけでは不十分なケースが存在します。
アフィニティルールを使用することで、管理者は「この仮想マシンとあの仮想マシンは必ず別の物理サーバーで動かす」といった明示的な指示をシステムに与えることができます。
仮想化環境におけるリソース管理の重要性
VMware vSphereやNutanix AHVなどの主要な仮想化基盤には、リソースの負荷を分散させる機能（DRS：Distributed Resource Schedulerなど）が備わっています。
これらの機能は、物理サーバーのCPUやメモリの消費率を監視し、必要に応じて仮想マシンを別のホストへライブマイグレーションさせます。
しかし、システムの論理的な構成を考慮しないまま移動が行われると、思わぬトラブルを招くことがあります。
例えば、冗長化のために用意した2台のWebサーバーが同一の物理ホスト上に配置されてしまうと、そのホストが故障した際に両方のサーバーが同時にダウンしてしまいます。
このような単一障害点（SPOF）を回避するために、アフィニティルールによる制御が不可欠となります。
アフィニティルールの主な種類
アフィニティルールには、大きく分けて「アフィニティ」と「アンチアフィニティ」の2つの方向性があります。
これらを使い分けることで、システムの目的に応じた柔軟な配置制御が可能になります。
アフィニティ（Affinity：同居）
アフィニティは、指定した複数の仮想マシンを可能な限り同じ物理ホスト上で稼働させるルールです。
「一緒にする」という意味から、同居ルールとも呼ばれます。
このルールは、主にネットワーク遅延を最小限に抑えたい場合に使用されます。
仮想マシン同士が同じホスト内にいれば、ネットワーク通信が物理スイッチを経由せず、ホスト内部の仮想スイッチのみで完結するため、スループットの向上が期待できます。
アンチアフィニティ（Anti-Affinity：分離）
アンチアフィニティは、指定した複数の仮想マシンを異なる物理ホストに分散させて稼働させるルールです。
「離す」という意味から、分離ルールとも呼ばれます。
可用性を重視するシステムにおいて、最も頻繁に利用されるのがこのアンチアフィニティです。
冗長構成を組んでいるサーバー群に対してこのルールを適用することで、物理ホストの故障による共倒れを防ぐことができます。
適用対象による分類
ルールが「何と何」を結びつけるかによっても、いくつかの分類が存在します。
VM-VM アフィニティルール
仮想マシン同士の配置関係を定義するルールです。
前述した「Webサーバー同士を離す」や「アプリケーションサーバーとDBサーバーを同じホストに置く」といった制御がこれに該当します。
物理ホストの構成変更に左右されにくいため、論理的なアプリケーション構成に基づいて設定されます。
VM-Host アフィニティルール
特定の仮想マシングループと、特定の物理ホストグループの間の関係を定義するルールです。
このルールを使用するには、あらかじめ仮想マシンをグループ化した「VMグループ」と、物理サーバーをグループ化した「ホストグループ」を作成しておく必要があります。
特定のライセンス要件を満たすサーバー上でのみ実行したい場合や、高性能なCPUを搭載した特定のホストでのみ稼働させたい場合などに利用されます。
強制力の違い：MustルールとShouldルール
アフィニティルールには、その制約をどの程度厳密に守るかという「強制力」の設定があります。
この選択を誤ると、障害発生時の動作が意図しないものになるため注意が必要です。
強制的なルール（Required / Must）
設定されたルールを何があっても絶対に遵守する設定です。
例えば、「VM-Aは必ずホスト-1で動かす」という強制ルールを設定した場合、ホスト-1が故障してもVM-Aは他のホストで起動することはありません。
ライセンス遵守の観点など、法的な制約や厳格な技術的制約がある場合に用いられます。
ただし、可用性が低下するリスクがあるため、慎重な検討が必要です。
優先的なルール（Preferential / Should）
「通常時はルールに従うが、やむを得ない場合はルールを無視してもよい」という柔軟な設定です。
例えば、アンチアフィニティを設定していても、他のホストにリソースの空きがない場合や、メンテナンス時には、一時的に同じホストに仮想マシンが配置されることを許容します。
可用性と配置の最適化をバランスよく両立させたい場合に、一般的に推奨される設定です。
| 項目 | アフィニティ（同居） | アンチアフィニティ（分離） |
|---|---|---|
| 主な目的 | 通信パフォーマンスの向上 | 可用性・冗長性の確保 |
| 推奨されるケース | VM間の通信トラフィックが極めて多い場合 | Active-Standby構成、クラスタ構成 |
| 主なメリット | ネットワーク遅延の低減 | 物理故障時の同時停止を防止 |
| 代表的な設定例 | APPサーバーとDBサーバーのペア | 2台のドメインコントローラー |
アフィニティルールを導入する具体的なメリット
アフィニティルールを適切に設定することで、単に仮想マシンを並べる以上の価値が生まれます。
可用性の向上と冗長性の確保
企業システムにおいて最も重要なのは、サービスを止めないことです。
アンチアフィニティルールを適用することで、ハードウェアの故障がサービス全体に波及するのを防ぐことができます。
例えば、3台で構成されるWebサーバー群をそれぞれ異なる物理ホストに配置しておけば、1台の物理サーバーがダウンしても、残りの2台でサービスを継続できます。
これは、クラウド基盤においても「アベイラビリティゾーン」や「配置グループ」といった名称で同様の概念が取り入れられています。
パフォーマンスの最適化
密接に連携するシステム同士をアフィニティルールで同じホストに固定することで、通信効率が向上します。
物理ネットワークの帯域を消費せず、ハイパーバイザー内のメモリバス速度に近い速度で通信が行えるようになるからです。
特に、マイクロサービスアーキテクチャを採用している場合や、大量のデータをやり取りするETL処理などでは、この設定が大きな効果を発揮します。
ライセンスコストの最適化
商用ソフトウェアの中には、インストールされている物理サーバーのCPUコア数に基づいてライセンス料が決まるものがあります。
仮想マシンが自由に全ホストを移動できてしまうと、クラスタ内の全サーバー分のライセンスを購入しなければならない事態になりかねません。
VM-Hostアフィニティルールを使用して、特定の仮想マシンをライセンス購入済みの特定の物理サーバー群に限定して稼働させることで、不要なライセンス費用の発生を抑えることができます。
これは、Oracle DatabaseやMicrosoft SQL Serverなどの導入環境で特によく見られる手法です。
設定時の注意点とデメリット
アフィニティルールは非常に強力な機能ですが、乱用すると運用の首を絞めることになります。
運用の複雑化
ルールの数が増えすぎると、どの仮想マシンがなぜそのホストにいるのかを把握するのが困難になります。
また、ルール同士が競合してしまうと、仮想マシンがどのホストでも起動できなくなる事態が発生します。
例えば、「VM-AとVM-Bを離す」というルールと「VM-AとVM-Bを両方ホスト-1に置く」というルールを同時に設定すると、システムは矛盾を解消できなくなります。
障害復旧への影響
強制的な「Mustルール」を多用している場合、障害発生時の自動復旧（HA機能）が動作しなくなるリスクがあります。
物理ホストが故障した際、HA（High Availability）機能は仮想マシンを別のホストで再起動させようとします。
しかし、ルールによって移動先が制限されていると、「移動できる適切なホストがない」と判断され、仮想マシンが停止したままになることがあります。
そのため、極端な理由がない限りは「Shouldルール」を使用し、緊急時には柔軟な移動を許可しておくのが定石です。
リソースの不均衡
特定のホストに仮想マシンを縛り付けることで、クラスタ全体の負荷分散がうまく機能しなくなることがあります。
あるホストが過負荷になっても、ルールによって仮想マシンを逃がすことができないため、結果として特定のシステムのパフォーマンスが低下する可能性があります。
アフィニティルールを設定する際は、常にクラスタ全体のキャパシティ設計と照らし合わせる必要があります。
代表的な活用シーン
実際の現場で、アフィニティルールがどのように使われているかの具体例を見ていきましょう。
データベースサーバーの冗長化
データベースの可用性を高めるために、Active-Standby構成やマルチマスター構成をとる場合です。
これらのDBノードには必ず「アンチアフィニティルール」を適用します。
これにより、ストレージ共有型のクラスタ構成であっても、コンピュートリソースの分離が担保され、信頼性が向上します。
特定のハードウェア要件があるアプリケーション
一部の物理サーバーにのみ高性能なGPUや、特殊なUSBドングル、特定のネットワークインターフェースが接続されている場合です。
この場合、「VM-Hostアフィニティルール」を使用して、そのハードウェアを必要とする仮想マシンを特定のホストに固定します。
これは、画像解析システムや特定のセキュリティソフトを稼働させる際に有効な手法です。
3層構造システムの最適化
Webサーバー、アプリケーションサーバー、データベースサーバーで構成される3層システムの場合です。
同じ層のサーバー同士（Webサーバー1とWebサーバー2）にはアンチアフィニティを適用し、異なる層のペア（Web1とApp1）にはアフィニティを適用して通信効率を高めるといった複雑な組み合わせが行われることもあります。
まとめ
アフィニティルールは、仮想化環境における仮想マシンの配置を最適化するための強力な管理ツールです。
アンチアフィニティを活用すればシステムの可用性を劇的に高めることができ、アフィニティを活用すればパフォーマンスの向上が期待できます。
また、VM-Hostルールを適切に運用することで、ライセンスコストの削減といった経営的なメリットも享受できるでしょう。
ただし、ルールの強制力を強くしすぎたり、構成を複雑にしすぎたりすると、かえってシステムの柔軟性を損なう恐れがあります。
まずは「Shouldルール（優先的なルール）」を中心に設計を行い、本当に必要な箇所にのみ「Mustルール」を適用するのが、安定した運用のコツです。
自社のシステムの特性とリスクを十分に分析した上で、最適なアフィニティルールを策定し、強固な仮想化基盤を構築してください。
