VirtualBox上でPixelmonサーバーを運用していた構成を前提に、この記事ではWSL2へ移行する判断材料を整理します。
ここでは、運用中に観測されたホストOS側のリソース占有を中心に、VirtualBoxからWSL2へ移行する理由と運用上の課題を記録します。
1. リソースの最適化と運用の高度化
現在、PixelmonサーバーはVirtualBox上のRocky Linuxにて稼働していますが、運用フェーズにおいて「ホストOS側のリソース占有」という課題が観測されました。
最大の要因は、Type-2ハイパーバイザー特有の静的なメモリ確保です。タスクマネージャーのログを確認すると、仮想マシン自体がホストOSのメモリを大きく占有し、ゲストOS内での実消費量と大きな乖離が発生しています。このオーバーヘッドを排除し、リソース効率を最適化した環境を再構築します。
現状の稼働状況：仮想マシン(約8.2GB)に対し、Javaプロセス(約3.2GB)と乖離がある
2. WSL2を採用するアーキテクチャ上の理由
次期インフラ環境としてWSL2を選定しました。主な技術的根拠は以下の通りです。
// 動的メモリ割り当て（Dynamic Memory）
VirtualBoxは、起動時に設定したメモリ領域をホストから完全に切り離して確保する仕様です。対してWSL2は、Linux側のプロセスが必要とする量に応じて、ホストOSとメモリを動的に共有するアーキテクチャを採用しています。
// ファイルシステムI/Oの親和性
WSL2は仮想ディスク（ext4）内で動作し、ホスト（Windows）側から \wsl$ 経由で直接マウントポイントへアクセス可能です。また、ホストOSと統合された軽量ユーティリティVMを利用するため、プロセスの起動・停止にかかるレイテンシが大幅に削減されます。
3. 構成管理のコード化（IaC）とコンテナ運用
今回の再構築において、手動オペレーションによる「ゴールデンイメージ」への依存を破棄します。コードによる環境の再現性とポータビリティの確保を要件とします。
// Dockerによる実行環境のコンテナ化
Javaランタイム、NeoForge、およびサーバー本体をDockerコンテナとしてカプセル化します。これにより、ホストOSの環境汚染を防ぎつつ、依存関係を含めた同一環境を即座にデプロイ可能なポータビリティを確保します。
// Ansible / Terraformによる土台構築（IaC）
WSL2上でのパッケージ導入やDockerエンジンのセットアップなど、インフラのプロビジョニングをAnsible等の構成管理ツールで自動化します。環境構築のプロセス自体をコード（IaC）としてバージョン管理の対象に含めます。
// データと実行環境の疎結合化
コンテナはステートレスな実行環境として定義します。ワールドデータやConfig等の永続化が必要なデータは、ホスト側のディレクトリ（またはDocker Volume）へバインドマウントし、コンテナの再生成時にもデータが担保される疎結合な構成を構築します。
4. 次世代インフラ設計の具現化
ホストOSにおけるメモリリソースの固定的な枯渇を防ぎ、システム全体のパフォーマンスを最適化するためには、従来の仮想化アプローチからWSL2＋Dockerアーキテクチャへの移行が合理的と判断しました。
VirtualBox運用で見えた固定的なリソース占有や管理負荷を整理したことで、WSL2、Docker、Ansibleを次のローカルサーバー基盤として検討する理由が明確になりました。