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してストリーミング経由でブラウザ・クライアントに流す。

そういう感じ。

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