はじめに Kubernetes上でLLMの推論などGPUを使うワークロードを動かすには、GPUノードにドライバを入れ、PodからGPUを利用できる状態にしておく必要があります。本記事では、インターネットに接続できないAirGap環境のRKE2クラスタに対して、NVIDIA GPU DriverとNVIDIA GPU Operatorを導入し、Kubernetes上でGPUを使えるようにするまでの手順を紹介します。 SUSE AIのようなKubernetes上のAI基盤を構築する際の前提作業にあたりますが、手順自体は特定のAI基盤に依存しない汎用的な内容です。RKE2以外のKubernetesディストリビューションでも、containerdのソケットや設定ファイルのパスを読み替えれば応用できます。 GPU設定に必要なツール KubernetesでGPUを使うには、ノードのOS側でGPUを動かす「NVIDIA GPU Driver」と、Kubernetes側でGPUをリソースとして扱うためのコンポーネント群をまとめて管理する「NVIDIA GPU Operator」の2つが必要です。 NVIDIA GPU Driver NVIDIA GPU Driverは、OSがGPUを認識・制御するためのソフトウェアです。カーネルモジュール（ nvidia 、 nvidia_uvm など）と、 libnvidia-ml.so や libcuda.so といったユーザー空間ライブラリ、 nvidia-smi などの管理ツールで構成されます。コンテナ内のCUDAアプリケーションも、最終的にはホスト上のこのドライバを経由してGPUを利用します。 Kubernetesで使う場合、ドライバの導入方法は次の2通りです。 ホストOSに直接インストールする ：OSのパッケージ管理でドライバを入れる方法です。 GPU Operatorのドライバコンテナで入れる ：GPU Operatorがドライバ入りのコンテナを各ノードで動かし、カーネルモジュールをロードする方法です。 ホストOSに直接インストールする方法はドライバをOSのパッケージ管理で扱えるため、OSの更新やイメージ管理とあわせてドライバを管理したい場合に向いています。また、Kubernetes以外のプロセスからもGPUを使いやすくなります。 GPU Operatorのドライバコンテナで入れる方法は、OperatorがすべてのGPUノードにドライバを自動で導入し、更新も管理するため、GPUノードが多い場合や頻繁に増減する場合に向いています。 本記事では前者のホストOSへの直接インストールの手順を解説します。 なお、ドライバのバージョンはGPU Operatorのサポート対象から選びます（ Release Notes ）。 NVIDIA GPU Operator NVIDIA GPU Operatorは、KubernetesでGPUを使うために必要なNVIDIAのソフトウェア一式を、Operatorパターンで自動的にデプロイ・管理する仕組みです。本来はノードごとに個別に設定する必要があるコンテナランタイムの設定やDevice Pluginなどを、 ClusterPolicy というカスタムリソースでまとめて宣言的に管理できます。 出典： About the NVIDIA GPU Operator GPU Operatorが管理する主なコンポーネントと、本記事での扱いは次のとおりです。 コンポーネント 役割 本記事での扱い Node Feature Discovery（NFD） ノードのハードウェア情報を検出し、NVIDIA GPU搭載ノードにラベルを付与 有効 GPU Feature Discovery（GFD） GPUの型番・メモリ量・ドライババージョンなどを nvidia.com/* ラベルとして付与 有効 NVIDIA Container Toolkit コンテナランタイム（containerd）を設定し、コンテナからGPUを使えるようにする 有効 NVIDIA Device Plugin GPUを拡張リソース nvidia.com/gpu としてkubeletに登録し、Podへ割り当てる 有効（タイムスライシング設定あり） DCGM Exporter GPUの使用率や温度などのメトリクスをPrometheus形式で公開 有効 Operator Validator ドライバ・Toolkit・Device Pluginが正しく動作しているか検証 有効 NVIDIA Driver（コンテナ） ドライバをコンテナとして導入 無効（ホストに導入済みのため） MIG Manager MIG対応GPUの分割構成を管理 無効（MIG非対応のGPUノードを使うため） 設定手順 設定概要 AirGap環境では、インターネットに接続できる作業用端末で必要な資材を集め、閉域側のノードやレジストリへ運び込んでから設定します。全体の流れは次のとおりです。 作業用端末でNVIDIA GPU Driverのパッケージ（.deb）をダウンロードし、GPUノードへ転送する GPUノードにNVIDIA GPU Driverをインストールし、動作を確認する 必要に応じてGPUノードにラベルとテイントを設定する 作業用端末でGPU OperatorのHelmチャートとコンテナイメージを取得し、閉域内のHelmリポジトリ・コンテナレジストリへ登録する RKE2のHelmChartリソースでGPU OperatorをDownstream Clusterにインストールし、動作を確認する インターネットに接続できるのは作業用端末だけです。Downstream Clusterは、閉域内のHarborからチャートとイメージを取得します。 前提条件 GPUノードのOSが、NVIDIA GPU DriverとGPU Operatorのサポート対象であること（ Platform Support ） SUSE Rancher PrimeのRancher Management Server（以下、RMS）と、RMSから管理されるRKE2のDownstream Clusterが構築済みであること RMSとDownstream ClusterはAirGap環境にあり、インターネットに接続できないこと Downstream ClusterのRKE2がcontainerd 2.x系を同梱していること（GPU Operator v25.10以降のCDIを使う前提） インターネットに接続できる作業用端末があり、GPUノードと同じOS・バージョン（本記事ではUbuntu 24.04）であること 作業用端末に helm 、 skopeo 、 kubectl 、Docker（またはPodman）が導入されていること 作業用端末からGPUノードへSSH接続できること 作業用端末からDownstream Clusterを kubectl で操作できること（RMSから取得したkubeconfigを利用） 作業用端末とDownstream Clusterの両方から接続できる、OCI対応のコンテナレジストリ・Helmリポジトリがあること。また、Downstream Clusterの各ノードがそこからイメージを取得できること（RKE2の registries.yaml 設定など） 構築環境 本記事の検証環境は次のとおりです。GPU Operatorの各コンポーネントは、v26.3.3のデフォルトバージョンを使っています。 項目 バージョン・設定 OS Ubuntu 24.04 RKE2 v1.36.3+rke2r1 Rancher Prime v2.15.2 搭載GPU NVIDIA Tesla T4（AWS g4dn.2xlarge） コンテナレジストリ・Helmリポジトリ Harbor NVIDIA GPU Driver 580.178.04（nvidia-driver-580-server） NVIDIA GPU Operator v26.3.3 NVIDIA Container Toolkit v1.19.1 NVIDIA Device Plugin / GPU Feature Discovery v0.19.3 DCGM Exporter 4.5.3-4.8.2-distroless Node Feature Discovery v0.18.3 NVIDIA GPU Driver 設定手順 最初にGPUノードで、搭載されているGPUの種類とカーネルバージョンを確認します。カーネルバージョンは、後でカーネルヘッダをダウンロードする際に使います。 $ lspci | grep -i nvidia # 出力例 00:1e.0 3D controller: NVIDIA Corporation TU104GL [Tesla T4] (rev a1) $ uname -r # 出力例 7.0.0-1012-aws 次に、作業用端末でドライバのパッケージをダウンロードします。apt-get install –download-onlyは、実行した環境に導入済みのパッケージをダウンロード対象から外します。そこで、GPUノードと同じUbuntu 24.04のクリーンなコンテナを起動し、その中でダウンロードします。こうすると作業用端末の環境に左右されず、依存パッケージを漏れなく集められます。 $ mkdir -p ~/nvidia-driver-pkgs $ docker run --rm -it -v ~/nvidia-driver-pkgs:/pkgs ubuntu:24.04 bash コンテナ内で、利用可能なドライバを確認します。データセンター向けGPUでは、末尾が -server のパッケージを選びます。 # apt-get update # apt-cache search nvidia-driver | grep server # 出力例 nvidia-driver-470-server - NVIDIA Server Driver metapackage ・ ・ ・ nvidia-driver-580-server - NVIDIA Server Driver metapackage 使用するドライバを決めたら、カーネルヘッダとあわせてダウンロードします。ドライバのDKMSモジュールはGPUノード上でビルドされるため、GPUノードのカーネルに対応した linux-headers が必要です。指定できるバージョンは Launchpad で確認できます。 7.0.0-1012-aws のカーネルバージョンで nvidia-driver-580-server をインストールする場合は、コンテナ内で次のように実行します。ダウンロードしたパッケージは、マウントした /pkgs 経由で作業用端末の ~/nvidia-driver-pkgs に保存されます。 # apt-get install --download-only -y \ nvidia-driver-580-server=580.178.04-0ubuntu0.24.04.1 \ linux-headers-<GPUノードのカーネルバージョン> # cp /var/cache/apt/archives/*.deb /pkgs/ # exit クリーンなコンテナでダウンロードするため、GPUノードに導入済みの基本パッケージも含まれます。GPUノードのパッケージが古い場合、インストール時にそれらも更新される点に注意してください。 ダウンロードしたパッケージを、作業用端末からGPUノードに転送します。 $ scp -r -i <SSH鍵> ~/nvidia-driver-pkgs ubuntu@<GPUノードIP>:~/ GPUノード上でパッケージをインストールし、再起動します。 $ cd ~/nvidia-driver-pkgs $ apt-get install -y --no-download ./*.deb $ sudo reboot 動作確認 再起動後、インストールが正常に完了したかをGPUノード上で確認します。まず、 nvidia-smi でGPUの情報とドライババージョンが表示されることを確認します。 $ nvidia-smi # 出力例 Fri Sep 25 06:34:12 2026 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 580.178.04 Driver Version: 580.178.04 CUDA Version: 13.0 | +-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 | | N/A 32C P0 26W / 70W | 0MiB / 15360MiB | 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ +-----------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=========================================================================================| | No running processes found | +-----------------------------------------------------------------------------------------+ 次に、NVIDIAのカーネルモジュールがロードされていることを確認します。 $ lsmod | grep nvidia # 出力例 nvidia_uvm 2080768 0 nvidia_drm 139264 0 nvidia_modeset 1687552 1 nvidia_drm nvidia 105373696 3 nvidia_uvm,nvidia_drm,nvidia_modeset drm_ttm_helper 20480 1 nvidia_drm video 77824 1 nvidia_modeset 最後に、GPU Operatorの各コンポーネントがドライバとのやり取りに使う libnvidia-ml.so が存在することも確認しておきます（ RKE2 GPU Operators ）。 $ find /usr/ -iname libnvidia-ml.so* # 出力例 /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1 /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.580.178.04 /usr/lib/x86_64-linux-gnu/libnvidia-ml.so ノードラベリング・テイント設定 GPUを使うアプリケーションだけをGPUノードに配置したい場合は、ラベルとテイントで管理します。ここからの kubectl は、Downstream Clusterのkubeconfigを設定した作業用端末（またはRancher UIのkubectlシェル）で実行します。 ラベルは、ワークロードの nodeSelector や nodeAffinity でGPUノードを指定するために付与します。GPU Operatorの導入後は nvidia.com/gpu.present=true などのラベルも自動で付与されるため、独自ラベルは運用上の必要に応じて付けてください。 $ kubectl label node <GPUノード名> accelerator=nvidia-gpu テイントは、GPUを使わないPodがGPUノードに配置されるのを防ぐために設定します。 $ kubectl taint nodes <GPUノード名> nvidia.com/gpu=dedicated:NoSchedule GPU OperatorのDaemonSetは、デフォルトで nvidia.com/gpu キーの NoSchedule テイントを許容する設定になっているため、このテイントを先に設定しても導入に影響はありません。一方、GPUを使うワークロード側には同じキーの tolerations を設定する必要があります。 NVIDIA GPU Operator 設定手順 まず、閉域内のHarborに次の2つのプロジェクトを作成します。 nvidia-chart ：GPU OperatorのHelmチャート用 nvidia ：GPU Operatorが使うコンテナイメージ用 プロジェクトを非公開にする場合は、Downstream Cluster側にも認証情報の設定が必要です（イメージは registries.yaml 、チャートはHelmChartリソースの認証用フィールド）。 作業用端末からNVIDIA GPU OperatorのHelmチャートをダウンロードします。 $ helm repo add nvidia https://helm.ngc.nvidia.com/nvidia $ helm repo update $ helm pull nvidia/gpu-operator --version v26.3.3 Helmリポジトリにログインし、チャートをOCI形式で登録します。本記事のHarborは自己署名証明書のためTLS検証をスキップしています。 $ helm registry login <Helmリポジトリのドメイン> \ --username <Helmリポジトリのユーザ名> \ --password <Helmリポジトリのパスワード> \ --insecure $ helm push gpu-operator-v26.3.3.tgz oci://<Helmリポジトリのドメイン>/nvidia-chart --insecure-skip-tls-verify 次に、GPU Operatorが使うコンテナイメージを skopeo でコンテナレジストリへコピーします。 コピー元イメージ 使用するコンポーネント nvcr.io/nvidia/gpu-operator:v26.3.3 GPU Operator本体、Operator Validator nvcr.io/nvidia/k8s/container-toolkit:v1.19.1 NVIDIA Container Toolkit nvcr.io/nvidia/k8s-device-plugin:v0.19.3 NVIDIA Device Plugin、GPU Feature Discovery nvcr.io/nvidia/k8s/dcgm-exporter:4.5.3-4.8.2-distroless DCGM Exporter registry.k8s.io/nfd/node-feature-discovery:v0.18.3 Node Feature Discovery ${src#*/} で先頭の nvcr.io/ を取り除き、 <コンテナレジストリのドメイン>/nvidia/... という同じ階層でコピーしています。NFDのみ取得元が異なるため、個別にコピーします。 $ REGISTRY=<コンテナレジストリのドメイン> $ skopeo login --tls-verify=false ${REGISTRY} $ for src in \ nvcr.io/nvidia/gpu-operator:v26.3.3 \ nvcr.io/nvidia/k8s/container-toolkit:v1.19.1 \ nvcr.io/nvidia/k8s-device-plugin:v0.19.3 \ nvcr.io/nvidia/k8s/dcgm-exporter:4.5.3-4.8.2-distroless; do skopeo copy --dest-tls-verify=false docker://${src} docker://${REGISTRY}/${src#*/} done $ skopeo copy --dest-tls-verify=false \ docker://registry.k8s.io/nfd/node-feature-discovery:v0.18.3 \ docker://${REGISTRY}/nvidia/node-feature-discovery:v0.18.3 RKE2のHelmChartリソースとして、GPU Operatorのインストール設定を記載した gpu-operator-helm-chart.yaml を作成します。ポイントは次の3点です。 イメージの参照先 ：各コンポーネントの repository を閉域内のレジストリに向けます。 ホスト導入済みドライバの利用 ： driver.enabled: false とし、使わないコンポーネントも無効にして、ミラーが必要なイメージを減らしています。MIG対応GPUを使う場合は migManager を有効にし、 k8s-mig-manager イメージもコピーしてください。 RKE2固有の設定 ：RKE2のcontainerdはソケットの場所が標準と異なるため、 toolkit.env で CONTAINERD_SOCKET を指定します（ RKE2 GPU Operators ）。 devicePlugin.config はタイムスライシングの設定です。 replicas: 4 により、1枚の物理GPUを4つの nvidia.com/gpu として公開し、複数のPodで時分割共有できます。ただし、Pod間でGPUメモリは分離されないため、不要な場合は config ブロックごと削除してください（ Time-Slicing GPUs ）。 apiVersion: helm.cattle.io/v1 kind: HelmChart metadata: name: gpu-operator namespace: kube-system spec: chart: oci://<Helmリポジトリのドメイン>/nvidia-chart/gpu-operator version: v26.3.3 targetNamespace: gpu-operator createNamespace: true insecureSkipTLSVerify: true valuesContent: |- validator: repository: <コンテナレジストリのドメイン>/nvidia image: gpu-operator version: v26.3.3 operator: repository: <コンテナレジストリのドメイン>/nvidia image: gpu-operator version: v26.3.3 devicePlugin: repository: <コンテナレジストリのドメイン>/nvidia image: k8s-device-plugin version: v0.19.3 # タイムスライシングを使わない場合はconfigブロックを削除 config: create: true name: "time-slicing-config" default: "t4-sharing" data: t4-sharing: |- version: v1 flags: migStrategy: none sharing: timeSlicing: resources: - name: nvidia.com/gpu replicas: 4 dcgmExporter: repository: <コンテナレジストリのドメイン>/nvidia/k8s image: dcgm-exporter version: 4.5.3-4.8.2-distroless gfd: repository: <コンテナレジストリのドメイン>/nvidia image: k8s-device-plugin version: v0.19.3 toolkit: repository: <コンテナレジストリのドメイン>/nvidia/k8s image: container-toolkit version: v1.19.1 env: - name: CONTAINERD_SOCKET value: /run/k3s/containerd/containerd.sock node-feature-discovery: image: repository: <コンテナレジストリのドメイン>/nvidia/node-feature-discovery tag: v0.18.3 # ホストにドライバを導入済みのため無効化 driver: enabled: false # 本記事では使わないコンポーネント migManager: enabled: false vgpuDeviceManager: enabled: false vfioManager: enabled: false sandboxDevicePlugin: enabled: false kataSandboxDevicePlugin: enabled: false ccManager: enabled: false 作成したHelmChartリソースをDownstream Clusterに適用します。RKE2のHelm Controllerがチャートを取得し、GPU Operatorをインストールします。 $ kubectl apply -f gpu-operator-helm-chart.yaml Container Toolkitは設定を反映するためにcontainerdへ再読み込みを指示し、その影響でGPUノードのRKE2が再起動します。稼働中のワークロードがある場合は、作業タイミングに注意してください。 動作確認 GPU OperatorのPodがすべて Running または Completed になっていることを確認します。出力例はGPUノード2台の環境のものです。 $ kubectl get pod -n gpu-operator # 出力例 NAME READY STATUS RESTARTS AGE gpu-feature-discovery-8t85l 2/2 Running 0 5m gpu-feature-discovery-kkwbb 2/2 Running 0 5m gpu-operator-7974d8cf9-qq7bh 1/1 Running 0 5m gpu-operator-node-feature-discovery-gc-5c84b6f5c4-tmf9k 1/1 Running 0 5m gpu-operator-node-feature-discovery-master-6db6986c58-bjdsg 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-55v8j 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-b944b 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-cxrxs 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-kmmv2 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-qnz9w 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-wxln9 1/1 Running 0 5m nvidia-container-toolkit-daemonset-4kkbt 1/1 Running 0 5m nvidia-container-toolkit-daemonset-vbgnc 1/1 Running 0 5m nvidia-cuda-validator-b8grf 0/1 Completed 0 5m nvidia-cuda-validator-z7skc 0/1 Completed 0 5m nvidia-dcgm-exporter-6dhd5 1/1 Running 0 5m nvidia-dcgm-exporter-8mhhp 1/1 Running 0 5m nvidia-device-plugin-daemonset-6v4xz 2/2 Running 0 5m nvidia-device-plugin-daemonset-snx4x 2/2 Running 0 5m nvidia-operator-validator-4ldlj 1/1 Running 0 5m nvidia-operator-validator-kctw6 1/1 Running 0 5m GPU Operator全体の状態を表すClusterPolicyが ready になっていることも確認します。 $ kubectl get clusterpolicy # 出力例 NAME STATUS AGE cluster-policy ready <作成日時> 以下のコマンドを実行し、GPUノードのラベルに nvidia.com/gpu.machine などのGPU関連ラベルが付与されていることを確認します。 $ kubectl get node <GPUノード名> -o jsonpath='{.metadata.labels}' | tr ',' '\n' | grep "nvidia.com" # 出力例 "nvidia.com/cuda.driver-version.full":"580.178.04" "nvidia.com/cuda.driver-version.major":"580" "nvidia.com/cuda.driver-version.minor":"178" "nvidia.com/cuda.driver-version.revision":"04" "nvidia.com/cuda.driver.major":"580" "nvidia.com/cuda.driver.minor":"178" "nvidia.com/cuda.driver.rev":"04" "nvidia.com/cuda.runtime-version.full":"13.0" "nvidia.com/cuda.runtime-version.major":"13" "nvidia.com/cuda.runtime-version.minor":"0" "nvidia.com/cuda.runtime.major":"13" "nvidia.com/cuda.runtime.minor":"0" "nvidia.com/gfd.timestamp":"1790646472" "nvidia.com/gpu.compute.major":"7" "nvidia.com/gpu.compute.minor":"5" "nvidia.com/gpu.count":"1" "nvidia.com/gpu.deploy.container-toolkit":"true" "nvidia.com/gpu.deploy.dcgm":"true" "nvidia.com/gpu.deploy.dcgm-exporter":"true" "nvidia.com/gpu.deploy.device-plugin":"true" "nvidia.com/gpu.deploy.driver":"true" "nvidia.com/gpu.deploy.gpu-feature-discovery":"true" "nvidia.com/gpu.deploy.node-status-exporter":"true" "nvidia.com/gpu.deploy.operator-validator":"true" "nvidia.com/gpu.family":"turing" "nvidia.com/gpu.machine":"g4dn.2xlarge" "nvidia.com/gpu.memory":"15360" "nvidia.com/gpu.mode":"compute" "nvidia.com/gpu.present":"true" "nvidia.com/gpu.product":"Tesla-T4-SHARED" "nvidia.com/gpu.replicas":"4" "nvidia.com/gpu.sharing-strategy":"time-slicing" "nvidia.com/mig.capable":"false" "nvidia.com/mig.strategy":"single" "nvidia.com/mps.capable":"false" "nvidia.com/vgpu.present":"false" ノードの割り当て可能リソースに nvidia.com/gpu が追加されていることを確認します。値は「物理GPUの枚数 × タイムスライシングのreplicas」で、本記事では1 × 4 = 4です。タイムスライシングを使わない場合は物理GPUの枚数と一致します。 $ kubectl get node <GPUノード名> -o jsonpath='{.status.allocatable}' # 出力例 {"cpu":"8","ephemeral-storage":"196555267123","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"32479456Ki","nvidia.com/gpu":"4","pods":"110"} GPUノード上で、NVIDIAコンテナランタイムのバイナリが配置され、RKE2のcontainerd設定にNVIDIAランタイムが追加されていることを確認します。 $ ls /usr/local/nvidia/toolkit/nvidia-container-runtime # 出力例 /usr/local/nvidia/toolkit/nvidia-container-runtime $ grep nvidia /var/lib/rancher/rke2/agent/etc/containerd/config.toml # 出力例 [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia'] [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia'.options] BinaryName = "/usr/local/nvidia/toolkit/nvidia-container-runtime" [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia-cdi'] [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia-cdi'.options] BinaryName = "/usr/local/nvidia/toolkit/nvidia-container-runtime.cdi" おわりに 本記事では、AirGap環境のRKE2クラスタに対して、ホストへのNVIDIA GPU Driverの導入と、HelmChartリソースによるNVIDIA GPU Operatorの導入を行いました。AirGap環境では、依存パッケージを漏れなく集めることと、イメージの参照先をすべて閉域内のレジストリに向けることが主なポイントです。 これで、GPUを使うAIアプリケーションをクラスタ上で動かす準備が整いました。次回はSUSE AI Factoryのインストール方法について解説したいと思います。 参考 About the NVIDIA GPU Operator Installing the NVIDIA GPU Operator Install NVIDIA GPU Operator in Air-Gapped Environments NVIDIA GPU Operator Release Notes NVIDIA GPU Operator Platform Support Time-Slicing GPUs in Kubernetes RKE2 Documentation – GPU Operators nvidia-graphics-drivers-580-server package in Ubuntu（Launchpad） ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post SUSE RancherでのGPUノード設定方法解説 〜AirGap環境へのNVIDIA GPU Driver・GPU Operator導入〜 first appeared on SIOS Tech Lab .

「自治体のためのクラウドコスト最適化」シリーズについて 自治体がガバメントクラウド上で業務システムを運用する場合、クラウド利用料の管理はオンプレミスとは性質の異なる実務になります。従来は、機器を調達した時点で費用がほぼ固定され、その後の管理は保守契約の範囲で済みました。クラウドは使った分だけ課金されるため、構成を変えれば費用も変わります。移行しただけでは費用は下がらず、稼働後に構成を見直し続けることで効果が出ます。 ところがこの見直し作業は、技術的な判断を伴うため日々の運用を担う事業者に委ねられがちです。結果として、自治体側に判断の材料が届かないまま請求額だけが確定していくことがあります。クラウド利用料は自治体の予算から支出され、住民や議会に説明する主体は自治体です。本シリーズは、 自治体が自らクラウド費用を把握し、事業者と協働して最適化を続けられる状態 を目標にしています。 ただしコスト最適化は、コンソールで数値を確認する日々の運用から、調達仕様書への反映、予算要求・決算の手続き、システム基盤そのものの設計まで、性質の異なる複数の作業で成り立っています。これらは担い手も検討のタイミングも異なるため、本シリーズでは領域ごとに記事を分けています。 # タイトル 扱う領域 自治体職員 ベンダー 情報政策 担当 財政担当 運用管理 補助者 ASP ① 定期レビューで回すコスト最適化の手順 日々の運用 ● ○ ● ○ ②-1 運用管理補助者との協働体制を調達仕様書に落とし込む 調達・契約 ● ○ ○ ○ ②-2 AI Agent でコスト分析を自動化する（公開予定） 運用の効率化 ● ○ ○ ③ 予算要求・執行・決算の実務（本記事） 予算・会計 ○ ● ④ 20業務の最適化設計と実践（公開予定） 基盤の設計 ○ ● ● 補足： ②-2、④は今後公開予定です。公開時にはこの表からリンクします。 ● は主な対象、 ○ は関連する範囲で参考になる読者です。 情報政策担当 ：情報システム部門でクラウド環境の運用を所管する職員 財政担当 ：予算要求・執行・決算の手続きを担当する職員 運用管理補助者 ：ガバメントクラウドの運用管理を自治体から受託する事業者 ASP ：業務システム（パッケージ）を提供し、その動作保証を担う事業者 どこから読むか ：情報政策を担当される方は①から、財政を担当される方は③から始めてください。運用管理補助者・ASP の方は④が中心になります。 本記事について シリーズ②-1では、GCASガイド「継続的運用経費最適化(FinOps)ガイド」において、クラウドサービスの利用実績の可視化、削減提案、翌事業年度の改善提案・目標設定等に取り組むこととされていることを紹介しました。これらを実現するためには、運用管理補助者・ASP、政策担当原課、情報システム部門、財政部門が各々の立場で役割を果たすことが必要になります。 そこで今回は、クラウドコストの予算管理等をテーマとし、特に、財政部門の皆さまがクラウド経費の予算査定・執行管理を行う際の実務的な視点で記載しています。 目次 1. はじめに ― 従量課金等のクラウドサービスの特徴に伴う運用の違い 1.1 クラウドサービス利用料の特徴 1.2 クラウドの特性を踏まえた新たな予算管理の考え方 1.3 コスト最適化への取組 2. 年度予算要求時のコスト見積もり 2.1 移行初年度の見積もり 2.2 2年目以降の見積もり 3. 年度途中のコスト変動への対応 3.1 AWS Budgets による予算設定・予算超過の防止 3.2 執行残発生時の扱い 4. まとめ Appendix 長期利用割引（リザーブドインスタンス・Savings Plans）の予算上の扱い 1. はじめに ― 従量課金等のクラウドサービスの特徴に伴う運用の違い 1.1 クラウドサービス利用料の特徴 自治体の予算制度は単年度が原則です。従来のオンプレミス方式（庁舎内又はデータセンターにサーバーを設置する方式）では、5年リースの契約時に年間費用が確定し、リース料を長期継続契約や債務負担行為により複数年にわたる経費の平準化と予算の見通しを確保してきました。 一方、クラウドサービスは初期投資不要/従量課金で利用できる特性を有するため、システム利用状況に合わせて無駄なく利用できる一方、予算の編成や執行等において、従来のオンプレミスとは異なる運用が必要になります。例えば、AWSのクラウドサービスの利用料には、次のような特徴があります。 従量課金 ：使った分だけ請求される仕組みであり、月ごとに金額が変動します。繁忙期（確定申告時期等）にはリソースを拡張し、閑散期には縮小することで無駄を抑制できます。 USD（米ドル）建て ：ガバメントクラウド（AWS）の利用料は米ドルで計算されるため、為替レートの変動が円換算後の支出に影響します。なお、為替を固定する契約方式も選択肢として存在します。 運用中のリソース最適化・コスト最適化が可能 ：オンプレミスでは契約更新時にしかコスト見直しができませんが、クラウドでは稼働中に随時リソースの追加・削減が可能です。 つまり、クラウドの予算管理では「予算要求時の見積もり精度」と「年度途中の予実管理」の双方が重要になります。 1.2 クラウドの特性を踏まえた新たな予算管理の考え方 また、オンプレミスの情報システムの構成をそのままクラウドに移行する「単純リフト」では、クラウドの特性を活かしきることができず、サーバーの規模が過大なまま稼働するなどにより、利用料がオンプレミス時代を上回るおそれがあります。デジタル庁による先行・検証事業等においても、単純移行ではコスト増となる事例が報告されています。 こうしたなか、財政部門としては、予算査定の際に「コスト最適化計画」の実行状況を確認することが有効となります。クラウドの費用対効果を発揮するには、移行後にコスト適正化（不要リソースの削減、サーバー規模の見直し等）を継続的に実施することが重要になります。デジタル庁が整備しガバメントクラウドに関する情報を提供しているGCASガイドにおいても、本番稼働後に継続的なコスト最適化へ取り組むことの重要性が示されています。 1.3 コスト最適化への取組 クラウドは本番稼働後がコスト最適化のスタート地点です。財政課としては、最適化の取組が継続的に行われているかを経年の予算査定や四半期報告の中で確認することが考えられます。従来、運用経費としてまとめられている経費の詳細な内訳、費目、区分が判然とせず、算出することも困難な状況にありました。しかし、クラウドサービスの特徴と、AWS Cost Explorer、AWS Budgets 等の管理ツールにより、リアルタイムで状況を可視化できます。毎月の従量課金の請求を踏まえることで、どのサービスを、どのように活用しているのか、関連する運用の人件費との切れ目はどうなっているのか、工数・人月・単価は適切かどうか、人件費のほかシステムやサービス利用料以外が過大になっていないかなどを精査できるようになります。 例えば、クラウド利用料だけを見ると「新規コストが発生した」ように見える場合であっても、オンプレミス時代には「見えにくい形」で発生していた「隠れたコスト」を含めた総保有コスト（TCO）で比較すると、クラウド移行によりシステム全体のコストが削減されているケースもあります。 （隠れたコストの例） データセンターの電気代・空調費（施設管理費の中に含まれていたもの） 職員がサーバー管理に費やしていた工数（人件費の中に含まれていたもの） 5年ごとのハードウェア更新費用（更新年度に一括計上されていたもの） 災害対策用のバックアップ設備投資 このように、コスト最適化の取組によりクラウドサービスに適した運用管理を実施していくためには、事業者（ASP/運用管理補助者）も含め、各部門が連携するスキームを確立して運用することが重要です。また、各部門の役割分担と報告ルート（情報システム部門→原課→財政課）を予め明確にしておくことで、PDCAサイクルに基づく継続的なコスト適正化が実現します。 また、例えば、情報システム専任部署を持たない小規模団体においては、ASP事業者からの月次コストレポートを受領することを基本とし、四半期ごとに財政担当が確認するという簡易な運用から始めることも方法のひとつです。この場合、ASP契約仕様書において、コストレポート（利用量・費用明細）の月次提出義務を含めておくことが考えられます。 なお、このコスト最適化には、予算を縮減することばかりが含まれるのではなく、より適切なサービスを利用するため、あるいは、より適した人材をアサインするために予算の枠内で割り当てを再分配したり、必要な経費等を増加させることも含まれる点にご留意ください。 （参考） 利用方式や環境によっては、AWS マネジメントコンソール（AWS Cost Explorer、AWS Budgets 等を含む）の閲覧権限が自治体職員に付与される場合があり、従来はASP（事業者）経由でしか確認できなかったコスト情報を、自治体職員が自ら確認できる事例も出ています。閲覧権限の付与を運用管理補助者に求める際の調達仕様書の記載例は、シリーズ②-1 の 3.1 で紹介しています。 以降、自治体の予算サイクル（予算要求→執行→決算）に沿って、クラウドコストの管理方法を具体的に解説します。 図: クラウドコストと自治体の予算サイクル（括弧内は本記事の対応章） 2. 年度予算要求時のコスト見積もり 原課又は情報システム担当から提出されるクラウド利用料の予算要求書を査定する際に、財政課が確認するとよいポイントを解説します。なお、ガバメントクラウドの利用形態は「共同利用方式」と「単独利用方式」に大別され、それぞれ見積もり精査のポイントが異なります。本記事では主に共同利用方式を念頭に記載しますが、単独利用方式の場合は、AWS アカウント内のリソースがすべて自団体の費用等となるため按分が不要となり、見積もりにおいて、共同利用方式と比較して考慮事項等が少ない特徴があります。 2.1 移行初年度の見積もり ガバメントクラウドへの移行初年度は、過去の実績データがないため、見積もりの難度が最も高い年度です。主に、 AWS Pricing Calculator を用いて概算を行います。現行システムの構成（サーバー台数、CPU/メモリ/ディスク等）を整理し、対応するAWSサービスにマッピングして試算します。また、デジタル庁がGCAS上で提供する利用料比較の仕組み（提供状況・利用方法はデジタル庁の案内をご確認ください）を活用し、人口規模や業務内容が類似する他団体の利用実績を参考値（メルクマール）とすることで、見積もりの妥当性を検証することも重要です。財政部門が予算査定を行う際は、これらの比較データの提示を求めることが有効です。 また、クラウドへの移行完了までの既存システム運用費が見落とされてしまうと、システム停止を余儀なくされてしまう可能性があります。このような移行過渡期に係る費用についても適切に計上されていることを確認してください。なお、クラウド移行に当たっては、テスト環境の稼働、一時的なスケールアップ、想定外のデータ転送等のコストの考慮も必要になります。提供する行政サービス等の停止等を防ぐためにも、初めてのシステムの移行は抜け漏れなく慎重に、かつ従量課金を加味してバッファを持つことが考えられます。そのため、類似する、あるいは先行する同規模の事例を参照した上で、初年度は特に余裕を持った予算を確保することを推奨します。 確認項目 主なチェックポイント 見積もり根拠 AWS Pricing Calculator 等のツールを使った試算結果が添付されているか スペック インスタンスサイズ（サーバー規模）が現行システムの実使用量に対し適正か。類似規模の他団体における実績値と大きく乖離していないか クラウド利用料・移行スケジュール ・何月からクラウド利用料が発生するか（月数 × 月額で積算されているか） ・テスト環境稼働から移行完了後年度末までの月数分が適切に計上されているか 移行作業費 データ移行、環境構築、テスト等に要する作業費用が適切に計上されているか 環境稼働 ・テスト環境の稼働時間が限定されているか（24時間稼働は不要） ・共同利用方式の場合、運用管理部分（監視・バックアップ等）及びネットワーク部分の費用が適切に按分されているか ・開発環境・テスト環境が移行計画に沿ったタイミングで縮退・終了される計画となっているか（稼働後も残存していないか） 並行稼働費 移行完了までの既存システム運用費が適切に計上されているか 為替考慮 為替変動と為替固定の双方の契約方式における費用や差異を比較しているか 査定のコツ : 初年度は「不確実性が高い」ことを前提に、予算を認める代わりに「四半期ごとの実績報告」を条件として付すことで、執行段階での管理を担保できます。 2.2 2年目以降の見積もり 2年目以降は、前年度の実績データが最も信頼できる見積もり根拠になります。 見積もり手順： 前年度の月別利用実績（USD）をAWSの請求データから取得します。 季節変動（確定申告時期の負荷増、年度末処理等）による増減を考慮します。 新規サービスの追加・既存サービスの廃止の影響を加味します。 前年度に実施したコスト最適化施策の通年効果（年度途中の実施分を12か月に拡張）を反映します。 為替レートを設定してJPYに換算します。 予見し難い環境変化への対応に要する経費として予備的な経費を上乗せします。なお、予算査定においては、予備的な経費分の予算については執行保留分とする運用も考えられます。いずれにせよ、予備的な経費の設定にあたっては根拠の明示が重要です。 （参考）計算例：前年度の月平均利用額が$4,200の場合、通年換算で$50,400。変動要因（+$5,100）と最適化効果（▲$4,800）を加味すると$50,700。レート160円/USDで換算すると約811万円。予備的な経費として仮に12%（97万円）を加えると、予算要求額は908万円となります（12%は計算のための仮の値です）。 長期利用割引（リザーブドインスタンス・Savings Plans）を適用している場合、または適用を予定している場合の予算上の扱いは、Appendix で補足しています。 確認項目 主なチェックポイント 前年度実績 月別実績データ（USD）が添付されているか。根拠のない増額要求になっていないか 変動要因 増額の場合：具体的な理由（利用者増、新機能追加等）が示されているか 最適化効果の反映 前年度の削減施策の効果が次年度見積もりに反映されているか（反映されていなければ過大） リスク予見・予備的な経費 過去1年間の実際の変動幅に対して上乗せ幅が過大でないか（2年目以降も初年度と同じ上乗せ幅のままになっていないか） 3. 年度途中のコスト変動への対応 情報システム担当または原課から四半期ごとに報告を受ける際、次の観点で確認します。 確認項目 主なチェックポイント 予算消化率 経過月数に対し、許容範囲であるかどうか 年度内の予算消化 予算内に収まる見通しかどうか 為替の影響 実績が予算レートを上回っている場合、予算の枠内に収まる見込みかどうか 最適化の取組 施策が実施されているか（「特になし」は要確認） 3.1 AWS Budgets による予算設定・予算超過の防止 GCASガイドの予実管理では、AWS Budgets に月次予算を設定することとされています。年間予算額（USD）を利用月数で除算して月次予算額を算出しつつ、季節変動を考慮し、繁忙月（確定申告時期の1〜3月等）は多めに、閑散月は少なめに配分されていることを確認してください。これらの設定を行うことで、予算超過が見込まれる場合に事前アラートにより早期検知と対策が可能になります。アラートの主な設定方法としては、①AWS Budgetsにより閾値を設定して予算上限超過を監視する、②AWS Cost Anomaly Detectionによりコスト急騰などの異常検知を行う、の2つが挙げられます。 アラートが発報された場合の原課の主な対応は、次のとおりです。 設定ミスや不要リソースの放置であれば即時是正 月末までと年度末までの累計見込みを算出し、意思決定権者に報告 予算超過が見込まれる場合に事前アラートの通知先に、財政課を含めておくことで、財政課側から対応を指示することが可能となり、早期の対策による予算超過の予防にも繋がります。 図: （参考）AWS Budgets と AWS Cost Anomaly Detection による予算超過・異常の検知 3.2 執行残発生時の扱い 従量課金では、利用が少なかった場合に執行残が発生します。発生要因には、次のようなケースがあります。 コスト最適化施策の成果（積極的な取組の結果） 想定より利用量が少なかった（利用者数が見込みを下回った等） 為替レートが有利に推移した（外部要因） 見積もり時の予備的な経費の設定が過大だった このうち、最適化の成果による執行残は、クラウドサービス及びFinOpsの活動の優れた成果になります。一方で、執行残が発生したことを理由に、翌年度予算を機械的に削減することにはリスクもあります。最適化の取組の再現性の検証、関連システムも含めた全体最適としての運用の確認等、次年度以降の変動事由の考慮等を踏まえる必要があります。そこで、最適化の効果が生じた翌年度（N＋1年度）は、効果が継続しているかを検証する期間とし、効果が定着したことを確認できた段階で、翌々年度（N＋2年度）の予算の見直しに反映するといった段階的な扱いも考えられます。政策目的に照らした適切なシステム運用等を目指しつつ、原課の意欲を最大限発揮することが可能な仕掛けで、FinOpsと効果検証を着実に進めることが重要です。 また、クラウドサービスの強みは、柔軟な機能拡張やログ分析基盤をスピーディに構築し、最新技術の短期間の試験運用等が可能である点です。これらは、住民サービスの向上、DXの加速化、セキュリティ強化にも直結するものであり、さらなる利便性と安心の好循環を生み出すことが期待されます。また、平時の運用管理やシステム/サービスを活用した執務の遂行について、更なる業務効率化に向け、最新のデジタル技術やAI等の活用を図ることも効果的です。 そのため、最適化の取組等により発生した執行残について、予算活用の短期・中期の運用サイクルとして、本来的な政策目的等を含め、原課・情報システム課・財政課その他の関係機関で認識合わせを行うことが重要です。その際、例えば、予算執行のルールの範囲内において、執行残をうまく活用しつつ、FinOpsの結果の定性化や最新技術の試用や実証実験等への活用を選択肢の一つとして検討することで、コスト最適化の取組を継続する動機付けにもなり得ると考えられます。 4. まとめ 以上、クラウドコストの予算管理をテーマとし、クラウド経費の予算査定・執行管理を行う際の実務的な視点についてご紹介いたしました。 繰り返しになりますが、クラウドは本番稼働後がコスト最適化のスタート地点です。クラウドサービス利用料の適正化によるコスト削減に努めつつ、柔軟な機能拡張やログ分析基盤をスピーディに構築し、最新技術の短期間の試験運用等を通じて、住民サービスの向上、DXの加速化、セキュリティ強化に取り組むことが期待されます。クラウドサービスの利用実績の可視化、削減提案、翌事業年度の改善提案・目標設定等のサイクルを効果的に実施することで、デジタル技術を使いこなし、効率的な行政運営と豊かで便利な社会を実現していただければと存じます。 より詳しく知りたい方へ 本記事で扱わなかった日々のコスト確認や調達仕様書への反映などは、シリーズの他の記事で解説しています。 やりたいこと 参照先 定期的なコスト確認の手順・チェックリストを知りたい シリーズ① 調達仕様書へのFinOps要件の反映方法を知りたい シリーズ②-1 生成 AI を使ったコスト確認の効率化を知りたい（公開予定） シリーズ②-2 運用管理補助者・ASPとして具体的に何をすべきか知りたい（公開予定） シリーズ④ Appendix 長期利用割引（リザーブドインスタンス・Savings Plans）の予算上の扱い AWSには、一定期間（1年又は3年）の利用を約束（コミット）することで割引を受けられる仕組みがあります。これは、自治体が複合機やコピー用紙を「年間契約」することで単価が下がるのと同じ考え方です。 通常利用（従量課金） ：毎月、使った分だけ定価で請求されます。 長期利用割引適用後 ：Savings Plans は「1時間あたりの利用金額（USD）」、リザーブドインスタンスは「インスタンスの種類と台数」を単位としてコミットし、コミット分には割引単価が適用されます。コミットを超えた利用分は通常の従量課金単価で請求されます。 購入・設定の流れ ガバメントクラウドでは、リザーブドインスタンス・Savings Plans のいずれも、自治体と合意した内容に基づいて運用管理補助者が購入・設定します。財政部門としては、購入の時期・期間・コミットの水準が予算と整合しているかを、情報システム担当とあらかじめ確認しておくことが考えられます。コミットは期間中の変更・取消が原則できないため、確実に利用する水準で設定することが重要です。購入時期の考え方は、シリーズ①の 2.2 で紹介しています。 自治体が過去の利用実績を基に、確実に利用する最低水準のコミット額を算出します。 デジタル庁に対して長期利用割引の適用を申請します。 デジタル庁が申請を取りまとめ、一括で割引を購入・適用します。 割引効果が自治体の月次利用料に反映されます。 ※ コミットは期間中の変更・取消が原則できないため、確実に利用する最低水準で設定することが重要です。申請手続きの詳細や最新の運用は、デジタル庁の案内をご確認ください。 免責事項 : 本記事の内容は情報提供を目的としたものであり、特定の環境や要件に対する推奨を保証するものではありません。実際の効果は個別の環境・構成により異なります。AWS サービスの料金は変更される場合がありますので、最新の料金情報は AWS 料金ページ をご確認ください。 ガバメントクラウドに関するご相談: ガバメントクラウドの利活用に関するご質問やご相談は、 AWS ガバメントクラウド相談窓口 までお問い合わせください。 筆者について Chisaki Noguchi 野口 智紗樹（Chisaki Noguchi）は、自治体向けの新規事業開発等担当です。中央省庁での勤務経験を活かし、政府の方針等を踏まえた中長期的な視点で、クラウドやAIを活用した行政課題・地域課題の解決、持続可能なサービスの構築等による豊かで便利な社会の実現に取り組んでいます。 Kazuki Fujimoto 藤本 一樹（Kazuki Fujimoto）は、パブリックセクターの自治体担当のソリューションアーキテクトです。自治体の基幹システムのクラウド移行やそれに伴うコスト最適化とモダナイゼーション、生成 AI の活用支援などをおこなっています。

はじめに こんにちは、ZOZOMO部FBZブロックの杉田です。普段は Fulfillment by ZOZO （以下、FBZ）が提供するAPIシステムを開発・運用しています。昨年からは、社内における開発者向けAI支援ツールの推進を担う専門チームも兼務しています。 FBZ APIは2017年にServerless Frameworkで構築を開始し、現在はAWS Lambda（以下、Lambda）の関数500本超、40個以上のスタックで稼働しています。サーバーレス自体の運用負荷は低い一方、9年間でツールの有償化やプラグインの保守停止、ランタイムのEOL、リソース上限といった「周辺環境の変化」への追従を迫られてきました。本記事では、こうした変化への追従における課題と、その解決に至る取り組みを紹介します。 目次 はじめに 目次 FBZ APIの構成とシステム規模 9年間で直面した3つの変化 1. 構成管理：Serverless Frameworkとプラグインの長期運用に伴う課題 2017年の選定背景：エコシステムと拡張性を重視 v1にとどまった5年間とプラグインによる拡張・負債化 2024年の有償化対応：移行コスト vs ライセンス費用 プラグインの整理と「外部依存」を抱え込む判断基準 2. ランタイムEOL：迫る期限と「手動検証」の限界 1回目（Python 3.6から3.9へ）：手動検証による3か月の苦闘 2回目（Python 3.9から3.13へ）：E2Eテストによる期間短縮と作業負荷の軽減 3. システム規模の拡大：アプリケーションの肥大化とデプロイ時間の長期化 CloudFormationのリソース上限 1時間を超えた直列デプロイ時間 変化に追従し続けるための「3つの仕組み」 1. 判断基準：デプロイ後の健全性を担保するE2Eテスト 判断基準として機能した理由 Karateで書いたE2Eテスト あらゆる変化を支える安全網としての効果 2. 可観測性と検知：変更後の影響・予兆を捉える監視 Datadogによる分散トレーシングとメトリクス監視 AWS Health EventのSlack連携による重要情報の早期検知 3. 基盤の最適化：スタック分割とデプロイの並列化 スタック分割と共有リソースの集約 デプロイ並列化によるリードタイム70％削減 まとめ FBZ APIの構成とシステム規模 FBZ APIは、2017年7月に開発を開始し、現在まで約9年間にわたってサーバーレスアーキテクチャを中心に稼働を続けているAPIシステムです。 現在の技術スタックと規模感は以下のとおりです。 実装言語 ：Python 3.13 主要コンポーネント ：AWS Lambda、Amazon API Gateway 規模 ：Lambda関数500本超、AWS CloudFormation（以下、CloudFormation）スタック40個以上 構成管理ツール ：Serverless Framework サービス構成やアーキテクチャ戦略の全体像は、以下の記事でも詳しく紹介しています。 techblog.zozo.com 構成管理に採用しているServerless Frameworkは、サーバーレスアプリケーションのコードとインフラを宣言的に一元管理できるフレームワークです。 www.serverless.com シンプルな操作でコードのパッケージングからリソース定義の生成、デプロイまでを自動化できます。複雑なクラウド構成を意識せずにスタック単位で容易に管理できる点や、コミュニティ製の豊富なプラグインにより柔軟に機能を拡張できる点が大きな特徴です。 こうした管理の容易さと高い拡張性に支えられ、インフラの運用保守コストは9年が経過した現在も低く抑えられています。しかし、依存していたプラグインの保守停止やフレームワークのバージョンアップなど、エコシステムの発展に伴う変化への追従が運用の現場で大きな課題となっていきました。 9年間で直面した3つの変化 9年間の運用を続ける中で、大きく分けて次の3つの変化に直面しました。 構成管理（Serverless Frameworkとプラグイン） ：長期利用に伴う依存プラグインの負債化や、フレームワークv4の有償化 ランタイム（LambdaのPythonランタイムサポート終了） ：定期的に訪れるサポート終了への追従と、初回移行における検証の長期化（約3か月） システム規模（アプリケーションの肥大化） ：機能追加に伴うCloudFormationのリソース上限への到達や、デプロイ時間の長期化（1時間超） 1と2はライセンス体系や外部コミュニティ、AWSのサポート方針といった「外部環境の変化」であり、3はプロダクトの成長に伴う「内部要因の変化」です。それぞれの変化において、どのような課題が生じたのかを振り返ります。 1. 構成管理：Serverless Frameworkとプラグインの長期運用に伴う課題 2017年の選定背景：エコシステムと拡張性を重視 2017年の開発初期、サーバーレスの構成管理ツールの選択肢は現在とは大きく異なっていました。現在広く使われているAWS CDK（2019年に一般提供を開始）はまだ登場していません。チームが検証したのは、Serverless Framework、AWS Serverless Application Model（以下、AWS SAM）、CloudFormationの3つでした。 3ツールを比較検討した結果は以下のとおりです。 観点 CloudFormation AWS SAM Serverless Framework 記述量 ×：配線からパッケージングまですべて自前で記述し、関数が増えるほど肥大化する ○：CloudFormationの拡張でサーバーレスの定義が簡潔 ○：関数とイベント、リソースを短いYAMLで定義できる 成熟度 ○：AWS純正で実績が十分 ×：登場直後で未成熟 ○：当時のデファクトスタンダードで利用事例が豊富 拡張性 △：汎用ゆえに不足はすべて手作り ×：プラグインのような拡張手段がない ○：プラグインをはじめエコシステムが充実 必要な権限 ○：CloudFormationの権限のみ ○：CloudFormation準拠 △：admin相当の権限が必要 結論 見送り 見送り 採用 当時の成熟度の差は、各ツールのリリース時期や普及状況を比較すると明確でした。AWS SAMの本体が一般提供されたのは2018年4月で、CLIの一般提供は2020年7月です。一方のServerless Frameworkは、2016年10月のv1.0リリース時点でGitHubスターが11,000を超え、2018年には25,000を超えていました 1 。 一方で課題となったのが必要な権限です。Serverless Frameworkはadmin相当の権限を要求するため、当初の開発者権限のままではリソースを正常に作成できませんでした。この点は社内で調整し、必要な権限を付与してもらうことで解決しました。 比較の結果、AWS純正の2ツールよりも成熟度や機能の豊富さにメリットを感じ、Serverless Frameworkの採用に至りました。 v1にとどまった5年間とプラグインによる拡張・負債化 採用翌年の2018年にv1.27へ更新して以降、2023年まで約5年間にわたりv1系のマイナー更新にとどまりました。その間、開発元からはv2.0やv3.0がリリースされていました。 以下の図は、Serverless Framework本体のメジャーリリースと、FBZ APIにおける追従の歩みをまとめた年表です。 図が示すように、世の中でv2やv3が登場する間もFBZ APIでは約5年間v1系を維持し、2023年にv2をスキップしてv3へ移行する形をとりました。 長期間v1系にとどまったのは、当時の機能開発に大きな支障が生じておらず、フレームワーク自体の更新優先度を上げにくかったためです。 一方で、システムの成長に伴い、標準機能だけでは要件の実現が難しかったり、余計な実装工数がかかったりする場面が増えていきました。そこで活用したのが、Serverless Frameworkの強力なプラグインエコシステムです。公開プラグインの導入にとどまらず、要件に応じたプラグインの自作や、既存プラグインへのプルリクエストによる機能追加・修正を通じて課題を解決していきました。 Serverless Frameworkでは、以下のように設定ファイルの plugins に使いたいプラグインを指定するだけで、本体に手を加えることなくデプロイの各工程へ独自の処理を差し込めます。 service : fbz-api provider : name : aws runtime : python3.13 plugins : - serverless-plugin-split-stacks - serverless-plugin-datadog - my-original-plugin # 自作プラグインも指定可能 ビルドやパッケージング、デプロイといった一連のライフサイクルに対してきめ細かくフックでき、CloudFormationテンプレートの直接操作や設定の自動注入が可能です。インフラからアプリケーションの挙動まで柔軟に介入できる、非常に高い拡張性を備えています。その手軽さと強力さから、Python依存関係の同梱やスタック自動分割、Datadog連携といった要件をプラグインで次々と実現し、累計で12種ものプラグインを活用するようになりました。 手軽に拡張できる反面、本体のバージョンアップを止めたままプラグインに依存し続けたことで「負債化」が進みました。導入したプラグインの開発が停止したことで、チーム内でフォークして保守せざるを得ないプラグインが増加したのです。例えばAWS Batch連携プラグインはフォークして不具合を修正しながら保守し、その他のプラグインでも独自修正を加えたフォーク版を使い続けました。 さらに2023年、利用していた主要プラグインがv1系を非推奨としたことで、本体を動かせない事態に直面しました。これを契機に、v2をスキップしてv3への移行を決断しました。 2024年の有償化対応：移行コスト vs ライセンス費用 v3への移行からわずか7か月後の2023年10月、開発元から一定規模を超える組織でのv4商用利用を有償化する方針が 公式ブログ で発表されました。v3のセキュリティ修正を含む保守期限は2024年末までと定められ、2024年6月にはv4.0がリリースされました。 私たちは約1年強の猶予の中で、次の方針決定を迫られました。 他ツールへ移行 ライセンス契約して継続 やること 40個以上のスタックとLambda500本超のインフラ定義をCDKなどで書き直す コード資産はそのまま活かし、バージョンアップのみ コスト 数か月の移行工数と全APIの再検証。その間の機能開発は停滞 利用状況に応じた一定のライセンス費用が発生。移行工数はほぼゼロ リスク 段階移行に伴うリグレッションの検知が難しい ベンダーの価格やプランの改定に影響される 判断 見送り 採用 比較検討の結果、私たちはライセンス契約を結んでServerless Frameworkを継続利用する判断を下しました。これは、Serverless Frameworkやプラグインのエコシステムに深く依存していたことによる移行コストの膨大さを踏まえた判断です。 他ツールへ書き直す場合、単にインフラを再定義するだけでなく、プラグインが担ってきた独自のデプロイ処理やスタック分割などをゼロから再設計・再実装する必要があります。さらに、移行作業に伴う数か月の機能開発の停滞や、全APIの再検証に伴うリグレッションリスクも無視できません。これらの移行に伴うコストやリスクを考慮すると、一定のライセンス費用を投じて継続するほうが合理的であると判断しました。 なお、この判断はFBZの既存資産と当時の料金体系を前提にしたものです。FBZとは別の新規プロダクトではゼロベースで構成管理ツールを選定しなおしました。実際に、開発言語との統一やきめ細やかなIAM制御、将来性を評価してAWS CDK（Go）を採用しています。ツール選定は過去の実績にとらわれず、プロダクトの状況に合わせて都度行うべき意思決定だと考えています。 AWS CDKを使った新規プロダクトの詳細は以下の記事をご覧ください。 techblog.zozo.com プラグインの整理と「外部依存」を抱え込む判断基準 v4の利用継続を決めた後、私たちは長年抱え込んできたプラグインの整理に着手しました。12種にのぼっていたプラグインは、現在6種まで削減できています。長年フォークして自前保守を続けていた2つのプラグインも、本体機能の充実や代替手段への移行によって役目を終えました。 プラグインを導入すれば、必要な機能を迅速に実現できる大きなメリットがあります。一方で、本体のバージョンアップへの追従や、メンテナンス停止時にフォークして自前で保守を継続するといった責任も伴います。外部のプラグインを採用する際は、更新が止まった場合でも自チームで保守を引き受けて使い続ける覚悟があるかを、あらかじめ見据えておく重要性を実感しました。この経験を経て、手軽さだけで安易に追加せず、長期的な運用負荷も考慮して厳選する姿勢がチームに定着しました。 2. ランタイムEOL：迫る期限と「手動検証」の限界 フレームワークとプラグインの変化は放置しても、システムは当面動き続けます。実際、FBZはv1のまま5年間動いていました。しかし、LambdaランタイムのEOL（サポート終了・非推奨化）にはこの猶予がありません。Lambdaは非推奨日にセキュリティ更新と技術サポートを終了します。その後、原則として30日後から関数の作成がブロックされ、60日後からは関数の更新もブロックされます（段階的な制限の詳細は Lambdaランタイムのドキュメント を参照してください）。 Lambda側のサポート終了時期と、FBZが経験したランタイム移行のタイムラインは次のとおりです。 1回目（Python 3.6から3.9へ）：手動検証による3か月の苦闘 2022年にPython 3.6から3.9へ移行しました。500本を超えるLambda関数を抱える環境での初めてのランタイム移行です。当時はユニットテストこそ一定のカバレッジを確保して整備されていたものの、デプロイ後のAPIの挙動をE2Eで自動テストする環境はありませんでした。結果として、実環境での動作の健全性を確かめる手段は手動検証に頼らざるを得ませんでした。 スタックごとに依存ライブラリの互換性確認とAPIの手動検証を重ね、慎重に本番反映を進めました。最終的に全スタックの移行が完了したのはLambdaの非推奨日の直前で、着手から完了まで約3か月を要しました。 「変更後に壊れていないことをどう確かめるか」という確認コストが最大のボトルネックでした。膨大な手作業は作業者の大きな負荷となり、作業量の多さから人為的ミスのリスクも高まっていました。この移行作業を通じて手動検証の限界を痛感したことが、直後の2022年8月にE2Eテスト基盤を整備する大きな契機となりました。 2回目（Python 3.9から3.13へ）：E2Eテストによる期間短縮と作業負荷の軽減 1回目の反省からE2Eテストを整備したことで、2025年に迎えたPython 3.9から3.13への移行は大きく様相が変わりました。判断基準を自動実行されるE2Eテストに委ねることができたことで、開発チームは互換性の調査やコード修正そのものに集中し、テストの成功を確認しながら機械的に作業を進められるようになったのです。 項目 1回目（2022年） 2回目（2025年） 移行内容 Python 3.6から3.9 Python 3.9から3.13 確認手段 手動検証 E2Eテストの自動実行 期間 約3か月（4月着手、7月完了） 約4週間（9月着手、10月に主要スタック完了） 互換性の洗い出しやコードの修正といった作業自体は、2回目の移行作業でも同様にありました。しかし、修正後に既存の機能が壊れていないことを確かめる作業をテストに任せられたことで、主要スタックの移行期間は約3か月から約4週間へと大幅に短縮されました。手作業による過度な負荷や人為的ミスのリスクを抑え、安全かつ迅速に移行を完遂できました。 3. システム規模の拡大：アプリケーションの肥大化とデプロイ時間の長期化 外部環境の変化に起因していたここまでの2つとは異なり、3つ目の変化は継続的な機能追加によってもたらされた内部要因による課題です。 CloudFormationのリソース上限 最初に直面した課題は、CloudFormationで定められている単一スタックあたりのリソース上限でした。Serverless Frameworkは、定義したリソース一式を1つのCloudFormationスタックとして管理します。Lambda関数を1本追加すると、関数本体だけでなくCloudWatch Logsのロググループやバージョン、API Gatewayの設定といった関連リソースも同時に生成されます。日々の機能追加に伴ってリソースが急増し、開発開始から8か月目の2018年2月にはAPIスタックが当時の上限であった200リソース（ 現在のクォータ は500）に早くも到達しました。 1時間を超えた直列デプロイ時間 スタックを直列でデプロイしていた頃、1回のデプロイは1時間以上かかりました。日常的な動作確認だけでなく、障害時の切り戻しにも同等の時間を要していました。デプロイ時間は障害からの復旧速度にも大きく影響します。切り戻しが遅れるほど障害の影響も長引いてしまうため、可用性の面で大きな課題となっていました。 変化に追従し続けるための「3つの仕組み」 これらの変化に共通して立ちはだかったのは、「変更後にシステムが正常に動作しているかをいかに効率的・確実に担保するか（確認コスト）」と「肥大化するアプリケーション全体のデプロイ速度」でした。 これらを解消し、長期にわたって安全かつ迅速に変化へ追従できるように整備したのが、以下の3つの仕組みです。 1. 判断基準：デプロイ後の健全性を担保するE2Eテスト 前述した1回目のランタイム移行で痛感した手動検証の限界を打破するため、2022年8月に導入したのがE2Eテストです。デプロイ後の環境のAPIを外から呼び出し、変更後も既存の挙動が保たれているか自動で確かめる回帰テストです。 これにより、デプロイ後の判断基準が明確になりました。デプロイパイプラインの最終工程にE2Eテストを組み込み、テストが全件成功した場合はそのままリリースを進めます。1件でも失敗した場合は原因を調査し、追加の修正や必要に応じた切り戻しを行うという運用ルールです。 判断基準として機能した理由 E2Eテストが追従の判断基準として有効に機能した理由は、主に次の3点にあります。 内部実装に依存しない検証 ：デプロイ後の環境に対して外部からHTTPリクエストを送信し、レスポンスの整合性のみを検証する。内部のランタイムやフレームワークを更新しても、テストシナリオ自体を書き直す必要がない。 実環境での実行 ：ローカル環境のテストを通過しても、ビルドやパッケージング、プラグインの挙動といった差分はデプロイして初めて顕在化することが多い。実環境でテストを実行することで、インフラ設定を含めたシステム全体の正常性を包括的に検証できる。 検証手順の統一 ：「変更を加えてデプロイし、テストを実行する」という一連の手順は、ランタイム更新、フレームワーク移行、プラグイン変更のいずれであっても共通。変化の種類ごとに確認手順をゼロから検討し直す必要がない。 Karateで書いたE2Eテスト E2Eテストには、APIテスト自動化フレームワークの Karate を採用しています。KarateはGherkin記法（Given / When / Then）をベースにしたテストフレームワークです。プログラミング言語による記述が不要で、自然言語に近いシナリオファイル単体でリクエスト送信からJSON検証までを直感的に記述できます。 FBZ APIでは、Karateの以下の特徴を活用してE2Eテストを運用しています。 直感的なJSON検証 ： match 構文により、レスポンスの完全一致や部分一致を簡潔に検証できる。 #uuid や #string といったマッチャーにより、実行ごとに値が変わる項目も型やパターンで柔軟に検証できる。 複数APIをつなぐシナリオテスト ：直前のAPIレスポンスから値（注文IDなど）を抽出し、後続リクエストへ引き渡すことで、カート作成から注文完了までの一連の業務フローをつなげて検証できる。 設定切り替えによる再利用性 ：ベースURLやテストデータを設定ファイルで切り替えることで、まったく同じシナリオを開発環境と検証環境の双方で実行できる。 以下は、説明用に単純化した在庫確保APIのシナリオです。 Feature: 在庫確保 API Background: * url baseUrl Scenario: 在庫を確保できる Given path '/v1/stocks/reserve' And request { itemCode: '#(itemCode)', quantity: 2 } When method post Then status 200 And match response == { reservationId: '#uuid', status: 'RESERVED', quantity: 2, expiresAt: '#string' } * def reservationId = response.reservationId reservationId は実行のたびに変わるため、値の代わりに #uuid というマッチャーで検証しています。また、 itemCode は環境ごとの変数として定義し、同じシナリオを開発環境と検証環境で共通して利用しています。内部の実装言語やフレームワークをどのように入れ替えても、このシナリオファイルは1行も変更する必要がありません。 あらゆる変化を支える安全網としての効果 前述したPython 3.13への移行だけでなく、2024年12月に実施したServerless Framework v4への移行でもE2Eテストは威力を発揮しました。テストの全通過を確認しながら進めることで、全スタックの移行をわずか1か月で完了させています。プラグインの廃止や入れ替え時にも、このテスト基盤が共通の安全網として機能しています。 さらに、この効果はフレームワークやランタイムの移行といった大規模なイベントに限りません。日常の機能改修や仕様変更においても、デプロイ後に既存APIへの影響を自動で検証できるため、手動による回帰テストの負担を大きく軽減できています。変化の種類や規模を問わず、システム全体の健全性をすばやく確かめられる安全網が整ったことで、チーム全体が安心してリリースを重ねられるようになりました。 2. 可観測性と検知：変更後の影響・予兆を捉える監視 E2Eテストが「デプロイ直後の外側からの振る舞い」を保証するのに対し、開発環境での調査から本番環境における健全性の担保までを担っているのが可観測性の仕組みです。 Datadogによる分散トレーシングとメトリクス監視 FBZ APIでは、現役プラグインの1つである serverless-plugin-datadog を通じて、全Lambda関数にDatadog Lambda Extensionを導入しています。開発環境と本番環境の双方で利用しており、 serverless.yml の設定をわずかに追加するだけで、以下の可観測性を確保しています。 分散トレーシング（APM） ：API Gatewayから後続のLambda、外部サービス呼び出しまでのエンドツーエンドのトレースを可視化 リアルタイムメトリクス ：呼び出し回数、エラーレート、実行時間、メモリ使用率、コールドスタートの発生頻度などを常時監視 ログの一元管理 ：CloudWatch Logsを経由したログ集約とトレースIDとの自動紐付け ランタイムやフレームワークの更新時、事前のテストだけでは見落としがちなレイテンシ悪化や特定条件下のエラーが発生する可能性は残ります。開発環境での事前検証から本番リリース後のトラフィック監視まで、Datadogのダッシュボードやモニターによって即座に異常を検知し、迅速に対処できるセーフティネットとなっています。 Datadogを用いたサーバーレス環境の監視設計や導入の詳細は、以下の記事でも紹介しています。 techblog.zozo.com AWS Health EventのSlack連携による重要情報の早期検知 また、ランタイムEOLへの追従が必要なのは、自分たちが書いたPythonの関数だけではありません。プラグインが生成するNode.jsなどの補助的なLambda関数も、同様にサポート終了を迎えます。 こうしたランタイムのEOL予告はもちろん、利用しているAWSサービスの計画メンテナンスや障害、セキュリティ更新といった重要通知を見逃さない仕組みも欠かせません。そこで私たちは、AWS Health EventをSlackへ連携して通知を受け取れるようにしています。 能動的に確認しなければ見落としやすい事前通知をSlackへ集約することで、EOLや基盤の変更予告をいち早くキャッチできます。これにより、突発的な対応に追われることなく、計画的なタスク化と十分な検証期間の確保が可能になっています。 3. 基盤の最適化：スタック分割とデプロイの並列化 アプリケーションの肥大化とデプロイ遅延に対しては、アーキテクチャの分割とデプロイパイプラインの高速化で対処しました。 スタック分割と共有リソースの集約 CloudFormationのリソース上限には、3つのアプローチを組み合わせました。 ドメインや処理形態に応じた分割 ：商品や注文といったビジネスドメインに加え、APIやバッチといった処理の種類ごとにスタックを分割 共有リソースの集約 ：共通のDynamoDBテーブルやS3バケット、共有Layer（依存ライブラリ）などを専用スタックへ集約し、各機能スタックから参照する形に整理 nested stackの活用 ：単一スタックで上限に近づく場合は、プラグイン（ serverless-plugin-split-stacks ）を用いて子スタックへ自動分割 これらの結果、現在は40個以上のスタックに分割して安定運用できています。 デプロイ並列化によるリードタイム70％削減 1時間14分かかっていた直列デプロイには、ビルドの並列化とデプロイオプションの見直しで対処しました。 ビルドの並列化 ：CodeBuildのバッチビルド（ビルドグラフ）でタスクの依存関係を定義し、依存のないスタックは並列に更新 変更セットの省略 ：direct deploymentsの有効化で、CloudFormationの変更セット作成を省略して直接反映 パッケージ処理の削減 ：時間のかかっていたdevDependenciesの除外処理のスキップで、パッケージ作成にかかる時間を短縮 その結果、1時間14分かかっていた直列デプロイが24分になり、約70％の時間を短縮できました。詳細は以下の記事にまとめています。 techblog.zozo.com まとめ 本記事では、開発から9年が経過したFBZ APIを例に、サーバーレス基盤の周辺で起きる変化への追従を紹介しました。 変化を通じて得た教訓は大きく3つあります。 1つ目は、 構成管理ツールやプラグインの選定では、自前保守や移行のしやすさを見極めること です。ライセンス変更やメンテナンス停止はいつでも起こり得ます。「便利だから」と安易に導入せず、自前での保守性や移行のしやすさを見極めたうえで採用を判断することが大切だと実感しました。 2つ目は、 マネージドサービスであってもランタイムのEOLに備え、回帰テストを自動化しておくこと です。マネージドサービスであってもEOLは避けられず、手動確認による消耗は大きな負担です。回帰テストを自動化し、いつでも安全かつ迅速に検証できる仕組みを整えておくことが欠かせません。 3つ目は、 システム規模の拡大を見越して、スタック分割やビルド並列化によりデプロイの俊敏性を維持すること です。機能追加に伴ってデプロイが重くなると、日々の開発だけでなく障害からの復旧速度も低下します。スタック分割やビルド並列化で先手を打ち、デプロイの俊敏性を維持しておくことが重要です。 個人的には、これまでの開発や運用の中で特に苦労したことの1つが、こうした周辺環境の変化への追従でした。しかし、サーバーレス本来のインフラ管理の少なさを活かし、E2Eテストや可観測性といった「追従のための仕組み」へリソースを投資できたことが、長期運用を支える大きな力になりました。技術トレンドやツールの提供条件は常に変わり続けます。これまでの構成を前提としすぎず、状況に合わせて柔軟に構成や仕組みを見直し続けることが大切だと感じています。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com Serverless公式ブログの「 Releasing Serverless Framework V.1 & Fundraising 」（2016年10月）と「 The Serverless Framework wins Best Microservices API at the API Awards! 」（2018年9月）に記載のスター数です。 ↩