のえる @noellabo@fedibird.com

Fedibirdの運営費について（支援のお願い：銀行振込）
====

Open Collectiveを通じた支援ですが、スポットに限り、銀行振込できるようになりました。

クレジットカードを用いる場合とは異なり、指定の口座に振り込んで頂いたあと、こちらで受け取り確認を行ってから確定します。

可能であればクレジットカードで対応していただいた方が助かりますが、事情によりカードが使えない場合にはこちらをお試し下さい。

『スポット支援』の『支援する』ボタンから、デフォルトの1,000円やotherから金額を自由に設定いただき、プロフィールを指定後、支払い方法で「Bank transfer」を選択します。

振り込み先を案内するメールが送られるので、お振込時に参照番号を依頼人情報に追加してお振込下さい。振込手数料は御負担ください。

#fedibird #fedibird_info

misskey.io側の方針も出てないし、一応、もう一日だけ臨時増設サーバ維持しておきますかねー。 #fedibird #fedibird_info

こういう状況のときに、大きいサーバ……というか、リモートフォローの多い、生きたユーザーをたくさん抱えたサーバは、処理量が多くなるので、そこがネックになりやすい。

webもかなり重くなるので、リモート投稿を受け付けるプロセスと、直接の利用者がAPI利用するプロセスをわけておくと、APIの応答性を守れたりするよ。

あとmstdn.jpでよく発生していたと思うけど、負荷が高まってくると画像のアップロードがコケるようになるんだけど、これもバックグラウンド処理があるからで、分離しておくと安定した動作を確保できる。fedibird.comでやってるよ。

まあそんな感じで、多少ソフトウェアの機能を調整したり、どうプロセスを分割して、どこにどのぐらいのリソースを割くようにするか調整するなど、運用って工夫次第なんだ。

あけおめ負荷試験もそうだし、地震も、他鯖の詰まりもそうだけど、そういうのを貴重なデータにして、仮説を立てておいて結果を検証し、改良を重ねて知見を積み上げていくんだよ。

で、ボトルネックは改善すると別の場所に移動するので、あとはバランスとりかな。

misskey.ioはピーキーなサーバなので、そのへん難しいだろうね。構成変更したときにバランスが崩れやすい。ま、任せるしかないけど！ がんばえ！

fedibird.comの場合、ingressキューが詰まる現象というのは見たことがなくて、基本的にdefaultキューが処理仕切れなくて溢れるよ。

でも元凶はingressキューからdefaultキューに投げられる大量の配送処理なので、ingressキューをわざと絞り込んで、処理を遅延させて負荷を軽くすることはできる。

defaultの処理が追いつかなくて死にそうだったら、一時的にingressキューを止めちゃうっていう手もあるよ。

特定のサーバからの処理がキツければ、たとえばlow_priority_ingressキューを別に作って、そこで処理件数を制限しながらゆっくり処理する。で、pumaの方でmisskey.ioから来たActivityだけlow_priority_ingressに積むって感じ。

ま、fedibird.comでは今回、流れてくるものなら全力で処理する方針だけどね。

このingressキューは、mastodon.socialが大量流入で人口爆発したときに生み出されたやつで、これで調整するようにしたらしいよ。重くて動かない状態から、サーバ内動作はなんとかなる、というところまで回復させたりね。

いまのMastodonはリモートから配送されてきた投稿について、まずmastodon-web（puma）が受け取って、送信元の身元確認などを行ったあと、ingressキューに積む。

ingressキューで順番に処理していくんだけど、重複を無視したりして、新規投稿ならデータベースに投稿データとして保存する。

で、この保存した投稿データを内部で配送する。配送はdefaultキューに積んで、順番に処理する。フォローしている人のホームとかリスト、公開タイムライン（連合やローカル、ハッシュタグ）などに差し込む処理ね。

タイムラインに差し込まれるときに、redisのpub/sub channelsを使って、ストリーミングで繋がっているブラウザ・クライアントに結果を流し込む処理を行う。ストリーミングはnode.jsで動いている本体とは別のプロセスが処理するので、redisを仲介にして分離されている。

新規投稿じゃない場合、たとえば絵文字リアクションとかお気に入りなら、ingressキューのワーカーの段階でredisに通知をpubしてストリーミング経由でブラウザ・クライアントに流す。

そういう感じ。

で、もの凄く大量の処理が必要なときに、どこがボトルネックになるかってことを見極めるのが重要なのね。

Mastodonの管理画面でmisskey.ioのとこみると、fedibird.comの場合でフォロー合計46,237って出るんだけど、これは延べ人数。

たとえばしゅうまい君をfedibird.comからフォローしている人は1,186いるんだけど、しゅうまい君の投稿はそれぞれ1回だけmisskey.ioからこちらに送られてきて、それをこちらで1,186人のフォロワーに配る仕組みになっているのね。

だからユニークユーザー数も重要で、こちらは15,156。

15,156人分の溜まっている投稿を受け取って、46,237人に配るわけ。

fedibird.comの場合、フォロワーへ配る他に、各種の購読の処理が加わる。一般的なMastodonサーバでも、ハッシュタグのフォローの処理は加わる。

実際にmisskey.ioの15,156人から24時間にどのぐらいの投稿が配送されてくるのか調べると、1月2日の24時間でみると2,908人が行った29,354件の投稿になる。この数字も面白いね。

ちなみに、misskey.ioの配送の中には投稿だけじゃなくて絵文字リアクションとか投稿削除とかフォローリクエストとか承認とか、いろんなものが混じっているはずなので、投稿件数ではないよ。リアクションの割合は多そうだねえ。

今日は臨時増設したサーバを減らそうかと思ってるんだけど、その前にmisskey.ioの未配送Activity流してくれないかなーw（そう都合良くはいかん）

いま、昨日の12:00ぐらいの投稿が流れてきてるね。

ログボ

「サーバあれ」

これ、なんか手を入れる（メンテする）と一気に回復したりするので、単純な性能不足という感じじゃなくて、限界突破すると速度低下するとかそういう動きあるよね。

メモリが溢れてスワップ使い始めた時とか、ファイル開ける数超えちゃってリトライ連発のような、急な性能低下……どこかにボトルネックがあるような。（適当なこと言ってるので注意）

やぁ、misskey.ioのキュー凄いねえ。

いま、だいたいfedibird.comに11時間半（ほぼ半日）ぐらい遅れて届いてる……というかもはや止まっているような速度だね。

ActivityPubの投稿の連合は、投稿者のサーバ側が、各ユーザーのフォロワーのいるサーバに新規の投稿があったことを伝える（相手サーバにPOSTする）仕組みです。

misskey.ioで1,100万個の外部配送が待機中になっている状況で、少しずつしか消化されないので、どんどん遅れが増えていってます。

ちなみにmisskey.ioで投稿のURLを拾ってきてそれを検索すると個別にfetchできるので、配送を待たずに受け取ることはできます。

誰かがブーストした場合も、まだ受け取っていなければ個別にfetchするので、それも届いたりします。

村上さんや運営のアナウンスがあったら、他鯖でブースト（リノート）することで伝えて回るっていうことはできるかな。あとはあんまりやっても仕方ないか……。

ま、個人的に自分の投稿を流したいサーバにもって来ちゃうっていう使い方はできますけどw

UN_NERVからちゃんと配送されてきてるね

大宮氷川神社だよ！！

まぁでも、NERVの配送が遅延しがちなのはちゃんと対策とった方がいいよね。

#fedibird #fedibird_info 臨時増設したサーバ（2台）ですが、

そのまま使い続けると毎月6万2千円の増額になるので、ひとまず3日だけ維持します。3日で6,200円。それ以降のことは改めて検討ということで。

NERV側だと思いますー #fedibird

2023年の漢字は『投』、2023年の絵文字は『​​』でした。 by notestock( https://notestock.osa-p.net ) #今年の漢字 #今年の絵文字