タイトルの通りで、 mstdn.maud.io のサーバーを立て直して移設しました。
式年遷宮とは？
遷宮（せんぐう）とは、神社の本殿の造営または修理の際に、神体を従前とは異なる本殿に移すことである。
定期的な遷宮を式年遷宮（しきねんせんぐう）と言う。「式年」とは「定められた年」の意。
という感じで、サーバーの移設をそのように呼んでいます。
たぶん今後も遅くても4年を目処にやることになりそうなので、実質遷宮じゃん、ということでそう呼んでいます。1回目なのに式年とは…とか言わない。
前回こんなことを言っていたら本当に4年が経とうとしてしまい、式年だったかもしれん。
:don: が抱えるサーバー構成の闇２
バージョン
前回の式年遷宮でデーターベース・サーバーを分離して負荷分散に成功し、GitHub Actionsの導入で更にスリムな実行環境を手に入れた :don: でしたが、年月の経過には抗えませんでした。 Mastodon v4.4 における PostgreSQL 12 のサポート終了です。
“There is no immediate reason for us to drop PostgreSQL 12, but PostgreSQL 12 is already End-of-Life and we do not want to be stuck with old releases for the lifetime of Mastodon 4.4.”
コメントでは積極的ではないように見えても、しっかり 13 未満のバージョン相手では migration が中止されるように変更されていたので、更新は必須になってしまいました。
更に、よく考えたらWebサーバーも Ubuntu 20.04 だったのでこの際 24.04 に乗り換えることに。これで結局前回と同じ規模が確定しました。いや古すぎる。
ネットワーク構成の大ポカ
そうしてデータベース・サーバーの入れ替えが必要になったわけですが、同様の構成で稼働しているテスト環境で工程を見積もろうとしていたときにそれは明らかになりました。
「なんか外部からログイン試行されてね？」
a やら postgres やら versionprobe やら、不穏なログイン試行が記録されていますね。
ところでさくらのクラウドのデータベースアプライアンス、ログの postgresql タブが居たり居なかったりするのどうにかなりませんか？
そう、旧データベース・サーバーはインターネットに接続された ルータ+スイッチ 配下で公開状態にあり、外部からのアクセス制限も不十分な状態にありました（これはテスト環境だけでなく、本番環境も同様です）。幸いにもユーザー名やバカ長いパスワードを当てられたことはなく、これまでにデータの侵害は確認されていません。
構成見直し
そこで、インターネットには接続しないスイッチを用意し、データベース・サーバーをこちらに繋げておくことにしました。Webサーバーにはもう一つNIC(eth1)を追加して、DB向けの通信だけそちらに出ていくようにします。最終的に下の図のようになればOKです。
式年遷宮（本番）
移行作業
まずはサービスを落として、WebサーバーのAレコードを新鯖のほうに更新します。
新鯖で証明書を取り直して、メンテナンスページを返すようにしておきます。
予告で触れていたように、新鯖に繋がっていることがわかるような記載をこのページに書くつもりでしたが、できていませんでした（一敗）。なんならnginx絡みでトラブってエラーページ自体が出せていない時間帯がありました（二敗）。
前回同様にDBのダンプを取ります。
Webサーバーはストレージをケチってしまった上、あんまりパッケージ管理がごちゃつくのも本望ではないため、ストレージを盛った作業用マシンを別途用意します。ダンプは30分弱で終わりました。
ダンプを流し込みます。これがめちゃんこ長かった。
長すぎ！
できたので前回同様にアクセス制限を自宅に絞って動作確認、動いてそうだったので一旦稼働開始したのが16時半ごろのことでした。
ネットワーク構成の大ポカ２
さて、これで postgres はインターネットから隔離されたスイッチに接続しており、これで安心だと思っていました。
しかしいざ稼働してみると、他サーバーからの投稿は受け取っているものの、こちらの投稿が他のサーバーに届いていないことが判明しました。サムネイルの生成や、画像の Amazon S3 へのアップロードも必ず失敗します。このとき、:don: に何が起きていたのでしょうか？
そう、外向きの通信がすべてインターネットに接続していない eth1 を向いていたのです。
外部からのアクセスは eth0 が受けており、nginxは自分の仕事をし、ユーザーはWebUIにアクセスすることができ、リモートの投稿は続々と /inbox に集まっていました。アクセスできているユーザーからは一見正常な動作に見えていたのはそういうことですね。
原因は単純で、 eth1 にもデフォルトゲートウェイの設定を書いていたために外向きの通信がすべてこちらに流れてしまっていました。
Ubuntu では netplan を用いてネットワークを設定しますが、このときの設定ファイルは以下のようになっていました。
network: |
ここを消して sudo netplan try した瞬間に外部サーバーに投稿が流れ始めて頭を抱えました。
ここに気づくまでにいろいろ遠回りをしてしまい、その遠回りな対処の数々とこれを全部消してようやく正常に動き始めたので、完全な復旧までに時間を要することとなりました。徒労。
これはその対処と根本原因を全部消したら動き出して「ほんとか？？？？そんなんでよかったんか？？？」って言いながら様子見てた期間のことです。
さいごに
今も昔も自分がネットワーク苦手すぎるのを再認識したので、これを期にちゃんと勉強し直したい気持ちがあります。いい感じの入門書があれば @hota@mstdn.maud.io におすすめしてください。