高負荷の中、予約投稿は予定通り投稿できたかな？ #fedibird
のえる(@noellabo@fedibird.com)の投稿
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator（開発者の一員）です。また、独自機能を盛り込んだFedibirdを管理・開発しています！
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
いま14万待機ぐらいだね。連合で5分、ホームで10分といったところ。どこまで遅延するか。
まあ処理が遅れても死にはしないので（そこが凄いところ）、そういうのも含めてお楽しみ下さいませ！ #fedibird
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
fedibird.comの遅延はサーバ内の連合やホームなどの配送だけで、外部サーバには即座に届いているので、遅延していると思ってヘンなこといわないようにね！ #fedibird
24万待機いってるね。
今回は何もオペレーションせずに、ただ見ているだけにしています。一応様子をみていますが、まあほっといても大丈夫でしょう。
遅延しないようにするサーバ構成にしたら大変だし、このままでいいんじゃないかな。
待機ゼロまで回復しました。0時前から遅延始まってたから、1時間半ぐらいかな。 #fedibird
あけおめ負荷試験、無事終了ということで簡単にご報告を。
Mastodonは、処理を小さな単位に分割し、それらを大量に処理する構造になっています。
具体的には、投稿の処理、お気に入りの処理、誰かのタイムラインに投稿が届いた処理、リモートサーバに届ける処理、などの小さな単位に分かれていて、これをdefault、pushなどの分野ごとにわけ、順番に処理しています。
処理の一つ一つを『ジョブ』と呼び、順番に処理する待機列を『キュー』と呼んでいます。
『Sidekiq』という仕組みがこれを支えています。
新年は、いつもよりたくさんのユーザーがアクセスし、新年の挨拶などを大量に投稿しますので、膨大な『ジョブ』が発生し、『Sidekiq』の『キュー』で長い順番待ちが発生します。
そうすると、タイムラインに5分前や10分前の投稿は届くけれども、いま自分が行った投稿は流れてこないなど、処理の遅延が発生します。
時間をかけて順番に処理しているだけなので、待ってさえいれば確実に終わるということでもあります。
こうした状況は意図して発生させることが難しく、地震のように予測できないものに比べ、新年は発生タイミングがわかっているので、貴重な機会になっています。
Mastodonを運用する上で、遅延を一切発生させない環境を整えることもできるし、混雑時にある程度の遅延が発生することを織り込んで通常時に快適な範囲に留めることもできます。
遅延させないつもりなら、非常時に処理能力を高められる仕組みにするか、普段から処理能力を高くしておけばいいのですが、いずれにしても余裕をもって予算投入する必要があります。
ですが、お金がたくさんかかりますので、fedibird.comではこの方針をとることはできません。
そこで、遅延を許容し、予算規模を拡大せずに乗り切る方針で臨んでいます。
結果として今回は、過去の実績やあらかじめ予想した遅延時間に対し、少ない遅延と短い時間での回復となりました。
遅延が発生したのはdefaultキューだけで、他のキューはほぼ遅延なく流すことができましたので、defaultキューの処理を省略したり効率化する方法を考えようという方向性が確認できました。
ご協力いただきありがとうございました。
あけましておめでとうございます。
昨年やりきれなかったこと、今年はやり遂げたいなあ。
大晦日の年越しそば。
そば、好きなんだけど、最近あんまり食べてないなー。かき揚げ入れてシンプルに。
お正月にしか食べないお雑煮。
もっと普段から食べたい気もするけど、特別なのもいいよね。
焼いた角餅、大根と小松菜、にんじん、鶏肉、そして八つ頭。醤油ベースのだし汁。
まぁ、八つ頭は普段は手に入らないかなー。
ところで、これ貫通幌（電車の車両と車両を繋ぐ通路についてる覆い）なんだけど、この横にずらっとついてるホックみたいなやつ、どんな機能のためについてるんだろうね？
内側から見えないけど、外側に何かつないでるのかな？
@osapon 天井部分を別につけといた方が、水が溜まらないとか雨漏りしにくいとか、機能向上するのかなー
@digi__tan でじたん、あけましておめでとう！ 今年もよろしく！
このでじたんかわいいねえ。
#fedibird Nightlyのアカウントを持っている人は、必要であれば遅延のないNightlyを使うといいよ。
#fedibird #fedibird_info 遅延が解消しました。
サーバを増強して対応しましたので、当面は大丈夫かと思います。
2023年の漢字は『投』、2023年の絵文字は『
』でした。 by notestock( https://notestock.osa-p.net ) #今年の漢字 #今年の絵文字
@chihato 年越しは訓練のつもりでやってましたが、すぐに本番という……。なめてかかってると結局足下を掬われますねえ。
#fedibird #fedibird_info 臨時増設したサーバ（2台）ですが、
そのまま使い続けると毎月6万2千円の増額になるので、ひとまず3日だけ維持します。3日で6,200円。それ以降のことは改めて検討ということで。
やぁ、misskey.ioのキュー凄いねえ。
いま、だいたいfedibird.comに11時間半（ほぼ半日）ぐらい遅れて届いてる……というかもはや止まっているような速度だね。
ActivityPubの投稿の連合は、投稿者のサーバ側が、各ユーザーのフォロワーのいるサーバに新規の投稿があったことを伝える（相手サーバにPOSTする）仕組みです。
misskey.ioで1,100万個の外部配送が待機中になっている状況で、少しずつしか消化されないので、どんどん遅れが増えていってます。
ちなみにmisskey.ioで投稿のURLを拾ってきてそれを検索すると個別にfetchできるので、配送を待たずに受け取ることはできます。
誰かがブーストした場合も、まだ受け取っていなければ個別にfetchするので、それも届いたりします。
村上さんや運営のアナウンスがあったら、他鯖でブースト（リノート）することで伝えて回るっていうことはできるかな。あとはあんまりやっても仕方ないか……。
ま、個人的に自分の投稿を流したいサーバにもって来ちゃうっていう使い方はできますけどw
これ、なんか手を入れる（メンテする）と一気に回復したりするので、単純な性能不足という感じじゃなくて、限界突破すると速度低下するとかそういう動きあるよね。
メモリが溢れてスワップ使い始めた時とか、ファイル開ける数超えちゃってリトライ連発のような、急な性能低下……どこかにボトルネックがあるような。（適当なこと言ってるので注意）
@takt_kr サーバ内は元気に動いているので、直接使っている人は普通に使えてるんですよ。ほとんど不便に感じてないという。
今日から仕事のみんなにお手入れ中の猫ちゃんを見せてあげよう
@takt_kr 外部配送に遅延が出ている旨はアナウンスされているので、解消できない何らかの事情があるんじゃないかと思います。
今日は臨時増設したサーバを減らそうかと思ってるんだけど、その前にmisskey.ioの未配送Activity流してくれないかなーw（そう都合良くはいかん）
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の配送の中には投稿だけじゃなくて絵文字リアクションとか投稿削除とかフォローリクエストとか承認とか、いろんなものが混じっているはずなので、投稿件数ではないよ。リアクションの割合は多そうだねえ。
いまのMastodonはリモートから配送されてきた投稿について、まずmastodon-web（puma）が受け取って、送信元の身元確認などを行ったあと、ingressキューに積む。
ingressキューで順番に処理していくんだけど、重複を無視したりして、新規投稿ならデータベースに投稿データとして保存する。
で、この保存した投稿データを内部で配送する。配送はdefaultキューに積んで、順番に処理する。フォローしている人のホームとかリスト、公開タイムライン（連合やローカル、ハッシュタグ）などに差し込む処理ね。
タイムラインに差し込まれるときに、redisのpub/sub channelsを使って、ストリーミングで繋がっているブラウザ・クライアントに結果を流し込む処理を行う。ストリーミングはnode.jsで動いている本体とは別のプロセスが処理するので、redisを仲介にして分離されている。
新規投稿じゃない場合、たとえば絵文字リアクションとかお気に入りなら、ingressキューのワーカーの段階でredisに通知をpubしてストリーミング経由でブラウザ・クライアントに流す。
そういう感じ。
で、もの凄く大量の処理が必要なときに、どこがボトルネックになるかってことを見極めるのが重要なのね。
fedibird.comの場合、ingressキューが詰まる現象というのは見たことがなくて、基本的にdefaultキューが処理仕切れなくて溢れるよ。
でも元凶はingressキューからdefaultキューに投げられる大量の配送処理なので、ingressキューをわざと絞り込んで、処理を遅延させて負荷を軽くすることはできる。
defaultの処理が追いつかなくて死にそうだったら、一時的にingressキューを止めちゃうっていう手もあるよ。
特定のサーバからの処理がキツければ、たとえばlow_priority_ingressキューを別に作って、そこで処理件数を制限しながらゆっくり処理する。で、pumaの方でmisskey.ioから来たActivityだけlow_priority_ingressに積むって感じ。
ま、fedibird.comでは今回、流れてくるものなら全力で処理する方針だけどね。
このingressキューは、mastodon.socialが大量流入で人口爆発したときに生み出されたやつで、これで調整するようにしたらしいよ。重くて動かない状態から、サーバ内動作はなんとかなる、というところまで回復させたりね。
こういう状況のときに、大きいサーバ……というか、リモートフォローの多い、生きたユーザーをたくさん抱えたサーバは、処理量が多くなるので、そこがネックになりやすい。
webもかなり重くなるので、リモート投稿を受け付けるプロセスと、直接の利用者がAPI利用するプロセスをわけておくと、APIの応答性を守れたりするよ。
あとmstdn.jpでよく発生していたと思うけど、負荷が高まってくると画像のアップロードがコケるようになるんだけど、これもバックグラウンド処理があるからで、分離しておくと安定した動作を確保できる。fedibird.comでやってるよ。
まあそんな感じで、多少ソフトウェアの機能を調整したり、どうプロセスを分割して、どこにどのぐらいのリソースを割くようにするか調整するなど、運用って工夫次第なんだ。
あけおめ負荷試験もそうだし、地震も、他鯖の詰まりもそうだけど、そういうのを貴重なデータにして、仮説を立てておいて結果を検証し、改良を重ねて知見を積み上げていくんだよ。
で、ボトルネックは改善すると別の場所に移動するので、あとはバランスとりかな。
misskey.ioはピーキーなサーバなので、そのへん難しいだろうね。構成変更したときにバランスが崩れやすい。ま、任せるしかないけど！ がんばえ！
misskey.io側の方針も出てないし、一応、もう一日だけ臨時増設サーバ維持しておきますかねー。 #fedibird #fedibird_info
このアカウントは、notestockで公開設定になっていません。
Fedibirdの運営費について（支援のお願い：銀行振込）
====
Open Collectiveを通じた支援ですが、スポットに限り、銀行振込できるようになりました。
クレジットカードを用いる場合とは異なり、指定の口座に振り込んで頂いたあと、こちらで受け取り確認を行ってから確定します。
可能であればクレジットカードで対応していただいた方が助かりますが、事情によりカードが使えない場合にはこちらをお試し下さい。
『スポット支援』の『支援する』ボタンから、デフォルトの1,000円やotherから金額を自由に設定いただき、プロフィールを指定後、支払い方法で「Bank transfer」を選択します。
振り込み先を案内するメールが送られるので、お振込時に参照番号を依頼人情報に追加してお振込下さい。振込手数料は御負担ください。
@aoetk 何も改善してないと思うな！ #misskeyio #fedibird
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
#fedibird #fedibird_info 地震による投稿量増加に対応するため1月1日16:41からサーバを臨時増設しておりましたが、先程解約しました。
また必要になったら確保します。
だいたい50ドルぐらいだったから、7,250円の臨時出費かな。
いやしかし、為替レートの影響大きいなあ。
ピークの10月分の請求と、いま請求されたばかりの12月分で、ドルは同額なのに、円だと8,364円も差があるぞ（安くなった）
去年の2月と10月を比較すると、18,443円も変わってるんだなぁ。
（2月から12月だと10,079円負担増ってこと）
@famisics 何らかの原因でパフォーマンスが落ちる問題があって、それが発生すると詰まり始めるって感じで、本来はスイスイ送れる能力はあると思うのよね。
たぶん、一度つまり始めたらどんどんつまる。
このアカウントは、notestockで公開設定になっていません。
@famisics ジョブキューに一度に突っ込んで大丈夫な限界件数みたいなのがあって、それを超えるとパフォーマンス落ちちゃうんじゃないかな。観測から言えるのはそのぐらいだね。
たぶん改善できると思う。
ありがとうー
これ（一部で）流行ってたよね、ポケットいっぱいあるやつ
https://www.nissen.co.jp/item/BHN0223E0001
@Midori_Aoyagi これで一命を取り留めるやつですね！！（取り出すとき不便な気がする！）
いったんゼロからスタートしたけど、もう33分遅れ、49万Waitingになってるね。大変だこりゃ（misskey.io）
@yuba 投稿毎に送る。1000回だね。
バルク送信（まとめ送り）はもちろん昔から話題に出るし検討もされるんだけど、それほどうまくいくわけでもないんだ。
いわゆるオーバーヘッドを減らす工夫としては、つながったままのセッションを使ったりするものはあるよ。
約200万Waiting、2時間遅れになってるなー。配送速度が著しく遅くなるの解せないなー。（misskey.io）
#fedibird #fedibird_info misskey.ioのジョブ処理を受け取ってる間＋α、遅延が続くと思いますが、温かく見守って頂けると幸いですー
スルーしようと思ったけど、ちょっとだけsidekiqワーカー数の調整をしました。遅延徐々に解消していくと思いますー。 #fedibird #fedibird_info
待ちくたびれたので、ちょっとサーバ足しました。解消したら止めますw #fedibird #fedibird_info
@minna_iiko キューが遅延していたのでメール送信も遅れていたと思います。届きましたか？ #fedibird
3日前のmisskey.ioの投稿流れてくるの、飛行機事故にざわめいているタイムラインが再現されてヤバイね。
@MaySoMusician ジョブキューに採用しているシステムの作りと使い方の問題で、一定以上のアクティブジョブがエントリーされるとパフォーマンスダウンする不具合で、対処可能なもののようです。たぶん解決してます。
もっと本格的に負荷が高まったらまた何か起きるでしょうけど、たぶん今回の問題は乗り越えたかなと。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
