Red Hat OpenShift 向けの電力モニタリング：テクノロジープレビュー

昨年 10 月、Red Hat は Red Hat OpenShift 向けの電力モニタリングの開発者プレビューを発表し、 サステナブル・コンピューティング・アップストリーム・コミュニティ・イニシアチブの不可欠なコンポーネントとして Kepler を公開しました。この取り組みにより、早期採用者はこの有望なテクノロジーを試すことができます。この発表以来、私たちのチームは Red Hat 製品のセキュリティとテスト基準を満たすパイプラインとツールを構築するために懸命に取り組んできました。

本日は、Red Hat OpenShift の取り組みにおける新しいマイルストーンとして、 Red Hat OpenShift 向けの電力モニタリングのテクノロジープレビューのリリースをお伝えできることを嬉しく思います。電力モニタリングのデプロイに積極的に参加し、貴重なフィードバックを惜しみなく共有してくれた、早期採用者のすべてと破壊的テクノロジーを愛好するすべての人々に、心から感謝します。

Red Hat OpenShift の電力モニタリングを使ったことのない方のために説明すると、これは OpenShift クラスタで実行されているワークロードの電力消費を監視するためのツールセットです。この情報は、最も電力を消費する namespace を特定したり、電力消費を最小限に抑える戦略的な計画を策定したりするなど、さまざまな目的に活用できます。

このプレビューリリースを試してみたい方のために、以下に開始方法の詳細を記載しています。公式サポートの詳細については、 テクノロジープレビューのステートメントをお読みください。

Red Hat OpenShift 向け電力モニタリングのインストール

Red Hat では統一されたエクスペリエンスの提供を目指しているため、これらのインストール手順は、 コミュニティ Operator を利用する以前のバージョンの電源モニタリングのものとよく似ています。

1. Red Hat OpenShift のドキュメントに記載された手順に従って、user-workload-monitoring を有効にします。
2. 不要な競合を回避するために、コミュニティ Operator カタログからインストールした可能性のある古いバージョンの kepler-operator があれば、それをまずアンインストールします。
3. [Operators] -> [OperatorHub] に移動して、OpenShift 4.14 (およびそれ以上) コンソールから Operator をインストールします。次に、検索ボックスを使用して Red Hat OpenShift 向け電力モニタリングを見つけ、それをクリックして [Install] ボックスを押します。
4. Operator がインストールされたら、[View Operator] をクリックしてから Kepler API の下にある [Create instance] をクリックして Kepler カスタムリソース定義のインスタンスを作成します。

これで完了です。Kepler がインストールされると、OpenShift コンソール UI の [Observe] > [Dashboards] タブに 2 つの新しいダッシュボードが追加されます。

電力モニタリングの詳細については、 OpenShift ドキュメントにある電力モニタリングの公式ドキュメントを読むことを強くお勧めします。

モニタリングの力

これらのダッシュボードを使用することで、クラスタとそのワークロードについて以下の知見を取得できるようになります。

• 選択された CPU アーキテクチャや監視対象ノードの数を含めて、過去 24 時間にクラスタで消費された総エネルギー量を監視する
• 電力消費量の多い上位の namespace の内訳を見る
• どのコンテナと pod が最も多くの電力を消費しているかを把握する。これは、[Observe] -> [Metrics] タブにある、Kepler が公開しているメトリクスを分析することで実施できます。
  • ヒント：正規表現 { __name__ =~ "kepler.+"} を使用して、電力モニタリングで利用可能なすべてのメトリクスをクエリできます。

前述のように、Kepler を OpenShift に組み込むことで、このようなメトリクスが利用可能になります。Kepler によって取得される一連のメトリクスは、基盤となるハードウェアとクラスタの構成に大きく依存します。現在、Kepler は特定のクラウド構成セットから正確な測定値を提供しています。具体的には、ベアメタルデプロイで Running Average Power Limit (RAPL) と Advanced Configuration and Power Interface (ACPI) を公開できる Intel ハードウェアに基づくものです。

その他の構成については、初期の機械学習モデルが提供されます。さらに Red Hat はより広範なコミュニティと連携して、機械学習に基づく推定器 (estimator) の精度を向上させています。現時点では、これらの推定値に一貫性があるので、これを利用して同じワークロードの実行間の変動を確認できます。ただし、これらは実際の電力消費の概算値であることに注意してください。

Kepler がデフォルトでメトリクスベースの値を提供しているのか、モデルベースの値を提供しているのかを簡単に識別するために、[Overview] ページの [Node - CPU Architecture] パネルに [Components Source] という列を追加しました。

この拡張機能によって透明性が提供され、ユーザーはこれらのメトリクスがどこから提供されているか (rapl-sysfs や rapl-msr など) を確認できるようになります。Kepler がハードウェアの消費電力メトリクスを取得できない場合は、代わりにソースとして [estimator] を表示します。このような場合、Kepler は機械学習モデルとそれによる前述の推定器を利用します。精度と対処できるフットプリントの範囲を向上させるため、これらのモデルの改良を重点として、継続的な開発作業が行われています。

メトリクスの確認

実際にはどのようなものでしょうか。例を使って詳しく見ていきましょう。 公式ドキュメントに従って Kepler をインストールした後、 HTTP/2 トラフィックジェネレーターとモックをインストールして、システムに少し負荷をかけました。

それでは、OpenShift クラスタへの消費電力の影響を見てみましょう。OpenShift コンソールで [Observe] -> [Dashboards] -> [Power Monitoring Overview] ダッシュボードの順に移動すると、次のことを確認できます。

• [Architecture] パネルに表示されているノードではメトリクスベースの結果が報告され、[Components Source] 列に rapl-sysfs と表示されています。 
• クラスタはしばらくの間稼働していましたが、アイドル状態であるため、それほど多くの電力を消費していません。
• 消費電力量が多い namespace のリストも表示されます。

その他に、電力消費とエネルギー消費のプロファイルを理解したいので、2 つ目のダッシュボード [Power Monitoring/Namespace] に移動します。対象の namespace (hermes-ns) を選択すると、以下のようになります。

• 最初に気がつくのは、2,3 回のピークの後、ワット単位の電力消費が経時的に安定していることです。これには PKG コンポーネントが最も大きく貢献しています。パッケージ (PKG) ドメインは、ソケット全体の電力消費を測定します。これには、すべてのコア、内蔵グラフィックス、アンコアコンポーネント (ラストレベルキャッシュ、メモリーコントローラー) の消費量も含まれます。これは正しいと思われます。電力消費はエネルギーの割合であるため、累積はありません。
• 時間の経過とともにエネルギー消費量が増加していることもわかります。この場合、DRAM (統合メモリーコントローラーに接続された RAM のエネルギー消費を測定) が消費電力に与える影響はごくわずかであると思われます。 

少し下にスクロールすると、 コンテナごとに、PKG と DRAM 両方の消費量をさらに詳しく分析することができます。最初に目を引くのは、最初のピークが以前のワークロードによって引き起こされているように見えることです。これは興味深いことで、アプリケーションまたはモックでデバッグが必要になるかもしれません。

2 つ目のデプロイメントの準備ができた後、両方のコンテナが均等に電力消費に影響していることが確認できます。

これはどういうことでしょうか。ある種の複雑なロジックや、OpenTelemetry、メトリクス、トレースによるインストルメンテーションを備えたトラフィックジェネレーターが、「200 OK」とコンソールに出力するだけの シンプルなモックと同じ量のエネルギーを消費しているということなのでしょうか？先進的な可観測性は良いのですが、それでも時には標準出力に出力する必要があります。

func exampleHandler(w http.ResponseWriter, r *http.Request) {
	time.Sleep(2 * time.Millisecond)
	fmt.Println("Request received. URI:", r.RequestURI, "Method:", r.Method)
	w.WriteHeader(200)
}

トラフィックジェネレーターは C++ で記述され、モックは Go で記述されています。最近の研究では C++ は Go よりもエネルギー効率が高く、特定の条件下では 2.5 倍にもなることが示されていますが、その説明はこのブログの範囲をはるかに超えています。私たちはどの言語も大好きで、それぞれの言語に独自の得意分野があります。電力モニタリングがどのように活用されるか、楽しみです。自分のデータを使って、プログラミング言語と電力消費の戦いに参加することもできるでしょう。 

次のステップ

これからもお客様のフィードバックを反映し、調整を行い、機能を強化していきます。コミュニティとのコラボレーションを継続し、エネルギー消費のより効果的な監視を実現するグローバルな取り組みに貢献していきます。前途は洋々で、電力モニタリング監視をより広範な持続可能性の取り組みと統合する、開発者による OpenShift プラットフォーム内でのコードの監視や OpenTelemetry を通じたデータのエクスポートについて開発者を支援するなどの計画が考えられます。 

参考資料

• Red Hat OpenShift 公式ドキュメント
• Kepler 開発者プレビューの紹介：Red Hat OpenShift 向けの電力モニタリング
• https://sumtainable-computing.io/
• Exploring Kepler’s potentials: unveiling cloud application power consumption | CNCF
• Which Programming Languages Use the Least Electricity?- The New Stack
• 開発者プレビューのサポート範囲：Red Hat カスタマーポータル
• テクノロジプレビュー機能のサポート範囲：Red Hat カスタマーポータル
• 開発者プレビューとテクノロジープレビューの比較：Red Hat カスタマーポータル
• ユーザー定義プロジェクトのモニタリングの有効化 | モニタリング | Red Hat OpenShift Platform 4.14