のえる @noellabo@fedibird.com

ウイスキーコロコロ（そんなものはない）

@hanubeki こっちで寝た子を起こした感じ。Mastodon側の構造の問題ではないけど、構成によってインパクトが大きくなる感じかな。

このへんの流れみて。 [参照]

@Garry050 まず、Misskeyには全アカウントの削除をリモートに配送するような機能はないので（Mastodonにはある）、自分自身で削除した人以外は、ばすきー閉鎖時点でリモートに配送されたアカウントと投稿は残り続けています。Mastodonサーバでも、全削除を流す機能は使われないことも多いです。

Mastodonは、1日以上経ったアカウント情報は、何かそのアカウントにアクションしようとするとWebFingerからやり直して再取得するようになっていて、この時点でばすきーが410を返していれば、そのアカウントと投稿データを自主的に削除します。（削除のAcitvityが流れてきて削除するのではありません）

これが、リモートMastodonサーバそれぞれで、必要に応じて行われます。

何かアクションするというのは、たとえばアカウントを検索して内容を確認しようとしたり、フォローしようとしたり、といった具合です。

ばすきーから新規の投稿は流れてこないので、誰かが古い投稿から辿ったり、直接入力したりしない限り、そうそう頻繁に再取得アクションは行われません。そのため、このプロセスはゆっくりと進行します。

（200cmのアクスタもいいよ）
（もはやアクスタじゃねえ）

@Garry050 WebFingerでアカウントの問い合わせをした際に410を受け取ったら、アカウントを削除する処理が入るんだよ。

アカウントの問い合わせはいろんなタイミングで入るんだけど、前回取得してから24時間以上経過したアカウント情報はWebFingerから取得し直すよ。

何らかの原因でまとめてアカウント情報の問い合わせが入ると、その時に同時実行可能なキューのプロセス数だけ同時に削除処理が入る。これで、Fedibird(Mastodon)がメッチャ重くなった。

今回は、キューのプロセス数が多すぎたので減らして、トータルの負荷を減らした。

アカウント削除処理は重いけど、単独で実行する分にはたいしたことはない。メッチャ同時実行したらさすがに重い。

そういう感じ。

@risahana りんごおいしいよねえ

@risahana こん！ 🍎 🍎
今日はりんご？

買い換えようとしたとたん、今使ってるPCがご機嫌を損ねるって、良くあるよね！

（変異体の話じゃないよ！）

@sk_tak そういえばそれがあったね！！ セーフ！！ #fedibird

物理的には、各プロセスを実行する、複数台の実行環境に分割することができます。

処理能力の高いすごいサーバを借りてもいいし、小さなVPSを複数借りてもいいし、必要に応じてサーバ数を増減できる仕組みで動的に対応することも可能です。

PostgreSQLが大きくなりますので、自前設置ではなく、データベースサーバとして提供されているサービスを利用することで、安定動作やスケーリングの問題をサービス側で解決する方法もあります。めっちゃお金かかるけどね！！

PostgreSQLのデータベースは、基本的には一つしか設置できません。先程までに紹介した、たくさんのプロセスからのリクエストに、矛盾無く応じる必要があるためです。

PostgreSQLと各プロセスの間に、pgbouncerなどの交通整理をするプロセスを挟むこともあります。

大規模化すると同時にたくさんの接続とリクエストが来るようになるので、pgbouncerがそれぞれと接続しておいて、PostgreSQLとの接続は少数にしぼり、交通整理して順番に流すようにする役割を果たします。

リードレプリカという、読み出しのみを受け付けるサーバを設置することもできます。

データベースの複製を作って同期し、負荷分散を図る仕組みですが、書き込まれた内容が反映するまえに古い内容を応答すると動作がおかしくなるので、適用できる条件が限定的になります。

他にもいくつか冗長化する工夫は可能ですが、比較的高度です。

さて、ある程度の大きさのサーバになったら、これらのプロセスを複数用意して、よりたくさんの処理を捌けるように構成する必要があります。

nginxは、pumaが複数あるときには、処理を分散して引き渡す役割を果たします。応答してこないpumaがあったら他に割り振ることで、全体が一度にダウンしないようにする安全を担保する役割も果たしています。

sidekiqは、元々小さなジョブに分割された処理を実行するエンジンなので、たくさんあれば、それだけ同時にたくさんの処理ができます。

ジョブは種類でわけられているので、種類別のsidekiqを立てて、役割を分割することができます。

一番大事なローカルユーザーに応答する処理と、リモートサーバに配送する処理、リモートサーバから受けたリクエストに対応する処理など、別々にわけることで、負荷が高くなったときに、どの処理を優先し、どの処理に処理能力を配分するか、調整することもできます。

nodeは、redisの発行と購読の仕組みのおかげで、プロセスをたくさん起動しても、分散して対応することができます。

redisは、役割に応じて3つまで分割できます。最近は、redisの冗長化機能も使えるようになったようです。

ずっと内容を保持しておくデータは、PostgreSQLによるデータベースに保持されています。

pumaやsidekiqからの読み書き、nodeからの読み出しを一手に引き受け、矛盾のない状態を維持しています。

redisは、みんなのホームやリストタイムラインを保持したり、pumaやsidekiqの一時的なデータをキャッシュして高速化に貢献したり、発行と購読の仕組みをサポートして発行側と購読側を橋渡しする役割を担っています。

全体の役割分担は、だいたいこんな感じです。

このほか、オプションとして、全文検索の処理を行うElasticsearchを実行する場合もあります。

Elasticsearchがあると、そのサーバでは全文検索ができるようになるのですが、Mastodon本体と同じかそれ以上にヘビーなプロセスなので、余力のあるサーバにしか設置されていません。

Mastodonの構成の話。

ちいさなサーバは、VPSを一つ借りて、必要なプロセスを一つずつ起動して実行しています。

nginx、puma、sidekiq、node、postgresql、redisってとこかな。

nginxが外からのAPIアクセスや連合のリクエストを受け付けて、背後で実行しているMastodonのアプリケーションサーバであるpuma（mastodon-web）に処理を依頼します。

pumaは受け付けた内容を、その場で応答するものと、バックグラウンド処理にまわすものにわけます。

バックグラウンド処理は、小さなジョブに分割し、種類毎に順番待ちの列に突っ込んで、sidekiqプロセス（mastodon-sidekiq）が処理を行います。

pumaやsidekiqは、ユーザーにリアルタイムに知らせるべき内容をredisにpublish（発行）しておきます。

それをnode（mastodon-streaming）のプロセスが、現在subscription（購読）しているユーザーに対し、サーバ側からクライアント側に次々と流していきます。タイムラインがリアルタイム更新されていく仕組みです。

#fedibird #fedibird_info 大丈夫そうかな。

あらためて、昨晩からさきほどまで、サーバがつながりにくい・ほぼつながらない状態が続いていたようで、ご迷惑お掛けしました。

misskey.backspace.fm（ばすきー）のアカウント削除がたくさん流れていたのかな。これを大量に同時処理したことで、データベースが過負荷になっていました。

現在も削除処理は走っていますが、同時実行するプロセスを減らすなど構成をアレンジして、動作に差し支えないレベルに負荷を抑えられたかなと思います。

まだ様子見していますが、まあこれでなんとかなるでしょう。たぶん！

だいぶマシになった？

#fedibird #fedibird_info

ioで使われていない機能大喜利もう終わっちゃった？

さすがに重いね、スパムでひしめいてるサーバ。