ノリと勢いだけでぜんぶやりました。
経緯
2023年のはじめにMisskeyのサーバーを建て、そこから1ヶ月余りが経った頃...。Misskeyのバージョンアップや連合先からの流入負荷増大についていけず、サーバーが重くなりつつあった。
Misskeyサーバーは、さくらの安いVPS（2x vCPU, 1GB RAM, 50GB SSD）上でバックエンドを動かし、Cloudflare経由で配信するという構成だった。メモリもCPUも恒常的に不足し、もっさりと重く、普段遣いしていてイライラするのが日常だった。しまいにはサーバーを建てた私自身でさえ、重さに嫌気が差してアクセスしなくなる始末。ところが奇跡的に、これ以上重くなることも動作が止まることもなく、首の皮一枚でトロトロと動き続けていた。構築から8ヶ月もの間、ズボラな維持管理とは裏腹に安定運用が継続できた。
VPSのスケールアップができれば良かったのだが、少ない私のポケットマネーでは、これ以上つよいサーバーを契約することは難しかった。
一方、手元には、古いビジネスデスクトップを改造したNAS兼開発サーバーが転がっていた。もともと、私がLinuxを勉強するために、Ubuntu Desktopを入れて使っていたマシン。4コア4スレッド、RAM4GB、256GBのSSDに2TBのHDD。スペックは十分にもかかわらず、今では十分に活用できておらず「役不足」であった。
「手元のマシンでMisskeyが動かせたら楽しいだろうなぁ」なんて考えていたら、手が勝手に動いて、気づけばサーバーの引っ越しまで終わっていた。
急遽決まったDebianへの乗り換え
自宅サーバーでは、Linuxの勉強を始めたての頃に入れたUbuntuが今も動いていた。サーバー化したときにデスクトップ環境を一掃したり、Ubuntu 22.10が出たときにdist-upgradeを走らせたりしたので、パッケージがもうごちゃごちゃのぐちゃぐちゃ。よほど整理して不要なパッケージを削除しても、まだ2000パッケージくらいが残っていた。
本番環境としてサーバーを動かすなら、無駄なリソースを浪費しないためにも、余計な穴を開けないためにも不要なパッケージは削除したい。
そんなことを考えながらちまちまパッケージを消していた7/15の夜、再起動後いつまでたってもSSHにつながらなくなる事件が突然発生。やってもうた。
手持ちのディスプレイをつなぐと、カーネルは立ち上がるもネットワーク接続周りがダメそう。しかも、パスワード認証で弾かれてターミナルにログインできない...。
もう、こうなったら一層のことOSを入れ替えたほうが早い。
当時、必要なデータのほとんどは、OSとは別ストレージのHDDに入れていた。必要なデータの救出などを気にすることなく、OSの入っていたストレージをまるごと潰して新しいOSをクリーンインストールしても支障がなかった。
サーバーに使うOSにはDebianを選んだ。Linuxにはもうかなり慣れているので、リッチなサードパーティソフトウェアも不要だったし、OSの公式リポジトリでインストールできないソフトウェアも自分でリポジトリを探してインストールできる。OSのコンパクトさ、ミニマムさを優先したかったのと、Ubuntu以外にまともに使用経験のあるディストリビューションが少なかった。慣れているDebian系ディストリビューションの中で、サポートがある程度期待できて、コンパクトなディストリビューションとして浮かんだのが、Debianだった。
突貫でDebianをインストール&キッティング
7/18夜、Debianをインストール開始。ウィザードにしたがってサクサク進めていくだけで、特にハマりどころはなかった。当然GUI環境は無し、SSHサーバー以外はすべてプリインストールのチェックも外した。インストール開始から1時間くらいで、LAN内の端末からSSHできるように。
Ubuntuとの違いは随所に感じたけど、初期設定だとsudoが入っていない点にビックリ。suコマンドでrootになって、各種必要パッケージと共々、sudoもインストール。その後、sudoerファイルに自分のユーザー名を追加。これでsudoできるようになる。
それから、netplanもインストールして、LAN設定をいい感じに書いたり、ufwをインストールして簡単に設定を書いたり。もちろん、SSHできるようになった後は、公開鍵を登録してパスワード認証を禁止した。
どうでも良いけど、ホスト名には太陽や空にちなんだ名前をつける癖がある。 solarium 〈英: ソーラリウム・ソウレリアム〉は日差しがよく入るように全面をガラス張りにした部屋のことらしい。
事前検証期間
Misskeyサーバーの引っ越しにあたって、どういう構成を組むべきか、ゆっくり考えた。
自宅のルーターのポートを開けずに、Cloudflare TunnelでCDNと接続するのはほぼ確定。それ以外の構成をどうするか悩んでいた。
VPSで動かしていた頃はMisskeyサーバーとCloudflareとの間にnginxが挟まっていて、リバースプロキシとして動いていた。今回もnginxを採用しても良かったのだが、Cloudflare Tunnelを使うとリバースプロキシが不要になる。nginxは採用せず、CDNからMisskeyサーバーまで直接アクセスするという構成になった。
自宅サーバー上でMisskeyが動作するのかも検証。案の定、一発では動かなかった。原因はホスト上にNode.jsが入っていなかったこと。aptでNode.js v20系をインストールして、Misskeyが正常に起動して、データベースとも接続されることを確認。
ここまでで事前検証はほぼ終わり。真面目にやるならステージング環境とか作って、Cloudflare側の設定もちゃんと投入して、本番環境を模してエンドツーエンドでMisskeyにアクセスできることを確認すべきだと思うけど、一人で使っているサーバーなのでそこはパス。
いざ引っ越し
引っ越す前に、移行のための手順書を用意。手順書を書きながら、引っかかりそうなところがないか探したけど、Cloudflare側の設定で躓きそうだなぁ、という以外は特になし。
手順としては、
1. サーバー停止、mi.hk-shuttle.net. のDNSレコードを削除
2. データベースのダンプ
3. メディアファイルのダンプ
4. 旧サーバーから新サーバーにファイル転送
5. ダンプしたメディアを新サーバーに展開
6. ダンプしたSQLを新サーバーに投入
8. docker compose up -d
9. Cloudflare側の設定を更新
10. アクセスでき次第完了！
というのがざっくりした流れ。失敗したら切り戻してVPSでまたMisskeyを立ち上げるつもりだった。
7/23 0:30にMisskeyを止めてから、新サーバーでMisskeyが動いたのが35分後。朝までかかる覚悟だったけど、かなり短いダウンタイムで済んで自分でもびっくり。
引っ越し後はとても軽くなり、大手サーバーに引けを取らないくらいレスポンスが改善していて素晴らしい...！自分の手元のマシンで、毎日使うWebサービスが動いているというのもとても楽しい。
これが実際のサーバーマシン。リビングのルーター横に設置されている。家族が寝転がったり、飼いねこがほっつき歩いている場所に設置しているので、電源ボタンは押しても反応しないように対策済み。
今後の見通し
サーバーの引越し後、データベースの定期バックアップなどいくつかのメンテナンスを実施した。サーバーを止めて行うメンテナンスも済ませた。大きなメンテナンスはこのくらいかな。
今後は監視周りを強化したい。Zabbixの導入をゆるーく構想中。
