“費用10倍”のESXiから脱却 追加予算なしで1400店舗のVMを刷新した方法：openSUSEとKubernetesで「脱VMware」

店舗など現場拠点のシステム運用において、IT製品のライセンス費用高騰は深刻な問題だ。追加予算なしで、1400店舗のインフラをESXiからKubernetesを中心としたオープンソースシステムに刷新した事例を紹介する。

[TechTargetジャパン]

　小売店舗など分散したエッジ（データ発生源の近く）におけるITインフラの運用は、企業にとって悩みの種だ。カナダ全土で食料品店や薬局などを展開し、年間10億回以上の顧客取引を処理する小売大手Loblaw Companies（以下、Loblaw）も例外ではなかった。

　Loblawの約1400店舗では、店舗ごとに独立して運用されていたハイパーバイザー「ESXi」において、薬局管理やPOS（販売時点情報管理）などの重要な仮想マシン（VM）が稼働していた。システム自体は安定していたが、VMwareの仮想化製品のライセンス費用が約10倍に高騰したことで運用費用の維持が困難になった。VM中心の設計はコンテナやマイクロサービスの導入を阻害し、システムモダナイゼーションの大きな壁にもなっていた。

　一方でLoblawには「ハードウェア更新予算なし」「新たなプロプライエタリ製品の導入不可」「店舗業務のダウンタイム最小化」という厳しい制約があった。店舗には専任のITエンジニアが不在であり、ネットワークやメモリなどのコンピューティングリソースにも限界がある。

　この課題に対し、Loblawはオープンソースの「Linux」ディストリビューション「openSUSE」と、コンテナオーケストレーションツール「Kubernetes」を中心としたシステムへの移行を決断した。KubernetesでVMを動かせるようにする拡張機能「KubeVirt」を活用して店舗システムを大規模に刷新し、仮想化製品やOS、監視ツールに関わるライセンス費用を完全に撤廃することに成功した。

　既存のハードウェアを使い回しながら、いかにしてダウンタイムやトラブルを防ぎ、1400店舗で稼働するシステムの大規模移行を実現したのか。その移行戦略と運用ノウハウを解き明かす。

高額ライセンスから逃れるための移行術

併せて読みたいお薦め記事

「脱VMware」をどう進めるか

• 脱VMwareの本命「Proxmox VE」とは　情シス部が決断すべき理由
• 「脱VMware」の新たな選択肢　中小企業が注目するeuroNASの仮想化OSとは

　本稿は、北米で開催されたSRE（サイト信頼性エンジニアリング）カンファレンス「SREcon 2026 Americas」におけるセッション「From ESXi to Kubernetes at the Edge」の内容を基に、Loblawの取り組みを深掘りする。

　Loblawの移行戦略における最大の特徴は、常にロールバック可能な状態を維持する「4段階の移行プロセス」にある。新しいハードウェアを購入することなく、店舗にある既存のサーバのCPUやメモリ容量などをやりくりして安全性を確保した。

　まず移行前の準備段階として、かつて別の用途で使われていた店舗内のサーバを再利用し、ESXiを用いた既存システムと並行してKubernetesクラスタを構築した。この段階で、レガシーな薬局管理アプリケーションから一部の機能を分離し、VMのメモリ要件を32GBから18GBへと大幅に軽量化した。

　実際の切り替え作業は、店舗の営業時間外である夜間に実施した。既存のVMを1つのESXiノード（ESXiが稼働する個別の物理サーバ）に集約し、空いたノードをKubernetesクラスタに組み込んで拡張する。その後データを同期してトラフィックを新しいシステムへ切り替えた。ここで特筆すべきは、残った1つのESXiノードをシャットダウン状態のまま「保険」として残した点だ。これによって、万が一新システムで問題が発生しても、いつでも元の状態に戻せる安全網を構築した。切り替え作業の翌日に店舗での正常稼働が確認された後、最後に残ったESXiノードもKubernetesを稼働させるサーバへと再構築してクラスタに合流させ、サーバ3台で連携するシステム構成を完成させた。

　もう一つの重要なポイントは、1400店舗という膨大なエッジ拠点を少人数で確実に管理するための運用手法だ。

　各店舗のサーバに対するopenSUSEとKubernetesのインストール作業は構成管理ツール「Ansible」を用いて自動化し、クラスタ構築後の設定管理には、設定情報をGitで管理し、変更を自動反映させる運用手法「GitOps」を導入した。通常、GitOpsではエッジにあるクラスタがリポジトリを定期的に確認するが、Loblawの場合は店舗数が多いためネットワークに過度な負荷がかかる懸念があった。そこで同社は「Hub-and-Spoke」モデルを採用した。これは中央の管理クラスタ（Hub）が変更を検出し、各店舗のクラスタにデータを直接送り込んで設定を同期させる仕組みだ。これによって、一貫性のある宣言的な運用（手順ではなく「システムが最終的にどうあるべきか」の状態を定義して、その状態を自動で維持させる手法）が可能になり、各店舗のシステム状態を正確に保つことができた。

　Loblawは、一晩に1店舗のペースから慎重に移行を開始し、運用手順や自動化スクリプトの改善を繰り返した。最終的には週に最大40店舗を移行するスピードに達し、専任のSREチーム5人と少数のデプロイ担当者のみで大規模なプロジェクトを推進した。

　システム刷新の結果、Kubernetesの自己修復機能によって店舗システムの信頼性は飛躍的に向上した。レガシーなVMアプリケーションと最新のマイクロサービスを同じインフラで共存させることが可能となり、将来的なシステム拡張への道筋も開かれた。

　Loblawの事例は、モダナイゼーションが単に最新のツールを導入することではなく、運用の複雑さや手作業の介入を減らし「運用表面積を縮小すること」であるという、SREの本質的な教訓を示している。