Misskeyの遅いから「Node.jsやめる(Rustにする？)」というissueが紛糾 75
ストーリー by nagazou
紛糾 部門より
紛糾 部門より
あるAnonymous Coward 曰く、
Twitter代替サービスとしてユーザーが急増してサーバーコストが問題となっているOSSのSNSプラットフォーム「Misskey」で、「Node.jsやめる(Rustにする？)」というissueが登録されて紛糾しているようだ（はてなブックマーク）。
Misskeyのメインである「Misskey.io」のインスタンスは、個人運営であるが現在CPU1416コア、メモリ2.8TBという途方もないスペックで稼働しているという（まとめダネ！）。こうした状況を受けてか、3日に「Node.jsやめる(Rustにする？)」というissueが「Node.jsはパフォーマンス上の問題があるため。Goとかでもいいけど」というコメントと共に登録されたようだ。
issueにはタレコミ時点で94件のコメントが寄せられている他、Twitterなどでも話題となっていたが、メモリ消費が削減できそうやおもしろそうという意見がある一方で、そもそもMisskeyが遅い原因は本当にNode.jsなのかやスロークエリーを先に直すべきではと言った声、CPUバウンドなのかIOバウンドを測定してから検討すべきと言った声が多く寄せられる事態となっている。タレこみ子的にも、サーバー開発では性能対策は言語よりもまずDBやキャッシュというイメージがあるが、果たしてこの言語移行はありだろうか？
パフォーマンスだけが理由ではないです (スコア:3, 興味深い)
Issue作成した者です。Issueでも書きましたが、パフォーマンスの理由もありますが「Rustで書かれている」方が選ばれやすいという、マーケティング的な理由も大きいです。
Twitterなど見てても「なぜMisskeyはRustにしないのか」といった意見がよく流れてきますね
他にも単に面白そうだからという技術的な興味もあります。
Re: (スコア:0, フレームのもと)
それならあなたがRust版のSNSを作って公開すればよいのでは。
既存のソフトウェアにRustにしろと言って回るのではなく。
Rails製のMastodonなど、ActivetyPubを採用したオープンソースSNSは多数あり、その中で知名度のもっともあるMastodonと、
そしてこのMisskeyがよく選ばれているわけで、それなのにマーケティング的な理由で言語を切り替えはおかしいのでは。
もっと無名なオープンソースSNSからRustにしては？
Re:パフォーマンスだけが理由ではないです (スコア:2, すばらしい洞察)
謙遜して言わなかったのかどうか知らんけど「Issue作成した者」==「Misskeyの開発者」ですよ。自分のソフトをRustにしたいと言っていることに何の文句があるんですか。
Re: (スコア:0)
まあ、「Rustで書き直せ」的な荒らしIssueってOSS界隈ではそこそこ見かけるし、早とちりも分かる
Re: (スコア:0)
それはわからんでもないけど、失礼しましたって素直に言えないのがいかにもスラド民らしい。
Re:パフォーマンスだけが理由ではないです (スコア:1)
横からだけど、本物だとしたらその方ってMisskeyを作った方だし、むしろ「Rustに変更になるのが嫌ならフォークすれば？」って言える方の立場でしょ・・・
Re:パフォーマンスだけが理由ではないです (スコア:2, おもしろおかしい)
「その理論をつくったのは私なのですが～」をスラドで目の当たりにできるとは思わなかった
Re:パフォーマンスだけが理由ではないです (スコア:1)
私がMisskeyの作者で、私があのIssueを作りました。
Re: (スコア:0)
かっけー。いっちょかみさん瞬殺やん。
Re: (スコア:0)
Node.jsやめてDenoにしよう、というのならわかります(個人的見解)。
Re: (スコア:0)
バックエンドをJavaScriptにするメリットって何だろう。
サーバー負荷に苦しむ状況だとSSRなんて論外だし、特にメリットが思い付かない。
Re:パフォーマンスだけが理由ではないです (スコア:1)
ノンブロッキングIOとエンジンの高速化に血道をあげているブラウザ開発者のおかげでシングルコアを何も考えずにいい感じで使い切れる上、コンテナ化すればコアごとにプロセス立てて並列で回せるので簡単に性能を稼ぎやすいのはメリットだと思います。
Re: (スコア:0)
プロジェクト参加者がコードをかけるってだけじゃないかな。
よく知らない言語で書いたって禄なことないわけで。
プロジェクト参加者の技量で何を使うかって左右されると思う。
Re: (スコア:0)
フロントとバックで同じ言語が使えるというのは大きい。
学習コストは減るしロジックの共通化や移動もしやすい。
Re: (スコア:0)
それは JavaScript とかいうぶっ壊れた言語を使ってることで帳消しになってる気がする。
TypeScript しか使わないというなら多少ましにはなるけど。
Re: (スコア:0)
十数年くらい前はなんかNode.jsがスッゲー持て囃されてたよな
自分にはよく分からんかった
サーバーサイドもJSで書けるのがメリット？
いや、サーバーサイドは別の適した言語で書けばいいやんって
案の定、熱が冷めたらこういう話が出てくる
Re: (スコア:0)
syuilo さん Issue を思いついたやりたいことをとりあえず書くアイデア帳みたいに使うから、今回それに慣れてない外部の人の目に触れてしまったせいで検討不足とか何とか変に過剰反応されてしまった感ある
Re:パフォーマンスだけが理由ではないです (スコア:1)
匿名でって・・・スラドのアカウントを持ってるかどうかしらんけど、持ってなくてもこのコメントのためにわざわざアカウント作らんでしょ
Node.jsは流行っていない (スコア:0)
確かにNode.jsはイケてない
Re: (スコア:0)
利用者は実装が何かなんて気にするの？
Re: (スコア:0)
利用者というか開発者に対してじゃないかな。
絶対的な開発者の数で言えばNode.jsの方がいいだろうけど、OSSに参加してくれそうな開発者はRustの方が多そう。
OSSじゃないけど開発者への受けが良いから.NETからGoで書きなおしてますって会社知ってるけど、逆に経験者の採用は苦労しているみたいね。
Re: (スコア:0)
>面白そうだからという技術的な興味
コレ大事
>言語よりもまずDBやキャッシュ
DB構造がちゃんとしてればDBMSのキャッシュでIOも極小になるけどね。
別途キャッシュ持つとデータ二重管理で同期やら整合性で面倒な面も。
Re:パフォーマンスだけが理由ではないです (スコア:2, 興味深い)
むかーし、自社の DBMS を SQLServer だと遅いから ○iRDB に変更したらどうかという馬鹿みたいな提案（ごり押し）があって、
アホな人が全く同じクエリを何回百回も投げて、○iRDB ならこんなに速くなりますとか言ってたことがあったなあ。
まあ、確かに接続ユーザーが一つしか無い状態で同じクエリが投げられたら、諸々のチェックをスキップして
同じ結果を返せばいいんだから、その点では ○iRDB（もしくは ○iRDB のミドルウェア）の方が賢いとは
言えるけど、現実ではそんなことないんだから、そんな特殊処理入れるより、全うに性能上げる方がいいよなあ。
なお、毎回違うクエリを投げるようにアドバイスしたところ、無事遅くなった模様。
Re:パフォーマンスだけが理由ではないです (スコア:2)
似たような事あったなぁ
若いとやりがちなことってことか
メイン貢献者の意見まとめ (スコア:3, 参考になる)
趣味なんだから貢献者のモチベと経験が重要で、ここやIssueにいっちょかみしに沸いてくる外野なんてどうでもいいよね
過去1年間のコミット数を見た感じ、メイン貢献者はこの4人かな...
| コミット数 | ユーザ名 | 賛否 | Rust経験 |
|---------------|--------------|------------------------|----------------------|
| 1,901 commits | syuilo | 提案者 | かじった程度か？ |
| 259 commits | tamaina | 自分が書けないから反対 | 書けない |
| 147 commits | acid-chicken | 賛成 | そこそこ触ってそう？ |
| 71 commits | saschanaz | 元々Rust移植版を開発中 | Mozilla社員、強そう |
技術的解決は楽しいけど、まずは原因調査よね (スコア:1)
何が遅い原因なのかを明確にしてからじゃないと、言語やフレームワークを変更すれば解決するかはわからないですよね
// 画面表示ごとに何故かドでかいクエリを3回発行してる謎クソ実装とかに遭遇したが、PMが「サーバスペック不足かなぁ？」とか言っててひっくり返りそうになった
Re: (スコア:0)
何が遅い原因なのかを明確にしてからじゃないと、言語やフレームワークを変更すれば解決するかはわからないですよね
// 画面表示ごとに何故かドでかいクエリを3回発行してる謎クソ実装とかに遭遇したが、PMが「サーバスペック不足かなぁ？」とか言っててひっくり返りそうになった
画面表示ごとになぜかドでかいクエリを3回発行しているという事実を知ってる上でサーバスペック不足かなぁって言ったならひっくり返るのも分かる
けど、知らなかったら「作ったやつの技術力不足だろ」なんて言ったら開発メンバーから顰蹙かうから言えないだろ…
根本的な問題 (スコア:1)
そもそもメッセンジャーサービスはマネタイズが難しいというのが根本的な問題ではないかと
Twitterも創業以来ずっと莫大な負債を積み上げ続けてきて、2018年頃やっと一時は黒字化を達成しましたがまたすぐに赤字転落
コロナショックを経てインターネット広告の有効性に疑問符がつき始めているのが現状なわけで今後も厳しい時期が続くのではないかと
つまりイーロンマスクがどうこうする以前からTwitterの未来には暗雲が立ちこめていた状態だったように思います
MastodonやMisskeyのようなTwitterクローンサービスが運用できていたのは端的には利用者が少なく有志の持ち出しでコストを賄えていたからに他ならず、
ユーザーが増えてTwitterと近い規模で運用しようと思ったらその莫大な運用コストをどこからか調達しなければサービスの継続は間違いなく不可能でしょう
Misskeyが直面している問題は技術的な問題ではなく結局は運用コストをどう捻出するかという単純な問題なのではないかと思います
Twitterがうまくいかなかった問題を一から作り直すだけでそう簡単に解決できるとは思えません
そもそもとして分散型サービスはどうしても中央集権型サービスより全体としてのコストは増加するものです
言語やシステムを刷新するだけでコスト問題が解決すると安易に考えてしまうのは、人員を削減しまくれば解決すると考えたイーロンマスクと同様の安直さではないでしょうか？
やってみて欲しい (スコア:0, 既出)
他人事としては、どうなるか興味深いしー
Re:やってみて欲しい (スコア:1)
同意です。
他の大きいボトルネックから改善していっても、いつかはGCがボトルネックになるのは目に見えてますし、
それなら一番大きい言語から変更するのは割と妥当な気がします。
Re: (スコア:0)
いつかは来るの？
リファクタリングとかより (スコア:0)
Misskey.ioがスポンサーを探してサーバー増強 (金の力) で解決した方がいいんじゃないかなと思った。
MetaのThread ? が 1000万ユーザー突破したらしいけど安定しているのはプログラムの質もあるだろうけどサーバースペックもすごいんだろうし
詳しくは知らんけど。
Re: (スコア:0)
上手くいかないネットサービス無限ループ
1. 新しいプラットフォームに人が集まって来て処理が重くなる
2. 処理が重いのを解決するにはサーバー増強しないと
3. サーバー増強するためには金がないといけないよね
4. 金を集めるには、スポンサー広告付けたり 金取ってトレントに載せたり ユーザーから課金しないと
5. 広告やトレンド操作やユーザー課金に 多くのユーザーがキレて別プラットフォームに離脱する
以下、無限ループ
今twitterやredditで起きていることって、かつてMySpaceやニコニコ動画で起きてたことですよね。
Re:リファクタリングとかより (スコア:2)
ループしてないよね（5で終わり）
Re: (スコア:0)
ユーザーがループしてるよ
Re:リファクタリングとかより (スコア:2)
なるほど！
ユーザーによるネットサービス焼畑農業か！
んなあほな
Re:リファクタリングとかより (スコア:1, おもしろおかしい)
> ユーザーによるネットサービス焼畑農業か！
実際そうじゃない？
嫌儲ユーザーによるサービス乗り換え焼畑農業 ってのが実態じゃないすかね？
Re:リファクタリングとかより (スコア:1)
イナゴか
Re: (スコア:0)
それってMisskeyに存続するほど魅力がないって (コメントはここで途切れている
Re: (スコア:0)
Facebookは自社データセンタ + それなりの性能のサーバーの超多クラスタだったような…
でも今はソフト側をチューンしてAMD EPYCの少クラスタで動かすのが流行りってどこかで読んだような…
まず状況の分析からでしょ (スコア:0)
> 遅い原因は本当にNode.jsなのかやスロークエリーを先に直すべきではと言った声、
> CPUバウンドなのかIOバウンドを測定してから検討すべきと言った声
まずはこれでしょ。もしも仕事なら。
自腹でやってる中の人が、別の言語で書きなおしたいってのなら好きにしていいと思う。
スラドもやりたきゃ書き換えていいよ (・∀・)
確かに重い (スコア:0)
Misskey.ioをfirefoxで見るとめちゃくちゃメモリを喰うんですよね。
なんとかなるのならしてほしい。
Re:確かに重い (スコア:1)
Firefoxはjavascript多用するサイト見るとだいたいどこでもめちゃくちゃメモリ食う
ブラウザゲームとか特に顕著
Re: (スコア:0)
ここで言うパフォーマンスはフロントではなくバックエンドのはなし
Re: (スコア:0)
Node.jsやRustというからサーバーサイドの話で、クライアントであるfirefoxとは関係ない話ではないかな。知らんけど
Re: (スコア:0)
直接の関係はないんだけど
サーバーサイドとフロントを同じ言語で開発できるということは
フロント側の開発も活発にやっているのが想像できて
機能の一部をフロント側で実行しようとする可能性がある
クライアント側で重い処理すればサーバー側が軽くなる
でも重くて使いにくいサイトが出来上がる
Re:確かに重い (スコア:1)
CDNも使えるし、ローカルキャッシュも効くしね。
CalckeyはRust化を進めてる (スコア:0)
Misskey forkのCalckeyの方は既にバックエンドのRust化を進めています [gnusocial.jp]。
でも技術的な問題 [codeberg.org]で2ヶ月前ぐらいから開発が止まってるようです [codeberg.org]ね…。
えーと、 (スコア:0)
>Misskeyの遅いから
Misskeyの反応が遅いということを書きたいのでしょうけど
こういう書き方はモヤる
他の案として (スコア:0)
elixirは候補に上がらないの？