レポート

Mastodon/Pawooの運用&開発技術 - pixiv Night #04 レポート

この記事を読むのに必要な時間:およそ 7 分

「アプリを最速でリリースした話」

三津山さん@chocomelon@pawoo.netの発表は,リリースしたばかりのAndroid版Pawooのアプリ開発の模様を紹介しました。発表の冒頭では,アップデートのリリース作業を行ってから話が始まりました。

画像

Androidアプリはネイティブ

Androidアプリ自体は,きちんとネイティブで作ったと言います。構成は,MVPっぽいアーキテクチャで,Retrofit,RxAndroid,Data Bindingとかを使っているそうです。ただ,そんなことはどうでも良くて,とにかくスピード重視で作ったと話しました。なお,対応バージョンは,pixivのアプリは4.0.3を切ったばかりですが,このアプリは5からであることを補足していました。

このアプリは基本的に全部のことをできることを意識して作っているそうです。それは,競合クライアントの中でPawooのアプリを使ってもらうとなると,メイン機能を絞るのは難しいと考えたためです。その結果,実装に全力を出すことになったと述べていました。

アプリ開発の進行の模様

アプリはほぼ6日で作ったとし,三津山さんはその模様を振り返りました。

1日目は,自分一人だけで開発していました。午前中に話があり,ログインから作って,ホームタイムラインを表示するように進めたそうです。

しかし2日目になって,1週間程度で作るのは厳しいと思い始めたとのこと。ただ人を入れるにしても,同時並行にするのはこのままでは結構難しく,人を受け入れられる体制を作ろうとしたのが2日目だったと言います。ハンバーガーメニュー・タブメニューを作ったり,タイムラインの構造はだいたい一緒であるため,ベースの構造をしっかり作ったりしたりして,人が増えたときに単体でページが作れるように,作業を進めたそうです。

2日目終わった段階で,以下の図のように,ログインがWebViewからできて,タイムラインを取ってこれるものができていました。

画像

3日目に一人増やしました。そして,インスタンスがPawoo限定になっていたので,他のインスタンスでもログインできるようになりました。また,自分たちが使っていて楽しいと思う機能を最初に実現したかったので,アクション回りを作っていったそうです。社内に中途半端な状態でも配布して使ってもらい,フィードバックを受け取れるようにするため,DeployGateの整備もしたそうです。

4日目からは4人体制になりました。プッシュ通知や,細かなブラッシュアップを行いました。結果,4日目には,タイムラインがきれいに見えるようになり,ユーザーページも見れて,アクションもできて,一通り雑にはそろったと言います。

5日目は,アプリのメインの体験とは違うところを作業を行いました。通知・Fav一覧,翻訳リソース,画像付きトゥートなどです。6日目はバグ修正,つまりブラッシュアップの時間となりました。そのほか,プレスリリースの準備を行いました。

最終的にリリースされて

pixivのアプリでも,Androidだけで4名体制は相当リソースを割いていたことになるそうです。三津山さんは「ハッカソン的なノリで一気に作った」と言います。適切な時に適切な人数・人材を投入したのが良かったとし,多少バグは残ったりとか,足りない機能みたいなのはあったが,それなりに使ってもらえるクオリティにはなったと話していました。

また,全員がマストドンのことを理解していたため,アプリとしてどうすべきか,楽しめるかなどのフィードバックがきちんと出たことが,ブラッシュアップにつながったと述べていました。

ただ,正直6日もハッカソンのノリで作業するのは相当きつく,最後のほうは消耗していたとも述べていました。

これからは,複数インスタンスへの対応やアカウント検索,Pawoo独自の機能への追従,フィードバックへの対応をしていくそうです。Pawooが使いやすく,ほかのインスタンスでも使えることが,結果,Pawooの認知やこのアプリを使ってもらうことにつながるはずだと話していました。

「Mastodonを3倍速くしたい話」

石井さん@alpaca_tc@pawoo.netは,マストドンのスピード改善について発表しました。

画像

石井さんは,もともとPawooの開発に関わっていませんでしたが,エラーが出ているという開発陣の会話を見て,その修正点を指摘した流れで,そのままPawooの開発に携わるようになったそうです。

Pawooのサーバー構成

現在のマストドンはとても重く,現在(イベント時)のPawooは次の構成で動かしていると言います。

  • APサーバー10台
  • Sidekiq,60プロセス,1,400ワーカー
  • DB40コア,メモリ160GB(イベント時にはDB16コア,メモリ64GBに改善)

現在,最適化を進めていて,現在できたことと,これから行いたいことを話しました。

DB最適化

マストドンのデフォルトでは,アドミンだけが入れる/pgheroにアナライザなどが入っています。これでDBのクエリを見ることができます。それをずっと眺めていると「これなんか遅いな」というのが,まだまだあると石井さんは言います。つまり,DBに最適化の余地がありました。

例えば,遅いクエリのためにindexを張ったことを取り上げました。これにより,DB40コア,メモリ160GBから,DB16コア,メモリ64GBになったと言います。⁠グラフは機能追加で障害が入った直後の個所なので結構見づらいとのこと⁠⁠。

画像

実際コードを見ていると,まだまだindexが張れていなかったり,クエリが遅い箇所があるので直していきたいと述べていました。

リモートインスタンスへのリクエストを改善

マストドンはリモートインスタンスとの通信が必要です。そのデフォルトのタイムアウトは長いもので60秒もありました。そのままの設定だと,弱いインスタンスでは即詰まります。そこで,Goldfinger,PubSubHubbub,AtomServcieなどのタイムアウトを短くするのが良いと話しました。

画像

そもそもタイムアウトやリモートインスタンスを改善するには,マストドン自体を改善するしかありません。そこでpixivでは,Pawooを最適化して,本家のマストドンにプルリクエストで貢献しています。実際,次のバージョンはこの貢献によって速くなるし,これ以降も貢献していくことで,リモートインスタンスもPawooも速くなって,みんな幸せになることを目指していると述べていました。

mstdn.jp DoS攻撃の改善

リモートインスタンスがメンテナンスに入ると,例えばmstdn.jpが落ちると一気に数万件のキューが,どかんと溜まると言います。この解決のために,賢いretry戦略を検討しているそうです。それは,リモートインスタンスが落ちていることを把握することで,接続可能なリモートインスタンスのジョブが詰まることを避けることだと話します。

失敗したリクエストなどをホストごとに管理することを考えているとし,例えばRedisに集計して,10分以内にリクエストが失敗したら,そこへのインスタンスは何十分間遅らせることなどを検討しているそうです。

Sidekiq N+1問題の改善

道井さんのセッションでも取り上げられましたが,ユーザーがつぶやくたびに全フォロワーに通知が飛びます。

実際に,次のようなコードになっていて,workerを積んでいく形になっています。

画像

Sidekiqに積まれるのは,Redisに積むためにIDの数値のみになっています。オブジェクト自体は積まれません。そうすると,実質N+1になります。SidekiqにはIDしか積んでないので,ジョブのなかで引き直す必要が出てきます。

これに対して石井さんは,where(id:ids)で一気に全件を取ってきて処理すればDBへの負荷が減るはずだと考えていて,次のようなperform_async_in_batchesといった仕組みを導入することを検討しているそうです。

画像

これによって,バッチサイズを設定することができ,また1を指定しておけば現在のマストドンの挙動と同じになります。もし500とか1,000とかのバッチサイズを設定できれば,それをまとめて処理することで,N+1問題を改善したいと話していました。

最後に,石井さんは「pixivではすでに30近くのPRを本家のマストドンに送っています。これからもマストドンをどんどん引っ張っていきたいです。ぜひ興味がある人は来てください」と締めくくっていました。


すべての発表後に懇親会が催されました。随所でマストドンの感触や運用ノウハウなどが語られていたようです。そのようななか,片隅でPawooチームが開発している風景も見られ,マストドン・Pawooの勢いが感じられるイベントとなりました。

著者プロフィール

高橋和道

gihyo.jp編集部 所属。最近では電子書籍の制作にも関わる。

URL:https://twitter.com/k_taka