13 KiB
+++ date = "2019-12-22JST" tags = ["heroku","sns"] title = "Herokuで立てる分散SNS" slug = "heroku-sns" +++
今回は、Herokuで立てる分散SNSの話です。
アドベントカレンダーに参加しています。
Herokuについて
私は、MastodonをHeroku上に構築しています。この界隈ではzundaさんが有名です。
Herokuは、個人的に最も良心的かつ使い勝手が良く安定したPaaSだと思っています。今までOpenShiftやIBM Cloud(Bluemix)など様々なサービスを試してきましたが、その中では総合的に見てHerokuが一番でした。(あくまで個人的見解
さて、そんなHerokuですが、サービスとしての認知度は高く、定評があり、人気もあるので、知っている人は多いかと思います。
ですが、Herokuがどういった会社なのかを知る人は少ないと思うので、今回は少しだけそのへんを考えてみたいと思います。
まず下のページを読んでみてください。
Hanafuda has been around for hundreds of years and has a very recognizable style. The cards have special significance and represent months of the year. Heroku also has a distinctive style, one we take great pride in. Herein lay the challenge: How do we make the cards recognizable to experienced Hanafuda players, but also make them feel like they came from Heroku?
花札は、何百年も前に考案されたもので、特徴的なスタイルも持っています。それぞれの札には特別な意味があり、1 年のそれぞれの月を象徴しています。Heroku にも独特なスタイルがあり、私たちはそれを誇りに思っています。ここに今回の課題があります: 花札に熟練した人にも分かりやすい札を Heroku によるものだと感じてもらえるようにするにはどうすればよいのか？
https://jp.heroku.com/hanafuda
(Herokuは多言語ページが用意されていることも多く素晴らしい！)
上記は、URLからも分かる通りhanafuda(花札)に関する文章です。
珍しいですね、花札なんて。日本人でもあまり馴染みがありませんが、花札は、日本のかるたの一種「花かるた」とも呼ばれています。
昔、Herokuのトップページにアクセスした時の第一印象は「ここのオーナー、日本人なの？」と思ったことを覚えています。背景に富士山のようなデザインが描かれていたので、なんか日本的だなあと感じたためです。
しかし、これも花札由来のものだったのかもしれません。
さて、そんな花札ですが、デザインのセンスがとても優れた任天堂という会社があります。古くからある会社ですが、世界的にも有名なゲームメーカーです。そんな任天堂、実は花札で成功した会社でもあるのです。
確かに、Herokuと任天堂、単なる花札つながりで全く関係ないんですが、私は、少しだけ親近感を覚えました。任天堂のゲーム、好きなんですよね。
それに、Herokuのデザインセンスはとてもいいですし、ドキュメントも充実していて、わかりやすいです。
また、Herokuのdocsでは、コードを記述する際のシンタックスハイライト以外にもコマンドプロンプトを示す$がコピーされないようになっています。芸が細かいっ！(早速、真似してみた
https://devcenter.heroku.com/articles/go-sessions
$ go get -u github.com/heroku-examples/go-sessions-demo
$ cd $GOPATH/src/github.com/heroku-examples/go-sessions-demo
Herokuは、デザインも素晴らしいですが、こういう細部のこだわりもすごいと思っています。また、しっかりと日本語ページも用意されていて、そんなHerokuが私は大好きです。
Herokuで分散SNSを立ててみた
私は、Heroku上でMastodon, Misskey, Dolphin, Pleroma, GNU Socialなどの分散SNSを立ててみたことがあります。
どれも実験用アカウントなのでMastodon以外のサーバーは費用面の関係で近く停止させると思いますが、以下のようなアカウントを作っていました。
Heroku上での分散SNSの立てやすさに関しては、素晴らしかったです。
分散SNSの感想
しかし、立てるのは簡単でも、長期的に運用していくとなると、また別の話。ここからは運用の話になります。実験的に色々な分散SNSをHerokuに立ててみた感想。
私が最初に立てたのは、Mastodonサーバーでした。2年ほど運用していると、いろいろ思うところはあるものの、Mastdonでよかったなー、Herokuでよかったなーという感想になります。
当初の目標は、なるべく長く運用できればいいなーという軽い気持ちでした。私がMastodonをやり始めたきっかけは、単なる遊び心です。「なんか面白そうなものがあるぞ、やってみよう」という程度のものでした。だからこそ、お金かかりそうならそこで終了する。それが最初に決めたルールです。長く運用するためにも費用を最小限に抑えるのが一番いいかなと思いました。
そんな運用方針のため、負荷には少し敏感です。それに、たくさんの実験ができたのも良かったかなと思っています。そこそこ長くMastodonや分散SNSと付き合うことができました。
そんなMastodonですが、実は、GNU Socialを立てた時のほうが負担が大きかったのは意外でした。あくまでHeroku上の話ですが、GNU Socialは、初期の頃のMastodonより高負担でした。逆にエコだったのはPleromaでした。
しかし、今では、Mastodonもかなりのエコになってきて、確か2.7あたりからDBの増加量に変化がありました。圧倒的に負担、増加量が少なくなったのです。おそらく、ソースの方で、誰かがパフォーマンスの勘所を見つけたのでしょう。例えば、アプリのパフォーマンスを遅くしているのは、全体の1%の部分に過ぎないみたいな話があります。そこを改善した場合、全体でx2やx4の向上があるというのは別に珍しい話ではありません。
したがって、今からMastodon 3.0以上をやろうと考えている人は、初期の頃よりも費用を抑えられると思います、おすすめです。
最後は、その他の分散SNSについてです。
Misskeyは開発者が日本人の方で、話しやすいかもしれませんし、開発速度も速い印象なので、おすすめかも。また、Misskeyのmini版でもあるDolphinはぼっちインスタンスに特化しています。
PleromaはMastodonよりはるかにソースを改造しやすかった印象。
反対に、この中で最もおすすめしないのは、GNU Socialです。何故かと言うと、プロトコルがOStatusなので、分散SNSとしても管理者としても厳しい気がしています。ですが、GNU SocialはPHPですし汎用性があり、サーバーサイドから見ると、一番扱いやすいかも。
とはいえ、自分が良いと思ったものをやるのが一番なので、ここに書いたことはあまり気にしないでください。あくまで個人感想に過ぎません。
以上が実験的に色々な分散SNSをHerokuに立ててみた感想です。
MastodonなどをHerokuで立てるのは、個人的にすごくおすすめだと思います。
年間 $0 運用
私は、2年以上、継続してぼっちインスタンス(お一人様インスタンス)を運営してきましたが、今までにかかった費用は$0です。しかし、この運用にはいろいろな工夫が必要でした。これはHerokuを含めた様々なサービスのおかげです。感謝しかない。
Mastodonは、初期の頃、Heroku上でもかなりの高負担でした。特に、DBのレコード増加量が半端なかった。したがって、初期の頃は1ヶ月に一度ほどDBをリセット(正確にはリストア)しなければなりませんでした。
DBに関しては、Adminアカウントを作って初期設定を終えた時点のものをバックアップしてます。そして、DBがいっぱいになった時点で、そこにリストアします。なので、アカウントの同一性は保持されている状態(ただし齟齬は発生します)。Mastodon自体はDBと関係なくアップデートしているので、リストア後はマイグレーションを実行します。リストア後に問題がなければ、そのDBをバックアップして古いものは削除します。この流れを繰り返します。これによって、年間 $0 運用を達成しています。この一連の流れは、スクリプトにしているので、それほど大変ではありません。
$ pg_restore --verbose --clean --no-acl --no-owner -h $host -U $usern -d $database ./backup_db.dump
$ heroku run rake db:migrate -a $app
また、メディアサーバーをGitHub Repoに切り替えて運用していました。画像の投稿もAPIを使って行います。こちらも以下のような流れでコマンドを作っているため、それほど不便ではありません。(あまり画像を投稿しないというのもある)
# メディアサーバーをGitHub rawにする
heroku config:set PAPERCLIP_ROOT_PATH=https://raw.githubusercontent.com/$USER/$REPO/master/img/mastodon
# 画像ファイルを投稿して画像IDを取得する, IMG_ID
curl -F "file=./test.png" -sS https://$host/api/v1/media -H "Authorization: Bearer $access_token"| jq -r .id
# 画像をgit serverにpushする
git push -f origin master
# ユーザーから画像を投稿する
curl -sSL https://$host/api/v1/media/statuses -d "status=#media&media_ids[]=${IMG_ID}" -H "Authorization: Bearer $access_token"
しかし、他のサーバーに流れている画像は取得しませんし、表示できません。あくまで自身が投稿する画像のみ表示します。
フォローもしない方針です。分散とは、タイムラインに蓄積される情報を各インスタンスが保存する仕組みだからです。
ドメインはFreenomを利用し、DNSはCloudFlare、メールはMailgunです。どのサービスも本当にありがとう！
これからも、そこそこ長くMastodonをやっていけたら嬉しいです。
なお、この記事は、サーバー代などの節約を推奨するものではありません。運用方針は人それぞれです。私が様々なサービスを使ってみた感触として、Herokuが非常に良いサービスだと感じているという話なので、Herokuは月額契約するにもおすすめです。おすすめする理由は様々で、デプロイが簡単、ドキュメントが充実している、細部にこだわりが見られる、費用が安い、無料で使い勝手を試せる環境が存在しているなど、これらのことは、デベロッパーにとってすごく重要なことだと思います。Herokuには、そういった環境が整っているので、おすすめです。Herokuのコマンドラインツール、メチャクチャ使いやすい。素晴らしい！