Mastodonのソースをみてみる

急にMastodonという分散型マイクロブログが話題になってきましたね。短文投稿が出来るTwitterライクなサービスですが、ソースが公開されており、自分でインスタンス（=サーバー）を立てることができます。その上で、サーバー（=ドメイン）をまたいで、フォローをすることができます。これをリモートフォローと呼ぶようです。

これにより、Twitterが障害などで落ちても全滅することはなくなり、データもTwitterのみに握られることもなくなり、勝手にアカウントの凍結やBANも食らうこともなくなります。

Mastodon自体はOStatusというオープンなプロトコルの実装レイヤでしかありません。つまり、思想的には別段新しくはないのです。

詳しくは以下の記事がめちゃんこよくまとめてくれています。
https://blog.cardina1.red/2017/04/13/federated-social-web/

個人的には、触ってみてもたいして何か新しいことが始まるワクワク感的なものは感じませんでした....。根本的にUXが新しくない限り、OStatusのキラーアプリケーションには成り得ないんじゃないかなあ。

今回のテック会議では、公開されているソースを覗いてみます↓
https://github.com/tootsuite/mastodon

軽く見た感想

ひと目見てRailsアプリだとわかります。最初のコミットは2016年2月で、当時はまだRails4.2の頃だったようです。

最近のRails界隈でよく話に出るベストプラクティスに沿った構成になっています。modelレイヤ(ActiveRecordのサブクラス)は軽めで、serviceレイヤに煩雑な処理は切り出されています。

サーバーをまたいだ分散型なので、更新系の処理を行う際は他のサーバーへもOStatusの各種プロトコルを喋って通知してあげる or もらう必要があるのでかなり煩雑な処理になります。このような通信周りはすべてserviceレイヤに押し込められていています。modelはローカルのDBまわりの設定・実装に絞られており、全体的に見通しが良くて読みやすいです。

controllerはすぐにserviceをcallし、serviceはDB更新やsidekiqにqueueを詰んですぐに抜けます。

フロントエンドはRedux + Reactで書かれています。Railsもまだ5.0系ということで、Sprocketsに乗っているようですね。SSRはしてない模様。APIはnodeで書いてないみたいなので、SSRをやるならフロント用のサーバーをAPIサーバーの前段の置くのでしょうが、構成を複雑にしすぎるとだれでも気軽に設置できる感じじゃなくなるので、やりすぎずそれなりの得点をとりにいくバランス感覚が必要なのかもしれません。

高負荷に耐えられる?

インターネッツでは、遅いとか大量のユーザには耐えられないなどスケーラビリティに関して疑問を呈する意見が散見されました。たしかに、1台のサーバーにすべて乗っけるとなると、Railsアプリだし、Redisをハードに使いそうだし、帯域も食いそうだし...で大変そうです。

[参考]
実際に運用してみてわかった、大規模Mastodonインスタンスを運用するコツhttp://inside.pixiv.blog/harukasan/1284

とはいえ

すごく良く書けていてバランス感覚の良い実装だと思いました。RailsやReactをやっているエンジニアにとっては格好の研究対象になるかなと。わたくしももっとdigります。