Mastodonインスタンスを閉鎖するときの手順（妄想）

はじめに

この手順は検証されていません。なので、誤りが指摘しやすいようにできるだけ裏の考え方も記載していきます。個人がやるような、それほど大きくないインスタンスを前提に考えてみました。

閉鎖しようと思ったとき

まず、本当に閉鎖するのかどうかを考えましょう。

頭に血が登ったり、心が折れたりした状態であれば、発表は 2 日くらい待ちましょう。

勢いでインスタンスを閉鎖してもあまり良いことはありません。

閉鎖 or 移譲？

インスタンスの運営は、サーバーごと譲り渡すか、DB、.env ファイル、メディア、ドメイン等を譲渡することで移譲できます。が、移譲する相手が気に入らないユーザーもいる可能性があるので、

移行期間を設けて、移行期間はアカウント削除を可能にした上で移譲等、きめ細かい対応をする必要があるかもしれません。

(mstdn.jp は何度か移譲されているので参考になるかもしれません）

正直、運営者が変わるのであれば新しいインスタンスを別ドメインで立ててしまって、エクスポート／インポート＋引っ越しを呼びかけた方が楽だと思います。

手順

閉鎖を決めたとき

閉鎖をアナウンスします。移転先がある場合（後継インスタンスがある場合）はそちらもアナウンスします。ここから、エクスポートが実行されまくるため DB、Sidekiq の負荷が上がるはずです。

規模によりますが 1 週間から長くても 2 週間くらい取れば OK だと思います。

あまり長くとってもお通夜モードが続いてしまうので。ただし、LTL メインで運用されているインスタンスの場合、エクスポート等はギリギリまで実行されない可能性が高いです。（エクスポートして他インスタンスに移ると LTL が見えなくなるため）

閉鎖日まで

エクスポートはお早めに！というアナウンスを続けます。そして閉鎖への準備を行います。

閉鎖のとき

Web へのアクセス停止

とりあえず、フロントのリバースプロキシ（nginx/apache）の設定を変更して、メディア以外へのアクセスに対して 410 Gone を返すように変更します。

この時点では、DB、Sidekiq、メディア、メールサーバー等は停止しません。

これらはまだ後続の処理で必要だからです。

閉鎖後のエクスポートの依頼

断っても良いですが、 tootctl account backup [accountname] を実行することで

管理者側から実行することもできます。出力完了後にメールが飛ぶのでそこからダウンロードが可能です。メール内にバックアップzipへのURLが記述されているのでそこからダウンロード可能。メディア(S3)サーバーが生きていればOKなのでこれで対応可能です。

閉鎖日以降

当日にやる必要はありません。翌日以降で十分です。

エクスポートジョブがないことを確認

閉鎖直前にエクスポートを実行したユーザーのエクスポートが完了していない可能性があるためです。エクスポートの実行には DB、Sidekiq が必要です。エクスポートされた圧縮ファイルの保存と配布にはメディアサーバーが必要です。

（S3 を使わない設定の場合は、nginx でメディアへのアクセスだけは通すようにする必要があります。

エクスポートが完了したタイミングでユーザーにはメールが送信されるのでメールサーバーも停止できません。

エクスポートの実行状況は、DB の backups テーブルを参照するとわかります。

select * from backups where processed <> 't'; を実行して 1 行でも帰ってきた場合は、まだ完了していないエクスポートがあります。完了するまで待ちましょう。

また、完了後もそのユーザーがエクスポートしたファイルをダウンロードする時間が必要なことを忘れないでください。

…といっても閉鎖までに間に合わなかったら諦めて。というポリシーもアリだとは思います。

自爆コマンドを投入する

tootctl self-destruct を Web サーバーで実行します。

おそらく、時間のかかる処理になると思われます。完了まで首を長くして待ちます。

（help に always interactive and requires confirmation twice と書かれているので、相当な確認があると思われます。）

とはいえ、410 Gone を返している時点でそのインスタンスは無くなったものとして扱われはじめるので、実行するしかありません。

使っている FQDN で再度 Fediverse に参加できるかどうかも怪しいです。

（サブドメイン違い等、いくらでも手はありますが。）

※ self-destruct していれば可能なはずだけれども、たまたま self-destruct 時にダウンしていたインスタンスがあった場合、同じ FQDN で何かのインスタンスを立てた場合問題が起きるでしょう

自爆後

• 1~2 週間は 410 Gone を返し続けるようにします。nginx/apache のサーバー以外は停止できます。
• DB のダンプはしばらくの間持っておいた方が良いかもしれません。（問い合わせ対応）
• ドメインに関しては不要になったとしてもある程度の期間は寝かせたほうが良いです。（同じドメインでアダルトサイトが出来てしまうと悲しいので）

蛇足

某インスタンスの閉鎖に伴って色々と調べたのでその結果を出力しただけという説がある。

なにより検証していないので多分これで良いんじゃないか。というレベルだと思ってください。

self-destruct するのであれば 410 Gone を返す期間は短くてもよさそうな気がするし、このあたりはやってみないと色々とわからないことが多い気がする。

お引越しの告知とかを考えると、閉鎖を決めたあと一旦停止してその間に管理者以外のアカウントのログインを止めた状態でしばらく動かしたほうが良いような気もするし（ログインできちゃうと閉鎖ってなんなの？ってなっちゃうので）、閉鎖に関してはこれと行ったお作法がまだ確立してないし、確立することも無いのではないかなぁという感想。