大規模オンプレ × 生成AI/SaaS の引き継ぎ・再構築に必要な知識体系

はじめに

100台規模の物理サーバ、数百台の仮想マシン、そして千台級のコンテナ群を安全に引き継いで再構築するには、まずCMDBとトポロジ、BoMによって資産と依存関係を完全に把握し、Golden ImageとIaC、事前ベンチマークを組み合わせて仮想化やOS移行の互換性と性能を検証することが欠かせない。続いて、監視ノイズの低減やRunbookの整備、自動修復の導入といったSRE運用の標準化を進め、MIGや電力・熱・DCレイアウトを含むH100級GPUの運用論を確立する。さらに、ポリシー設計と監査対応、変更管理を通じてセキュリティ/ISMSと証跡化を徹底し、RPO/RTOに基づくDR/BCPとDC移転をプレ演習と併せて設計する。これらすべてをコード化と証跡化で一貫させることが成功の鍵である。

目次

目次の読み方

本稿は、最初に「目的と前提」を提示し、続いて資産把握と依存関係の可視化（フェーズ0）から、仮想化/ストレージ設計（フェーズ1）、Linuxモダナイゼーション（フェーズ2）、GPU/H100運用（フェーズ3）、監視・インシデント運用（フェーズ4）、IaC/CIによる変更管理（フェーズ5）、セキュリティ/ISMSと証跡化（フェーズ6）、DR/BCPとDC移転（フェーズ7）へと進む構成になっている。最後に、現場で陥りがちなアンチパターンと、設計チェックの最終確認、さらにスニペット集を示す。

フェーズ0：資産把握と依存関係の「可視化・正規化」

フェーズ1：仮想化/ストレージ設計（VMware, vSAN, Network）

フェーズ2：Linuxモダナイゼーション（CentOS7→RHEL8/Rocky8）

フェーズ3：GPU/H100クラスの運用論（MIG/電力/熱/監視）

フェーズ4：監視・インシデント運用（24/365, ノイズ低減, 自動化）

フェーズ5：IaC/CIでの変更管理（Plan/Apply分離, Policy as Code）

フェーズ6：セキュリティ/ISMSと証跡化（運用を“証明可能”に）

フェーズ7：DR/BCP と DC移転設計（ゲームデイとカットオーバ）

逆張りリスト：ありがちなアンチパターン

付録：設計チェックリスト & スニペット集

1. 目的と前提

本稿の対象は、オンプレミスの大規模インフラ上で生成AIやSaaSを運用する企業において、既存環境の引き継ぎから再構築までを担うアーキテクトおよびPLである。規模感としては、物理は10^2オーダー、仮想は10^2〜10^3オーダー、コンテナは10^3オーダーを想定する。目標は、可用性、性能、コスト、コンプライアンスの最適点を見極め、それをコード化と証跡化によって持続的に担保することに置く。

2. フェーズ0：資産把握と依存関係の「可視化・正規化」

まずは後工程の失敗リスクをあぶり出し、可視化して潰すことから始める。サーバ、VM、コンテナ、ネットワーク（VLAN/VRF/L3/L4）、ストレージ、バックアップ、監視、ジョブ、証明書、契約情報を単一スキーマで棚卸し、CMDBとBoMを整える。同時に、NetFlowやsFlow、SPAN、アプリケーションログを活用してサービス依存のグラフを機械的に抽出し、人間の暗黙知への依存を極小化する。移行順序はビジネス影響と技術リスクの二軸で四象限に整理し、GPUやDB、ネットワーク境界、L7ゲートウェイのような高リスク領域は最後に、ステートレスな領域は先行で進めるのが定石である。注意点として、証明書の期限やEoL/EoS、ライセンス、外部SaaS連携（IdPやCASBなど）は後から顕在化しやすい“地雷”であるため、最初に洗い出しておくべきだ。BoMには型番やファームウェア、サポート窓口まで含めておくと復旧速度が確実に上がる。

3. フェーズ1：仮想化/ストレージ設計（VMware, vSAN, Network）

VMware環境では、ホスト単位のvSwitchではなく、集中管理可能なvDSでセキュリティやテンプレートを一元化するのが基本である。EVCやDRS、HA、Admission Controlはローリングアップグレードを前提に設計し、GPUの扱いはPCIeパススルー、vGPU、SR-IOVの選択肢を運用要件と性能要件で使い分ける。vSANについては、FTTやFTM、QoSをワークロード単位で分離し、メンテナンス時のresyncストームを避けるための運用ルールを整備しつつ、キャパシティはN+2で余裕を確保しておくのが望ましい。vSphereはTerraformでIaC化し、テンプレートやネットワーク、ストレージの定義を再現可能に保つ。

provider "vsphere" {
  user           = var.vsphere_user
  password       = var.vsphere_password
  vsphere_server = var.vsphere_server
  allow_unverified_ssl = true
}

data "vsphere_datacenter" "dc" { name = var.dc }
data "vsphere_datastore"  "ds" { name = var.datastore }
data "vsphere_compute_cluster" "cluster" { name = var.cluster }
data "vsphere_network" "pg" { name = var.portgroup }

resource "vsphere_virtual_machine" "app" {
  count            = var.vm_count
  name             = format("%s-%02d", var.vm_name, count.index + 1)
  resource_pool_id = data.vsphere_compute_cluster.cluster.resource_pool_id
  datastore_id     = data.vsphere_datastore.ds.id

  num_cpus = var.cpu
  memory   = var.mem_mb
  guest_id = "rhel8_64Guest"

  network_interface {
    network_id = data.vsphere_network.pg.id
  }

  disk {
    label = "disk0"
    size  = var.disk_gb
  }

  clone {
    template_uuid = var.template_uuid
    customize {
      linux_options { host_name = format("%s-%02d", var.vm_name, count.index + 1) }
      network_interface { ipv4_address = var.base_ip + count.index, ipv4_netmask = var.netmask }
      ipv4_gateway = var.gateway
    }
  }
}

4. フェーズ2：Linuxモダナイゼーション（CentOS7→RHEL8/Rocky8）

CentOS7のEOS対応では、RHEL8またはRockyLinux8への移行が主流となる。systemdの機能強化、yumからdnfへの移行、ifcfgからnmcliへの移行、iptablesからnftablesへの切り替え、そしてchronyのデフォルト化など、管理の前提が変わる点を押さえておく必要がある。SELinuxはPermissiveで逃げるのではなく、CIS準拠と監査適合の観点からEnforcingを前提とするのが正攻法だ。GPU環境ではカーネル、ドライバ、ランタイム（CUDA/NCCL/ドライバ）の互換性マトリクスを先に確定し、Golden Image化した上で段階ロールアウトする。以下のPackerとAnsibleの例は、そのためのベースライン整備に使える。

# packer.pkr.hcl（vsphere-iso 例）
source "vsphere-iso" "rhel8" {
  vcenter_server      = var.vcenter
  username            = var.user
  password            = var.pass
  cluster             = var.cluster
  datastore           = var.datastore
  vm_name             = "golden-rhel8"
  guest_os_type       = "rhel8_64Guest"
  iso_paths           = [var.rhel8_iso]
  ssh_username        = "packer"
  ssh_password        = var.ssh_pass
}

build {
  sources = ["source.vsphere-iso.rhel8"]
  provisioner "shell" { inline = [
    "sudo dnf -y update",
    "sudo dnf -y install epel-release",
    # NVIDIA/CUDA は環境に合わせてレポジトリとバージョン固定
  ]}
}

# ansible: baseline.yml（CIS 抜粋・例示）
- hosts: all
  become: yes
  tasks:
    - name: Ensure SELinux enforcing
      ansible.posix.seboolean:
        name: selinuxuser_execheap
        state: no
      ignore_errors: yes

    - name: Enforce SELinux mode
      lineinfile:
        path: /etc/selinux/config
        regexp: '^SELINUX='
        line: 'SELINUX=enforcing'

    - name: Install baseline packages
      dnf:
        name:
          - chrony
          - firewalld
          - tuned
        state: present

    - name: Enable services
      systemd:
        name: "{{ item }}"
        enabled: yes
        state: started
      loop: [chronyd, firewalld, tuned]

移行に先立ってfioでvSANとNFSの差分を測り、I/Oの落とし穴を事前に潰しておくと安全である。

#fio: randrw, 深いキューで vSAN/NFS の差分を可視化
fio --name=vsan_test --rw=randrw --bs=4k --iodepth=64 --numjobs=4 --size=8G --runtime=120 --time_based

5. フェーズ3：GPU/H100クラスの運用論（MIG/電力/熱/監視）

生成AIに適した基盤では、GPUの設計と運用が最重要の検討事項になる。電力や熱、ラックの搭載密度はPDUの相バランスやコンセント計画、吸排気の向き、冷却冗長性まで含めて最初に検討する。NVLinkの有無、PCIeスロットやNUMA、CPUアフィニティといったトポロジの整合も、スケール時の性能に直結する。仮想化はパススルー、vGPU、SR-IOVの選択をジョブ特性とSLAで決め、MIGの切り方もジョブの粒度と隔離要件から設計する。ドライバ、CUDA、cuDNN、NCCLはバージョンを固定し、段階的にロールアウトする。運用時にはDCGMやpynvmlでメトリクスを取得し、ECCエラーや温度、クロックの異常はジョブ側に即時返報して根因を見失わない設計にする。以下にMIGと監視の導入例を示す。

# MIG を有効化（GPU 0 の例 / プロファイルは環境に応じて）
sudo nvidia-smi -i 0 -mig 1
# インスタンス作成（プロファイルIDはGPU/容量で異なるため設計値を使用）
sudo nvidia-smi mig -i 0 -cgi <config-id> -C

# DCGM（データセンター GPU マネジメント）で健全性チェック
dcgmi discovery -l
dcgmi health -t 1  # quick

# Python + pynvml でメトリクス取得（監視連携用の雛形）
from pynvml import *
nvmlInit()
n = nvmlDeviceGetCount()
for i in range(n):
    h = nvmlDeviceGetHandleByIndex(i)
    name = nvmlDeviceGetName(h).decode()
    mem = nvmlDeviceGetMemoryInfo(h)
    temp = nvmlDeviceGetTemperature(h, NVML_TEMPERATURE_GPU)
    util = nvmlDeviceGetUtilizationRates(h).gpu
    print(i, name, mem.used//(1024**2), "MiB", temp, "C", util, "%")
nvmlShutdown()

ノイジーネイバーの影響を避けるため、MIGやネームスペース、マウント制御を用いたジョブ隔離は運用の基本と考えるべきだ。

6. フェーズ4：監視・インシデント運用（24/365, ノイズ低減, 自動化）

24時間365日の運用では、単一シグナルに頼らず、ネットワークのSNMPやNetFlow、ホスト/アプリのエージェント監視、各種ログを相関させたルールで判断することが重要になる。たとえば、ホストがCRITICALでNetFlowもDOWNならリンク断の可能性が高いが、ホストがCRITICALでもNetFlowがOKであればVM単体またはアプリ起因の問題と見なし一次抑制する、といった具合だ。通知はSlackやチケットシステムへ自動連携し、深夜帯のオンコールを最小化する。以下はAlertmanagerによるSlack連携の一例である。

# alertmanager.yml（抜粋）
route:
  receiver: "slack-critical"
  group_by: ["cluster", "service"]
  routes:
    - matchers: [severity="critical"]
      receiver: "slack-critical"
    - matchers: [severity="warning"]
      receiver: "slack-warning"

receivers:
  - name: "slack-critical"
    slack_configs:
      - channel: "#ops-critical"
        send_resolved: true
        title: "[CRIT] {{ .CommonAnnotations.summary }}"
        text: "{{ range .Alerts }}• {{ .Annotations.description }}{{ end }}"

一次対応の自動化として、特定サービスの自動再起動と通知をAnsibleで実装しておくと、復旧時間の短縮に直結する。

# service_auto_recover.yml
- hosts: target_group
  become: yes
  tasks:
    - name: Check service
      shell: systemctl is-active mysvc || systemctl restart mysvc
      register: r
      changed_when: "'inactive' in r.stdout"

    - name: Notify to Slack
      when: r.changed
      uri:
        url: https://hooks.slack.com/services/XXX/YYY/ZZZ
        method: POST
        body_format: json
        body:
          text: "[auto-recover] mysvc restarted on {{ inventory_hostname }}"

SREの基本として、SLI/SLOの定義（可用性、レイテンシ、エラー率、容量）を先に行い、Error Budgetを変更判断の基準に組み込む。守れないSLOは、実装より先に設計の見直しが必要だ。

7. フェーズ5：IaC/CI での変更管理（Plan/Apply分離, PoC→段階適用）

変更は常にコードで管理し、PlanとApplyを分離する。PR段階でPlanを提示し、メインブランチにマージされた変更のみApplyする運用にすることで、レビューと承認、実行の分離が自然に実現できる。以下はGitHub Actionsでの最小構成例である。

name: terraform
on:
  pull_request:
  push:
    branches: [ main ]
jobs:
  plan:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform plan -out=tfplan
  apply:
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform apply -auto-approve

あわせてConftestやOPAでポリシーをコード化し、禁止リソースやタグ必須、サイズ上限などを静的検査に組み込む。ドリフト検出は定期的なterraform planの実行で早期に察知し、差分の原因をPRベースで追えるようにしておく。

8. フェーズ6：セキュリティ/ISMS と証跡化（運用を“証明可能”に）

特権管理は最小権限と期限付き付与、そしてブレークグラス手順まで含め、レビューと承認、実行をPRベースで分離する。監査要求に応えるには、認証、変更、監視、バックアップ、復旧のログを相関させ、誰が何をいつどの文書に基づいて行ったのかを追跡可能にしておくことが不可欠である。運用設計書やRunbookは現場が迷わない粒度で整備し、差分履歴と検索性を確保する。ここまでが整って初めて、運用は“説明可能”であり“監査可能”になる。

9. フェーズ7：DR/BCP と DC移転設計（ゲームデイとカットオーバ）

経営と合意したRPO/RTOを起点に、レプリケーション、スナップショット、ログシッピングの手段を選び、四半期に一度の計画障害演習（ゲームデイ）でリンク断、ホスト断、ストレージ断、電源系のシナリオを検証する。DC移転時には、IP再設計やBGP、VRF、搬入出計画、そして管理プレーンからデータプレーン、アプリ層へという移行順序を厳密に守る。カットオーバは“儀式”ではなく“再現可能なプロセス”としてコードとRunbookに落とし込んでおく。

10. 逆張りリスト：ありがちなアンチパターン

移行を急ぐあまり計測を省略して“まず移す”という判断は、Golden Imageやベンチ結果、依存グラフの不在とセットで失敗を招く。アラートをすべてSlackに流すだけの運用は、相関や抑制のないノイズで人を疲弊させる。SELinuxをPermissiveで運用する安易さはISMSや外部監査で必ずしっぺ返しを食う。GPUを“とにかく詰める”考え方は電力、熱、エアフローの制約を無視しており、長期運用では破綻する。口伝の手順は運用ではない。ConfluenceやGitで差分管理された文書とコードだけが、再現性と責任の所在を保証する。

11. 付録：設計チェックリスト & スニペット集

最終チェックでは、CMDB/BoMが型番やファーム、契約、窓口まで含めて完了しているか、L3/L4/L7の依存関係グラフと優先度が定義されているか、VMwareのEVC/DRS/HA/Admission設計とvDS統一、メンテ窓口の定義があるか、vSANのFTT/FTM/QoSやresync計画、N+2の余力があるかを確認する。OSではRHEL8/Rocky8のGolden ImageとCIS Baseline、SELinux Enforcingを前提にし、GPUではMIG、電力、熱、監視（DCGM/pynvml）、ドライバマトリクスを固める。監視は相関ルールとノイズ抑制、Slack/チケットの自動連携まで整備し、IaC/CIではPlan/Apply分離、ポリシー、ドリフト検出が組み込まれているかを点検する。ISMSは変更管理、証跡、権限、監査ログを横断で揃え、DR/BCPはRPO/RTOの合意とゲームデイ、DC移転計画まで閉じていることが目安になる。以下に、現場で役立つスニペットを添えておく。

#!/bin/bash
# /usr/local/bin/check-proc-count.sh
PROC="myservice"
COUNT=$(pgrep -fc "$PROC")
[ "$COUNT" -ge 1 ] && echo "OK: $PROC=$COUNT" && exit 0
echo "CRITICAL: $PROC not running" && exit 2

# mackerel-agent.conf（抜粋）
[plugin.checks.proc_mysvc]
command = "/usr/local/bin/check-proc-count.sh"

ルール：(device_down AND link_down_same_segment) -> Critical
ルール：(vm_down AND link_up) -> App/OS 起因（一次抑制）
メンテ中は自動サイレンス（タグ/タイムウィンドウ連携）

さいごに（まとめ）

引き継ぎと再構築の本質は、「測る」「設計する」「コード化する」「証跡化する」という反復に尽きる。生成AIを支える基盤はGPUという強い物理制約を内包し、仮想化やOS、電力、熱、セキュリティを横断して設計しなければ“詰み”を回避できない。SREアプローチとISMSの要件を最初から組み込み、障害に強く監査に耐えるプラットフォームを、コードと文書で説明できる状態に保ち続けること。それがアーキテクト/PLに求められる実務の中核である。本稿は規模やプロダクトの差に応じて適宜読み替えを要するが、共通の設計原則として参照できるはずだ。

参照リンク集：大規模オンプレ × 生成AI/SaaS の引き継ぎ・再構築

フェーズ0：資産把握・依存関係の可視化

• RFC 7011: IPFIX（NetFlow後継）仕様
• sFlow v5 仕様（sFlow.org）

フェーズ1：仮想化／ストレージ（VMware, vSAN, Network）

• VMware vSphere Distributed Switch (vDS) 概要
• VMware vSAN 設計・運用ガイド
• Terraform vSphere Provider (Registry)
• Packer vsphere-iso Builder

フェーズ2：Linuxモダナイゼーション（CentOS7→RHEL8/Rocky）

• RHEL 8 SELinux ガイド
• CentOS 7 EOL アナウンス
• Rocky Linux 8: NetworkManager/nmcli ドキュメント
• fio I/O テストツール公式

フェーズ3：GPU/H100 運用（MIG／電力・熱／監視）

• NVIDIA MIG ユーザーガイド
• NVIDIA DCGM (Data Center GPU Manager)
• NVML API / pynvml (Python Binding)
• CUDA Compatibility Guide
• DGX A100: MIG 運用ガイド

フェーズ4：監視・インシデント運用（相関・自動化）

• Prometheus Alertmanager 設定ガイド
• Slack Incoming Webhooks
• LibreNMS Alerts ドキュメント
• Mackerel チェックプラグイン
• Jira Service Management Webhook 自動化

フェーズ5：IaC／CI と Policy as Code

• Terraform vSphere Provider (再掲)
• Packer vsphere-iso (再掲)
• Open Policy Agent (OPA) ドキュメント
• Conftest GitHub

フェーズ6：セキュリティ／ISMS（ISO/IEC 27001）

• ISO/IEC 27001:2022 概要（ISO公式）
• Microsoft Learn: ISO/IEC 27001 概要

フェーズ7：DR/BCP・ゲームデイ

• NIST SP 800-34 Rev.1: Contingency Planning Guide
• Principles of Chaos Engineering

SRE（SLI/SLO／エラーバジェット）

• Google SRE Workbook: SLO 実装
• Google SRE: Error Budget Policy
• Site Reliability Engineering 書籍（オンライン版）

コスト最適化（FinOps）

• FinOps Framework (finops.org)
• FinOps Foundation: 用語集とリソース
• Microsoft Learn: FinOps 解説