24時間365日の稼働を止めない！ESXiアップデートを完遂するための緻密な計画と「泥臭い」調整術

2026年1月31日

インフラエンジニアにとって、基盤のアップデートは避けて通れない一大イベントです。特に「24時間365日、絶対に止められないサービス」を預かっている場合、そのプレッシャーは相当なものです。

先日、私が担当する8台のESXi環境で実施したアップデート作業。そこには、技術的な手順以上に重要だった「緻密なリソース計算」と「泥臭い社内・外の調整」がありました。現場のリアルな記録と、次回に活かすためのチェックリストを共有します。

この記事の想定読者

この記事を読むことでのメリット

そもそも「VMware」や「仮想化」とは？

この記事で扱う「VMware（ヴィエムウェア）」は、現代のITインフラを支える最も重要な技術の一つです。まずは、初めての方に向けて簡単に概要を説明します。

仮想化（ESXi）： 1台の大きな物理サーバー（ハードウェア）の中に、ソフトウェアの力で「仮想的なコンピューター」を何台も作り出す技術です。この「魔法のソフトウェア」がESXiです。
集中管理（vCenter）： 複数あるESXiサーバーを、1ヶ所からまとめて操作・監視するための司令塔がvCenterです。
無停止移動（vMotion）： メンテナンスなどの際、仮想コンピューターを「動かしたまま（シャットダウンせずに）」別の物理サーバーへ引っ越しさせる機能です。

今回の記事は、この「引っ越し」を駆使しながら、止めてはいけない本番システムをどう守り抜いたか、という現場の記録です。

今回のアップデート計画を立てるにあたり、前提となる構成とサービス要件は以下の通りでした。

仮想化基盤サーバ（ESXiサーバ）： 計8台
vCenterサーバ： 計4台
管理体制： ライセンス要件およびサーバの種類に応じた管理区分により、1台のvCenterサーバが2台のESXiサーバを管理する「1:2」の構成。
稼働状況： すべてのESXiサーバ上で仮想サーバがフル稼働しており、vMotionの「バッファ」となる空のホストが存在しない。

止まらないサービス： 原則24時間365日稼働。
本番影響の最小化： 月1回の定期メンテナンス枠（2〜3時間）はあるものの、それはあくまで「通常のメンテナンス」用。アップデート作業でこの枠を使い切ることは避け、可能な限り業務サービスを停止させずに完了させることが至上命題。

この「逃げ場のない構成」と「止まらないサービス」の組み合わせが、今回のパズルの難易度を極限まで高めていました。1台をメンテナンスモードにするためには、ペアとなるもう一方のホストへ全ての負荷を安全に集約させ、かつサービスへの瞬断すら許されないという緊張感の中での作業となります。

「深夜作業が当たり前」と思われがちなインフラ保守ですが、今回はあえて「平日の日中帯」を主戦場に選びました。その根拠は、1週間にわたるリソース推移の徹底的な確認です。

1週間単位の推移を確認したところ、夜間はバックアップやバッチ処理で負荷が高く、逆に日中帯の方が相対的に負荷が低いことが判明しました。曜日別では、火曜日と水曜日が「凪（なぎ）」の状態。この客観的なデータが、日中作業という決断を後押ししました。

vMotionでVMを片寄せする際、最大の壁はメモリです。計算の結果、以下の通り、余裕ありセットと、余裕なしのセットがありました。

余裕ありのセットはvMotionで片方のESXiサーバ上で稼働する仮想サーバを空にすることで、メンテナンス可能です。

一方、余裕なしのセットはメモリが足りず、vMotionで仮想サーバを片寄せすることができません。そこで、業務に影響を与えない待機系サーバ、管理系サーバを停止することを考えました。それでもメモリが足りない部分は、トレーニング環境を停止させることで、最小限の影響としました。

対応グループ	現状の判断	具体的なアクション
余裕あり（2セット）	片寄せ可能	そのままvMotionで片方のESXiを空にする
余裕なし（2セット）	片寄せ不可	待機系（Standby）サーバを一時停止管理系サーバを一時停止トレーニングサーバを一時停止（顧客調整済み）

作業当日、最も大切なのは「何時までに終わらなければ、作業を諦めて引き返すか」という切り戻し基準の顧客との合意です。