フォロー
あけおめ負荷試験、無事終了ということで簡単にご報告を。
Mastodonは、処理を小さな単位に分割し、それらを大量に処理する構造になっています。
具体的には、投稿の処理、お気に入りの処理、誰かのタイムラインに投稿が届いた処理、リモートサーバに届ける処理、などの小さな単位に分かれていて、これをdefault、pushなどの分野ごとにわけ、順番に処理しています。
処理の一つ一つを『ジョブ』と呼び、順番に処理する待機列を『キュー』と呼んでいます。
『Sidekiq』という仕組みがこれを支えています。
新年は、いつもよりたくさんのユーザーがアクセスし、新年の挨拶などを大量に投稿しますので、膨大な『ジョブ』が発生し、『Sidekiq』の『キュー』で長い順番待ちが発生します。
そうすると、タイムラインに5分前や10分前の投稿は届くけれども、いま自分が行った投稿は流れてこないなど、処理の遅延が発生します。
時間をかけて順番に処理しているだけなので、待ってさえいれば確実に終わるということでもあります。
こうした状況は意図して発生させることが難しく、地震のように予測できないものに比べ、新年は発生タイミングがわかっているので、貴重な機会になっています。
Mastodonを運用する上で、遅延を一切発生させない環境を整えることもできるし、混雑時にある程度の遅延が発生することを織り込んで通常時に快適な範囲に留めることもできます。
遅延させないつもりなら、非常時に処理能力を高められる仕組みにするか、普段から処理能力を高くしておけばいいのですが、いずれにしても余裕をもって予算投入する必要があります。
ですが、お金がたくさんかかりますので、fedibird.comではこの方針をとることはできません。
そこで、遅延を許容し、予算規模を拡大せずに乗り切る方針で臨んでいます。
結果として今回は、過去の実績やあらかじめ予想した遅延時間に対し、少ない遅延と短い時間での回復となりました。
遅延が発生したのはdefaultキューだけで、他のキューはほぼ遅延なく流すことができましたので、defaultキューの処理を省略したり効率化する方法を考えようという方向性が確認できました。
ご協力いただきありがとうございました。
#fedibird #fedibird_info