第14章 低レイテンシーチューニング
14.1. クラスターノードの低レイテンシーチューニングについて
エッジコンピューティングは、レイテンシーと輻輳の問題を軽減し、通信アプリケーションおよび 5G ネットワークアプリケーションのパフォーマンスを向上させる上で重要な役割を果たします。可能な限りレイテンシーを抑えたネットワークアーキテクチャーを維持することが、5G のネットワークパフォーマンス要件を満たすための鍵となります。平均レイテンシーが 50 ms の 4G テクノロジーと比較して、5G ではレイテンシーを 1 ms 以下に抑えることを目指しています。このレイテンシーの削減により、ワイヤレススループットが 10 倍向上します。
14.1.1. 低レイテンシーについて
Telco 領域にデプロイされるアプリケーションの多くは、ゼロパケットロスに耐えられる低レイテンシーを必要とします。パケットロスをゼロに調整すると、ネットワークのパフォーマンス低下させる固有の問題を軽減することができます。詳細は、Tuning for Zero Packet Loss in Red Hat OpenStack Platform (RHOSP) を参照してください。
エッジコンピューティングの取り組みは、レイテンシーの削減にも役立ちます。クラウドの端にあり、ユーザーに近いと考えてください。これにより、ユーザーと離れた場所にあるデータセンター間の距離が大幅に削減されるため、アプリケーションの応答時間とパフォーマンスのレイテンシーが短縮されます。
管理者は、すべてのデプロイメントを可能な限り低い管理コストで実行できるように、多数のエッジサイトおよびローカルサービスを一元管理できるようにする必要があります。また、リアルタイムの低レイテンシーおよび高パフォーマンスを実現するために、クラスターの特定のノードをデプロイし、設定するための簡単な方法も必要になります。低レイテンシーノードは、Cloud-native Network Functions (CNF) や Data Plane Development Kit (DPDK) などのアプリケーションに役立ちます。
現時点で、OpenShift Container Platform はリアルタイムの実行および低レイテンシーを実現するために OpenShift Container Platform クラスターでソフトウェアを調整するメカニズムを提供します (約 20 マイクロ秒未満の応答時間)。これには、カーネルおよび OpenShift Container Platform の設定値のチューニング、カーネルのインストール、およびマシンの再設定が含まれます。ただし、この方法では 4 つの異なる Operator を設定し、手動で実行する場合に複雑であり、間違いが生じる可能性がある多くの設定を行う必要があります。
OpenShift Container Platform は、ノードチューニング Operator を使用して自動チューニングを実装し、OpenShift Container Platform アプリケーションの低レイテンシーパフォーマンスを実現します。クラスター管理者は、このパフォーマンスプロファイル設定を使用することにより、より信頼性の高い方法でこれらの変更をより容易に実行することができます。管理者は、カーネルを kernel-rt に更新するかどうかを指定し、Pod の infra コンテナーなどのクラスターおよびオペレーティングシステムのハウスキーピング向けに CPU を予約して、アプリケーションコンテナーがワークロードを実行するように CPU を分離することができます。
OpenShift Container Platform 4.14 では、クラスターにパフォーマンスプロファイルを適用すると、クラスター内のすべてのノードが再起動します。この再起動には、パフォーマンスプロファイルの対象になっていないコントロールプレーンノードとワーカーノードが含まれます。このリリースでは RHEL 9 と連携した Linux コントロールグループバージョン 2 (cgroup v2) が使用されているため、これは OpenShift Container Platform 4.14 の既知の問題です。パフォーマンスプロファイルに関連付けられた低遅延チューニング機能は cgroup v2 をサポートしていないため、ノードは再起動して cgroup v1 設定に戻ります。
クラスター内のすべてのノードを cgroups v2 設定に戻すには、Node
リソースを編集する必要があります。(OCPBUGS-16976)
Telco では、cgroups v2 サポートがないため、低レイテンシー、リアルタイム、および Data Plane Development Kit (DPDK)ワークロードに PerformanceProfile
を使用するクラスターは自動的に cgroups v1 に戻ります。PerformanceProfile
を使用している場合は、cgroup v2 を有効にすることはできません。
OpenShift Container Platform は、さまざまな業界環境の要求を満たすように PerformanceProfile
を調整できる Node Tuning Operator のワークロードヒントもサポートします。ワークロードのヒントは、highPowerConsumption
(消費電力が増加する代わりにレイテンシーを非常に低く抑える) と realTime
(最適なレイテンシーを優先) で利用できます。これらのヒントの true/false
設定の組み合わせを使用して、アプリケーション固有のワークロードプロファイルと要件を処理できます。
ワークロードのヒントは、業界セクターの設定に対するパフォーマンスの微調整を簡素化します。“1 つのサイズですべてに対応する” アプローチの代わりに、ワークロードのヒントは、以下を優先するなどの使用パターンに対応できます。
- 低レイテンシー
- リアルタイム機能
- 電力の効率的な使用
理想は、上記のすべての項目を優先することです。しかし、これらの項目の一部は、他の項目を犠牲にして実現されます。Node Tuning Operator は、ワークロードの期待を認識し、ワークロードの要求をより適切に満たすことができるようになりました。クラスター管理者は、ワークロードがどのユースケースに分類されるかを指定できるようになりました。Node Tuning Operator は、PerformanceProfile
を使用して、ワークロードのパフォーマンス設定を微調整します。
アプリケーションが動作している環境は、その動作に影響を与えます。厳密なレイテンシー要件のない一般的なデータセンターの場合、一部の高性能ワークロード Pod の CPU パーティショニングを可能にする最小限のデフォルトチューニングのみが必要です。レイテンシーが優先されるデータセンターやワークロードの場合でも、消費電力を最適化するための対策が講じられています。最も複雑なケースは、製造機械やソフトウェア無線などのレイテンシーの影響を受けやすい機器に近いクラスターです。この最後のクラスのデプロイメントは、多くの場合、ファーエッジと呼ばれます。ファーエッジデプロイメントの場合、超低レイテンシーが最優先事項であり、電力管理を犠牲にして実現されます。
14.1.2. 低レイテンシーおよびリアルタイムアプリケーションを実現するハイパースレッディングについて
ハイパースレッディングは、物理 CPU プロセッサーコアを 2 つの論理コアとして機能させ、2 つの独立したスレッドを同時に実行できるようにする Intel プロセッサーテクノロジーです。ハイパースレッディングにより、並列処理が有効な特定のワークロードタイプでシステムスループットが向上します。デフォルトの OpenShift Container Platform 設定では、ハイパースレッディングが有効になっていることが想定されています。
通信アプリケーションの場合、レイテンシーを可能な限り最小限に抑えるようにアプリケーションインフラストラクチャーを設計することが重要です。ハイパースレッディングは、パフォーマンス時間を低下させ、低レイテンシーを必要とする計算集約型ワークロードのスループットに悪影響を及ぼす可能性があります。ハイパースレッディングを無効にすると、予測可能なパフォーマンスが確保され、これらのワークロードの処理時間が短縮されます。
ハイパースレッディングの実装と設定は、OpenShift Container Platform を実行しているハードウェアによって異なります。当該ハードウェアに固有のハイパースレッディング実装の詳細は、関連するホストハードウェアチューニング情報を参照してください。ハイパースレッディングを無効にすると、クラスターのコアあたりのコストが増加する可能性があります。
関連情報