電話はしていたけど、ここ１年ぶりに帰省してきた。
一番の気がかりは、やはり親の健康とか、生活状態。
両親ともに健在ではあるが、親父が（初回に）倒れてから１０年が経過し、平均寿命も超えたことで、健康状態が何よりも気がかり。
結論として生活状態は良好、健康状態も「現状維持」状態ではあるものの、個人的には「もって１〜数年かなぁ」と思った次第。
その理由が、体重というか体の肉づき状態。
オカン曰く、食欲は以前とそれ程変わらないものの、おそらく栄養として吸収できていないのではないかと。
とはいえ検査しているかぎりでは、腫瘍などの問題はないらしいし、極端な体重変化でもないそうな。
でも１年前に比べて、あの「痩せ具合」は普通ではないわけで。。
あとデイザービスのない日は、昼間の睡眠がかなり増えているそうで。
身体の衰えは着実に進行しているみたい。
まぁ人間には寿命があって、本人が望んでいないかぎりは「成り行き任せ」でよいとは思うが、子としては「そろそろ覚悟が必要かもなぁ」と思った次第。
料金とかサービスは記事掲載時点のものです。
サービス内容については、必ず公式サイトの最新の記事をご確認ください。
トヨタレンタカーには、車両限定・貸渡期間限定・ワンウェイ専用の激安サービス「片道GO!」というのがある。
これはワンウェイで通常利用された車両を、本来の利用地域に戻すため行われているサービスで、元々はレンタカー会社の社員やアルバイトで行われていた回送を「サービスとして提供してしまえ！」という形で始まったものと思われる。
レンタカー会社としては一石二鳥ではあるが、利用者にとっても果たしてメリットがあるのか、Win-Win が成立しているサービスなのか検証してみた。
３人ファミリー以上の利用であれば、おそらく「レンタカー代＋ガソリン代＋高速道路の利用料」としても、「新幹線利用料」に比べて安くなると思うが、もともと１〜２人利用の場合だとかなり微妙になる。
もともと「片道GO!」は2,200円/24時間、または4,400円/48時間の貸渡期間固定のサービスではあるが、予約時点で「あらかじめ車種が決められている」サービスのため、ハイブリッド車でないミニバンクラスになると、当然ガソリン代も嵩む。
「返却店舗」は地域内の指定店舗が選べるものの、「出発店舗」は予約の時点で固定されている。
そのため利用するには、その店舗までは別の交通手段（つまり「別途交通費」）が必要となる。
なお「返却店舗」についても、たとえ同一地域であっても、系列会社の違いで返却できない店舗がある。
たとえば大阪府の場合だと系列会社が２社あり、返却店舗が「トヨタレンタリース新大阪」となっている場合、「トヨタレンタリース大阪」の店舗に返却することはできない。
また、店舗の規模によって返却できない車種（車高制限や貨物・バスワゴンなど）もあるので、注意が必要。
返却時刻オーバーや、指定以外の店舗への返却など発生した場合は、すべて正規料金に基づいた金額で再計算され、返却時に差額を請求される。
なので流動的な予定での旅行における利用には向かない。
交通渋滞も考慮したうえで、返却時刻を厳守する必要がある。
このような形で色々と制限・成約が多いサービスではあるが、タイミングや用途が合致すれば便利なサービス。
一時期、車を持っていないドライバーが、便利に移動するためにこのサービスを利用して激安に移動するような記事・話題があったが、自分自身で運転する以上、疲れるし、ガソリン代や高速道路料金もかかるので「お得か？」と言われると、正直かなり微妙なレベルではないかと思う。
でもファミリー旅行などの場合だと、新幹線の駅⇒自宅までの移動などがダルいので、近隣にトヨタレンタカーの店舗があって、タイミングなどが合えば、帰りの新幹線を払い戻して利用するのは「あり」かも知れない。
ちなみに今回自分が利用したのは、「都心郊外⇔新幹線⇔東海地方」の弾丸帰省。
もともと名古屋駅から東海地方の帰省先まではレンタカーを借りていたのだが、たまたま愛知県内でミニバン・東京都返却の「片道GO!」車両が発生したので、速攻で電話予約。
借りていたレンタカーについても返却先変更の連絡を貸出店に電話してオッケーをもらい、そのまま「片道GO!」車両の店舗で乗り換える形で移動。
（「片道GO!」貸出店も名古屋と同じ愛知県なので、ワンウェイ料金は発生せず。）
自分自身の運転は疲れるものの、子連れでの新幹線移動も結構大変。
それにコロナ禍において駅構内や公共交通の利用はリスクもあるので、ある程度の回避もできる。
それに帰途の際、コインランドリーや夕食がてら静岡県内の「さわやか」、入浴施設などに寄り道立ち寄ることも出来たし、仮眠しながら帰れたので、まぁ「良し」という感じ。
でも夜間の新東名⇒東名はトラックがメチャクチャ多いし、車間ツメツメで運転しているので、ACCとレーンアシスト使っていても神経遣うのが難点。
結局疲れるのは変わらない。うーむ。
こちらの記事は今後随時追記していきます。
こちらは Java Edition に関する記事です。統合版とは仕様が異なる点がある場合がある等、ご注意ください。
大型アプデからおよそ１ヶ月経過したので、アプデしてみた。
ちなみに１ヶ月空けたのは、自鯖で spigot 使ってたり、大バグを警戒しての理由。
あと、Dynmap や OptiFine, Forge といったプラグインや mod の 1.19 対応を待っていたから。
基本的には、1.17 ⇒ 1.18 にアプデした時と手順は同じ。
今回 Java のアプデは必要なかったので、そのぶん手順は減ったけど、modのアプデが、現時点では一部間に合っていない。
41.0.100 の話
いつ安定版になるんやろか。
Spigot をアプデして、クライアントはノーマルな状態で動かしたら問題なかったのだが、その後β版 Forge をインストールしたところ、起動時に見事クラッシュ。
おそらくその出かけた普通の自分の場合、手懐けたネコの種類（ネコの柄）が、すべて Tabby になってしまっている。
でもって data コマンドで調べてみたところ、CatType というネコの種類を指定する値がどうも見つからない。
おそらくこれが原因で CatType=0 つまりTabby になってしまっている模様。
これがクラッシュの影響なのか、β版を入れた影響なのかは判らない。
1.18.2 の環境では Forge の中に OptiFine も同居できたが、1.19 対応の現バージョンでは同居不可。起動時に Java がクラッシュする。
泥ブロックとかカエルとか古代都市の話は、他サイトの記事で沢山取り扱われているので割愛。
なので一度これらの合体トロッコを作成すると、永久にそのまま使うことになる。
これが意外と鬱陶しい。
というのも、ここ数年のバージョンは（地下が深くなったり、バイオーム分布の影響で？）地下廃坑がかなり多く生成されやすくなった感じがするので、地下の湧き潰しがてらブロック収集していると「チェスト付きトロッコ」が割と見つかる。
これが今まではチェストとトロッコに分解できたので、それぞれ別用途に流用できたけど、今後は永久に「チェスト付きトロッコ」のままなので、使い道が限定されてしまった。
個人的にチェスト付きトロッコの使い道は、現状ほぼゼロ。
そのため当面は死蔵品。今後チェスト付きトロッコを使うような仕掛けを作る機会は…あるのかなぁ…
少し古い記事ですが、良記事なので。
そもそもエアコンは、室外機で室内と屋外の温度差を熱交換して冷やしたり暖めたりするので、そもそも気温差のない状態では熱交換の効率が悪くなるため、冷えにくくなります。
そして「冷えにくいから」と言ってエアコンを強くしたり、長時間運転すると、今度は室外機本体や廃熱フィンなどが温度差によって結露し、これが結氷に繋がりエアコンの効きが悪くなったりします。
この室外機の結露⇒結氷による「効かない」トラブル、冬場は特になりやすく、暖房運転・雨天・高湿・などでも発生します。
でもって対策ですが、正直あまりオススメな手段はないです。
例えば、室外機を大型なものにしたり、業務用にすれば、低能力で稼働するようになるため、これらのトラブルは減少しますが、高額です。
室外機にお湯をかけるのは、結氷を溶かす効果が一時的にありますが、気温・天候次第で今度はかけたお湯が冷めて、そのまま結氷するし、そもそもお湯との温度差が金属の膨張収縮を促すことになり、場合によっては故障や低寿命に繋がります。
結局のところ、窓を開けて外気を直接取り込むのが一番良いと思います。
いわゆる「下げ」進行で。
(さらに…)今回の話題、資本主義というか人間社会であるなら、どこでもある話ではないかと思います。
権力を有する者と技術知見を有する者とのバランスというのは会社組織だけでなく、ちょっとした仲間関係から国家レベル、資本主義・共産主義など、社会ではどこでもある話ではないかと。
自分も技術者・知見者の端くれとして人生を送ってきましたが、様々な会社と話をしてきました。
結局のところ、経営を全面に出すと技術知見を有する人が離れていく傾向が多い気がした。その原因は、技術知見者の意見を尊重したり、関係をはじめとしたバランスを保てなくなることが、ほとんではないかと思う。
とはいえ技術知見者側の性格というか（言葉は悪いが）偏屈な方も多いので、正直お互い様であるような気もする。
とは言え、いずれにせよ所属している会社であれば、個人的には一緒に仕事できるか、できないかという話に行き着くのではないかと。
個人も会社を選ぶ権利はあるので、デメリットはそれなりにあるかもだけど、究極（？）としては、最終的に伸るか反るかの判断は、自分にあるわけで。
翌々考えてみると、ごく当たり前な話ではあるんですが、その「ごく当たり前」を自分自身、見失うことがあるんだよなぁ（感慨）
Becky! でスパムフィルタを実現するためのプラグイン。
公開されてからかなり経過してるのと、フィルタのコアとなる bsfilter を最新（とはいえ、こちらもかなり前）のものを使おうとするとインストールの際に Ruby もインストールする必要があるなど、若干クセがあるので、備忘録がてら記事にした次第。
同じ bsfilter ライブラリを利用したプラグインとして、bkbsfilter なるものも以前あったようだが、こちらはサイトが閉鎖された模様。
おそらく現在で bsfilter を利用した Becky! プラグインの唯一なものではないかと。
インストール手順などは上記プラグイン配布元の解説があるので、そちらを参照の事。
上記サイトとは別に bsfilter、さらに bsfilter の最新版を利用する場合は Ruby もインストールする必要あり。
上記サイトから最新版をダウンロードすればよいかと。
Ruby のインストール手順については、別途ググってインストール。
ただしインストールの際は、Ruby 2系を使用すること、最新バージョンの Ruby 3系は不可。
bsfilter 自体が 2系時代（しかも初期）に作成されたもの。
そして Ruby は2系 ⇒ 3系になった際にサポートされなくなった機能（仕様？ 文法？）があるようで、それらが影響しているのかはわからないが、bsfilter スクリプトが途中でエラー終了してしまう。
これらは Becky! に bkbsfilter プラグイン導入後して動作させると、受信時の動作が明らかにスローダウンするうえ、フィルターに一切引っかからないなど挙動が起こすので容易に分かる。
もしこの挙動が確認されたら、Ruby のバージョンを疑うこと。
ちなみに Ruby 3系と2系を同一マシンにインストールしても問題なさそう。
BkBsfilWrapper 上で使用する Ruby は、プラグインの設定内でプログラムパスを直接指定する設定する。そのため環境変数 Path の影響を受けないように実装されている。
もし開発環境としてRuby 3系を利用している場合は、別ディレクトリに Ruby 2系をインストールすれば同居可能。
（同居については、この記事の主体ではないので省略。2系⇔3系の切替方法や Path の変更方法など色々調べたうえで、自己責任で。）
執筆時点での Ruby 2系のバージョンは最新版の 2.7.5 を利用しているが、今のところ動作に問題はなさそう。
この記事は、今後随時追加・変更・訂正・削除する可能性あり。
また 1.18 の頃の話も含まれている。
そのためこの記事はマイナーバージョンの変化も含めて、一つの記事で流動的な内容を取り扱っているため、他のバージョンとは挙動などが異なる場合あり。
さらに掲載後の時間経過によって、最新版を対象とした記事でなくなる。
これらに十分注意し、記事を参照すること。
Java版（JE版、Java Edition）の記事。
統合版は若干仕様が異なる場合があるので、注意。
この辺の話は、調べればよく聴く話だと思うので割愛。
今までは明るさレベルが７以下がスポーン条件だったが、これが０でないかぎり、つまり光源ブロックからの明かりが少しでも当たっていれば、敵 Mob はスポーンしなくなった。
そのため、今まで湧き潰しが甘い箇所箇所が近くにあったりすると、クリーパーが湧いたりして、いきなり背後で爆発に巻き込まれるとかあったが、このような事態は、かなり減った。
むしろ地上拠点など、湧き潰しされてる空間上での不意な「湧き」がかなり少なくなってしまったので、当初は「アップグレードのバグか？」と思ったぐらい。
すでにブランチマイニングされているエリア（チャンク）は、掘ってなくてもワールド（ブロックの情報）が生成済のため、それが書き換わることはない。
しかしながら、今回追加した Y=0 より下の層や未踏のエリアについては、プレーヤーの移動によって追加生成されるのだが、その際注意しなくてはならないのは、鉱石分布の変更。
特にダイヤモンド鉱石の場合、今までは Y=1～15 に分布していたが、1.18 では Y=16 以下、しかも深くなるにつれ、出やすくなるように変更された。
（ただし溶岩溜まりなどの Y 座標は 1.17.1 と同じなので、深層を掘る際のマグマダイブは従来通り注意が必要だし、横掘りや上掘り時の注意も必要）
それ以外の鉱石についても、一定数の生成頻度とは別に、出やすい高度の傾斜が追加された。
そのためブランチマイニングなどの効率重視の場合、目的の鉱物別に高度を変更する必要があるなど、適宜方針変更する必要が出るくると思う。
1.17.1 において 雨・雷雨がほとんど降らなかったが、1.18 では、割と頻繁に降るようになった。
落雷も 1.17.1 に比べると、かなり頻繁に発生するようになったので、木造の設備や植生などについては、火災対策が重要になると思う。
1.18 からは描画距離の設定や考え方が変更されたようで、単にアップグレードすると、遠くの景色が霞むようになった。
おそらくこれは、ＰＣのスペックによって左右されるのだと思うが、非力な環境だと、この霞み具合がさらに広がった。
（1.18.1 にて改善されました。1.17.1 とほぼ同じ描画距離になったと思います）
普通に吠えて（元気で）も「オオカミが息切れする」と表示される。（字幕のバリエーションがトンでる？）
溶岩や水流などの環境音に指向性が追加された？
以前は 360° どの方向を向いていても、環境音は聞こえていたのだが、1.18 になってから後方の環境音が聞こえなくなった。
また以前は他のブロックの先にある音が、結構数ブロック以上離れた遠い距離からも聞こえていたものが、1.18 ではかなり近くのブロックに来ないと聞こえなくなった気がする。
また「聞こえない＝字幕にも表示されない」ため、調子にノってマイニングしていると、いきなり「溶岩ドバァ」とか溶岩遊泳とか落下の憂き目に遭ってしまう。
プレイヤーの向いてる方角によって聞こえたり、聞こえなくなるような効果が追加された？
地中にある（渓谷や洞窟などの空間がない）溶岩ブロックについて、音が聞こえなくなった？
併せて字幕も表示されなくなった？
マイクラはプレイヤーの移動にあわせて、seed値に沿って動的にワールドが生成されていく。
厳密にはプレイヤーの移動にあわせて、プレイヤーの存在する位置周辺のチャンク（感覚的には遠景でみえる景色の数チャンク先）が生成される。
そして前バージョンで生成されたワールドについては、アプデ以降も基本的には変更されない。
逆に未踏破のエリアは、新バージョンの設定で生成されることになるため、いきなりバイオームが変化するような場所が生じることもある。
また 1.18 では地下も拡張されたため、1.17で生成された地下世界の下に、1.18 で追加された深層地下が広がっている。
【以下、引き続き気づいた点について、随時記事を追加・変更する予定。】
Minecraft Java版も 1.18 になり、Spigot も 1.18 が公開されたので、うちの貧弱環境で動作するのかも含めて、早速アップデートしてみた。
ちなみにシングルで遊ぶのであれば、自分のPC上で「シングルプレイ」で普通に遊ぶのが、あくまで一般的なはず。
最近のゲーミングPCであれば、スペックとかも問題ないはず。
この記事は、Spigot サーバをわざわざ建てて、マルチ環境でシングルプレイするという奇特な人（私）を前提とした内容。
なので、その辺の無粋なツッコミは、なしの方向で。
今まで「さくらのVPS 1Gプラン」で稼働させてましたが、1.18 へのビルド・アップグレードについては、なんとか可能。
しかしながらゲーム中の動作中、以下のような事象が発生していた。
このような状態になっていると、往々にして Spigot サーバーのコンソールに、以下の過負荷警告が繰り返し表示されることがある。
> Can't keep up! Is the server overloaded? Running XXXXXms or YYY ticks behind
【意訳】
もうついていけねぇ！ サーバーが過負荷じゃね？ XXXXX ミリ秒または YYY ティック遅れてる。
（ティック：ゲームの処理単位、マイクラだと1/20秒単位）
つまり現実時間軸に対して、ゲーム内の処理量が多すぎて時間が追いつけていないという状態。
これが積み重なるとゲームは処理落ちを跳ばして無理矢理、時簡短縮をしたり（プレイヤーは見かけ上、コマ落ちやキャラがワープしたように、移動や操作前の状態に巻き戻されたように見える）、ゲームが強制終了してしまう。
ちなみにこの事象、1.18 ほどではないにしろ 1.17.1 でも発生していた。
それでも 1.17.1 の場合、個人的にはシングルプレイで利用するかぎり、まだ耐えられる程度だったが、1.18 では頻発するため、さすがにストレスがキビしい。
いずれにせよ、この現象はメモリ不足や処理の過負荷が原因。
1.18 にはアップグレード（ビルド・インストール）できるものの、プレイは現実的ではないという結論。
そのため、急遽 VPS のプランを 1G ⇒ 2G に変更。
その結果、頻発していた負荷警告は（発生はするものの、1.17.1 の時よりも少ない状態に）収まった。
この状況から、今後のマイクラ JAVA 版は、普通にゲームするだけでも、少なくとも2G以上のプランが必須となってきそう。
ちなみに Spigot の動作スペックを少し調べてみたが、どうやら最近は 2GB 以上のメモリを最小としている模様。
もしかしたらメモリ 1G での挙動させる猛者はいるのかも知れないが、普通に Spigot をセットアップしてあくまで標準的に利用する場合、メモリ 1G での動作は無理だと思う。
あと以前の記事にも記載した通り、自分が利用しているサーバは契約自体が年間契約のものを流用した関係と、AWSなどを再契約した場合、またイチからサーバを構築しなくてはならない。
そのため今回は緊急避難的にスケールアップで対応し、契約満了までは利用することにした。
しかしながら 1G⇒2G へのプラン変更は、概ねどこの VPS サービスもそうなのだが、利用料金がほぼ倍になってしまう。正直なところ、お値打ち感はない。
なので個人的には契約満了後、AWS（EC2）に切り替え、かつ弾力的にインスタンスの開始/終了ができるようなシステムを構築する方向で、費用圧縮を考えている。
そして本題です。
まずビルド・実行にあたり、Minecraft 1.18 は java 17 のバージョンが必須となる。
そのため、まずは java のバージョンを 16 ⇒ 17にアップグレードする必要がある。
でも、何はともあれ、まずはバックアップから。
# sudo su # cd /opt # cp -a spigot spigot.1.17.1 # exit
自分の場合、spigotを導入している /out/spigot ディレクトリ配下を、権限そのままで、ごっそりコピー。
ちなみに apt コマンド等は Ubuntu 20.x.x の場合。
CentOS や Windows など、各自のOS環境や権限、ディレクトリ構成などによって、手順やコマンドや手順は異なる。
そのあたり、各自で適宜調べて実施する必要あり。
次にパッケージインデックスを更新。
$ sudo apt update
ついでに、他のアップグレードがある場合、必要に応じて更新。
$ sudo apt upgrade
自分の場合、最も環境変化の影響の少ないアップグレードをしている。（余計な機能は追加しない。）
本題に戻り、OpenJDK 17 をインストール。
$ sudo apt install java-17-openjdk
最後に Java 17 になったか、バージョン確認。
$ java -version
これでjava 17.x.x がバージョン表示されればOK。
次に ビルドツールを最新化。
$ cd spigot $ rm BuildTools.jar $ wget https://hub.spigotmc.org/jenkins/job/BuildTools/lastSuccessfulBuild/artifact/target/BuildTools.jar
このビルドツール、頻繁に更新されていて、古い BuildTools.jar だと最新版のビルドができない場合が多い。
なので BuildTools.jar は、常に最新版を使う。
必ず Spigot 公式が提供している jar ファイルをダウンロードして使用すること。
BuildTools.jar をググったりして探すと、野良サーバの jar ファイルがヒットすることがある。これがセキュリティ上とても危険。
必ず公式サイトからダウンロードしているか、URLを確認すること。
そしてビルド。
$ java -jar BuildTools.jar --rev 1.18
これによって、Spigot 1.18（Spigot-1.18.jar）がビルドされる。
次に、既存のワールドデータや設定ファイルなどを、1.17.1 ⇒ 1.18 にアップグレードしつつ、spigot サーバを一旦起動。
$ java -jar spigot-1.18.jar --nogui --forceUpgrade
このタイミングで、現時点でのワールドデータやプレイヤーのデータがすべて書き換わる。
ちなみにこのアップグレード作業、ワールドの広さによって、かなり時間がかかる。
もしかしたら半日以上とか、かかるかも。
自分の場合、まだ数百座標単位しか展開していない。
しかしそれでも 15 分ぐらいかかった。
だからといって、上記コマンドを入力したら、絶対に途中で止めず、辛抱強く待つこと。
途中で止めると、ワールドデータが破損する可能性があり、その場合、二度と起動できなくなる可能性すらある。
バージョンによっては、上記アップグレードコマンドにて操作終了後、何もしていないのにメモリ不足などの例外エラーで終了したり、コマンドの入力挙動がモッサりして不安定になることがある。
自分の環境では、1.18.1 アップグレードの際に発生した。
ただ今のところアップグレード時のみ生じている問題で、OSごと再起動し Spigot を通常起動させた状態では安定。
少しゲームプレイしたかぎり、問題も起きていない。むしろ動作が軽くなった気がする。現状様子見。
無事に起動が確認できたら、一旦停止。
> stop
Spigot を終了させる。
そして最後に –forceUpgrade オプションなしの状態で Spigot を再起動。
これで問題なく起動し、ゲームにログインインして普通に操作できれば、アップグレードは無事終了。
以上アップグレードの作業そのものは、特段難しくはない。
しかしながらアップグレード前に、サーバースペックの問題を確認・解決する必要がある。
この記事は、今後更新される可能性があります。
サーバのインストール手順については、ググると先達の Web 記事がいくつかヒットするので、ここでは解説していない。
あくまでプラン選択の経緯を記事にしてみた。
また、利用したマイクラサーバは Vanilla（バニラ）ではなく、今後の利用を考えて、Spigot を選択。
以前は512MBなど、低スペックなVPCサーバでも利用できたようなので、元々所有していたサーバ契約を流用して、インストールを試みてみた。
コンパイル時にもメモリ不足のエラーが表示されたが、無理矢理ビルドすることは可能。
しかしながら、サーバ実行（起動）の過程でメモリ不足となり、立ち上がらなかった。
こちらのプランだと、サーバも起動できる。
ところがプレイ中、ボートやトロッコなどで高速移動すると、処理落ち（移動が巻き戻ったり、切断、例外発生によるサーバーエラー終了など）が頻発。
原因がメモリ制御なのか、処理速度（CPU）の問題なのかは不明だが、いずれにせよ、メモリ１Ｇであっても、新規ワールド（空間）への立ち入りや複数人でサーバに接続すると、かなり不安定になるのではと思う。
現状、拠点でブランチマイニングや、精々近所の村や洞窟探索を中心にプレイしてるので、何とか動作している。
しかしながら飽き足らなくなれば遠征することになると思う。
おそらくそれは、時間の問題かと。
おそらくクラウドサービスを利用してマイクラサーバを立ち上げる場合、CPU やハードディスク容量については、一定以上のプランを利用すれば、ほぼクリアできることが判明した。
しかしながら Java を利用しているため、初期のモジュールビルドにも、マイクラサーバの実行にも、とにかくメモリを喰う。
おそらく２Ｇ以上のサービスを利用するのが安泰だと思うが、そうすると今度は、費用面が問題になると思う。
例えば、さくらインターネットの場合だと、プランを１Ｇ⇒２Ｇにすると、基本料金がほぼ倍になる。
ざっくりだが、年額でおよそ１万⇒２万の差。
いくつか他の VPC 事業者もみたが、ほぼ同じ傾向。
ちなみに仕事用を中心に、オンプレサーバをクラウドに移行したので、玉突きで空いたオンプレサーバをマイクラサーバにしようかとも思った。
しかしながら、オンプレサーバのディスクをSSDに換装したり、電気代などの維持費を考えると、先のクラウド移行した理由が破綻してしまう。
なので今のところは、AWS（EC2）などのインスタンスの自由度が高いクラウドにマイクラサーバを移行することを検討中。
ただし、正直なところ AWS のようなクラウドサービスは、一般的な VPC サービスに比べて、設定や操作が煩雑なのと、費用面のコストが見えにくいので、かなり躊躇している。
しかしながらインスタンス（CPU やメモリのスペック）切替が容易なところは正直魅力的だし、バッチを頑張って作れば、未使用時にはサービス停止して、費用節約も不可能ではない。
でもまぁ、さくらインターネットのVPC契約を１年契約にしてしまったため、とりあえず、解約時期までにEC2環境を整備しておこうかと考えているところ。
