1. はじめに

昨今、AI開発のスケール拡大にともない、コンピュータ環境におけるジョブ管理の最適化はますます重要になっています。
その課題解決に有力な選択肢とされているのが、HPC領域でトップクラスのシェアを誇るジョブスケジューラ「Slurm」です。

本記事では、まず「ジョブスケジューラとは何か」を直感的に理解できるよう解説し、続いてSlurmの概要や主要機能、基本的な利用の流れを紹介します。
読み終えるころには、Slurmの基本概念から基本的な操作イメージまで掴めるよう意識して構成しました。

• 対象：
  • Linuxは触れるけど、ジョブスケジューラに触れるのは初めての方
• 前提：
  • Slurmがすでに利用可能な環境想定
  • 本記事ではセットアップ方法は扱わず、概念理解と利用イメージの習得に重点を置く
    セットアップ手順はSlurm公式から公開されていますので、以下をご参照ください。
    Slurm Workload Manager - Quick Start Administrator Guide
• ゴール：
  • ジョブスケジューラの役割を直感的に理解する
  • Slurmの基本概念・操作の流れを抑える
  • 実務運用で抑えるべき基本的な設計ポイントを把握する
  • 「ジョブスケジューラって何？」に対して自信を持って答えられるようになる

2. ジョブスケジューラ不在による運用上の課題

近年のAI開発現場では、多数のGPUを備えた大規模GPUサーバーや、複数台のGPUノードを接続したクラスタ環境を複数人で共用利用するケースが増えています。こうした環境では、利用者同士が同時にGPUなどの計算資源を要求するなどリソースのバッティングが発生しやすく、運用効率や開発スピードに大きな影響を与えてしまいます。

他にも、ジョブスケジューラがない環境では次のような課題が発生しがちです。

• ジョブの手動管理が必要（長時間ジョブの開始や監視を人が行う）
• リソース割り当てが不公平になりやすい（CPU/メモリ/GPUなどの計算資源が先着順や声が大きい人優先になってしまう）
• 利用状況が可視化できない（稼働率や待機時間が把握できない）
• リソースの無駄遣いが発生しがち（空きリソースが放置される、過剰占有など）

実際の現場では、「空きリソースが出るのを見張って、空いた瞬間にジョブ投入！」という取り合い状態になってしまう…そんな声も少なくありません。

3. ジョブスケジューラって？

前述の課題に対して、ジョブスケジューラ（ここではSlurm）を導入すると、運用効率・公平性・透明性のすべてにおいて効果が期待できます。
特に複数人でリソースを共有するクラスタ環境などでの共同利用では、その効果は顕著です。

単に「ジョブを順番に処理する」だけでなく、リソースの利用制限、優先度制御、実行履歴の可視化と蓄積といった機能が組み合わさることで、リソースの取り合いを防ぎ、安定した開発サイクルを実現することが可能です。
以下では、その代表的な改善ポイントをご紹介します。

• ジョブの自動実行・監視
  条件に基づいて自動的にジョブを実行。完了や失敗を記録し、必要に応じて再実行も容易
• 公平かつ計画的なリソース割り当て
  プロジェクトやユーザー単位で優先度やリソースの利用上限を設定し、「早い者勝ち」ではなく、公平なジョブ実行を実現
• 効率的なリソース活用（キューイング＋Backfill）
  ジョブはキューに登録され、前ジョブの終了タイミングで自動的に次のジョブが実行されるため、待ち時間が最小化、さらにBackfill機能により、空きリソースには短時間ジョブを差し込み、全体の稼働率を最大化
• 利用状況の可視化
  実行状態のジョブや待機中のジョブなどをリアルタイムに確認が可能
• 利用実績の取得・記録による透明性確保
  ジョブ実行ログやリソースなどの利用量をデータベースに記録
  これにより「誰がどれだけ使ったか」を正確に把握でき、部署・研究室ごとの利用配分やコスト換算（社内課金や研究費精算）に活用が可能

ジョブスケジューラは、クラスタのような大規模環境だけでなく、単体のサーバ環境でも複数ジョブの順序制御や自動実行、履歴管理といったメリットは同様に得られます。

AI分野でよく使われるオープンソースのジョブスケジューラには、今回紹介する「Slurm」のほか、以下のようなものもあります。

4. Slurmとは？

Slurm Workload Manager（以下、Slurm）とは、HPCやAI開発環境などで広く利用されているオープンソースのジョブスケジューラです。複数ユーザーによる計算リソース（CPU・メモリ・GPUなど）の共有利用を効率化し、公平性を確保しながら、ジョブの投入・実行・監視・記録を一元的に管理します。
また、スーパーコンピュータの性能ランキングで知られるTOP500のうち、約6割がジョブスケジューラとしてSlurmを採用しており、この分野においてはトップクラスのシェアを誇っています。
引用：Slurm Workload Manager - Wikipedia

4-1. アーキテクチャ概要

Slurmの全体構成は、大きく分けて管理ノード（Head Node）と計算ノード（Compute Node）から成り立っています。さらに、管理ノード内にはジョブスケジューリングとアカウンティング（実行履歴の記録等）を行う複数のコンポーネントが動作します。なお、管理ノードと計算ノードは物理的に分離する構成が一般的ですが、物理単体システムの場合は同居させることも可能です。

下表に代表的なコンポーネントと役割をまとめました。

Slurmはデフォルトでジョブ実行履歴は保持しません。しかし、slurmdbdを導入することで、ジョブ実行履歴の保存に加え、リソース利用制限（QoS）機能も利用できるようになります。

4-2. ジョブ投入の流れ

ユーザーがジョブを投入してから実行を完了するまでにはいくつかのステップがあります。
Slurmがどのようにジョブを受け付け、実行するのか簡単に解説します。

1. ユーザーがジョブを投入
   コマンド（例：sbatch）でジョブを投入すると、管理ノード（slurmctld）がジョブを受付
2. スケジューリングと割り当て
   実行可能な計算ノードを選び、計算ノード（slurmd）へジョブを送信
3. ジョブ実行と監視
   計算ノード上でジョブが実行され、完了情報などのステータスをslurmctldへ報告
4. リソース解放と記録
   slurmctldがリソースを「空き」状態に戻し、次のジョブに割り当て可能にする
   slurmdbdが実行履歴や利用リソース量などを記録する

管理ノードと計算ノードは物理的に分離する構成が一般的なので、ジョブ実行にあたっては、「/home」などの作業ディレクトリはNFS等で共有されている必要があります。

上記では管理ノード(slurmctld)がユーザから直接ジョブを受け付けていますが、大規模環境では別途ログインノードを用意し、ユーザはそこから管理ノードへジョブを投入する構成が一般的です。

5. Slurmによるジョブ管理の基礎概念

ここまでの章では、ジョブスケジューラとその代表的なSlurmについて解説しました。もう少しだけジョブ管理について、とくに抑えておきたいポイントを説明します。

5-1. パーティションって？

Slurmでジョブ管理を行う際には、パーティションという概念の理解が欠かせません。
パーティションとは、計算ノードの論理グループであり、パーティションごとに利用できるリソースや制限（ジョブ最大時間・同時実行数・利用者やグループの制限、優先度など）をひとまとめに設定します。
実務観点では、例えば以下のようにジョブの性質に応じてパーティションを分けるのが一般的です。

• 短時間・小規模ジョブ用
• 長時間だが優先度の低いジョブ用
• GPU専用ジョブ用
• 大規模並列ジョブ用

ちなみに、同じ計算ノードを複数のパーティションに重複所属させる設計も可能です。これにより、同一のリソース資源を異なる用途や制限で運用できる柔軟性があります。
パーティションを分けた時、ユーザーはジョブをどのパーティションに投入するかコマンドで指定します。パーティションを指定しなかった場合のデフォルトパーティションも設定が可能です。

5-2. リソース制限って具体的に何ができる？

Slurmではパーティション単位だけでなく、ユーザー単位・グループ（Slurmでは「アカウント」と呼ぶ）単位でもリソース制限が可能です。設定できる項目が多いのと、実際には制限が適用される順序（少し下の公式URL内を参照）もあるので、慣れるまでは少し複雑に感じると思います。

代表的な例：

• 最大同時実行ジョブ数（例：1ユーザーにつき10本まで）
• ジョブごとの最大実行時間（例：24時間以内）
• CPUコア数やGPU数の上限
• 1ジョブあたりの最大メモリ

これらを組み合わせることで、リソースの公平利用やシステム全体の安定運用が可能になります。
今回は具体的な設定方法には触れませんので、詳しく知りたい方は公式ドキュメントを参照してください。
Slurm Workload Manager - Resource Limits

6. とりあえず触ってみる

ここまででジョブスケジューラやSlurmが何者か掴めてきたのではないでしょうか？
ここからは、さらに具体的にイメージを掴むため、Slurmでよく使われるコマンドを叩いていきたいと思います。

6-1. Slurmクラスタの状態確認（sinfo）

セットアップは完了している前提なので、とりあえずユーザー「yu_imai」のSlurmクラスタの状態を確認してみます。
手っ取り早い方法としては、管理ノード上でsinfoコマンドを叩きます。
以降、コマンド例は特に記載がない限り、管理ノード上で実行しています。

yu_imai@mgr:~$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
defq*        up   infinite      2   idle node[01-02]

• defqという名前のパーティションが存在していることがわかる
• defqの隣の「*」はデフォルトパーティションであり、ジョブ実行時にパーティションを指定しない場合は自動でこれが使用される
• STATEが「idle」なので待機中でジョブ待ち状態であることがわかる

各カラムの意味は下記の通りです。

ノード単位で状態を確認したい場合は「-N」オプションをつけて実行します。

yu_imai@mgr:~$ sinfo -N
NODELIST   NODES PARTITION STATE
node01         1     defq* idle
node02         1     defq* idle

• ノード2台とも「idle」=待機中であることがわかります

6-2. ジョブの投入（srun / salloc / sbatch）

ジョブの投入方法はインタラクティブジョブとバッチジョブの2種類があります。
それぞれの特徴を交えながら、実際に実行してみたいと思います。

6-2-1. インタラクティブジョブ

インタラクティブジョブは実行中のアプリケーションにリアルタイムにアクセスしながら操作や確認ができるジョブ形式です。
対話型ジョブとも呼ばれ、ちょっとしたテストやデバッグに使えます。
主に使うコマンドとしては、srunまたはsallocです。

特徴：

• 端末から直接コマンドやスクリプトを試せる
• 実行結果をその場で確認できるため、トラブルシュートや動作検証に向く
• リソース確保後は“予約時間”を消費し続けるため、長時間放置は厳禁

まずは、Slurm経由でジョブがちゃんと投入できるか簡単なコマンドで試してみます。
ここでは、管理ノード上でホスト名を表示するコマンドを実行し、実際どのノードで動いているか確認します。

yu_imai@mgr:~$ srun ./myapp  # myappの中身は「hostname」を書いてるだけ
node01
yu_imai@mgr:~$ srun hostname
node01

ポイント：

• 管理ノード（mgr）から投入したジョブは、計算ノード（node01）側で実行されたことがわかる
• スクリプト（プログラム）で渡してもいいし、対話型の場合は直接コマンドを渡しても構わない

ジョブが上手く動かない場合、計算ノードの環境を直接確認したいことがあります。
直接SSH接続してしまってもよいのですが、せっかくなので疑似端末（—pty）を使って計算ノードへログイン風にアクセスをしてみます。

yu_imai@mgr:~$ srun --pty bash　# --ptyで疑似端末を割り当てbashを起動
yu_imai@node01:~$ hostname
node01

• 「—pty」により計算ノードに対して直接コマンドを打ち込める
• 環境変数の確認や、GPUの見え方チェック等にも使えるので便利

GPUリソースなどを割り当てたうえでジョブを実行するには、sallocを組み合わせます。

yu_imai@mgr:~$ salloc -G 1　# GPUを1枚要求
salloc: Granted job allocation 100
salloc: Nodes node01 are ready for job

yu_imai@mgr:~$ srun nvidia-smi

<-出力省略-GPUが要求した1枚分だけ表示される>

ポイント：

• 上記の状態で「nvidia-smi」を叩くとGPUが1枚分しか見えない
• salloc 実行後は、そのシェルがSlurmのジョブ環境になる（パッと見、見分けがつかない）
• 放置するとリソースを占有し続ける為、短時間の利用に留める

その他、実務よりな使い方として以下のような例があります。
オプションは無数にあるので、詳細については以下公式ページをご確認ください。
Slurm Workload Manager - srun

# appを8個（8プロセス）立ち上げ、それぞれに1枚ずつGPUを見せる　
$ srun -n 8 --gpus-per-task 1 ./app

# メモリを32GB以上利用可能な2ノードを選択し、appをノード辺り4個起動、1時間で終了させる
$ srun -N 2 --ntasks-per-node 4 --mem 32G –t 1:0:0 ./app

6-2-2. バッチジョブ

バッチジョブは専用のジョブスクリプトに実行内容や必要リソースを記述し、sbatchコマンドで投入する方式です。
一度投入してしまえば、あとはSlurmが実行・管理してくれるため、長時間の学習や解析、大量のジョブ投入などに最適です。
実務ではこの方式がメインになるかと思います。
以下に簡単なバッチジョブスクリプトの例を書きます（ sample.sh ）。
こちらもオプションは無数にあるので、詳細については公式ページをご確認ください。
Slurm Workload Manager - sbatch

yu_imai@mgr:~$ cat sample.sh
#!/bin/bash
#SBATCH -J test-job               # ジョブ名
#SBATCH -p defq                   # 利用パーティション名
#SBATCH --time=01:00:00           # 実行上限時間
#SBATCH --nodes=1                 # ノード数
#SBATCH --gpus=1                  # 要求GPU数
#SBATCH --cpus-per-task=8         # 1タスクあたりのCPUコア
#SBATCH --mem=32G                 # 要求メモリサイズ
#SBATCH -o logs/%x-%j.out         # 標準出力ファイル
#SBATCH -e logs/%x-%j.err         # 標準エラー出力ファイル

# 実行するプログラムを srunで起動
srun ./sample_app

• スクリプト先頭の 「#SBATCH」はコメントアウトに見えるが、オプション宣言
• プログラム実行結果は「-o」、エラーについては「-e」で指定したログファイルを参照
  • %xはジョブ名、%jはジョブID。ログファイル名に埋め込むと実行ごとのログが衝突しない

ジョブの投入例：

yu_imai@mgr:~$ sbatch sample.sh
Submitted batch job 111

• ジョブが投入（Submit）されジョブIDとして「111」が割り当てられている
• ジョブの実行状態の確認方法は後述

6-3. ジョブコントロール

ジョブを投入したら終わりではありません。
今どう動いているかを確認し、必要に応じて止める・詳細を見るのがジョブコントロールです。
この操作を適切に行うことで、リソースの無駄や予期せぬトラブルを大きく減らせます。

6-3-1. ジョブステータス確認（squeue）

現在投入中のジョブや、他ユーザーのジョブの状態を一覧にするコマンドがsqueueです。
まずは、ダミージョブを投入して表示例を見てみます。

yu_imai@mgr:~$ srun tail -f /dev/null 　#ダミージョブを投入（終わらないtail）


yu_imai@mgr:~$ squeue 　　　 　　　　　　#ジョブの実行状態を確認
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
               113      defq     tail  yu_imai  R       0:03      1 node01

• ユーザー 「yu_imai」 のジョブ （JOBID 113）が、計算ノード 「node01」 で実行中「R」である
• 実行開始してから3秒経過
• 割当ノード数は1台

主なカラムの意味を以下に記載します。

その他、よく使うコマンド例：

• 自分のジョブだけ見たい： squeue -u $USER
• 実行予定時刻を知りたい： squeue --start

6-3-2. ジョブの詳細確認（scontrol）

特定ジョブの割り当てリソースや状態の詳細を知りたいときはscontrol show job <JOBID>を使います。
このコマンドでは実行中ジョブの情報しか見れません。既に終了したジョブの履歴等はslurmdbdで管理しており、sacctを使って確認は可能ですが、確認方法については今回は割愛します。

# 詳細確認をしたいジョブIDを確認
yu_imai@mgr:~$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
               113      defq     tail  yu_imai  R       0:03      1 node01

# ジョブIDを指定しジョブの詳細を確認する
yu_imai@mgr:~$ scontrol show job 113
JobId=113 JobName=tail
   UserId=yu_imai(1000) GroupId=yu_imai(1000) MCS_label=N/A
   Priority=4294901709 Nice=0 Account=(null) QOS=normal
   JobState=RUNNING Reason=None Dependency=(null)
   Requeue=1 Restarts=0 BatchFlag=0 Reboot=0 ExitCode=0:0
   RunTime=00:00:07 TimeLimit=UNLIMITED TimeMin=N/A
   SubmitTime=2025-08-15T15:07:48 EligibleTime=2025-08-15T15:07:48
   AccrueTime=Unknown
   StartTime=2025-08-15T15:07:48 EndTime=Unknown Deadline=N/A
   SuspendTime=None SecsPreSuspend=0 LastSchedEval=2025-08-15T15:07:48 Scheduler=Main
   Partition=defq AllocNode:Sid=node01:1111321
   ReqNodeList=(null) ExcNodeList=(null)
   NodeList=node01
   BatchHost=node01
   NumNodes=1 NumCPUs=2 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
   ReqTRES=cpu=1,mem=128803M,node=1,billing=1
   AllocTRES=cpu=2,node=1,billing=2
   Socks/Node=* NtasksPerN:B:S:C=0:0:*:* CoreSpec=*
   MinCPUsNode=1 MinMemoryNode=0 MinTmpDiskNode=0
   Features=(null) DelayBoot=00:00:00
   OverSubscribe=OK Contiguous=0 Licenses=(null) Network=(null)
   Command=tail
   WorkDir=/home/yu_imai
   Power=

色んな情報が確認できますが、よく見る部分を抜粋して以下に記載します。

6-3-3. ジョブの停止・キャンセル（scancel）

投入したジョブを取り消す場合はscancelを使います。
ジョブの誤投入や条件の変更をしたいときに利用します。

# キャンセルしたいジョブIDを確認
yu_imai@mgr:~$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
               113      defq     tail  yu_imai  R       0:03      1 node01

# ジョブIDを指定してキャンセル
yu_imai@mgr:~$ scancel 113

# 自分のジョブを全てキャンセル
yu_imai@mgr:~$ scancel -u $USER

6-4. QoS設定

ジョブ投入時に利用制限がかけられるのは上述の通りですが、QoS設定を行うにはsacctmgrを使って、slurmdbd内にLinuxユーザーと同一ユーザーを作成し紐づけたうえで、QoSプロファイルを同コマンドで作成する必要があります。（正確にはslurm.confも少々触らないといけません）
今回はSlurmでの基本的なジョブ管理イメージを掴んで頂くことがメインなので本記事では割愛します。

7. まとめ

今回の記事は、「Slurmって聞いたことはあるけど、触ったことはない」という方を主な対象として、まずは「直感的に理解する」ことをゴールにして書いてみたつもりです。
ジョブスケジューラの概念や役割を押さえつつ、少し踏み込んで実際のコマンドを使ったリソース確保・ジョブ投入・状態確認・停止といった操作例を見ていただくことで、具体的なイメージが掴めた（？）のではないかと思います。
ただ、Slurmは触れば触るほど奥が深い部分もあります。

• 大規模クラスタの緻密なスケジューリング
• QoSやアカウンティングによる利用制御
• Backfillや優先度調整による効率最適化

こうした高度な運用テクニックは、慣れてからゆっくり学んでいけば良いかなと思います。
一方で、本記事で取り上げた基本コマンドだけでも、日常的なジョブ管理には十分実用的です。まずはこの基本を押さえ、少しずつ自分の環境に合わせた運用へと広げてみてください！