鷲北 賢 さんはインスタンス mstdn.jp のユーザーです。アカウントさえ持っていればフォローしたり会話したりできます。もしお持ちでないなら こちら からサインアップできます。
鷲北 賢 @ken_washikita

#マストドン会議 でたくさんの方からいただいた質問が「ユーザが○○人なんですけどサーバのスペックはどれぐらいあればいいですか?」だった。正直分かりません! なにしろ普段見ているインスタンスも公開されている情報も5万~15万のものばかりなので…。

でも逃げてばかりではいかんので、逆にみんなに聞いたらいいんかな、と。どれぐらいのスペックでみなさんやってます? 個人的には「お一人様~100人ならVPSで充分」「500人までなら1core/1GBでギリギリやってけそう」「1000人までなら2core/4GB、dockerからは剥がさないとつらそう」「5000人だと4core/8GB? 8core/16GB?」「1万超えたら複サバ・クラスタ化・LB導入検討」ぐらいかなと思っています。

が、もっと小さくやってるよというご意見があったらぜひ伺いたいですw

· Web · 55 · 67

@ken_washikita さくらのクラウドさんで50人以内(1core/1GB)でやってましたが、1000人以上抱えられているインスタンス2つとやり取りが盛んになった時にエラー吐きまくったので2Core/
4GBにプラン変更しました。

@7_nana ありがとうございます。連合は確かに負荷増大に繋がるんですが、その度合いを測るのが難しいですよね…。ちなみにどんなエラーが出ていましたでしょうか。またスペックアップで解消されたのでしょうか?
自分の理解では、リモートフォローしている相手までであって、インスタンスのデータ丸ごとコピーしてくるワケではないので、それほどメッセージ数は大きくないと思っているのですが。

@ken_washikita 頻発したのは500エラーでした。鎖国したインスタンスと再度繋がった時に、ちょっと祭りみたいな感じになったんです。連合に沢山の投稿が流れて、同時に沢山のリモートフォロー・ブースト・ファボ(と通知)を受けました。全体的に動作が重くなって、500が出て止まって、また動いて、を繰り返しました。一時的なものだろうと思ってそのままにしていたんですが、ホームと連合で投稿の表示にタイムラグがあって、それがなかなか解消されませんでした。1.3.3にバージョンアップした時にかなり解消されたんですが、時々表示が重くなるのでスペックアップしました。それでとても快適になったと思っています。サーバ周りは素人で、体感でしかお伝えできず申し訳ないです。何かの参考になれば幸いです。

@7_nana 貴重なご意見ありがとうございます。負荷の原因の筆頭がメッセージのやり取り、toot数なんですよね…。なのでユーザがどのように振舞うのか(tootの数やフォローの数)で大きく変わってしまうので、予想が実に難しいというのがMastodon運営の難しさですよね。

@ken_washikita 素人なもので、ヒヤヒヤしていますw ただ、さくらさんのスタートアップスクリプトのお陰で貴重な経験ができています。ありがとうございます🙂

@ken_washikita マストドン会議参加してました。私が質問を受けた場合、コストパフォーマンスを考えると、VPSでスケールできる構成にしておくように回答します。(個人でたてる場合)
私はほぼお一人様ですが、さくらVPS1GプランでHDDとSSDを組み合わせて利用させていただいています。
(画像などの容量を考慮)

@Kou ありがとうございます。画像は割とキモですよね。最初はゆっくり増えるので後々で困ることになることも有り得ますよね…

@ken_washikita 画像の移行は大変ですので…。設計を考えたときは、接続数における必要メモリと画像の容量は分けてスケールできるようにしました。(画像の保存はコスパ優先でminioにしました。)
今後の話の参考になれば幸いです。

@Kou minioは使い勝手がよいですよね。ぬるかるさんもmstdn.jpで使ってますよ

@ken_washikita ぬるかるさんはオブジェクトストレージサービスを使わなかったのですね。
てっきり外部サービスに移行したものだと思ってました。

@ken_washikita ぼっちインスタンス mastodon.zunda.ninja はpumaとsidekiqに512MB RAMのマシン(Herokuの一番小さいdyno)、Streaming API (node)にもう1台512 MBのマシンで稼動しています。pumaのマシンはメディアファイルを受け取るとImagemagickがメモリをがっぽり使うので200MBほどスワップに行きます。この他、Redis (無料版)を使い、、1ヶ月強の稼動でPostrgesは60 MBほど、メディアファイルはS3に1GB強たまってます。費用は$16/月強くらい。github.com/zunda/mastodon/wiki ご参考まで。

@zundan ありがとうございます。工夫でコストを下げられている感じですばらしいですね。私は事業者なもんで、どうしても力で解決するクセがついてしまい最近いけませんw

@ken_washikita うちのインスタンスは現在ユーザ数350名ほどです。
構成として、さくらさんのクラウドでは
「1core 2GB 40GB」
でしばらくは大丈夫かなという印象です。

当初は「1core 1GB 20GB」でしたが
空きメモリ、SSDの空き容量に余裕がない状態でしたのでバージョンアップを期にプラン変更も実施しました。

CPU使用率は時々瞬間的に100%になって監視エージェントに引っかかりますので2coreいるかな?と思っていましたが特に不具合等はなく、CPUの稼働状況としては逼迫している印象はありませでしたので1coreで運用しています。

いずれ1000名規模になったらプラン変更による増強を考える必要があるかなと考えています。

@syumari ありがとうございます。discordでもお世話になってます。
私の予想は少々楽観的すぎましたかね、負荷はやはりtoot数に比例すると思うのですが、toot数とユーザ数の関係が、インスタンスによって全然違うので、分かりやすい指標をお示しできないのが実に難しいと感じています。

@ken_washikita 負荷という観点からで言いますと、ユーザがインスタンス内で行うTOOTや投稿よりも接続されている外部インスタンスとのリモートフォローや連合とのデータのやり取りがストレージ的にもコンスタントにデータを消費しますし、普段の運用的にもsidekiqに対する負荷のほうが影響が大きいように感じました。
外部インスタンスとの接続状況によって負荷のばらつきが各インスタンスで現れるのではないかと推測します。

@syumari リモートフォローの結果、リモートのtootやデータが外部インスタンスから流れ込んでくることになり、それが大きな負荷につながるということでしょうか。確かにユーザの数やtoot数よりも大きな影響を及ぼしそうですね。やはり様子を見ながらMastodonをチューニングするとか、サーバをスペックアップしていくことになるのでしょうね…

@ken_washikita 技術的な検証の上でのTOOTではなく、今までの運用監視している上で経験上での発言となりますのでその点はご了承ください。

いまのところmastodonのバージョンではインスタンス内で例えば全文検索、今までのTOOTを含む「ユーザアカウント削除など高負荷となる機能がないので、今のところは外的要因による影響が大きいと考えております。

ちなみにマストドンのバージョンアップの際にそれまでの負荷がほんの少し軽減しましたので、チューニングによっても変わるのだなと思います。

さくらさんのクラウドを今後も利用する前提であれば、今後のロードマップとしてはサーバ単体の増強はパフォーマンスを見極めた上で調整するとして

いずれはクラスタ、ロードバランスの導入、メディアファイルをオブジェクトストレージに退避分散、と言った構成にシフトすることが必要なのかなぁと漠然として描いております。

@ken_washikita gnusocial で済むインスタンスならgnusocialの方が圧倒的にリソース食わないですね

@zgock999 gnusocialは実は全然見たことがないんですが、LAMP環境でしたっけ。正直そちらのほうが何倍も馴染みがあるんで、流行るならそっちのほうがありがたかったですw RubyもPostgresも運用したことがなくてマジで泣けます

@ken_washikita  
はじめまして。
スタートアップスクリプトを活用して運用させて頂いております。

530人登録で8000トゥート越えのインスタンスですが、40GBは10日位でいっぱいになってしまいました。今は1TBで運用。2コア2GBでギリギリ回っている状況です。
夜になるとちょっと重くなります。

ただ、350人登録で1163トゥートのインスタンスは、8コア5GBにしても反応が遅いです。LTLが表示まで5-6秒も掛かっています…。2コア2GBだと10秒くらい掛かります。

@mangakantoku 40GBが10日間でいっぱいになるとはすごい量ですね…。画像キャッシュでしょうか。みなさんに話を伺ってみて、だいぶ過小評価していたことを思い知りました。ありがとうございます。

@ken_washikita  インスタンスは eigadon.net/ なのですが、画像はそれ程多くないかと思います。あっという間に40GBいっぱいになり、アクセスできなくなってしまっていたので、慌てて1TBにしました。1GB1コアも7日間くらいはスムーズに表示できました。まだ500名程度なので、3000名規模になってくると、コスト的にもどうなのかな....と心配している状況です。

@mangakantoku 一般的には、ローカルのデータやtootだけではそれほどのデータになる事はないと思います。可能性ですが、リモートの画像を持ってきているのではないかと想像します。最近のバージョンでは、リモートのインスタンスごとにキャッシュしない設定ができるようになってますから、それでディスクを節約できるかもしれません。

@ken_washikita ありがとうございます!4/22くらいにつくったので、V1.2.2くらいでしばらく運用しておりました。それが急速に容量がなくなる原因だった可能性があるのですね。今は最新バージョン1.3.3にしてあるので、ちょっとは節約できそうですね。マストドン管理画面上にはリモートインスタンス画像をキャッシュしない・・・という設定がなかったので、もし可能でしたら、どのようなコマンドで実行できるか・・・さくらのナレッジ等でご紹介頂けると大変助かります。マストドン関連のナレッジかなり熟読しております…。

@mangakantoku 恥ずかしながら、Mastodon自体の運営は経験がなくて、具体的にどうするとどうなるかが分からないのです。すみません。ただ、管理メニューにドメインブロックというのがありまして、そこに「メディアファイルを拒否」というチェックがあります。こちらでキャッシュを抑制できるようになるはずです。ただ、このとき「サイレンス」か「停止」を選ぶことになってしまうと思うんですが、副作用で連合TLに流れなくなったり、リモートフォローできなくなったりしてしまうと思います。このあたりを一度調べてみてください。

@ken_washikita アドバイスメチャメチャ助かります!盲点でした…。「メディアファイルを拒否」を実行して、どこまで反応速度が上がるか、検証中です。停止サーバをいくつか選んで実行したら、3-4時間処理が走り続けているようです…。結果はまたご報告します。

@hortense667 いろいろご意見いただいていますが、やはりインスタンスごとにそれぞれの事情があって、結構スペックを必要とするようです。

@ken_washikita コンピューターの歴史を見ると、CPUと帯域を使い切るものが世界を変えていくようです。意外に大変かもしれないけど、それがそのまま経済原則にはならず、コードの改善やインフラ自体の変化で変わっていくのが、この業界なんだと思います。というほどやさしくないですかね?

@hortense667 そういうことは今、GPUを使ったHPC、ML分野で起こっているようですよ。話題の将棋のソフトもうちのサーバファームを使っていただいていますし、そっち系の面白い話は別にできます。
Mastodonの場合、ソフトウェアが富豪的ということで、古典的な最適化で普通に早くできそうな気がします。