CPU ピニングを外すと何が変わるのか – 専有実行から共有実行へ変わるということ

CPU ピニングを外すことは、単にチューニングを弱める話ではありません。特に NFV、低レイテンシ用途、仮想アプライアンスでは、実行モデルそのものを変える変更として扱うべきです。

CPU ピニングありの VM は、特定の物理 CPU に vCPU を固定することで、スケジューラの揺らぎを抑えます。一方で、CPU ピニングを外すと、VM はホスト OS のスケジューラと他 VM の影響をより強く受ける共有実行モデルになります。

そのため、CPU ピニングを外した構成を、以前と同じサービスとして扱うのは危険です。性能が少し落ちる、という話ではなく、前提が変わります。

CPU ピニングは単なる性能チューニングではない

CPU ピニングは、VM の vCPU を特定の pCPU に固定する設定です。これにより、ホスト側のスケジューリングの揺らぎを減らし、実行タイミングをある程度制御しやすくなります。

もちろん、すべての VM に CPU ピニングが必要なわけではありません。一般的な Web サーバーや業務アプリケーションでは、ホスト側のスケジューラに任せても十分なことが多いです。

しかし、パケット処理、暗号化、トンネル終端、仮想ルーター、仮想ファイアウォール、NFV 型のネットワーク機能では話が変わります。これらは CPU の揺らぎがスループットやレイテンシに直接影響しやすいからです。

専有実行から共有実行へ変わる

CPU ピニングを外すと、VM はより一般的な共有実行モデルに近づきます。これは、ホスト全体のリソース効率を高める一方で、実行タイミングの予測可能性を下げます。

構成	性質
CPU ピニングあり	専有実行に近い。vCPU と pCPU の対応が固定され、実行タイミングを制御しやすい。
CPU ピニングなし	共有実行。ホストスケジューラと他 VM の負荷の影響を受けやすい。
CPU オーバーコミットあり	リソース効率は上がるが、競合時の性能変動が大きくなる。
低レイテンシ用途	平均性能よりも揺らぎの小ささが重要になる。

この違いは、単なる設定値の違いではありません。サービスとして提供する性能特性の違いです。

NFV では同じサービスと見なすべきではない

NFV 型のネットワーク機能では、仮想マシンがパケット処理の中心になります。IPsec 終端、BGP、ファイアウォール、ロードバランサー、NAT、トンネル終端などでは、CPU スケジューリングの揺らぎがサービス品質に直結します。

このような VM で CPU ピニングを外すと、パケット処理のタイミングがホスト側の状況に左右されやすくなります。平均スループットがそれほど落ちなくても、瞬間的な遅延、ジッタ、パケットドロップ、暗号処理の詰まりとして表れる可能性があります。

したがって、CPU ピニングありで成立していた NFV 型サービスを、CPU ピニングなしにした場合、それは同じサービスではなく、別の実行モデルを持つサービスとして評価すべきです。

クラウド上の NFV でも同じ問題が出る

パブリッククラウド上で NFV 型のネットワーク機能を動かす場合も、この問題は避けられません。クラウドでは物理 CPU の割り当て、NUMA、ホスト上の他テナント、基盤側のスケジューリングが利用者から見えにくくなります。

クラウド事業者が提供する VM は便利ですが、すべての VM が専有実行に近い性質を持つわけではありません。インスタンスタイプ、専有ホスト、ベアメタル、拡張ネットワーク機能などを含めて、どの実行モデルなのかを確認する必要があります。

クラウドを使うこと自体が問題なのではなく、専有実行を前提にした NFV を、共有実行モデルの上へそのまま持ち込むことが問題です。

性能要件は平均値だけで見てはいけない

CPU ピニングの話では、平均 CPU 使用率や平均スループットだけを見ると判断を誤ります。

低レイテンシ用途やネットワーク機能では、平均よりも揺らぎが重要です。短時間のスケジューリング遅延、割り込み処理の遅れ、他 VM の影響が、サービス品質に出ることがあります。

• 平均スループットだけでなく、瞬間的な低下を見る
• レイテンシとジッタを見る
• パケットドロップや再送を見る
• 暗号処理やトンネル処理の詰まりを見る
• ホスト負荷がある状態でも確認する

CPU ピニングを外してよい場合

もちろん、CPU ピニングを外すことが常に悪いわけではありません。一般的な用途では、CPU ピニングなしの方がリソース効率が高く、運用も楽です。

重要なのは、対象サービスがどの実行モデルを必要としているかです。低レイテンシ性や処理タイミングの安定性がそれほど重要でないなら、CPU ピニングなしで十分な場合もあります。

逆に、CPU ピニングを前提に性能要件を満たしていたサービスなら、ピニングを外す時点で、再設計、再試験、再評価が必要です。

構成変更ではなくサービス変更として扱う

CPU ピニングを外す変更は、見た目には設定変更です。しかし、実行モデルが変わる以上、サービス変更として扱うべきです。

特に NFV や低レイテンシ用途では、次のような観点で再評価する必要があります。

• 変更後も性能要件を満たすか
• 負荷時のジッタや遅延が許容範囲か
• 他 VM の影響をどこまで受けるか
• 障害時やホスト高負荷時にどのような劣化をするか
• 利用者に提供している SLA や期待値と矛盾しないか

関連記事

• 単一 VM の vCPU はどこまで割り当てるべきか
• VM パフォーマンス Day2 – CPU 最適化と NUMA / CPU ピニングの考え方
• VM パフォーマンス Day3 – メモリ最適化と HugePages / TLB / NUMA の考え方
• パブリッククラウド上で NFV 型 NF は成立するのか – アンダーレイ / オーバーレイ / 帯域制約で考える
• クラウドを AWS だけで理解してはいけない – 本質は場所ではなく運用モデルである

まとめ

CPU ピニングを外すことは、単なるチューニング変更ではありません。特に NFV や低レイテンシ用途では、専有実行に近いモデルから共有実行モデルへ変える変更です。

そのため、CPU ピニングありで成立していたサービスを、ピニングなしにした後も同じサービスとして扱うのは危険です。平均性能だけでなく、レイテンシ、ジッタ、パケット処理、他 VM の影響を含めて再評価する必要があります。

設定変更に見えても、実行モデルが変わるなら、それはサービスの性質が変わるということです。