本稿は、北米で開催された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の本質的な教訓を示している。

本稿は、USENIXが2026年4月24日に公開した動画「SREcon26 Americas - From ESXi to Kubernetes: Modernizing 1,400 Edge Locations with Open Source」を基に作成しました。