ITエンジニアのための勉強会・イベントレポート情報メディア

勉強会に行ってみた!第51回「Mastodon/Pawooの運用&開発技術」
event

勉強会に行ってみた!第51回
「Mastodon/Pawooの運用&開発技術」

2017.05.16

 
  • このエントリーをはてなブックマークに追加

話題のマストドンについての勉強会です。ポストTwitterとも言われる分散型SNSですね。企業としては最初に Pawooというインスタンスを作った Pixiv が、その舞台裏を話してくれました。今まさに大きな流れが始まろうとしている、その熱気のさなかにいるようでした。

三土たつお

会場は東京・千駄ヶ谷のピクシブでした。イベントは夜の19時30分から。

会場の入り口では手書きのイラストが迎えてくれました。エンジニアとデザイナーの方が書いたんだそうです。上手! 右側は Pawoo のマスコットですね。

会場はこんなふうでした。

イベントスペースは満員でした。メディアも少なくとも15社来ていたようで、マストドンとPawooへの注目の大きさが分かります。

19時30分になり、イベントが始まりました。

マストドンのおもしろさは何か?

最初のお話は、Pawoo プロダクトマネージャーの norio さん。この方がマストドンをやろう!と言い出したことで、Pawoo のプロジェクトが始まりました。「勢いで始めたが、かなりの反響があった」といいます。

マストドンの機能としては、各インスタンスのローカルタイムラインが一番面白いと感じました。

ローカルタイムラインとは、各インスタンスの参加者の発言を集めたタイムラインです。各インスタンスにはそれぞれ、どのような話題を扱うかについての個性があるので、ローカルタイムラインにもそれが反映されます。

そのためローカルタイムラインに一体感があり、眺めているだけでも楽しいと感じたそうです。初期のツイッターにはパブリックタイムラインがありましたが、話題がバラバラで眺めていても楽しいものではありませんでした。また、ツイッターでは誰かをフォローしないと何も始まりませんが、マストドンならとりあえずローカルタイムラインを眺めればよく、ツイッターとの違いを感じたそうです。

マストドンのインスタンスは、新宿とか渋谷みたいに人が集まる街に似ているんじゃないかと思います。もっと言えば歩行者天国みたいな。誰かがパフォーマンスしているのを見てるだけで面白いし、自分がやれば誰かに見てもらえる。

マストドンは街に似ている!面白いことを言いますね。確かに、街には多くの人が集まるし、そこに集まる人には街ごとに個性があります。

戦後は新宿が若者文化の発信地でした。そのあと原宿へ移り、90年代は渋谷、そして秋葉原、その次はウェブです。これまでのように場所に根付いた文化をウェブ上でできないか。マストドンは新しい文化が生まれるプラットフォームになるんじゃないか。そう思って、ほとんど勢いで始めました。そうしたら会社も共感してくれた。

マストドンを、文化の発信の場として捉えているんですね。norio さんのお話は、原稿がほとんどないにもかかわらず、理路整然としてなめらかでした。思いつきで Pawoo を始めたわけではなくて、それまでに考えていたことがあって、それが Pawoo にうまくはまったからこそすぐ決断できたのだなと思いました。

実際運用してみてわかった、大規模
Mastodonインスタンスを運用するコツ

harukasan は、Pixiv のリードエンジニアです。世界でも屈指の大規模インスタンスであるPawoo はわずか 10時間でリリースされたそうです。その舞台裏を教えてくれました。

マストドンは Ruby on Rails で作られたモダンなアプリケーションになっています。構成としては PostgreSQL、node.js、Redis、Sidekiq などが使われています。まず、これらをDocker からはがしました。Docker のままだと、考えなきゃいけない問題が多くなる。全部 systemdのサービスに置き換えました。ここらへんは新卒を含む二人が適当にやってくれました。

ピクシブの新卒の人たち、すごい!

「そして AWS に展開しました。ピクシブでは普段はオンプレを使っていますが、さすがに10時間でなんとかしようというスピード感だとオンプレではできない。期間限定プロジェクトなどでは AWS が楽でよく使っているので、今回も選びました。マストドンのメインロジックはSidekiqが支えています。Sidekiqはジョブキューシステムですが、マストドンではメッセージパッシングにも使っています。つまり、1トゥートごとにフォロワーの数だけキューに積まれます。なのでフォロワーの多いユーザーだとキューがやばいことになります。

キューはいくつか種類があるんですが、デフォルトではすべてを1つのSidekiqプロセスで処理します。ということは1つでも重いリモートインスタンスがあってキューが詰まると、タイムラインが遅延してしまうんです。そこで、Sidekiqプロセスをキューごとに分けて、しかもたくさん立てることでカバーしました。

これでSidekiq問題は改善したものの、リモートインスタンスが1つ詰まると他への配信も詰まるという問題は解決せず、そのためにプロセスを増やすと結局DOSみたいになってしまうという課題があるんだそうです。

ここは難しそうですね。Pawooだけで解決するというより、マストドンそのものの仕組みや、他のインスタンスとの連携で改善する必要がありそうだなあと思いました。

なんか node の CPU使用率が100%で張り付いててマジヤバかったのでなんとかした話

次は geta6 さんによる Node.js まわりの改善の話でした。

geta6といいます。職業は一般ノーマルエンジニアです。JavaScript鉄砲玉として各プロジェクトに突っ込まれる係などをしています。なんかnodeのCPU使用率が100%で張り付いてるぞ、タイムラインが遅延してるぞ、といった問題が発覚して、Pawoo に割り当てられることになりました。

マストドンの実装を見てみると、WebSocketを使った pgsql、redisなどのストリーミング関連の実装は、すべて1ファイルで実装されていました。しかもそれらをbabel-node コマンドで直接起動する『筋力運用方式』になっていました。pm2などのマネージャーは挟んでいません。

筋力運用とかの言葉遣いがいちいち面白くて、会場からは笑いが起きていました。

ところで node はシングルスレッドです。コア数が多くても、1スレッドにつき1コアしか使われません。元の実装では1サーバーあたり1プロセス、つまり1コアしか利用できない状態になっていました。

こんなふうに全力で1つのコアを殺しにかかります(会場笑)。サーバーとしては余裕なはずなのに、node のプロセスだけが100%で張り付いてしまう。すると、ページは普通に見えるのに、タイムラインがめちゃくちゃ遅れてる、といった状態になります。解決策としては、プロセス数を増やして複数のコア間で負荷を分散するようにします。定石としては pm2 などのプロセスマネージャーを使います。

こんなふうに1つずつ殺す(会場笑)。しかし今回は systemd との相性が悪かったようで、うまく動きませんでした。そこで node に標準でバンドルされている cluster モジュールを使って筋力で解決しました。ユーザーが困っているという現状では、解決が最優先だからです。

コードとしてはこんなふうになります。これで晴れてマルチコアを全部使い切れるようになり、プロセスの負荷がいい感じに減りました。この改善はチケット #1970 としてマストドンの本家に取り込まれました。バージョン1.2.2でリリースされていますのでぜひご利用ください。

まとめ

なんというか、やる気と勢いにあふれた勉強会でした。マストドンのような新しいものにすぐに取り組んで成果を出してしまう。そしてそれができるだけの実力をふだんから蓄えている、と感じました。マストドンをただ利用するだけでなく、改善してそれをコミュニティにどんどんフィードバックしているから、みんなも幸せになる。素晴らしいです。

マストドンについて、自分は様子見かなあと思っていました。でもまずは貪欲に飛びついてみないと、その良さすら分からないんだな、と反省しました。

今回行った勉強会:「Mastodon/Pawooの運用&開発技術 - pixiv Night #04」
https://pixiv.connpass.com/event/55613/

原稿:三土たつお
1976年生まれ。プログラマー、ライター。プログラマーとしてはふだんPHPを書いてます。ライターとしてはニフティのデイリーポータルZとかで書いてます。近著「街角図鑑」(実業之日本社)。
http://mitsuchi.net/

勉強会に行ってみた!第51回「Mastodon/Pawooの運用&開発技術」

この記事はどうでしたか?

おすすめの記事

キャリアを考える

BACK TO TOP ∧

FOLLOW