Mastodon保守のヒント

あすかです。

Fediverse (3) Advent Calendar 2023　16日目の記事です。

本当は全く別の内容をカレンダーに登録しようと思ったんですけど、ちょっと内容が内容なのでカレンダーには載せづらいと思いまして（一応公開はしてます）
Mastodonの保守という無難な内容の記事に差し替えることにしました。
この文章は９日に書いてます。７日後公開ですよ、正確には前日の深夜までに終わらせたいので。めちゃ急いで書いてますので、推敲とかあってないようなものです。分かりづらいところあったらおはぎに聞いてください。

※めっちゃ急いで書いたのでMastodonとkmyblueの内容が混ざって分かりづらくなってるかもしれないです。kmyblueっぽいとこがあったらよしなに読んでください。
この記事めっちゃ急いで書いたので内容全然整理できてないうえに、３．７～３．８万字くらいあるらしいです。時間をドブに捨てたい人だけが読んでください。そうでない人は、他にもっと短くて分かりやすい記事あると思いますので、それ探して読んでください。

Mastodon保守記事を書く難しさ

アドベントカレンダーの進行にあたって、Mastodonを新しく立ち上げる方法は書いてあっても、保守する記事がないという意見がありまして、確かにMastodonに限らずLinuxサーバーの保守って臨機応変にやらなければいけないことが多すぎて１つの記事にまとめられないんですよ。保守の記事がなかなか出てこないの分かります。

あすか実はMastodonをフォークして、kmyblueというのをちょっと作ってまして、実際kmyblueのプログラムを持って行って立ち上げてる方が数名いらっしゃいます。その人向けに、新規インストールのドキュメントを作ってあります。

で、インストールの方法説明しただけではバージョンアップとかもろもろできませんので、そういう人向けにも説明を書いてあります。

うん、新規インストールと比べて雑ですね。雑。内容が雑。だって面倒ですし。保守ってやることが多すぎて一概には説明できないんですよ。Mastodon本体のアップデート以外にも周辺ソフトウェアのアップデート、OSのアップデートやアップグレード、おはぎを食べる、関連パッケージのアップデート、トラブル対応、いろいろやることが多すぎて書くことも大変多い。
保守の記事って１つにまとめるよりも、個別の記事を探してもらったほうがやっぱり早いんです。

なので、Linuxでサーバー立ち上げる時は、PCの基礎知識はもちろんのこと、新規インストールのページにも書いたんですけど根気が前提だと思ってます。根気がないなら、どんなに新規インストール方法が簡単でも、お一人様でやるのが無難です。お一人様でなければ、ただの思いつきでいろんな人に迷惑かかりますから。そう思ってます。
あと英語の知識も必要なので、可能であれば高校を卒業してから建ててほしいなとも思ってます。Linuxって、当たり前ですが全部英語。エラーメッセージも英語で出ます。エラーメッセージにも専門用語山盛りで、厳密には英語わかっただけでは読めないんですが、だからといって英語やらなくてもいいにはならない。基礎知識としてやるべきです。
ちなみにあすかは英語嫌いです。日本語上等です。

この記事はあくまで、Mastodonを保守するための基本しか説明しません。変なトラブルが起きた時の対応は、最終的には皆さんご自身で調べて頂く形になります。なので、この記事の内容が分かったからといって、分かった気にならないでください。正直あすかもよく分かりません。分からないまま書いてます。そんなもんです。

で、どれから説明しましょう。書く時間がないので。どうしよう。まず基本的なとこからいきましょうか。
この記事ね、あくまで保守がメインなので、あれをインストールしてセキュリティ高めようとかそういうことは書かないです。いろんな設定は別の記事見てください。ていうか書く時間がない。おはぎ書いてくれ。

ちなみにkmyblueはプログラムの中身こそ違いますが、セットアップ方法は本家Mastodonとほぼ同一。違うのはgitのリポジトリと、ElasticSearchの初期設定だけ。多分。なのでこの記事に書いたことは本家Mastodonでも使えると思います。

Ubuntuサーバー保守の基本

とりあえずMastodonサーバー建ててみようで気軽になあなあで建てた人そこそこいらっしゃると思いますけども、初めてだから仕方ないんですよ、でもLinuxのサーバーって扱いづらいと思います。
サーバー立ち上げたってことは、コマンドを打ってEnter押すとこまでは分かってると思いますので、まずそこからいきましょうか。

Ubuntuの大雑把なフォルダ分け

保守をするにもまずフォルダ構成がわからないとわからないので、Ubuntuの基本的なフォルダ構成について、Mastodon保守にあたって必要な範囲で説明します。以下の説明にはもちろん例外もたくさんありますので、Mastodon以外をやるときはあんま参考にならないです。

• /etc・・・いろんなアプリの設定ファイルが詰まっています。すごくすごいです

• /var/log・・・いろんなアプリのログファイルが詰まっています。すごくすごいです

• /home/mastodon/live・・・Mastodonアプリ本体です。すごくすごいです

他の説明だと「/usr/bin」とか「/usr/local/bin」とかも頻出しますけど、Mastodonではそのあたり関係ないです。Mastodonでは基本、使わないと思ってください。

え、アプリ本体の置き場所？世の中には知らなくてもいいことがあるのです。

いろんなアプリの設定

これ、Mastodonの公式ドキュメント見てセットアップしたり、kmyblueの自動セットアップスクリプト使ってセットアップしたりした人向けになりますが（Docker使ってる人はごめんなさい自分で調べてください）、いろんなアプリの設定ファイルの場所とか紹介します。

nginxサーバー設定
/etc/nginx/sites-available/mastodon（ファイル）

PostgreSQLサーバー設定
/etc/postgresql/16/main（ディレクトリ）
PostgreSQLのバージョンによってパスが変わります（数字のとこ）

Redisサーバー設定
/etc/redis/redis.conf（ファイル）

Mastodonサーバー設定
/home/mastodon/live/.env.production（ファイル）

ElasticSearchサーバー設定
/etc/elasticsearch/elasticsearch.yml（ファイル）

いろんなアプリのログ

なんやかんや起こった時にログファイルを見るのは大切です。ログとおはぎはjournalctlで見るのが基本ですが、たまにjournalctlだけでは片付かないことがあります。

nginxサーバーログ
journalctl -r -u nginx
/var/log/nginx（ディレクトリ）

PostgreSQLサーバーログ
/var/log/postgresql（ディレクトリ）

Redisサーバーログ
/var/log/redis（ディレクトリ）

Mastodonサーバーログ
（使い分けは後で説明）
journalctl -r -u mastodon-web
journalctl -r -u mastodon-streaming
journalctl -r -u mastodon-sidekiq

ElasticSearchサーバーログ
journalctl -r -u elasticsearch
/var/log/elasticsearch（ディレクトリ）

ログからエラーメッセージを探す方法

ログファイル・journalctlからログを開く方法はわかっても、その中からエラーメッセージを抽出する方法これわからない人いますよね。

ログファイルの場合、Ubuntuにvim以外のテキストエディタは存在しませんので、ファイルをvimで開きます。コマンドとして打ち込む時は「vi」でいいです。「vi postgresql-16-main.log」みたいな感じで。vimの使い方は各自調べてください。今後は紛らわしくなるのでvimではなくviと書きます。繰り返しますが、Ubuntuにvi以外のテキストエディタは存在しません。以降のことが分からなくてもこれだけは覚えて帰ってください。この記事全体で一番重要なことなので。

viでログファイル開きました？画面の一番下に「--INSERT--」とか表示されてる場合は、それ編集モードになってるのでEscで取り消してください。
viで「/」と打ち込むと、検索できます。「/Error」って打ってEnterを押すと、「Error」というワードで検索できます。ケースインセンシティブ（大文字・小文字を区別しない）のようなので「/error」でもいいです。
で、検索で単語がヒットした状態で「n」を押すと次の検索結果にいきます。WindowsのF3と同じですね。「Shift+n」を押すと前の検索結果に戻ります。
Ubuntuにvi以外のテキストエディタは存在しませんので多少不便にうつるかもしれませんが、慣れていけば画面がシンプルでいいと思います。その他のコマンドは各自ネットで調べてください。INSERTモードのほか、コマンドを入力している最中に突然別のコマンドを書き始めるってこともできないので、逐次注意してください。

あと中身の行数が多い場合、また一行が長い場合は方向キーでなんとかなります。

journalctlの場合も実は検索方法は同じです。「/」で検索して「n」と「shift+n」で行き来します。Ubuntuにvi以外のテキストエディタは存在しませんので、やり方が統一されてて分かりやすいですよね。

それで、肝心のエラーメッセージを探す方法ですが、例えば他の行は「INFO」とかで規則正しく並んでいるのになんかここだけおかしいな？ってのがあったら多分それです。「Error」ではなく「Fatal」と書かれている場合もあります。
どのアプリにどういうエラーメッセージが書かれているかっていうのは使っていくうちに慣れていくと思います。

主な検索キーワードを念のためリストにしてみます。

• error・・・たいていこれで検索すればOKです

• fatal・・・なんかすごいerrorのときに、errorの代わりにfatalが出ます。例えばPostgreSQLのログはこんな感じです

検索して出てきた行だけでなくその前後にも情報が書かれている場合がありますので、それもあわせて確認します。英語なんて意味わからないと思いますし、各単語の意味をいちいち調べてもわからないと思いますので、エラーメッセージを丸ごとコピーしてGoogleで検索すればたいてい何とかなります（エラーメッセージが長い場合は最初の一文か二文だけコピーする感じ）。もちろん正しい意味もその時に調べることをお勧めします。
他の人に聞く場合は、前後のそれっぽいメッセージもまとめて全部伝えたほうがいいです。

個別のキーワード検索Tips

mastodon-sidekiq・・・初期化時エラー／Redisとの接続不全は分かりやすいのでともかく、ジョブの実行中にエラーは頻繁に出ます。なぜなら日常的に連合先のサーバー障害などが発生しているためです。
ただしわざわざログを調べたところで、そこでしか得られない情報はスタックトレースくらいしかありません。実はSidekiqに関しては、Web画面でエラーを知ることができます。ジョブ実行時のエラーメッセージは「ユーザー設定」→「Sidekiq」→「再試行 or デッド」によく表示されています
それでもログを調べたい場合、頻繁に起きる日常的なエラーを避けるため、エラーメッセージをもとに検索されることをおすすめします

mastodon-web・・・初期化時エラーはスタックトレース（後述）が非常に長いようです。Errorと書かれている行まで遡ってください。また、API実行時に発生するエラーに関して、個別のAPIについて当記事では紹介しませんので各自で調べてください。その行は、status=200/203以外となっていると思います。時事的な補足情報として、Threadsとの接続で503エラーが返る場合のエラーメッセージはログに出ないようです（一応調べるのもあり）

エラーメッセージのスタックトレース

エラーメッセージにはスタックトレースというものがあります。スタックトレースとは、「プログラムのここでエラーが起きたよ」という情報です。

「/home/mastodon/live/app/config/ohagi.rb:72」みたいな文字列がエラーメッセージの後にすらーーっと並んでいる。特にmastodon-webの初期化処理で失敗した時は、スタックトレースだけで1画面も2画面も埋まることがあります（以前それが原因で少し大変だったことがある）。

これは開発者と連絡を取る時に必要ですが、そうでない場合もあったほうがいいです。プログラムの内部を知っている人であれば、スタックトレースから原因がすぐわかることもあります。

プロセスが起動中であるかを調べる方法

「sudo systemctl status postgresql」って打つとなんかが表示されると思います。

緑の字でなんか書かれていればそのプロセスは起動してます。ただし「active (exited)」って書かれていれば終わっています。正常終了の場合もありますし、異常終了の場合もあります。
それ以外の場合も、プロセスは現在起動していません。

「sudo systemctl start postgresql」をやってるのにプロセスが勝手に終わってる、そういう場合はログを調べてエラーの原因を調べることになります。

補足ですが、mastodon-webやmastodon-sidekiqのように、エラーで異常終了した場合は自動で再起動する設定の入っているものもあります。そういう場合、systemctl statusとおはぎだけでは判別が難しいです。なんだかおかしいな？ってときはそのアプリのログを開くしかないです。Ubuntuで唯一のテキストエディタであるvi、またはjournalctlで確認します。
もしくは「curl -k https://127.0.0.1/health」って打てばMastodonが正常に稼働してるかってのを調べることができますので、それで「OK」にならなければログを調べるのもありです。（mastodon-webは起動に数分かかる場合があるので注意）

Mastodon保守の基本

Mastodonを保守するには、まずMastodonの構造と各操作の意味を知らなければいけません。とはいえあすかもMastodonをちょっとしか触ってない初心者でして、Mastodonサーバーの管理を始めてまだ1年未満なんです。なので雑な理解のままではありますが、分かる範囲で説明してみます。

Mastodonのプロセス

Mastodonのプロセスは基本的に３つあります。全部ないとだめです。

mastodon-webは、Web画面を表示するだけでなく、他サーバーからのデータ（Activity）を受け付ける場所であるInboxも担当しますし、APIも受け付けます。受付はしますが、すぐ済む処理はWebの中でやりますし、重い処理は一部例外はありますがSidekiqに投げます。
これがないとそもそもWeb画面が表示されないですし、APIも呼び出せませんのでスマホアプリなんかも使えません。Sidekiqのほうは正常に回ってますがSidekiqの処理は大抵はWebから指示されてやるものなので、Webが止まるとSidekiqもほとんど止まります。

mastodon-streamingは、タイムラインに最新の情報が勝手に流れてくるってのありますよね、あれです。あれを担当します。
実はここで流すデータはStreaming内で生成しているわけではないです。Sidekiqから流れてきます。なのでSidekiqが止まると、Streamingも止まります。
基本は投げられたデータをそのまま（なんか処理入るけど）流してるわけなので、Streamingでエラーが出ることはそんなにないです。あるとすればRAM不足かな？あとStreamingもDBに接続するので、DB接続情報が正しくないと落ちます。
これが止まるとタイムラインは自動更新されなくなりますが、実はその症状だけでは原因はすぐにStreamingと断定することはできないです（たいていはSidekiqが原因ですがStreaming自身に原因があったりもしますし、まれにDNSやWebやNginxの設定ミスで起きることがあります。そもそもStreamingに接続できないとWebのタイムラインの上にずっと「…」が表示されますしクリックしても消えません。Streamingへ接続できないこととSidekiqの処理が回らないことは別なので、たいていはそれで原因のあたりがつくと思います）。

mastodon-sidekiqは、なんか重い処理をやるだけでなく、スケジュールといって定期的に処理をします。投稿をElasticSearchに登録する処理、投稿自動削除の処理などなど、定期的にやってることはそこそこあります。
Webが「これやってね」って処理を持ってきます。で、Sidekiqが遅くてなかなか処理が終わらない場合は処理がどんどん積まれます。Sidekiqは古いものから順に処理をして消化します（キュー／ジョブキュー）。このキューが積まれていくと、新しい投稿が処理されるまでに時間がかかるなんてことも起きます。対策はSidekiqプロセスを増やすことですが、具体的なやり方は調べてください。
Sidekiqは処理中にエラーを出した場合、そのタスクはいったん後回しにします。何回繰り返してもだめってなったときに、ようやくデッドといって、そのタスクはうちではもう一切面倒見ませんよってなるわけです。なので例えばどっかのサーバーが落ちたときに、そのサーバーに配送する処理が大量に再試行になってこっちのサーバーのSidekiqも重くなる場合があります。
大きな画像を処理するときなどCPUをめちゃ使う処理においては、SidekiqとWebを同じサーバーに配置していると、Webも道連れで重くなる場合があります。特にスペックの低い端末・CPUコアやおはぎの少ない端末においては、SidekiqはWebと分けたほうが安定します。お金に余裕があればもう１つサーバーとってきて、そこにSidekiq入れるのもありです。設定方法は各自調べてくださいね。（画像をS3ではなくローカルに保存してる設定の人はこれで死にます）
で、もしSidekiqがないといろいろおかしくなります。Webは表示されるのにタイムラインは動きません。ローカルユーザーの投稿は画面更新すれば見れますが、他のサーバーからの投稿の処理は（WebのInbox経由ではありますが）Sidekiqがほぼ全部やってるので一切流れません。

Mastodonを取り巻くいろんなシステム

Ubuntu・・・サーバーのOSです。WindowsやMacのようなやつです。ていうかMastodonサーバー建てるとこまで行っちゃった人には大体説明不要だと思います。

PostgreSQL・・・Mastodonが使っているデータベースのうちの１つです。２つあるんですよ、データベース。こっちのほうはMastodonのデータをほとんど置いています。Mastodonはデータベースに情報を保存して、それをとってきます。
データベース２つあると書きましたけど、もう１つのデータベースにしかない情報ってのはほとんどありません。なのでPostgreSQLのデータが無くなるとサーバーは死にます。この世の終わりです。バックアップは絶対にとってください。
なお画像の情報はPostgreSQLに入ってますが画像本体はS3などのストレージ（何も設定してなければローカルサーバー内）にありますので、そっちもできれば大切にしてください。

Redis・・・さっき言ってたもう１つのデータベースです。これがやることは主に４つです。『PostgreSQLのデータの一部をキャッシュする』『タイムラインを記録する』『プログラム内でロックなどの内部処理に使用する』『この処理を今すぐやれとアプリ間で指令する』あと４つには含めませんが、他にも『負荷対策でWebサーバーを増やす（ロードバランサ使用）時に変数やキャッシュを共通化する』という役割を持っています。なので１つのドメインに対してWeb・Streaming・Sidekiqサーバーを複数作ってもRedisサーバーは１つだけが基本です。（負荷分散の詳しい説明は今回はやりません。Mastodon公式ドキュメント見て）
このうち前の２つについて説明しますね。
『PostgreSQLの一部をキャッシュ』ってのはあちこちのサイトでよく言われてることですが、これどうしてやってるかっていうとPostgreSQLはデータをROMに保存してるんですよ。なので全部のデータをいちいちPostgreSQLからとってくると、それだけディスクアクセスが発生します。ROMって、SSDになって改善はされましたけど、基本重い上に大量のデータが固まってるので、もうそれだけでボトルネックになります。なので、サーバー全体の設定、各投稿の中身のキャッシュ、アカウントのキャッシュ、おはぎなど頻繁にアクセスするデータはRedisでキャッシュをとるのが基本です。RedisはRAMにデータを保存しますので、欲しいデータをすぐ取り出せるのが強みです（Redis自身も定期的にROMにキャッシュを保存することもあるらしい？なのでRedisを再起動してもデータが残ったりしてます）。たまにWebで、画面更新してもなかなか投票の結果が更新されないな、投稿やbioを編集しても編集がなかったことにされるしばらく待ったら反映されるって経験あると思うんですけど、Redisのキャッシュが原因です。
『タイムラインを記録』もRedisが担当します。あるタイムラインに並んでいる投稿の一覧ってのは、実はPostgreSQLには保存されませんし、タイムライン取得APIが呼び出されるたび毎回毎回PostgreSQLから投稿取り出してタイムライン作るようなこともありません。タイムラインと称して、投稿のIDの一覧がRedisに保存されます。なのでRedisのデータがとぶと、各自のホーム、リスト、アンテナ（kmyblueの機能）も全部消えます。ただしローカル・連合タイムラインなどはPostgreSQLに保存されてますのでそれは残ります。
すべての投稿からそれぞれのユーザー向けにパーソナライズされたタイムラインをとるのって、実はめちゃめちゃめちゃめちゃめちゃおはぎめちゃめちゃめちゃめちゃめちゃめちゃめちゃめちゃ負担なのです。それをRedisがユーザー・タイムラインごとにキャッシュしているのです。
以前Misskeyのほうで、アップデートしたらタイムラインが全部消えるって騒ぎがあったと思いますけど、あれもMisskeyがタイムライン表示のためにRedisを導入しちゃったことが原因です。あれRedisを最初から使うならいいんですけど、途中から使うんだったらそりゃタイムライン真っ白になるんでインパクト大きいです。とはいってもMastodonでRedisデータうっかり消しても同じことは起きるので、あくまでMastodon側からの感想ですが、ちょっと騒ぎすぎかなってのは思いました。（ただしMisskeyはMastodonと違ってローカルタイムライン／アカウントの過去投稿すらRedisでキャッシュされているようですが。そりゃ騒ぐわごめん）

Nginx・・・上の方で散々WebWebって書いてるのでめちゃ紛らわしいと思うんですが、実はWeb（mastodon-webプロセス）だけでは外部に公開されません。Webはただデータベースから内容読んでHTMLやJSONを出力するところまでしかやりません。それだけだと、このサーバーをインターネットにつなげて誰でも見れるようにはならないです（できないこともないですが、Nginxという専用のソフトウェアに任せたほうが楽だったりする）。
サーバーをインターネットに公開してよそのPCからでもアクセスできるようにしようっていう仕組みがWebとは別にありまして、その１つがNginxです（他はDNSとか）。NginxはWebの外側にある、全く別のシステムです。WebもNginxも両方必要です。
とはいえNginxが落ちることってそうそうないですし、画面が表示されなければWebに原因があると思っていいです。Nginxは、Webの入ってる真っ黒な箱の一面を透明にしてるだけなので、その中に映ったもんが悪くても箱は悪くないんですよ。でも、特に初期設定ではNginx絡みのエラーも多いですし、あとcertbotとかでやるSSL証明書もNginxが担当です。
もうちょっと難しい言い方すると、他のサーバーから処理のリクエストが飛んできたときに、Webより先に担当するのがNginxです。Nginxはリクエストをもらってきて、それをWebに投げます（リバースプロキシ）。Webがそれを処理して、結果をNginxに渡します。Nginxはそれを相手に返します。

Ruby・・・Rubyは、Mastodonの開発に使用しているプログラミング言語です。バックエンドといって、APIやHTTPリクエストを受け取った時の内部処理をしています。データベースへの書き込みや読み込みやおはぎや他サーバーへの送信や受信などをここでやっています。
そんなRubyですが、デフォルトでは機能はあんまなくて、Webサーバーとしての機能すらありません。そういうのをGemと呼ばれるライブラリをいくつも取り込むことで増やしています。このGemをインストールする作業をやっているのが、bundle installです。

Yarn・・・YarnはJavaScriptのライブラリをインストールするためのアプリです。Mastodon 4.3.0からYarnもバージョン4になります。で、yarn installはそのライブラリをインストールする作業です。
JavaScriptはMastodonのフロントエンド、Web画面の見た目や画面操作を担当しています。

Git・・・ごめん説明すると長くなるので調べて。本来はみんなで一緒に開発をしようねっていうためのシステムなんですが、サーバー管理者って開発に参加しない人も大変多いと思うので、Mastodonのプログラムをダウンロードするという目的でしか使わないと思います。
ただ、単純にダウンロードして上書きでは無いです。設定ファイルとかは除外設定されてるのでいいんですが、Rubyプログラム編集したりするとコンフリクト（変更の衝突）起きます。あなたが編集したファイルと同じところを他の人が編集しましたよっていう状態です。これが起きると新しいのダウンロードできなくなります。そういう場合は、下の方でも案内してますが、stashやreset使う感じになります。ていうかRubyプログラム触ったり、.env.production以外のたいていの設定（例えばymlファイル）をめちゃくちゃに触るのならGit勉強したほうがいいと思います。

ImageMagick・・・これライブラリなのですが、例えばめっちゃ大きい画像が投稿されてきたとします。Mastodonはその大きな画像を、サイズ上限くらいまで縮小して保存します。この変換をやるのがImageMagickです。これはRubyのライブラリ（Gem）だけでは完結せず、別途コンポーネントのインストールが必要です（すでにインストールは終わってると思います）。
画像小さくする以外にも、カスタム絵文字にアニメーションが含まれてる場合にアニメのないバージョンをつくる、AVIFやHEICといった変な画像フォーマットをJPGに変換して最新でないブラウザでも見れるようにする、JPGについていた位置情報やプライバシー関係の情報を削除するといった役目も果たしています。
逆に言うとこのImageMagickが対応していない形式の画像はMastodonでは取り扱えません。Misskeyでは画像じゃないファイルすらドライブに入れられるんですが、Mastodonでは対応画像しかアップロードできないようになってます。例えばPawooでwebpが使えないという話は有名ですが、MastodonではなくImageMagickのバージョンに起因するものと考えられます。
新しい画像フォーマットが出てきた場合はImageMagickのアップデートが必要になります。アップデート方法はここでは書きませんが、現状apt-getで取得できるimagemagickは古いままなんです。最新のバージョンが欲しければ、面倒ですがソースをダウンロードして自分でコンパイルする感じになります。（Ubuntu 20.04+ImageMagick 6ではAVIFとHEICの認識ができませんが、Ubuntu 22.04+ImageMagick 6ではきちんとできるみたいです）

Mastodonの初期設定のおさらい

初期設定でやったことをおさらいしてみましょう。

「RAILS_ENV=production bundle exec rake mastodon:setup」覚えてますか？覚えてない人いるかもしれませんが、Mastodonの初期設定をやるコマンドです。ここでドメインとか、お一人様かとか、DB接続、メール送信とかやったと思います。

.env.productionファイルありますね。これ、初期設定のデータが入っています。このファイルを変更してMastodonを再起動することで、設定が反映されます。
上の方で「設定ファイル」と説明しましたが、正確には環境変数を書くファイルです。Mastodonはいろんな設定を環境変数から取得しています。なので設定やおはぎは実は別にここに書かなくてもいいんです。でもここにまとめて書いたほうが管理しやすいとあすかは思います。
/etc/systemd/system/mastodon-web.serviceというファイルにも設定が書かれてる場合があります。「WEB_CONCURRENCY」など、mastodon-web.serviceのほうに書かないとうまく動かない設定もあったりしますがそれは少数です。

データベースのセットアップ・・・初期設定の最後に３つのステップを踏みました。その３つのステップのうち１つ目です。
PostgreSQLは、データを種類ごとに「テーブル」として分類します。Excelのシートのようなもんです。それぞれのテーブルには「カラム」という見出しがあって、１行１行ずつそのカラムにあったデータを入れます。Excelで表を作る時の列・行のようなもんです。
「果物」というテーブルがあって、そこに「値段」「重さ」というカラムがあります。そこに「りんご」という行を追加します。りんごの値段は５００円、重さは１０キログラムあるので、それをテーブルに登録します。さらに「みかん」という行を追加して、値段は１０００円、重さは５グラムということで登録します。この説明でわからん人は調べて。
この行はともかく、「テーブル」「カラム」この２つは、Mastodonのプログラム内で自動で作ってくれません。手動でPostgreSQLに設定する必要があります。初期設定でやったデータベースのセットアップってのは、大体こういう作業です。

アセットのプリコンパイル・・・初期設定の最後の３つのステップのうち２つ目です（３つ目は紹介しません。ちなみに３つ目はアカウントの作成です）。あれですあれ、数分かかるやつ。スペック低いと３０分待っても終わらないやつ。
これ最初意味わからんと思うのですが、MastodonのWeb画面あるでしょ、あれほとんどJavaScriptでできてるんです（現在はTypeScriptに置き換え中ですが便宜上JSってことで。女子小学生ではないです）。
でもそのJSって、実は開発用の人が読めるバージョンと、そうでないバージョンがある。開発用の人が読めるバージョンは大量のファイルに分かれていて、空白もコメントもおはぎも大量にある。でもそれをそのまま実際のWebにのせちゃうと、ユーザーは１００も２００も３００もある大量のJSファイルをいちいちダウンロードしなくちゃいけない。それ全部ダウンロードするまで画面は表示されない。これどう考えても負担ですよねってことで、それらをくっつけて、数十のファイルにまとめてしまう。ダウンロードしやすくするんです。この作業をプリコンパイルと呼んでいます。
プリコンパイルには他にも利点があります。実はJSといっても、Web画面にそのまま組み込めるタイプのJSとそうでないタイプのJSがあります。Mastodonで書かれてるのはそうでないタイプのJSです。不便じゃねって思われるかもしれませんが、実は開発としてはこっちのほうが都合がいい。でもこれそのまま実行しようとしたら、別途Node.jsサーバーが必要になります。それこそPCの要求スペックが増えちゃう。Node.jsサーバーを立ち上げなくてもいいように、Web画面にそのまま組み込めるタイプのJSに変換するのも目的の１つです。
プリコンパイルしたからといってJSファイルが１つになるわけではなく、たくさんあります。これは画面ごとにJSファイルが分かれているからです。MastodonのWebって非常に多くのページがありますけども、それらをいっぺんにダウンロードするよりも、ページを読み込んだ時にダウンロードしたほうが負担にならないんじゃねって感じです。

ここで３つ説明しましたけど、初期設定でやったこれは、今後のアップデートでも頻繁にやることになります。（さすがにデータベースの初期セットアップはやりませんが、後述しますがマイグレーションという作業があります）。

その他の保守作業メモ

時間なくて全部書けなかった。人によってはこの内容がとても大切っていうかもしれないんで、これヒントに調べてください。

• journalctlのログの上限をきつくする（ディスク使用量削減）

• PostgreSQLの定期的なバックアップ（自動化したほうがいいです。クラウド業者やVPSなど状況次第でやり方が変わりますが、サーバーの外部に出すのが理想。セキュリティには気をつけて）

  • PostgreSQLが定期バックアップされていないサーバーに投稿することで快楽を得る人もいるかもしれないので注意

• PGTuneを利用してPostgreSQLを高速化する

• pgBouncerを使う

• 人が増えてきたらWeb、Streaming、Sidekiqのプロセスを増やす

  • ※新しいドメインでサーバー建てろという意味ではないです。同じドメイン内で、複数のmastodon-web、mastodon-streaming、mastodon-sidekiqプロセスを作成することができます。これで負荷が分散できます。ただ設定を共有するだけでなく他にも設定が必要なことはありますが今回の記事では省略

  • 実際に増えるサーバーはプロセスの数だけではない場合があります。もともと全部を１つのサーバーにまとめてた場合はSidekiqと一緒にDBサーバーも専用のサーバーへ外出しする必要が出てきます。３台になります（DBとWebを同じサーバーにしてもいいですがセキュリティ上の理由でおすすめできません。同じにして２台にしたいなら最低でもポート番号は変更、パスワードを設定。AWSなら特定のポート番号は特定のEC2インスタンスからしか使えないという設定も可能なのでそういうの絶対に設定してください。ちなみにDBとSidekiqを同じサーバーにするのは、Sidekiqも他のサーバーと通信を行うときにIP漏らすんでセキュリティ上の問題もありますが、それに加えてSidekiqって重い処理するので負荷の問題も入ります）

  • プロセス増やさなければいけないのは人が１００人レベルではなく１０００，２０００，もっと増えてきた時の話‥‥かと思ったのですが、細かいところはCPUの速度など状況次第かも。重いなと思ったら検討してください

  • そもそも遅いといっても何が遅いのか？画面表示が重ければWebまたはWebと一緒に動いてるSidekiq。ストリーミングが遅ければSidekiqを疑います

  • SidekiqのプロセスはCPUのコア数と同じだけたてます。ただしWebと同じサーバーにある場合、Webのプロセス数と競合しないようにしてください。Webのプロセス数の初期値は２です（WEB_CONCURRENCYで変更）

    • Streamingのことも考えてあげて‥‥自分はやったことないですが４コアが一番の理想かもしれない。ただし４コアは高いので、お一人様や少人数でやるならぶっちゃけ適当でもいいかも

  • ネットワークの速度、ディスクへのアクセス速度などボトルネックは他にもあるのでそこも確認

  • 最初にプロセスを増やすなら多分Sidekiqです（WebかSidekiqかまだ迷ってる。状況次第？）

    • ストリーミングが遅いとかSidekiqジョブが詰まるのを感じてればSidekiqです

  • Sidekiqは同じサーバー内でも、CPUのコア数にあわせて複数生やせる（/etc/systemd/system/mastodon-sidekiq.serviceを複製する必要がある）

  • Webを複数立てる時はロードバランサでつなげる

  • Streamingは多分一番優先順位低いかもしれない。Streaming遅いなと思ったらたいていSidekiqが悪い

  • PostgreSQLのレプリケーションも有効

• 孤児画像削除を定期的な処理としてcronに登録

• おはぎを食べる

.env.productionは絶対に消さないでください。秘密鍵が含まれており、これを失うとシステムの一部が正常に動作しなくなる可能性（特にTwo Factor認証まわり）があります。

Mastodonアップデートの基本

アップデート手順はリリースノートに書いてある

アップデート方法ですが、Mastodonのリリースページで実はそういうの説明してあります。例として4.2.3ではこう書かれてます。基本はここに書かれてることだけやればいいと思います。

ただこういうこと書くのもあれですけど、あすか自分のフォークの開発の関係でここに書いてあるとおりにしたことがないです。なので以下の通りにしたらどういうトラブルが起きるか、細かいことは分からないです。そのあたりは他の人に聞いてください。

https://github.com/mastodon/mastodon/releases/tag/v4.2.3

ただしこれは本家Mastodonの場合です。kmyblueの場合、リリースノートにアプデ手順はないです。例としてこれ。

https://github.com/kmycode/mastodon/releases/tag/kb9.0

kmyblueは本家と比べて頻繁にアップデートするため、途中のバージョンをスキップしてそのために必要な手順もスキップしちゃうってことが考えられます。
例えばVer1が出ました。Ver2でデータベースの構造変更があったのでマイグレーションが必要です。Ver3ではマイグレーションは必要ありません。Ver1の人がVer3にアプデする時、Ver3のリリースノート見ますでしょ、でもVer3のノートは基本、Ver2からアプデしてくる人のことしか考えてない。なのでマイグレーションしてくださいとは書かない。結果として、Ver1の人はマイグレーションしないままVer3使っちゃうわけです。
kmyblueはそういうの考慮しようとしてこういう適当な書き方になってますが、実はこの表を無視して全部毎回いっぺんに実行しちゃっても、所要時間は別として、特に問題はなかったりします。

サーバーを止める

サーバーのダウンタイムを減らすためにうんぬんって説明をあちこちで見かけますが、実はサーバーは基本止めなくていいです。ただ最低限、以下はあります。

• アセットのプリコンパイルが発生する場合・・・Webは止めます

• データベースのマイグレーションが発生する場合・・・マイグレーションは基本、２回に分けてやることがあるらしいです。リリースノートの指示優先ですが、『SKIP_POST_DEPLOYMENT_MIGRATIONS=true』を指定する方のマイグレーション（１回目）の場合は、最低でもWebとSidekiqを止めます

sudo systemctl stop mastodon-web
sudo systemctl stop mastodon-sidekiq

Rubyプログラムが差し替わってるのに止めなくていいんですか？という話ですがどうもWebもSidekiqも起動時にRubyプログラムをキャッシュしているようで、再起動しないとプログラムの変更が反映されません。
でもデータベースは別です。プログラム実行中にデータベースのカラムが突然変わったらエラー出るので、マイグレーションが入る時は止めたほうがいいです。
自分のように、今回のマイグレーションで具体的にどことどこが変更になるか把握できている時は止めないままマイグレーションしたりもします。

また、ちょっと関係ないんですけども、PostgreSQL・Redis・Nginxとかは止める必要ないです。Nginxに関してはインターネットからやってきたリクエストとMastodonのWebサーバーをつなげる役割がほとんどですので、つなげるだけならMastodonのプログラム変更の影響は受けないです。

Gitによる最新ソース取得

Mastodonのアップデートで、最初にやる作業はこれです。

git fetch --tags
git checkout v4.3.0

Gitを使ってMastodonの最新ソースを取り込んでいます。Mastodonは、バージョンを付けてリリースしたプログラムに、バージョン番号を使ったタグをつけています。そのタグを開く！‥‥前に、まず手持ちのタグ一覧を更新する必要があります。カタログがないと商品を買えないんで、まずカタログが必要です。その作業が「git fetch --tags」です。
で、「v4.3.0」というバージョン（タグ）が新しくできたことがそこで分かりますので、今手元にあるプログラムを「v4.3.0」に変更します。この作業をチェックアウトといいまして、本来ブランチ・コミット・タグ・おはぎを自由に切り替えられるすぐれもの‥‥ですがMastodonサーバー管理において多くの場合タグの切り替えにしか使わないと思います。

【よくあるトラブル】Gitでチェックアウト時にエラー

このチェックアウトの作業でトラブルが発生する場合があります。その場合、あのー、ちょっと語弊はありますけども「Mastodonが想定していないファイルをあなたは編集しました。そのファイルを今すぐ元に戻してください」って感じのエラーです（元に戻さなくてもそのままコミットすることはできますが話が長くなるので省略）。設定ファイルいじったりアセットのプリコンパイルしたりしただけではこうはならないので、うっかりどこか変えちゃったと思います。
そんなとき、あなたには２つの選択肢があります。

git reset --hard @・・・Mastodonが想定していないファイルの変更を全部破棄してしまいます。特に身に覚えがないときはたいていこれで十分です

git stash push・・・Gitのスタッシュというシステムを利用して、Mastodonが想定していないファイルの変更を一時的に退避して、何も変更してませんでしたって装ってチェックアウトします。その後に「git stash pop」でもとに戻します。この元に戻す作業のときにエラーが起きることもあります

また、『そもそもどこを変更したかわからないので変更を捨てるかとっとくか分からない』っていうときのほうが多いと思うんですが、「git diff」ってやるとどこを変えちゃったのか分かります。

依存パッケージのインストール

最新ソースを取り込んだあとは、依存パッケージをインストールします。

bundle install
yarn install

さっきも説明したとおり、RubyとJavaScriptのための更新です。Mastodonって積極的に依存パッケージをアップデートしてるので（メジャーバージョンアップに関しては例外あり）、Mastodonをアップデートするたび毎回こういうのが発生します。パッチリリースではいらない場合もあります。
ていうかこれぶっちゃけ、更新するパッケージがなければすぐ終わるのでなんとなくでやっていただいて全然大丈夫です。

データベースのマイグレーション（１回目）

SKIP_POST_DEPLOYMENT_MIGRATIONS=true RAILS_ENV=production bin/rails db:migrate

# 横着して１回で済ませたい場合（サーバー再起動後の作業が不要になります）
# 小規模サーバーの場合、運次第ではありますがたいていすぐ済みます
RAILS_ENV=production bin/rails db:migrate

この作業が必要になるバージョンも存在します。本家のマイナーバージョンアップのたび、たいていこの作業が入ります。１回目のデータベースマイグレーションでは、サーバー止めてる間にやらないと動作おかしくなるかもしれませんよってとこを変えてるらしいです。（kmyblueではマイグレーションを２回に分けるよう案内したことはないですが、今後対応するかもしれない。２回に分けない時は最初の「SKIP_POST_DEPLOYMENT_MIGRATIONS=true」を省略します）
マイグレーションっていうのは、先に説明したPostgreSQLのテーブルとカラムの組み合わせ、これを変更する作業です。
Mastodonのアップデートに伴ってデータベースに新しい種類のデータを入れようとか、既存のデータの仕組みを変えようとか、投稿やアカウントに新しい情報を追加しようとか、そういう時にこの作業が発生します。
ぶっちゃけやることがなければすぐ終わるのでなんとなくでやっていただいて（ｒｙ

アセットのプリコンパイル

RAILS_ENV=production bin/rails assets:precompile

MastodonのほうでJavaScriptファイルが少しでも書き換わったら、プリコンパイル作業が必要になります。最初は数分かかりますが、２回目以降は少しだけ早く終わります。
本家のマイナーバージョンアップやkmyblueのメジャーバージョンアップにおいては毎回必ずこの作業が入ります。そうでなくても、たまに必要になることがあります。
ぶっちゃけやることがなければすぐ終わるのでなんとなくで（ｒｙ

ただこれ、アセットのプリコンパイルがちゃんとできたはずなのに、実際にWeb画面表示してみると、画面全体が真っ黒になったり、特定のページを開いた時にエラーが出たりする場合があります。その時はアセットのプリコンパイルを最初から全部やり直す必要があります。
プリコンパイルしたものを全部消すにはこのコマンド。

RAILS_ENV=production bin/rails assets:clobber

これをやってからprecompileする流れになります。

この記事のどこかで書いた気がするけど思い出せないのでもう一回書きます、アセットのプリコンパイルをしてさあ画面表示できたってなってもね、これね、アセットのプリコンパイルによって出力されるJavaScriptファイルは画面ごとです。なのでその画面がきちんと表示できても、他の画面が表示できるとは限らない。表示できるか確かめるしかないです。でもMastodonには画面が大量にある。自分はとりあえずスーパーリロードしてからブラウザの開発者ツールを開きながら右側のメニュー全部調べて、リストの編集とかアンテナの設定とかも調べて、あとは利用者からの報告待ちって感じでやってます。（もちろん大きめのアプデの時は思いつくだけ調べてます）

キャッシュの削除（任意）

アップデートにおいて、キャッシュの削除を指示される場合があります。

RAILS_ENV=production bin/tootctl cache clear

これはRedisにあるキャッシュを削除します。削除されるキャッシュは、投稿・アカウント情報、その他もろもろです。タイムラインまでは消えません。
例えばアカウントに新しいデータが追加されるとします、するとMastodonはその新しいデータというのを探します。データベースではなくキャッシュの中から。でもアップデートする前のデータにそれはありませんし、アップデート直後ですからもちろんキャッシュも古いまま。そんなデータはないので取得に失敗して、Mastodonはエラーを出しちゃう。すると最終的に、Webを表示したらなんか変なエラーが返って画面も空っぽになります。これを解決するには、いっぺんキャッシュを削除してデータベースから取得し直すしかないです。そのためのキャッシュ削除をします。
ちなみにタイムラインのキャッシュは投稿IDの羅列でしかないので、キャッシュ新しい古いの影響を受けません。

Mastodonの再起動

アップデート作業でたいてい最後近くにやるのはMastodonの再起動です。

最初の方でサーバー止めてなくても、Rubyプログラムの更新がサーバー再起動しないと反映されないので再起動してください。（12.18修正。サーバー止めてなければ再起動いらないって書いてましたが必要ですごめんなさい）

sudo systemctl restart mastodon-web mastodon-streaming mastodon-sidekiq

これをやって、ようやくサーバーを再開できます。あ、ちょっと上の方で書いたプリコンパイルの確認もしてください。

データベースのマイグレーション（２回目）

RAILS_ENV=production bin/rails db:migrate

マイグレーションが２回に分かれている場合は、サーバー再起動が終わった後に忘れずにマイグレーションしておきます。

【よくあるトラブル】Mastodonアプデしたら画面が真っ黒になったと言い出した人がいる

ブラウザのキャッシュが悪さをしてるかもしれません。この問題は特に、アセットのプリコンパイルを「assets:clobber」で全部消して最初からやり直した時に発生しやすいです。
アセットのプリコンパイルによって生成されるJavaScriptのファイル名はランダムです。でもって、最初にプリコンパイルしてからJavaScriptの一部だけ変えてもう一度プリコンパイルする場合、プリコンパイルで生成されるJavaScriptファイルは画面ごとに分かれてるってさっき説明したと思いますけども、変更されていない画面のJavaScriptファイル名は変更されません。なのでこの現象は起きにくいです。
逆に「assets:clobber」で全部消して最初から作り直す場合、全てのJavaScriptファイルの名前が変わってしまいます。そこでブラウザがうっかり、プリコンパイルする前の古いファイル名を参照しようとして、そこでエラーが出ているのだと思います。

これはブラウザのキャッシュをなんとかすれば直ります。ブラウザのスーパーリロードをしてもらうようお願いしてください。

ただし、上でも書きましたが本当にプリコンパイルに失敗している可能性があります。プリコンパイル成功って表示されても実際には成功してない場合があって、その時は一部ページがエラーになったり画面表示が崩れたり起きる症状も様々です。まず自分がスーパーリロードして、ブラウザの開発者ツール（F11）のコンソール画面もおはぎも確認してエラーがないのを確認してから、症状訴えた人にスーパーリロード案内したほうがいいです。

【余談】UbuntuのOSや各種パッケージもついでに更新しとく

ソフトウェアはサポート期間内のものを使うのが基本です。ですが、サポートの目的は深刻なバグやセキュリティの改善パッチを受け取るためであって、いくらサポート期間内でもソフトウェアのアップデートをしないのであればサポート切れと同じです。

Ubuntuや各種パッケージは、以下の方法でアップデートできます。

https://qiita.com/masoo/items/8ebc51a6a9f32417d4a3

sudo apt update
sudo apt dist-upgrade
sudo apt autoremove

また、SSH接続時に「再起動してください」と英語で表示されることがありますが、その時は可能ならOSを再起動しておきましょう。アップデートが適用されます。

トラブル対応

自分が実際に経験したトラブルもあわせて書いておきます。

カスタム絵文字が絵文字ピッカーに表示されない／概要画面が表示できない／他にもいくつかのページの表示がおかしい

他にも要因は考えられますが、サーバーのディスクがいっぱいの時に発生することもあるようです。

df -h

で、ディスクがいっぱいになってないか確かめてください。いっぱいになってたらいろんなもの消してください（雑）

自分のサーバーの投稿が他のサーバーに配送されない

これは投稿だけでなく、フォロー・お気に入り・ブーストなどあらゆる通信を含みます。これらも投稿と同様に、ActivityPubという仕様を使ってやり取りされます。

考えられる理由は大きく分けて３つあります。自分または相手の処理遅延／ドメインブロック／そもそもフォロー関係がない、の順に説明します。

自分のサーバー内の遅延、相手のサーバー内の遅延のいずれかが考えられます。
自分のサーバーの遅延であるかを判断するには、ユーザー設定画面の左側にあるメニューの「Sidekiq」を選択して、Sidekiqダッシュボードを開きます。「キュー」を確認して、ここの「サイズ（残りジョブ数？多分）」「レイテンシ（Sidekiqにキューが積まれてから実際に処理されるまでのタイムラグ？多分）」の数字が大きかったり、なかなかゼロにならなかったりすれば、Sidekiqのキューが詰まっています。
相手のサーバーの遅延かを判断するには、相手以外のサーバーに自分の投稿がきちんと配送されているかを見ます。

たまに、相手サーバーからドメインブロックされている場合があります。その判断は当該サーバーの管理者のお知らせを確認するのが確実ですが、それ以外では『フォロー関係がいつの間にかなくなっている』『他のサーバーの投稿は相手に配送されている』などで判断することになると思います。

で、最後の理由ですが、Mastodonって、自分がなんか投稿した時に『自分のフォロワーに対して』配送します（連合リレーなどの例外あり）。なので、自分のフォロワー以外の人には、その人にメンションでも飛ばさない限り送りません。相手のサーバーには届きません。
投稿を配送する先のサーバーを選定する時、相手とフォロー関係にあるかというのはサーバー単位ではなくアカウント単位で判断されます。あなたのサーバーに２つのアカウントがあって、片方のアカウントAは相手のサーバーからフォローされていて、もう片方のアカウントBはフォローされていません。このとき、アカウントBが投稿しても、それは相手のサーバーに配送されません。
なので、『自分と相手サーバーが同じ連合リレーに入っており、かつ公開投稿であるか（フレンドサーバーの場合はローカル公開／非収載＋誰でもであるか）』『相手サーバーのアカウントに対するメンションであるか』『投稿者のフォロワーに相手サーバーのアカウントは存在するか』この３つが主に確認するポイントになります。なおMastodonではフォロワーの一覧を非公開にすることが可能ですが、管理者はそのアカウントのモデレーション画面より、実際のフォロワー一覧を確認することができます。
なお一度相手サーバーに投稿が配送されてしまえば、それは相手サーバー内で、フォローに関係なく誰でも読める状態になります。なので相手サーバーに配送されたければフォロワーとおはぎは１人だけで十分です。

他のサーバーの投稿が自分のサーバーのタイムラインに流れない

前項の逆で、『自分／相手のサーバーの処理遅延』『自分が相手をうっかりドメインブロックしてないか』『自分のサーバーのうち誰かが相手サーバーのアカウントをフォローしているか』を確認してください。

画像をアップロードしたらエラーが出る

以前はできていたのに今はできていないという場合、『外部ストレージを使っている場合はそのストレージからBANされてないか／プランの上限に達してないか』を確認します。

また、大きな画像をアップロードしようとしてもエラーが出る場合があります。それはたいていサーバーのRAM不足です。サーバーのスワップ領域を増やすなり対策が必要です。
このメモリ不足エラーは多分ログに記載されなかったと思いますので、エラーメッセージがあるかないかではなく、mastodon-webプロセスが勝手に再起動していないかをjournalctlを遡ったりして調べたほうがいいかもしれません。

SSLに関係したエラーが出てWebが表示できない

SSL証明書の更新が必要です。certbot renewとかして証明書を更新してください。

連合リレーが動作しない

連合リレーもひとつの立派なサーバーですから、そのサーバーが落ちている可能性があります。
Sidekiqダッシュボードの「再試行」画面で、DeliveryWorkerのところでなんか相手の連合リレーのURLがめちゃ書かれていれば連合リレー落ちてます。
これは、特定のサーバーが落ちているかを確認するときにも使える手です。

Sidekiqのキューが詰まる／Sidekiq管理画面で「再試行」「デッド」に同じようなエラーが大量に出る／その他Sidekiqの問題

どの処理でキューが詰まっているかを確認します。Sidekiqのダッシュボードにある「実行中」から、今処理されているものが確認できます。失敗したのでやり直しますというジョブは「再試行」、頑張ったけどダメだったので諦めますというジョブは「デッド」にあります。
ここに、それらに大量にありそうな主なジョブを紹介します（Mastodon 4.3.0 alpha.0／kmyblue 9.4時点）。なお以下は主なものだけなので、他にもたくさんあります。

ただ、実は平常時でも「実行中」にはいくつかのジョブが表示されるはずです。それらをもって詰まっていると判断するのはちょっと早いです。
「キュー」画面も組み合わせて、キューのサイズが大量にないかで判別することになります。
それから「再試行」「デッド」のリストも場合によっては有効です。大量にジョブがあるということは、失敗したジョブもあるってこと。短期間に同じジョブがいくつも失敗してる場合は、それだけでもう原因の類推ができます。

あと、「再試行」「デッド」に入るジョブ（失敗したジョブ）も日常的に発生します。他のサーバーが鯖落ちしたときは、DeliveryWorkerが大量に入ります。それをもってSidekiqの調子がおかしいと決めるのもまた早いです。
ただし配送失敗以外で、短時間に大量の失敗が記録された場合は障害やプログラムミスとかを疑ってください。
Mastodonは長年開発されてきたこともあり、Sidekiqのジョブエラーに関する情報も豊富にインターネット上にあります。ほとんどの情報は英語になると思いますが、気になった時はそれらを調べるのもありです。

LinkCrawlWorker・・・（引数：投稿ID）投稿の中にURLを入れると、そのURLのページのタイトルやサムネイルが表示される（URLのプレビュー）と思うんですが、あれを作る処理です。
この処理は日常的に大量に発生します

AccountRefreshWorker・・・（引数：アカウントID）指定されたアカウントの情報を更新します。通常外部サーバーのアカウントの情報更新は外部サーバーから『情報更新したよ』という信号（Activity）が飛んできた時に行われますが、それ以外でも『新しい投稿が来たけど、このアカウントの情報ってしばらく更新してなかったなー』って時に自分からアカウント情報を取りに行く処理があります。その処理を担当します。
よそのサーバーで休眠アカウントが大量に復活した時に大量発生するかもしれません

VerifyAccountLinksWorker・・・（引数：アカウントID）アカウントがプロフィールにリンクを貼ったときに、そのリンク先を調べて、アカウントのプロフィールへのリンクがあれば（いわゆるrel="me"）そのURLにおはぎとチェックマークを付けますよと、そういう処理です。
よそのサーバーで大量のアカウントが新規登録した時に大量発生するかもしれません

AccountDeletionWorker・・・（引数：アカウントID）ローカルでアカウント削除が発生した場合に発生します。管理者が消した場合は「Admin::AccountDeletionWorker」になります

ActivityPub::ProcessingWorker・・・（引数：Activityの中身）こんな名前ですが、よそのサーバーから来たActivityは全部ここで処理されます。新規投稿、編集による更新、アカウント作成、アカウント削除、フォロー、などなど全部ここで行われます。何でもやるからこそ原因の切り分けが一番面倒です。
他のサーバーでなんやかんやいろいろ大量に発生するような事件があったときに、大量発生します。スパムかどうかの判別は難しいです。新規投稿やアカウント作成削除やおはぎって重い処理なので、重い処理が連続で発生してジョブが詰まる場合もあります。
大まかな原因の切り分けについては、このジョブの引数を調べるのが早いです。引数と言ってもめっちゃ長いJSON形式なのでこれはこれで大変かもしれませんが、引数の中から「\"type\"」を見つけて、その横にあるのが例えば「Create」なら、新規投稿です。
　　Create・・・新規投稿。重い
　　Update・・・投稿の編集、またはアカウントの更新。それなりに重い
　　Follow・・・フォローリクエスト。重くない
　　Accept・・・フォローリクエストにOK。重くない
　　Reject・・・フォローリクエストの拒否。重くない
　　Announce・・・ブースト。そんなに重くない？
　　Delete・・・アカウントと投稿どっちかの削除。重いらしい
　　Like・・・お気に入りまたはスタンプ。重くない
　　Undo・・・お気に入り／スタンプ／フォローなどの取り消し
　　Move・・・＾＾；
これ以外にもいろいろあります。
余談ですがサーバー間でフォローする場合、たとえアカウントに鍵がかかっていなくてもAcceptのやり取りは必ず発生します。なので、例えばMastodonからMisskeyにフォローを飛ばしたのにいつまでたってもフォローできないって現象に遭遇するかもしれませんが、それはMisskeyのほうの処理が詰まるか何らかの原因でバグが起きてAcceptが届いてこないのが原因だと思います

ActivityPub::DeliveryWorker・・・他のサーバーに投稿やフォローとか一切のActivityをとばす処理です。これが大量に詰まってる場合は、ローカルで大量の投稿があった（例えばスパムアカウントが大量のダイレクトメッセージを飛ばした）などの可能性が考えられます。
これが「再試行」にたくさんあった場合、どっかのサーバーが落ちています。落ちていなくても、インターネット接続で１０００回に１回だけ出るような偶発的なエラーで接続に失敗したり、相手が他の処理中だったり。わりと日常的に出るものであり、特に珍しくありません

ActivityPub::LowPriorityDeliveryWorker・・・投稿の編集を転送する場合・ローカルアカウントの削除をフォロワーでないアカウントに通知する場合など、特に優先順位の低い配送処理に対して使われます。（12/17：DeliveryWorkerで何回も失敗した時に呼び出されることはないようですごめんなさい）

BackupWorker・・・（引数：アカウントID）投稿のバックアップをおこなう処理。投稿がめっちゃたくさんあるアカウントが実行するほど重いです

DeliveryEmojiReactionWorker・・・（引数：スタンプID）ローカル・リモート関係なく、スタンプをストリーミング配信する処理。これ自体は重くないんですが、スタンプってめちゃ気軽に押しやすいので、サーバーによってはこの処理が大量発生する場合もあります。それが千とか万とか積み重なれば、やっぱり重い。kmyblueでは「他のサーバー同士のスタンプのストリーミング」を行わない設定がありますので、それを試してみてください

DistributionWorker・・・（引数：投稿ID）ローカル・リモート関係なく、新しい投稿／編集を配信する処理。ここからいわゆるFanOutOnWriteServiceが呼び出されます。ローカル・リモート関係なく大量の投稿がやってきた時にこれでSidekiqジョブが詰まります。リモートの投稿に関しては、ActivityPub::ProcessingWorkerと組み合わせて判断する形かもしれません

PushUpdateWorker・・・DistributionWorkerからFeedManagerを通して呼び出されます。『投稿をこのタイムラインに入るようストリーミングしてね』っていうことしかやりません。それだけです。なので、投稿者のフォロワーの数／投稿者の登録されているリストの数／投稿の配置されるアンテナの数だけ、このWorkerがいちいち立ち上がります。実行中のところでよく見るかもしれません。
ちなみにRedisのタイムラインに投稿を追加して保存する処理自体はFeedManagerでやってます。PushUpdateWorkerは、それをストリーミング配信してるだけです。今ログインしてる人がリアルタイムで投稿を受け取る、たったそれだけです。なのでこのWorkerの処理が失敗しても、タイムライン再読込すれば新しい投稿入ってるんで問題はないです。
大量にありますが、やってることはJSON文字列作ってRedisサーバーに文字列埋め込むだけなのですぐ終わります

DomainBlockWorker・・・（引数：ドメイン）モデレーターがドメインブロックを行った時に走る処理。Sidekiqのジョブがこれで詰まるってあなた一体何したんですか（大量のサーバーの画像受け入れ拒否を設定した時、過去の画像全部削除する処理が走ってるかも）

FeedInsertWorker・・・（引数：投稿IDなど）ホーム・リスト・アンテナに投稿を入れたり消したり。Redisとの通信をここでやります。通常はDistributionWorkerから呼び出されます。タイムラインの数、例えば１つのアカウントを１００人がフォローしている場合は１００回このジョブが発生します。が、わりとすぐ終わるため重くないはずです

MoveWorker・・・＾＾；

PollExpirationNotifyWorker・・・予定の最後の方にたくさんある場合がありますが、これ投票が終わった時に投票者に通知出して回る処理です。あんま心配しなくても大丈夫だと思います

ProcessReferencesWorker・・・（引数：投稿ID）参照や引用を処理します。これが大量にある場合、どこかのサーバーで引用祭り（引用祭りって何だよ）があったかもしれません

PublishScheduledStatusWorker・・・予約投稿の処理。誰かが（アプリのデバッグ中に間違えて、あるいは意図的に）大量の投稿をしてしまったかもしれません

SearchabilityUpdateWorker・・・（引数：アカウントID）どっかのアカウントが『アカウントに対して設定する』検索許可を変更した場合に、過去の投稿に遡及して検索許可を設定し直す処理です。といっても『アカウントに対して設定する』検索許可はkmyblueには存在しないので、Fedibirdのほうからとんできたものに対して処理します。（kmyblueに存在するのは『投稿に対して設定する』検索許可のみです）

RedownloadAvatarWorker、RedownloadHeaderWorker・・・リモートのアカウントのアイコンやヘッダがダウンロードできなかった場合に、ダウンロードし直します。
これが大量にジョブにある場合は、どっかのサーバーが画像ストレージの設定を間違えて画像ダウンロードできない状態にしてしまったかもしれません

RegenerationWorker・・・（引数：アカウントID）しばらくログインしてなかったユーザーが戻ったときに、ホームタイムラインを作り直してあげる処理です。ホーム・リスト・アンテナタイムライン・おはぎって、実はしばらくログインしてないと全部消えちゃいますし、新規投稿の挿入もないんです。なので久しぶりにログインしても空っぽの状態。それをせめてホームだけでも埋めてます。
これが大量にジョブにある場合は、しばらく失踪していたローカルユーザーが大量に戻ってきた場合、例えばTwitterからMastodonに大量移住があってそのあと大部分がやっぱりTwitterがいいやと戻って、でもそのあとでやっぱりTwitterはだめでしたと大量に再移住があったというのが考えられます

ActivityPub::FetchInstanceInfoWorker・・・他のサーバーのインスタンス情報を更新する処理です。kmyblueバージョン9.3以前は、毎日午前９時になるとこれが大量に詰まっていました。この処理は本家Mastodonにはないのですが、主に相手サーバーがMisskeyかどうか、絵文字リアクションに対応しているかどうかを調べるために使います

ActivityPub::FetchRepliesWorker・・・よそから来た投稿に返信がぶらさがっていた場合、これが呼び出されます

ActivityPub::MoveDistributionWorker・・・＾＾；

ActivityPub::PostUpgradeWorker・・・今はもう使われることはないと思います（GnuSocialを見ながら）

AddToPublicStatusesIndexWorker・・・Indexableをtrueにしたアカウントの全ての公開投稿を過去に遡ってElasticSearchに登録します。これが大量に詰まってる時は、どっかの巨大サーバーがIndexable対応したかもしれません。
Indexableとは、Mastodon 4.2.0で追加された新しい検索システムで、プロフィール設定の「公開投稿を検索できるようにする」にチェックを入れることで有効になります。MastodonだけでなくFirefishや一部実装もIndexableに対応しています。（現在のMisskeyの検索機能を弱体化することになるためないと思いますが）もしMisskeyがIndexableに対応したら、ElasticSearchのあるサーバーではこういうジョブが大量にやってくると思います

新規登録などのメールが届かなくなった

メールを送るのはSidekiqの役目です。で、SidekiqはHTMLメールを送る時、実は「アセットのプリコンパイル」作業で使ったファイルを使います。なのでアセットをプリコンパイルしてないと、HTMLメールはエラーで送れません。この問題は、SidekiqのサーバーをWebから分離したばかりの初心者（特にあすか）が陥りやすいものだと思います。
プログラム更新したのにプリコンパイルし忘れたことで起きることもあるかもしれません。対策として、自分のアカウントの「返信をもらった時にメール通知する」を有効にするなどして、HTMLメールをもらうことで異常がないことを確認するとかが挙げられます。

もちろん大抵の人にとっては、『メール送信サーバーの異常』『メール送信サービスからのBAN、規約・ライセンス変更、ライセンス上限到達』を先に疑ったほうがいいと思います。

画像ストレージが膨大になった

「コンテンツの保持」設定してますか？
あと50GBくらいなら少なめの部類に入ると思います。AWSの場合、EBSは料金高いのでS3を検討してください。

スパムが大量に新規登録してきた

先祖代々から続く呪いの可能性があります。まず登録を一時的に審査制にしてから他の対策を考えましょう。
自分の場合、新規登録画面にCloudFlareを使って画像認証入れています。やり方はネットに書いてあります。
すでに登録してきたアカウントの削除は、お気の毒ですが、リストから頑張って複数選択して消すしかありません。本家Mastodonが今後改善する可能性はありますが、本家ってスパム対策について消極的な感じはします。
Cloudflare画像認証は有事じゃなくても最低限入れたほうがいいと思います。

あとFedibirdでは完全招待制にしてますけど、あれもスパム対策として有効です。登録への敷居の高さはそれなりに考慮が必要です。

Misskeyの絵文字の一部が表示されない

本家Mastodonって、JPEGのカスタム絵文字には対応してないです（4.1.x時点で対応してなかったはず。4.2で対応してたらごめん。kmyblueは独自改造でjpeg対応してます）。
カスタム絵文字のファイルサイズも、Mastodonでは256KB（kmyblueでは512KB）という制限かかってます。対してMisskeyって、極端な場合は1MBのカスタム絵文字もあったりします。この上限を変えるにはプログラムいじる必要があるので、MastodonとMisskeyどっちかの開発者に殴り込みに行ってください。
あと、それ以外でも複数の原因があるようです（APNGまわり？）。そこらへんよく分かってないので他の鯖缶に聞いてください。
あとMisskeyのカスタム絵文字はいくらなんでも自由すぎます。横長絵文字がMastodon（kmyblue/Fedibird/その他ごく一部以外）で正常に表示できないのは仕様です。カスタムCSSいじればいけるかもしれませんが。

全文検索ができない

一番多いのが、サーバーにElasticSearchが入ってないケースです。インストールしてください。なおkmyblueではElasticSearchの辞書の置き場所を特別に指定してますので、kmyblueのドキュメント見てインストールしてください。
あとはElasticSearchが落ちてるケースです。この場合は500エラーが出ます。ElasticSearchってメモリとおはぎをよく食べますので、半端なスペックだと落ちる場合があります。ていうか落ちた。sudo systemctl status elasticsearchで今動いてるか確認します。

ElasticSearchはサーバーへの負荷がものすごいです。メモリを食います。あるもん全部食います。可能ならMastodonとは別の機器にインストールしたほうがいいです。

まとめ

あとはこれ読んでください。うちみたいなMastodon始めて１年未満の新参管理者が急いで書いたような記事よりもよっぽと有用だと思います。長年運営してよくある問題ってのがまとめられてると思います。

https://blog.noellabo.jp/entry/mastodon-admin-checklist

あとUbuntuにvi以外のテキストエディタは存在しません。

鯖缶工場

やっぱりね、ここに書いていないトラブルもたくさんあるわけです。保守って幅広いので。
Mastodonには、鯖缶工場っていうDiscordチャンネルがあるらしいです。そこをインターネットのどっかで見つけて参加して質問すると、有用なお返事がもらえます。

【参考】サーバーthreads.netと連合することによる負荷

※あくまで筆者自身の見解であり、事実と異なる場合があります
※この節の大部分は１２月１３日（ThreadsのFediverse接続の前日）に書いています

これあくまでMastodon・kmyblueの話であってMisskeyの場合は一部若干事情変わるかもしれませんが（そこらへんはMisskeyくわしい人に聞いて）、最近何かと話題になっているThreads。これ、もうすぐActivityPubに接続しますよという話がある。Threadsは、今はもう空っぽになったらしいとはいえ人が大変多いサーバーです。ここと連合で繋がってしまったら、『Threadsと連合することによって自分のMastodonに過大な負荷がかかるんじゃないか』という懸念、これ自分としては『サーバーの規模やつながりや状況やおはぎによる』としか答えられないです。もっと詳しく言うと、『人の多いサーバーほど重くなりやすいが、人の少ないサーバーはそれほどでもない』『ただし投稿が広く拡散され大量のリアクションが集まった場合は察して欲しい』になります。

どうして結論が出せないかについて、MastodonとThreadsの連合処理を複数に分解して考えてみます。
なお以下の話は、Threadsに限らずfedibird.com、misskey.ioなどそこそこ大きいインスタンスとの連合にも使えます。

MastodonからThreadsにいるフォロワーへの投稿送信・・・例えばあなたのMastodonに２つのアカウントがあります。Threadsのことはいったん忘れてですね、アカウントAには20人のフォロワー、アカウントBには100人のフォロワーがいます。フォロワー５倍ですね。ではどっちで投稿したほうがサーバーへの負荷重いんでしょうか？答えは『この情報だけではわからない』です。
もしフォロワーがローカルユーザーだった場合、ローカルのユーザーへの配送処理（ホーム／リスト／アンテナタイムラインへの追加、ストリーミング、通知など）がかかります。対してリモートユーザーだった場合、リモートサーバーに１回送って終わりです。
では質問を変えます。アカウントA、Bともにフォロワーの人数はそのままで、全員がリモートフォロワーだった場合、どっちで投稿したほうが負荷重いんでしょうか。答えはさっきと同じ、『この情報だけではわからない』です。
極端な例えになりますけど、アカウントAのフォロワー２０人全員お一人様サーバー、アカウントBのフォロワー１００人全員同じサーバーの人だったら、アカウントAのほうが重いです。
Mastodonは原則としてサーバーの数だけ投稿を配送しますので、アカウントAは２０のサーバーから見られてるので２０回送信リクエスト（inboxへのPOST）が発生します。対してアカウントBはフォロワー１００人いますが全員同じサーバーなのでサーバーは１つだけです。送信リクエストは１回だけになります。
よって、１つのアカウントにThreadsのフォロワーが１００人いようか１０００人いようか１万人いようか、送信リクエストは同じ１回です。このへんはThreadsのユーザーが莫大でも関係ありません。（もっともこのレベルまで行くと、フォロワーをサーバーごとに分類する（正確にはshared_inbox_urlをまとめる）処理のほうが重そうな気はしますが）

Threadsのフォロイー（フォロー相手）からMastodonへの投稿受信・・・Threadsのアカウントをフォローした場合、そのTのアカウントがなんか投稿すると、自分のサーバーのinboxへ投稿送信リクエストが入ります。ThreadsもおそらくMastodonと似た送り方を採用すると思いますので、さっき説明したとおり、状況に関係なくThreadsからうちに来るリクエストは投稿１つあたり１回だけと仮定します。おはぎくれ。
ところで問題は、Threadsのアカウントが大変多いことです。アカウントが多いということは、相当数の投稿が予想される。そして自分のサーバーからThreadsのアカウントをフォローする人がもし多ければ、それだけ大量のリクエストや自分のサーバー内への配信処理が発生することになります。そりゃ重くなりますわ。でもこの話全体の結論は冒頭に書いた通り『分からない』なんですよね。何でこれで分からないになるか、それを説明します。
実はThreadsが出る前にも、規模はThreadsに及ばないですが、規模の大きいサーバーというのは存在しました。mastodon.socialは月間アクティブユーザーが現時点で２５万。おそらくmisskey.ioより多いんじゃないかと思います（misskey.ioは日別しか公開してませんがおそらく月間は日別の２～３倍くらいかな？多めに５倍と見積もってもmastodon.socialよりめちゃ少ないです）。でもそこのことを誰も話題にしない。誰も気にしない。mastodon.socialって英語圏のサーバーというイメージがあって、日本人にとっては近寄りがたいです。自分のサーバーからmastodon.socialのアカウントをいくつフォローしているかって、片手で数えられるくらいかもしれません。この場合、mastodon.socialが自分のサーバーにかける負荷はほとんどありません。連合上に１万でも１億でも１兆でも、どんなに人数の多いサーバーがあったとしても、自分のサーバーと繋がらなければゼロなんですよ。
でもThreadsは日本国内でも結構話題になっている。多数の日本人が登録している。朝日新聞なども活動されておられる。『日本人がフォローしたいと思えるような魅力的なアカウント』がThreadsにはたくさんあるんです。だから必然的にそことのつながりが濃くなってしまいます。これは自分のサーバーにとってインパクトになります。
負荷が多少増えることは確定に等しいです。ですが、もしThreadsのアカウントを１０や１００しかフォローしていないのであれば、他の普通のMastodonやMisskeyとつながるのと同じ。Threadsのアカウントを１万もフォローしていればさすがに重いですが、例えばMastodonやMisskeyやめてThreadsに来た人がそれに含まれていれば、それだけ相殺されます。リクエストって投稿単位で発生するので、投稿なければゼロです。
要は、これからThreadsにどのようなアカウントが集まるか。それに尽きます。

自分の投稿がブーストされてThreadsに回っていった場合・・・ActivityPubでブーストって、Announceという名前で回ってくんです。このAnnounceというActivityには、ブーストされた投稿のURLだけが載ってる。受信側のサーバーは、そのURLを自分のサーバーから取ってきてます。なので、自分とは異なるサーバーAが自分のサーバーの投稿をブーストして、それをサーバーBにいるフォロワーに送った場合、発生するリクエストは以下のとおりです。
　１．サーバーAからサーバーBへブーストのActivity
　２．サーバーBが自分のサーバーへブーストされた投稿を取得
自分と無関係のサーバーが自分の投稿をブーストしただけで自分のサーバーにもリクエストかかるわけです。
ではThreadsが絡むとどうなるか。結論から言うと、拡散によってダメージを受ける可能性があります。これまでのFediverseでは、投稿はTwitterほど拡散されなかった。コンテンツ力とかそういう次元ではなくて、Fediverse自体の人口が少なかったんです。でもThreadsには大量の人がいます。
もしThreadsがMastodonと同じ実装をしていたらという仮定付きになって申し訳ないんですが、Mastodonの実装ではブーストされた投稿がすでに自分のDBにあったらそれを読みます。なので、Threadsから自分へ投稿内容の取得リクエストが発生するのは最初の１回だけ。あとは、Threadsのアカウントをフォロワーに持ったあちこちのアカウントが何回あなたの投稿を転がそうが、あなたのサーバーがその回数だけAnnounceを受け取ること以外に影響はないです。
これはあくまでブーストにかかる負荷ですから、多くの人に拡散されて大量のお気に入りが集まったときまでは考慮してません。ブーストされるような投稿はさそ価値があるでしょうからThreadsのほうから多くのお気に入り、便乗ブースト、返信、フォローが集まります。それぞれ、Like、Announce、Create、Followという立派なActivityです。Followに関しては、自分のアカウントに鍵がかかっていなければ別途自分から送るAcceptも発生します（すでに説明しましたが、ThreadsからのFollowが大量に増えたところでその後の投稿配送の負荷に影響はありません）。一般論でいって、ブーストされる＝価値ある投稿である＝多くのリアクションがつく＝負荷が高まる、と言っていいです。ただ実際の負荷については、Threadsでどんな人が何人くらい見るか次第にはなると思います。
とここまで書いたのですが、Like、Announce、Followの負荷はCreateより低く（ただしリアクションした相手を自分のサーバーが認識していない場合はアカウント情報を取りに行くため、そのぶん負荷も上積みになる）、そのCreate（返信）も他のリアクションと比べるとほとんど来ないでしょうから、負荷はたしかに上がりますがよほどのことがなければ影響は限定的だと思います。

Threadsの投稿がブーストされて回ってきた場合・・・自分からThreadsに取りに行くところが違うだけで、考え方はさっきと同じです。
あなたが他のサーバーのアカウントを複数フォローしている場合、それらがThreadsの投稿をいくつもブーストしてくると、それだけThreadsへのリクエストが発生します。あなたがフォローしているアカウントがどのような行動を取るかによって、計算量が大きく左右されるでしょう。しかし現実的に考えて、Threadsにある大量の投稿が全部ブーストされるわけはないため、これも影響は限定的と考えられます。

ThreadsによってActivityPub全体が活発化した場合・・・MastodonもMisskeyも、Twitterのように５０万１００万もフォロワーいますっていうアカウントはめったにないです。それはFediverse全体の人口がTwitterよりも大幅に少ないからです。
でももしThreadsがActivityPub接続すると、Fediverse全体の人口が急増します。２倍や３倍ではすみません。そうなるともちろん、Fediverseを流れるアカウント数、投稿数、ともに激増し、それだけ自分のサーバーから外部へとぶフォローリクエストも大幅に増えます。
このFediverseの話題は現在のところ、技術に詳しい人の間で回ってるのみで、一般で話題になっているようには見受けられません。ですがFediverseは知らなくてもThreadsは知っているという人も多く、これからThreadsに復帰したり新たに登録したりするアカウントも増えてきます。Fediverseの人口の増加スピードが上がることを意味します。タロットカードの大アルカナで「死」というカードがありますし、小アルカナで「ソードの１０」というカードがあります。どれも死からの再生、生まれ変わりを示します。それと同等、Fediverse全体は大きなインパクトを受け、歴史の転換点を迎えることになるでしょう。
Threadsひとつをドメインブロックすればいいのではなく、ActivityPubの概念に目覚めた多くの人々がMastodonやMisskeyにアカウントを作るかもしれません。スパムも増え、おそらく正常な投稿の数十倍の勢力を誇るでしょう。Threadsはテレビで報道されるほどのその知名度をもって、ActivityPubという概念を一般化するかもしれないのです。
これまで小規模サーバーがそのスペックで成り立っていたのは、Fediverse全体の人口が絶対的に少ないからです。Fediverse全体の人口やおはぎが増えれば、その前提は崩れるかもしれません。
ただ、これは希望的観測も入っているかもしれません。実際どうなるかはちょっと自分には予想が難しいです。ThreadsはFediverseとの接続について、プライバシーを気にする人向けに、アカウント設定でオプトアウト可能にする可能性もまだ残っています。ですがもしThreadsが原因でFediverse全体が盛り上がるようなことがあれば、たとえthreads.netをドメインブロックしていても、多くのサーバーが負荷の影響を受けることになるでしょう。

存在しないサーバーに対してドメインブロックすることもできます

現在threads.netはActivityPubに接続しておらず、当然Mastodonは認識しません。でもMastodonには『現在存在しないサーバー』に対してドメインブロックを行えますので、操作方法を説明します。

（※注：この節は１２月１３日に書いたものです。Threadsが限定的にMastodonと繋がり始める前日でした）

モデレーションの「既知のサーバー」画面の右上に「ドメインブロックを追加」があります。ここから、ドメイン名を「threads.net」と手打ちして作成することができます。

できれば一度連合してみたほうがいいと思うんですが、特にスペックに自信のないサーバー、他の様子を見てから繋がりたいサーバーに関してはこれもう仕方ないと思います。

Threadsからブロックされた場合の表示

ThreadsがFediverseに部分的に接続したようですが、一部サーバーでThreadsと接続できないという話を聞いています。おそらくあちら側のセキュリティルールが厳しいか、IP単位で厳しい制限をかけているものと推測します。しばらく待てば接続できるようになったという報告も、自分のサーバーを含め複数確認しています。

さて、ここではあなたのサーバーがThreadsと接続できない場合の挙動を説明します。Threadsに限らず、特定のMastodonサーバーからIP制限をかけられている場合にもこれは適用されます。ただドメインブロックされているだけでHTTPS接続自体は可能である場合、一部挙動が変わる場合があります。

まず、接続ができません。「@mossori@threads.net」で検索しても結果は表示されません。サーバーによっては503エラーが出ます（この503エラーの具体的なスタックトレースなどはログに出力されないようです）。
なので当然、アカウントをフォローしたり、投稿にリアクションしたりすることはできません。

また、上で書いたとおり、他のサーバーのアカウントがブーストしても、あなたのサーバーに流れることはありません。ブーストされた投稿は、あなたのサーバーがThreadsへ直接取得しに行くからです。

この問題は、特にスパムへの対策に対して消極的なVPS・クラウド業者のほうで発生しやすいのかもしれません。まだ接続できない条件が十分に確認できていないのでこれ以上は何とも言えないですが、自分のサーバーはAWSのEC2を使っています。