プロジェクトの動機、リソースの最適化と運用の高度化
現在、PixelmonサーバーはVirtualBox上でRocky Linuxを動かすことで安定稼働していますが、運用を続ける中で「リソースの有効活用」という新たな課題が見えてきました。
最大の動機は、仮想化に伴うメモリ占有の解消です。現在のタスクマネージャーを確認すると、仮想マシンそのものがホストOSのメモリを大きく占有しており、サーバー内での実消費量との乖離が発生しています。この「器」によるオーバーヘッドを削ぎ落とし、より洗練された環境を構築することが今回の目的です。
現状の稼働状況：仮想マシン(約8.2GB)に対し、Javaプロセス(約3.2GB)と乖離がある
なぜWSL2を採用するのか
次期環境としてWSL2を選定した理由は、そのアーキテクチャにあります。
// 動的メモリ割り当て（Dynamic Memory）
VirtualBoxのようなType-2ハイパーバイザーは、起動時に設定したメモリ分をホストから完全に切り離して確保します。対してWSL2は、Linux側のプロセスが必要とする量に応じて、ホストOSとメモリを柔軟に共有する仕組みを持っています。
// ファイルシステムI/Oの親和性
WSL2は仮想ディスク(ext4)内で動作するため、Windows側から \wsl$ 経由で直接アクセスでき、メンテナンス性が向上します。また、ホストOSのカーネルを共有する軽量VMであるため、プロセスの起動・停止にかかるコストが低いことも選定の根拠となりました。
構築のロードマップ（IaCとコンテナ化へ）
今回の再構築では、旧来の手動による「ゴールデンイメージ作成」への依存を完全に破棄し、コードによる「環境の再現性」と「ポータビリティ」を最優先事項とします。
// Dockerによる実行環境のコンテナ化
Java、NeoForge、そしてサーバー本体をDockerコンテナ内に封じ込めます。これにより「どのPC（WSL2環境）に持っていっても、コマンド一発で同じ環境が立ち上がる」ポータビリティを獲得し、ホストOSをクリーンな状態に保ちます。
// Ansible / Terraformによる土台構築（IaC）
WSL2内のパッケージインストールやDockerエンジンのセットアップといった「土台作り」を手作業で行うのは時代遅れです。Ansibleなどの構成管理ツールを用いてプロビジョニングを自動化し、環境構築のプロセス自体をコードとして管理・バージョン管理します。
// データと実行環境の完全な疎結合化
コンテナはあくまで「一時的な処理の実行環境」として扱います。ワールドデータやConfigといった永続化が必要なデータはホスト側（またはDocker Volume）にマウントし、コンテナをいつ破棄・再生成してもデータが失われない堅牢な構成を目指します。
次回、モダンなインフラ設計の具現化
VirtualBoxのスナップショットには何度も助けられてきましたが、今のタスクマネージャーの状況を見ると、やはり「器」の重さが無視できなくなってきました。PCのリソースを無駄なく使いつつ、よりモダンな開発体験を得るために、WSL2＋Dockerへの移行は必然と言えます。
次回は実際にWSL2上でDocker環境を展開し、IaCの概念を取り入れながら、コマンド一発で立ち上がるサーバー環境を組み上げていく手順をまとめていきます。