iovcとiopsがよく脳内で混乱する（制限されてんのかな？ ……じゃなかった）
のえる(@noellabo@fedibird.com)の投稿
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator（開発者の一員）です。また、独自機能を盛り込んだFedibirdを管理・開発しています！
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
@brsn おや、何が起きてるんだろう。制限などはないです。ログインしているセッションが切れたりしてるかな……。
@Panta fedibird.comで参照すると、[参照]リンクのパブリックページでfedibird.comがキャッシュしているコンテンツを外部公開できるので、死んでるサーバの投稿をみんなに見せられるという技がある。
このアカウントは、notestockで公開設定になっていません。
Fediverseにカレーが遍在しているのであって、fedibird.comに一極集中しているのではないのだ。 [参照]
iOS 16.4のβ2になったんだけど、PWAのMisskeyにログインできない問題とか解決してるし、MastodonのPWAがチカチカするのも再現しなくなってる気がするな……。
mastodon.social、Kubernetes構成に移行したみたいだねえ。大きいトコロはみんな大変だ。 [参照]
#fedibird #fedibird_info ブックマーク、お気に入り、絵文字リアクション、自分限定ホームで、メディアのみ表示、メディアを除外設定をした際にページング（初回読み込み以降の追加読み出し）が正しく機能しなかった不具合を修正しました。
@Satis データベースの拡張が限界を迎えて、抜本対策に追われているのじゃ。
メンテナンス終了時刻は未定なのじゃ。
@Soja 自分に合うFediverseとの付き合い方が見つけられたら、私もここまでやってきた甲斐があるというものです！
Daily新機能ぐらいの勢いで手を動かしていきたいけど、そんなに手が早くないんだよねえ。
モデレーション機能とか増やしても誰もわからないしw
前にEugenさんが妥協案として出した仕様と同じような感じかな？ ちょっと追えてないから事情わからんけど。
BotにBotフラグつけるかどうかは登録者の判断だけど、モデレーションによる変更（強制）はできた方がよさそうねー
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
新方式のデータベースをぶつけ本番で動かすと、不具合起きた時にロールバックするか、壊れたままなおしながら動かすか、ってなるので、まあ茨の道。
@ars42525 通数が馬鹿にならない奴である。まあどのみち新しいログインあったよというメールは送るんだけどね。
タイムライン幅いっぱいに本文表示するようになって（v4）アクションのボタン表示領域だけは広くなった
fedibird.comの招待URLです。
https://fedibird.com/invite/osjwGt9q
現在、fedibird.comは招待URLがないと登録できません。
このURLは、100人登録したら無効になります。人数オーバーの際は他の招待URLをご利用ください。
これもう20人枠しかないけど
QT: https://fedibird.com/@noellabo/109940699428806967 [参照]
たかし先生のソフトエロな絵、ソフトエロっていうのとは別に、魅力的な絵を描く人だな、っていうところからファンが広がっていくと思う。うまく説明ができないのだけど、とても良い。
@Satis 「なんかよくわからないけど、アカウント作ってみたらひどいところだった」ってミスマッチにならないように、ほんのちょっとだけ考えて登録してもらったらいいんだよ。
誰の招待コードで登録したかはわかるので、インフルエンサー的な人が沢山連れてきたらそれもわかるし、みんなでちょっとずつ責任を感じてもらうんだ。
勢いをコントロールしやすいしね。
マッチしそうな人を見つけたら、誘ってあげてね。
ひとりひとり、みているものが違うんだよ。ほんとうは言うまでも無いんだけど、Fediverseのタイムラインは、それをかなり明確にしてる。
昨日の対策ですが、絵文字リアクションのストリーミングで関連の負荷が約50%削減、アクティブ期間の短縮でfan-out負荷が23%削減という試算となっています。
リアクションのストリーミングは、Fedibird自身の絵文字リアクションに起因するものもさることながら、misskey.ioをはじめとするMisskey系サーバからやってくるもの起因もかなりの件数にのぼります。
misskey.ioが健在な一昨日でいうと、misskey.ioから45,599件の絵文字リアクションが届いており、misskey.cf, misskey.artがそれぞれ2,200件、fedibird.comは3,500件というところです。全体では83,274件ありました。
これを、これを600人から300人へのストリーミング配送に減らしたという具合です。
ちなみにトップは圧倒的に村上さんで、こちらに届いているリアクションだけでトータル6,679件あります。
fan-out負荷というのは、投稿をフォロワーのホームやタイムラインに挿入する処理の負荷のことで、
Mastodonではアクティブとみなしたユーザーのタイムラインに挿入処理をします。
これを、10,876人から8,392人分に減らしたという計算です。
QT: https://fedibird.com/@noellabo/109947845940427990 [参照]
負荷のピークはTwitterが調子が悪かった時間帯で、それがなおってきて、後にmisskey.io陥落して、という順番で、みるみる負荷が落ちていったのですが、
ともかくこの対策は効果が大きく、ピーク時のCPU 300%ぐらいの負荷が90%ぐらいまでは落ちました。
このほかにも、Fedibirdは通常のMastodonに比べると重い機能や負荷が高めになる設定値になっている箇所があるため、そこを最適化ないし制限していくことで、負荷を軽減する余地はまだあります。
まあ、必要に応じて対応していきますので、よろしくお願いします。
@Tommy のえすきーは4CPU 4GBのサーバです。misskey.cloudが6CPU 8GB。
前の人数超過したんで、もう100枠用意したよ。
fedibird.comの招待URLです。
https://fedibird.com/invite/JBH3GpKA
現在、fedibird.comは招待URLがないと登録できません。
このURLは、100人登録したら無効になります。人数オーバーの際は他の招待URLをご利用ください。
@yukiyalien 
「殴らないよー」
いろいろFedibirdでは解決できるように仕込んでるけど、肝心のMisskeyや、Mastodonの別のリアクション実装などでは徹底できないんだ。
たとえばFedibirdで投稿のjsonをとると、
emojiReactions: "https://fedibird.com/users/noellabo/statuses/109950820214581483/emoji_reactions",
って情報がとれるのね。ついてるリアクション（アクティビティ）の一覧。
これはMisskeyではとれないんだ。公開されてない。
だから、Fedibirdだけでネットワーク構成されてれば、投稿をfetchすればリモートの絵文字リアクションを完全把握できるんだけど、Misskeyではできない。
取りこぼしなく個々のEmojiReactionを受け取るしかないのだが、全部はこない。
@aqz 全件フラットでくるから、集約するアルゴリズムはそれぞれって感じよ。
ウチはcontentが同じなら合算しちゃう。
@aqz LikeかEmojiReactアクティビティのコレクションだからね。ActivityPub的な表現。
@rk_asylum このお知らせ部分の実装があったから、投稿にも流用されていまに至ってるんだけどねー。
@rk_asylum クライアントアプリが未対応とか、お知らせだけで済まないっていうところがまたつらい。
まあ利用率の低さだよねー。鯖缶がしらない！
@aqz そうなんだよなー。
REST APIの方は、さっきのと同じデータこういう表現でDBに計算済みキャッシュのjsonb持ってて、提供してる。
まあこれもでかいんだけど……。
クライアントアプリは全部情報揃った状態で受け取るから、実装が容易なんよね。
誰がつけたリアクションが含まれてるのかの情報も入ってるので、相手をミュート・ブロックしてる場合は除外するとか、いろいろやってるのよ。
@aqz さらなる絵文字リアクションの嫌がらせ対策とかも検討してるのよ。そのへんはそれぞれでいいと思う。
安全考える人はこっち使うだろうし、そんなの気にしねえって人はMisskeyで暴れるって感じで。
@aqz こっちでなるべく事例つみあげとくから、要望がでてきたら検討してみては。優先事項じゃないと思う。
@anqou 論理削除で済ませるのは条件があって、モデレーターが削除したとき（誤判定の取り消し30日保存デフォ）とか、論理削除じゃないとダメな場合。
通常は最初に論理削除処理して素早く参照できなくして、そのあと物理削除して完全に消すよ。
@Robinyan 一番影響大きかったのはすまほん!!で取り上げられたことかなー。
しゅいろがGihyoに記事書いたこともあるだろうけど、タイミングが重なったのでは。
Googleも勉強熱心だな……
（村上さんのやらかしを検索してた）
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
の投稿
cosy@misskey.noellabo.jp
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
昨日の対策ですが、絵文字リアクションのストリーミングで関連の負荷が約50%削減、アクティブ期間の短縮でfan-out負荷が23%削減という試算となっています。
リアクションのストリーミングは、Fedibird自身の絵文字リアクションに起因するものもさることながら、misskey.ioをはじめとするMisskey系サーバからやってくるもの起因もかなりの件数にのぼります。
misskey.ioが健在な一昨日でいうと、misskey.ioから45,599件の絵文字リアクションが届いており、misskey.cf, misskey.artがそれぞれ2,200件、fedibird.comは3,500件というところです。全体では83,274件ありました。
これを、これを600人から300人へのストリーミング配送に減らしたという具合です。
ちなみにトップは圧倒的に村上さんで、こちらに届いているリアクションだけでトータル6,679件あります。
fan-out負荷というのは、投稿をフォロワーのホームやタイムラインに挿入する処理の負荷のことで、
Mastodonではアクティブとみなしたユーザーのタイムラインに挿入処理をします。
これを、10,876人から8,392人分に減らしたという計算です。
QT: https://fedibird.com/@noellabo/109947845940427990 [参照]
負荷のピークはTwitterが調子が悪かった時間帯で、それがなおってきて、後にmisskey.io陥落して、という順番で、みるみる負荷が落ちていったのですが、
ともかくこの対策は効果が大きく、ピーク時のCPU 300%ぐらいの負荷が90%ぐらいまでは落ちました。
このほかにも、Fedibirdは通常のMastodonに比べると重い機能や負荷が高めになる設定値になっている箇所があるため、そこを最適化ないし制限していくことで、負荷を軽減する余地はまだあります。
まあ、必要に応じて対応していきますので、よろしくお願いします。
misskey.io落ちてると、ノートもそうなんだけど、絵文字リアクションのアクティビティが飛んでこないのよ。fedibird.comはそれでメッチャ軽くなってる。
日本のMastodon系でもね、mstdn.jpが不調の末に長期ダウンしたり、Pawooが数日停止したりしたときに、どんなに信頼をおいている大きなサーバでも落ちることはあるんだな、分散ってこういうときに頼りになるんだな、って再評価されて、これまでmstdn.jpやPawooのアカウントだけあればいいと思っていた人が、他のサーバにアカウントを作ってみて、見える景色が変わったりしたよ。
misskey.ioがそのうち力強く復活するとしても、それまでの間に少し旅をしておくといいよ。
まあ、misskey.ioにしかアカウントない人は、私たちの投稿・他のサーバの存在も見えないんだけどさ。Discordを見に行ってる人はなかなかの通だし、まあTwitterから様子を窺ってる感じかな？
のえすきーはローカルタイムラインのあるサーバなので、fedibird.comやmisskey.cloudとの使い分けとして、ローカルタイムラインを無視する運用ではなく、存在する前提で使っていただけるとありがたいです。
noellabo.jp系は個人サーバという位置付けなので、ひとまずは管理者がルールということだけ承知しておいてください。まあ、どのサーバでも共通する点としては、過干渉の禁止ぐらいかな。
以下はfedibird.comの簡易ルールだけど、こういうのはどこでも共通です。
- 日本の法律と社会規範に従った行動を心がけてください
- 不快や脅威に対してはブロック・ミュート・フィルターで距離をとってください
- 投稿する際は、適切な公開範囲・CW・閲覧注意を使用してください
今のところ4 core / 4GB memoryのサーバで動かしていますが、人が増えてもあまりスペックアップせず、ほどほどのところで登録を閉じる運用になると思います。
ローカルが機能しないほど人を増やしても意味がないですからね。
misskey.cloudの方は、他のサービスが一部同居していますが、6 core / 8GB memoryのサーバで、ある程度までは増強していってもいいと考えています。まあmisskey.ioみたいにはできませんけども。
Misskeyというプロダクトとしては連合はオマケ扱いかもしれないけど、私が運用する上で、連合は必須の重要事項です。
あちこちのサーバとつながって、リモートフォローでき、リモート先とのリプライやリアクションなどを通じたコミュニケーションが成り立たなければ、個人サーバ、小規模なサーバは成り立ちません。
ローカルのコミュニティを楽しみつつ、リモートも活用し、バランス良くやっていきましょう。
巨大サーバもロマンなんだけどね。
mastodon.socialやmisskey,ioがそれを追求するのは必然があって意味のあることで、やれる限りやっていくことで、ソフトウェアも鍛えられるし、運用の経験も積める。いつかダメになるかもしれないけど、そのときは他のサーバがあるから大丈夫。全員が無事でいる保証はしないけど、全滅はしないから！
SNSを必要としてる人なんて、人口の何パーセントいるでしょう？ そんなに、みんながみんな必要とするものじゃないと思うよ。
その中で、発信に使う人がどれだけいるか。
さらにその中で、自分の考えをもって主体的に使う人がどれだけいるか。
まあたいしていないだろうし、それでいいと思います。
主体的に使っているからといって殊更えらいことでもない（必要な人がそうしているに過ぎない）し、必要としない人が大多数だって、別に嘆くことでもないです。集団って、自然にそういう構成になるのです。
まあでも、そんな中で、お気に入りのサーバをみつけて、友人の一人でもみつけられたら、最高ですよね。
キャパシティー的にはmisskey.cfあたりに集合したらいいと思うんだけど、そんなのみんなひとりひとりで選ぶものだからね。
Misskeyいいけど、このノリずっと続けるつもりないし、ひょっとしてこれ疲れるな？ って思ったらFedibirdや普通のMastodonに移行してもいいんよね。この機会に試しておくといいかも。
