【第8回】エンタープライズ向け運用ベストプラクティスとトラブルシューティング：ローカルLLMインフラの完成

全8回にわたる連載「LinuxエンジニアのためのローカルLLM」も、ついに今回が最終回となります。第1回の概念理解から始まり、AlmaLinux 9上でのNVIDIA CUDA環境の最適化（第2回）、Ollamaやllama.cppによる推論エンジンの構築（第3回・第4回）、そしてエンタープライズ向けのvLLMサーバーとQdrantによるRAG基盤の構築（第5回・第6回）、最後にPrometheus/Grafanaを用いた監視・セキュリティ設計（第7回）と、インフラエンジニアの視点で「安全かつ高速な生成AI基盤」をゼロから組み上げてきました。

システム構築が完了し、社内ユーザーへのサービス提供が開始されると、プロジェクトは「構築フェーズ」から「運用保守フェーズ（Day 2 Operation）」へと移行します。しかし、AIインフラの運用は、従来のWebサーバーやデータベースの運用とは異なる特有の難しさが存在します。

本記事では、AlmaLinux環境におけるコンテナベースのAI基盤を前提とし、モデルの無停止アップデート（Blue-Greenデプロイ）、RAG基盤のバックアップ戦略、GPU特有のメモリリークの検知と復旧フローなど、現場で直面する高度な運用課題の解決策を徹底解説します。

---

1. 本番運用で直面する「AIインフラ特有の壁」とは

一般的なWebアプリケーション（PHPやRubyなどで書かれたステートレスなシステム）であれば、アプリケーションのアップデートはGitからコードをPullし、コンテナを再起動するか、ロードバランサーの後ろで数秒かけてプロセスを切り替えるだけで完了します。しかし、LLMインフラにおいては、この常識が通用しません。

1.1. 巨大なモデルファイルのロード時間（コールドスタート問題）

LLMの推論エンジン（vLLMやOllamaなど）が起動する際、ストレージ（NVMe SSD等）に保存されている数GBから数十GBのモデルファイル（重みデータ）を、一度メインメモリ（RAM）に読み込み、そこからさらにGPUのVRAMへと転送するプロセスが発生します。
この転送プロセスには、PCIeバスの帯域幅やストレージの読み込み速度に依存しますが、通常数十秒から数分かかります。つまり、コンテナを単に systemctl restart するだけでは、「数十秒〜数分間にわたってAPIが完全に沈黙し、ユーザーからのリクエストがタイムアウトする」という最悪のダウンタイムが発生します。

1.2. VRAM容量の絶対的な制約（並行デプロイの困難さ）

「ダウンタイムを防ぐために、新しいバージョンのLLMコンテナを別ポートで立ち上げ、ロードバランサー（Nginx）でトラフィックを切り替えてから古いコンテナを落とそう」と考えるのは、インフラエンジニアとして非常に正しい発想（Blue-Greenデプロイメント）です。
しかし、AIインフラにおいては「VRAMの空き容量」がそれを許しません。
第5回で解説した通り、vLLMなどの本番向け推論エンジンは、起動時にVRAMの80〜90%を確保（事前割り当て）してしまいます。そのため、同一のGPU上で「古いコンテナ」と「新しいコンテナ」を同時に起動しようとすると、後から起動したコンテナは100%確実に CUDA Out of Memory でクラッシュします。

この「巨大なロード時間」と「VRAMの占有」という相反する制約をどう乗り越えて無停止アップデートを実現するかが、AIインフラ運用の最大の関門となります。

2. モデルの無停止アップデート戦略（Blue-Greenデプロイメント）

2.1. マルチノード構成におけるBlue-Greenデプロイの流れ

前提として、前段にNginxやHAProxyなどのリバースプロキシ（ロードバランサー）が配置されており、バックエンドとして複数のGPUサーバー（例：gpu-node-01, gpu-node-02）でvLLMが稼働しているアーキテクチャを想定します。

1. トラフィックの切り離し（Drain）： ロードバランサーの設定を変更し、gpu-node-01 をバックエンドプールから切り離します。この際、すでに処理中のリクエストが完了するまで待つ「グレイスフル・ドレイン」を行います。
2. モデルのダウンロードとキャッシュ： gpu-node-01 のホストOS上で、新しいモデル（例：Llama 3.1 8B）を事前にダウンロードしておきます。
3. コンテナの再起動（VRAMの解放と再確保）： gpu-node-01 のvLLMコンテナ（Quadletのsystemdサービス）を停止し、VRAMを完全に解放します。その後、新しいモデルを指定してコンテナを再起動します。
4. ヘルスチェックと再組み込み： 数分後、新しいvLLMがモデルのロードを完了し、APIエンドポイント（/health など）が 200 OK を返すようになったことを確認してから、ロードバランサーのバックエンドプールに gpu-node-01 を戻します。
5. ローリング・アップデート： gpu-node-02 に対しても同様の手順を繰り返します。

2.2. Nginxを用いた動的切り替えスクリプトの例

上記の手順を手動で行うのはヒューマンエラーの元です。インフラエンジニアとしては、以下のようなシェルスクリプトやAnsibleを用いて切り替え作業を自動化します。

#!/bin/bash
# Nginxのバックエンド切り離しとvLLMコンテナのローリングアップデート例

NODE="gpu-node-01"
NGINX_CONF="/etc/nginx/conf.d/vllm_upstream.conf"

echo "=== ${NODE} の切り離しを開始 ==="
# Nginxの設定ファイルを書き換え、対象ノードを down にする
sudo sed -i "s/server ${NODE}:8000;/server ${NODE}:8000 down;/g" ${NGINX_CONF}
sudo systemctl reload nginx

echo "処理中のリクエスト完了を待機中 (30秒)..."
sleep 30

echo "=== ${NODE} のvLLMコンテナを停止・モデル更新・起動 ==="
# リモートでSSH経由にてQuadletサービスを再起動（※事前にUnitファイルのモデルパスは更新済みとする）
ssh admin@${NODE} "sudo systemctl restart vllm.service"

echo "vLLMの起動（モデルロード）を待機中..."
# APIが応答するまでポーリング（最大5分）
for i in {1..30}; do
    STATUS=$(curl -s -o /dev/null -w '%{http_code}' http://${NODE}:8000/health || true)
    if [ "$STATUS" = "200" ]; then
        echo "vLLMの起動を確認しました。"
        break
    fi
    sleep 10
done

echo "=== ${NODE} をロードバランサーに復帰 ==="
sudo sed -i "s/server ${NODE}:8000 down;/server ${NODE}:8000;/g" ${NGINX_CONF}
sudo systemctl reload nginx
echo "アップデート完了"

このように、インフラレイヤーでの確実なトラフィック制御と、VRAMのリソース解放タイミングを完全にコントロールすることが、AIインフラの運用保守の基本となります。

3. RAG基盤：Qdrantベクトルデータベースのバックアップとリストア設計

LLM本体（推論エンジン）は、極論すれば「モデルファイルを再度ダウンロードすれば復旧できる」ステートレス（状態を持たない）なコンテナです。しかし、RAG基盤の中核を担う「Qdrant」などのベクトルデータベースは、社内の機密ドキュメントやベクトルデータが蓄積されたステートフル（状態を持つ）な永続化ストレージであり、インフラエンジニアが最も慎重にバックアップ設計を行うべきコンポーネントです。

3.1. ベクトルDBのデータ構造と破損リスク

Qdrantはデータをディスク（NVMe SSD等）にメモリマップトファイル（mmap）として書き込んでいます。稼働中のQdrantコンテナに対して、単にホストOS上から tar や cp コマンドで /var/lib/qdrant/storage ディレクトリを丸ごとコピーすると、メモリ上のインデックス情報とディスク上のデータが不整合を起こし、リストア時に確実にデータが破損（Corrupt）します。

3.2. QdrantのスナップショットAPIを用いたバックアップ自動化

Qdrantには、REST API経由でコレクション（テーブルに相当）のスナップショットを作成し、それを一つのファイルとしてダウンロードできる機能が備わっています。
以下のスクリプトは、AlmaLinuxの cron や systemd timer を用いて毎晩自動実行し、スナップショットを安全な外部ストレージ（S3やNFSなど）へ退避するための実用的なバックアップスクリプトの例です。

#!/bin/bash
# Qdrant Vector DB スナップショットバックアップスクリプト

QDRANT_HOST="127.0.0.1:6333"
COLLECTION_NAME="internal_documents"
BACKUP_DIR="/mnt/nfs/ai_backups/qdrant"
DATE=$(date +%Y%m%d_%H%M%S)

# 1. スナップショットの作成をAPI経由で要求
echo "Creating snapshot for collection: ${COLLECTION_NAME}..."
CREATE_RESP=$(curl -s -X POST "http://${QDRANT_HOST}/collections/${COLLECTION_NAME}/snapshots")

# JSONレスポンスからファイル名を抽出 (jqコマンドが必要)
SNAPSHOT_NAME=$(echo $CREATE_RESP | jq -r '.result.name')

if [ "$SNAPSHOT_NAME" == "null" ] || [ -z "$SNAPSHOT_NAME" ]; then
    echo "Error: スナップショットの作成に失敗しました。"
    exit 1
fi

echo "Snapshot created: ${SNAPSHOT_NAME}"

# 2. スナップショットファイルのダウンロード
DOWNLOAD_URL="http://${QDRANT_HOST}/collections/${COLLECTION_NAME}/snapshots/${SNAPSHOT_NAME}"
BACKUP_FILE="${BACKUP_DIR}/${COLLECTION_NAME}_${DATE}.snapshot"

echo "Downloading snapshot to ${BACKUP_FILE}..."
curl -s -o "${BACKUP_FILE}" "${DOWNLOAD_URL}"

# 3. サーバー側に残った古いスナップショットのクリーンアップ（容量節約）
curl -s -X DELETE "http://${QDRANT_HOST}/collections/${COLLECTION_NAME}/snapshots/${SNAPSHOT_NAME}" > /dev/null

echo "Backup completely successfully: ${BACKUP_FILE}"

# 4. (オプション) 保持期間を過ぎたローカルの古いバックアップファイルの削除
find ${BACKUP_DIR} -name "*.snapshot" -type f -mtime +30 -exec rm -f {} \;

この運用を定着させることで、ランサムウェア被害やサーバーの物理的なハードウェア障害が発生した場合でも、別のAlmaLinuxサーバーにQdrantコンテナを立ち上げ、API経由でスナップショットをリストアするだけで、RAG基盤を即座に復旧させることが可能になります。

4. GPUメモリリークと異常検知時の緊急対応フロー（トラブルシューティング）

監視基盤（Prometheus/Grafana）もバックアップも完璧に整えたとしても、AI特有の予期せぬトラブルは必ず発生します。中でもインフラエンジニアを最も悩ませるのが、GPUにおける「VRAMのメモリリーク（ゾンビプロセス化）」と「PCIeバスのエラー」です。

4.1. VRAMを占有しているゾンビプロセスの特定とキル

コンテナが停止しているのにVRAMが解放されない場合、まずはGPUを使用しているホスト側のプロセス（PID）を強制的に特定してキルする必要があります。nvidia-smi コマンド単体ではプロセスIDが見えないことがあるため、以下のコマンド群を使用します。

# GPUを使用しているプロセス一覧（PIDとVRAM使用量）を表示
sudo fuser -v /dev/nvidia*

# または、lsofコマンドで /dev/nvidia0 等を開いているプロセスを特定
sudo lsof /dev/nvidia0

# 特定したPID（例：12345）を強制終了（SIGKILL）してVRAMを解放する
sudo kill -9 12345

これで通常はVRAMが解放され、nvidia-smi の使用量が正常な状態（0 MiB）に戻ります。

4.2. GPUのリセット（ドライバスタックのフリーズ時）

上記の手順でプロセスをキルしてもVRAMが解放されない場合、または nvidia-smi コマンド自体がハングアップして応答を返さなくなるという致命的な状況に陥るケースがあります。これはNVIDIAカーネルモジュール自体がデッドロックを起こしている状態です。

OS全体の再起動（Reboot）が最も確実ですが、ダウンタイムを最小限にするため、まずはNVIDIAドライバのリセット（デバイスリセット）を試みます。

# 注意：関連するすべてのAIコンテナ・エクスポーターを停止してから実行すること
sudo systemctl stop vllm.service
sudo systemctl stop dcgm-exporter.service

# GPUデバイスのリセットを実行
sudo nvidia-smi --gpu-reset

# リセットに失敗し、モジュールが使用中(in use)でなければ、ドライバの再ロードを試みる
sudo rmmod nvidia_uvm
sudo rmmod nvidia
sudo modprobe nvidia
sudo modprobe nvidia_uvm

それでも復旧しない場合は、ハードウェア障害（GPUのサーマルダメージやPCIeバスのパリティエラー）の可能性が高いため、サーバーのコールドリブート（電源断からの再起動）を実施し、カーネルの dmesg ログ（NVRM: Xid エラーなど）を確認して物理的な故障を疑うフェーズに移行します。

5. コスト最適化とインフラサイジングの継続的見直し

エンタープライズ環境におけるインフラエンジニアのもう一つの重要なミッションは「コスト（ROI）の最適化」です。

AIプロジェクトの初期（PoC）は、「とにかく高性能なサーバーを立てる」というアプローチで進みがちですが、第7回で構築したPrometheus/Grafanaのメトリクスが蓄積されてくると、「オーバースペック」または「アンダースペック」な部分が明確に数値として表れてきます。

5.1. メトリクスに基づくダウングレード戦略

• VRAMは余っているが、Tokens/secが低い場合： モデルサイズに対してコンピュート能力（CUDAコア数）が不足しています。VRAM容量はそのままに、コア数の多いGPUへのリプレイスを検討します。
• GPU使用率が常に20%以下の場合： トラフィックに対してGPUの馬力が過剰です。この場合、高価なGPU（A100等）から安価なGPU（RTXシリーズ等）にダウングレードするか、または第4回で解説した llama.cpp と GGUF 量子化によるCPU単体推論環境へ移行することで、インフラコストを劇的に削減できます。

クラウドAPI（OpenAI等）を利用する場合はトークンごとの従量課金となるため、使えば使うほどコストが青天井で膨れ上がります。しかしローカルLLMインフラであれば、固定のハードウェア資産の上で「インフラエンジニアがチューニングしてスループットを上げれば上げるほど、1リクエストあたりの単価が下がる」という圧倒的なスケールメリットを享受できます。これこそがオンプレミス・自社インフラAIの最大の魅力です。

6. 本連載の総まとめ：インフラエンジニアが創るAIの未来

全8回にわたる本連載「LinuxエンジニアのためのローカルLLM」では、AlmaLinux 9をベースとした堅牢なAIインフラ基盤の構築と運用について、徹底的に解説してきました。

• 第1回〜第2回： ローカルLLMのアーキテクチャ全体像と、AlmaLinux上でのNVIDIA CUDA・ドライバ環境のクリーンなインフラ構築手法。
• 第3回〜第4回： OllamaによるDockerライクな手軽なコンテナ管理と、llama.cppによるCPU/低VRAM環境での限界突破チューニング（GGUF・NUMA最適化）。
• 第5回〜第6回： vLLM（PagedAttention）による本番向け高スループット推論サーバーと、Qdrantを用いたセキュアなRAG（ベクトルデータベース）連携アーキテクチャ。
• 第7回〜第8回： Prometheus/GrafanaによるAI特有のメトリクス監視、ゼロトラスト・セキュリティ設計、そしてモデルの無停止アップデートとトラブルシューティングのベストプラクティス。

生成AIの技術進化は凄まじいスピードで進んでおり、新しいAIモデルやフレームワークが毎日のように登場しています。しかし、それを支える根底の技術——「LinuxOSのメモリ管理」「プロセス制御」「コンテナのネットワーキング」「ハードウェアリソースの厳格なサイジング」——は、インフラエンジニアが長年培ってきた普遍的なスキルそのものです。

AIの民主化は、一部の巨大テック企業だけのものではありません。自社のデータを守り、自社のビジネスプロセスに完全に統合されたAIシステムをオンプレミスで稼働させる技術力は、これからの時代のインフラエンジニアにとって最強の武器となります。
本連載が、皆様のローカルLLM環境構築とエンタープライズAI運用の成功への確かな道標となることを願っています。最後までお読みいただき、本当にありがとうございました！