雪国から始まるクラウドネイティブ実践 – OpenTelemetryで繋ぐ環境センサー、GPU、そしてコミュニティ

クラウドネイティブ会議 :5/14 17:40~ 雪国から始まるクラウドネイティブ実践 – OpenTelemetryで繋ぐ環境センサー、GPU、そしてコミュニティ

「またコンテナの話、しようか」——2018年に『コンテナ・ベース・オーケストレーション』（翔泳社）を共著してから8年、一人はIBMでObservabilityを、もう一人は雪国でGPUデータセンターを作っていた。2025年に再会した2人は、本物のコンテナ（型データセンター）の中にいた。

新潟県湯沢町のコンテナ型データセンターにNVIDIA H100（空冷）、H200・B200各8基（液冷）を収容し、Rancher K8sでGPUクラスターを構成。地下水（井水）による液冷で業界最高水準のエネルギー効率を目指します。

NVIDIA DCGMとOpenTelemetryを使ってGPUの可視化はInstanaで本番運用稼働中。Schneider Electric in-row冷却のSNMP MIBから風量を取得しGPU温度とOpenTelemetry Collectorで繋ぐことに挑戦中。液冷はPoC準備中。実績と途中経過を正直に共有。DCGM・SNMP×OTelの設計判断と失敗を持ち帰れます。

Transcript

1. 雪国から始まるクラウドネイティブ実践 — OpenTelemetryで繋ぐ環境センサー、GPU、そしてコミュニティ クラウドネイティブ会議 平岡 大祐 日本アイ・ビー・エム株式会社 境川 章一郎 ゲットワークス株式会社
2. 2 © 2026 IBM Corporation またコンテナの話しようか — 本のコンテナから、本物のコンテナへ 共著出版 本のコンテナ Japan IT Weekで再会 越後湯沢でコンテナDC 作ってるんだけど… 境川 章一郎 ゲットワークス株式会社 LinkedIn 2018年 2025年春 2025年冬 湯沢GX データセンター 本物のコンテナの中にいた 平岡 大祐 日本アイ・ビー・エム株式会社 LinkedIn
3. 3 © 2026 IBM Corporation 見えているもの、見えていないもの ✗ 見えてない 当然 DCGM Software Pod の CPU・メモリ — 見えてる GPU 温度・電力・使用率 — 見えるようになった 冷却・設備 それを冷やしてる側は — 見えてますか？ 見えないものは、最適化できない つなげないものは、相関できない
4. 4 © 2026 IBM Corporation 冷却の仕組み — 井水で冷やす 湯沢GXデータセンター(ゲットワークス) / コンテナ型DC 実機構成 : 水冷サーバーラック Dell XE9680L (NVIDIA HGX B200) Motivair CDU (Schneider Electric ) 右側ファン列 = InRow (Schneider Electric) サーバーが発熱 液冷もファンも 最終的にコンテナ内の空気になる コンテナ内に排熱が蓄積 長時間負荷で温度が上昇 井水で空気を冷却 →冷気をサーバーへ 温まった水は融雪・農業などに活用 暖かい空気 InRowが吸い込む 井水(地下水) GPU 側と冷却側、お互いに見えない — OpenTelemetry でつなげた それがこの後の話
5. 5 © 2026 IBM Corporation OpenTelemetry パイプライン — 全部OTLP、全部K8s上 3つのプロトコル（DCGM・Redfish・SNMP）を統合 / Schneider Electric の冷却エコシステム全体を可視化 Instana ダッシュボード Smart Alert OTel Collectorで できることは Collector に任せた（SNMP → OTLP） できないことは OTel SDK で自作した（Redfish / 相関計算） 出口はすべて OTLP — これが OTel の強み correlator v6 Python + OTel SDK 3ソースを scrape → 相関計算 → 16メトリクス thermal_headroom / delta_t / cooling_lag データソース 処理・変換 可視化・アラート DCGM Exporter GPU温度 / メモリ Prometheus形式 SNMP Receiver InRow + CDU (Schneider) SNMP (1988〜) Redfish API GPU電力 / T.Limit REST API (iDRAC9) Redfish GPU Poller Python + OTel SDK REST API → パース → OTLP 出力 ※ OTel Receiver がまだないため自作 OTel Collector x 2 DaemonSet: DCGM → OTLP Deployment: SNMP → transform/scale → OTLP OTLP なので バックエンドは自由に選択可能 （Grafana, Datadog, etc.） 自作 OTLP OTLP 自作
6. 6 © 2026 IBM Corporation correlator — 異なるドメインを相関させる GPU 単体でも冷却単体でも計算できない OTel で繋いだから初めて生まれるメトリクス correlator thermal_headroom / delta_t / cooling_lag / demand_response_time / fan_response_time GPUドメイン 電力 (Redfish) 温度 (DCGM) Thermal Limit 冷却ドメイン cool_demand / cool_output fan_speed / airflow supply / return 温度
7. 7 © 2026 IBM Corporation 意外な発見— 水冷サーバーラック隣の InRow . 165 cool_output = 0 kW 冷却出力がゼロ？ 壊れている？ いいえ Dell XE9680Lの排熱の大部分を液冷(Motivair CDU)で 処理しているためInRow のコンプレッサーが不要な状態でした 2層冷却の1次（液冷）が効いている証拠
8. 8 © 2026 IBM Corporation .164 vs .165 — 同じ InRow、違う振る舞い でも、本当にずっと 0 のまま？ メトリクス .164 (空冷ラック隣） .165(水冷ラック隣) cool_output 6 kW 0 kW fan_speed 45% 23% delta_t 9 – 10℃ 7 – 8℃ 解釈 空気冷却フル稼働 液冷効果で省電力待機
9. 9 © 2026 IBM Corporation 8時間の負荷テスト 結果は… GPU 8基 × 8時間 — cool_output は動くのか？ 8基 NVIDIA B200 7,940W GPU電力 TDP上限 8時間 連続負荷 28,800秒
10. 10 © 2026 IBM Corporation InRow が目を覚ました 通常 0kW の cool_output が、約30〜45分おきにスパイク 最大 9.1kW
11. 11 © 2026 IBM Corporation スパイクの詳細 — InRow のバックアップ発動 約30分〜45分おきに周期的に発動 水冷環境でも InRow は寝ていない — 必要なときに起動するバックアップ機構 最大スパイク（12:53 JST）— 最も顕著 時刻 delta_t demand cool_output 状態 12:51 3.5°C 4.0 kW 0 kW 待機中 12:52 3.5°C 4.2 kW 0 kW 待機中 12:53 3.6°C 4.0 kW 8.6 kW ★ 発動 12:54 4.2°C 4.5 kW 9.1 kW ★ ピーク 12:55 10.4°C 4.3 kW 0 kW 停止 12:56 6.1°C 2.4 kW 0 kW 回復中
12. 12 © 2026 IBM Corporation thermal_headroom — ドメイン横断メトリクス 9.62°C = GPU T.Limit − max GPU 温度 thermal headroom GPU 単体では出せない 冷却単体でも出せない OTel で GPU と冷却を繋いだから 初めて計算できるメトリクス GPU負荷開始 GPU負荷開始 → GPU 8基フル稼働中は 0°C 付近を推移 テスト終了で即座に回復 — 冷却システムが正常に機能している証拠
13. 13 © 2026 IBM Corporation プロトコルが違う、管轄が違う— でも繋がる SNMP → OTel Collector レガシーな産業機器を クラウドネイティブな Observability に統合 Redfish → Otel SDK サーバーハードウェアの テレメトリを OTLP で標準化 ※将来的にはOTel Receiverが 出れば Collector に移行できる Custom Correlator on K8s 異なるドメインの メトリクスを 相関分析 バックエンド非依存 OTLP なので Instana / Grafana /Datadog どれでも 今回は SNMP x Redfish x DCGM あなたの現場では何と何？ OTLPに揃えれば、ドメインの壁は消える
14. 14 © 2026 IBM Corporation まとめ — ３つの技術が交わって見えたもの Schneider Electric InRow 冷却設備 井水冷却構成で バックアップ発動を確認 fan 23% 省電力 + 周期的スパイク 湯沢GX データーセンター 2層冷却設計がB200 高負荷に 耐えることをデータで証明 thermal_headroom で 8基フル稼働での 冷却データを取得 OpenTelemetry on Kubernetes SNMP + Redfish → OTLP 異なるドメインの 相関分析を実現 全部 K8s 上 バックエンド非依存 ↑ cool_output スパイクは、３つが揃って初めて見えた ↑ OTel Collector の SNMP Receiver も、コミュニティが作ってくれたもの
15. © 2026 IBM Corporation 15 Observability の対象を段階的に拡大 ── ソフトウェアから設備、そしてデータセンター設備へ Facility Observability 設備テレメトリー収集 GPU可視化 STEP 1 本番稼働中 GPUの温度・電力・使用率を Otelで収集し、Instanaで 本番運用を開始 冷却設備(InRow・CDU)の 温度・風量・冷却出力を Otelで集めて、GPUと相関させる STEP 2 検証進行中 この先 DCGM → Otel → OTLP STEP 3 サステナビリティ 環境指標の可視化 設備テレメトリーが集まれば、電 力・水・熱の全体像が見える 環境報告の自動化へ 今後の展開 SNMP/Redfish → Otel → OTLP テレメトリー → 環境指標 → 報告 今日お話ししたのは・・・STEP 1 〜 STEP 2
16. © 2026 IBM Corporation 16 見えたあと、どうするか？ Observability から Optimizationへ — テレメトリーを意思決定に変える 設備が見えれば、最適化できる 最適化できれば、サステナビリティに届く 電力↓ kWh エネルギー消費 • どこの負荷で冷却は足りているか？ • 電力と冷却のバランスは適切か？ • 今の運用はどれだけCO2を出しているのか Observability がないと最適化はできない 見えないものは制御できない / データがなければ判断の根拠がない Observability だけでは最適化にならない 見えた後に「意思決定」に繋げる仕組みが必要。 排熱↓ CO2排出量 井水↓ L/kWh 水効率 今日この場で共有できたこと自体が、コミュニティの力です
17. 17 © 2026 IBM Corporation 通知と免責事項 ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報提供の目的のみで 提供されており、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またIBM製品やサービスがお客様に適用ある特定の法令に適合す ることを保証するものでもありません。本講演資料に含まれている情報については、完全性と正確性を期するよう努めておりますが、「現状のまま」提供され、明示また は黙示にかかわらず、商業性、特定の目的への適合性、非侵害性を含め、いかなる保証も伴わないものとします。本講演資料またはその他の資料の使用によって、あるい はその他の関連によって、いかなる損害が生じた場合も、IBMは責任を負わないものとします。 本講演資料で言及されるIBM製品、プログラム、またはサービスは、IBM がビジネスを行っているすべての国・地域でご提供可能なわけではありません。本講演資料で言及される将来の展望（製品リリース日付や製品機能を含む）は、市場機会 またはその他の要因に基づいてIBM独自の決定権をもっていつでも変更できるものとし、将来の製品または機能が使用可能になること、もしくは特定の結果を確約するこ とを意図するものではありません。本講演資料は、言及される IBM製品またはサービスに適用ある契約条件を変更するものでも、追加の表明または保証を意図するもの でもありません。 本講演資料に含まれている内容は、参加者の活動によって特定の結果が生じると述べる、または暗示することを意図したものでも、またそのような結果を生むものでもあ りません。 パフォーマンスは、管理された環境において標準的なIBMベンチマークを使用した測定と予測に基づいています。ユーザーが経験する実際のスループットや パフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、ストレージ構成、および処理されるワークロードなどの考慮事項を 含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで述べられているものと同様の結果を得られると確約するものではありません。記述されて いるすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例として示されたものです。実際の環境コスト およびパフォーマンス特性は、お客様ごとに異なる場合があります。 IBM、IBMのロゴ、ibm.comは、世界の多くの国で法的に登録された、International Business Machines Corporationの商標です。その他の製品名・サービス名はIBM または他社の商標である可能性があります。IBM商標の最新リストは、ウェブ上の「著作権および商標情報」（ www.ibm.com/jp-ja/legal/copytrade.shtml ）でご確 認いただけます。 NVIDIA®、NVIDIA® H200、NVIDIA® DCGM は、米国およびその他の国におけるNVIDIA Corporationの 商標または登録商標です。 OpenTelemetry は、Cloud Native Computing Foundation (CNCF) のプロジェクトであり、The Linux Foundation の商標です。InRowは、 Schneider Electric の商標または登録商標です。 本資料に記載されているゲットワークスは、株式会社ゲットワークスを指します。同社は、本資料の作成および発表に協力し、資料内の写真を提供・承認しています。 写真内に写り込んでいる他社の商標・ロゴは、実際のデータセンタ環境を構成する機器・パートナーの一部として付随的に写り込んでいるものであり、これらの企業の製 品・サービスを宣伝・推奨する意図はございません。