Synology VMM Pro: AI を活用した本番環境 VM の適正サイズ化 (2026 年)

このショップを運営する仮想マシンは、必要なハードウェアの2倍の容量を何ヶ月も搭載していました。仮想CPUが8個、メモリが16ギガバイト、実際のワークロードはどちらも4分の1以下しか使用していませんでした。これは珍しいことではありません。初日はゲストOSのサイズを余裕を持たせて設定します。なぜなら、何が必要になるか全く分からないし、サイトは正常に動作し、誰も戻ってこないからです。この記事は、その「戻って」の記録です。Synologyを使用して、ゲストOSのサイズを4つのvCPUと8ギガバイトに削減しました。 VMM Pro, AIアシスタントがシェルを操作している状態で、ストアには2分7秒間アクセスできませんでした。サイズ変更自体は退屈な部分で、ダイアログの2つのフィールドです。興味深いのは、8ギガバイトで十分であることを証明した測定、ゲストOSが初回起動時にメモリ不足にならないようにする操作の順序、そしてそれらすべてを元に戻せるようにしたスナップショットです。VMM Proはこれらのすべてを安価に実現しており、それがこの製品の正当な主張です。

SynoPower Clubポイント：セルフホスティングにおいて、適正サイズ化は最も地味な作業ですが、最も見返りが大きい作業でもあります。8ギガバイトのメモリを解放したことをブログ記事に書く人はいません。しかし、大きすぎるゲストOS内でアイドル状態になっているメモリは、何の節約にもなりません。Synologyではメモリが固定されているため、他のサーバーでは使用できません。容量がいっぱいになり始めていたホストOSで8ギガバイトのメモリを解放できたので、ハードウェアを購入する必要のあるゲストOSが2つ減りました。この作業を不安ではなく安全にしてくれたのは、VMM Proが基盤となっていたことです。最初のコマンドを実行する前にスナップショットをロックしておいたおかげで、万が一何か問題が発生した場合でも、90秒以内に元の状態に戻すことができました。問題は発生しませんでしたが、VMM Proがなければ作業を開始できなかったでしょう。

SynologyとVMM Proとは何ですか？

Virtual Machine ManagerはSynologyのハイパーバイザーパッケージです。パッケージセンターからインストールでき、無料です。単一のNAS上で、ローカルスナップショットを使用してLinux、Windows、およびVirtual DSMゲストを問題なく実行できます。 VMM Pro これは、単一ボックスのハイパーバイザーを小規模なクラスターに変える有料アップグレードです。複数のNASユニットを1つのプールとして管理し、ゲストOSがユニット間を移動でき、高可用性を実現し、スナップショットをホスト間で複製できます。

この記事では、この区別が重要になります。なぜなら、適切なサイジングは容量に関する決定であり、容量は複数のマシンを運用する場合にのみ重要になるからです。単一のNASでは、解放されるメモリはそのNAS上で未使用のままになっているメモリです。VMM Proクラスタでは、解放されるメモリはフェイルオーバー時に別のホストが借りることができるメモリ、または何も購入せずに新しいゲストを構築できるメモリです。

A 仮想DSM ゲスト（仮想マシンとして実行される完全な DSM インストール）は、ここでサイズ変更したワークロードです。ゲストは Container Manager を実行し、このストアの背後で 2 つの Docker コンテナを実行します。このレイヤリングは意図的なものであり、ジョブを安全に実行できるようにしました。ゲスト間で Docker スタックを移動する方法については、 VDSM Docker移行の手順; この記事は、その下のゲストを適切なサイズにする方法についてです。

VMM Proと無料版の比較：アップグレードで実際に何が得られるのか

無料版は機能が制限されたデモ版ではありません。本番環境のゲストOSを実行でき、スナップショットも取得できます。単一のNASであれば、ほとんどの人が必要とする機能はすべて備えています。 VMM Pro これはゲストOS上の機能ではなく、ホストOS全体に共通する機能です。

能力	無料版	VMM Pro
1台のNASでゲストOSを実行する	はい	はい
ローカルスナップショット	はい	はい
複数のNASユニットを1つのクラスターとして扱う	いいえ	はい
ゲストをホスト間で移動する	いいえ	はい
高可用性フェイルオーバー	いいえ	はい
スナップショットを別のホストに複製する	いいえ	はい

購入前に、参考文献にリンクされている公式機能ページを確認してください。Synology では、DSM リリース間のエディション分割が改訂されています。実際のテストは表よりも簡単です。NAS を 1 つ所有していて、スナップショットから手動で復元することに満足している場合は、無料版で問題ありません。2 つ目の NAS を所有していて、最初の NAS が故障してもゲストを継続させたい場合は、 VMM Proライセンス.

当社のクラスタは3ノード構成で、そのうち2ノードはほとんどの場合電源が入っています。3ノード目はコールドスタンバイで、スケジュールに従って起動し、レプリケートされたスナップショットを受信した後、再びスリープ状態に戻ります。冗長性が必要な時だけ電気代を支払うというこのパターンはVMM Proパターンであり、コンソールに接続できないホストに関する警告が常に表示される理由です。この警告は設計上の不具合ではなく、正常に動作している証拠です。

制作ゲストが本来必要な規模の2倍になってしまう理由

ゲストの滞在時間を増やす要因は3つあり、減らす要因は何もありません。1つ目は、最初の部屋のサイズはあくまで目安であり、初日は余裕を持ったサイズを選んでも費用がかからないことです。2つ目は、どんなトラブルも最終的には誰かが部屋のサイズ制限を引き上げることで解決することです。私たちのホテルでは1週間に2回、メモリ不足のトラブルがありましたが、どちらも部屋のサイズを少し広げることで解決し、その後は再発しませんでした。3つ目は、メモリ使用率が80%と表示されるダッシュボードを見ると不安になるため、誰もメモリを減らそうとしないことです。これらはVMM Proの問題ではなく、人間的な問題であり、だからこそ大柄なゲストが当たり前になっているのです。

最後の点が落とし穴であり、はっきり言っておく価値があります。コンテナに空き容量があるかどうかを判断する際に多くの人が参考にする数値は、間違った数値なのです。私たちの場合は、データベースコンテナが制限の81%に達していると表示されましたが、実際はそうではありませんでした。第5章では、その理由と、VMM Proのリサイズを希望的観測ではなく安全な判断へと変えた測定方法について詳しく説明します。

VMM Proを使用してライブゲストのサイジングを最適化する4つのステップ

作業全体は4つのステップで構成されており、サイトがオフラインになるのは3番目のステップのみです。コンテナが停止してから、ゲストが戻ってきて最初のHTTP 200応答が返されるまでのダウンタイムは、合計で2分7秒でした。 VMM Pro ステップ1とステップ3に関与し、中間のステップはゲストの体内で起こります。

docker stats が正しい答えからあなたを遠ざける理由

サイズ変更前は、コンテナダッシュボードはまるで余裕のない機械のように見えました。

docker stats WordPress 2.51 GiB / 7 GiB (35.9%) WordPress-DB 3.25 GiB / 4 GiB (81.1%) <-- ほぼ満杯のようです

それを読むと、データベースには4ギガバイトが必要で、ゲストOSは12ギガバイト未満にはできないと結論づけるかもしれません。しかし、どちらの結論も間違っています。なぜなら、これらのツールが報告するメモリ使用量にはページキャッシュが含まれており、ページキャッシュは他の何かがメモリを必要とするとすぐに自動的に解放されるからです。メモリ不足による強制終了が発生するかどうかを決定する数値は、匿名メモリです。これを直接読んでみてください。

docker exec sh -c 'awk "/^(cache|rss) /{printf "%-8s %8.0f MBn", $1, $2/1048576}" /sys/fs/cgroup/memory/memory.stat' WordPress rss 1305 MB キャッシュ 1609 MB WordPress-DB rss 2553 MB キャッシュ 1543 MB

ここで状況は一変します。アプリケーションコンテナが実際に使用しているメモリは2.5GBではなく1.3GBです。そして、その1.3GBのうち768MBは、すべてのワーカープロセスがコピーではなくマップする単一の共有オペコードキャッシュです。つまり、20個のワーカープロセスはそれぞれ約27MBのメモリを消費しており、単純なプロセスメモリの合計から推測される250MBではありません。データベースの2.5GBは、663MBのデータベースに対して3GBのバッファプールがほぼすべて使用されていました。

同じ系統の落とし穴がもう一つあります。履歴ピークカウンターは、ページキャッシュも含むため、上限に達したコンテナをそのまま表示してしまうことがあります。私たちの環境では両方ともそうでした。どちらもメモリ不足で強制終了されたことはありませんでした。最高値ではなく、メモリ不足カウンターを確認してください。

この2つの事実を踏まえると、8ギガバイトという数値はもはや危険な数字ではなくなった。バッファプールを1ギガバイトに縮小しても（それでもデータベース全体よりは十分大きい）、サイズ変更に必要な以上の実メモリが解放された。最終的にVMM Proに入力した数値は、ゲストOSをシャットダウンする前に既に検証済みだった。

小規模チームがVMM Proを使用してサーバー全体を復旧する方法

Synology ゲストのメモリは固定されています。ハイパーバイザがメモリをロックして事前割り当てするため、他のプラットフォームのようにメモリを過剰に割り当てることはできません。ゲストに割り当てられた 16 ギガバイトは、ゲストがビジー状態かアイドル状態かに関わらず、他のゲストが使用できない 16 ギガバイトです。この制約があるからこそ、適切なサイジングを行う価値があるのです。 VMM Pro 具体的には、NASを購入する以外で容量を増やす唯一の方法は、メモリを解放することです。

合計46.83GBのホストで、8GBのメモリが返されました。利用可能なメモリは約22GBから30.29GBに増加しました。実際には、計測値から算出されただけで、実際に運用している規模のゲストが2つ増えたことになります。3ノード構成のクラスタでは、これは残りのホストが、障害が発生したノードのゲストを吸収するための余裕が増えることを意味し、そもそもVMM Proを購入する目的そのものです。

CPU側では、より率直に同じことが言えました。ゲストOSは8つの仮想CPUを持ち、休止状態では1つのコアの約6分の1しか使用していませんでした。4つは妥協ではなく、依然として十分な数であり、VMM Proはそれを単一のフィールドに適用しました。サイズ変更後、ゲストOSは4つのvCPUに対して平均負荷1.36を維持しており、これは1日のうち最も負荷の高い時間帯でも約3分の1が使用されていることを意味します。

起動時のメモリ不足ループを防ぐための操作順序

ここは間違えやすく、間違えると高くつく部分です。コンテナのメモリ制限と、VMM Proで設定したゲストのメモリは、それぞれ独立した上限値です。コンテナの制限値の合計がゲストのメモリを超えると、コンテナはマシンが持つメモリよりも多くのメモリを使用できることになります。負荷がかかると、カーネルはこの不一致を何らかのプロセスを強制終了することで解決します。

変更前の制限は、アプリケーションコンテナが7ギガバイト、データベースが4ギガバイトで、16ギガバイトのゲストOSでは合計11ギガバイトでした。これは問題ありませんでした。しかし、8ギガバイトのゲストOSでは、最初のトラフィック急増で問題が発生する可能性がありました。そのため、まずコンテナを停止する必要がありました。

設定	前に	後
ゲスト	8 vCPU / 16 GB	4 vCPU / 8 GB
アプリケーションコンテナの制限	7168 MB	4096 MB
データベースコンテナの制限	4096 MB	2048 MB
データベースバッファプール	3GB	1GB
データベースの最大接続数	300	100
アパッチワーカーの天井	50	35

その表には、二次的なルールが隠されています。コンテナのメモリ制限を現在の使用量より低く設定しても、カーネルが適切に処理してくれるとは限りません。アプリケーションコンテナは新しい制限値よりも少ないメモリしか使用していなかったため、再起動やダウンタイムなしでリアルタイムに制限されました。データベースコンテナはそれよりも多く使用していたため、バッファプールを再構成し、コンテナを再起動する必要がありました。そうして初めて、低い制限値を適用できました。VMM Proではこれらの手順はどちらも実行されません。サイズ変更ダイアログを開く前に、両方の手順を完了する必要があります。

ワーカー数の上限設定は、この取り組み全体における唯一の真のコストであり、隠蔽するのではなく明記しておくべき点です。アプリケーションコンテナを7ギガバイトから4ギガバイトに削減することで、同時実行可能なリクエスト数を減らすことができます。ピーク時の同時実行数は50から35に減少し、30%削減されます。通常、サイトは11のワーカーで稼働しているため、何も変わりません。広告の集中配信時には変更が生じる可能性があります。これは私たちが意図的に行ったトレードオフであり、次の担当者がシステム障害時に同じ問題に遭遇しないように、ここに明記しておきます。

AIアシスタントが実際に行ったこと、そしてその間違いはどこだったのか

アシスタントは、忍耐が報われる部分を実行しました。何も操作する前にVMM Proスナップショットを取得し、ダッシュボードを鵜呑みにするのではなくcgroupの統計情報を読み込み、コンテナ制限の順序制約を計算し、実際のページを取得して価格が正しい通貨で表示されていることを確認することで結果を検証しました。これはおそらく40分かかるような慎重な作業を数分に凝縮したものであり、非常に役立ちます。

また、1回のセッションで3回も間違えたという点も、この話のより重要な部分だ。

• 所有者が8ギガバイトを要求したのに対し、システムは10ギガバイトを推奨した。所有者の要求は正しかったが、それは同時にバッファプールのサイズが大きすぎたためである。アシスタントは測定値を手元に持っていたにもかかわらず、より安全な数値である8ギガバイトを基準に判断を下していたのだ。
• ゲストの名前を変更したと読みました 成功: true APIから取得したデータに対して、名前変更が完了したと報告されました。しかし、実際には名前は変更されていませんでした。APIが使用した名前変更フィールドは、ゲストを識別するフィールドであり、名前を変更するフィールドではありませんでした。APIはどちらの場合でも成功を返します。
• VMM Proクラスタが到達不能なホストに関する警告を検知し、それを劣化フェイルオーバーパスとしてフラグ付けした。当該ホストは意図的に電源がオフにされているコールドスタンバイであった。この警告は設計上、数か月前から表示されていた。

3つのパターンすべてに共通するのは、もっともらしいチェックから得られる確実な出力です。したがって、実際に重要なガードレールは地味なものです。リスクの高いコマンドを実行する前ではなく、最初のコマンドを実行する前に、必ずスナップショットを取得してください。戻り値を証拠として受け入れてはいけません。状態を読み戻し、変更しようとしたフィールドを確認してください。設定ではなく動作を検証してください。ページが読み込まれ、価格が正しいことは、コマンドがゼロで終了したという確認を何度しても損なうことはありません。

これらはAIに限った話ではありません。ルートアクセス権限を持つ新しい同僚に求める規律と同じもので、仕事が速く、精力的に働き、時折、事実ではないことを確信してしまうような人にも当てはまります。

その他の公式資料の入手先

VMM Proでファイルのサイズ変更を行う前に、ぜひ見ておくべき動画が3つあります。1つ目はパッケージ自体の概要を最も分かりやすく解説したもので、残りの2つはゲストの作成とライセンス認証について説明しています。これは、多くの人が初めて試す際につまずく部分です。

VMM Proを生産現場で使用する前に知っておくべき制限事項

メモリは過剰割り当てできません。割り当てた1ギガバイトごとに、NAS上の他のすべてのデータ（使用状況に関わらず）から隔離されます。この制約があるため、適切なメモリ容量を選択することが重要になります。また、この制約こそが、過剰割り当てが可能なプラットフォームに比べて、導入初日に余裕を持った容量を割り当てるとコストが高くなる理由でもあります。

メモリを縮小するには再起動が必要です。VMM Pro は実行中のゲストからメモリを解放しないためです。仮想ディスクの拡張や一部のリソースの拡張はリアルタイムで行われますが、メモリを解放するにはゲストをシャットダウンする必要があります。短時間の停止を想定してスケジュールを立ててください。2分程度であれば可能ですが、ゼロではありません。

仮想ディスクは拡張するだけで縮小することはありません。メモリではなくストレージを過剰に割り当てた場合、, VMM Pro 返却はしません。唯一の方法は、新しいゲストOSを構築してそこに移行することですが、これは今日の午後よりもはるかに長い時間がかかります。

コンテナ内のCPU制限は、全く機能しない可能性があります。このゲストOSでは、カーネルにCFS帯域幅制御機能がないため、コンテナのCPUクォータは即座に拒否されます。さらに悪いことに、メモリ制限と同じコマンドでCPUクォータを設定しようとすると、コマンド全体がサイレントに失敗します。利用可能なCPU保護手段は、メモリ制限とアプリケーション自身のワーカー上限のみです。

スナップショットはバックアップではありません。スナップショットは、保護対象のゲストと同じホスト、同じストレージプール上に存在します。VMM Proはスナップショットをより近い別のホストに複製できますが、建物火災から生き残るのは、やはりデータ自体のオフサイトバックアップです。

最後に、コンソールに表示される内容を確認してください。コンテナの詳細ページには、環境変数がプレーンテキストで表示されます。データベースのパスワードも含まれています。これはDockerの仕様上の欠陥ではなく、Dockerの正直な仕様なのですが、間違ったページのスクリーンショットを1枚撮るだけで認証情報が公開されてしまうことを意味します。もしそれが気になるのであれば（気になるはずです）、機密情報を変数として渡すのではなく、コンテナが読み込むファイルに移動させてください。

参考文献

• SynoPower Club, Synology NASガイドとカメラレビュー
• Synology — Virtual Machine Manager, 公式の機能とエディションの比較
• Synology ナレッジセンター — Virtual Machine Manager ヘルプ, ゲスト設定とクラスタ設定
• Docker — Dockerコンテナの更新, 実行中のコンテナのメモリ制限を変更する
• Apache — MaxRequestWorkers, 第7節で議論した労働者の上限

よくある質問