「自社でAIを動かす」なら求められる“インフラの発想転換” なぜKubernetesが鍵か：【第1章】（4）従来のHPC型からサービス型へ

AIサービスは、止まることなく動き続けることを前提に設計されます。ある瞬間にアクセスが数倍に跳ね上がることも珍しくありません。それを支える企業のインフラはどうあるべきか。従来型HPCと対比しつつ、Kubernetesなどを使った新しいインフラ運用について解説します。

[松浦淳（トゥモロー・ネット）, 編集：遠藤文康，＠IT]

　生成AIの急速な普及により、AIはもはや企業の業務や日常のサービスに深く組み込まれる存在になっています。常時動き続けるAIを支えるインフラに求められるのは、単に大量の計算を走らせるだけではありません。「サービスを止めない」ことが前提になります。

　本連載『現場で役立つ「AIインフラ」の基礎と運用』の第1章として、AIインフラの電力や冷却、リソース最適化など、AIを止めないためのハードウェア設計と運用の基本を見てきました。AIインフラの進化として着目すべきは、それだけにとどまりません。本稿で見ていくのは「動的な設計思想」です。AIが常に学習・推論を繰り返し、利用状況が刻一刻と変化する今、固定的な構成のままでは性能を引き出すことが難しくなっているのです。

ジョブ中心の発想からサービス中心の発想へ

　これまで主流だった「従来のHPC（High Performance Computing：高性能計算）型」の構成は、研究用途や大規模解析には適していましたが、“24時間稼働し続ける商用AIサービス”には必ずしも適していません。ここで言う「従来のHPC型」は、事前にジョブ単位でリソースを固定的に割り当て、大規模な処理を効率的に実行するような運用を指します。AIの処理を支えるインフラには、変化に合わせて自ら拡張し、最適化していく「動的な設計思想」が求められています。

　本稿ではまず、従来のHPC型の特徴と限界を整理します。その上で、コンテナオーケストレーションツール「Kubernetes」を中心とした新しい運用モデルと、その思想的転換について解説します。

「Slurm」や「InfiniBand」に象徴される“従来型のHPC”との違い

　HPCとは、膨大な計算を短時間で処理するために設計された高性能計算システムのことです。多数の計算ノードを高速ネットワークで接続し、1つの大規模な仮想計算機として動作させます。

　各ノードにはCPUを中心とした演算ユニットと共有ストレージが備えられ、通信の遅延（レイテンシ）を抑えるために「InfiniBand」（大規模並列処理に広く使われる高速ネットワーク規格）などを用いた低レイテンシネットワークが用いられます。

　ストレージは並列ファイルシステムを採用し、複数ノードから同時にデータを読み書きしても処理が滞らないように設計されています。

　従来のHPCは、計算リソースを集中管理し、順番にタスクを割り当てて処理する「バッチ型」の仕組みが基本です。このような構成により、科学技術計算やシミュレーションのような大規模バッチ処理を効率的に実行できます。

標準的に採用されてきたSlurm

　ジョブスケジューラとして代表的なのが「Slurm」（Simple Linux Utility for Resource Management）です。Slurmは、利用者が投入したジョブをキューに登録し、ノードの空き状況や優先度を判断して実行順序を決定します。ジョブが完了するとリソースを開放し、次のタスクに割り当てる仕組みで、「計算資源を公平かつ効率的に使う」ことができます。学術機関や研究施設では標準的に採用されており、「MPI」（Message Passing Interface）などの並列処理ライブラリと組み合わせて、数千台規模のノードを統合的に制御することが可能です。

　計算リソースの公平な分配や再現性を重視する研究分野では理にかなった仕組みですが、AIサービスのように24時間連続稼働を前提とする場合の要件は異なります。

「ジョブを止めずに回し続ける」へ

　AIの推論処理はリアルタイム性が求められるため、キュー待ちが生じれば即座に応答遅延が発生します。また、学習や再学習ではデータ量と演算規模が動的に変化するため、静的に割り当てられたノードでは柔軟なスケールアウトが難しいのが現状です。一度ジョブを投入するとリソース構成を変更できないことも多く、運用面での機動力に欠ける点が課題です。

　従来のHPCの設計思想は「ジョブを確実に終わらせること」にあります。一方で、AIサービスの世界では「ジョブを止めずに回し続けること」が重要です。この違いが、両者のアーキテクチャを分ける最大のポイントといえるでしょう。

Kubernetesによる並列最適化の発想

　近年、クラウド環境や商用AI基盤では、Kubernetesを軸にした運用が広がっています。Kubernetesは、コンテナ技術を基盤とし、分散システムを自動的に構成・制御する仕組みを提供するオープンソースのプラットフォームです。もともとはGoogleが大規模サービスの運用効率化を目的に開発したもので、現在ではクラウドからオンプレミスまで幅広い環境で採用されています。

　Kubernetesの仕組みの中核は、「Pod」と呼ばれる最小単位のコンテナ群にあります。アプリケーションを複数のコンポーネントに分割し、必要な場所に自動的に配置・起動させることができます。「Node（ノード）」と呼ばれる実行環境をクラスタとして束ね、制御プレーンが全体の状態を監視・制御します。利用者はシステム構成を意識せず、「どのアプリケーションを、どの条件で、どれだけ動かすか」だけを定義すれば、Kubernetesが自動的に配置、拡張、回復を行います。

インフラを「サービス」単位で扱う発想

　この仕組みの本質は、「インフラの抽象化」にあります。従来はサーバ単位で設定や調整を行っていたものが、Kubernetesでは「サービス単位」で管理されるため、GPUノードやストレージを含むインフラ層をプログラムとして扱うことが可能になりました。いわゆる「Infrastructure as Code」（IaC）と呼ばれる手法です。この発想は、AIインフラの運用を大きく変えています。モデル更新やバージョンの差し替えといった作業を、本番稼働中の環境でも安全に自動化できるようになり、システムを「構築して終わり」から「運用しながら進化させる」方向へ導いています。

　Kubernetesのスケジューラは、Pod間の依存関係やノードの状態、GPUリソースの空き状況をリアルタイムで判断し、最適な場所にタスクを配置します。クラスタ全体を1つの仮想的なリソースプールとして扱えるため、GPUやストレージの利用効率が飛躍的に向上します。AIモデルの学習、推論、データ前処理といった異なる処理を同じ基盤上で柔軟に動かすことができ、動的なスケジューリングが容易になります。

　AI推論リクエストが増えれば自動的にGPUノードを追加し、負荷が下がればノードを削除する。このスケールアウトとスケールインの仕組みが、従来のHPCでは実現が難しかった柔軟な運用を可能にしています。また、障害発生時の自動再起動や更新時の段階的な切り替えなど、常時稼働を前提とした設計も備えており、AIサービスの継続運用に適しています。

　さらに、こうした環境では、スケジューラがGPUやストレージの利用状況を監視し、「AIOps」（AIを使った運用の仕組み）と連携させ、最適なリソース割り当てを自動で行うこともできます。静的な構成を人が管理するのではなく、システム自体が稼働状況を学習し、自己調整する方向へと進化しています。

Kubernetesによる並列処理の進展

　米国を中心に、Kubernetesを用いたAIインフラの並列処理と自動運用が急速に進んでいます。従来のHPCがジョブ単位での計算効率を追求してきたのに対し、Kubernetesを活用したクラウドネイティブな運用では、サービス全体の稼働効率と柔軟性に重点が置かれています。

　多くのAIプラットフォームでは、学習や推論のジョブをコンテナ化し、数千単位のGPUノードに自動的に配分する仕組みが整備されています。これにより、学習負荷の変動やモデル更新にも即座に対応でき、ジョブ単位ではなく「システム全体を最適化する」設計が実現されています。

　またIaCや継続的インテグレーション／継続的デリバリー（CI/CD）といった自動化の仕組みとKubernetesを連携させることで、モデルの更新から推論環境へのデプロイまでを一貫して自動化できるようになりました。

　Kubernetesを活用した並列処理の発展は、単なる技術的進化にとどまらず、AIの開発・運用プロセスそのものを変えつつあるのです。

HPCとKubernetesを共存：ハイブリッドという現実的な道

　しかしながら、全ての環境を一気にKubernetesへ移行することは現実的ではありません。大規模学習には、従来型のHPCの持つ高速ネットワークや並列処理性能が依然として有効であり、研究開発領域ではその価値が変わりません。現実的な解決策は、HPCとKubernetesを共存させるハイブリッド構成です。

　バッチ型の学習や解析処理をHPC側で実施し、APIを通じて提供する推論やサービス運用をKubernetes側で担う。両者をストレージとネットワークで接続し、ジョブやモデルデータを双方向に共有することで、「学習と運用の分業」と「全体最適化」を両立することができます。

　この構成であれば、既存の設備投資を生かしながら、新しいアーキテクチャへ段階的に移行できます。日本企業にとっても、HPCの強みを生かしながらサービス前提の発想を取り入れる現実的なアプローチになるでしょう。

今後の設計思想

　AIインフラの設計は、今後さらに動的な方向へと進化していきます。GPUやストレージの使用状況をリアルタイムで把握し、負荷に応じて自動的に構成を切り替える――。これまでのように「人が監視して調整するシステム」から、「システムが自律的に最適化する仕組み」へと変化していく流れです。

　AIOpsの導入もその一環です。AIがシステム全体の状態を学習し、異常検知やスケーリングを自動で行うことで、人的な運用負荷を大幅に削減できます。AIを支えるインフラそのものが、AIによって管理される時代が到来しつつあります。

　インフラはもはや固定化された設備ではなく、継続的に成長し続ける仕組みです。「AIを動かす設計から、AIを止めない設計へ」。この転換こそが、これからのインフラ設計に求められる最も重要な発想だと考えます。

---

　第1章では、AIを支えるハードウェアとインフラの構造について整理してきました。電力や冷却、GPUリソース、ストレージ、そしてアーキテクチャ設計の全てが密接に関係し、どれか一つが欠けてもAIを安定して動かすことはできません。

　AIインフラは、固定的な設備ではなく、環境や負荷の変化に合わせて進化し続ける仕組みへと変化しています。第2章では、この動的な基盤の上で動くデータとミドルウェアに焦点を当て、AIを止めずに運用するためのソフトウェアアーキテクチャを考えていきます。

　学習から推論、再学習までのデータフロー設計や、システム全体を連携させる仕組みを通じて、より実践的な「止まらないAI」の実現方法を探ります。

筆者紹介

松浦 淳（まつうら じゅん）　トゥモロー・ネット

富士通、シトリックス・システムズ・ジャパンで開発、サポート、ソリューションエンジニア業務に従事し、デル株式会社（現：デル・テクノロジーズ株式会社）の事業部長を経て現職に至る。米国シリコンバレーを中心とした海外スタートアップ企業の日本法人立ち上げも複数経験しており、日本市場への製品展開に豊富な経験を持つ。トゥモロー・ネットでは、ITエンジニアとしての経験を生かして企業経営全般に関与している。