皆さんこんにちは。OpenShift Virtualization とストレージを生業にしている Red Hat のうつぼ（宇都宮）です。 【NetApp コラボ特集】Virt 屋のひとりごと : 第4回をお届けします。今回のテーマは vSphere から OpenShift Virtualization への VM 移行です。 回 テーマ 第1回 ストレージ基本設計、Trident のドライバ選定 第2回 容量設計 第3回 性能設計 第4回（本記事） VM 移行（Shift Toolkit） 第5回 マルチテナント設計 第6回 データ保護 第7回 DR 設計 第8回 監視と運用 VMware 環境の VM を OpenShift Virtualization に持ってくる。これが移行プロジェクトの最大のハードルです。特にディスクデータのコピーがボトルネックになります。1TB の VMDK を 10GbE でコピーすると理論値でも 14 分、実効速度を考えれば数十分から数時間。VM の台数が多ければその分だけ線形に伸びていきます。移行ウィンドウの確保、業務停止時間の調整、ネットワーク帯域の奪い合い。VMware 運用者にとってはどれも馴染みのある頭痛の種ではないでしょうか。 ところが NetApp Shift Toolkit を使うと、この「コピー」がストレージ側のメタデータ操作に置き換わるため、1TB のディスクでも秒単位でコピーが終わります。むちゃくちゃ速いです。正直感動しました。 この記事では、Shift Toolkit がなぜそんなに速いのかを FlexClone の仕組みから掘り下げつつ、Red Hat の Migration Toolkit for Virtualization（MTV）と組み合わせた移行の設計パターンを紹介します。 Shift Toolkit にはいくつかのデプロイ方式がありますが、今回は OpenShift 上にコンテナとしてデプロイする "MTV Bundle" を使います。別途 Windows サーバーを用意する必要がなく、MTV コンソールから操作が完結する方式です。後半では MTV 単体と Shift + MTV で移行時間がどれくらい変わるかの実測検証も行います。 本シリーズの他の記事と合わせて読むと、移行前後のストレージ設計がつながります。第1回で紹介した ontap-nas ドライバの基礎知識は、本記事の NFS データストアや Trident バックエンドの話に直結します。また、第3回の性能検証と同じ AFF C190 環境（Trident は Shift の要件に合わせて 26.06 に更新）で今回の移行検証も実施しています。 検証環境 NetApp Shift Toolkit とは FlexClone で速い理由、NFS でなければならない理由 Shift + MTV の役割分担 移行の設計と手順 検証 MTV 単体 vs Shift + MTV どう使い分けるか 検証環境 この記事を作る上で、お借りした NetApp 機器を OpenShift クラスタに接続した検証環境を構築して動作を確認しました。以下には環境情報を記載します。 NetApp 機器 および Trident 項目 値 ストレージモデル NetApp AFF C190 x 2（HA ペア） ONTAP バージョン 9.18.1P2 Trident バージョン 26.06 ディスク SSD x 12 本（モデル: X382_S1643960ATE / 894.3GB） パーティショニング ADP（Advanced Disk Partitioning）有効 データアグリゲート RAID-DP x 2（各ノード 1 つ） ネットワーク 10GbE AFF C190 はエントリークラスの All-Flash モデルです。 第3回の性能検証 と同じ機器を使用しています。今回は記事中で紹介する「移行専用 SVM」パターンを採用し、この SVM 内に作成した FlexVol を ESXi に NFS データストアとしてマウントしています。 VMware 環境（移行元） 項目 値 vCenter Server vCSA 7.0.3 ESXi 7.0.3 NFS データストア ONTAP-NFS-Datastore（AFF C190 の FlexVol を NFSv3 マウント） OpenShift クラスタ（移行先） 項目 値 OpenShift バージョン 4.22.0 OpenShift Virtualization 4.22.2 Trident CSI 26.06 MTV 2.12 Shift Toolkit 1.0.0（MTV Bundle） Control Plane Node 3 x 仮想マシン Compute Node 3 x ベアメタルマシン ネットワーク 10GbE ざっくりネットワーク図 ONTAP は VMware ESXi と OpenShift クラスタの両方に NFS で接続しています。Shift + MTV による移行ではデータパスが ONTAP 内で完結するため、ESXi ↔ OpenShift 間のネットワーク転送は発生しません。 移行対象 VM VM 名 OS ディスクサイズ mig-test-rhel RHEL 8.3 316 GB この VM に対して MTV 単体と Shift + MTV の 2 通りで Cold Migration を実行し、MTV が報告する Phase ごとの所要時間を計測しました。 NetApp Shift Toolkit とは NetApp Shift Toolkit （以下 Shift）は、異なるハイパーバイザー間で VM を移行・変換するための無償ツールです。vSphere から OpenShift Virtualization、Hyper-V、Proxmox、Oracle Linux Virtualization Manager など複数の移行先に対応しています。 このツールの核になっているのが ONTAP の FlexClone 技術です。FlexClone は Snapshot を基点として既存ブロックを共有する、書き込み可能なクローンを瞬時に作成する機能です。作成時にフルコピーと同等の追加容量を必要とせず、その後に変更されたブロック分の容量だけを消費します。 普通の移行ツールは VMDK のデータをネットワーク経由で丸ごと実コピーしますが、Shift は ONTAP 側で FlexClone を作成します。そのため、1TB の VMDK でも数秒でコピー&変換が完了します。全体をネットワーク経由でコピーする必要がないため、従来のデータコピー方式と比べて、移行時のネットワーク転送量とストレージ負荷を大幅に削減できます。 大雑把に言うと「コピーしないで変換する」のが Shift です。 2 つのデプロイ方式 Shift には大きく分けて 2 つのデプロイ方式があります。 ひとつは Windows サーバーにインストールするスタンドアロン版。従来からある方式で、Shift 専用の GUI から操作します。Hyper-V や Proxmox への移行ではこちらを使います。 もうひとつが今回使う MTV Bundle（ shift-toolkit-openshift-installer ）です。こちらは Shift を OpenShift クラスタ内にコンテナとしてデプロイします。専用の Namespace に、変換を実行する Shift Service と、MTV が作成した PVC を監視して Shift Service に変換を依頼する Shift Listener の 2 つが Pod として展開されます。 Windows スタンドアロン版 MTV Bundle 動作場所 別途用意した Windows サーバー OpenShift クラスタ内（Pod） 操作 Shift 独自の Web UI MTV コンソールから直接操作 MTV 連携の流れ Shift → MTV を呼び出す MTV が作成した PVC を Shift Listener が検知して変換を実行 Windows 版だと「Shift UI で Blueprint を作って MTV Plan を選んで…」という操作が必要ですが、MTV Bundle ならその手間がなくなります。MTV コンソールで Migration Plan を実行するだけで、裏側で Shift Listener が FlexClone 変換を自動的にキックしてくれる。Shift の存在を意識せずに済むのが嬉しいところです。 MTV Bundle はコンテナイメージの tar がパッケージに同梱されているので、インターネットに接続できない（エアギャップ）環境でも、OpenShift の内部レジストリに push すればデプロイできます（手順は後述）。エンタープライズの OpenShift 環境はインターネット接続がない制限環境で運用されていることが珍しくないので、ここは心強いところです。 FlexClone で速い理由、NFS でなければならない理由 FlexClone の仕組み NetApp のドキュメント によると、ONTAP のファイルシステムである WAFL（Write Anywhere File Layout）はすべてのデータをブロック単位で管理しており、FlexClone でボリュームのクローンを作る際はブロックそのものはコピーせず、メタデータ（ブロックへのポインタ）だけを複製するとのことです。 nfs_datastore（FlexVol = NFS データストア） ├── vm1.vmdk ← 元の VMDK（1TB） │ ↓ Snapshot → FlexClone Volume（データブロック共有、ゼロコピー） trident_pvc_xxx（FlexClone Volume） └── disk.img ← フォーマット変換済み（数秒で完了） 今回の検証では、Shift がソース FlexVol の Snapshot を取得し、そこから FlexClone Volume を作成している様子を ONTAP System Manager の画面で確認できました。クローンされたボリューム内で VMDK から disk.img（RAW 形式）への変換が行われ、これが Trident の PVC のバックエンドとして使われるようです。 「変換」と聞くとデータを読み出して別フォーマットで書き直すイメージがありますが、FlexClone は Snapshot からの分岐のためデータコピーは発生しません。後述しますが、実際に 316 GB のディスクでもクローンからフォーマット変換まで秒単位で完了しました。 NFS でなければならない理由 ここで大事な前提があります。Shift を使うには、ソース VM が ONTAP の NFS データストア上にないといけません 。VMFS データストア（iSCSI / FC）にある VM には直接使えない。 NetApp Community の記事 では、Shift は VMDK ファイルのヘッダーに直接アクセスしてフォーマット変換を行う "agentless, header-only approach" と表現されています。この方式が動作するには、ONTAP が VMDK を「ファイル」として認識できる必要があると考えられます。 NFS データストアの場合、ONTAP が NFS サーバーとしてファイルシステムを管理しているため、FlexVol 内の個々の VMDK ファイルを認識できます。ボリュームをクローンした後にその中の VMDK のヘッダーにアクセスしてフォーマット変換を実行できる、というのが NFS が必要な理由のようです。 ESXi → NFS マウント → ONTAP FlexVol ├── vm1.vmdk ← ONTAP がファイルとして認識している ├── vm2.vmdk ← FlexClone Volume を作れば変換可能 └── vm3.vmdk 一方、VMFS データストアでは ONTAP は LUN（ブロックデバイス）を丸ごと提供しているだけです。VMFS は ESXi が LUN の上に構築・管理するファイルシステムなので、ONTAP 側からは中の個別ファイルを認識できません。仮に LUN をクローンしたとしても、ONTAP から見ればバイト列の塊のままであり、中の VMDK を見つけることもヘッダーにアクセスすることもできないわけです。 ESXi → iSCSI/FC → ONTAP LUN（ただの raw ブロックデバイス） └── [VMFS ファイルシステム] ← ESXi が管理 ├── vm1.vmdk ← ONTAP からは見えない └── vm2.vmdk ← クローンしても変換できない じゃあ VMFS 上の VM はどうするのかというと、事前に Storage vMotion で ONTAP の NFS データストアに移動させておけばよいのです。Storage vMotion は VM を動かしたまま実行できるので、ここでのダウンタイムはゼロです。ただしネットワーク経由のデータコピーが走るため、VMDK サイズに応じた時間はかかります。 もともと NFS データストアで VMware を運用していた環境は Shift の恩恵を最大限受けられるわけで、NetApp が昔から「ONTAP + NFS で VMware を動かしましょう」と推してきた理由のひとつがここにもつながっています。 Shift + MTV の役割分担 Shift だけでも移行はできる Shift 単体でも VMware → OpenShift Virtualization の移行は可能 です。ディスク変換から Trident による PVC インポート、VM オブジェクトの作成まで、Shift がすべて実行します。ゲスト OS の調整は、移行前に起動中のソース VM へスクリプトを流し込む方式（prepareVM）で行い、VirtIO ドライバや qemu-guest-agent の導入、VMware Tools の削除、IP 設定のバックアップなどを事前に済ませておく、とドキュメントには書かれています。なお、今回は Shift 単体での移行は検証していません。 MTV を併用すると何が変わるか MTV を併用すると、Shift はディスク変換と PVC インポートに専念し、VM の作成とゲスト OS 調整は MTV に委任する形になります。 MTV Bundle の場合、この連携は MTV コンソールから Migration Plan を実行するだけで自動的に行われます。MTV は、移行先が Shift 連携用 StorageClass のディスクについて、通常の DataVolume の代わりに Shift 用のアノテーションを付けた PVC を作成します。Shift Listener がこの PVC を検知すると、Shift が Snapshot から FlexClone ボリュームを作って RAW 形式のディスクイメージを生成し、Trident がそれを PVC として取り込みます。MTV から見ると「ディスクデータがすでに PVC に入っている」状態になるので、ネットワーク経由のデータコピーをスキップし、 virt-v2v-in-place モードでゲスト OS 調整だけを実行します。 つまり MTV の最大のボトルネックであるデータ転送を Shift が解消し、ゲスト OS 調整は MTV の virt-v2v が担当する。それぞれの得意領域で役割分担する設計です。 処理 Shift のみ Shift + MTV（MTV Bundle） VMDK → RAW 変換 Shift（FlexClone） Shift（Shift Listener が依頼して FlexClone） PVC インポート Shift（Trident） Shift + Trident（MTV が作成した PVC に取り込み） VM オブジェクト作成 Shift（OpenShift API 直接） MTV（ VirtualMachine ） ゲスト OS 調整 移行前にソース VM 上でスクリプトを実行（prepareVM） 移行後にオフラインで変換（ virt-v2v-in-place ） 操作起点 Shift UI MTV コンソール virt-v2v と、それ以外の MTV の価値 一番大きいのは virt-v2v によるゲスト OS 調整の自動化です。MTV の Conversion Pod 内で virt-v2v が走り、VMware 固有ドライバの除去、virtio ドライバの注入、ブートローダーの修正、SELinux relabel などを一括で処理してくれます。特に Windows VM では、ドライバの差し替えが複雑になるため、 virt-v2v が自動でやってくれるのは大きな安心材料になります。 それ以外にも、Warm Migration（VM を動かしたままディスクの大部分を事前にコピーしておき、カットオーバー時は差分だけを転送してダウンタイムを最小化する方式）や、移行前後に Ansible Playbook を実行できる Migration Hooks、OpenShift コンソールからの一元管理など、大規模な移行プロジェクトで欲しくなる機能が揃っています。ただし、Shift と組み合わせる場合は Cold Migration のみになります（後述）。 個人的には、OpenShift Virtualization への移行であれば MTV Bundle を使わない理由は無いと考えます。Windows サーバーの準備も不要で、操作は MTV コンソールに集約できる。Shift の速さと MTV のオーケストレーションを両方手に入れた上で、運用の手間まで減るのだから、選ばない理由がない。 移行の設計と手順 知っておくべき制約 Shift には速さの裏返しとして、設計時に押さえておくべき制約があります。 まず最も重要なのが、変換はソースの FlexVol の中で行われるという点です。Shift はデータストアの FlexVol の Snapshot から FlexClone ボリュームを作り、それを PVC として使います。そのため、PVC になるボリュームは必ずソースの FlexVol から派生し、その FlexVol がある SVM を OpenShift 側の Trident バックエンドとして扱えることが前提になります。 NFS データストア必須の制約は前述の通り。それ以外にも、NFSv3 データストアのみサポート（NFSv4 は非対応）、vSphere で暗号化された VMDK は事前に暗号化解除が必要、同一ソース/宛先間の並列変換は 10 件以下を推奨、移行後にクローンの切り離しが必要（後述）、といった制約があります。切り離しを早く終わらせるため、移行元の NFS データストアは 5TB 以下に抑えることも推奨されています。 移行専用 SVM を作る 上記の制約は、端的に言えば「vSphere 環境で NFS データストアとして使っている FlexVol がある SVM を、OpenShift Virtualization 環境の Trident バックエンドとしても登録する必要がある」ということです。これは環境をまたいで SVM を共有することになり、本番系への影響を与えたくないなど様々な理由で実現できない場合もあると思います。 ですので、移行専用の SVM を作ることをお勧めします。 NetApp のドキュメント でも移行専用 SVM の新規作成を推奨しています。移行専用 SVM のパターンは第5回（マルチテナント設計）でも発展させます。SVM を用途や環境ごとに分離する設計思想は、移行だけでなく本番運用にもそのまま活きてきます。 今回の検証では svm-vmware という名前で移行専用 SVM を作成しました。 ONTAP クラスタ ├── 本番 SVM（既存の VMware 用） │ └── 既存の NFS データストア（FlexVol） │ └── svm-vmware（移行専用 SVM・新規作成） ├── nfs_datastore（FlexVol = NFS データストア） │ ├── vm1.vmdk ← Storage vMotion でここに移動 │ └── vm2.vmdk │ ↓ Snapshot → FlexClone Volume ├── trident_pvc_aaa...（FlexClone Volume → PVC） │ └── disk.img └── trident_pvc_bbb...（FlexClone Volume → PVC） └── disk.img 流れとしては、移行専用 SVM（ svm-vmware ）を作る → FlexVol（ nfs_datastore ）を作って NFS データストアとして ESXi にマウント → 移行対象 VM を Storage vMotion で移動（無停止）→ Shift が Snapshot から FlexClone Volume を作成 → Trident の PVC として取り込む → 移行後にクローンを切り離す、です。 移行専用 SVM を分けておくと、本番ワークロードへの影響を避けられます。ただし、移行した VM のディスク（PVC）は、クローンを切り離した後もこの SVM 上のボリュームとして残ります。移行専用 SVM を最終的に片付けたい場合は、Storage live migration で別の SVM の StorageClass に PVC を移してから削除してください。 移行先の Trident バックエンド 第1回で紹介したように、OpenShift Virtualization 環境でサポートされる Trident のストレージドライバとして ontap-nas 、 ontap-san 、 ontap-san-economy の 3 種類があります。では、Shift で変換した後のディスクをどのストレージドライバのバックエンドに載せるのがよいのでしょうか。 最もシンプルなのは ontap-nas で、今回の MTV Bundle での検証もこの構成です。そのまま使い続けてもいいですし、必要に応じて Storage live migration で別の StorageClass に切り替えることもできます。なお、Windows 版の手順には VMDK を LUN に変換して ontap-san / ontap-san-economy に取り込む方法も載っていますが、MTV Bundle での対応状況は今回は確認していません。 MTV Bundle のデプロイ まず Shift の MTV Bundle を OpenShift にデプロイします。前提として、Trident CSI v26.06 以降と MTV v2.12 以降がクラスタにインストール済みである必要があります。作業端末には oc CLI（cluster-admin でログイン済み）が必要です。 1. パッケージの準備 本記事は Shift Toolkit 1.0.0 で検証しています。手順は NetApp のドキュメント とパッケージ同梱の README をもとにしています。ドキュメントとはパッケージ名や Pod 名が異なる場合があるので、新しいバージョンを使う場合も含め、手元のパッケージに合わせて読み替えてください。 NetApp Support Site の Toolchest から shift-toolkit-openshift-installer-1.0.0.zip をダウンロードし、展開します。 deploy/ ディレクトリの中に bundle.yaml 、PVC 定義、コンテナイメージの tar が入っています。 2. Namespace の作成 oc create namespace shift 3. 認証情報の Secret を作成 Shift Service のログインと、Shift Listener が Shift API を叩く際の Basic 認証に使われます。パスワードは任意のものを設定してください。 oc create secret generic shift-credentials -n shift \ --from-literal=username=admin \ --from-literal=password='<任意のパスワード>' 4. TLS 証明書の作成と登録 Shift Service は HTTPS で通信します。自己署名証明書を作成し、ConfigMap として登録します。 openssl req -x509 -newkey rsa:4096 -days 3650 -nodes \ -keyout server.key \ -out server.cert \ -subj "/CN=shift-toolkit-service.shift.svc.cluster.local" \ -addext "subjectAltName=DNS:shift-toolkit-service.shift.svc.cluster.local" oc create configmap shift-toolkit-service-server-crt -n shift \ --from-file=server.cert=server.cert oc create configmap shift-toolkit-service-server-key -n shift \ --from-file=server.key=server.key oc create configmap shift-toolkit-service-ca -n shift \ --from-file=ca.crt=server.cert 3 つ目の ConfigMap は、Shift Listener が Shift Service の証明書を検証するための CA バンドルです。自己署名なのでサーバー証明書そのものを CA として登録しています。 5. PVC の作成 Shift のデータベースとログ用に 2 つの PVC が必要です。 deploy/filedb-pvc.yaml と deploy/logs-pvc.yaml の storageClassName を自分の環境の StorageClass に書き換えてから apply します。 # filedb-pvc.yaml（抜粋） apiVersion : v1 kind : PersistentVolumeClaim metadata : name : shift-toolkit-filedb namespace : shift spec : accessModes : - ReadWriteOnce resources : requests : storage : 50Gi storageClassName : "<自分の環境の StorageClass>" oc apply -f deploy/filedb-pvc.yaml oc apply -f deploy/logs-pvc.yaml oc get pvc -n shift 両方の PVC が Bound になっていることを確認してから次に進みます。 6. Bundle の適用 oc apply -f deploy/bundle.yaml これで Shift Service と Shift Listener の Deployment、ServiceAccount、SCC などがまとめて作成されます。 7. 動作確認 oc get pods -n shift shift-toolkit と shift-toolkit-listener の 2 つの Pod が Running になっていれば OK です。 oc logs -n shift deployment/shift-toolkit-listener oc logs -n shift deployment/shift-toolkit Listener のログに起動完了のメッセージが出ていることを確認します。 $ oc logs -n shift deployment/shift-toolkit-listener shift-toolkit-listener: starting 2026/08/30 12:54:39 INFO starting shift-toolkit-listener testMode=false shiftAPIURL=https://shift-toolkit-service.shift.svc.cluster.local:3704/api/recovery/conversion-pvc tridentNamespace=trident shiftNamespace=shift workers=2 2026-08-30T12:54:39Z INFO starting server {"name": "health probe", "addr": "[::]:8081"} 2026-08-30T12:54:39Z INFO Starting EventSource {"controller": "shift-toolkit-listener", "controllerGroup": "", "controllerKind": "PersistentVolumeClaim", "source": "kind source: *v1.PersistentVolumeClaim"} 2026-08-30T12:54:39Z INFO Starting Controller {"controller": "shift-toolkit-listener", "controllerGroup": "", "controllerKind": "PersistentVolumeClaim"} 2026-08-30T12:54:39Z INFO Starting workers {"controller": "shift-toolkit-listener", "controllerGroup": "", "controllerKind": "PersistentVolumeClaim", "worker count": 2} エアギャップ環境の場合 クラスタが quay.io に到達できない環境では、コンテナイメージを OpenShift の内部レジストリにプッシュしてからデプロイします。作業端末には skopeo が追加で必要です（ dnf install skopeo ）。 なお、ここでの手順は同梱の README から一部変更しています。README では push 先にクラスタ内部の Service 名（ image-registry.openshift-image-registry.svc:5000 ）を使っていますが、この名前はクラスタの外にある作業端末からは名前解決できません。そこで、push は内部レジストリの外部ルート経由で行い、Pod がイメージを pull する bundle.yaml 側だけ内部の Service 名を参照するようにしています。 まず内部レジストリの外部ルートを有効にします（すでに有効なら不要）。 oc patch configs.imageregistry.operator.openshift.io cluster \ --type=merge -p '{"spec":{"defaultRoute":true}}' push 先（外部ルート）と、Pod が pull するときの参照先（内部の Service 名）を変数に入れておきます。 ROUTE=$(oc get route default-route -n openshift-image-registry -o jsonpath='{.spec.host}') INTERNAL=image-registry.openshift-image-registry.svc:5000 内部レジストリでは、push 先のパス（ shift/... ）が Namespace に対応します。そのため、オンラインインストールの Step 2 にあたる Namespace の作成をここで先に済ませておきます。 oc create namespace shift レジストリの認証情報を取得します。 oc registry login を使います。 oc registry login --skip-check \ --registry=$ROUTE \ --to=/tmp/registry-auth.json パッケージに同梱されている tar イメージを、外部ルート経由で内部レジストリにプッシュします。 skopeo copy \ docker-archive:deploy/images/shift-toolkit-1.0.0-image.tar \ docker://$ROUTE/shift/shift-toolkit:1.0.0 \ --dest-tls-verify=false \ --dest-authfile=/tmp/registry-auth.json skopeo copy \ docker-archive:deploy/images/shift-toolkit-listener-1.0.0-image.tar \ docker://$ROUTE/shift/shift-toolkit-listener:1.0.0 \ --dest-tls-verify=false \ --dest-authfile=/tmp/registry-auth.json bundle.yaml のイメージ参照先を内部レジストリに書き換えます。Pod はクラスタ内からイメージを pull するので、こちらは外部ルートではなく内部の Service 名を指定します。 sed -i \ -e "s|quay.io/netapp/shift-toolkit:1.0.0|$INTERNAL/shift/shift-toolkit:1.0.0|g" \ -e "s|quay.io/netapp/shift-toolkit-listener:1.0.0|$INTERNAL/shift/shift-toolkit-listener:1.0.0|g" \ -e "s|imagePullPolicy: Always|imagePullPolicy: IfNotPresent|g" \ deploy/bundle.yaml あとはオンラインインストールと同じく、Step 3 の Secret 作成から Step 7 の動作確認まで実行すれば完了です。 Shift 連携用 StorageClass の作成 MTV Bundle をデプロイしたら、次に Shift 連携用の StorageClass を作成します。これが MTV 単体の移行との最大の違いです。MTV は、ストレージマップのマッピング先 StorageClass に shift.netapp.io/storage-class-type: "shift" が付いていると、そのディスクを Shift で処理する対象と判断し、Shift 用のアノテーション（ forklift.konveyor.io/netapp-shift: "true" や移行元 NFS のサーバーとパスなど）を付けた PVC を作成します。 apiVersion : storage.k8s.io/v1 kind : StorageClass metadata : name : ontap-nas-vmware annotations : shift.netapp.io/storage-class-type : "shift" shift.netapp.io/trident-backend-uuid : "<Trident バックエンドの UUID>" provisioner : csi.trident.netapp.io parameters : backendType : ontap-nas reclaimPolicy : Delete volumeBindingMode : Immediate allowVolumeExpansion : true shift.netapp.io/trident-backend-uuid には、ソース VM の NFS データストア（FlexVol）が置かれている SVM（今回は svm-vmware ）を管理する Trident バックエンドの UUID を指定します。Shift はデータストアの FlexVol から FlexClone ボリュームを作り、このバックエンド経由で PVC として取り込みます（今回は、データストアと同じ SVM を管理するバックエンドで検証しています）。 Trident バックエンドの UUID は以下で確認できます。 oc get tridentbackendconfig -n trident -o jsonpath='{range .items[*]}{.metadata.name}: {.status.backendInfo.backendUUID}{"\n"}{end}' MTV コンソールからの移行手順 ここからは通常の MTV 操作ですが、ストレージマッピングで上記の Shift 連携用 StorageClass を指定する点が異なります。 Step 1. Provider の追加 MTV コンソールから Source Provider（VMware vCenter）と Destination Provider（OpenShift）を追加します。 Step 2. Migration Plan の作成 Migration Plan を作成し、移行対象の VM を選択します。 ネットワークマッピングは通常の MTV と同じです。ストレージマッピングで、NFS データストアのマッピング先に ontap-nas-vmware （Shift 連携用 StorageClass）を指定します。通常の ontap-nas を指定すると Shift が介入せず、普通のネットワークコピーによる移行になります。 なお、Shift 連携用 StorageClass を使う Plan には、MTV 単体にはない制約が 2 つあります。移行対象 VM に VMware Snapshot が残っていると Plan が Ready にならないこと（事前に Snapshot を削除してください）と、移行タイプが Cold Migration に限られることです（Warm を選ぶと MTV のバリデーションでブロックされます）。 コンソールで設定する内容を YAML で表すと、次のようになります（名前は例です）。StorageMap のマッピング先を Shift 連携用 StorageClass にする点以外は、通常の MTV と変わりません。 apiVersion : forklift.konveyor.io/v1beta1 kind : StorageMap metadata : name : vmware-shift-storage namespace : openshift-mtv spec : provider : source : name : vmware namespace : openshift-mtv destination : name : host namespace : openshift-mtv map : - source : name : ONTAP-NFS-Datastore # 移行元の NFS データストア destination : storageClass : ontap-nas-vmware # ← Shift 連携用 StorageClass を指定するだけ apiVersion : forklift.konveyor.io/v1beta1 kind : Plan metadata : name : mig-test-rhel-shift namespace : openshift-mtv spec : type : cold provider : source : name : vmware namespace : openshift-mtv destination : name : host namespace : openshift-mtv map : network : name : vmware-network # NetworkMap は通常どおり namespace : openshift-mtv storage : name : vmware-shift-storage # ← 上の StorageMap namespace : openshift-mtv targetNamespace : <移行先の Namespace> vms : - name : mig-test-rhel Step 3. Migration の実行 Migration Plan を実行します。ここから先は MTV と Shift Listener が裏側で連携し、おおむね以下のような流れで自動的に処理が進むと考えられます。 MTV が Shift 連携用 StorageClass を検出し、DataVolume の代わりに Shift 用アノテーション付きの PVC を作成 Shift Listener が PVC のアノテーションを検知し、Shift API を呼び出す Shift がソース FlexVol の Snapshot を取得し、FlexClone Volume を作成して RAW 形式に変換（ここが秒で終わる） FlexClone 済みボリュームが Trident によって PVC にひも付けられ、PVC が Bound になる（MTV はこれで DiskTransfer 完了とみなす） MTV の virt-v2v Pod が virt-v2v-in-place モードで起動し、FlexClone 済みディスク上で直接ゲスト OS を変換 virt-v2v が virtio ドライバ注入、ブートローダー修正、SELinux relabel などを実行 MTV が VM オブジェクトを作成 MTV コンソール上では通常の Cold Migration として表示されますが、ディスクデータのネットワーク転送がなくなるため全体のリードタイムは大幅に短縮されます。 Step 4. 移行完了の確認 OpenShift コンソールから VM が正常に起動していることを確認し、ネットワーク接続やアプリケーションの動作をチェックします。 Step 5. クローンの切り離し 移行が終わったら、Shift が作った FlexClone ボリュームを親ボリュームから切り離します。移行直後の PVC は、データストアの FlexVol（ nfs_datastore ）の Snapshot から作られたクローンなので、親ボリュームと Snapshot に依存したままです。切り離すまでは、移行元のデータストアや Snapshot を削除できません。 NetApp のドキュメント では、ONTAP 9.17.1 以降は clone split 、それより前のバージョンでは vol move で切り離すよう案内されています。 検証 MTV 単体 vs Shift + MTV ここからは、冒頭で紹介した検証環境を使い、MTV 単体での移行と Shift + MTV（MTV Bundle）での移行で実際にどれくらい差が出るかを検証します。 移行時間の比較 RHEL 8（316 GB） Phase MTV 単体 Shift + MTV Initialize 10 秒 10 秒 DiskAllocation 13 秒 — ImageConversion 2 分 15 秒 3 分 34 秒 DiskTransfer （MTV 単体では DiskTransferV2v ） 8 分 49 秒 33 秒 VirtualMachineCreation 3 秒 < 1 秒 合計 11 分 30 秒 4 分 17 秒（63% 短縮） DiskTransfer （ディスクデータの転送）が劇的に短縮されているのが分かります。MTV 単体では VDDK 経由で vSphere から 10GbE ネットワーク越しにデータをコピーするため、 DiskTransferV2v に 8 分 49 秒かかっています（このうちディスクコピー自体は約 415 秒で、残りは後述する変換後の処理です）。Shift + MTV では FlexClone によりわずか 33 秒で完了しました。 なお、Shift + MTV では DiskAllocation が「—」になっています。MTV 単体では、virt-v2v がデータを書き込むための空のボリュームを CDI で確保するステップとして DiskAllocation が実行されます。一方、移行先が Shift 連携用 StorageClass の場合、MTV は virt-v2v によるディスク転送を使わず、Shift 用のアノテーションを付けた PVC を作成するだけなので、 DiskAllocation ステップ自体がありません。代わりに DiskTransfer ステップで Shift 側の処理が終わるのを待ちます（表の 33 秒）。 Phase 名が同じでも中身が違う 上の表で ImageConversion が Shift + MTV のほうが長く見えますが、これは処理が遅くなっているわけではありません。Phase 名は同じでも中身の範囲が異なるためです。 virt-v2v のログを比較すると、実際の処理内容の違いが見えてきます。 MTV 単体の virt-v2v MTV 単体では virt-v2v （通常モード）が実行されます。単一コマンドの中でゲスト OS 変換とディスクコピーの両方が行われます。 Building command: virt-v2v [-o kubevirt -i libvirt -ic vpx:// -it vddk ... mig-test-rhel] [ 0.0] Setting up the source ← vSphere に VDDK 接続 [ 42.3] Converting RHEL 8.3 to run on KVM ← ゲスト OS 変換 [ 75.3] Mapping filesystem data ← 未使用領域のスキップ準備 [ 83.2] Setting up the destination [ 84.8] Copying disk 1/1 ← ここからネットワーク転送（415 秒） [ 500.2] Finishing off この単一コマンドの内部で、0〜83 秒目のゲスト OS 変換部分が MTV の「 ImageConversion 」フェーズ、84〜500 秒目のディスクコピー部分が「 DiskTransferV2v 」フェーズに対応しています。 Shift + MTV の virt-v2v Shift + MTV では virt-v2v-in-place （in-place モード）が実行されます。ディスクデータは FlexClone ですでに PVC 上にあるため、コピーなしで直接ゲスト OS を変換します。 Building command: virt-v2v-in-place [-i libvirtxml ... /tmp/input.xml] [ 0.0] Setting up the source ← ローカルディスクを参照 [ 33.3] Converting RHEL 8.3 to run on KVM ← ゲスト OS 変換 [ 62.4] SELinux relabelling [ 67.4] Finishing off ← "Copying disk" ステップが存在しない どちらの方式でも virt-v2v に続いて virt-v2v-inspector （メタデータ生成、約 75 秒）と virt-customize （ネットワーク設定、約 20 秒）が実行されます。MTV 単体ではこれらが DiskTransferV2v フェーズに含まれますが、Shift + MTV では DiskTransfer （Shift 側の処理待ち）が ImageConversion より先に終わっているため、変換 Pod の処理はすべて ImageConversion フェーズに計上されます。 つまり、ゲスト OS の変換処理自体は同等の時間で完了しており、差が出ているのはディスクデータの転送だけです。 どう使い分けるか ここまでの内容を踏まえて、ざっくり判断基準を整理します。 もともと ONTAP + NFS データストアで VMware を運用している環境なら、Shift + MTV（MTV Bundle）を使わない理由がほぼありません。FlexClone によるゼロコピー変換の速度と、MTV の virt-v2v によるゲスト OS 調整を両方手に入れた上で、Windows サーバーの管理も不要。無償ですし、試す敷居も低い。 VMFS データストアの環境でも、Storage vMotion で NFS に寄せるステップを挟めば Shift を使えます。ただし Storage vMotion 自体はネットワークコピーなので、「それなら最初から MTV 単体でいいのでは」という判断もあり得ます。VM の台数が多く、何度も移行バッチを回すようなケースでは、最初に NFS へ寄せるコストを払ってでも Shift の速度を取る価値はあるでしょう。 移行先のストレージを SAN で運用したい場合は、まず ontap-nas で移行を完了させてから Storage live migration で ontap-san の StorageClass に切り替える 2 段階方式が現実的です。 FlexClone の速度は一度体験すると「今までのデータコピーは何だったんだ」という気持ちになります。ONTAP を持っているなら、使わない手はないでしょう。 移行後の VM を守る仕組み（Snapshot、バックアップ、レプリケーション）については第6回（データ保護）で詳しく扱います。また、サイト障害に備えた DR 設計は第7回で取り上げます。移行して終わりではなく、その先の運用まで見据えた設計が大事です。 というわけで今日はここまで。次の第5回は OpenShift + NetApp でマルチテナンシーをどう実現するかについて紹介します。

皆さんこんにちは。OpenShift Virtualization とストレージを生業にしている Red Hat のうつぼ（宇都宮）です。 【NetApp コラボ特集】Virt 屋のひとりごと : 第3回は性能設計です。 前回の記事 では ontap-nas と ontap-san で VM のデータディスクを作成したときの容量消費の違いを比較しましたが、今回はさらに踏み込んで、同じディスクに同じワークロードをかけたとき IO パフォーマンスにどれだけ差が出るのかを fio ベンチマークで測定します。 回 テーマ 第1回 ストレージ基本設計、Trident のドライバ選定 第2回 容量設計 第3回（本記事） 性能設計 第4回 VM 移行（Shift Toolkit） 第5回 マルチテナント設計 第6回 データ保護 第7回 DR 設計 第8回 監視と運用 VMware 管理者のみなさんへ 測定結果についてのお断り 検証環境 測定手法の改善点 性能検証 1 : ブロックサイズ 性能検証 2 : 並列度（iodepth） nconnect=8 の効果と SAN/NAS の性能差の要因に関する考察 性能検証 3 : 複数 VM 並列 まとめと選定ガイド おまけ : ベンチマーク中に起きたトラブル VMware 管理者のみなさんへ VMware 環境では、NFS データストアと VMFS（iSCSI / FC）データストアの性能差を気にしていた管理者は多いと思います。「NFS は手軽だけど性能は VMFS に劣る」「VMFS は速いけど管理が手間」といった議論は、VMware の世界では定番の話題でした。 OpenShift Virtualization + ONTAP でも同じ疑問があります。NFS ベースの ontap-nas と iSCSI ベースの ontap-san で、VM のディスク性能にどれくらい差が出るのか。VMware のときと同じような傾向なのか、それとも Kubernetes ならではの違いがあるのか。今回はこの疑問に fio ベンチマークで答えます。 測定結果についてのお断り 本記事の測定結果は、 特定の 1 構成（AFF C190 HA ペア、10GbE x 4、SSD 12 本）で、1 VM または少数 VM から fio を実行した結果 です。ストレージのモデル、ディスク構成、ネットワーク帯域、VM 数が変われば結果も変わります。 ontap-nas と ontap-san の相対的な傾向を掴むための参考値として読んでください。「NFS は遅い」「iSCSI が速い」という一般論を導くものではありません。 なお、QoS による性能管理については第5回（マルチテナント設計）で、性能の監視方法については第8回（監視と運用）で詳しく扱います。 検証環境 この記事を作る上で、お借りした NetApp 機器を OpenShift クラスタに接続した検証環境を構築して動作を確認しました。以下には環境情報を記載します。 NetApp 機器および Trident 項目 値 ストレージモデル NetApp AFF C190 x 2（HA ペア） ONTAP バージョン 9.18.1P2 Trident バージョン 26.02 ディスク SSD x 12 本（モデル: X382_S1643960ATE / 894.3GB） パーティショニング ADP（Advanced Disk Partitioning）有効 データアグリゲート RAID-DP x 2（各ノード 1 つ）。各アグリゲートは 12 本全ディスクのデータパーティション（10 data + 2 parity）で構成 アグリゲート容量 約 3.65TB / ノード（パーティションあたり Usable 415.8GB） SVM svm-openshift （両ノードのアグリゲートを使用） ネットワーク 10GbE x 4（iSCSI / NFS 共通） AFF C190 はエントリークラスの All-Flash モデルです。12 本の物理 SSD は ADP により root パーティションとデータパーティションに分割され、各ノードの root アグリゲート（ aggr0 ）とデータアグリゲートの両方にパーティションを提供しています。SVM svm-openshift は両ノードのデータアグリゲート（ sr_c190rj_01_SSD_1 , sr_c190rj_02_SSD_1 ）を使用しています。 平たく言えば、どちらのデータアグリゲートで作られた FlexVol でも、データは 12 本すべての SSD に stripe されます。つまり ontap-san と ontap-nas のどちらの FlexVol がどちらのノードに載っていても、バックエンドのディスク IO 性能は同条件となります。 OpenShift クラスタ 項目 値 OpenShift バージョン 4.22.0 OpenShift Virtualization バージョン 4.22.2 Control Plane Node 3 x 仮想マシン（8vCPU, 24Gi RAM） Compute Node 3 x ベアメタルマシン（8c/16t CPU, 64Gi RAM） ネットワーク ネットワーク接続は以下（All 10GbE, MTU=9000） ざっくりネットワーク図 Trident の設定 ontap-san の TBC（抜粋）: defaults : snapshotPolicy : default snapshotReserve : "10" spaceReserve : volume spaceAllocation : "true" ontap-nas の TBC（抜粋）: defaults : snapshotPolicy : default snapshotReserve : "10" spaceReserve : volume provisioningType : thin nfsMountOptions : nconnect=8 ontap-nas の TBC に nfsMountOptions: nconnect=8 を追加しています。VMware 環境でも NFS データストアのマウントオプションチューニング（TCP ウィンドウサイズの調整など）は行われていましたが、 nconnect は Linux カーネルの NFS クライアント機能であり、Kubernetes / Trident 環境で TBC の nfsMountOptions に 1 行追加するだけで有効化できるのが特徴です。効果の詳細は次のセクションで説明します。 VM の設定 rhel10-ontap-san rhel10-ontap-nas OS RHEL 10 RHEL 10 rootdisk (30Gi) ontap-san ontap-san datadisk (500Gi) ontap-san ontap-nas volumeMode Block Filesystem プロトコル iSCSI NFS（NFSv4.2） NFS マウントオプションの詳細 ontap-nas の NFS マウントオプションは、 ontap-nas の PVC を仮想ディスクとして使用している VM が稼働する Compute Node 上で以下のコマンドにより確認できます。 $ oc debug node/wk-02 -- cat /host/proc/mounts | grep nfs 192.168.34.xxx:/trident_pvc_... /host/var/lib/kubelet/pods/.../mount nfs4 rw,relatime,vers=4.2,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,nconnect=8,timeo=600,retrans=2,sec=sys,clientaddr=192.168.34.xxx,local_lock=none,addr=192.168.34.xxx 0 0 今回の検証で使用された NFS マウントオプションの主要な値は以下のとおりです。 オプション 値 説明 vers 4.2 NFS プロトコルバージョン rsize 65536 (64k) 1 回の NFS READ RPC で転送する最大バイト数 wsize 65536 (64k) 1 回の NFS WRITE RPC で転送する最大バイト数 nconnect 8 NFS マウントあたりの TCP コネクション数 proto tcp トランスポートプロトコル sec sys セキュリティモード（AUTH_SYS） hard (有効) サーバー無応答時に無期限リトライ Trident の TBC では nfsMountOptions: nconnect=8 のみを指定しており、それ以外のオプション（ vers=4.2 , rsize=65536 , wsize=65536 , hard , sec=sys 等）は Compute Node と ONTAP のネゴシエーションで決まったデフォルト値です。 ただし、意図して特定のオプション値（例えば nfsvers=4.2 など）を使いたい場合は、ネゴシエーション任せにせず TBC の nfsMountOptions や StorageClass の mountOptions で明示的に指定しておくのが妥当です。特に rsize / wsize は NFS の性能に直接影響するパラメータであり、後述の考察でも触れます。 注意 : Trident バージョンについて 本記事（第1回〜第3回）の検証環境では Trident 26.02 を使用していますが、Trident 26.02 は OpenShift 4.22 を公式にはサポートしていません。検証の範囲では動作に影響はありませんでしたが、私の不注意をお詫び申し上げます。実際に環境を構築される際は、必ず Trident のサポートマトリクス を確認し、お使いの OpenShift バージョンに対応した Trident バージョンを使用してください。 測定手法の改善点 実はこの記事、初稿ではデフォルトの NFS 設定（ nconnect なし = TCP 1 本）で測定して「ほぼ全パターンで ontap-san が有利」と結論づけていました。しかし、この条件は NFS にとってフェアとは言えませんでした。測定手法を見直して再測定を行ったところ、特に高 iodepth や複数 VM の結果に影響がありました。見直した 2 点と、NFSv4.2 に関する補足を説明します。 1. nconnect=8 の有効化 NFS はデフォルトで 1 本の TCP コネクションですべての IO を送受信します。10GbE の帯域があっても、1 本の TCP コネクションでは CPU のシングルスレッド処理がボトルネックになりやすく、NFS の並列 IO 性能が制限されます。 一方 iSCSI は、multipath を構成していなくても iSCSI initiator 内部で複数の IO を並列に発行できます。つまりデフォルト設定同士の比較は NFS にとって不利と言えます。 NFS の nconnect マウントオプションは、1 つの NFS マウントに対して複数の TCP コネクションを張るオプションです。これにより IO を複数コネクションに分散でき、NFS の並列 IO 性能が大幅に向上します。Trident では backend の nfsMountOptions に nconnect=8 と設定するだけで有効になります。 VMware の世界では、ESXi の NFS クライアント実装が独自であり、TCP コネクション数はハイパーバイザー側で制御されていました。OpenShift Virtualization では Linux カーネルの NFS クライアントがそのまま使われるため、 nconnect のような Linux カーネルのマウントオプションがそのまま効きます。これは Kubernetes / Trident 環境ならではの柔軟さです。 検証 2 では nconnect=8 の NAS と nconnect なし（=1）の NAS の両方を測定し、 nconnect の効果も合わせて検証しています。 2. random_generator=lfsr の使用 fio のデフォルトの乱数生成器は、同じブロックを複数回アクセスする可能性があります。ランダム IO のベンチマークで同一ブロックに再アクセスすると、ONTAP の read cache（DRAM）にヒットして実際のディスク性能よりも高い IOPS が出てしまいます。 random_generator=lfsr （Linear Feedback Shift Register）を使用すると、テストファイル内の各ブロックが正確に 1 回だけアクセスされます。これにより ONTAP の read cache への再ヒットを抑制し、ストレージの実性能をより正確に測定できます。 3. NFSv4.2 の使用 今回の検証では NFS のバージョンとして NFSv4.2 が使われています。これは Trident や ONTAP 側で明示的にバージョン指定したものではなく、Compute Node と ONTAP のネゴシエーションで自動的に決まったバージョンです。 なお、OpenShift Virtualization 自体はストレージプロトコルに制約を設けていません。 Red Hat のドキュメント には、 "there are no restrictions on storage protocol (e.g. NFS, iSCSI, FC, etc.) specific to OpenShift Virtualization. The only requirement is that the RWX access mode is available to support live migration of VMs within the cluster." と明記されており、Live migration の要件も RWX アクセスモードであって NFS バージョンではありません。NFSv3 でも NFSv4 でも ontap-nas であれば RWX を提供でき、Live migration は動作します。 ただし NFSv3 で接続する場合は、ストレージ側が NLM（Network Lock Manager / lockd）をサポートしている必要があります。Live migration 中に QEMU がディスクイメージファイルのロックを取得・解放するため、NLM が利用できないと移行に失敗します。NFSv4 ではロック機構がプロトコルに組み込まれているため NLM は不要です。なお ONTAP は NFSv3 + NLM をサポートしているので、ONTAP をバックエンドに使う場合はどちらのバージョンでも問題ありません。 性能面では、NFSv4 には NFSv3 にはない利点があります。Compound Operations により複数の操作（LOOKUP + OPEN + READ など）を 1 つの RPC にまとめて送信でき、ラウンドトリップ数が削減されます。また NFSv4.1 以降ではセッショントランキング（Session Trunking）がサポートされ、 nconnect で複数コネクションを張った際の管理も効率的に行われます。NFSv3 を使う積極的な理由がなければ、NFSv4 以上でのマウントをお勧めします。 一方、NFSv4 には Grace Period という注意点があります。ONTAP コントローラの HA フェイルオーバーが発生すると、NFSv4 サーバーはクライアントがロックを再取得するための猶予期間（Grace Period、ONTAP デフォルト 45 秒）に入ります。この間 READ/WRITE は NFS4ERR_GRACE で拒否され、クライアント側では IO が一時停止します。NFSv3 にはこの仕組みがないため、フェイルオーバー時の IO 再開は NFSv3 の方が速くなります。VMware 環境でも HA フェイルオーバー時の NFS データストアの再接続は運用上の注意点でしたが、NFSv4 の Grace Period はそれと性質の異なる遅延要因です。ベンチマーク結果には影響しませんが、運用上は知っておくべきポイントです。 性能検証 1 : ブロックサイズ まずはシンプルに、ブロックサイズを変えたときの性能差を見てみます。7 種類のブロックサイズ（4k〜256k）× 4 種類の IO パターン（Sequential / Random × Read / Write）= 合計 28 パターンを iodepth=1 で実行しました。NAS は nconnect=8 の条件です。 [global] time_based runtime=120 startdelay=5 ramp_time=10 direct=1 size=450G numjobs=1 iodepth=1 ioengine=libaio random_generator=lfsr filename=/myvol/testfile direct=1 で OS のページキャッシュの影響を抑制、 random_generator=lfsr で ONTAP read cache への再ヒットを抑制 各パターン 120 秒間 × 3 iter、iter2-3 の平均を採用 1 VM ずつ実行（ONTAP 側の負荷が相互に影響しないようにするため） iodepth=1 についての注意 : iodepth=1 は同時に未処理の IO が 1 つだけという条件です。per-IO のレイテンシの違いを比較するには適していますが、ストレージのポテンシャルをすべて引き出す条件ではありません。この条件での結果をもってストレージの製品性能や限界性能を語ることはできません。ストレージの限界性能は検証 2（iodepth を段階的に上げる検証）で測定します。 結果 IOPS 比較 : Random Read / Random Write（iodepth=1） スループット比較 : Sequential Read / Sequential Write（iodepth=1） iodepth=1 の条件では、Read は全パターンで SAN が NAS を上回りました。特にブロックサイズが小さいほど差が大きく、Random Read では 4k で SAN 2.5 倍、256k で 1.4 倍です（Sequential Read: SAN 1.3〜1.9 倍）。一方 Write は SAN 優位ながらも差は小さく、Random Write で SAN 1.0〜1.3 倍、Sequential Write で SAN 0.95〜1.4 倍とばらつきがあり、ブロックサイズによっては NAS が上回るケースもありました。 nconnect=8 を設定しても iodepth=1 では同時に処理される IO が限られるため、 nconnect の効果はほぼ出ていません。 iodepth=1 では IO パスの短い SAN が有利で、per-IO オーバーヘッドの影響が大きい小ブロックほど差が顕著です。では iodepth を上げていくとどうなるか、次の検証 2 で見てみましょう。 性能検証 2 : 並列度（iodepth） 検証 1 は iodepth=1 （同時 IO が 1 つだけ）の条件でした。しかし現実の環境では複数の VM やアプリが同時に IO を発行するのが普通です。ストレージのポテンシャルを引き出すために、iodepth を 1 → 128 まで段階的に上げて限界性能を探ります。 iodepth を上げていくと IOPS は伸びますが、やがて処理能力の限界に達して Latency が急上昇します。横軸 IOPS・縦軸 Latency でプロットするといわゆるホッケースティック型のカーブになり、実用的な動作点と限界性能が見えてきます。 テスト条件 4k Random Read / Random Write に絞り、iodepth を 1 → 128 まで段階的に上げて測定しました。SAN（iSCSI）、NAS nconnect=8 、NAS nconnect=1 （比較用ベースライン）の 3 構成を測定しています。 [global] time_based runtime=120 startdelay=5 ramp_time=10 direct=1 bs=4k size=450G numjobs=1 ioengine=libaio random_generator=lfsr filename=/myvol/testfile iodepth: 1 / 2 / 4 / 8 / 16 / 32 / 64 / 128 各 iodepth × 各構成で 3 iter 実施し、iter2-3 の平均を採用しています（iter1 は ONTAP キャッシュウォームアップの影響があるため除外）。 再度の注意 : 以下の結果は 1 VM からの fio 実行結果です。クラスタ全体の集約性能やマルチクライアント性能を示すものではありません。複数 VM の結果は検証 3 で見ます。 結果と考察 Random Read iodepth SAN (iSCSI) NAS nc8 NAS nc1 SAN vs nc8 nc8 / nc1 1 4,394 1,804 1,796 SAN 2.4x 1.00x 2 10,275 4,072 4,152 SAN 2.5x 0.98x 4 21,302 8,190 8,081 SAN 2.6x 1.01x 8 38,704 15,606 15,152 SAN 2.5x 1.03x 16 65,668 25,724 24,247 SAN 2.6x 1.06x 32 106,533 58,893 36,535 SAN 1.8x 1.61x 64 136,682 108,739 50,807 SAN 1.3x 2.14x 128 135,911 121,113 48,758 SAN 1.1x 2.48x Random Read は、この構成では全ての iodepth で SAN が NAS nconnect=8 を上回りました。ただし、その差は iodepth が上がるにつれて縮まっています。低 iodepth（1〜16）では SAN が 2.4〜2.6 倍と大きく差をつけていますが、 iodepth=64 では 1.3 倍、 iodepth=128 では 1.1 倍とほぼ拮抗します。 注目すべきは nconnect=8 の効果の出方です。iodepth 1〜16 では nconnect=8 と nconnect=1 の差がほぼゼロ（nc8/nc1 ≈ 1.0x）。 nconnect の効果が現れるのは iodepth=32 以降で、 iodepth=128 では nc8 が nc1 の 2.48 倍に達しています。同時に発行する IO が少ないうちは複数 TCP コネクションを利用した並列化の効果が出にくいと考えられます。 Random Write iodepth SAN (iSCSI) NAS nc8 NAS nc1 SAN vs nc8 nc8 / nc1 1 2,240 1,970 1,986 SAN 1.1x 0.99x 2 4,628 3,874 3,545 SAN 1.2x 1.09x 4 9,513 7,569 6,765 SAN 1.3x 1.12x 8 16,387 13,556 12,301 SAN 1.2x 1.10x 16 26,607 23,655 20,756 SAN 1.1x 1.14x 32 36,975 34,686 30,471 SAN 1.1x 1.14x 64 42,132 41,759 36,840 SAN 1.0x 1.13x 128 42,771 42,824 37,253 同等 1.15x Random Write も低〜中 iodepth では SAN が優位ですが、Read ほどの大差はありません。SAN の優位は iodepth=4 の 1.3 倍が最大で、iodepth が上がるにつれて差が縮まり、 iodepth=128 では NAS nconnect=8 が SAN とほぼ同等（42,824 vs 42,771 IOPS）に追いつきます。 nconnect=8 の効果は Read と同様に iodepth 依存です。低 iodepth では nc1 とほぼ同等ですが、 iodepth=16 以降で nc1 の 1.14〜1.15 倍と、控えめながら一貫したプラス効果が出ています。 IOPS by iodepth 4k Random IO : IOPS by iodepth（SAN / NAS nconnect=8 / NAS nconnect=1） グラフにすると傾向がより明確になります。Random Read では SAN の線が終始トップを走りますが、NAS nconnect=8 の線が iodepth=32 あたりから急勾配でスケールし、高 iodepth で SAN に迫っています。NAS nconnect=1 は iodepth が上がっても伸びが鈍く、 nconnect の有無で大きな差がつきます。Random Write では 3 構成とも似た軌跡を描きますが、 iodepth=128 で NAS nconnect=8 が SAN に追いつくのが見て取れます。 ホッケースティックカーブ IOPS vs Latency 横軸を IOPS、縦軸を Latency としてプロットしたホッケースティックカーブです。 Random Read では、SAN のカーブが最も右に伸びており、137K IOPS 付近でカーブが立ち上がっています。NAS nconnect=8 は 121K IOPS まで伸びており SAN の約 89% に達していますが、Latency の上昇が SAN より早く始まっています。 nconnect=1 は 51K IOPS 付近が天井です。 Random Write では、SAN が 43K IOPS に到達しても Latency の急上昇に至っておらず、まだ余力がありそうです。NAS nconnect=8 も同程度の 43K IOPS に達しており、Write に関しては SAN と NAS の天井がほぼ同じという結果です。 nconnect=8 の効果と SAN/NAS の性能差の要因に関する考察 検証 2 の結果を左右しているのは、次の 2 つの要因だと考えられます。 IO パスの長さ : SAN を有利にする要因 TCP コネクションの並列度 : NAS が追い上げる要因 iodepth が低いうちは要因 1 が支配的で SAN が大差をつけますが、iodepth が上がると要因 2 が効き始め、差が縮まっていきます。それぞれ見ていきましょう。 要因 1 : IO パスの長さ（SAN 有利） ontap-san （iSCSI）の IO パス : VM → virtio-blk → iSCSI initiator → iSCSI target → LUN → WAFL ontap-nas （NFS）の IO パス : VM → virtio-blk → disk image（ノード上のファイルシステム）→ NFS client → NFS server → FlexVol 内ファイル → WAFL ontap-nas のパスには「ノード側のファイルシステム」が挟まっています。OpenShift Virtualization では、 ontap-nas （ volumeMode: Filesystem ）の場合、VM のディスクイメージは NFS マウントされたファイルシステム上のファイルとして格納されます。VM が IO を発行するたびに、ノード側のカーネルでメタデータ処理（inode → extent map → NFS ファイルハンドル + オフセットの解決）が介在すると考えられます。 一方 ontap-san （ volumeMode: Block ）では、LUN がノードからブロックデバイスとして直接見えるため、ノード側にファイルシステムレイヤーが存在しません。この IO パスの短さが、SAN の per-IO レイテンシの低さにつながっている要因の一つと考えられます。 iodepth が低い（同時に飛ぶ IO が少ない）状態では、IOPS はほぼ per-IO レイテンシで決まります。IO パスが短い SAN はここで大きく有利になり、Read で 2.4〜2.6 倍の差がついています。 なお、今回の測定だけでは IO パス差と他の要因（プロトコルオーバーヘッド、NFS RPC の処理コストなど）の個別の寄与率を切り分けることはできません。上記はあくまで傾向を説明する考察です。 要因 2 : TCP コネクションの並列度（NAS 追い上げ） nconnect=8 は NFS マウントに 8 本の TCP コネクションを張り、IO をラウンドロビンで分散します。ただし、その効果は iodepth に強く依存します。 iodepth 1〜16: Read は nc8 ≈ nc1（nc8/nc1 ≈ 1.0x）、Write は nc8 が若干有利（1.0〜1.15x） iodepth 32〜128: nc8 > nc1（Read で最大 2.5x、Write で 1.1〜1.2x） iodepth=1 では同時に未処理の IO は 1 つだけなので、TCP コネクションが 8 本あっても実際に使われるのは 1 本です。iodepth が上がって同時に複数の IO が飛ぶようになると、ようやく複数コネクションへの分散が効き始めます。 iodepth が十分に高くなると、IOPS の律速要因が per-IO レイテンシから IO の同時処理能力に移ると考えられます。こうなると、IO パスの長さによるオーバーヘッドは消えないものの、8 本の TCP コネクションによる並列性で補えるようになり、NAS が SAN との差を詰められるようになります。Read では iodepth=128 で SAN の 89%（121K vs 136K IOPS）まで追い上げ、Write では同等（43K IOPS）に追いついています。 Read での効果が Write より大きいのは、NFS の READ call が並列処理の制約が少ない操作であるのに対し、 WRITE call はサーバー側で整合性処理（NVRAM への書き込み、確認応答の同期など）が介在するため、コネクションを増やしたぶんだけスケールしにくいためではないかと考えられます。 iSCSI で TCP を増やすには iSCSI は 1 セッションあたり 1 本の TCP コネクションを使います。iSCSI の規格（RFC 7143）には MC/S（Multiple Connections per Session）という複数コネクション機能がありますが、Linux の iSCSI イニシエータ（ open-iscsi ）はこれをサポートしていません。iSCSI で TCP コネクションを増やすには iSCSI multipath（複数 NIC 構成）が必要です。NFS の nconnect のように Trident の TBC に nfsMountOptions: nconnect=8 と 1 行追加するだけで TCP を多重化できる手軽さは、NFS 側のアドバンテージと言えます。 性能検証 3 : 複数 VM 並列 ここまでのテストは 1 VM（1 fio プロセス）での測定です。しかし VMware 環境では 1 つのデータストアに複数の VM が載るのが当たり前でした。同様に、ONTAP 上でも複数 VM が同一の FlexVol（ ontap-san の場合）や同一の NFS マウント（ ontap-nas の場合）に同時にアクセスするのが現実です。VM を増やしたときに ONTAP がどこまでスケールするのか、SAN と NAS で差が出るのかを検証します。 テスト条件 3 Compute Node に VM を均等配置し、全 VM で同時に fio を実行しました。 3 VM: 各ノードに 1 VM ずつ（1/1/1 配置） 6 VM: 各ノードに 2 VM ずつ（2/2/2 配置） fio のパラメータは検証 2 と同じですが、iodepth は 1 / 4 / 16 / 64 の 4 段階に絞っています。各 VM がそれぞれ独自の datadisk（500Gi）に対して fio を実行し、結果は全 VM の合算 IOPS です。 VMware に例えると、「1 つの ESXi ホストに 1〜2 台の VM を載せ、3 ホストクラスタ全体でストレージのスケーラビリティを見る」という構成に近いテストです。 3 VM の結果 パターン iodepth SAN (iSCSI) NAS nc8 優位 randread 1 7,460 5,584 SAN 1.3x randread 4 30,888 23,079 SAN 1.3x randread 16 83,059 71,570 SAN 1.2x randread 64 102,983 108,122 NAS 1.05x randwrite 1 6,649 5,395 SAN 1.2x randwrite 4 24,010 20,065 SAN 1.2x randwrite 16 43,230 50,608 NAS 1.2x randwrite 64 50,355 70,838 NAS 1.4x 3 VM では興味深い結果になりました。低い iodepth（1, 4）では SAN が 1.2〜1.3 倍で優位ですが、 iodepth が高くなると NAS が逆転 しています。 検証 2 の 1 VM でも、高 iodepth では NAS が SAN に迫る傾向がありました（Write iodepth=128 で同等）。3 VM ではその傾向がさらに進んでいます。3 ノードからそれぞれ nconnect=8 の TCP コネクションで IO を発行するため、ONTAP 側で並列処理できる IO の総量が増え、 nconnect の効果がより強く現れていると考えられます。 6 VM の結果 パターン iodepth SAN (iSCSI) NAS nc8 優位 randread 1 14,869 10,707 SAN 1.4x randread 4 61,645 41,563 SAN 1.5x randread 16 162,501 92,993 SAN 1.7x randread 64 207,877 115,976 SAN 1.8x randwrite 1 13,986 10,238 SAN 1.4x randwrite 4 46,829 33,754 SAN 1.4x randwrite 16 85,962 65,814 SAN 1.3x randwrite 64 99,924 73,809 SAN 1.4x 6 VM になると様相が一変します。 全パターン・全 iodepth で SAN が優位 で、その差は 1.3〜1.8 倍。3 VM で NAS が逆転していた高 iodepth 領域でも、6 VM では SAN が明確に上回っています。 SAN は iodepth=64 で randread 208K IOPS、randwrite 100K IOPS に到達。一方 NAS は randread 116K、randwrite 74K にとどまりました。 3 VM → 6 VM スケーリング 複数 VM での並列 IO（3 VM / 6 VM） 3 VM → 6 VM スケール パターン iodepth SAN スケール NAS スケール randread 1 1.99x 1.92x randread 4 2.00x 1.80x randread 16 1.96x 1.30x randread 64 2.02x 1.07x randwrite 1 2.10x 1.90x randwrite 4 1.95x 1.68x randwrite 16 1.99x 1.30x randwrite 64 1.98x 1.04x ここが今回の検証で最も注目すべき結果のひとつです。 SAN は VM 数に対してほぼ理想的な線形スケーリング を示しています。3 VM → 6 VM で全パターン約 2.0 倍。ONTAP の HA ペア（2 ノード）に対して VM が均等に分散されるため、両ノードの処理能力を効率的に使い切っています。 NAS は低 iodepth では線形に近い（1.8〜1.9 倍）ものの、高 iodepth ではスケーリングが頭打ちになっています。 iodepth=64 ではわずか 1.04〜1.07 倍しか伸びていません。VM を倍にしてもほとんど性能が上がらないということです。 6 VM が 3 ノードに分散し、各ノードから nconnect=8 で複数の TCP コネクションが ONTAP の NFS サーバーに集中することで、NFS プロトコルの処理（RPC の処理、コネクション管理等）がボトルネックとなり、ストレージ側が飽和していると考えられます。SAN（iSCSI）は各 LUN が独立して処理されるため、プロトコル層でのこの種のボトルネックが生じにくいと考えられます。 VMware の世界に置き換えると、「NFS データストアに多数の VM を集約すると、VMFS（iSCSI / FC）データストアに比べてスケーラビリティの壁に当たりやすい」という経験則に近い傾向です。ただし、ストレージモデルやネットワーク帯域によってその壁の位置は大きく変わります。 まとめと選定ガイド 今回は 3 種類の fio ベンチマークにより、AFF C190 上の ontap-san （iSCSI）と ontap-nas （NFSv4.2, nconnect=8 ）の IO 性能を比較しました。 検証結果サマリ 検証 条件 Read Write 検証 1 1 VM, iodepth=1 , BS 可変 SAN 1.2〜2.5x（小 BS ほど差大） SAN 0.95〜1.4x（NAS 優位もあり） 検証 2 1 VM, iodepth 可変, 4k SAN 1.1〜2.6x（高 iodepth で差縮小） SAN 1.0〜1.3x（iodepth=128 で同等） 検証 3（3 VM） 3 VM, iodepth 可変, 4k 低 iodepth: SAN、高 iodepth: ほぼ同等 低 iodepth: SAN、高 iodepth: NAS 1.4x 検証 3（6 VM） 6 VM, iodepth 可変, 4k SAN 1.4〜1.8x SAN 1.3〜1.4x 結果から見えたこと 1 VM では Read は SAN が安定して速い。 Write も多くの条件で SAN が優位ですが、iodepth が上がるにつれて差は縮まり、Write の iodepth=128 では NAS nconnect=8 が SAN と同等まで追いつきます。 nconnect=8 は高 iodepth で効果を発揮する。 nconnect=8 の効果は iodepth 32 以上で現れます。Read では nconnect=1 の最大 2.5 倍、Write でも 1.1〜1.2 倍の向上が得られます。逆に iodepth が低い状態では nconnect を増やしても効果はほぼありません。NFS を使うなら nconnect の設定が性能に大きく影響しますが、その効果が活きるのは IO の並列度が高い環境です。 NFS は NFSv4 以上を使う。 今回の検証では NFSv4.2 を使用しています。NFSv4 の Compound Operations によるラウンドトリップ削減やセッショントランキングは nconnect と相性が良く、NFSv3 よりも効率的に並列 IO を処理できます。 VM 数がスケールする環境では SAN にスケーラビリティの利がある。 SAN は VM 数に対して線形にスケールしますが、NAS は高 iodepth で頭打ちになる傾向が見られました（この AFF C190 構成の場合）。多数の VM が同時に高 IO を発行する環境では、SAN のスケーラビリティが光ります。 少数 VM なら NAS も十分競争力がある。 3 VM 程度であれば NAS nconnect=8 は高 iodepth で SAN と同等以上の性能を出しており、用途によっては ontap-nas が有利な場面もあります。 プロトコル選定ガイド : 性能だけでは決まらない VMware から OpenShift Virtualization へ移行する際、ストレージプロトコルの選定は性能だけで決まるものではありません。VMware のときと同様に、総合的な判断が必要です。以下の観点で整理します。 観点 ontap-nas （NFS） ontap-san （iSCSI） IOPS 性能（1 VM） SAN に劣るが nconnect=8 + 高 iodepth で差は縮まる 全般的に安定して高い スケーラビリティ（多 VM） 高 iodepth で頭打ち傾向あり VM 数に対して線形にスケール Live migration RWX を標準サポート。VMware の vMotion と同様にストレージ側の追加設定不要 RWX（ volumeMode: Block ）で対応可能 運用のシンプルさ NFS マウントのみ。VMware の NFS データストアと同様に管理がシンプル iSCSI initiator、LUN マッピングが必要 nconnect によるチューニング TBC に 1 行追加で TCP 多重化。Kubernetes / Trident ならではの手軽さ TCP 多重化には multipath（複数 NIC）が必要 バックアップ・DR ONTAP SnapMirror、Trident Protect で NFS / iSCSI ともに対応。プロトコル差は小さい 同左 既存の運用ナレッジ VMware で NFS データストアを運用していた組織には親和性が高い VMware で VMFS + iSCSI / FC を運用していた組織には親和性が高い 性能要件が見えている場合 : 例えばピーク IOPS が 20,000 IOPS 程度であれば、 ontap-nas も ontap-san もどちらもサブミリ秒で返すので、ぶっちゃけ大差ありません。その場合は論理構成がシンプルな ontap-nas を選ぶ判断は全くもって妥当です。多数 VM の高 IOPS が必要な環境では ontap-san のスケーラビリティが活きます。 性能要件が見えていない場合 : 最近は Storage live migration も GA になって ontap-san ↔ ontap-nas の移動は簡単にできるので、まずは気楽に ontap-nas + nconnect=8 で始めて、性能要件に応じて ontap-san に切り替えるというアプローチも十分現実的です。 VMware で NFS データストアを使っていた場合 : NFS の運用ナレッジがある組織なら、 ontap-nas は移行のハードルが低いです。 nconnect=8 を忘れずに設定すれば、性能面でも十分戦えます。 VMware で VMFS + iSCSI / FC を使っていた場合 : SAN の運用ナレッジがある組織なら、 ontap-san への移行は自然な選択です。ただし、OpenShift / Kubernetes 環境では Trident が LUN の管理を自動化してくれるため、VMware 時代の LUN 管理の手間は大幅に軽減されます。 なお、QoS による VM ごとの性能制御については第5回（マルチテナント設計）で、日常的な性能監視の方法については第8回（監視と運用）で詳しく扱います。 というわけで今日はここまで。次回の第4回では、NetApp Shift Toolkit と MTV を使った VM の移行について紹介します。 おまけ : ベンチマーク中に起きたトラブル 今回のベンチマークで、 snapshotPolicy: default のまま fio を実行した結果、ONTAP の Snapshot 差分が snapshotReserve （10%）を超えて FlexVol を埋め尽くし、VM が PausedIOError で停止するというトラブルが発生しました。 容量編 で「 snapshotReserve: 10 を設定しておけば Snapshot 領域を確保できる」と書きましたが、変更率の高いワークロードでは 10% でも不足し得るという実例です。 fio のような大量書き込みを行うワークロードでは、1 時間ごとの定期 Snapshot が取得されると、変更ブロックが Snapshot に保持され続けます。450G のファイルを繰り返し上書きすると、差分が膨張し、今回は snapshot-space-used が 195% に達しました。 Write のベンチ実施時には、対象ボリュームの snapshotPolicy を一時的に none に変更しましょう。また、既存の Snapshot も削除しておくことを強くおすすめします。WAFL の Snapshot は Redirect-on-Write で、Snapshot 作成時はほぼ無風ですが削除時にブロックの解放処理がわーっと発生して性能に影響を及ぼすので、安全のためベンチの前に消しておきましょう。 本番環境では、ワークロードの変更率（日次の変更ブロック量）と Snapshot の保持世代数から必要な snapshotReserve を見積もり、Snapshot 使用率を監視することが重要です。「10% にしておけば安心」ではなく、実際の変更パターンに合わせた設計が必要です。

皆さんこんにちは。OpenShift Virtualization とストレージを生業にしている Red Hat のうつぼ（宇都宮）です。 NetApp コラボ特集の第2回をお届けします。 前回の記事 では ontap-nas と ontap-san のストレージドライバの違いを整理しましたが、今回はもう一歩踏み込んで、実際に VM のディスクを作ったとき、ONTAP 側でどのようにボリュームが作られるのかを比較してみます。 回 テーマ 第1回 ストレージ基本設計、Trident のドライバ選定 第2回（本記事） 容量設計 第3回 性能設計 第4回 VM 移行（Shift Toolkit） 第5回 マルチテナント設計 第6回 データ保護 第7回 DR 設計 第8回 監視と運用 本稿のアジェンダです。 検証環境 VMware の容量管理を振り返る ONTAP / Trident 側の設定 VM の設定 PVC の Capacity を覗く : FS オーバーヘッドという新しい概念 ONTAP を覗く : Snapshot reserve は VMFS ではなく FlexVol の中にある それぞれのディスクに紐づく FlexVol を見てみる なぜ FlexVol のサイズが逆転するのか 容量消費の全体像 おまけ： snapshotReserve を設定しないとどうなるか まとめ はじめに、この記事では容量に関する以下の4つの用語を使い分けます。 用語 意味 確認方法 VM ディスク容量 ゲスト OS から見える・利用できるディスクサイズ VM 内で lsblk 等 PVC Capacity OpenShift 側の PVC サイズ oc get pvc の CAPACITY 列 FlexVol サイズ ONTAP の FlexVol 論理容量（Snapshot reserve を含む） volume show の Size FlexVol Available FlexVol 内のユーザーデータ利用可能容量（Snapshot reserve を除く） volume show の Available VMware で言えば、「VM ディスク容量」は VMDK の論理サイズ、「FlexVol サイズ」はデータストア上で実際に管理されるボリュームの総容量に相当します。ただし、FlexVol はデータストアとは構造が異なるため、完全な対応ではありません。 ※ Aggregate 上の物理容量消費はこれらとは別の話になるため、本記事では扱いません。 ※ OpenShift/Kubernetes では GiB を Gi と表記します。本記事では CLI 出力の引用を除き GiB で統一します。 検証環境 この記事を作る上で、お借りした NetApp 機器を OpenShift クラスタに接続した検証環境を構築して動作を確認しました。以下には環境情報を記載します。 NetApp 機器および Trident 項目 値 ストレージモデル NetApp AFF C190 x 2（HA ペア） ONTAP バージョン 9.18.1P2 Trident バージョン 26.02 ディスク SSD x 12 本（モデル: X382_S1643960ATE / 894.3GB） SVM svm-openshift （両ノードのアグリゲートを使用） ネットワーク 10GbE x 4 OpenShift クラスタ 項目 値 OpenShift バージョン 4.22.0 OpenShift Virtualization バージョン 4.22.2 Control Plane Node 3 x 仮想マシン（8vCPU, 24Gi RAM） Compute Node 3 x ベアメタルマシン（8c/16t CPU, 64Gi RAM） ネットワーク ネットワーク接続は以下（All 10GbE, MTU=9000） ざっくりネットワーク図 注意：Trident バージョンについて 本記事（第1回〜第3回）の検証環境では Trident 26.02 を使用していますが、Trident 26.02 は OpenShift 4.22 を公式にはサポートしていません。検証の範囲では動作に影響はありませんでしたが、私の不注意をお詫び申し上げます。実際に環境を構築される際は、必ず Trident のサポートマトリクス を確認し、お使いの OpenShift バージョンに対応した Trident バージョンを使用してください。 VMware の容量管理を振り返る VMware vSphere の世界では、VM のディスク容量は比較的シンプルでした。VMDK ファイルのサイズ = VM のディスク容量。vSphere Client から見えるプロビジョニングサイズがそのまま VM の容量……と思いきや、実はそこまで単純でもなかったですよね。 Thin Provisioning にすれば、VMDK の論理サイズと VMFS/NFS データストア上の実消費量は一致しない vSphere Snapshot を取ると、差分ファイル（delta VMDK）がデータストア上に作られ、実消費量がどんどん増えていく データストアの空き容量を監視していないと、Snapshot の蓄積でデータストアが満杯になり、VM が停止する つまり VMware でも「VM ディスクサイズ = 実際のストレージ消費量」ではなかったわけです。 OpenShift Virtualization（以下 Virt）+ ONTAP でも同じ問題は存在します。ただし、容量のオーバーヘッドが発生するレイヤーが異なります。VMware では VMFS データストア上で VMDK と差分ファイルが管理されていましたが、Virt + ONTAP では PVC（Kubernetes のストレージリソース）と FlexVol（ONTAP のボリューム）の2つのレイヤーで容量が決まります。そして、ドライバが ontap-nas か ontap-san かによって、オーバーヘッドの種類と大きさが変わるのです。 「同じ 500GiB で DataVolume を作ったはずなのに、PVC のサイズが違う」「OpenShift と ONTAP で容量の数字が合わない」……こういう場面に遭遇したことはないでしょうか。順番に見ていきましょう。 ONTAP / Trident 側の設定 今回の検証では、同一の SVM ( svm-openshift ) 上に ontap-nas と ontap-san の両方の TridentBackendConfig （TBC）を構成しています。どちらも Trident の公式ドキュメントのサンプル構成に合わせた設定です。 ontap-san の TBC（抜粋）: defaults : snapshotPolicy : default snapshotReserve : "10" spaceReserve : volume spaceAllocation : "true" ontap-nas の TBC（抜粋）: defaults : snapshotPolicy : default snapshotReserve : "10" spaceReserve : none provisioningType : thin どちらも snapshotPolicy: default 、 snapshotReserve: "10" で揃えています。 snapshotPolicy: default は、ONTAP にあらかじめ用意されている default Snapshot policy を適用する設定です。VMware では vSphere Client から手動で Snapshot を取得するか、バックアップソフトで自動化するのが一般的でしたが、ONTAP ではストレージ側でスケジュールに従って自動的に Snapshot が取得されます。このポリシーでは3つのスケジュールで自動取得されます。今回の検証環境（ONTAP 9.18.1P2）で確認したスケジュールは以下の通りです。 スケジュール タイミング 保持世代数 hourly 毎時 5 分 6 daily 毎日 0:10 2 weekly 毎週日曜 0:15 2 つまり、常時最大 10 世代分の Snapshot が FlexVol 上に保持されることになります。 snapshotReserve: "10" は、FlexVol の総容量のうち 10% を Snapshot 用の予約領域として確保する設定です。VMware では、vSphere Snapshot の差分ファイルがデータストアの空き領域をそのまま消費していたため、「いつの間にかデータストアが満杯」になるリスクがありました。ONTAP の Snapshot reserve はこの問題に対する仕組みで、Snapshot のデータ用にあらかじめ領域を確保しておくことで、ユーザーデータの領域を圧迫するのを防ぎます。 つまりこの構成では、ONTAP が自動的に Snapshot を取りつつ、その分の領域も FlexVol の中にあらかじめ確保しておく、というわけです。この snapshotReserve の存在が、後述する FlexVol のサイズ計算に効いてきます。 Tips：Thin と Thick はどこで決まるのか VMware でも Thin Provisioning / Thick Provisioning（Lazy Zeroed / Eager Zeroed）を VMDK の作成時に選べましたが、ONTAP + Trident でも同様に Thin / Thick の選択が可能です。ただし設定箇所が2つあります。 設定箇所 パラメータ Thin Thick TridentBackendConfig spaceReserve none volume StorageClass .parameters.provisioningType thin thick 両方に設定がある場合は StorageClass 側が優先されます。 TBC はバックエンド全体のデフォルト、 StorageClass は PVC 単位の上書きと考えるとわかりやすいです。 Trident のデフォルトは Thin です。Thick を選ぶのは、容量の確保を保証したい場合や、性能のばらつきを抑えたい場合が主なユースケースになります。 VM の設定 VM は以下の構成で2台作成しました。 rhel10-ontap-san rhel10-ontap-nas OS RHEL 10 RHEL 10 rootdisk (30GiB) ontap-san ontap-san datadisk (500GiB) ontap-san ontap-nas 注目すべきは datadisk です。同じ 500GiB を DataVolumeTemplate で要求していますが、 StorageClass が異なります。 PVC の Capacity を覗く : FS オーバーヘッドという新しい概念 まず、OpenShift 側から PVC の状態を確認してみましょう。 $ oc get pvc -n utubo-test -o custom-columns=NAME:.metadata.name,CAPACITY:.status.capacity.storage,STORAGECLASS:.spec.storageClassName NAME CAPACITY STORAGECLASS rhel10-ontap-san-datadisk 500Gi ontap-san rhel10-ontap-nas-datadisk 530Gi ontap-nas rhel10-ontap-san-rootdisk 30Gi ontap-san rhel10-ontap-nas-rootdisk 30Gi ontap-san 同じ 500GiB を要求しているのに、 ontap-nas の datadisk は 530GiB になっています。6% 増えていますね。 これは snapshotReserve のせいではありません。 原因は KubeVirt のファイルシステムオーバーヘッド です。 VMware では、VMDK ファイルがそのまま VM のディスクでした。VMDK 自体にはファイルシステムのメタデータのようなオーバーヘッドはありません（データストアの VMFS メタデータは別ですが、個々の VMDK のサイズには影響しません）。しかし Virt では事情が異なります。 ontap-nas は NFS ベースなので volumeMode: Filesystem で PVC を作成します。VM ディスクをファイルシステム上のイメージファイルとして格納するため、ファイルシステム自体のメタデータ（inode、ジャーナル等）が一定の領域を消費します。この消費分を見越して、Virt（CDI）は PVC のプロビジョニング容量を自動的に増やすことで、要求したディスクサイズ分の利用可能容量を確保します。つまり、ファイルシステムオーバーヘッドは snapshotReserve のような専用の予約パーティションではなく、プロビジョニング時にサイズを上乗せする仕組みです。 今回の検証環境（OpenShift Virtualization 4.22.2）では、このオーバーヘッドは 6% です。ただし、この値は CDI の CDIConfig CR（ spec.filesystemOverhead.global ）に基づいており、バージョンによって異なる場合があります（過去のバージョンでは 5.5% だった時期もあります）。 ONTAP に限らず、他の NAS でも NFS サーバでも、 volumeMode: Filesystem で仮想ディスクを作ると、このオーバーヘッドによる容量の上乗せは発生します。 PVC Capacity = 要求サイズ x (1 + オーバーヘッド率) = 500GiB x 1.06 = 530GiB ← 今回の検証環境の場合 一方、 ontap-san はブロックベースなので volumeMode: Block です。ブロックデバイスにはファイルシステム層がないため、このオーバーヘッドは発生せず、PVC は要求通り 500GiB になります。 ここがまず1つ目の差分です。OpenShift のダッシュボードから見ると、 ontap-nas の方が 30GiB 多くストレージを使っているように見えますが、これはファイルシステムオーバーヘッドの分であり、VM ディスク容量はどちらも 500GiB で同じです。VMware で言えば、VMDK のサイズは同じだけど、データストア側の管理領域の取り方が違う、というイメージに近いです。 PVC は 530GiB でも OS で見えるのは 500GiB ONTAP を覗く : Snapshot reserve は VMFS ではなく FlexVol の中にある VMware では、Snapshot の差分データはデータストア上の VMDK と同じ場所（同じデータストア内）に保存されていました。複数の VM が Snapshot を持つと、データストア全体の空き容量が圧迫されます。 ONTAP では話が違います。 Snapshot は FlexVol レベルで管理されます。 ontap-nas では1つの PVC = 1つの FlexVol なので、Snapshot の影響範囲はその FlexVol の中に閉じています。VMware のように「隣の VM の Snapshot のせいでデータストアが溢れた」ということは構造的に起きません。 それぞれのディスクに紐づく FlexVol を見てみる では、ONTAP 側の実態はどうなっているでしょうか。SVM に SSH でログインして、FlexVol の中身を確認してみましょう。 svm-openshift::> volume show -fields size,available,percent-snapshot-space,snapshot-policy vserver volume size available percent-snapshot-space snapshot-policy ------------- ------------------- -------- ---------- ---------------------- --------------- svm-openshift trident_pvc_69f5.. 611.1GB 550.0GB 10% default ← ontap-san svm-openshift trident_pvc_3af5.. 588.9GB 530.0GB 10% default ← ontap-nas ※ ONTAP CLI は容量の単位を GB と表示しますが、内部的には binary ベース（GiB 相当）の値です。本記事では以降 GiB と表記します。 ここで面白い逆転現象が起きています。OpenShift 側では ontap-nas の PVC の方が大きかったのに、ONTAP 側の FlexVol は ontap-san の方が大きいんです。 整理するとこうなります。 ontap-nas (datadisk) ontap-san (datadisk) DataVolume 要求サイズ 500GiB 500GiB volumeMode Filesystem Block FS オーバーヘッド (6%) あり なし PVC Capacity 530GiB 500GiB FlexVol サイズ 588.9GiB 611.1GiB FlexVol Available 530.0GiB 550.0GiB percent-snapshot-space 10% 10% snapshot-policy default default なぜ FlexVol のサイズが逆転するのか ontap-nas の場合： NAS ドライバでは PVC = FlexVol です。PVC Capacity が 530GiB なので、Trident はここに snapshotReserve 10% を上乗せして FlexVol を作成します。 FlexVol サイズ = PVC Capacity / (1 - snapshotReserve% / 100) = 530GiB / (1 - 0.10) = 588.9GiB ontap-san の場合： SAN ドライバでは、FlexVol の中に LUN が作成されます。PVC Capacity は 500GiB（= LUN のサイズ）ですが、FlexVol にはさらに上乗せが加わります。ステップごとに見てみましょう。 LUN 容量：500GiB LUN メタデータ +10%：500GiB x 1.1 = 550GiB（Trident が自動的に追加） Snapshot reserve 10% を含む FlexVol 総容量：550GiB / 0.9 = 611.1GiB うち Snapshot reserve 相当：約 61.1GiB FlexVol サイズ = (LUN 容量 x 1.1) / (1 - snapshotReserve% / 100) = (500GiB x 1.1) / (1 - 0.10) = 550GiB / 0.9 = 611.1GiB ポイントは、 Snapshot reserve は LUN メタデータを加算した後の 550GiB を利用可能容量として確保したうえで、FlexVol 全体の 10% が Snapshot reserve になるよう算出される という点です。つまり、550GiB が FlexVol の 90% (100%-10%) となるように計算されて FlexVol の容量が決まります。 ontap-san は LUN メタデータ分の +10% が必要なため、 ontap-nas よりも FlexVol が大きくなります。なお、この +10% 分は LUN メタデータ専用に固定される領域ではなく、メタデータの実際の消費量に応じて余剰分はデータ側でも利用できます。逆にメタデータ消費が多ければ、利用可能なデータ領域が減る可能性もあります。 図にするとこんな具合になります。 FlexVol の中の容量内訳 ontap-nas は「VM イメージ + FS メタデータ + Snapshot reserve」の3層構造。 ontap-san は「LUN + LUN メタデータ + Snapshot reserve」の3層構造。どちらも3層ですが、オーバーヘッドの種類と大きさが異なります。 VMware に置き換えて考えると、VMware では「VMDK + Snapshot 差分」の2層で、両方ともデータストアという同じ空間の中にあったのに対し、ONTAP では FlexVol の中に明確な予約領域（Snapshot reserve）が設けられている、という違いがあります。 容量消費の全体像 500GiB の VM データディスクを作成した場合の容量消費をまとめます。 積み上げ項目 ontap-nas ontap-san VM ディスク容量 500GiB 500GiB FS オーバーヘッド (6%) +30GiB なし（Block モード） PVC Capacity 530GiB 500GiB LUN メタデータ (+10%) なし +50GiB snapshotReserve (10%) +58.9GiB +61.1GiB FlexVol サイズ（論理容量） 588.9GiB 611.1GiB ポイントをまとめると： OpenShift の PVC で見ると、 ontap-nas の方が 30GiB 大きい → KubeVirt の FS オーバーヘッド（6%）が原因 ONTAP の FlexVol で見ると、 ontap-san の方が FlexVol の論理容量で 22.2GiB 大きい → LUN メタデータ（+10%）が原因 VM ディスク容量はどちらも 500GiB で同じ OpenShift のダッシュボードだけ見て「 ontap-nas の方がストレージ食ってるな」と思うかもしれませんが、 正確な容量管理のためには、ONTAP 側の FlexVol サイズも合わせて確認することをおすすめします。 VMware では vCenter の「使用済みストレージ」列で把握できていた情報が、Virt + ONTAP では2つのレイヤー（OpenShift の PVC と ONTAP の FlexVol）に分かれている点に注意が必要です。容量の監視方法については、第8回「監視と運用」で詳しく扱います。 なお、上記の FlexVol サイズはあくまで論理容量です。Aggregate 上で実際に消費される物理容量は、Thin Provisioning や ONTAP の容量効率化機能（圧縮・重複排除など）の影響を受けるため、FlexVol の論理容量とは一致しません。実際の物理容量消費を把握するには、Aggregate 側の使用状況を確認する必要があります。 おまけ： snapshotReserve を設定しないとどうなるか ちなみに、TBC で snapshotPolicy: none を設定し snapshotReserve を設定しないと何が起きるでしょうか。Trident の仕様では、 snapshotPolicy が none の場合、 snapshotReserve は自動的に 0% になります（ 公式 FAQ 参照）。 この状態で ontap-san の PVC を作ると、FlexVol には LUN メタデータ分の +10% しか上乗せされず、Snapshot reserve 領域は一切確保されません。Snapshot を取らない前提であれば問題ありませんが、CSI Snapshot 機能や ONTAP 側の運用で Snapshot を活用する場合は要注意です。 snapshotReserve が不足した状態で Snapshot が蓄積すると、FlexVol のユーザー領域を圧迫し、最悪の場合 LUN がオフラインになる リスクがあります。関連する事例として Trident GitHub Issue #554 も参考になります。 VMware でも同じようなリスクはありました。vSphere Snapshot を削除し忘れてデータストアを圧迫するのは、VMware 管理者なら一度は経験したことがあるのではないでしょうか。ONTAP の Snapshot reserve は、まさにこの「Snapshot の蓄積によるストレージ枯渇」を防ぐための仕組みです。 公式ドキュメントのサンプル でも ontap-san の TBC には snapshotPolicy: default と snapshotReserve: "10" が設定されています。明確にバックアップの世代数と変更差分がわかっていて 10% も使わないとわかっていれば snapshotReserve を減らすことは全然いいと思います。が、分からない場合はデフォルトに倣っておくのが妥当です。 ただし、 snapshotReserve: "10" でも万全とは限りません。データの変更量が大きいワークロードや、Snapshot の保持世代数を増やした場合、保持期間が長い場合には 10% を超過する可能性があります。Snapshot reserve が溢れた場合の実例は、第3回「性能設計」で紹介します。環境に応じて snapshotReserve の値を見直すことも検討してください。 Tips：Snapshot reserve の使用状況を確認するには Snapshot reserve が足りているかどうかは、ONTAP CLI で定期的に確認できます。 svm-openshift::> volume show -fields snapshot-space-used,snapshot-reserve-size snapshot-space-used が 100% に近づいている、または超過している場合は、Snapshot reserve の拡大や Snapshot の保持ポリシーの見直しを検討してください。Snapshot reserve を超過すると Snapshot のデータがユーザー領域を消費し始めるため、早めの対処が重要です。 容量の定常的な監視方法については、第8回「監視と運用」で詳しく扱います。 まとめ VMware vSphere からの移行で押さえておくべき容量設計のポイントをまとめます。 VMware との違い： VMware では VMDK サイズ = VM ディスクの論理容量で、Snapshot の差分はデータストア上に直接蓄積されていた Virt + ONTAP では、VM ディスクサイズの上に FS オーバーヘッド（ ontap-nas の場合）や LUN メタデータ（ ontap-san の場合）、さらに Snapshot reserve が積み上がり、FlexVol の論理容量が決まる 容量の確認先が2箇所に分かれる（OpenShift の PVC と ONTAP の FlexVol）。VMware の vCenter のように1画面で完結しないため、両方を見る習慣が必要 ontap-nas と ontap-san の違い： PVC が大きく見えるのは ontap-nas → KubeVirt の FS オーバーヘッド（6%）のせい。VM ディスク容量は変わらない FlexVol が大きくなるのは ontap-san → LUN メタデータ（+10%）のせい。FlexVol の論理容量はこちらの方が大きい。ただし実際の物理容量消費は Aggregate 側の確認が必要 snapshotReserve は明示的に設定しておく → Snapshot を使わないなら snapshotPolicy: none で 0% になるが、使うなら公式サンプルに倣って snapshotReserve: "10" がひとまず妥当。ただしワークロードによっては 10% でも不足する場合がある（第3回で実例を紹介） OpenShift の PVC の数字と ONTAP FlexVol の実態は必ずしも一致しません。「なんか容量が合わないな？」と思ったら、PVC だけでなく ONTAP 側の FlexVol サイズも確認してみてくださいね。 というわけで今日はここまで。次回の第3回では、 ontap-nas と ontap-san の性能差を fio で測定した結果を紹介します。

レッドハットのチーフアーキテクト駒澤です。この記事は、日々の業務でサイバーセキュリティ情報の収集、CVE情報の追跡、パッチ適用などで大忙しの、セキュリティ担当者の皆さまに向けた内容です。 レッドハットがオープンソースのセキュリティ対策にどのような貢献をしているかをお伝えしたいと思い、本記事を書きました。 急増する脆弱性と、見落とされる「オープンソースの隙間」 今年においては、AIを活用した脆弱性発見技術の進化により、脆弱性の公表件数は昨年の2倍以上へと急増しています。しかし、セキュリティの現場を悩ませているのは件数の多さだけではありません。真に深刻なのは、「依存しているオープンソース（OSS）ライブラリに脆弱性が見つかっても、CVE-IDが発行されず、修正パッチも存在しないまま放置されてしまうケース」です。 商用ソフトウェアであれば自社CNA（CVE Numbering Authority: CVE採番機関）が責任を持って採番し、修正を提供します。しかし、ボランティアの手が離れた小規模なOSSや、開発元がCNA資格を持たないライブラリでは、脆弱性が報告されても窓口がなく、リスクが水面下に潜んだままサプライチェーン全体へと広がってしまうリスクがあります。 「CNA-LR（CNA of Last Resort）」とは何か？ 皆さんは、CNA-LRという存在をご存知でしょうか？ CNAについては、世界中でMicrosoft、Apple、Google、Red Hatなどの主要ITベンダーをはじめ、日本国内でも任天堂、日立、キヤノン、サイボウズ、JPCERT/CCなど数百の組織がCNAとして加盟・活動しています。 通常、CVE-IDは開発元自身が採番・公表します。しかし、開発元がCNAではなく対応体制がない場合や、報告への対応が放置された場合、あるいは脆弱性の有無を巡って対立（Dispute）が生じた際に、「最後の砦」として中立な立場から介入し、CVE-IDを発行・公表する組織がCNA-LRです。 こうした「採番の空白地帯」をなくすためにCVEプログラム（MITRE運営）が整備した仕組みが、CNA-LR（CNA of Last Resort：最後の砦となる採番機関）です。 Red Hatは、オープンソースコミュニティを管轄する「Root（上位統括機関）」であると同時に、このCNA-LRとしての重責を担っています。 長年にわたりLinuxカーネルをはじめとするアップストリーム（上流）にコミットしてきた知見を活かし、どこにも頼る先がないオープンソース脆弱性を救い上げ、正確なメタデータ（CVSS、CWE、CPE情報）を整備して世界中に公開するセーフティネットの役割を果たしています。 Red Hat「Lightwell」：未知の脆弱性修復からコミュニティ還元までを担うクリアリングハウス 上流でCVEを付与してリスクを可視化することは極めて重要ですが、企業の現場が真に必要としているのは「実際に使える修正パッチ」です。 そこでRed Hatが提供しているのが、OSSライブラリの修復サービス「Lightwell」です。 Lightwellは、単なるパッチ配布にとどまらず、オープンソースの脆弱性に対する包括的なクリアリングハウス（調整・仲介組織）として機能します。 Lightwellを導入することで企業は以下のメリットを受けることができます。 未知の脆弱性（ゼロデイ）への直接対応: 既知のCVEだけでなく、まだ公になっていない潜在的・未知の脆弱性に対しても、Red Hatの専門チームが解析を行い、安全な修正コード（バックポートや修正パッチ）を迅速に提供します。 アップストリーム（オープンソースコミュニティ）への還元: Lightwellは修正を自社内に囲い込みません。作成した修正パッチを元のオープンソースプロジェクトへフィードバックし、コミュニティの健全な発展を支えます。 CNA-LRと連携したCVE公開・開示調整: Lightwellが修正した脆弱性について、必要に応じてRed HatのCNA-LR権限を通じて正式なCVE-IDを採番・公開し、安全で責任ある開示の調整を完結させます。 セキュリティ担当者・エンジニアにとっての3つの実務メリット Red Hatが「CNA-LR」としてエコシステムを支え、同時に「Lightwell」を提供していることは、日々のセキュリティ業務に次のような安心をもたらします。 SBOM（ソフトウェア部品表）や脆弱性スキャナーの「すり抜け」を防ぐ 依存ライブラリにCVEが割り当てられていなければ、どれほど優れたスキャナーを導入していても検知できません。Red Hatが上流でCVEを付与することで、サプライチェーンの盲点をなくします。 「脆弱性が見つかったが直せない」という手詰まりの解消 アップストリームでの公式パッチ提供が滞っているライブラリであっても、Lightwellを通じて安全な修復が適用可能になり、システム停止や強引なライブラリ置換のリスクを回避できます。 正確なメタデータによるトリアージ工数の削減 Red Hatが審査・修復に関わることで、影響範囲や悪用可能性の判断材料が高精度に整い、現場での優先度判断（トリアージ）が格段にスムーズになります。 おわりに：持続可能なオープンソースセキュリティを目指して オープンソースソフトウェアは、現代のあらゆるIT基盤・クラウドインフラの土台です。その土台を安全に保つには、コードの活用だけでなく、脆弱性情報を透明に流通させ、修正をコミュニティ全体に還元していく循環が不可欠です。 Red Hatは、「CNA-LR」として脆弱性の放置を防ぐ盾となり、「Lightwell」として未知の脅威を修復しエコシステムを発展させる推進力となって、世界中のソフトウェアサプライチェーンの安全を守り続けます。 社内のオープンソース活用における依存関係ライブラリの管理や、脆弱性対策でお困りの際は、ぜひRed HatのセキュリティソリューションおよびLightwellの取り組みにご注目ください。 参考情報： Red Hat is now a CVE Numbering Authority of Last Resort in the CVE Program アプリの脆弱性対応を改善する、Lightwellのご紹介 - 赤帽エンジニアブログ

皆さんこんにちは。OpenShift Virtualization とストレージを生業にしている Red Hat のうつぼ（宇都宮）です。 今回から NetApp コラボ特集シリーズを始めます。それは NetApp 様のご厚意によって機器をお貸し出しいただけることになり、私の OpenShift 環境で様々な検証をさせていただけるようになったからです。 NetApp 様に心より御礼申し上げます。ありがとうございます！ これから全 8 回にわたり、お貸し出しいただいた NetApp AFF を使った検証をベースに OpenShift Virtualization + NetApp Trident の特集をお届けします。 回 テーマ 第1回（本記事） ストレージ基本設計、Trident のドライバ選定 第2回 容量設計 第3回 性能設計 第4回 VM 移行（Shift Toolkit） 第5回 マルチテナント設計 第6回 データ保護 第7回 DR 設計 第8回 監視と運用 お付き合いいただけると幸いです。 ということで、今日のテーマは手始めに "OpenShift Virtualization + NetApp Trident で選ぶべきストレージドライバ" です。 検証環境 VMware 管理者にとってのストレージ選択 そもそも NetApp Trident とは NAS 系と SAN 系 Virt でサポートされる ONTAP ドライバ ontap-nas ontap-san ontap-san-economy 仮想ディスクの置き場としてどれを選ぶべきか まとめ ※ 以降、社名は敬称略とさせていただきます。ご容赦ください。 検証環境 この記事を作る上で、お借りした NetApp 機器を OpenShift クラスタに接続した検証環境を構築して動作を確認しました。以下には環境情報を記載します。 NetApp 機器および Trident 項目 値 ストレージモデル NetApp AFF C190 x 2（HA ペア） ONTAP バージョン 9.18.1P2 Trident バージョン 26.02 ディスク SSD x 12 本（モデル: X382_S1643960ATE / 894.3GB） SVM svm-openshift （両ノードのアグリゲートを使用） ネットワーク 10GbE x 4 OpenShift クラスタ 項目 値 OpenShift バージョン 4.22.0 OpenShift Virtualization バージョン 4.22.2 Control Plane Node 3 x 仮想マシン（8vCPU, 24Gi RAM） Compute Node 3 x ベアメタルマシン（8c/16t CPU, 64Gi RAM） ネットワーク ネットワーク接続は以下（All 10GbE, MTU=9000） ざっくりネットワーク図 注意：Trident バージョンについて 本記事（第1回〜第3回）の検証環境では Trident 26.02 を使用していますが、Trident 26.02 は OpenShift 4.22 を公式にはサポートしていません。検証の範囲では動作に影響はありませんでしたが、私の不注意をお詫び申し上げます。実際に環境を構築される際は、必ず Trident のサポートマトリクス を確認し、お使いの OpenShift バージョンに対応した Trident バージョンを使用してください。 VMware 管理者にとってのストレージ選択 この記事シリーズは「VMware で実現できていた運用を、OpenShift Virtualization ではどう実現するか」を軸に書いていきます。 VMware からの移行を検討されている方にも、新規に OpenShift Virtualization を導入される方にも参考になるよう、VMware での考え方との対比を挟みながら進めます。 さて、VMware 管理者の皆さんにとって、ストレージの基本設計で最初に考えることは何だったでしょうか。 データストアを NFS にするか、VMFS（iSCSI / FC）にするかですよね。 NFS データストア : ESXi から NFS マウントするだけでデータストアとして使える。構成がシンプルで、ONTAP 側でのボリューム管理も容易。 VMFS データストア（iSCSI / FC） : LUN をフォーマットして VMFS を載せる形。ブロックレベルのアクセスで、低レイテンシが求められるワークロードで好まれる。 どちらを選ぶかは、既存のネットワーク構成、性能要件、運用チームのスキルセットで決まっていたのではないでしょうか。 OpenShift Virtualization に来ると、Trident のストレージドライバがこの「データストアのタイプ選択」に相当する役割を担います。NFS で VM ディスクを提供するか、iSCSI / FC でブロックとして提供するかを、ストレージドライバの選択で決めるわけです。 この記事では、VMware でのデータストア選択の考え方と対比しながら、Trident のストレージドライバの種類と選び方を整理していきます。 そもそも NetApp Trident とは VMware からの移行のご相談をいただく中で、移行先のストレージに NetApp の FAS/AFF を使いたい、というお客様は少なくありません。 NetApp FAS/AFF は VMware 環境で最もよく使われるストレージの一つなので、同じ系統のストレージを継続して使いたいというのは極めて自然なことです。 VMware 環境では、ESXi がネイティブに NFS クライアントや iSCSI イニシエータを持っていて、データストアを直接マウントしていました。追加のソフトウェアが必要になるのは、VAAI プラグイン（ONTAP tools for VMware）くらいだったと思います。 OpenShift Virtualization（以下 Virt）の世界では事情が違います。OpenShift 環境で NetApp FAS/AFF を使うには NetApp Trident（旧称 Astra Trident）が必要です。 NetApp Trident（以下 Trident）は NetApp が提供するオープンソースの CSI ドライバです。CSI ドライバ以外にも様々な機能があるのですが、OpenShift/Kubernetes から NetApp の ONTAP（FAS/AFF/ASA/Cloud Volumes ONTAP/FSx for ONTAP 等を含む）や他のストレージを動的にプロビジョニングできるようにしてくれる、ストレージプロビジョナーです。 VMware でいえば、「ESXi のデータストア管理 + VAAI + ストレージプロビジョニング」を Kubernetes のお作法に合わせて一手に引き受けてくれるもの、と思っていただくとイメージしやすいかもしれません。 docs.netapp.com Trident では "バックエンド（backend）" という単位でストレージ接続先を定義します。バックエンドには OpenShift に接続する StorageVM（SVM）の情報やストレージドライバの指定を含みます。 VMware でいうと、「どのストレージのどのボリュームをデータストアとしてマウントするか」を定義していたのと同じ感覚です。ただし Trident ではプロビジョニングも動的に行うため、「接続先 + 自動作成のルール」をまとめて定義する形になっています。 実際にバックエンドを作るときは、 TridentBackendConfig （TBC）というカスタムリソースを作成します。すると Trident が裏で実体である TridentBackend というカスタムリソースを作り、これがバックエンドを定義してくれる形になっています。 （※古くからある tridentctl という専用 CLI に JSON を食わせて作る方法もあり、これを使うことももちろんできます。両者を行き来することもできます。） 1 つの Trident には複数のバックエンドを登録できます。なので、複数の SVM を使い分けたり、単一の SVM で使い分けたり、用途に応じて StorageClass を作り分けることができます。VMware でいう「NFS データストアと VMFS データストアを並行して使う」「チームごとにデータストアを分ける」といった運用が、バックエンドと StorageClass の組み合わせで実現できるわけです。 なお、SVM を使ったマルチテナント設計（チームごとの分離、ストレージティアの割り当てなど）については、第5回で詳しく扱います。 TBC のサンプルはこのような具合です。 apiVersion : trident.netapp.io/v1 kind : TridentBackendConfig metadata : name : tbc-ontap-san namespace : trident spec : credentials : name : ontap-svm-openshift-secret defaults : snapshotPolicy : default spaceReserve : none managementLIF : 192.168.124.103 sanType : iscsi storageDriverName : ontap-san svm : svm-openshift version : 1 svm に対象とする SVM を指定し、 credentials にはその SVM の認証情報を格納した Secret を指定します。 managementLIF は Trident が ONTAP を管理するためのエンドポイントで、SVM 管理 LIF でもクラスタ管理 LIF でもどちらでも指定できます。どちらを指定しても、ボリュームが実際に作られるのは svm で指定した SVM です。 で、ここで立ち止まるポイントが、さっきサラッと流した "ストレージドライバ" です。上のサンプルでは storageDriverName: ontap-san と指定されているところです。 Trident は、接続するストレージプラットフォーム（ONTAP、各社パブリッククラウドのマネージドサービス）や、使用するプロトコル（NAS、SAN）に合わせて、複数のストレージドライバを提供しています。 *1 このドライバがたくさんあって、何が違ってどう使い分けるべきなのか？が最初は分からないところだと思います。ということで Virt でサポートされている ONTAP ドライバに絞って紹介していきます。 NAS 系と SAN 系 細かいドライバの前に、ONTAP 向けのドライバはまず NAS 系と SAN 系に分かれます。 VMware 管理者の方にはなじみ深い区分だと思います。VMware でも NFS データストアと VMFS データストア（iSCSI/FC）で大きくアーキテクチャが異なっていました。Trident でも同様に、NAS 系と SAN 系で PV のプロビジョニング方式が変わります。 NAS 系（ ontap-nas* ） : NFS（あるいは SMB）でファイルとしてマウントします。PV は ONTAP の FlexVol として作られます。OpenShift 目線では Pod にファイルシステムをそのままマウントする形です。 VMware でいえば NFS データストアに VMDK を置くのと同じ感覚で、ストレージ側のボリュームをそのままファイルシステムとして見せます。 SAN 系（ ontap-san* ） : iSCSI / FC / NVMe/TCP でブロックデバイスとしてアタッチします。PV は ONTAP の LUN として作られます。OpenShift 目線では Pod にブロックデバイスが生えてくる形です。 VMware でいえば VMFS データストア上の VMDK、あるいは RDM（Raw Device Mapping）に近い形で、ブロックレベルでストレージにアクセスします。 「じゃあどっちがいいの？」という話ですが、大抵の用途はどっちでも動くけど、要件によって向き不向きがあるという感じです。VMware でも「NFS と VMFS どちらがいいか」は永遠のテーマだったと思いますが、Virt でも同じ議論があり、特に後述する理由で、この NAS/SAN の選択がわりと効いてきます。 Virt でサポートされる ONTAP ドライバ Trident には ONTAP 向けのドライバが ontap-nas 、 ontap-nas-economy 、 ontap-nas-flexgroup 、 ontap-san 、 ontap-san-economy の 5 種類ありますが、 すべてが Virt で正式にサポートされているわけではありません 。 次のリンク先にもある通り、 Trident 26.x で Virt の正式サポート対象は以下の 3 つ です。「Trident に存在するドライバ」と「Virt で正式サポートされるドライバ」は別の話なので、ここは注意してください。それぞれ見ていきます。 docs.netapp.com ontap-nas プロビジョニング単位 : PV 1 つにつき FlexVol 1 つ プロトコル : NFS, SMB 特徴 : 一番オーソドックスな NAS ドライバです。PV ごとに独立した FlexVol が作られるので、ONTAP の機能（Snapshot、Clone、QoS、レプリケーション等）をボリューム単位でフルに享受できます。 VMware でいえば、NFS データストアに VMDK を置いていた運用に最も近い形です。NFS データストアを使っていた環境であれば、この ontap-nas が一番なじみやすいでしょう。ONTAP 側のボリューム管理（Snapshot、レプリケーション等）も VMware 時代とほぼ同じ操作感で行えます。 用途 : 迷ったらまずこれ。特に理由がなければ Virt でもこれが第一候補になりやすいです。 ontap-san プロビジョニング単位 : PV 1 つにつき LUN 1 つ（その LUN 専用の FlexVol の中に作られる） プロトコル : iSCSI, FC, NVMe/TCP 特徴 : ブロックストレージ用途の王道ドライバです。PV ごとに独立した LUN で、Snapshot や Clone がボリューム単位で効きます。 volumeMode: Block との相性がよく、Virt の仮想ディスク向けの筆頭です。 VMware でいえば、VMFS データストアや RDM を使っていた運用に近い形です。iSCSI や FC で接続し、LUN をブロックデバイスとして提供します。「VMware では iSCSI SAN で運用していた」という環境であれば、 ontap-san が自然な選択肢になります。 用途 : ブロックで見せたい場合。低レイテンシが欲しい、SCSI コマンドを使いたい、みたいなケース。 補足: VMware でいう RDM のように VM にブロックデバイスを直接見せたいときも、出元はこの手のブロックストレージです。ただし厳密には volumeMode とディスクのタイプは別の軸なので、RDM と完全に同じではありません。詳しくは ディスクの種類の記事 を参照してください。 ontap-san-economy プロビジョニング単位 : PV 1 つにつき LUN（1 つの FlexVol に複数 LUN を詰める） プロトコル : iSCSI 特徴 : ontap-san のスケーラビリティ強化版です。1 つの FlexVol に複数の LUN を詰めることで、FlexVol 数の上限を超えて大量の PV を作れます。Snapshot や Clone は使えますが、PV 単位の QoS やレプリケーションには制約があります。 VMware でいえば、1 つの大きな VMFS データストアに多数の VMDK を詰め込む運用に近い考え方です。スケーラビリティは高いですが、個別の VMDK（PV）単位での細かい制御には限界がある、という点も似ています。 用途 : iSCSI を使用し、必要な PV 数が FlexVol 数の上限を超える場合に検討してください。 補足: ontap-san では CSI Snapshot は FlexVol の Volume Snapshot（ポイントインタイムコピー）として作られますが、 ontap-san-economy では 1 つの FlexVol に複数 LUN が同居しているため、対象 LUN の FlexClone LUN として作られます。"Clone" という名前ですが、WAFL のブロック共有によるほぼ瞬時の空間効率的なコピーであり、フルコピーではありません。きちんと Snapshot と同様に動作します。（参考: Volume snapshots - Trident documentation ） 以上 3 つのストレージドライバを一覧にするとこんな感じです。VMware でのデータストアとの対応関係も併記します。 ドライバ 系統 PV の実体 Snapshot/Clone/DR VMware での近い構成 ざっくり用途 ontap-nas NAS FlexVol フル対応 NFS データストア + VMDK 迷ったらこれ ontap-san SAN LUN フル対応 VMFS データストア / RDM ブロックで使いたい ontap-san-economy SAN 複数 LUN/FlexVol 一部制約あり 大容量 VMFS に多数 VMDK ブロックで大量 PV なお FlexVol や LUN の上限値は ONTAP のバージョンや FAS/AFF のモデル・搭載メモリによって変わります。正確な数字はご自身の環境（モデル + ONTAP バージョン）で NetApp Hardware Universe（HWU）を確認してください。 https://hwu.netapp.com/ 仮想ディスクの置き場としてどれを選ぶべきか それでは、Virt で使う場合にどのドライバを使うべきか。 VMware では、NFS と VMFS のどちらを選んでも vMotion（Live migration）はできていました。NFS データストアでも VMFS データストアでも、vMotion は ESXi 側が透過的に処理してくれていたからです。 Virt でも Live migration は同様に重要ですが、ストレージ側の要件が少し異なります。 Virt では VM の Live migration をやりたいので、 PVC が ReadWriteMany （RWX）の AccessMode に対応していること が最重要になります。Virt の Live migration はディスクを引き渡すタイミングで移行元ノードと移行先ノードの両方から同じディスクにアクセスするため、どうしても RWX が必要になります。 VMware では vMotion 時のストレージアクセスは ESXi が VMFS のクラスタリング機構や NFS の排他制御で透過的に処理していたので、管理者がアクセスモードを意識することはほとんどなかったと思います。Virt では PVC の AccessMode を明示的に RWX にするという一手間が必要になります。 ontap-nas は、NFS で volumeMode: Filesystem の PV を提供するため、複数ノードから何の問題もなく同時マウントでき、RWX は素直にできます。よって Live migration は問題なくできます。 一方 ontap-san は、提供される PV はノードから見るとブロックデバイスですが、 volumeMode: Block を指定することで RWX を実現できます。よって Live migration する際は、 accessModes: ReadWriteMany & volumeMode: Block の組み合わせで実現できます。以前の RDM の記事でも同様の指定をしています。 rheb.hatenablog.com 結局、どちらにせよ Virt の仮想ディスクとして使うことはできます。じゃあどっちの方がより良いの？って思いますよね。 個人的には「Virt の仮想ディスク」というポイントのみで見ると、 ontap-san がいいと思います。そもそも VM が仮想ディスクとして求めるのはブロックデバイスなので、 ontap-san で LUN を見せるほうが適切だと思うからです。 しかし ontap-nas でも普通に使えるし、LUN が無い分 ONTAP 側の管理はシンプルになります。この両者を比べるにはここでは余白が少なすぎるので、第2回（容量設計）と第3回（性能設計）で徹底比較します。 VMware で「NFS と VMFS どっちがいいか」に唯一の正解がなかったのと同じで、ここでも環境と要件次第です。VMware 時代の運用を思い出しながら、以下の指針を参考にしてください。 Virt でのざっくりした指針としては、こんな感じかなと思います。 ontap-nas VMware で NFS データストアを使っていた環境に近い。あまり詳しくないけどひとまず使い始めたいという場合にも、RWX が取りやすく、ボリューム単位で Snapshot もできるので、仮想ディスクの置き場として扱いやすい。 ontap-san VMware で VMFS / iSCSI SAN を使っていた環境に近い。既存の FC/iSCSI SAN を使いたい、性能を追求したい、RDM 的なことをやりたいという場合に Good。 ontap-san-economy PV 単位の QoS やレプリケーションに制約があるため、 VM ディスク用途では基本的に第一候補にはしない 。iSCSI で大量の PV が必要な場合に検討、くらいの温度感でよい。 もちろん実際には、お使いの ONTAP のプロトコル構成（NFS が引けるのか iSCSI なのか）、ネットワーク、既存の運用に強く依存します。「うちは iSCSI SAN しかないんだよ」という環境なら最初から ontap-san か ontap-san-economy が選択肢になりますし、逆に「NFS でシンプルに運用したい」なら ontap-nas 一択です。 VMware 時代に ONTAP で NFS データストアを運用していた方は ontap-nas 、VMFS + iSCSI/FC で運用していた方は ontap-san を出発点にすると、これまでの運用知識をそのまま活かせるはずです。 まとめ 前置きが長かったのでサクッとまとめます。 VMware では「NFS データストアか VMFS データストアか」が最初の選択でした。Virt では「Trident のストレージドライバに何を選ぶか」がそれに相当します。 Virt で NetApp FAS/AFF を使うなら、 まず ontap-nas （NFS でよければ）か ontap-san （ブロックがよければ）のどちらか 、というのが大方針です。 ontap-san-economy は大量の PV が必要な場合の選択肢ですが、まずは上の 2 つから検討すればまず外しません。 今回はドライバの種類だけでしたが、VMware で実現していた運用を Virt でどう再現するかは、まだまだ話すことがあります。 次回以降では以下のテーマを扱っていきます。 第2回: 容量設計 — ontap-nas と ontap-san で ONTAP 側の容量がどう変わるか、Snapshot reserve の考え方 第3回: 性能設計 — NAS / SAN の性能差の検証 第4回: VM 移行 — Shift Toolkit を使った VMware からの VM 移行 第5回: マルチテナント設計 — vCenter のフォルダ・権限・SPBM を SVM + StorageClass + Namespace でどう置き換えるか 第6回: データ保護 — Snapshot / バックアップの設計 第7回: DR 設計 — SnapMirror 等を使った DR 第8回: 監視と運用 — 日常運用の監視と管理 次回は ontap-nas と ontap-san の容量面での徹底比較を行います。 というわけで今日はここまで。 （※本記事の内容は各種公式ドキュメントを参照しつつ執筆していますが、実際の構成・パラメータはお使いの Trident / ONTAP のバージョンによって異なる場合があります。本番投入前には必ず公式ドキュメントと検証で裏を取ってくださいね。） *1 : 既に販売終了となっている SolidFire / NetApp HCI 向けのドライバも提供されていますが、新規導入で選択するものではありません

レッドハットのソリューションアーキテクトの森です。 ここ1〜2年で、生成AIの活用は「チャットで質問する」段階から、「AIエージェントが業務システムやデータに直接アクセスして仕事をこなす」段階へと進みつつあります。社内でエージェントのPoCに取り組んでいる、という方も多いのではないでしょうか。 ところが、PoCから本番に進もうとすると、セキュリティ部門や監査部門から、こんな質問を受けることがあります。 「そのAIエージェント、誰の権限で動いていますか？」 この質問に、すぐに答えられるでしょうか。 本記事では、レッドハットの認証・認可基盤 Red Hat build of Keycloak （以下RHBK）を例に、AIエージェントの認証・認可をどう考えればよいかを、できるだけシンプルにご紹介します。細かい設定手順ではなく、「考え方」と「始め方」を中心にお話しします。 ※本記事の製品情報は、RHBK 26.6時点のものです。 そのエージェント、誰の権限で動いていますか？ 考え方はシンプル：エージェントにもIDを、トークンに「誰の依頼か」を 同じエージェントでも、使う人によって見える範囲が変わる Red Hat build of Keycloakが向いている理由 どこから始めるか：小さく始めて広げる 終わりに そのエージェント、誰の権限で動いていますか？ まずは、AIエージェントの認証・認可で起きがちな「あるある」を4つ挙げてみます。 AIエージェント時代の認証・認可の課題 1. 共有APIキー・固定シークレット PoCでは、エージェントに業務APIのAPIキーを1つ渡して動かす、というケースがよくあります。ところが、同じキーを複数のエージェントで使い回すと、どのエージェントがアクセスしたのか区別がつきません。漏えいした場合の影響範囲も大きく、キーを入れ替えるのもひと苦労です。 2. エージェントへの過剰な権限 「便利に使ってもらいたいから」と、エージェントに「全社の売上データを参照できる」ような広い権限を与えてしまうことがあります。そうすると、誰がエージェントを使っても、同じ範囲のデータにアクセスできてしまいます。 3. 人とエージェントのIDの分断 人は社内のIdP（Entra IDやOktaなど）で管理しているのに、エージェントは個別のキーで別管理、という状態です。これでは、「誰の依頼で、どのエージェントが、何をしたのか」を後から追いかけることができません。 4. エージェント・ツールの急増 部門ごとにエージェントやMCPサーバーが増えていくと、登録・権限変更・廃止の管理が追いつかなくなります。気づいたら、使われていないエージェントのキーが残り続けている…ということも起こりがちです。 これらに共通しているのは、 これまでの認証・認可が「人がログインすること」を前提に作られている という点です。エージェントの時代には、「エージェント固有のID」「利用者のID」「最小権限の短時間トークン」の3つで制御する仕組みが必要になります。 考え方はシンプル：エージェントにもIDを、トークンに「誰の依頼か」を では、どうすればよいのでしょうか。考え方は意外とシンプルです。 エージェントにも人と同じように「ID」を持たせ、エージェントが使うトークンに「誰の依頼か」を一緒に載せる。 これだけです。図にすると、次のようになります。 人とAIエージェントの「二重のアイデンティティ」 左上が 人のID です。利用者はこれまでどおり社内のIdPでサインインします。RHBKは社内のIdPと連携し、部署やグループといった属性を受け取ります。 左下が エージェントのID です。「営業分析エージェント」「設計支援エージェント」のように、エージェントごとにRHBKに登録し、固有のIDと権限を持たせます。 そして真ん中のRHBKが、この2つを結び付けて トークン を発行します。右側がトークンの中身のイメージです。1つのトークンの中に、 誰の依頼か（人のID） どのエージェントか どこで使うか（宛先） 何をしてよいか いつまで有効か（数分で失効） といった情報がまとめて入っています。エージェントがAPIを呼び出すときは、このトークンを提示します。受け取る側は、トークンを見るだけで「誰の依頼で、どのエージェントが来たのか」を判断できるわけです。 エージェントの動き方には、利用者のサインインを起点に「利用者の代わりに」動くタイプと、バッチ処理のように「エージェント自身の権限で」動くタイプがありますが、どちらも同じ仕組みで扱えます。 ここで使っているのは、OAuth 2.0やOpenID Connectといった 標準のプロトコル です。特別な独自仕様ではないので、既存のAPIゲートウェイやアプリケーションとも組み合わせやすい点もポイントです。 同じエージェントでも、使う人によって見える範囲が変わる この仕組みのうれしさが一番よく分かるのが、次のようなケースです。 社内に「営業分析エージェント」があり、エージェント自体は全社の売上データを参照できるとします。でも本当は、 第1営業部のAさんが使うときは、第1営業部のデータだけ 第2営業部のBさんが使うときは、第2営業部のデータだけ を返してほしい。こういうご要望は、実際によく伺います。 同じエージェントでも、使う人によって見える範囲が変わる ポイントは、 実際にアクセスできる範囲を「エージェントに許可された範囲」と「利用者に許可された範囲」の重なりにする ことです。 RHBKは、「誰が、どのエージェントで、どの部署の人か」という判断材料をトークンに載せます。それを受け取ったAPIゲートウェイや業務API、データベースが、その情報をもとにアクセスの可否や返すデータの範囲を判断します。 こうすると、 1つのエージェントを全社で共有しながら、見えるデータは使う人ごとに自動で変わる 、という状態を作れます。部署ごとに別々のエージェントを作る必要はありませんし、「誰の依頼で、何にアクセスしたか」もトークンの情報から追跡できるので、監査の面でも説明しやすくなります。 なお、RHBKには、利用者の権限の範囲を保ったまま、下流のAPI向けに「宛先と権限を絞ったトークン」に交換する仕組み（Token Exchange）も標準で備わっています。エージェントが利用者の強いトークンをそのまま持ち回らずに済むので、より安全に構成できます。 Red Hat build of Keycloakが向いている理由 AIエージェントの認証・認可を実現する手段はいくつかありますが、RHBKには次のような特長があります。 観点 RHBKの特長 既存のIdPを活かせる 人のIDは今の社内IdPのまま。サインインの体験を変えずに、エージェント向けの認可を追加できる 標準仕様で組み合わせ自由 OAuth 2.0／OpenID Connectで構成するため、APIゲートウェイやAI基盤の製品を選ばない 閉域網でも使える 自社の基盤の中で、認証からトークンの検証まで完結できる エージェントが増えてもコストが増えにくい ユーザー数ではなく、CPUコア数ベースのサブスクリプション いくつか補足します。 コスト について。AIエージェントは、うまく活用が進むほど数が増えていきます。利用者数やエージェント数に応じて費用が増えるモデルだと、横展開するほどコストが膨らみます。RHBKはCPUコア数ベースなので、エージェントが増えてもライセンス費用に直結しにくく、「小さく始めて、全社に広げる」という進め方と相性がよいのです。 閉域網 について。製造業や金融、公共分野など、インターネットにつながらない環境でAIを活用したいというご相談も増えています。RHBKは自社の基盤上で動くため、閉域網の中で認証・認可を完結できます。 どこから始めるか：小さく始めて広げる 「考え方は分かったけれど、いきなり全部は難しい」という方も多いと思います。おすすめは、次の3つのステップで小さく始めることです。 どこから始めるか：小さく始めて広げる STEP 1：エージェントに固有のIDを持たせる まずは1つのエージェント、1つのAPIから始めます。共有APIキーをやめて、エージェントをRHBKに登録し、短時間のトークンで許可されたAPIだけを呼べるようにします。これだけでも、「どのエージェントがアクセスしたか」が分かるようになります。 STEP 2：利用者のIDと結び付ける 次に、社内のIdPとRHBKを連携し、トークンに「誰の依頼か」を載せます。利用者のサインインの体験は変わりません。 STEP 3：範囲を絞り、運用を自動化する 最後に、利用者の属性に応じてデータの範囲を絞り込みます。あわせて、エージェントの登録・廃止の自動化や、「誰が何をしたか」の追跡の仕組みを整えていきます。 一度この仕組みができれば、エージェントが増えても同じやり方で横展開できます。 終わりに いかがでしたでしょうか？ AIエージェントの活用が本番フェーズに入るにつれて、「そのエージェント、誰の権限で動いていますか？」という問いに答えられることが、ますます重要になっていきます。エージェントにもIDを持たせ、トークンに「誰の依頼か」を載せる。この考え方を取り入れるだけで、セキュリティと使いやすさを両立したエージェント活用に一歩近づけるはずです。 本記事では考え方を中心にご紹介しましたが、実際の構成例や、既存のIdP・APIゲートウェイとの組み合わせ方、検証の進め方などについては、レッドハットから詳しくご説明することも可能です。AIエージェントの認証・認可について検討されている方は、お気軽に担当営業までお問い合わせいただければと思います。

こんにちは、ソリューションアーキテクトの蒸野（ムシノ）です。 今回は、いまこそAPIセキュリティを見直すとき！〜AI脅威論を超えて、組織の「事業境界」を再構築する〜という内容で記載していきたいと思います。 2026年10月：激化する攻撃と「AI原因説」の罠 2026年10月、日本国内では不正アクセスや個人情報・認証情報の漏えい事案が相次ぎ、政府（国家サイバー統括室等）も強い警戒感を示して異例の注意喚起を発令しました。報道によれば、今年の国内におけるサイバー攻撃関連被害はすでに500件を超え、前年の年間件数を大幅に更新する勢いです。 生成AIや攻撃自動化ツールの進化により、攻撃者が偵察・脆弱性探索・プロキシ回避・クレデンシャルスタフィング（アカウントリスト型攻撃）を高速かつ大量に実行可能になったことは事実です。 しかし、被害の根底にある問題を「AIを用いた未知の高度攻撃だったから防げなかった」と言い換えて納得してしまうのは極めて危険です。 本質的な課題として、 攻撃者がAIという強力な道具を手にする前から、自社が外部に公開しているすべてのAPIやエンドポイントを正確に把握（インベントリ化）できていたか？ 「セキュリティ予算がない」「専門人材が不足している」「英語の最新脅威情報や国際標準（OWASP等）を追う余裕がない」といった理由で、基本対策を先送りにしてこなかったか？ 問われているのは攻撃者の技術力だけではなく、優先順位の設定や投資判断を先送りにしてきた組織のあり方そのものでもあります。相次ぐ事件を「対岸の火事」や「不可抗力」として片付けず、自社の備えを根本から問いただす時が来ています。 こちらでもAPIセキュリティに関する記事があります。是非参考にしてみてください。 rheb.hatenablog.com なぜいまだったのか？ 8月、9月、10月にかけてサイバー攻撃やハッキング被害が急増している背景には、生成AIの発達によってこれまで日本を守ってきた「言葉の壁（日本語の壁）」が完全に排除されたことが大きく影響しています。従来、海外からのフィッシングメールや詐欺攻撃は、不自然な日本語や文脈の違和感から比較的容易に見破ることができました。しかし現在では、高度な生成AIにより、ビジネスメールとして違和感のない完璧な敬語表現、文脈に応じた自然な文章、さらには組織固有のトーンに合わせた標的型メールが瞬時に生成できるようになりました。これにより、攻撃の「騙しの精度」が劇的に向上しただけでなく、多言語への攻撃展開が自動化され「攻撃量」も爆発的に増加しています。 こうした「AIによる言語の壁の解消」がサイバー犯罪の参入障壁を劇的に下げたことに加え、組織的・構造的な複数の要因が複合的に絡み合っています。 主な理由は以下の通りです。 1. 既知の脆弱性（未修正のセキュリティホール）の放置 修復遅れを狙う攻撃（1-day攻撃）： メーカーからセキュリティパッチ（修正プログラム）が公開された直後、攻撃者は修正内容を解析（リバースエンジニアリング）して逆手に取り、まだ対策を行っていない企業・システムを狙い撃ちします。 VPNやWebサーバーの放置： テレワーク普及時に導入されたVPN機器や古いCMS（Webサイト管理システム）の更新が追いつかず、インターネットに公開されたままの「入口の穴」が標的になっています。 2. 脆弱性探査・スキャンツールの自動化と高速化 常時スキャンの増加： 攻撃者はAIや自動化ボットを用いて、インターネット全体に対してセキュリティの弱いシステムがないか（WebスキャンやSQLインジェクションの試行など）を24時間体制で高速探査しています。 効率的な標的選定： 弱点を持つシステムを無差別かつ機械的に洗い出す体制が整ったため、短期間で被害件数が表面化しやすくなっています。 3. ビジネスモデル化した攻撃エコシステム サイバー犯罪の分業化： 攻撃ツールやランサムウェアをパッケージ化した「RaaS（Ransomware as a Service）」や、流出したログイン情報を売買する「ダークウェブ市場」が確立しています。 技術的ハードルの低下： 専門的な技術がない攻撃者でも、ダークウェブで購入したツールや、生成AIに悪質コードの作成・デバッグを補助させることで、容易に高度なハッキングを行える環境が整っています。 このようにして、生成AIによる「自然な日本語表現の生成」と「攻撃の自動化・効率化」は、海外のサイバー犯罪グループにとって日本市場を格好の標的に変える「最大の引き金」となりました。このAIによる攻撃の質的・量的進化に、「未修正の脆弱性の放置」「自動探査技術の普及」「攻撃ツールの商品化（RaaS）」、そして「組織の年度替わりの隙」が重なったことで、9月、10月の被害集中・急増という事態を引き起こしています。 複雑に絡み合いながら攻撃から防御する手立ては？ JPCERT/CCでは攻撃方法の注意喚起の一つにAPIによる不正な操作が上げられています。 www.jpcert.or.jp 上記の注意喚起からの抜粋です。 （b）本来画面操作では実行できない内部APIに対する攻撃 - ユーザー権限を変更する - 不正なアカウントを作成する - ヘッダーの有無の切り替えや不正な形式の認証トークンの付与による応答の違いを確認する - NoSQLインジェクションによるブラインド探索によってアカウント情報を特定する なぜAPIが標的になるのか 現代のビジネスにおいて、APIはスマホアプリ、Webフロントエンド、SaaS連携、B2B取引、社内のマイクロサービス同士を接続する「事業の主要導線」です。攻撃者にとっても、従来のWeb画面（GUI）を迂回して直接データベースやバックエンド処理にアプローチできる最も効率的な入口となっています。OWASP API Security Top 10等でも指摘されている通り、API固有の脆弱性は組織に致命的な損害を与えます。 シャドーAPI・ゾンビAPIの放置 開発・テスト用に作成されたまま放置されたAPIや、旧バージョン（/v1/など）が管理対象から漏れ、無防備なまま公開されている。 BOLA（破綻したオブジェクトレベルの認可：Broken Object Level Authorization） ログイン（認証）は成功していても、「他人のユーザーID」を指定してリクエストを送るとデータが取得できてしまう認可制御の欠陥。 過剰なデータ露出（Excessive Data Exposure） クライアント側でフィルタリングすることを前提に、APIレスポンスとして必要以上の個人情報や内部ステータスを返却している。 レート制限（Rate Limiting）の欠如 Bot等による大量リクエストを制御できず、サービス停止（DoS）や大量データの一括窃取（スクレイピング）、認証試行の連打を許してしまう。 APIセキュリティの欠陥は、単なるWebサイト改ざんを超え、「基幹データの直接流出」や「事業継続の停止」に直ちに直結します。だからこそ、開発チームの個別の実装スキルに依存するのではなく、「組織全体のガバナンス方針」としてAPIセキュリティを定義する必要があります。 APIゲートウエイによるハッキングへの防御 APIゲートウェイ（API Gateway）は、外部のインターネットと内部のシステム・マイクロサービスとの間に立つ「単一のアクセス窓口（プロキシ／検問所）」として機能します。前述のサイバー攻撃の要因（脆弱性の放置、自動スキャン、AIフィッシング後の不正アクセスなど）に対し、APIゲートウェイがどのように防御効果を発揮するのか、具体的な仕組みと役割を示します。 1. 大量アクセス・DoS/DDoS攻撃への対策 悪意のある大量のリクエストによってサーバーをダウンさせる攻撃を防ぎます。 レートリミット（流量制限）/ スロットリング :　IPアドレスやAPIキーごとに、1秒間（または1分間）あたりに受け付けるリクエストの上限を設定し、超過分をブロックします。 WAF（Web Application Firewall）との連携 :　AWS API GatewayとAWS WAFのように、ゲートウェイの前段または一体型でWAFを動作させ、不正なIPからのアクセスやシグネチャベースの攻撃を遮断します。 2. 不正アクセス・なりすましへの対策 認証されていないユーザーや、権限のないシステムからのアクセスを防ぎます。 認証・認可の一元化（Authentication & Authorization） :　バックエンドの各サービスで個別に実装するのではなく、ゲートウェイでOAuth 2.0、OIDC（OpenID Connect）、JWT（JSON Web Token）などの検証をまとめて行います。 APIキー管理 :　許可されたクライアントだけにAPIキーを発行し、有効なキーを持つリクエストのみを通過させます。 3. データの改ざん・インジェクション攻撃への対策 SQLインジェクションやクロスサイトスクリプティング（XSS）、不正なパラメータの送信を防ぎます。 リクエスト検証（Validation） :　バックエンドにリクエストを転送する前に、JSONなどのスキーマ検証やデータ型・必須項目のチェックを行い、不正なデータ構造を持つリクエストを弾きます。 入力値のクレンジング :　不正なスクリプトやコマンドが含まれていないかチェックします。 4. 情報漏洩・盗聴への対策 通信の傍受や、バックエンドの不要なエラー情報が攻撃者に漏れるのを防ぎます。 SSL/TLS暗号化の強制（SSL Termination） :　すべての通信をHTTPSで強制し、暗号化をゲートウェイで解除（終端）してバックエンドに安全に流します。 レスポンスのマスキング / エラーの共通化 :　システム内部のエラー（SQLのエラー文など）がそのままクライアントに返ると攻撃のヒントになります。ゲートウェイでエラーレスポンスを標準的なコード（例: 500 Internal Server Error）に書き換えて隠蔽します。 5. 攻撃の検知と追跡 攻撃の兆候を早期に見つけ、被害発生時に調査できるようにします。 ログ記録とモニタリング（Logging & Auditing） :　「誰が・いつ・どのAPIに・どんなパラメータで」アクセスしたかをすべて記録し、アクセスパターンの異常を検知します。 6. 設定値が書き換えられるリスクへの対策 ハッキング対策の設定そのものが書き換えられるリスクに対して、Red Hat Connectivity Link がサポートするGitOpsプラクティス（Policy-as-Code）が有効です。まさにGitOps（Policy-as-Code）こそが、管理権限の奪取や手動設定の変更による「セキュリティ設定の改ざん」に対する強力な特効薬となります。セキュリティポリシーをGitで一元管理することで、設定の改ざんを素早く検知・修正し、常に安全な状態を維持できます。 Solution Patterns: Connect, Secure and Protect with Red Hat Connectivity Link :: Solution Patterns from Red Hat Red Hat Connectivity Linkによるポリシーの標準化と運用組み込み Red Hat Connectivity Link（オープンソースコミュニティプロジェクト「Kuadrant」をベースとしたソリューション）は、まさにハイブリッドクラウドおよび生成AI時代の要求に応える次世代API ゲートウエイ / AI ゲートウエイです。 詳細は下記記事をご覧ください。 rheb.hatenablog.com rheb.hatenablog.com APIセキュリティを組織全体で維持するには、個々のアプリコード内に認証・認可やレート制限をハードコーディングするのではなく、「プラットフォーム（インフラ/ゲートウェイ）層でポリシードリブンに一元適用する」設計が不可欠です。 [クライアント/外部リクエスト] │ ▼ ┌────────────────────────────────────────────────────────┐ │ Gateway API (Red Hat Connectivity Link) │ │ ┌────────────────────────────────────────────────────┐ │ │ │ 一貫したポリシー適用 │ │ │ │ - TLS暗号化 & mTLS終端 │ │ │ │ - OIDC / JWT / OAuth2 による強力な認証 │ │ │ │ - 細粒度なアクセス認可 (RBAC/ABAC) │ │ │ │ - 動的レート制限 (Rate Limiting) │ │ │ └────────────────────────────────────────────────────┘ │ └──────────────────────────┬─────────────────────────────┘ │ 観測性: メトリクス / トレース / ログ ▼ [マイクロサービス / バックエンドAPI] 1. ポリシーのKubernetesネイティブな定義 Declarative（宣言的）に認証、認可、TLS、レート制限などのルールをカスタムリソース（CRD）として記述できます。アプリケーションコードを変更することなく、インフラ/ゲートウェイレベルで一律のセキュリティ境界を形成します。 2. マルチクラスター/ハイブリッド環境での一貫性 複数のOpenShiftクラスターやクラウド環境に跨がるAPI接続に対し、同一のセキュリティポリシーをシームレスに展開・維持できます。 3. 観測性（Observability）の向上 PrometheusやJaeger/OpenTelemetry等との連携により、すべてのAPIリクエストのメトリクスや分散トレースを可視化。異常なスパイク（急激なトラフィック増）や不正なステータスコード（401/403/500系）の急増をリアルタイムに検知できます。 【導入にあたっての留意点】 製品の導入自体がセキュリティを自動完成させるわけではありません。「どのAPIにどのようなレート制御をかけるか」「誰にどのロール権限を与えるか」という組織としての設計方針（Policy Definition）を策定した上で、Connectivity Linkをその方針の「適用エンジン」として運用に組み込むことが重要です。 今日から着手する「APIセキュリティ点検」の5ステップ 派手なAI対策ツールを検討する前に、まず基礎となる守るべき基本的なガードレールを維持・運用するための実行手順が必要です。まずはこのようなロードマップを描いてみましょう。 Step 1: APIゲートウェイの全量洗い出し (インベントリ化) ↓ Step 2: 認証・認可 & 内部通信の暗号化 (TLS/mTLS) の再点検 ↓ Step 3: アダプティブな「レート制限」の設計と適用 ↓ Step 4: リアルタイム観測体制 (ログ・メトリクス・アラート) の確立 ↓ Step 5: 定期的な設計見直しと責任分担 (RACI) のアップデート APIおよびゲートウェイの全量洗い出し（インベントリ化） 開発・運用・外部連携の各チームで管理されているすべてのAPIエンドポイントを調査。未把握のシャドーAPIやゾンビAPIを特定・閉塞する。 認証・認可およびTLS設定の再点検 すべての公開APIに適切な認証メカニズム（OAuth 2.0/OIDC、API Key等）が適用されているか。通信のTLS暗号化や、サービス間通信におけるmTLSの適用範囲を確認する。 適切な「レート制限（Rate Limiting）」の設計 エンドポイントの特性（ログイン処理、データ参照、重い集計処理など）に応じたレスポンス制限値を設定し、過剰な連打やDoS攻撃、スクレイピングをゲートウェイ側で遮断する。 観測（Observability）と即時対応体制の確立 アクセスログ、メトリクス、トレースを集約し、閾値を超えた異常アクセスを即時にSOCや運用チームへアラート通知する仕掛けを作る。 責任分担と見直しサイクルの定期化 CISO、開発チーム、プラットフォーム運用チーム間の責任分解点（RACIマトリクス）を明確にし、四半期ごとなど定期的な設定レビューを実施する。 おわりに：一時的な対策で終わらせないために 2026年10月に相次ぐサイバー攻撃事案は、単なる「季節性のニュース」でも「一部の不運な企業の事故」でもありません。デジタルトランスフォーメーション（DX）が進み、あらゆる事業がAPIで外部と繋がる中で露呈した、組織の設計思想と運用の課題です。 攻撃の手口が変化し高度化しても、「守るべき境界を正しく把握し、一貫したポリシーを適用し、継続的に観測する」というセキュリティの原則は変わりません。 APIを自社事業の重要な境界と再定義し、明確な運用方針と適切なテクノロジー（Red Hat Connectivity Link等）を用いて防壁を構築する――。「いつかやる」を終わりにして、いまこそAPIセキュリティを高める決断が求められています。

みなさま、はじめまして。 パートナー様を担当しているEcosystem SAの萩原と申します。 昨今、サイバー攻撃による情報漏洩のニュースを目にしない日はないくらいに被害が増えていますね。特にAIが急速に進化している現在、攻撃者側もAIを駆使してソフトウェアの脆弱性を防御を上回る速度で発見し、攻撃を仕掛けてくるようになってきていることも要因の一つになっていると考えられます。 最近ではOSやクラウド基盤のセキュリティは自動化が進み、パッチ管理もかなり当たり前になってきました。でも、その上で動いている「アプリケーションの中身（OSSコンポーネント）」はまた状況が変わっていると言えます。 現代の商用アプリケーションにおいてコードベースの98%にオープンソースが含まれているというデータがあり、平均的な商用アプリケーション一つをとっても、その中には1,100個以上のOSSコンポーネントが存在すると言われています。 （参考： 2024 OSSRA Report / What enterprises need to know about the software they depend on ） また、OSSコンポーネントの修正はそれぞれのコミュニティに委ねられているため、修正のスピード感が違ったり、OSSコンポーネントに脆弱性があると判明した場合でもバージョンアップとなり、リグレッションテストなどで修正の取り込みに時間がかかったりするケースもあるかと思います。 AIによって脆弱性の報告件数が爆発的に増える中、従来の対応ではスピードが追いつかなくなってきているのが現状と言えます。 そこで今回はRed HatとIBMが共同で立ち上げた、OSSセキュリティ問題を解決する新サービス 「Lightwell」 について概要をご紹介させてください。 Lightwellって何？ Lightwellの価値とは 1. セキュアなリポジトリ提供 2. パッチの早期提供 3. パッチ影響の最小化 リポジトリの種類 Lightwell 提供形態 アプリケーションの脆弱性と向き合うために 参考リンク・リソース Lightwellって何？ 調べると色々と記事が出てくると思いますが、簡単に説明するならば 「企業のアプリケーションが使用しているOSSの脆弱性を、IBMとRed Hatが発見・修正し、専用のリポジトリを通じてお客様へ提供するサービス」 となります。 この取り組みを実施するために、20,000人を超えるエンジニアとAIツールを活用しており、最大のポイントは、 「脆弱性の発見と修正」 にあります。 冒頭にも記載しましたが、攻撃者もAIを使って未知の脆弱性をハイスピードで探し出しています。 Lightwellは、これに対抗するために高度なAIエージェントを活用し、まだ公になっていない脆弱性を自ら発見し、上流コミュニティと連携しながら、攻撃者に利用される前にエンタープライズ品質の修正パッチを生成して提供します。 なので、利用者はその修正パッチをCI/CDパイプラインを通じ、アプリケーションへ迅速に適応することによって、攻撃者に該当の脆弱性を悪用される前に対応を講じることが可能になります。 Lightwellの価値とは 1. セキュアなリポジトリ提供 Lightwellは、修正済みのパッケージを配布する専用のリポジトリを提供します。ユーザーはこの専用のリポジトリを通じてパッケージを受け取ることができるようになります。 提供されるのは、修正後のファイル（バイナリ）だけではありません。そのパッチが「何の要素で構成されているか」を示す SBOM と、脆弱性の修正状況を正確に伝える VEX がセットで提供されます。 これにより、提供されたパッチが安全であることを客観的に証明できるだけでなく、VEXの情報も提供されるため脆弱性スキャナーによる「誤検知」を防ぐことができます。 2. パッチの早期提供 Lightwellは未知の脆弱性を発見し、修正パッチを生成して契約者がアクセス可能なリポジトリに提供します。契約者は、脆弱性が一般に公開（CVE化）される前の期間中にリポジトリからパッチを入手し、事前に対策を講じることが可能となります。これにより、脆弱性がオープンになってから攻撃が始まるまでの無防備な時間を短縮することができます。 また、Lightwellで生成された修正パッチは一定の猶予期間の後、最終的には上流（アップストリーム）のオープンソース・コミュニティへと還元されます。Red Hatの「アップストリーム・ファースト」の理念に基づき、自社のサービスだけでパッチを抱え込むのではなく、コミュニティ全体に貢献することで、オープンソース・エコシステム全体の安全性を高める役割も担っています。 3. パッチ影響の最小化 発見された脆弱性への対応方法として、その脆弱性に対応がなされた最新バージョンにアップデートするのが一般的な対応方法になります。ただ、アップデートをするとなると依存関係やAPI互換性の検証などで適応までに時間がかかってしまうケースや、リスクを受け入れてシステム更改まで待つといったケースもあるかと思います。 Lightwellの脆弱性対応のパッチでは最新版のリリースではなく、 市場で多く使われているバージョン（Pinned Version）にバックポートして提供 します。 最終的にアプリケーションが動くかどうかの確認というのは必要になってきますが、バックポート修正によりアプリケーションへのパッチ適用時のリスクを最小限に止めることが可能となっております。 リポジトリの種類 Lightwellのリポジトリは、その役割やパッケージのステータスによって大きくいくつかに分かれています。詳細は公式ドキュメントをご覧いただければと思いますが、ここでは簡単にご紹介します。 Validated Repositories（検証済みリポジトリ） : 上流コミュニティのパッケージをRed Hatが改めて検証し、SBOMやVEXなどのセキュリティ情報を付与したものです。「中身が透明で、信頼できることが証明されている」ことが最大の特徴です。 Remediated Repositories（修正済みリポジトリ） : 脆弱性が発見された際、Red Hatが独自にパッチを適用（バックポート）したパッケージが格納されます。「今すぐ安全なものに置き換えたい」というニーズに応える、Lightwellの核心となるリポジトリです。 Predisclosure Repositories（公開前リポジトリ） : 脆弱性が一般に公開（CVE化）される前の、猶予期間中にある修正パッチが格納されます。 （※各リポジトリの詳細な仕様については、こちらの公式ドキュメントでご確認いただけます） https://docs.redhat.com/ja/documentation/lightwell_network/current/discover-lightwell_network_repositories このように、「今のライブラリをより安全に管理したい（Validated）」から「見つかった脆弱性を今すぐ解決したい（Remediated）」、「一般公開される前に脆弱性を解決したい(Predisclosure)」、といった形で目的に応じたリポジトリが用意されています。 Lightwell 提供形態 一年間のサブスクリプションとなり、以下の2つの契約形態があります。 Lightwell Network: Red Hatのセキュアなリポジトリを通じて利用可能になった、対象となるオープンソースの脆弱性に対する署名付きライブラリ、修正プログラム、およびパッチ適用済みアーティファクトへの統合されたセルフサービスアクセス。 Lightwell Clearinghouse: 対象となる組織に一般的に提供される、厳選された、よりきめ細やかなサポートを提供するサービスです。Lightwell Networkのメリットに加え、承認された範囲での顧客固有の脆弱性およびパッケージ要求、脆弱性の検証と開示の調整、該当する匿名化された要求の可視化、およびLightwell Security TAMサービスが含まれます。 修正パッチへのアクセス権利など基本的なLightwellの機能へのアクセスは「Lightwell Network」サブスクリプションを契約し、個別バージョンの脆弱性修正依頼などを実施したい場合は「Lightwell Clearinghouse」サブスクリプションを契約いただく形になります。 アプリケーションの脆弱性と向き合うために ここまで読んでいただいてお気づきになった方もいらっしゃると思いますが、新たに発見された修正パッチを有効に活用するためには 自社のアプリケーションでどのようなライブラリが使われているか把握してること 、また 修正パッチを迅速に適応できる仕組みを整えること も非常に重要な要素となっております。 どんなに早く修正パッチが提供されても、それに気づかなければ穴として存在し続けますし、攻撃者が気づく前にパッチ適応をしなければ侵害のリスクは生まれます。 Lightwell はアプリケーションの脆弱性対応するために、非常に有用なサービスです。 この記事を通じてLightwell の概要を知っていただけると勿論嬉しいのですが、そういえば自社の環境はどうなっているのか・・など何か気づきを得てもらえたら幸いです。 参考リンク・リソース Lightwell 公式製品ページ (Red Hat) Lightwell 公式製品ページ (IBM) Lightwell Network 製品ドキュメント（トップページ） Lightwell Network リポジトリの検索と詳細 Red Hat セキュリティ・バックポート・ポリシーの詳細 What enterprises need to know about the software they depend on (Red Hat Blog) Closing the remediation gap with Lightwell (Whitepaper) 2024 Open Source Security and Risk Analysis Report (Black Duck/Synopsys)

はじめに レベルの境目に引かれているのは「責任の線」だった 企業の AI 活用も、同じ壁にぶつかっている OpenShift AI が敷く「高速道路」 1. 処理の流れをコードで固定する — 「どう判断したか」をたどれるようにする 2. Guardrails — 入口と出口、そしてツール呼び出しに線を引く 3. トレース — 「どう判断したか」を後から再現する 4. Human-in-the-Loop — 責任の分岐点を人間に戻す では、レベル3になれるのか おわりに 参考文献 はじめに アソシエイトコンサルタントの野口です。 前回の記事 では、自動車の安全設計思想を補助線に OpenShift の「クラッシュセーフティ」を読み解きました。今回はその続きで、自動運転の安全設計を使って OpenShift AI の安全基盤を考えてみます。 IT業界に来て、企業の AI 活用で繰り返し聞く話があります。AI を入れてみたがうまくいかない。精度が足りない、レビューが追いつかない、結局 PoC（実証実験）止まりで本番に出せない。 こんな状況に心当たりはないでしょうか。 AI の精度は出ているのに、法務やセキュリティ部門の承認が下りない 人間のダブルチェックがボトルネックになり、AI の速度を活かしきれていない 「事故が起きたら誰の責任か」に答えられず、本番投入を判断できない 結局 PoC のまま止まり、現場の手応えにつながらない 以前いた自動車業界でも、自動運転で同じ議論を何度も耳にしました。技術は進んでも本番に出せない。突き詰めると核心にあったのは「事故が起きたら誰の責任か」という問いでした。今回はその補助線を使って、「AI に業務を任せるとは、どういうことなのか」を考えてみます。 レベルの境目に引かれているのは「責任の線」だった 「自動運転の車が事故を起こしたら、誰の責任か」。 自動車の世界には SAE（Society of Automotive Engineers、米国の自動車技術会）が定めた自動運転の レベル0〜5 という分類があります [1]。これは「どれだけ賢いか」の段階表ではありません。レベルの境目に引かれているのは、能力の線ではなく責任の線ではないかと感じています。 レベル 何が起きているか 常に見ているのは 1〜2 車間距離の自動調整やレーンキープ。人間が常に監視している 人間 L2+ ハンズオフ走行。支援は極めて高度だが監視の役割は人間に残る 人間 3 限定条件下でシステムが運転を主導する システムの側 4 限定条件下で完全自動運転。人間の介入は不要 システムの側 5 あらゆる条件下で完全自動運転 システムの側 L2+ は SAE の正式な定義ではなく、業界で慣用的に使われている呼び方です [2]。限りなくレベル3に近いのに、監視の役割だけが人間に残っている段階を指します。 2021年、世界初のレベル3搭載市販車が発売されました。ただし対象は高速道路の渋滞時のみ、100台限定のリースでした。責任を持って「ここなら動く」と言い切れる範囲は、それだけ狭かったということです。レベル3は、技術が万能になったから実現したのではなく、動作条件を極端に絞り込んだからこそ成立しました。 企業の AI 活用も、同じ壁にぶつかっている これは今の企業の AI 活用とまったく同じ構造だと思いました。 コード補完も、検索も、提案書の下案づくりも、人間が最後に目を通す前提で回っています。AI が誤っても「人間が確認を怠った」で処理できる。だから導入しやすく、PoC もうまくいく。これは L2+ までの世界です。 しかし「毎回ダブルチェックするなら、最初から人の手でやった方が早いのではないか」。現場にはそんな疲弊も広がっています。 もっとも、自動運転でも業界は L2+ の中で進化する道を選びました。大半の業務は人間が確認する運用のまま回すのが現実的でしょう。それでも、条件を絞り込んだ一点だけ「人間の確認なしで動かす」ところまで持っていきたい場面がある。さらに最近では、AI が自ら判断してツールを呼び出し、複数のステップを自律的に実行する Agentic AI の流れが加速しています。AI のケイパビリティが上がるほど、「誰が最終的な責任を持つのか」は机上の議論ではなく、いま目の前にある問題です。 ところが、そこに踏み込もうとすると少し話が変わってきます。AI が誤った処理を実行して損失が出たとき、企業として「いつ・どのデータで・どのモデルが・どう判断したのか」を説明できなければなりません。法務やセキュリティ部門が慎重なのは、AI の精度への懸念というより、説明できない状態のまま本番へ出すことへの不安ではないでしょうか。 ここで自動運転から借りたい考え方が ODD（Operational Design Domain：運行設計領域） [1]。「どういう条件下でなら動作を保証するのか」をあらかじめ定義しておく考え方です。 ODD を定義する作業は、ソフトウェア開発者なら TDD（テスト駆動開発） と重ねて考えるとわかりやすいでしょう。TDD は「テストを先に書き、コードがそれを満たすように実装する」手法です。ODD も「動作条件を先に定義し、その内側でシステムが正しく動くことを保証する」という点で同じ発想を持っています。違いは、TDD が個々の関数やモジュールの正しさを検証するのに対し、ODD はシステム全体が安全に運用できる範囲そのものを定義するところにあります。 どの業務の、どの入力範囲までを AI に任せ、どこから先は人間に戻すのか。合否判定をテストとして書けるくらい具体的に定義し、法務・セキュリティ・現場・経営がその条件に合意する。そうすれば、止めていた部門が線を引く側に回れるのではないでしょうか。さきほどの「説明できないまま本番に出せない」は、裏返せば、この条件がないまま本番の話が始まっていることを示しています。 オープンなチャット UI に自由に指示を出す運用は、いつどんな入力が来るかわからない「一般道」を走るようなものです。大事なのは AI をもっと賢くすることよりも、一般道から高速道路へ上がり、任せる範囲（ODD）を先に定義して、その内側で説明がつく状態をつくることではないかと感じています。 OpenShift AI が敷く「高速道路」 一般道から高速道路へ。条件を絞り込み、管理された実行環境をつくる。その前に、ひとつ、大事だと感じていることがあります。ODD を定義するのは、あくまで人間です。どこまでを AI に任せるかを決めるのは経営と現場の判断であって、製品が代わりに決めてくれるわけではありません。OpenShift AI が引き受けるのは、人間が決めたその条件を 構造化し、監視し、追跡すること です。 では、その基盤をどこに置くのか。汎用の AI サービスをそのまま使う、クラウド事業者のマネージド基盤に乗る、自社で基盤を持つ。大きく分ければ選択肢は3つあり、どれを選ぶかは定義した ODD 次第です。入出力のログで説明がつくなら1つ目で十分ですが、エージェントの挙動全体の統制や追跡可能性まで求められるなら、自社で基盤を持つ選択肢が必要になります。ここから先は、その話です。 さきほどの問い、「いつ・どのデータで・どのモデルが・どう判断したのか」に答えられる状態をつくることが、この製品群の仕事です。ここで鍵になるのが、 決定論的な処理と確率論的な処理を分ける という考え方です。LLM の推論は本質的に確率論的で、同じ入力でも出力が揺れます。だからこそ、入力検証・出力フィルタ・ログ記録・承認フローといった決定論的な処理で囲い込み、確率論的な部分を説明可能な枠の中に閉じ込める。その線に沿って見ていきます。 1. 処理の流れをコードで固定する — 「どう判断したか」をたどれるようにする まず、何をどの順で実行するかを、その場のプロンプト任せにしないことです。実行すべき一連の処理を、あらかじめコードとして書いておく。 LangGraph のようなエージェントフレームワークは、会話のループもシステムプロンプトもツールの呼び出しも、コードの側に持ちます。OpenShift AI 3.5 であれば、同じ役割を担う OGX （旧 Llama Stack）を使うこともできます [3]。 ターミナル型のエージェントに自由に指示を出す使い方に比べれば、できることは狭まります。しかし、その狭さこそが ODD です。手順が決まっていなければ、そもそも「どう判断したか」を後から追うことが難しくなります。 2. Guardrails — 入口と出口、そしてツール呼び出しに線を引く 入出力のチェックは NeMo Guardrails が担います [4]。機密情報の混入や、想定した入力範囲の外から来たリクエストを検知・遮断する。定義した ODD の外側を、境界で止める役割です。 エージェントの場合、境界は入口と出口だけではありません。3.5 では MCP ゲートウェイと組み合わせることで、 エージェントが外部のツールを呼び出す瞬間 にも同じ検査をかけられます（3.5 時点では Technology Preview）。確率論的な判断がシステムの外へ手を伸ばすところに、決定論的な関所を置く、という考え方です。 3. トレース — 「どう判断したか」を後から再現する エージェントの動作は、二つの層で記録します。 MLflow [5] が、どんな問い合わせが来て、どのツールを呼び、何を返したかというエージェント単位のトレースを残します。 OpenTelemetry はより細かく、どのガードレールが何を止めたのかをスパンとして残します。 さきほどの「いつ・どのデータで・どのモデルが・どう判断したか」に、エージェントであれば「どのツールを呼び出したか」が加わります。自分で学習させたモデルを使うなら、 モデルレジストリ [6] でバージョンを管理しておくことも必要でしょう。法務やセキュリティ部門が求めていた回答に、正面から応える仕組みです。 4. Human-in-the-Loop — 責任の分岐点を人間に戻す すべてを人間が確認するのでも、すべてを任せきるのでもない。「ここから先は人間」という線を引き、その手前でエージェントを止める。たとえばツールを実行する直前に承認を挟めば、確率論的な判断が外の世界に影響を及ぼす前に、人間が引き取ることができます。 ここが ODD の考え方と素直につながるところだと感じています。どのツール呼び出しを止めるのか、その線を決めるのはやはり人間の側です。「システムの側」から「人間」へ、判断を明示的に戻す設計点にあたります。 ポイント - ODD（運用条件）を定義するのは人間。OpenShift AI が担うのは、その条件の構造化・監視・追跡 - 処理をコードで固定し、入口・出口・ツール呼び出しの境界で止める - トレースで「どう判断したか」を後から再現し、承認ステップで責任の分岐点を人間に戻す ただし、Human-in-the-Loop を最後の砦にすることには落とし穴があります。自動運転には 「out-of-the-loop 問題」 があります。普段システムに運転を任せきりにしているドライバーは、緊急時に突然「代われ」と言われても完璧には対処できません。自動車業界はこの問題に対し、ドライバーモニタリングシステム（DMS）で注意力を常時監視しつつ、L2+ に留まることで「ループの外に出る状態」自体を避ける方向に進みました。AI でも同じことが起きるのではないかと感じています。日常業務を AI に任せ続けるほど、人間のチェック能力は衰えていく。「最後は人間が確認するから安全だ」という前提は、AI が賢くなるほど揺らいでいくように感じます。承認ステップを置くだけで十分かというと、そうとは言いきれないのではないでしょうか。 では、レベル3になれるのか ここまでの道具立てを揃えれば、企業の AI 活用はレベル3に上がれるのでしょうか。 答えは「範囲による」です。冒頭で見たように、世界初のレベル3車は「あらゆる道路で」ではなく、 高速道路の渋滞時という一点まで条件を絞る ことで成立しました。もっとも、「そこまで絞るなら L2+ のまま進化すればいい」という議論も業界にはありました。 それでも企業の AI 活用で、条件を絞ってでも任せきりたい場面はあります。たとえば、所定フォーマットの請求書から金額と日付を読み取り、会計システムへ自動入力する処理。入力がフォーマットに合致し金額が一定範囲内にあるときだけ動かす、と決めれば、テストも書けるし、説明もつく。会計システムを呼び出す手前に承認を挟んでおけば、金額の大きいものだけ人間に戻すこともできます。そのくらい狭い範囲に、ここまで見てきた道具立てを集中させることで成立します。その一台がそうだったように、狭くなければ成立しません。 おわりに 「AI に業務を任せる」というと、プロンプトをどう書くか、どのモデルを使うか、コストをどう抑えるか。関心はそこに集まりがちです。しかしここまで見てきて感じたのは、話はもっと手前のところにあるのではないか、ということでした。 最初の問いに戻ります。「自動運転の車が事故を起こしたら、誰の責任か」。自動車の世界では、レベル3を境に責任の重心がドライバーからメーカー側へ移ると言われています。では AI に業務を任せた企業で同じことが起きたとき、どう考えればいいのか。この問いへの答えは、まだ定まっていません。 だからこそ、いまできることに目を向けたいと感じました。任せる範囲（ODD）を定義し、その中での挙動を説明可能にする。この問いへの答えがどうなるにせよ、この2つが出発点になるのではないかと思っています。 もっとも、本質的な難しさは残っています。ここまで見てきた OpenShift AI の仕組みも、あくまで「人間が想定できる前提」の上に組まれたものです。out-of-the-loop 問題にしても、自動車業界は L2+ に留まることで避けましたが、AI の側ではまだ答えが出ていません。 レベル3を市販したメーカーは相次いで撤回に動き、自家用車の世界ではドライバーを残したまま進化が続いています。企業の AI 活用も、結局レベル3を超えることはないのかもしれません。それでも、「ここまでなら説明がつく」というラインを地道に敷いていくしかないのだと感じています。エンジニア出身のアソシエイトコンサルタントとして、そういう仕事を積み重ねていきたいと思っています。 最後までお読みいただき、ありがとうございました。 参考文献 ※ 本記事の製品情報は OpenShift AI 3.5 時点のものです。 [1] "Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles". SAE International — SAE J3016_202104. https://www.sae.org/standards/j3016_202104 [2] "Understanding L2+ in Five Questions". Mobileye. https://www.mobileye.com/blog/understanding-l2-in-five-questions/ [3] "Build AI/Agentic Applications with OGX". Red Hat — OpenShift AI Self-Managed 3.5. https://access.redhat.com/documentation/en-us/red_hat_openshift_ai_self-managed/3.5/html-single/working_with_ogx/index [4] "Ensuring AI safety with guardrails". Red Hat — OpenShift AI Self-Managed 3.5. https://access.redhat.com/documentation/en-us/red_hat_openshift_ai_self-managed/3.5/html-single/enabling_ai_safety_with_guardrails/index [5] "Working with MLflow". Red Hat — OpenShift AI Self-Managed 3.5. https://access.redhat.com/documentation/en-us/red_hat_openshift_ai_self-managed/3.5/html-single/working_with_mlflow/index [6] "Register, version, and promote models with the model registry". Red Hat — OpenShift AI Self-Managed 3.5. https://access.redhat.com/documentation/en-us/red_hat_openshift_ai_self-managed/3.5/html-single/working_with_model_registries/index

こんにちは。レッドハットコンサルティングチームの木嶋です。 最近ニュースでは、情報漏洩事件が日々話題になっていますね。 AIの高度化に伴い、攻撃側によるAIの活用についても報告されるようになりました。 話題に上がる事件の中には、APIが攻撃経路の一つとなったと考えられるケースも含まれています。 この機会に今一度APIセキュリティの基本に立ち返り、自分たちのシステムで十分な対策が取れているか、振り返ってみてはいかがでしょうか。 AIエージェントの攻撃は、実はあまり特殊なことはしていない APIセキュリティの参考資料 点検対象のAPI OWASP API Security Top 10 プラットフォーム使い方点検対象 設計点検対象 NIST SP 800-228 まとめ AIエージェントの攻撃は、実はあまり特殊なことはしていない 人間とAIエージェントを比較したときに、大きく変わるのは、その実行速度や規模です。 AIエージェントを利用することで、偵察、試行、結果の分析、次のアクションの選択といった一連の活動を、高速かつ継続的に実行できるようになります。 単純にいうと、人間は飽きるし、疲れます。手間や時間がかかりすぎれば、どこかで諦めることもあります。 一方でAIエージェントは、疲れませんし、飽きません。 非常に粘り強く、目的に向かって試行を繰り返し続けることができます。 ここが、人間による攻撃と比較したときの大きな違いです。 従来のセキュリティ対策では、攻撃者に必要な手間や時間、コストを増やし、「そこまでして攻撃する価値がない」と思わせ、諦めさせることも重要な考え方の一つでした。 しかし、AIエージェントを使えば、この「手間」や「反復」のコストを大きく下げることができます。 これまで問題が起きなかったことは、これからも安全であることの根拠にはなりません。 AIエージェントによって攻撃の試行回数や継続性が大きく変わるのであれば、「ここまでやれば十分だろう」という経験則ではなく、一般的なベストプラクティスに準拠して、対策をあらためて見直す必要があります。 APIセキュリティの参考資料 APIセキュリティを考えるときに、基本として参照していただきたいのは、以下の2つです。 OWASP API Security Top 10 NIST SP 800-228 大まかに整理すると、OWASP API Security Top 10は「APIではどんな抜け漏れが発生しやすいのか」を具体的に理解するための資料、NIST SP 800-228は「それらのリスクに対して、APIのライフサイクル全体でどのように対策するのか」を整理した資料として読むことができます。 2つあるなら、対策が書いてあるNISTだけを読めばよいのではないか、と思われるかもしれません。 しかし、この2つはセットで参照することをお勧めします。 OWASP API Security Top 10には、APIの設計や実装で発生しがちな問題が具体的に記載されています。 例えば、オブジェクト単位の認可不備、認証の不備、リソース消費の制御不足、APIインベントリ管理の不備など、「どのような設計をすると問題が起こり得るのか」をイメージしやすい内容になっています。 一方、NIST SP 800-228では、APIの開発時から実行時までを対象に、どのようなセキュリティコントロールを適用するか、さらにそれらをどのような仕組みで実現するかが体系的に整理されています。 記載されている内容と、参考にできる場面が少し異なるため、両方を参照すると理解しやすくなります。 もちろん、「今から全部読んで理解しよう！」というのが理想ではあります。 とはいえ、今まさに自分たちのAPIをチェックしたい、という方もいらっしゃるでしょう。 ここからは、APIセキュリティを短時間で見直すために、この2つの資料をどのように読めばよいかをご紹介します。 点検対象のAPI 点検対象は、一般に公開しているPublic APIだけではありません。 自社開発のWebアプリケーションやモバイルアプリケーションから利用するAPI、パートナー企業向けAPI、認証後にのみ利用できるAPIなども含め、インターネット経由で到達可能なAPIはすべて対象として考えてください。 また、インターネットから直接は到達できないAPIであっても、インターネットから到達可能なAPIの先で呼び出されるものは、同様に点検対象とします。 「利用者を限定しているから」「開発者しか使わないから」「社内向けだから」といった理由だけで、基本的なセキュリティ対策を省略できるわけではありません。 ステージング環境や検証環境についても、インターネットから到達可能であれば同様です。 OWASP API Security Top 10 まずはOWASP API Security Top 10を確認することをお勧めします。 NIST SP 800-228 は対策の資料として非常に良いものですが、OWASP API Security Top 10と比較すると抽象的だったり、あるいは細かすぎたりで、「今すぐチェックしたい」というニーズに対して少々わかりづらいのが難点です。 その点、OWASP API Security Top 10は、今すぐ確認するためのチェック観点として活用できるため、まずはこちらを使いましょう。 Top 10を上から確認するのも良いですが、アクションリストとして分類すると、以下のように分類できます。 プラットフォーム使い方点検対象: プラットフォームの使い方の点検である程度がカバーできるもの 設計点検対象: ビジネス要求や設計に依存するので、すぐには修正しづらいもの ここからはそれぞれの項目と、点検項目の代表例を記載します。 詳しくは直接OWASP API Security Top 10をご参照ください。 プラットフォーム使い方点検対象 今すぐ何か対策をしなければならない場合は、まずはプラットフォームの使い方の点検で見直せる部分がある項目をお勧めします。 一般的なREST APIであれば、以下はAPI Management等の基盤で対策できることが多いので、ぜひ点検してみてください。 API2 Broken Authentication (認証の不備) OAuthやOIDC等の認証フローは変更を加えていないか。加えていれば、脆弱性はしっかり対策できているか。 認証強度に不備はないか。例えば、ユーザー認証にAPIキーを利用していないか。 トークンの署名・有効期限などが適切に検証されているか API4 Unrestricted Resource Consumption (制限のないリソース消費) 流量制御、特にRate Limitは、システム間連携も含め全てのAPIクライアントとの間で設定されているか。 流量制御は、キューイングするだけでなく、システムの処理能力を超える場合に備えて受付拒否も活用できているか。 大量データの抜き出しに制約・検知がかけられているか。 1リクエストで取得・処理できるデータ量や処理時間に上限が設定されているか。 API8 Security Misconfiguration (セキュリティの設定ミス) TLS、CORS、利用可能なHTTPメソッドなどの設定は適切か。 デバッグ用設定や不要な機能が有効なままになっていないか。 エラーやログにセンシティブな情報が含まれていないか。 API9 Improper Inventory Management (不適切なインベントリ管理) 組織が持つAPIがカタログ化されていて、管理対象から漏れているものがないか。 本番環境だけでなく、ステージング環境や開発環境なども含め、全ての環境が保護されているか。 古いバージョンはリタイアできているか。 なお、システム間連携などでは、API Gatewayのようなプラットフォームを経由せずにAPI通信を行っているケースも見かけます。 しかし、内部のシステム間通信であっても、認証・認可、流量制御、通信の保護、ログや監視といったセキュリティコントロールが不要になるわけではありません。 そのため、こうした通信についても、GatewayやService Meshなどを利用して、必要なセキュリティコントロールを適用できる仕組みを用意することを検討してください。 どの通信に、どのようなコントロールを適用するべきかについては、後ほど紹介するNIST SP 800-228が参考になります。 設計点検対象 こちらはどうしても設計の見直しから対策が必要になるものです。 場合によってはビジネス要求にさかのぼる必要があったり、あるいはAPIの仕様変更に伴い、APIクライアント側にも修正が入るなど、対策が大規模になりがちです。 上記にプラットフォームレベルですぐできることをリストアップしてはみたものの、やはり設計がしっかりしていないと守り方にも限界があるのも事実です。 まずは代表的な設計不備がないか、簡易チェックとして使えるように例を出してみました。 API1 Broken Object Level Authorization (オブジェクトレベル認可の不備) オブジェクト (例えばDBのレコード) の単位でアクセス権がコントロールされているか。 例えば /users/{id} というエンドポイントで、IDだけ書き換えると他の人のデータを抜き出せる状態ではないか。 API3 Broken Object Property Level Authorization (オブジェクトプロパティレベル認可の不備) 一つのAPIエンドポイントが扱っている属性の中に、センシティブさの異なる属性が紛れていないか。 利用者が参照・更新できる属性が適切に制限されているか。 API5 Broken Function Level Authorization (機能レベル認可の不備) HTTPメソッドの一つ一つに適切なアクセスコントロールが設定されているか。HTTPメソッドを書き換えただけでアクセスできるようになっていないか。 例えば /users/all のように管理者向け機能がある場合、一般ユーザーからアクセスできないようにアクセスコントロールが設定されているか。 API6 Unrestricted Access to Sensitive Business Flows (機密性の高いビジネスフローへの制限のないアクセス) 自動化されることでビジネス上問題となる処理を特定できているか。 例えば、買い占め、予約枠の占有、大量投稿など、APIとしては正常な操作でも、大量・自動実行されるとビジネス的には問題になる処理に制限や検知の仕組みがあるか。 API7 Server Side Request Forgery (サーバーサイドリクエストフォージェリー) 外部や他のシステムから受け取ったURLにアクセスする場合、渡されたURLの検査の仕組みがあるか。 API10 Unsafe Consumption of APIs (APIの安全でない使用) 外部や他のシステムのAPIを「信頼できる相手だから安全」と考え、通信・認証・レスポンスの検証を弱めていないか。 API7はURLを受け取ってそこに接続する場合の接続先URL、API10は接続した結果として受け取ったレスポンスを対象とします。 NIST SP 800-228 OWASP API Security Top 10で、まずは代表的な問題がないかを確認したら、次にNIST SP 800-228を参照してみましょう。 NIST SP 800-228はCloud Native環境におけるAPI保護を主題とした資料ですが、APIに対するセキュリティコントロールの考え方そのものは、Cloud Nativeではないシステムや、システム間連携のAPIを点検する際にも参考にできる観点が多くあります。 資料名や対象範囲に構えすぎず、必要なところから参照するとよいでしょう。 例えば、以下のような場面で活用できます。 OWASP API Security Top 10で問題が見つかったときに、「どこまで対策すべきか」を考えるためのベストプラクティスとして APIセキュリティを一度きりの点検で終わらせず、今後も継続的に見直す仕組みを作るための参考として 設計、開発、デプロイ、実行、運用など、APIライフサイクル全体にわたって弱点がないかを確認するために 外部公開APIだけでなく、マイクロサービス間やシステム間のAPI通信にも見落としがないかを確認するために OWASP API Security Top 10が「よくある問題を見つけるための入口」だとすれば、NIST SP 800-228は、その先で「どこまで、どのように守るか」を考えるための資料として使うと読みやすくなります。 まずはざっとチェックしたい場合、リスクカテゴリ別に整理された付録Dや、APIライフサイクル段階別に推奨コントロールを整理した付録Eから確認すると、全体像をつかみやすくなります。 まとめ ここまで読むと、「どれも当たり前のことでは？」と思われるかもしれません。 実際、どれも特別に難しい話ではありません。 これがユーザー向けのWeb画面やモバイルアプリのインターフェースであれば、誰に何を見せるのか、どの操作を許可するのか、不要な情報を表示していないか、といった点は比較的丁寧に設計するはずです。 ところがAPIになると、「これは社内からしか使わないAPIだから大丈夫」「利用者は自分たちだけだから、そこまで厳密にしなくてもよい」といった油断が入りやすくなります。 あるいは、「開発者向けのインターフェースだから多少不親切でもよい」「同じ開発者同士なのだから悪用はしないだろう」といった油断もあります。 しかし、APIの開発意図は攻撃する側には関係ありません。 攻撃者はさまざまな手法でアクセス可能なAPIを特定し、接続を試みます。一般公開していないAPIであっても、存在を特定される可能性はあります。 もし今まで扱ってきたAPIの中に、「内部向けだから」「開発者向けだから」という理由で対策を緩めたものに心当たりがあれば、そのAPIこそ、ぜひ時間をかけて点検してみてください。 まずはOWASP API Security Top 10を使って、よくある抜けがないかを確認する。そして必要に応じてNIST SP 800-228を参照し、ライフサイクル全体で対策に漏れがないかを見直す。 今回の記事が、その最初のきっかけになれば幸いです。

こんにちは。SSAの瀬戸です。 JBoss EAP 7のELSが延長されました。 ELS-1が2027年10月末までだったのが、2030年12月末(もともとのELS-2終了日)まで伸びています。 これによりセキュリティパッチを受け取れる期間が伸びました。 また、ELS-2も2030年12月末から2031年12月末まで伸びています。 詳細については、Red Hat Application Services 製品のアップデートとサポートポリシーのページを参照してください。 access.redhat.com

こんにちは Cloud 担当の Specialist 花田です。 access.redhat.com と言う Knowledge Base が出ているのですが、 ROSA ( Classic / HCP ) において、ある AWS の IAM Role の作成が必須化されます。現時点では、 2026年10月1日から 、必須化を予定しています。 この IAM Role は “ OCM IAM Role” と呼ばれていたもので、以前から存在してはいたのですが、GUI ( Hybrid Cloud Console ) を使って ROSA Cluster をインストールする時だけ必須とされていました。 今後は CLI のインストールをする場合も必須 となり、さらに 既存の ROSA Cluster (Classic/HCP) 環境でも(現状 OCM IAM Role が存在していない場合は) 追加で作成が必要になります。 HCC( Hybrid Cloud Console) / OCM (OpenShift Cluster Manager)とは？ Red Hat の製品を購入すると、サポートを受けたり、一般には非公開の Knwoledge Base を見る事ができるようになります。そのための前提条件の一つとして、 Red Hat Customer Portal のユーザーID を作成する必要があります。 Red Hat Customer Portal ユーザーID を使うと、Web上に存在するRed Hat 製品を管理するための” Hybrid Cloud Console ” (図1：右上) 機能が使えるようになっています。 Hybrid Cloud Console は、 RHEL 、 OpenShift 、 Ansible 等の Red Hat 製品を管理するためのツールで、 OCM ( OpenShift Cluster Manager ) はその中の OpenShift Cluster を管理するためのツールです。 Red Hat Customer Portal と Hybdrid Cloud Console と OCM(OpenShift Cluster Manager) 図1：Red Hat Customer Portal と Hybrid Cloud Console と OpenShift Cluster Manager self-managed OpenShift は、 OCM の使用は任意ですが、 ROSA の場合は、クラスター管理操作のための必須機能になっています。さらに ROSA は、 Hybrid Cloud Console からGUI を使ったインストールもできるようになっており、それを行うためには OCM IAM Role の作成が必要でした。 Hybrid Cloud Console が、 AWS Account の情報を取得するためにこの OCM IAM Role が使用されていました。 今回の変更で、 Hybrid Cloud Console GUI を使った ROSA のインストールをするかどうかに関わらず、全ての環境で OCM IAM Role の作成が必要になります。 必要な作業 Knowledge Base 内には、あまり詳細が書かれていないのですが、今回の OCM IAM Role の作成の必須化は、 セキュリティを高めるため に導入されます。 そのため、 既に Cluster を作成済の環境でも追加で OCM IAM Role の作成が必要になります。 作業を開始するにあって、 aws CLI と rosa CLI がセットアップされた環境で、以下のコマンドで rosa CLI で OCM にログインします。 rosa login この時、ログインする Red Hat Customer Portal アカウントを間違えないように気を付けてください。 A) 新規にCLIで ROSAをインストールする / 既存環境だが今後も新規に ROSA Clusterを作成する予定がない (最小権限 --no-console ) ここで言う "CLI" は terraform などのツールを含む、すべての Hybrid Cloud Console GUI 以外のインストールを指します。 以下のコマンドを実行して、 OCM IAM Role を作成します。後述しますが、これで作成される IAM Role は、一番少ない権限を持ちます。(作成される権限については後ほど解説します） rosa create ocm-role --no-console --prefix [your_chosen_prefix] インストール以外の目的で OCM を使う場合がある場合でもこの権限で十分です。例えば、OCM上で ROSA Cluster のステータスを見たり、Update などを行う必要がある場合もこの権限で問題ありません。 B) 新規にGUIでROSA をインストールする/ 既存環境だが今後、新規にGUIでインストールする予定がある(権限小さめ standard ) もし Hybrid Cloud Console GUI を使用して ROSA をインストールする、既存環境で今後、その必要がある場合は、以下のコマンドで、 OCM IAM Role を作成します。 既に Hybrid Cloud Console GUI を使用して、一度 ROSA をGUIインストールをした環境であるのであれば、 rosa list ocm-role で OCM IAM Role が確認してみてください。もし既存の OCM IAM Role が存在するのであれば作業の必要はありません。 rosa create ocm-role --prefix [your_chosen_prefix] C) GUIでROSA をインストールする必要がある場合(権限大きめ --admin ) これは、現時点では ROSA Classic Cluster 専用のモードです。 Hybrid Cloud Console GUI を使って ROSA Classic Cluster を作成する際に、 OIDC Config と Operator 用の IAM Role の作成も GUI から行う事ができます。これらの操作を Hybrid Cloud Console の GUI から行いたい場合は、以下のコマンドでの OCM IAM Role の作成が必要です。 既に Hybrid Cloud Console GUI を使用して、一度 ROSA をGUIインストールをした環境であるのであれば、 rosa list ocm-role で OCM IAM Role が確認してみてください。もし既存の OCM IAM Role が存在するのであれば作業の必要はありません。 rosa create ocm-role --admin --prefix [your_chosen_prefix] ROSA Classic Cluster の場合は、 Hybrid Cloud Console GUI から作成できる設定の量に応じて standard (CLIのフラグは無指定) と --admin の2種類があります。 ちなみに --admin の OCM IAM Role を作成したとしても Account IAM Role と呼ばれる IAM Role は、 CLI から作る必要があるので、 GUI からの完全なインストールは ROSA Classic Cluster でもできません。(ですので、個人的には、現時点で GUI を使ったインストールというのは、ほとんどのケースで、それほどメリットが無いと考えています) 作成された OCM IAM Role の確認 以下のコマンドで作成された OCM IAM Role が確認可能です。 rosa list ocm-role 実際に作成される IAM Role が持つ Policy 一番の関心毎は、作成された OCM IAM Role にどのような IAM Policy がアタッチされているかだと思いますので、中身を見ていきます。 なお、作成された OCM IAM Role は、OCM 経由で各ユーザーが使用するものです。Red Hat SRE は、この OCM IAM Role を使用しません。また、実際に誰がどのタイミングで呼び出されているかは、各 AWS Account 内の Cloud Trail にログが残りますので確認可能です。 A) --no-console の場合 以下は、 --no-console で作成した OCM IAM Role にアタッチされる IAM Policy です。 --no-console モードで作成した場合、 IAM Policy が持っている Action は、 iam:GetRole だけです。 NoConsole-OCM-OCM-Role-Policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:GetRole", "Resource": "*", "Condition": { "StringEquals": { "iam:ResourceTag/red-hat-managed": "true", "iam:ResourceTag/rosa_role_type": "OCM" } } } ] } B) standard (CLIフラグ無し) の場合 standard モードで作成した場合は、少し増えますが、こちらもView 系の action のみです。 StandardOCM-OCM-Role-xxxxxx-Policy { "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeSubnets", "ec2:DescribeVpcs", "ec2:DescribeRegions", "ec2:DescribeRouteTables", "ec2:DescribeInstanceTypeOfferings", "iam:GetRole", "iam:ListRoles", "iam:ListRoleTags", "iam:GetOpenIDConnectProvider", "iam:GetPolicy" ], "Effect": "Allow", "Resource": "*" } ] } C) --admin の場合 (現時点では) ROSA Classic 限定の、 --admin オプションを使用した OCM IAM Role を作成した場合は、以下のような IAM Policy が standard で作成される IAM Policy に 追加で アタッチされます。 AdminOCM-OCM-Role-xxxxxx-Admin-Policy { "Version": "2012-10-17", "Statement": [ { "Action": [ "iam:AttachRolePolicy", "iam:CreateOpenIDConnectProvider", "iam:CreatePolicy", "iam:CreatePolicyVersion", "iam:CreateRole", "iam:DeleteOpenIDConnectProvider", "iam:DeletePolicyVersion", "iam:DeleteRole", "iam:DetachRolePolicy", "iam:GetOpenIDConnectProvider", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:GetRole", "iam:ListAttachedRolePolicies", "iam:ListPolicies", "iam:ListPolicyTags", "iam:ListPolicyVersions", "iam:PutRolePermissionsBoundary", "iam:TagOpenIDConnectProvider", "iam:TagPolicy", "iam:TagRole" ], "Effect": "Allow", "Resource": "*" } ] } 他の OCM IAM Role では View 系の Action しかなかった一方で、こちらでは”Create” “Delete” 系のアクションが含まれています。 Security に厳しい環境では、この IAM Policy の導入には物言いが付く可能性があると思います。 複数AWS アカウントを管理している場合の考慮 普段は気にする事はあまりないと思いますが、ROSA の使用には、 AWS Account と Red Hat Customer Potal のユーザー・アカウントが所属する Organization ID を紐付ける必要があります。 Hybrid Cloud Console の右上の Org ID の所に表示されている数字が Organziation ID です(図2)。 Customer Portal User は、必ず Organization に所属しており、自身も ユーザー・アカウントと同時に作られる Organization の管理者になっています。 図2: OCM (Hybrid Cloud Console) の Organization ID また、 Organization ID は、 rosa list ocm-role コマンドでも確認できます。 $ rosa list ocm-role I: Fetching ocm roles ROLE NAME ROLE ARN LINKED ADMIN AWS Managed CONSOLE ACCESS myhcpcluster-OCM-Role-13245678 arn:aws:iam::522814712345:role/myhcpcluster-OCM-Role-13245678 Yes No No Yes $ rosa whoami AWS ARN: arn:aws:iam::522814712345:user/open-environment-674n6-admin AWS Account ID: 522814712345 AWS Default Region: ap-northeast-1 OCM API: https://api.openshift.com OCM Account Email: yhanada@redhat.com OCM Account ID: 1cA88cMwW02hEEier9oabcd1234 OCM Account Name: Yuhki Hanada OCM Account Username: yuhkih1234 OCM Organization External ID: 13245678 OCM Organization ID: 12A88XNl8ao46OeY2u7sS3abcdef OCM Organization Name: Yuhki Hanada $ ROSA Cluster を、ある AWS Account 内に作成するようなシンプルな環境では、一つの OCM の Organization ID に対して、一つの AWS Account が紐付いています。 この紐付けは、 OCM IAM Role を作成した時に自動的に行われているので、ユーザーが意識する事はありません。 図3: OCM Organization と AWS Account ID の紐付け(1対1) この紐付けは rosa list ocm-role で確認が可能です。 # rosa list ocm-role I: Fetching ocm roles ROLE NAME ROLE ARN LINKED ADMIN AWS Managed CONSOLE ACCESS myprefix-OCM-Role-13245678 arn:aws:iam::22814712345:role/myprefix-OCM-Role-13296330 Yes No No Yes # となっている場合、 OCM Organization ID は、 13245678 ( ROLE NAME の最後) で、 AWS Account は、 22814712345 ( ROLE ARN 内)である事がわかります。 LINKED のフラグが Yes であれば、これらが紐付けられている事を示しています。 もし ROSA Cluster が複数あり、2つの AWS Account に ROSA Cluster が分散している場合は、以下の図のように、それぞれの AWS Account に対して OCM IAM Role を作成する必要があります。 図4: OCM Organization と AWS Account ID の紐付け(1対2) 上記の構成の場合は、接続先の AWS account を切り替えて、それぞれの AWS Account で OCM IAM Role を前述のコマンドで作成すれば OK です。 実際の Knowledge Base には、もう少し構成が複雑なケースについても記載がありますので、上記より複雑な構成の場合は、Knowledge Base を参照してください。

こんにちは、ソリューションアーキテクトの川田と申します。 現在は、パートナー様を担当させていただいております。 突然ですが、OpenShiftをインストールする方法は、1つではありません。 環境がオンプレミスなのかクラウドなのか、インターネット接続が可能なのか閉域なのか、どこまでカスタマイズを行いたいかなどの要件によって、複数のインストール方式からご選択いただくことが可能です。 この記事では、その中でも特にオンプレミスの閉域、エアギャップ環境でニーズが高い Agent-based Installerを利用したインストール について、手順書を作成しましたのでご紹介します。 github.com 免責事項 本手順書はRed Hatの公式ドキュメントではなく、すべての環境や構成での動作を保証するものではありません。 本手順書の利用により正常にインストールできなかった場合や、その他の問題が発生した場合について責任を負いかねます。 実際の環境へ導入する際は、利用するOpenShiftのバージョンに対応したRed Hat公式ドキュメント、サポート対象の構成、必要な各要件もあわせて十分にご確認ください。 目次 OpenShiftのインストール方式おさらい Agent-based Installerを利用した閉域環境へのOpenShiftのインストール 主な手順の流れ 基本の手順書について (オプション) 検証を行うための手順書について おわりに OpenShiftのインストール方式おさらい OpenShiftのインストール方式には、主に以下の4種類があります。 IPI（Installer-provisioned infrastructure） Installerで、対応基盤のサーバー、ネットワーク、ロードバランサー、bootstrapノードなどを作成・設定し、OpenShiftの導入まで進める方式です。DNSなど一部の設定も、対応する基盤ではInstallerが自動で行います。 対応するクラウドやオンプレミス基盤で、基盤構築を含めて自動化し、導入作業を簡素化したい場合に向いています。 UPI（User-provisioned infrastructure） InstallerでOpenShiftの設定を作成し、サーバー、ネットワーク、ロードバランサー、DNS、bootstrapノードなどの基盤は利用者側で準備する方式です。IPIより作業量は増えますが、基盤構成のカスタマイズ性が高くなります。 既存基盤を利用する場合や、組織の要件に合わせて基盤を個別に設計・管理したい場合に向いています。 Assisted Installer Red Hatが提供するHosted ServiceをWeb画面から利用し、Discovery ISOを作成して各ノードを起動する方式です。専用の一時bootstrapノードは不要で、対話形式で導入を進められます。 インターネットへ接続できるオンプレミス環境で、Web画面を使って簡単に導入したい場合に向いています。SNO (Single Node OpenShift)にも対応しています。 Agent-based Installer Installerと設定YAMLを使用してCLIでAgent ISOを作成し、そのISOから各ノードを起動する方式です。専用の一時bootstrapノードは不要で、Red HatのHosted Serviceへ接続せずに導入できます。 インターネットへ接続できないオンプレミスの閉域環境で、OpenShiftを導入したい場合に向いています。SNOにも対応しています。 オンプレミス環境へのインストールであれば、シンプルさを重視する場合はAssisted Installerが便利です。 一方で、セキュリティポリシーやネットワーク設計上の理由からインターネットへ接続できない閉域・エアギャップ環境をご利用の方も多くいらっしゃるかと存じます。 そのような環境に適したインストール方式が、 Agent-based Installerによるインストール です。 Agent-based Installerを利用した閉域環境へのOpenShiftのインストール Agent-based Installerによるインストールは、外部インターネットへ接続できない閉域環境でもご利用いただけるインストール方式です。クラスター全体と各ノードの設定を組み込んだAgent ISOを作成し、そのISOからOpenShiftの各ノードを起動してインストールを行います。 再掲となりますが、作成した手順書はこちらのGitHubレポジトリにございます。 GitHub - yukarh/openshift_airgap_install · GitHub 主な手順の流れ 手順書の中では、閉域環境へのOpenShiftインストールを以下の流れで整理しています。 OpenShiftの構成や、各要件（ネットワーク、DNS、NTP など）を確認する インターネット接続が可能な環境で、OpenShift CLI、Installer、 oc-mirror など、必要なプログラムやファイルを準備する oc-mirror を使用して、OCPリリースやOperatorのイメージを取得し、閉域へ搬送できる形式で保存する 準備したプログラム、設定ファイル、認証情報、イメージを閉域内へ搬入する 閉域内でミラーレジストリーを準備し、証明書や認証情報などを設定する oc-mirror を使用して、搬入したOCPリリースやOperatorのイメージをミラーレジストリーへ格納する Agent-based Installerで使用する各YAMLファイル（ install-config.yaml と agent-config.yaml ）を作成する Installerを使用してAgent ISOを作成し、そのISOから各OpenShiftノードを起動する InstallerからOpenShiftのインストール完了を確認し、クラスターの状態を確認する 基本の手順書について 基本の手順書はレポジトリ内の以下のファイルです。 openshift_agentbasedinstall_airgap.md openshift_airgap_install/openshift_agentbasedinstall_airgap.md at main · yukarh/openshift_airgap_install · GitHub 閉域内で既存のDNS / NTPを利用でき、かつ手順の中で必要な各汎用パッケージも導入済みの環境を想定しています。 (オプション) 検証を行うための手順書について ゼロから一連の流れを試してみたいという方向けに、DNS、NTP、汎用パッケージの準備まで含めた手順書も作成しました。 openshift_agentbasedinstall_airgap_sample.md openshift_airgap_install/openshift_agentbasedinstall_airgap_sample.md at main · yukarh/openshift_airgap_install · GitHub また、この手順を手順書内のサンプル値のまま検証するためのAWS CloudFormationテンプレートも用意しています。 このテンプレートをご利用いただく場合、agent iso生成までの手順をお試しいただけます。 ocp-airgap-aws-test-cloudformation.yaml openshift_airgap_install/ocp-airgap-aws-test-cloudformation.yaml at main · yukarh/openshift_airgap_install · GitHub おわりに この記事では、オンプレミスの閉域、エアギャップ環境でニーズが高いAgent-based Installerを利用したインストールについて、手順書をご紹介しました。 本手順書が、OpenShiftを導入、構築を検討する際のご参考になれば幸いです。 関連記事 今さら聞けない!? OpenShift4の多すぎるインストール方式をおさらいする - 赤帽エンジニアブログ ゼロからはじめるOpenShift Virtualization（1）OpenShiftのインストール - 赤帽エンジニアブログ 閉域環境への新しい OpenShift Virtualization のインストール方法を試してみよう！ - 赤帽エンジニアブログ オンプレOpenShiftのインストール練習を爆速で回す！環境構築・破棄ツール ocp_create_vm の紹介 - 赤帽エンジニアブログ

Red Hat で Java を担当している伊藤ちひろです。 本記事は、弊社のJakarta EEアプリケーションサーバであるJBoss EAPから、Oracle社のOracle Databaseの機能であるOracle Label Securityを使う方法を紹介します。 サンプルコードはこちらです。 https://github.com/chiroito/jboss-eap-oracle-label-security JBoss EAPでも、Oracle JDBCのプロキシ認証を組み合わせれば、Oracle Label Securityを使えます。JBoss EAPにOracle Label Security専用の機能を追加する必要はありません。通常のOracle JDBCドライバーとデータソースを用意し、アプリケーションが接続をOracle固有の OracleConnection へ変換して、ログイン中の利用者へセッションを切り替えます。 Oracle Label Security（OLS）は、行に付けたラベルと利用者の認可を比較し、参照または更新できる行をデータベース側で制御する機能です。本稿では、OLSのポリシー設計や構築手順は扱いません。OLSのしくみと設定方法は、Oracleの公式情報を参照してください。 今回の例では、 TODO_APP ユーザーが所有する todo_items 表へOLSのポリシーを適用済みとします。アプリケーションの利用者はAliceとBobです。Aliceには機密情報を参照できるラベルを割り当て、Bobには機密情報を参照できないラベルを割り当てています。 JBoss EAPの接続を利用者のセッションへ切り替える この構成の要点は、データベース接続を TODO_APP で作り、SQLを実行する直前にAliceまたはBobのセッションへ切り替えることです。 Oracleの用語では、 TODO_APP が「プロキシユーザー」であり、AliceとBobが「クライアントユーザー」です。本稿では役割を直感的に区別するため、 TODO_APP を「接続ユーザー」、AliceとBobを「アプリケーションユーザー」と呼びます。 処理の流れは次のとおりです。 AliceまたはBob │ │ アプリケーションへログイン ▼ JBoss EAP │ │ TODO_APPでデータソースから接続を取得 ▼ Oracle Database │ │ プロキシセッションをAliceまたはBobへ切り替える ▼ TODO_APP.TODO_ITEMSをWHERE句なしで検索 │ │ OLSが利用者のラベルに応じて行を絞り込む ▼ 利用者ごとに異なる検索結果を返す この方法では、SQLへ利用者ごとの条件を追加しません。アプリケーションは同じ SELECT 文を実行し、どの行を返すかはOLSに任せます。 Oracle JDBCのプロキシ認証では、接続済みのユーザーから別のユーザーのセッションを作り、そのセッションへ接続を切り替えます。 TODO_APP として作成した物理接続を維持したまま、SQLを実行するセッションだけをAliceまたはBobへ切り替えられます。 データベース側の準備は完了しているものとする データベース側では、OLSとプロキシ認証を使える状態まで準備しておきます。本稿が前提とする状態は次のとおりです。 TODO_APP ユーザーが todo_items 表を所有している todo_items 表へOLSのポリシーが適用されている AliceとBobがデータベースユーザーとして作成されている Aliceには機密情報を参照できるOLSの認可が設定されている Bobには機密情報を参照できないOLSの認可が設定されている AliceとBobが TODO_APP を経由して接続できるようにプロキシ認証が設定されている 本稿では、これらのデータベース設定を作成する手順は扱いません。JBoss EAPから、設定済みのOLSを利用する部分に焦点を当てます。 アプリケーションへ渡すユーザー名は、認証済みの利用者から取得します。HTTPリクエストのパラメーターや入力フォームから受け取った文字列を、そのまま openProxySession へ渡してはいけません。利用者が任意に ALICE を指定できると、アプリケーション認証とデータベースの認可を結び付ける前提が崩れるためです。 Servletを使う場合は HttpServletRequest#getUserPrincipal() 、Jakarta RESTを使う場合は SecurityContext#getUserPrincipal() のように、アプリケーションサーバーが認証した主体からユーザー名を取得します。今回は簡略化のため、入力された文字列を使っています。 Oracle JDBCドライバーとデータソースを設定する JBoss EAP側では、Oracle JDBCドライバーをモジュールとして登録し、 TODO_APP で接続する通常のデータソースを作ります。OLS専用のデータソース設定はありません。 本稿の例では、JDK 17以上で利用できる ojdbc17.jar を使用します。 ojdbc17.jar はJDBC 4.3に対応し、Jakarta APIと互換性があります。 次のコマンドをJBoss EAPの管理CLIで実行します。 module add --name=com.oracle.ojdbc --resources=target/ojdbc17.jar /subsystem=datasources/jdbc-driver=oracle:add( \ driver-name=oracle, \ driver-module-name=com.oracle.ojdbc, \ driver-class-name=oracle.jdbc.OracleDriver) data-source add \ --name=TodoDS \ --jndi-name=java:jboss/datasources/TodoDS \ --driver-name=oracle \ --connection-url=jdbc:oracle:thin:@//localhost:1521/ORCLPDB1 \ --user-name=TODO_APP \ --password=todo_app \ --use-ccm=true \ --enabled=true module add は、 ojdbc17.jar を com.oracle.ojdbc というJBoss Moduleとして登録します。その次のコマンドは、登録したモジュールを oracle というJDBCドライバーとしてデータソースサブシステムへ追加します。 TodoDS は、 TODO_APP のユーザー名とパスワードで物理接続を作ります。AliceとBobの認証情報は、データソースには設定しません。AliceまたはBobへの切り替えは、接続を取得したあとのプロキシ認証でおこないます。 JBoss EAPでは、JDBCドライバーをコアモジュールとして登録したあと、通常の data-source add コマンドで非XAデータソースを作成できます。 作成したデータソースは、アプリケーションをデプロイする前に接続を確認できます。 /subsystem=datasources/data-source=TodoDS:test-connection-in-pool この確認でわかるのは、 TODO_APP としてOracle Databaseへ接続できることです。AliceまたはBobへのセッション切り替えと、OLSによる行の絞り込みは、アプリケーションを実行して確認します。 アプリケーションからOracleConnectionを参照できるようにする アプリケーションには、Oracle JDBCドライバーのモジュールを明示的な依存関係として追加します。 OracleConnection はJDBC標準の Connection にはないOracle固有のAPIであるため、データソースを設定しただけではアプリケーションから参照できません。 JBoss EAPは、モジュール単位でクラスの参照関係を管理します。アプリケーションからベンダー固有のJDBCクラスを利用する場合は、 MANIFEST.MF または jboss-deployment-structure.xml でドライバーモジュールへの依存関係を宣言します。 WARの場合は、 WEB-INF/jboss-deployment-structure.xml へ次の内容を記述します。 <? xml version = "1.0" encoding = "UTF-8" ?> <jboss-deployment-structure> <deployment> <dependencies> <module name = "com.oracle.ojdbc" /> </dependencies> </deployment> </jboss-deployment-structure> この設定により、アプリケーションから com.oracle.ojdbc モジュール内の oracle.jdbc.OracleConnection を参照できるようになります。 ビルド時にも OracleConnection が必要になるため、 pom.xml ではOracle JDBCドライバーを provided スコープで参照します。 <dependency> <groupId> com.oracle.database.jdbc </groupId> <artifactId> ojdbc17 </artifactId> <version> ${oracle.jdbc.version} </version> <scope> provided </scope> </dependency> provided は、コンパイル時にはクラスを参照するものの、実行環境から提供されるためWARには含めないことを表します。Oracle JDBCのアーティファクトは、Maven Centralで com.oracle.database.jdbc グループから取得できます。 ビルドに使うOracle JDBCドライバーと、JBoss EAPのモジュールへ登録するドライバーは同じバージョンにそろえます。 WARへ別の ojdbc17.jar を同梱すると、同じ名前の OracleConnection が異なるクラスローダーから読み込まれる可能性があります。その場合は、次のような例外が発生する原因になります。 java.sql.SQLException: IJ031030: Not a wrapper for: oracle.jdbc.OracleConnection JBoss EAPのモジュールに登録したドライバーだけを実行時に使用し、アプリケーションは jboss-deployment-structure.xml を通じて同じクラスを参照する構成にします。 OracleConnectionでプロキシセッションを開く アプリケーション側の要点は、JBoss EAPから受け取った Connection を OracleConnection へ unwrap し、 openProxySession でアプリケーションユーザーへ切り替えることです。 JBoss EAPのデータソースから返される接続は、JBoss EAPが管理するラッパーです。アプリケーションから物理接続を直接取得するのではなく、JDBCの Connection#unwrap を使ってOracle固有の接続を取得します。JBoss EAPの公式情報でも、ベンダー固有のJDBC APIを利用する方法として unwrap が示されています。 TodoRepository は次のように実装します。 package com.example.todo; import jakarta.annotation.Resource; import jakarta.enterprise.context.ApplicationScoped; import oracle.jdbc.OracleConnection; import javax.sql.DataSource; import java.sql.Connection; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.sql.SQLException; import java.util.ArrayList; import java.util.List; import java.util.Properties; @ApplicationScoped public class TodoRepository { @Resource (lookup = "java:jboss/datasources/TodoDS" ) DataSource dataSource; public TodoPageData findVisibleTodos(String userName) throws SQLException { Connection connection = dataSource.getConnection(); try { // JBoss EAPが管理する接続から、 // Oracle固有の接続を取得する。 OracleConnection oracleConnection = connection.unwrap(OracleConnection. class ); Properties proxyProperties = new Properties(); proxyProperties.put( OracleConnection.PROXY_USER_NAME, userName); // TODO_APPの接続を、認証済みの // アプリケーションユーザーへ切り替える。 oracleConnection.openProxySession( OracleConnection.PROXYTYPE_USER_NAME, proxyProperties); try { List<TodoItem> items = new ArrayList<>(); // 利用者を絞り込むWHERE句は書かない。 // 参照できる行の判断はOLSに任せる。 try (PreparedStatement statement = connection.prepareStatement( "SELECT id, title, done " + "FROM todo_app.todo_items " + "ORDER BY id" ); ResultSet resultSet = statement.executeQuery()) { while (resultSet.next()) { items.add( new TodoItem( resultSet.getLong( "id" ), resultSet.getString( "title" ), "Y" .equalsIgnoreCase( resultSet.getString( "done" )))); } } return new TodoPageData(userName, items); } finally { // 接続をプールへ返す前に、 // プロキシセッションを閉じる。 if (oracleConnection.isProxySession()) { oracleConnection.close( OracleConnection.PROXY_SESSION); } } } finally { connection.close(); } } } OracleConnection.PROXY_USER_NAME には、切り替え先となるAliceまたはBobのユーザー名を設定します。 OracleConnection.PROXYTYPE_USER_NAME を指定して openProxySession を呼ぶと、新しいユーザーのセッションが作られ、以降のSQLはそのセッションで実行されます。 SQLの実行には、引き続きJBoss EAPから取得した connection を使います。 openProxySession は、その接続が内部で使用するOracle Databaseのセッションを切り替えるためです。 このコードで最も重要なのは、プロキシセッションを閉じてから接続をJBoss EAPの接続プールへ返す順序です。 close(OracleConnection.PROXY_SESSION) は、 openProxySession で開いたプロキシセッションだけを閉じます。そのあとで標準の Connection#close を呼び、論理接続をJBoss EAPへ返します。 WHERE句を書かなくても利用者ごとに結果が変わる この実装では、AliceとBobがまったく同じSQLを実行しても、OLSの認可に応じて異なる行が返ります。 Aliceのセッションでは、機密ラベルを含むTODOを参照できます。 Bobのセッションでは、それらの行が検索結果に現れません。 アプリケーションが実行するSQLは、次の一つだけです。 SELECT id, title, done FROM todo_app.todo_items ORDER BY id 利用者を識別する WHERE user_name = ? のような条件はありません。利用者が参照できる行は、現在のデータベースセッションとOLSのラベルで決まります。 アプリケーションコードだけで行の絞り込みを実装すると、別の検索処理で条件を書き忘れるおそれがあります。一方、行の可視性をOLSへ集約すれば、同じポリシーがデータベース側で適用されます。 ただし、OLSがアプリケーション認証を代替するわけではありません。アプリケーションで利用者を認証し、その認証結果を正しいデータベースユーザーへ結び付ける処理は、引き続きアプリケーション側の責任です。 接続プールで使うときの境界を明確にする プロキシセッションは、接続を取得してから返すまでの短い範囲だけで使います。1回のリクエスト内でプロキシセッションを開き、必要なSQLを実行し、必ず閉じる構造にすると、利用者の状態を接続プールへ持ち越しません。 JBoss EAPのデータソースは、物理接続を複数のリクエストで再利用します。そのため、Aliceのプロキシセッションを閉じないまま接続を返すと、次に同じ物理接続を利用するBobの処理へ、Aliceのセッション状態が影響するおそれがあります。 プロキシセッションを閉じると、その接続に関連する Statement と ResultSet も閉じられます。すべてのSQL処理を終えてから close(OracleConnection.PROXY_SESSION) を呼び出し、プロキシセッションをまたいで PreparedStatement を再利用しないようにします。 Jakarta Transactionsのグローバルトランザクションへ参加させる場合は、プロキシセッションを開く順序も設計対象になります。 Oracle JDBCでは、グローバルトランザクションを開始したあとに openProxySession を呼ぶと、新しく作られたセッションがそのトランザクションから外れる場合があります。本稿のような読み取り処理を越えて利用する場合は、トランザクションを始める前にセッションを切り替えられるかを確認します。 JBoss EAPでもOLSの認可をそのまま活用できる JBoss EAPでも、Oracle JDBCドライバーが提供するプロキシ認証を使えば、OLSによる行単位のアクセス制御をアプリケーションから利用できます。 JBoss EAP側で特別なセキュリティ機構を実装するのではありません。通常のデータソースから Connection を取得し、 OracleConnection へ unwrap して、認証済みの利用者へセッションを切り替えることが中心です。 実装では、次の三つの境界を守ります。 アプリケーションユーザーの名前は、アプリケーションの認証結果から取得する Oracle JDBCドライバーはJBoss EAPのモジュールから一つだけ読み込む プロキシセッションは、接続をプールへ返す前に必ず閉じる この構成により、JBoss EAP上のJakarta EEアプリケーションでも、データベースに設定したOLSの認可を利用できます。アクセスできる行をアプリケーションの WHERE 句だけで管理せず、Oracle Databaseのセキュリティ機能へ任せられます。

こんにちは、レッドハットでソリューションアーキテクトをしている石川です。 みなさんvLLM使っていますか？ vLLM はオープンモデルの推論を行うため、多くのユーザーや企業などで利用されているOSSです。 レッドハットは昨年の Neural Magicの買収 を契機として、主要なコントリビューターの一社としてvLLMの開発を推進しています。現在では、vLLMの本体だけではなく、量子化ツールの LLM Compressor 、Speculative Decodingのドラフトモデルを作成する Speculators など、様々なサブプロジェクトについても積極的に取り組んでいます。 そんなvLLMですが、利用する際に悩ましいのが起動時にどんなオプションを与えるか、です。 単にモデルを動かすということだけであれば、オプションを付けずにそのままvLLMを起動すれば良いですが、モデルごとに適切な設定を行い推論を効率化するためには沢山ある起動オプションの中から何を選んで設定するかを検討する必要があります。 突き詰めると、実行するワークロードの特性によって与えるべき設定はケースバイケースとなりますが、このブログ記事では基本的な考え方や、おすすめの設定を紹介したいと思います。 Recipes vLLMのオプション設定を検討する上で、まず確認すべきなのがvLLMコミュニティが公開している recipes.vllm.ai です。 recipes.vllm.ai ここではHugging Faceで公開されている様々なモデルに対し、vLLMのどのバージョンが対応していて、どんな設定をすべきかという情報が載っています。 利用するGPUや、モデルの量子化ごとのパターンも確認できるため、モデルの実行に関わる多くの悩みはこちらのページを見ることで解決することができます。 まずはここで実行したいモデルを検索し、モデルごとに異なる値を設定する --tool-call-parser や、 --reasoning-parser などの基本的な設定値を確認することをおすすめします。 KV Cache量子化 推論を高速に実行する上でKV Cacheは欠かすことができない存在ですが、vLLMでは --kv-cache-dtype によりKV Cacheの量子化を設定することができます。KV Cacheはモデル本体の量子化と比較し外れ値の影響を受け易く、また一部のGPUではハードウェア側の問題によって顕著なパフォーマンスの劣化があったことから、以前は元精度(BF16)のまま取り扱うことが一般的でした。 しかし vLLMやFlash Attentionの様々な改善 を通じて、現在ではパフォーマンスの劣化を抑えながらKV Cacheを量子化することが可能となりました。これにより必要なVRAM量を削減しつつ、トークンスループット向上に寄与しています。 --kv-cache-dtype では fp8 のほか、 Turbo Quantなどの量子化設定をサポート しています。 しかし、以下のvLLMのコミュニティブログで検証された結果を見ると、Turbo QuantではAttention計算時の逆量子化によるオーバーヘッドの影響が大きく、それに伴うトークンスループットの低下が確認されています。 vllm.ai そのため、まずは --kv-cache-dtype には fp8 を設定し、要件に応じて他の値を試すのが良いでしょう。 KV CacheのCPUメモリへのオフロード 以前よりvLLMではOffloading Connectorを利用したKV CacheのCPUメモリ(DRAM)へのオフロードがサポートされていました。しかし、このOffloading Connectorが導入された当時、Attention層は全て一様であることが前提となっており、昨今のモデルで採用されている複数のAttentionタイプ(Sliding Window、Mamba、など)を併用するハイブリッドモデルでの利用がサポートされていませんでした。そのためKV Cacheオフローディングのための機能は存在するが、新しいモデルでは利用できないというジレンマが生じていました。 vLLMのv0.21.0にて、ハイブリッドモデルのメモリを管理するHMA(Hybrid Memory Allocator)がOffloading Connectorでサポートされ、以降のバージョンでは多くのモデルでKV Cacheのオフロードが利用できるようになっています。 DRAMへのオフロードは --kv-offloading-size にて、利用する領域をGiB単位で設定するか、 --kv-transfer-config から詳細を設定することができます。後者の詳しい設定方法については以下のドキュメントを参照してください。 ドキュメントのTipsにも記載がありますが、DRAMにオフロードする容量はVRAMのKV Cache容量の総計より大きい値を設定する必要があります。 docs.vllm.ai Speculative Decoding Speculative Decodingとは小規模なドラフトモデルを利用して、現在から複数先のトークンを予測し、それを本来利用したいモデル（ターゲットモデル）で検証することで、出力の品質を落とさずに高速なトークン出力を可能とする推論のテクニックです。 最近では、ターゲットモデルの一部としてドラフトトークン生成を可能とするMTP(Multi Token Prediction)ヘッドを備えたモデルが公開されたり、ドラフトモデルとして拡散生成モデルを利用するDFlashや、そのアイディアの発展形であるDSparkが公開されるなど、Speculative Decodingに関連した技術の進歩が進んでいます。 リクエスト数が増加しVRAMのメモリ帯域が逼迫すると逆にスループットが低下するため、推論における銀の弾丸というわけではありませんが、体感としての推論速度向上を感じやすく最近では広く利用されるようになっています。 vLLMでは --speculative-config にて設定します。 --speculative-config '{ "method": "dflash", "model": "<draft/model>", "num_speculative_tokens": 5 }' ドラフトモデルについては、モデルプロバイダーが提供するものや、Red Hatが提供するもの、あるいはSpeculatorsを利用して自身でトレーニングしたモデルなどを設定できます。 番外編: Red Hat AI Repository on Hugging Face vLLMの設定ではないですが、レッドハットはHugging Faceのリポジトリ上でさまざまなモデルを公開しています。 huggingface.co 複数の形式で量子化されたメジャーなオープンモデルや、最新のSpeculative Decodingのドラフトモデルなど、現在では700以上のモデルを公開しています。どなたでもダウンロードして利用することができるので、このブログ記事で紹介した設定と合わせ、よければお試しください。 おわりに この記事ではvLLMのおすすめオプション設定方法について紹介しました。レッドハットではvLLMや、分散推論のOSSであるllm-dをプロダクトとして提供しており、併せてエンタープライズレベルでのサポートを提供しています。本番環境での推論環境構築にご興味あればぜひレッドハットへお問い合わせください。

Red Hat のソリューションアーキテクトの瀬戸です。 最近のAIはすごいですよね。毎月のように新しいモデルが発表され、毎日のように新しい驚きがあります。(再) 前回、前々回とJBoss EAPの最新化や、Spring-BootからJSF on JBoss EAPへの移行をAIをつかってやってみました。 また、これ以外にもJakarta MVCも使ってみましたが、いくつかハマりポイントはあったりするものの簡単に移行が出来ています。 rheb.hatenablog.com rheb.hatenablog.com 今回は、JBoss EAPではなく、Quarkus への移行をしてみました。 なお、使用しているAIは前回同様Claude Sonnet 4.5です。少し古いバージョンですので、他のAIでも良好な結果が得られるのではないかと思います。また、AIの特性上同じAIを使っても同じ結果を得られるとは限らない点についてはご了承ください。 Quarkus とは QuarkusはJavaアプリケーションサーバー(フレームワーク)の中では比較的最近できたもので、Spring-BootやJBoss EAPに比べると起動(レイテンシ)やスループットが高いという特徴があります。 QuarkusではデフォルトではServlet APIを実装していない *1 という大きな欠点があるのですが、フォームベースの画面が不要なSPAや、そもそも画面の存在しないインテグレーション用途などでは最適解になるアプリケーションサーバーです。 JBoss EAPはSpring-Bootは汎用的ななんにでも使えるフレームワークですが、Quarkusでは汎用性を捨てて特定の分野に特化した性能を持っています。 乗用車に対するスーパーカーみたいなもので、便利なのですが、すべてをこれに！とはなかなかできないのが難点です。 Quarkusを使用する事でどれくらいリソースの使用量が改善するのかについてはQuarkusの公式サイトを確認してください。 ja.quarkus.io 今回移植したアプリケーション 前回はSpring-petclinicというアプリケーションを基にJBoss EAPに移植しました。 Quarkusでは Quteというテンプレートエンジン があるものの、UIを持ったアプリケーションはとても苦手としています。 なので、フロント部分を Next.js で作ったSPAとすることにしました。SPA化についてはClaude Sonnet 4.5に頑張ってもらってます。 ベースとしたSPA版のSpring petclinicについては次のリポジトリに保存しています。 github.com ちなみに、移行後のQuarkus版については次のリポジトリにあります。 フロントエンド部分(Next.jsで作成した部分)についてはSpring-BootからQuarkusの移行で全く手を加えずに済みました。 AIには移行時にフロント部分は変更しないように指示を出して行っています。 github.com 移行の雑感 今回はすでにSPA化されているアプリケーションをQuarkusに移行しただけという事もあり、その点ではハマる場所は少なかったなという印象です。 Hibernate ORM with Panache Hibernate ORM with Panache はQuarkusで採用されているORMです。Hibernate ORMはJPAの実装ですが、JPA以外の機能もたくさん持っています。Panacheはその一つで、JPAの使いにくさを改善することができます。Entityにアクセサー(getter/setter)を作らなければいけないのを作らなくてもよくなったりします。また、Spring data jpaのようにRepositoryパターンの自動生成をしてくれたり、RailsライクなActive Recordパターンの自動生成をしてくれたりもします。今回はRepositoryパターンで実装しています。Jakarta EE 10時点のJPAではRepositoryパターンの標準化がされていないため、前回はソースコード量が増えてしまいましたが、今回はほぼそのまま、むしろ減りました。 アノテーションの追加 SpringではRepositoryなどにはアノテーションを付けなくても勝手にBeanとしてDIの対象としてくれますが、Quarkusでは必ずアノテーションを指定する必要があります。その点はハマりやすかったです。@Transactional についても注意が必要でした。 @ApplicationScoped public class OwnerRepository implements PanacheRepositoryBase<...> { } 性能の改善 アプリケーションを移行したところ性能は改善しました。AIにまとめさせたところ、次のようなったようです。大きなアプリケーションでは足回りの改善はあまり影響はないですが、小さいアプリケーションでは大きな影響が出てきます。 起動時間の比較 モード Spring Boot Quarkus 改善率 JVM開発モード 3.5秒 2.1秒 40%高速 JVM本番モード 3.2秒 1.8秒 44%高速 メモリ使用量の比較（初回リクエスト後） 項目 Spring Boot Quarkus 改善率 Heap使用量 256MB 128MB 50%削減 Metaspace 85MB 65MB 24%削減 API応答時間（10回平均） エンドポイント Spring Boot Quarkus 改善率 GET /api/owners/1 12ms 11ms 8%改善 GET /api/vets?page=1 8ms 7ms 12%改善 POST /api/owners 18ms 16ms 11%改善 まとめ ということで、今回はSpring BootアプリケーションをQuarkusに移植してみました。事前にSPAにしていることもあり、大きく困ることはなかったという印象です。QuarkusはJBoss EAPやSpring Bootに比べると癖がありますが、ハマればとても強力ですので、ぜひ使ってみてください。 *1 : オプションでServlet APIを使う事もできますが、有効化するとスループットがJBoss EAPとほぼ同等になります。

はじめに 自己紹介 はじめまして、野口と申します。2026年3月に Red Hat へ入社し、現在はアソシエイトコンサルタントとして、OpenShift を中心にお客様の基盤づくりをお手伝いしています。 ただ、私のキャリアはずっと IT 業界だったわけではありません。前職では9年間、自動車の完成車メーカー（OEM）でエンジニアとして開発に携わっていました。 自動車から IT・クラウドの世界へ。一見すると大きな方向転換に見えるかもしれません。実際、文化も職種も専門用語も違い、戸惑うことばかりでした。 そんななか、「これからの社会を支える基盤」をつくるという仕事の本質は、自動車もクラウドも変わらない と感じました。そして学びを進めるほど、自動車業界で培った「安全」の感覚が、そのままクラウド基盤を見る目として活きることに気づいていきました。 この記事で伝えたいこと 自動車を買うとき、安全性能を気にしない人はいないと思います。 では、クラウド基盤を選ぶときはどうでしょうか？ 自動車業界では「安全」は単なる一機能ではなく、設計思想そのものです。そしてその目で OpenShift を見たとき、クラッシュへの備えが何層にも重ねられている ことに気づきました。 この記事では、自動車業界で確立された 1次安全・2次安全・3次安全 という考え方を補助線にして、OpenShift のクラッシュセーフティがどんな層で考えられているのか を、元自動車エンジニアの視点で読み解いてみます。 自動車の安全は3つの段階でできている 自動車の安全技術は、大きく3つの段階に分かれます。 段階 考え方 自動車の例 1次安全（予防安全） そもそも事故を起こさせない 車線逸脱防止、ESC（横滑り防止装置）、ADAS（先進運転支援システム） 2次安全（衝突安全） 事故が起きたときの被害を最小化する エアバッグ、衝撃吸収ボディ 3次安全（事故後対応） 迅速に復旧し、次に活かす EDR（イベントデータレコーダー）、自動通報、コネクティッド この3段階がすべて揃って、はじめて「安全な車」と言えます。どれか1つだけでは不十分です。 そして OpenShift も、この3段階の枠に当てはめて見ることができます。 OpenShift の安全設計を3段階で見る 1次安全：予防安全 — そもそも事故を起こさせない 自動車で言えば、ADAS（先進運転支援システム）にあたる段階です。自動ブレーキや車線逸脱防止のように、「危険な状態そのものを作らせない」という考え方です。 OpenShift では以下の機能がこの役割を果たしています。 機能 何を防いでいるか SCC (Security Context Constraints) コンテナが不必要に高い権限で動くことを防ぐ [1] RBAC (role-based access) 誰が何をできるかを厳密に制御する RHCOS の制御されたイミュータブル設計 ノードの OS が勝手に変更されることを防ぐ [2] ポイントは、これらが「デフォルトで有効」だということです。 自動車で言えば、最近の ADAS はオプションではなく標準装備です。OpenShift も同じで、例えば SCC は全ユーザーに対して最初から restricted-v2 ポリシーが適用されています [3]。「安全を有効にし忘れる」ということが起きない設計です。 また、RHCOS の土台は Red Hat が長年にわたって培ってきた RHEL です。RHEL の Linux カーネルで起動し、RHEL と同じ品質・セキュリティ基準がそのまま適用されています [2]。 さらに、この RHCOS は公式ドキュメントで「Controlled Immutability（制御されたイミュータブル性）」と表現されています [2]。ルートファイルシステムの大部分は読み取り専用で、Machine Config Operator（MCO）がサポートする書き込み先は /etc と /var に限られます [4]。 1次安全のポイント（予防安全） - SCC・RBAC・RHCOS による予防策がデフォルトで有効 - 「安全を有効にし忘れる」ことが構造的に起きない設計 - 危険な状態そのものを作らせない 2次安全：衝突安全 — 起きたときの被害を最小化する どれだけ予防しても、障害はゼロにはなりません。自動車で言えば、エアバッグや衝撃吸収ボディの出番です。 Kubernetes では、ノードに障害が発生すると Pod を健全なノードへ移動させて復旧を図ります。ただし Kubernetes 標準のままでは、Pod の退避が始まるまでにデフォルトで約5分40秒かかります [5]。さらに、障害ノードはそのまま放置されるため、永続ボリューム（PV）が旧ノードに掴まれたまま解放されず、ステートフルなワークロードの復旧がさらに遅れることがあります。 この課題に対処するのが Node Health Check（NHC） と Self Node Remediation（SNR） です。 機能 何をするか Node Health Check（NHC） ノードの異常状態を監視し、修復処理を起動する Self Node Remediation（SNR） 異常ノードを再起動して隔離し、ワークロードを安全に復旧させる NHC はノードの異常（NotReady 等）をデフォルトで5分間監視し続け、一時的な異常ではないと判断してから SNR による修復を起動します。SNR は異常ノードを再起動し、 out-of-service テイントを付与することで Pod を即座に削除します。 ただし1つ補足を。NHC と SNR は OpenShift に最初からインストールされているわけではなく、 Workload Availability for Red Hat OpenShift として提供される Operator 群を OperatorHub から追加する必要があります [6]。追加のサブスクリプションは不要で、OpenShift のサブスクリプションに含まれています。自動車で言えば、標準装備だけどディーラーで有効化してもらう機能のようなイメージです。 2次安全のポイント（衝突安全） - NHC が異常を検知 → SNR が異常ノードを再起動・隔離し、Pod と PV を安全に復旧 3次安全：事故後対応 — 迅速に復旧し、次に活かす 自動車では、事故後に EDR（イベントデータレコーダー）がデータを記録し、コネクティッドサービスが自動で救急に通報します。原因を究明し、次の設計に活かす。このサイクルがあるから、自動車はどんどん安全になってきました。 OpenShift にも同じ仕組みがあります。 機能 自動車で言えば 何をするか クラスターロギング EDR（イベントデータレコーダー） 何が起きたかを記録し、原因究明を可能にする [7] must-gather 事故後の状況記録 ＋ 自動通報 障害時の情報を一括収集し、サポートチームと共有する [8] 特に must-gather は、自動車のコネクティッドサービスに近い存在です。障害が起きたとき、状況を正確に記録してサポートチーム（救急）に伝えることで、迅速な復旧を可能にします。記録して原因を究明し、次に活かす。自動車の安全設計で大事にされているこのサイクルが、ここにもあると感じました。 3次安全のポイント（事故後対応） - クラスターロギング・must-gather で原因究明とサポート連携を高速化 - 記録 → 復旧 → 次に活かす、のサイクルが回る OpenShift と「自分で組む Kubernetes」の違い ここまで読んで、「Kubernetes でも同じことができるのでは？」と思った方もいるかもしれません。 確かに、個々の安全技術は Kubernetes のエコシステムから自分で組み合わせることもできます。違いは「どちらが優れているか」ではなく、統合とテストの手間を誰が持つか だと感じました。 自分で組む場合は、安全部品を一つずつ選び、相性の検証や継続的なアップデートも自分たちで担うことになります。OpenShift の場合は、SCC や RBAC、RHCOS といった安全機能があらかじめ統合・テストされた状態で提供され、アップデートも一括で届きます。必要なパーツを集めて自分で組み上げるか、メーカーが衝突試験まで済ませた状態で受け取るか、どちらが正解でもなく、検証をどこまで自分で引き受けるか という選択の問題だと感じました。 私は前職で、完成車メーカー（OEM）のエンジニアとして、まさにこの「部品を統合し、検証して1台にまとめ上げる」側にいました。 その経験から言えるのは、部品単体がどれだけ優秀でも、組み合わせて初めて見えてくる問題がある ということです。なのでメーカーは、出荷前に膨大な統合テストや衝突試験を繰り返します。「安全」は個々の部品の性能ではなく、それらが正しく組み合わさって検証されて初めて成り立つ。OpenShift を見たとき、同じ重みをそこに感じました。 おわりに 私が自動車業界で学んだのは、「安全という設計思想」でした。安全な車とは、単にエアバッグがたくさんついている車ではなく、1次安全（予防）・2次安全（衝突）・3次安全（事故後対応）の3段階が、設計段階から一貫して考え抜かれている車のことです。 OpenShift にも、それに通じる考え方が何層にも重ねられていると感じました。 これから書いていきたいこと 新しい技術を前にすると、誰でも「本当に任せて大丈夫なのか」と不安になります。それは自動車というハードの領域から、IT・クラウドの世界へ飛び込んだときの私自身の気持ちでもありました。 なので、このブログでは、専門用語をそのまま並べるのではなく、自動車のように身近なものに例えながら「なぜ安心できるのか」を少しずつ翻訳して届けていけたら と思っています。 この記事が、OpenShift の安全設計を見るときの 一つの補助線 になれば幸いです。異業種から来た私だからできる、ささやかな「翻訳」として、判断材料を一つ増やせたのなら、これほど嬉しいことはありません。 最後までお読みいただき、ありがとうございました。 参考文献 [1] "Understanding the underlying rationale of Security Context Constraints (SCC) within OpenShift", Red Hat, https://access.redhat.com/articles/7020712 [2] "Red Hat Enterprise Linux CoreOS (RHCOS)", Red Hat, OpenShift Container Platform 4.22 Architecture, https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/architecture/architecture-rhcos [3] "Managing security context constraints", Red Hat, OpenShift Container Platform 4.22, https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/authentication_and_authorization/managing-pod-security-policies [4] "Machine configuration overview", Red Hat, OpenShift Container Platform 4.22, https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html-single/machine_configuration/index [5] "How to modify the pod eviction and reschedule timeout in OpenShift 4?", Red Hat, https://access.redhat.com/solutions/5359001 [6] "Remediation, fencing, and maintenance — Workload Availability for Red Hat OpenShift 26.2", Red Hat, https://docs.redhat.com/en/documentation/workload_availability_for_red_hat_openshift/26.2/html-single/remediation_fencing_and_maintenance/index [7] "About OpenShift logging — Red Hat OpenShift Logging 6.5", Red Hat, https://access.redhat.com/documentation/en-us/red_hat_openshift_logging/6.5/html-single/about_openshift_logging/index [8] "Data gathering when oc adm must-gather fails", Red Hat, https://access.redhat.com/articles/4971311

Red Hat のソリューションアーキテクトの瀬戸です。 最近のAIはすごいですよね。毎月のように新しいモデルが発表され、毎日のように新しい驚きがあります。(再) 前回の AIを使ってJBoss EAP 6.4で動作するStruts 1アプリケーションをJBoss EAP 8.1に移行する - 赤帽エンジニアブログ という記事では古いStruts 1アプリケーションをAIを使って最新のJBoss EAP 8.1に移行してみました。 続く今回の記事では、Spring BootアプリケーションをJBoss EAP 8.1上のJSFへ移植してみます。 なんでSpring BootをわざわざJBoss EAPへ？ と思われる方も多いでしょう。 実は最近、Spring Boot周辺のライセンスや商用サポートモデルの変更（いわゆるMythosの話題など）をきっかけに、「コミュニティサポートのみのOSSのまま運用を続けるのはリスクがある」「Spring Bootの商用サポートは期間やコストの面で要件に合いにくい」といった課題に直面し、Jakarta EEサーバーへの移行を具体的に検討されるお客様が増えています。また、この話題の前からも、同様の理由ですでに移行を進められているお客様もいらっしゃいます。 Jakarta EEサーバーは古臭いとか、重いとか、そういうイメージが付いていますが、実際にはSpring-Bootと比べて明確にパフォーマンスが劣るようなことはありません！今後追加が予定されているJakarta MVCなど、現時点では足りない機能もありますが、自由にライブラリを追加する事もできるので、実用上は十分に強力な選択肢になります。 使用したAI 今回は Claude Sonnet 4.5を使用しています。前回のHaikuよりも高い性能を持つモデルです。現在（2026年）となっては一世代前のモデルにあたります。現行の最新AIであれば、同様のアプローチで移行を進められると推察されます。 ただし、どのようなAIでも出来るわけではない点ご注意ください。また、AIの特性上、同じClaude Sonnet 4.5を使っても同じような結果を得られないこともあります。 サンプルアプリケーション 今回は移行元のサンプルとして、お馴染みの Spring PetClinic を使用しました。動的なHTMLの生成からDB アクセスまで一通りの処理が実装されているアプリケーションです。前回の画面だけのものに比べたら実際の業務アプリケーションに近い、実践的な構成と言えます。 また、実際の業務アプリケーションに近いという事で、今回はOSSの PrimeFaces を使って移植をしてみました。PrimeFacesはJSF上で有名なUIライブラリです。簡単にリッチな画面を作ることができます。Red HatではPrimeFacesのサポートは行っておりませんが、有償サポートを契約することも可能です。 移行前のサンプルアプリケーションは以下にあります。 github.com 移行後のサンプルアプリケーションは以下にあります。JBoss EAP 8.1+OpenJDK 21で動作確認をしています。 github.com なお、今回はせっかくの機会ですので、画面も「JSFらしいモダンな見た目」にリニューアルしてみました。 *1 移行前のアプリケーション 移行後のアプリケーション 移行の指示 今回も前回と同様、以下のようなシンプルなプロンプトからスタートしました。 JBoss EAP 8.1で動くようにしてください。その際にSpringからJSFに変更します。また、pom.xmlは次のリポジトリのpom.xmlを参 考にしてbootable jarとして実行できるようにしてください。 https://github.com/ssetoredhat/eap8.1-bootablejar ただし、今回の構成ではこれだけでは明らかに不十分で、これ以外に多くの追加の指示、修正が必要になりました。Spring BootからJSFへ移行する際のノウハウとして、直面したポイントをいくつか紹介します。 追加で指示が必要だった点 全体として、実装方法が複数あってAIの判断が曖昧になる点や、「SpringとJSFでアノテーションや書き方は似ているものの、挙動や機能が異なる場合」に、詳細な移行指示を出す必要がありました。 GET/POSTなどのHTTPメソッドを維持する もともとのSpring PetClinicでは、データ登録はPOST、データ検索はGETで実装されていました（RESTのベストプラクティスに沿った形です）。しかし、AIがJSFに移行する際、すべてを一律でPOSTに変更してしまったため、ページング処理などで値がうまく引き継げなくなる問題が発生しました。GET/POSTの役割はそのまま維持するよう、明示的に指示すべきポイントです。 EJBよりもCDIを使用する 旧来のJava EEではEJBとServletを中心にアーキテクチャが構築されていましたが、モダンなJakarta EE（JBoss EAP 8.1）では、DIコンテナとしてCDIを中心に据えることが推奨されています。今回、AIは初期化処理をまずEJBに移植しようとしたため、最初から「CDIを使用すること」を指定しておくのが正解でした。 スコープの指示 @RequestScoped と @ViewScoped など、スコープの問題が多く発生しました。挙動がフレームワークに隠蔽されているため、実際にどういう挙動になるかがAIからわかりにくかったためと推察されます。 基本的には @RequestScoped を使用して、特定の場合のみ @ViewScoped に変更するなどすればいいのですが、それはAIに追加での指示が必要でした。 そのほか 今回、問題が発生したところに関しては、修正指示を出し、その結果を テキストにまとめてもらいました。 一部記述が怪しい部分も残っていますが、「AIにナレッジをまとめさせると、リアルにこのくらいの精度になる」という参考として、あえて手を加えずにそのまま公開しています。 次回、同様の移行を行う際はこのテキストをそのまま「AIへの指示書（コンテキスト）」としてインプットできるため、今回よりも遥かにスムーズに移行できるようになるはずです。ぜひ皆様も移行を試された際は、ご自身用の指示書を作って公開してみてください！ なお、前回記事で触れた考慮事項（移行時の注意点）については、今回も引き続き意識する必要があります。 まとめ いかがでしたでしょうか？今回のアプリケーションは前回に比べるとCRUDすべてが実装されているという事もあり、さすがに簡単なプロンプト1回で移行するというわけにはいきませんでした。 しかし、思っていたよりはずっと簡単に移行する事ができました。 また、ナレッジ自体もAIが勝手にまとめてくれるため、次回はもっと簡単に移行する事ができるようになります。 AIによって気軽にフレームワークを切り替えられるような時代になりました。ぜひSpring-Bootに不満がある場合はJBoss EAPを検討いただき、ぜひご利用ください。 *1 : 決して見た目を同じにする労力を省いたわけではありません。

はじめまして。ソリューションアーキテクトの川田と申します。 現在は、パートナー様を担当させていただいております。 前職では、仮想マシンを中心とした仮想化ソフトウェアの技術提案に携わっていました。 そこでこの記事では、仮想マシンの世界で生きてきたエンジニアが、どのようにコンテナ、Kubernetes (k8s)、 そして Red Hat が提供する OpenShift について学んでいるのか、学習した内容や、その中で得た気づきをご紹介します。 特に、これまで仮想マシンやオンプレミス基盤を中心に扱ってきた方、これからコンテナや k8s、 アプリケーションプラットフォーム、AI などの領域に知見を広げていきたい方に向けて、 既存のインフラ経験を活かしながらどのように新しい技術領域に踏み出せるのかをイメージしていただければ幸いです。 この記事でお伝えしたいこと： 仮想マシンとコンテナのアーキテクチャの違い 仮想マシンの管理と k8s によるコンテナ管理の考え方の違い Red Hat が提供する OpenShift と素の k8s の違い 0. 私のコンテナ、 k8s 学習前の経験・スキル 1. 仮想マシンとコンテナのアーキテクチャの違い 2. 仮想マシンの管理と k8s によるコンテナ管理の考え方の違い 3. Red Hat が提供するOpenShift と素の k8s の違い 4.おわりに 0. 私のコンテナ、 k8s 学習前の経験・スキル 私のコンテナ、k8s を学習をする前の経験・スキルは、以下のようなレベルでした。 ・ハイパーバイザーを含むインフラ領域（コンピュート、ネットワーク、ストレージ、クラウド IaaS）について多少の知見がある ・コンテナや k8s については、最低限の会話ができる程度の知識がある。コンテナや k8s で使う設定ファイルをゼロから書いた経験はほとんどない モチベーションとして、私は今後、仮想マシンだけでなく、コンテナ、アプリケーションプラットフォーム、さらに将来的には AI ワークロードの開発・実行環境の領域にも知見を広げていきたいと考えていました。 1. 仮想マシンとコンテナのアーキテクチャの違い はじめに、k8s や OpenShift に進む前段階として、Podman というツールを使ってコンテナの基礎を学びました。 （利用した学習コースはこちら: Red Hat OpenShift Development I: Introduction to Containers with Podman | DO188 ） 具体的な学習内容としては、コンテナの作成や実行、コンテナイメージの管理など、コンテナ化されたアプリケーションを扱う上で必要となる基本的な操作を学んでいきました。 このコースで利用する Podman とは、Red Hat 系の環境で標準的に利用されるコンテナツールです。よく名前を目にすることが多い Docker と異なり、裏側で常に動き続けるプロセスを必要としない点が特徴です。 学習を通じて、コンテナのメリットとして最初に感じたのは、起動が早く、リソースを効率的に使えるという点です。 仮想マシンのように OS 全体を個別に起動するのではなく、ホスト OS のカーネルを共有しながらアプリケーションを分離して動かすため、仮想マシンと比べ軽量に扱うことができます。 二点目のメリットとして、アプリケーションと共に実行に必要なライブラリなどをコンテナイメージとしてまとめられるため、開発環境、検証環境、本番環境などの各環境で動作差分を減らすことができる点も便利だと感じました。 また、コンテナと仮想マシンの運用面の違いを比べると、アップデートやパッチ対応にも大きな差があると感じました。 例えば、仮想マシンの運用フェーズで、稼働中の OS やミドルウェアに対して個別にパッチを当てたり、設定を変更したりする場面も多くあると思います。 コンテナの場合どのように対応を行うかというと、修正内容を反映した新しいコンテナイメージ（コンテナのテンプレートのようなもの）を作成し、そのイメージを古いものと差し替える形で更新を行います。 コンテナの場合も仮想マシンと同様に、更新時の再起動/再作成自体は発生します。ただ、変更内容をイメージとして管理できるため、「どのバージョンのアプリケーションが、どの設定・ライブラリで動いているのか」を把握することができます。 問題があった場合に以前のイメージへ戻したり、同じイメージを使って別環境に展開しやすい点も、メリットの一つだと感じました。 このように、コンテナはアプリケーションとその実行に必要なものをイメージとしてまとめ、軽量に起動・実行できる点が大きな特徴です。そのため、小規模なサービスや開発・検証環境であれば、Podman などを使ってコンテナ単体で動かすだけでも十分に有効だと感じました。 仮想マシンのエンジニアから見た、コンテナのいいところ: 仮想マシンより軽量で、すぐに立ち上がる コンテナイメージを差し替えるだけで、アップデート・パッチ対応はもちろん、ロールバックもできる 2. 仮想マシンの管理と k8s によるコンテナ管理の考え方の違い ここまでコンテナの特徴についてご紹介しましたが、実際にコンテナをアプリケーションとして運用しようとすると、考慮すべき点は増えてきます。 例えば、外部からのアクセスをどのように受けるか、複数のコンテナでどのように可用性を確保するか、障害時にどのように復旧するか、データやログをどこに保持するか、設定情報や環境変数をどう管理するかといった点です。 つまり、コンテナを単に「動かす」だけであれば比較的シンプルですが、アプリケーションとして安定して「運用する」ことを考え、しっかり管理しようとすると、コンテナの基盤として k8s のような仕組みが必要になるのだと感じました。 そこでコンテナに続いて、コンテナの管理・制御といったオーケストレーションを行うプラットフォームである、k8s の学習を行いました。 これまで私は k8s について、なんとなく概要を説明できる程度の知識しかありませんでした。 学習を進める中で、これまで仮想マシンを利用してきた方々が、k8s に対して「便利そうではあるが、難しそうで手を出しづらい」と感じる理由も少し見えてきました。 例として、仮想マシン、または k8s 上のコンテナを作成する際の操作を比較してみます。 仮想マシンであれば、UI 上で CPU やメモリなどのリソース、仮想ネットワーク、ストレージなどを設定し、OS を起動するという流れになります。この手順は比較的シンプルで、手順書があれば初心者の方でも直感的に進めやすい部分が多いと思います。 実は k8s でも、最小構成のコンテナを 1 つ動かすこと自体は難しくありません。 ただし、実環境でアプリケーションとして利用することを考えると、理解すべき要素が一気に増えます。 例えば、複数のコンテナでどのように可用性を確保するのか、アプリケーションが外部からの接続をどのように受けるのか、通信をどのように振り分けるのか、データを永続化する場合にストレージをどう扱うのか、設定情報や認証情報をどう管理するのか、といった要素それぞれを k8s のリソースとして定義する必要があります。 仮想マシンも本番運用を考えれば、ネットワーク、ストレージ、クラスタリング、HA、バックアップ、外部機器や外部サービスとの接続、構成管理など、多くの設計や運用上の考慮が必要であり、決して単純ではありません。 ただ、あくまで最初の学習段階においては、仮想マシンは「1 台のサーバー」という単位を中心にイメージしやすい面があると思います。そのサーバーに対して、各種設定や接続を順に整理していく形で理解しやすいためです。 k8s の場合、「1 台のサーバー」を中心に考えるというより、アプリケーションを動かすために必要な内容を、最初から複数に分けて定義する必要があります。 例えば、アプリケーションで起動するコンテナの数やアップデートのルール、外部からの通信を受ける入口、通信の振り分け先、設定値や認証情報の受け渡し、利用するストレージやデータの保存先などをそれぞれ定義し、それらを組み合わせた結果としてアプリケーションが動く、という考え方になります。 つまり、k8s の難しさは、仮想マシンより単純に難しいというよりも、設計や運用の捉え方が違うところにあると思います。仮想マシンでは「サーバーという単位を中心に、その周辺の構成を考える」感覚に近いのに対して、k8s では「アプリケーションがどう動いてほしいかを、複数のリソースの関係として定義する」感覚に近いためです。 このように、管理者が各操作手順を指示するのではなく、「最終的にこういう構成 (=『あるべき姿』)で動いていてほしい」という構成を定義する考え方を、『宣言的な構成管理』と呼びます。 この違いが、k8s を学び始めたときに難しさを感じる部分であり、実装における最初のハードルになる部分だと思いました。 一方、学習を進めたことで、k8s に対する見方も変わりました。具体的には、一度基盤として整備できれば、その後の運用や環境の払い出しなどのフェーズでは大きなメリットがあることが分かりました。 特にメリットだと感じたのは、定義した『あるべき状態』に近づけるように、k8s が環境を継続的かつ自動的に制御してくれる点です。例えば、何らかの理由でアプリケーションの一部が停止した場合でも、k8s は定義された状態と現在の状態との差分を検知し、自動的に復旧しようとしてくれます。 『あるべき状態』と現在の状態を継続的に比較し、差分があれば定義された状態に近づけようとする制御の考え方を、『Reconciliation Loop』と呼びます。また、障害が発生した際に自動的に復旧しようとする動きを『Self-healing』と呼びます。 こうした仕組みによって、管理者が都度状態を確認して手動で操作するのではなく、あらかじめ定義した状態を k8s が維持しようとしてくれるところに、従来の仮想マシン基盤と比べた画期性を感じました。 学習前は k8s に対して「便利そうだが難しそう」という印象を持っていましたが、今回実際に手を動かして学習したことで、そう感じていた理由が分かりました。同時に、k8s にはその印象を覆すような、運用面を中心とした様々なメリットがあることを実感しました。 仮想マシンのエンジニアから見た、k8s のいいところ コンテナを実環境で利用するための、全体の構成や各要素を一元的に管理できる 『あるべき姿』を維持するように、自動的に制御を行なってくれる 3. Red Hat が提供するOpenShift と素の k8s の違い Red Hat が提供するコンテナプラットフォームである OpenShift についても、入門的な学習からスタートしました。 （利用した無料の学習コースは以下: Containers, Kubernetes and Red Hat OpenShift Technical Overview | DO080 Red Hat OpenShift for Developers Technical Overview | DO088 Red Hat OpenShift Virtualization Technical Overview | DO016 ) 学習を始める前は、OpenShift についてほとんど知識がなく、「k8s に UI がついて、何かしらの便利ツールが付いたものなのかな」という程度のイメージを持っていました。 しかし、学習を進める中で、OpenShift は単に k8s を使いやすくするための UI や機能を加えたものではなく、企業や組織が本番環境でコンテナを活用するために必要になりやすい機能や運用の仕組みを、Red Hat が検証・統合し、製品として継続的に提供・サポートしているプラットフォームなのだと理解しました。 素の k8s 単体でもアプリケーションを動かすことはできますが、企業や組織の本番環境として利用するには、さらに、監視、ログ管理、CI/CD、認証・認可、セキュリティ、アップデート運用など、周辺の仕組みをどのように組み合わせ、どのようにサポートしてもらうかを別途考える必要があります。 OpenShift では、こうした要素を Red Hat が検証・統合したプラットフォームとして扱えるため、利用者が個別に選定・構築・保守する範囲を抑えやすくなります。その結果、本番環境で k8s を利用する際の運用上の不確実性や複雑性を減らせる点に価値があると感じました。 OpenShift はコンテナアプリケーションにとどまらず、仮想マシンも同じプラットフォーム上で管理することができます。 仮想マシンの管理自体は k8s を周辺の技術と組み合わせても実現できますが、安定した運用には工数も時間もかかります。 OpenShift の場合、仮想マシンの管理が OpenShift Virtualization としてあらかじめ統合され、Red Hat によるサポートも含めて提供されるため、既存の仮想マシン資産を活かしながら、段階的にクラウドネイティブ化やマイクロサービス化を進めやすくなると感じました。 また、複数の OpenShift 環境がある場合、OpenShift Platform Plus を利用することで、複数環境をまとめて管理したり、セキュリティリスクの検出やコンテナイメージの管理を共通のルールで行うことができます。これにより、環境ごとに個別に管理する範囲を減らし、運用の標準化とセキュリティレベルの向上に繋げることができます。 AI の利用を検討する場合も、AI モデルの開発や、AI アプリのデプロイ・運用を支えるツールや基盤は、選択肢が多く、変化も速いため、これらを自分たちで個別に組み合わせて運用していくのは簡単ではありません。OpenShift AI では、AI ワークロードに必要な仕組みを OpenShift に統合された形で利用でき、かつ Red Hat によるサポートもまとめて提供される点に価値があると感じました。 このように、OpenShift は単に k8s に機能を追加したものというより、仮想マシンや AI ワークロードも含めて、企業や組織の IT を支えるさまざまなワークロードを、統合された仕組みとサポートのもとで継続的に開発・運用していくためのプラットフォームなのだと理解しました。 4.おわりに この記事では、仮想マシンのエンジニアの視点から、コンテナ、k8s 、OpenShift について、学習した内容や、その中で得た気付きをご紹介しました。 学習を通じて、コンテナや、そのプラットフォームには、それぞれ従来の仮想マシン基盤とは異なる考え方やメリットがあることを学ぶことができました。 次回は、本記事で少し触れた OpenShift について、k8s と比較してどのようなメリットがあるのかをより具体的にご紹介させていただきます。

Red Hat のソリューションアーキテクトの瀬戸です。 最近のAIはすごいですよね。毎月のように新しいモデルが発表され、毎日のように新しい驚きがあります。 今までに何回かJBoss EAPへの移行をツールを使って行う記事を書いてきました。 rheb.hatenablog.com rheb.hatenablog.com 細かい話は置いておいて、AI使えば簡単に移行ができるよね？という話もあり、今回は実際に移行をしてみました。 Struts 1は20年ぐらいまえに私が社会人になった時に最初に使ったフレームワークで、10年ぐらい前にもStruts 1から移行しようみたいな案件をやったことがある気もするのですが、いまだにStruts 1の名前を見ることがあり、なんというか、はい。 使用したAI 今回はClaude Haiku 4.5を使用しました。現行の最新版ではなく、半年以上前の少し古いバージョンでかつ廉価版のAIとなっています。 最新版ではないため、特段Claudeだから出来る、というわけではなく、現行の最新のAIであれば似たようなことは出来るのではないかと推察されます。 ただし、どのようなAIでも出来るわけではない点ご注意ください。また、AIの特性上Claude Haiku 4.5を使っても同じような結果を得られないこともあります。 Claude Haiku 4.5の紹介記事は次のページを参照してください。 www.anthropic.com サンプルアプリケーション 移行前のサンプルアプリケーションは以下にあります。JBoss EAP 6.4+OpenJDK 8で動作確認をしています。 github.com 移行後のサンプルアプリケーションは以下にあります。JBoss EAP 8.1+OpenJDK 21で動作確認をしています。 github.com この記事自体は移行できました！という内容でしかないので、移行にお困りの方はとりあえずサンプルアプリケーションを基にAIに移行させてみるのが良いと思います。 改めて書きますが、少し古めのClaude Haiku 4.5を使って試していますので、Claudeに限らず、他のAIでも十二分にできる可能性があります。 移行の指示 今回は、Struts 1.2.9で作成したサンプルアプリケーションをJBoss EAP 8.1上のJSFで動作させるように命令しました。 移行に使用したプロンプトは次の通りです。 JBoss EAP 8.1で動くようにしてください。その際にStrutsからJSFに変更します。また、pom.xmlは次のリポジトリのpom.xmlを参 考にしてbootable jarとして実行できるようにしてください。 https://github.com/ssetoredhat/eap8.1-bootablejar その結果、無事に移行できました。無事にできましたとしか言いようがありません。。。 移行処理のサマリー ただし、移行時にはバグも発生させました。 ユーザー登録画面にはリセットボタンがあるのですが、それがJSFのsubmitとして実装され、色が青くなってしまいました。また、リセットの動作もうまくいっていませんでした。 ユーザー登録画面 そのため、次の指示で直してもらいました。 ユーザー登録画面のリセットボタンが動作しないようです。修正してください。 これもすぐに修正してくれました。 リセットの修正 なんか、すごいですね。 AI修正における所感 今回、AIに簡単な指示を出すだけで移行できたように見えますが、この最小限のプロンプトに行くまではいくつかの問題が発生していました。次のような点を考慮する必要がありました。 移行先のライブラリの明示 移行先のライブラリについては明示をします。AIは検索した結果などを基にわりとファジーに対応してくれるので、予期しないものを使用したりします。今回はpom.xmlを使ってサーバー構成のサンプルを渡してあげることで、バージョンを確定させています。また、JBoss EAPをUpstreamのWildFlyと混同しやすいらしく、動作しない場合にWildFlyの設定を積極的に入れようとしてきます。最初に動作する環境を渡してあげることでアプリケーションの移行に注力してくれるようになりました。 動作する環境の準備 動作する移行先を準備してあげることでAIは動作確認も行ってくれます。動作確認をしてくれると、問題が発生した場合に自動で修正をしてくれるようになります。今回は修正後の環境はbootable-jar(起動可能なjar)を使用しました。そのため、AIは自前で動作確認をしてくれるようになりました。必要に応じてデータベースの初期化スクリプトや接続情報などもAIに提供し、テストをする方法を明示するのが良いでしょう。また、AIは検索した結果などを基にわりとファジーに対応してくれる *1 ので、ライブラリのバージョンについては疎いです。ライブラリの特定のバージョンでないと動作しないような修正を入れてしまうこともあるので、動作確認は確実にさせるようにしてください。 エラーハンドリング・共通処理などの業務処理に関わらない処理・非機能要件 業務要件とは関わらないけれども共通的に検討しなければいけない処理が発生します。例えばJSFでは悪名高きViewExpiredExceptionの処理や、共通的なエラーハンドリング、ログ処理などです。これらについては移行前に検討をしてAIに実装させる前にサンプル実装を準備しておく必要があります。とはいっても、AIには何回作り直しをさせても大丈夫なので、実装は遅れても大丈夫です。これも最初のpom.xmlと同様に、プロンプトの中でAIに渡してあげると良いでしょう。また、当然ですが、これらの処理についてもAIに考えさせることは可能です。 まとめ ということで、AIを使って古いアプリケーションを最新のJBoss EAP 8.1に移行してみました。 AIになっていろいろな常識が破壊されています。StrutsからJSFへの移行も、まずは数日かけて検討して～からはじまっていたのが、数時間でできるようになってしまいました。 手を止めて検討する前に、ぜひ一度やってみてください。 *1 : 大事なことなので2回言いました。