なぜいま、自前でサーバーを立てるのか
1年ほど前から趣味でLinuxを触っています。過去VPSでブログ運用や、シェルスクリプトを用いたクラウドデータ保存の自動化などを行いながら学習を進めていました。そして今回、新たな技術的好奇心の対象としてMinecraft（Pixelmon）サーバーの構築を開始したのが経緯になります。
ゲームをプレイするだけでなく、Linux上でのサービス管理、リソース監視、そして運用自動化のパイプラインを自らの手で組む過程そのものを楽しんでいます。
運用環境とコンセプト
本環境では、エンタープライズのような高可用性よりも、個人開発における「検証の容易さ」と「プライバシー」を最優先事項としています。
// LAN限定運用の合理性
主な用途は同居しているパートナーとのマルチプレイです。外部公開を制限することで、不要なポート開放（Port 25565等）に伴うDDoS攻撃や不正アクセスのリスクを物理レイヤーで遮断しています。
// 仮想化プラットフォームの選定
長年馴染みのある Oracle VirtualBox を採用。最大の利点は「スナップショット機能」にあります。Modの競合やConfigミスによりシステムが不安定化した際、数秒で正常な状態へロールバックできる環境は、試行錯誤が続くサーバー構築において重要な役割を担っています。
VirtualBoxの管理画面
サーバー内部の管理・運用構成
OSにはエンタープライズ実績のある Rocky Linux 9.4 を、実行環境には NeoForge 21.1.220 を選定しました。
Pixelmonを安定して動作させるため、そして冒険をより快適にするため、いくつかの重要なModを導入しています。具体的には、メモリ使用量を最適化しラグを抑制する ModernFix や FerriteCore、広大な世界をマッピングする JourneyMap、そして移動時のチャンク読み込み負荷を劇的に軽減する Chunk-Pregenerator など、サーバー・クライアント双方の負荷軽減を重視した構成です。
- [ Performance / 軽量化 ]
- ModernFix / FerriteCore / AI-Improvements
- [ Utility / 冒険支援 ]
- JourneyMap / Waystones
- [ Stability / 安定化 ]
- Chunk-Pregenerator (移動時のiOWaitラグ抑制)
mod一覧
自動化、メンテナンススクリプト
本運用における肝は、バックアップ前の「徹底したクレンジング」です。単なる圧縮保存ではなく、不要ファイルをパージすることでストレージ効率を最適化しています。
cat backup.sh
#!/bin/bash
# --- 設定 ---
DATE=$(date +%Y%m%d-%H%M)
BACKUP_DIR="/opt/minecraft/backup"
SERVER_DIR="/opt/minecraft/server"
WORLD_DIR="${SERVER_DIR}/world"
# --- 1. バックアップ前のお掃除 (軽量化) ---
find ${SERVER_DIR}/logs/ -name "*.log.gz" -mtime +7 -delete
rm -rf ${SERVER_DIR}/crash-reports/*
rm -f ${WORLD_DIR}/*.bak
rm -f ${WORLD_DIR}/level.dat_old
rm -rf ${WORLD_DIR}/EliteRaidAllies.bak
# --- 2. バックアップ実行 ---
tar czf $BACKUP_DIR/world-$DATE.tar.gz $WORLD_DIR
# --- 3. 世代管理 ---
find $BACKUP_DIR -type f -name "world-*.tar.gz" -mtime +7 -delete
このスクリプトにより、ストレージの枯渇を防ぎつつ、過去7日間の任意の時点へ復元可能な状態を維持しています。これらは crontab により、毎日深夜4:00に自動実行されます。
安定稼働を支える運用管理体制
// プロセス管理の最適化
MinecraftをSystemd配下でサービス化することで、OS起動時の自動開始や異常終了時の自動再起動を実現しています。また、tmux を利用し、バックグラウンド実行中も必要に応じてコンソールへアタッチし、直接コマンドを送出できる環境を整えました。
リソース監視には btop を導入。JVMのメモリ使用量やストレージI/Oをリアルタイムに可視化することで、Mod起由のラグやボトルネック特定を迅速化しています。
実際の運用管理画面（tmuxログモニター）
今後の展望、WSL2への移行とIaC化
現在はVirtualBoxでの運用ですが、タスクマネージャーを監視する中で仮想化に伴う「静的メモリ占有」が看過できない問題となってきました。
ホストマシン（Ryzen 7 5700X / 32GB）からVMへ8GBのメモリを割り当てていますが、サーバーが実際に4GBしか使っていなくても、VirtualBoxの仕様上、ホストからは8GBが完全に奪い取られてしまいます。使っていようがなかろうが指定した値を奪うため、残りは「死にメモリ」と化し、VS Codeなどホスト側のパフォーマンスを不当に圧迫しています。
この非効率を解消するため、メモリを動的に共有できる WSL2 への移行を決定しました。
同時に、スナップショットや手動による「ゴールデンイメージ」への依存を破棄します。今後はWSL2上で Dockerによるコンテナ化 を行い、AnsibleとTerraformを用いた土台構築（IaC） を導入することで、コマンド一発でポータブルかつ強固なサーバー環境を展開できるモダンなアーキテクチャへと進化させる予定です。