minecraftBedrockAtHome.md (7533B)
1 --- 2 title: 自宅にMinecraft Bedrock Serverを立てた話 3 tags: 4 - minecraft 5 private: false 6 updated_at: '2026-06-17T07:11:33+09:00' 7 id: 07ca7d9d4b6927bb2df0 8 organization_url_name: null 9 slide: false 10 ignorePublish: false 11 --- 12 # 想定読者 13 - インフラエンジニア 14 # 始めに 15 この記事は半分は備忘録です． 16 なので，完成品についてだけでなく，試そうとした色々な構成についても書いています． 17 ## 記事の前提 18 この記事の前提として，Minecraft Bedrock Server(以下BDS)については知っているものとします． 19 例えばUDPを使っているみたいな解説はいちいち致しませんのでご了承ください． 20 # 前記 21 以前に使っていたBDSのデプロイ構成を簡単にご紹介したいと思います． 22 シングルノード上に`Ubuntu Server`をインストールし，その上にdockerを使ってコンテナでBDSのコンテナをデプロイしていました. 23 コンテナイメージは[`itzg/minecraft-bedrock-server`](https://hub.docker.com/r/itzg/minecraft-bedrock-server)を使用しました． 24 サーバーを外に出すため，契約していた光回線のポートを一つ解放してUDPバケットを通すような方式にしていました． 25 26 ## 反省 27 この構成を続けないという決断に至ったのは，この構成でのラグがひどいという報告を受けたからです． 28 実際にプレイしているところを画面共有見せてもらったりしたのですが，敵をクリックした数秒後にダメージが入った演出があり，その気にはすでにこちらがダメージを負っているみたいなことが珍しくなかったです． 29 これについて私は深く深く反省し，UXの向上に努めるべく，インフラエンジニアの威信をかけて，次のサーバーをデプロイしようというところであります． 30 31 # 構成の構想 32 ひと口にラグを改善するといっても手段は幾通りもあります．ここで注目したいのは，前回LAN内で折り返しをしていた私のプレイだけは非常に快適だったことです．つまりのところサーバー側に関してはほとんど問題なく稼働しており，サーバーが外に出るまでのところについて私どもの改善が見込まれるのではないかなと言う結論に至りました． 33 34 ## 上流について 35 ここで一つ注意なのですが，私が以前に使っていた光回線はソフトバンクで，私が今回使う回線は大家さんの意向で更新されたマーブル光であります．つまり厳密な検証環境ではないということは重々ご承知いただきたいなと思います． 36 基本的にはソフトバンク光よりもマーブル光の方が通信速度も安定していてパケットロスも少なくて回線の品質は良いです．しかしながらマーブル光はポート開放をすることができません．固定IPオプションを申し込めばもしかしたらみたいな話を聞いたのですが，そこらへんの準備がうまくいってない段階でこの企画を始めてしまったので，ポート開放は諦めて代替の手段を使います． 37 38 ## サーバーを外に出す 39 サーバーを外に出す方式について，本当はCloudflareトンネルを使いたかったのですが，トンネルが場合によってはUDPパケット通さないという仕様があったため，泣く泣く別のトンネルサービスを利用することにします． 40 それが`playit.gg`です．ゲーム用にサーバーをエクスポートするためのサービスらしくて，これ以外に良さげな選択肢がなかった(あったら教えてほしい)のでこれで頑張るという感じです．今のところそこまで悪い印象はないですが(ソフトバンク回線の時に比べて)，本番環境で8人とかが同時ログインしたら話が変わってくるかもしれません． 41 42 ## どこを高速にするべきか 43 以上のことを踏まえまして，今回速度向上のために使用するのは，LAN内部でどれだけロスを減らせるかに尽きるかと思います． 44 45 ## 反省点 46 前回，ボトルネックになっていた可能性のある箇所について列挙します． 47 48 - Dockerのネットワークを経由してノードネットワークに出ていた 49 - Ubuntu Serverの過剰な機能がリソースを圧迫した 50 - Dockerが制御に挟まっていた 51 52 このあたりかなと思っています． 53 ## 改善点 54 なんだかDockerが悪者みたいな書き方をしていますが，`docker compose`などは非常によい奴で，自分が最初にシステム管理を担当したときにDockerだったのが心底助かりました．いい奴です． 55 んでも，このくらいのエッジ環境を作るとなると，色々と改善点が見えてくるのです． 56 速度というか，直に動かすという意味では`systemd-nspawn`の方が強いですし，そこまでいかなくても`containerd`を直に触るほうが，そりゃ速いですよ． 57 ということで，Dockerを使わずにcountainerdを直に叩くorベアメタルにBDSをインストールしちゃう，という方策が一つ立ちました．OSももっとキレッキレのものを使う模索をしたいと思います． 58 ### Flatcar 59 コンテナを動かしたいだけなら，それ専用のOSがあるよという話をKaaSの方から聞いたことがありました．コンテナ専用OSの一つがFlatcarです． 60 [Flatcar公式サイト](https://www.flatcar.org/) 61 他のコンテナ専用OSもあって，k8s専用のTalos等です． 62 63 # 構成案s 64 ## Flatcar-systemd-nspawn 65 FlatcarというOSの上に，systemc-nspawnでBDSをデプロイするという方法です． 66 Flatcar上で色々と動かす必要があって，イミュータブルなシステムと相性が最悪でした． 67 今後はこの構成は登場しません． 68 ## Flatcar-containerd 69 containerdを直接叩こうという試みです． 70 nerdctlコマンドをインストールするIgnitionを書くところで詰まった(適切なバイナリーを落としてきても，バイナリーの形式が実行可能ではないというエラーが出た)ので，頓挫しました． 71 ## Flatcar-k3s 72 containerdを直接叩くような挙動をしたいけれど，Flatcarの外から叩きたいという思想です． 73 k3sを入れたInginitionを書くのが難しかった(検索しても情報が少ない)ので，停止中． 74 ## Gentoo 75 この記事の中で一番狂った選択肢です． 76 Linux Kernelのヘルツを変えてパケットさばきを高速にしたり，各種ツールについて，`-Ofast`でビルドするなどの，速くするためのカスタムを最も自由度が高くできるので，おすすめ． 77 最初に思いついたアイデアですが，作業コストが高すぎるので，テスト期間が終わって余力があったらやろうかなと思っています． 78 ## Alpine-k3s 79 Alpine Linuxというとても小さなLinuxの上にk3sクラスタを作ってcontainerdをコントロールしようというものです．デプロイが比較的簡単で(ほんとか？)，私でも3時間くらいでできました． 80 ちなみにコントローラーもAlpine Linuxですが，workのAlpine Linuxだけベアメタルにしようかなと思ってます．