大型メンテにあたって思ったこと

今度の土曜日（6月27日）に実施する大型メンテナンスを実施する理由を書いてみたくて久しぶりにnoteにログインしました。お時間ある方はご笑覧いただけると嬉しいです。

mstdn.beerは、その起ち上げ以来ずっと、さくらインターネットの提供するさくらのクラウドで運用してきました。

サーバースペックは紆余曲折してきましたが、2020年6月23日現在は以下の通りです。

仮想コア 4コア、メモリ8GB、ストレージ100GB

ときどき500エラーを吐いたりちょっと重くなったりしますが（個人の感想です）満足できるスペックです。

さくらインターネットがMastodonスタートアップスクリプトを提供してくれていなければ、自分でサーバーを借りてMastodonを起ち上げることなど到底できなかったに違いないと思います。そういう意味では、さくらインターネットは、わたしにサーバー管理やWEBサービス運営の楽しさを教えてくれた大恩人であり、感謝しても仕切れません。多くのことを学ばせていただきました。

ただし、このまま使い続けるにはいくつかの問題があり、実は1年以上前からさくらインターネット以外のサービスに移行しようと考えていました。

1．スタートアップスクリプトで扱うOSがMastodon公式と異なる

Mastodonの推奨OSは、現在Ubuntu18.04ですが、スタートアップスクリプトで起ち上げたMastodonはCentOS（2017年当時のバージョンは6）上にインストールされます。これは、サーバー管理に習熟している鯖缶さんにとってはなんの問題も無いのかもしれませんが、ほとんどLinuxに触ったことのないわたしのような者にはなかなか厳しく、多くの壁にぶち当たっては様々な方の助けを借りてなんとかここまで来られたというのは正直な感想です。やはり、思わぬトラブルを避ける意味でもOSをCentOSからUbuntuに移行したいというのが一つ目の動機です。

2．ストレージ容量の逼迫

本日現在のストレージ使用状況は以下の通りですが、かなり逼迫してきています。少し前に95％くらいまで行ってしまったのですが、ごにょごにょしてなんとか減らすことができました。

$ df -lh
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G  404K  3.9G   1% /dev/shm
tmpfs           3.9G  390M  3.6G  10% /run
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/vda3        95G   80G  9.9G  89% /
tmpfs           799M     0  799M   0% /run/user/1001

むろん、さくらのクラウドでもサーバー容量を増やすことはできますが、100GBの次は250GBと大盤振る舞いプランになっています。いきなりそんな大きいの入らないよぉ…///というやつです。

3．コスト面

三番目に書きますが、実はこれが一番大きな要因です。サーバー維持の費用はこれまで一切明かすことはありませんでした、自分のおこづかいの範囲ででき、楽しくてやっていることなので現状のコスト感ならなんの問題も無いのですが、利用している方によけいな心配（？）をしていただきたくなかったというのがあります。そのスタンスはこれからも変わらないのですが、サーバー移行を経てようやく「ひとさまにお見せできるコスト感になる」と思えることから、もうこの際ぜんぶぶちまけてしまおうなんて思った次第です。

また、「なぜ何時間もサーバーを止めてまでメンテナンスをするのか、そんなに苦労してまで」を理解していただく上で必要だろうとも考えてのことです。

現在のさくらのクラウドと移行先であるLinodeとを比較してみます（全て月額）。

さくらのクラウド：

サーバー利用｜4コア 8GB ｰ 9,680円　ストレージ利用｜100GB ｰ 3,850円

Linode：

サーバー・ストレージ利用｜4コア 8GB 160GBストレージ ｰ 40ドル

おなじ4コア 8GBでありつつ、ストレージ容量が1.6倍に増えてお値段半分以下っていうのは、やっぱり魅力です。

今後、長く続けていきたいと考えたとき、やはりコストはかからない方がよく、Linodeの場合、仮にスペックをひとつあげて6コア 16GBメモリ 320BGストレージとしても月額80ドルという破格のお値段ですので、これですと向こう3年～5年程度はなんとでもなるかなと思います。

以上が、壊してしまうかも知れないリスクと長時間のダウンタイムを伴うメンテナンスを実施したいと考える理由です。利用者の皆様にはご迷惑をおかけいたしますが、ご理解いただけると幸いです。