@protagonist なるほど、そういう理由！ たしかに！

ログボ

@kamisuke おはよう、王

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

@pacochi こないねそういえば……

@H2N_moon_ あと110人ぐらいだよ

@Tonbi_ko nginxは何でも良いけど、PostgreSQLを他のものに置き換えるのはすごい大変だよ。まあ必須。

@H2N_moon_ もちろん限定効果もあるとは思いますけど、結局登録開放しちゃうとどんどん増えちゃうってことなんで、少しずつ解放していかないと負荷バランス崩れちゃうんですよねー

@akasaka 全投稿を一つずつ削除することに比べると、アカウント削除はものすごく軽い処理になります。

関係するもろもろに伝えるのも、何回も繰り返さずに一度で済みますし、それぞれの内部で効率的に一括削除処理ができます。

@14ma16116 自分の行った絵文字リアクションを一括でみられるカラムがあるので、確認やキャンセルはそちらを！
https://fedibird.com/web/emoji_reactions

同人誌はフリートークが味わい深い（大好き）

@ymd Jujaは普通にエリックサウス行けばよろし

@ymd エンカウント率が上昇してる。間違いない。

@6u6_888 fedibird.comの人は誰でも招待状出せるので、実質いつでもアカウント作れますよ

ロラス「死者よりも、生者を気にかけてはどうだ？」

#fedibird とりあえず昨日の招待URLで400人増えてます。

のじゃ

Mastodonのように、たくさんのユーザーがいて、利用者が同時に使用していることが多く、短い投稿やそれに対する返信、リアクションなどが行われ、タイムラインに次々と新着投稿が流れるようなシステムは、

そのひとつひとつの処理（ジョブ）を実行するワーカーに分割し、必要に応じて順次処理していくことで、ユーザーの操作に素早く応答して結果を返し、たくさんの人が同時に利用してもスムースに流れるように工夫されています。

各サーバーは通常、このワーカーを遅滞なく実行できるだけのハードウェアを準備しているのですが、急激に投稿が増えたり、利用者が増えたりすると、処理能力が追いつかなくなります。（※ いつも処理能力不足のサーバもあります）

ワーカーは、処理が追いつかない場合、順番待ちの列を作って自分の番が来るのを待ちます。

列が長くなってくると、処理が完了するまで5分待つとか、20分待つといった状況になります。

そうすると、タイムラインに流れてくる最新情報が20分前だったり、お気に入りがなかなか反映されない、といったことが起きるわけです。

Mastodonでは Sidekiqと呼ばれるバックグラウンドジョブ処理システムを使っているので、『Sidekiqが遅延してる』などという言い方をします。

@saku_mio22 自由な入力を許しちゃうので、たとえば https: から書いてるとか、あと fedibird.com って書いてるとか！ #fedibird

Sidekiqによる、細分化されたワーカーを実行する仕組みは、ジョブの失敗をリカバリーすることに対しても強みを発揮しています。

あるサーバがメンテナンス中で接続できなかった場合、そのサーバに投稿を配送しようとすると失敗します。

このとき、投稿の配送をひとかたまりの処理として一回で実行するようになっていると、その時に繋がらないサーバにはもう配送するチャンスがなく、ダメだったら無視されてしまいます。

Sidekiqを使った仕組みでは、失敗したジョブだけを再実行することができます。

しかも、すぐにやり直しても失敗するので、失敗したら少しずつ間隔をあけていきます。

3時間後につながらなかったら、半日後にもう一回試す、というように、相手側が復旧するかもしれない時間を待つようにつくられています。

これにより、復旧したサーバにも配送が届くようになります。

あまりにも長くつながらなかったら、最後には諦めるようになっています。

連合を柔軟に運用できるようにするための、重要な仕組みです。

ジョブは短時間で実行できる単位に分割します。

そうしないと、ひとつのジョブが長時間占有しつづけることとなり、効率良く他のジョブを同時実行できなくなります。

また、ある処理を実行しているうちに、他の処理の影響で実行に失敗することも起きます。

たとえば、お気に入りしようとした投稿が、何かの都合でもう削除されているかもしれません。

ひとつのジョブが大きすぎると、こういう状況の変化に対応するのが難しくなります。

--

さて、リモートから誰かの投稿がやってきました。

この投稿者をこのサーバでは100人がフォローしているので、100人のタイムラインに投稿を流さねばなりません。

この時まず、リモートサーバから来たActivityの内容を確認するワーカーを実行します。投稿者Aの新規投稿であると解析されました。

次に、この投稿を各タイムラインに配送するワーカーを実行します。

やることの多いワーカーですが、公開範囲を確認し、公開タイムライン（連合、ハッシュタグなど）に流す処理、フォロワーのホームやリストに流す処理を行います。

このうち、フォロワーは人数が多いので、一人ずつのホームとリストそれぞれで100以上のワーカーに分割して走らせます。

難しいかと思いますが、なんとなくイメージできますでしょうか？

@yuicho blobcat系も、各所でオリジナルバリエーションが増えててそれぞれ権利主張があって制限事項などが増えていたりするので、もうなんとも。

統一された権利確認手段がないというのがシステム上の問題点で、運用だけで対応するの無理なところに来てるね。

変なインセンティブ設計するとダメになるよ。ホントに。

店内（店員同士）ではなんて呼ばれるんだろう、ガーリックシュリンプ