conoha（www.conoha.jp）というVPSサービスが安くて良さそうなので使ってみた。
これまで、AWSでEC2のt2.microを利用してfactorio headlessを立ち上げていたが、突然ゲーム内のスピードが落ちてカクカクになったのに、topコマンドの結果を見るとCPU使用率は低いまま。原因を調べた結果、tシリーズはCPU creditというものが設定されていて、それを使い切ってしまうと、CPUの能力を十全に活用できずキャップがかかる仕様と判明。そもそも、本来、t2.microはCPUをあまり利用しないサービスが前提となっているものの、起動など一時的にCPUを使用するシーンのみ、お情けとして規定された性能分だけCPU性能をオマケしてもらっている、という仕様らしい。CPUをガンガン常用するようなゲームサーバには適していないことが判明。
じゃあ、適したAWSのインスタンスタイプがどれかなと調べているとき、factorioがプリインストールされているVPSを格安で貸し出してくれる本サービスを発見し利用に至る。注意点は、サーバ停止時も利用料がかかってしまうこと。どうせ停止中でもお金がかかるなら起動しっぱなし（factorio headlessは誰もプレイしていないときはゲーム内時間がSTOPする仕様）とするか、毎回、セーブデータをローカルなどにバックアップしてサーバ自体を削除/新規するかの2択となる。
ちなみに、FAQには詐欺（？）のような書き方で「停止していても料金はかかる」と書いてある。
停止時の料金はありますか？(ConoHa VPS・ConoHa for Windows Server・ConoHa for GAME)
ConoHa VPS・ConoHa for Windows Server・ConoHa for GAMEについて、停止（シャットダウン）いただいた場合でも料金が変動することはございません。サーバーの稼動、停止の状態にかかわらず、ご契約数で料金が発生いたします。
https://support.conoha.jp/common/faq/payment-q/
セキュリティグループはプリセットから下記を適用する。Webコンソールは使いにくいし、セーブデータのアップロードやダウンロードができないので、SSH portを開放してやり、Teratermなど手に馴染んだクライアントソフトから接続するのが吉。
- IPv4v6-SSH
- IPv4v6-Factorio
セーブデータは下記に格納されている。コマンドからマップのカスタマイズをするのは面倒なので、ローカルのfactorioで作成したセーブデータを同名でアップロードしてやるのが吉。
- アップロード先：/opt/factorio/savedata/factorio_save.zip
- アップロード元（Windows Steam版）：%appdata%\Factorio\saves
conohaのすごいところは、factorioがプリインストールされているだけではなく、serviceまで作り込まれているところ。enableになっているので、サーバを起動した時点でfactorioが起動している。おなじみのsystemctlからサービスを起動/停止しよう。なお、ポートはデフォルト（34197）となっている。先程設定したセキュリティグループ（IPv4v6-Factorio）も34197が許可されている。
- systemctl status factorio.service
- systemctl stop factorio.service
- systemctl start factorio.service
statusを確認してみた。
# systemctl status factorio.service
● factorio.service - Factorio Server
Loaded: loaded (/etc/systemd/system/factorio.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2023-10-10 09:30:36 JST; 2h 8min ago
Main PID: 138266 (sh)
Tasks: 12 (limit: 1065)
Memory: 651.7M
CGroup: /system.slice/factorio.service
tq138266 /bin/sh -c /usr/bin/screen -DmS factorio /opt/factorio/factorio/bin/x64/factorio --start-server /opt/factorio/save>
tq138267 /usr/bin/SCREEN -DmS factorio /opt/factorio/factorio/bin/x64/factorio --start-server /opt/factorio/savedata/factor>
mq138276 /opt/factorio/factorio/bin/x64/factorio --start-server /opt/factorio/savedata/factorio_save --console-log /opt/fac>
Oct 10 09:30:36 vm-1c3075e2-0b systemd[1]: Started Factorio Server.
config.iniはデフォルトなので、必要に応じて修正する。デフォルトだと、10分間隔にオートセーブでフリーズがかかってうざいので、autosave-intervalは長めにしておくことを推奨。この方法だと、何故か設定が適用されない不具合が発生。解消方法は後述。
# pwd
/opt/factorio/factorio/config
# diff config.ini.default config.ini
21c21
< ; autosave-interval=5
---
> autosave-interval=20
23c23
< ; autosave-slots=3
---
> autosave-slots=5
上記の方法だと何故か設定が反映されない。別の方法を模索した結果、下記のjsonで設定してやるとうまくいくことが判明。exampleをコピーして設定ファイルを新規作成。仲間内でのゲームなので、public/lanをいずれもfalseにして、autosave_intervalを60分に変更。その後、この設定ファイルを読み込むよう、起動オプションに追加してやる。
- /opt/factorio/factorio/data/server-settings.example.json
- /opt/factorio/factorio/data/server-settings.json
# diff server-settings.example.json server-settings.json
13,14c13,14
< "public": true,
< "lan": true
---
> "public": false,
> "lan": false
48c48
< "autosave_interval": 10,
---
> "autosave_interval": 60,
serviceファイルの起動オプションに「–server-settings /opt/factorio/factorio/data/server-settings.json’」を付与する。systemctl daemon-reloadでserviceの再読み込みを忘れずに。
# cat /etc/systemd/system/factorio.service
[Unit]
Description=Factorio Server
After=network.target nss-lookup.target
[Service]
Type=simple
User=factorio
Group=factorio
WorkingDirectory=/opt/factorio
ExecStart=/bin/sh -c '/usr/bin/screen -DmS factorio /opt/factorio/factorio/bin/x64/factorio --start-server /opt/factorio/savedata/factorio_save --server-settings /opt/factorio/factorio/data/server-settings.json'
ExecStop=/usr/bin/screen -p 0 -S factorio -X eval 'stuff "/server-save\015"'
ExecStop=/bin/sleep 5
ExecStop=/usr/bin/screen -p 0 -S factorio -X eval 'stuff ^C'
ExecStop=/bin/sleep 5
Restart=always
[Install]
WantedBy=multi-user.target
# systemctl daemon-reload
