この記事はMastodon Advent Calendar 2018 13日目の記事になります。国見小道のブログにようこそおいでくださいました。前日の記事は、まめもさんのみそみそミサイル発射装置 MISO MODEL1とは？ でした。みそみそ～ってなんだよ（お決まりのツッコミ）おまえミサイル発射したのかよ（畏怖）

僕のMastodonおひとりさまインスタンスがどのような環境で動いているのか。また、構築にかかる時間や月ごとの料金など、環境整備にあたって7か月ほど運営して得られたノウハウを書いていきたいと思います。

この記事の文字数は1.1万です。読みきるまでに40分くらいかかるっぽいので注意なのです！

まずは構築相談相手を作る

公式ドキュメント 片手に特攻していくのも悪くはないですが、インフラに堪能でない場合は まず構築について相談相手を作ったほうがよいと思います。自分は.envファイルの構成とAWS各種サービスへのリンクがどうにもうまくいかなかったときにフォロワーの方々に助けてもらったりしました。

先日のおひとりさま最強記事でも書いたように、Fediverse上には各分散SNS製作者がいたり、インスタンスの管理人がごろごろいますので、コンタクト取れそうな人にかたっぱしからコンタクト取っていくとよいです。そういった意味でもFediverseにきたらまずサーバー管理人をフォローするのは筋が良いだろうなと思っております。

鯖缶工場

Fediverseに分散したサーバー管理人を集約しているコミュニティがあります。鯖缶工場です。 Fediverse上でハッシュタグ #鯖缶工場 で検索すると出てくると思います。鯖缶工場Discordでは構築依頼も受け付けておりますので、構築についてなんもわからんになりましたら頼ってみるとよいと思います。僕も在籍しております。お気軽にどうぞ。

余談：はじめは本家そのままで運用しよう

鯖缶工場での依頼にちょいちょい「改造インスタンスで運用したい（ex: LaTeX的に書けるようにしたい、Markdownを実装したい、文字数制限を1000字に拡張したい etc….）」という依頼もありますが、僕としては、そもそも構築がおぼつかないのに改造インスタンスを運営するのは無理があると考えてます。

改造したら終わりではなくて、その先の運用フェーズで本家との実装と改造がぶつかって機能を失ったりレイアウトがぶっ壊れたりする可能性があります。 それを直すにはプログラミングのスキルが必要になってきますし、構築のほうで手いっぱいだとなし崩しにインスタンスが倒れます。

運用が慣れてきたら 、RubyやJS/React/ReduxやRSpecの知識を入れて改造に臨んでも良いと思います。ひとつひとつのステップは小さく取る。 人生をラクにする秘訣のうちの一つです。（ドヤァ…）

大半の人はMastodon以外のところで引っかかると思う

構築時にやること簡易まとめ

Mastodonを動かすときにやらなければいけないことを公式ドキュメントの“Installation”から簡略化しつつ挙げていきます。雑に抜粋してるんで抜けがあったら教えてください。

  • 基礎的なセットアップ(Optional)
    • Ubuntu 18.04の準備
    • SSHのパスワードログインを許可しないようにする
    • Ubuntuのアップグレードや、パッケージのインストール
  • 前提条件
    • Ubuntu 18.04が乗っている、root access可能なサーバー
    • Mastodonサーバーのためのドメイン/サブドメイン
    • Eメール配送のためのSMTPサーバー
    • 画像用オブジェクトストレージ　Amazon S3（オススメ）など
    • ※ 筆者により条件追加。ないと運用フェーズでディスクフルやストレージ移行作業に追われる
    • インフラに慣れてる人であれば、bin/tootctl media remove などのコマンドを駆使してストレージなしでも可能
  • 色々とインストールする（※Standalone構成）
    • システムリポジトリ (curl, Node.js, Yarn)
    • 色々なシステムパッケージ
    • Ruby
  • 組み立て
    • PostgreSQL
    • Mastodon
    • GitHubからコードをローカルに持ってくる
    • 最新の依存関係（パッケージの）インストール
    • 設定ファイル “.env.production” の作成 (mastodon:setupコマンド)
    • Nginx
    • Mastodon向けconfファイルの作成
    • SSLサーバ証明書の取得
    • systemd serciveの設定
    • web/sidekiq/streamingファイルの編集
    • systemdを起動する

=> your-domain.tld/about が表示されていれば無事Mastodon立ち上げ成功。

Mastodon独自設定についてはそれほど多くない

上記の箇条書きを一覧していただくとわかるように、Mastodonならではの作業というとそこまで多くないのです。

Ubuntuセットアップ、ドメインの取得、SMTPサーバーの用意、オブジェクトストレージの用意、各種パッケージのインストール、Nginxの設定等々。これらは別にMastodon独自というわけではなく、サーバーの環境構築という領域です。

これはいわば、システムインフラストラクチャー構築 という風に言ってよいと思います。IT技術者がインフラインフラ言っているのはこうした背景があります。サーバー弄りとかロードバランサ設定だとか証明書更新なんかもインフラ運用の一部です。

インフラになれていないとMastodon構築に引っかかる

項で掲げた「大半の人はMastodon以外のところでひっかかる」とは、つまりは インフラ構築で引っかかる ということだとおもいます。立ち上げ時にトラブルがあったとして、

  • ドメイン設定が効かない / 設定したアドレスにアクセスしてもエラーが返ってくる
  • 常時HTTPSのソフトウェアなのに証明書が適用されていない（ブラウザが警告を出している）
  • 画像がアップロードできてない（ストレージ設定のミス）

など、こうした事象はインフラに慣れてないゆえのミスです。

かくいう僕もめっちゃ引っかかりました。画像は早く見たい！という気持ちがあったのでオブジェクトストレージとコンテンツデリバリーネットワーク (CDN) を組み合わせてみたのですが、証明書やサブドメイン回りでとても躓きました。画像が表示されるようになるまでに1日を要しました。

知らないIT用語は検索して乗り切ろう

さて、いまこの記事を読んでいるあなたにとって、これまで書いてきた文のなかでどれほど未知の単語があったでしょうか？ドメインって何？SSLって何？Yarnとは？

公式ドキュメントからして、開幕から平然と “Ubuntu 18.04” とかいうメカメカしいワードが飛んできてます。 サーバー弄りしないひとや、普段はプーさんのホームランダービーしかやってないわってひとにとってはかなり読み下すのがキツいドキュメントだと思います。

Webサービスというものは、こうした様々な概念を組み合わせてこねくり回した末に動くものです。しかもその概念は日々進歩しており、我々ITエンジニアにとってもアンテナを張っていないとすぐ落伍する世界となっております。

しかし、我々には目の前や手の中に便利な道具があります。Googleを始めとした各種検索サイトです。誰もが完璧な知識を持っているわけではないのです。わからないことは調べていきましょう。わからないからといって投げるのはもはやこのご時世では通用しません。 やっていきましょう。

マニュアルはしっかりしている方だと思う

普段サーバーをいじらない一般のご家庭の皆様におかれましては大量の専門用語に面食らうとは思いますが、世の中のOSSのなかではマニュアルをとても丁寧に用意してくれているほうだと僕は思います。

OSSでREADME.mdが分かりやすく書かれてるのは有名プロダクトでないかぎり少なかったり、そもそもお前なにができるんだっていうREADMEなどもザラにあります。

そして、各分散SNSのドキュメントを比較しても、Mastodonのマニュアルは最も充実しています。これは後日記事にします「『鯖缶工場』で務めて分かった、Mastodonを選ぶメリット」でも書く予定の、Mastodonを選ぶ大きなメリットでもあります。

構築期間は1日（インフラやりおるマン）〜1週間（インフラわからんマン）

構築時にやることが多いため、ドメインやサーバー類をすでに取得していたとしても1日はかかります。なんもわからん場合、1週間は見ておいたほうがいいでしょう。IT用語についての仕組みの理解をしつつMastodonを組み立てていくことになるので、たとえよく知らなかったとしても焦らず組み立てていきましょう。諦めなければサーバーは立ちます。

メモリは2GBが人権

Mastodonはリソースを結構使います。 おひとりさまインスタンスですら、Mastodonを動かすにはメモリは2GBが必要です。CPUは1CPUでも問題なさそうですが。

おひとりさまインスタンスを立ち上げて4か月ほどは、AWS EC2の無料枠 (t2.micro, 1CPUのメモリ1GB) で回してました。頻度としては、始めて2か月あたりは1か月に1回落ちるかどうかというラインだったので問題なかったのですが、そこから連合が広がっていくにつれて次第に落ちやすくなってまいりました。

バーベキューではしゃぎつつ写真を3連投したら、インスタンスのメモリスワップ使い果たして死んでしまい、バーベキュー会場で食休みの傍らSSHつないで修復した のを覚えています。つらかった。

1GBでも運営できなくはないですが、安定性がめっちゃおちるので、2GBで運営するようになると思います。1GBで運営できるのであればその運の良さを享受していきましょう。

とっっっっっっっても重要！！！mastodon:setup

公式ではさらっと書かれている mastodon:setup コマンド。対話型で.en.production 設定ファイルを作成するこのコマンドは、Mastodonを構築する上でとても重要なポジションにおります。

どれくらい重要かはプログラムを見れば一目瞭然です。 Mastodon構築の骨格を形成する様々なことをやっております。ドキュメントで書いてあるような、単なる.env.production生成のコマンドだけではありません。該当のプログラムは何をしているかを箇条書きしていきます。

  • マストドンで使うドメイン名の設定
  • おひとりさまか否かの設定
  • SECRET_KEY_BASE, OTP_SECRET の設定を生成 ※対話に出てこない。
  • VAPID_PRIVATE_KEY, VAPID_PUBLIC_KEY の設定を生成 ※対話に出てこない。
  • Dockerを使うかどうか設定
  • PostgreSQLの host/port/database-name/user/password の設定
  • Redisの host/port/password の設定（だいたいの人はここはデフォルトのままで良い）
  • オブジェクトストレージを使う場合の設定（Amazon S3, Wasabi or Minio）
    • Amazon S3: S3の bucket name, region, hostname, access key, secret key の設定
    • Wasabi: Wasabiの bucket name, access key, secret key の設定
    • Minio: Minioの endpoint URL, access key, secret key の設定
    • アップロード先のALIAS HOSTの設定
  • Eメールをローカルホストから送信するかどうかの設定
    • ローカルから出ない場合は、SMTPサーバーの server, port, username, password, authentication, OpenSSL-verify-modeの設定
  • Eメールをどのアドレスから送るか設定
  • 試しにメールを今すぐ送ってみる？と聞かれる
  • ここまで（↑）設定してきたことを.env.productionに保存するか聞かれる // Yesを選ぼう
  • ↑で “Yes” と答えた場合、以下の対話が現れる。
    • Databaseを作成するか聞かれる。Yesで db:setup コマンドが走る
    • assets:precompile を走らせるか聞かれる
    • ここまでで、Mastodonについての設定は完了したことを対話プロンプトから伝えられる
    • すぐに管理者アカウントを作るか聞かれる
    • 作る場合、ユーザーネームとEメールアドレスを設定、パスワードは自動生成されて画面に出てくる
    • 完了！

ご覧の通り、めちゃめちゃいろんなことやってるんですよ！！！しかも、これを通さないとコマンドを個別にたたかない限りMastodonはセットアップ完了できません！！

プログラムの実行内容をつらつらと書くだけでかなりのカロリーを消費しました。そんななか、公式の記述はたったこれっぽっちですよ。

こざっぱりしやがって！

ASS !!!

mastodon:setup は一発でぶち通せ！

mastodon:setup コマンドは先述した通り クソ長い対話スクリプトなので 1発で決めましょう。重要なコマンドなので、避けて通れません。このコマンドを通す前に、対話で何が聞かれるかをプログラムからチェックして（初心者バイバイポイント）、事前に連携先サービスの各種情報をまとめて（初心者バイバイポイント）、一発でコマンドを完了させましょう。

生成される .env.production ファイルはごくごく普通にエディタで編集できるため、設定項目が足りていなかったり、運用していくにつれて変更する必要が出た場合は編集しましょう。

Dockerで環境構築のススメ

mastodon:setup コマンドで 唐突に「Dockerを使うか？」 と聞かれます。なんだ急にお前と面食らいますが、実はDockerで環境構築を進めるのは僕としてはおススメしたいです。どのような利点があるかというと、

  • 立ち上げ時のインストール作業が大幅に減る
  • 各依存関係それぞれについて目を光らせる必要がなくなる（Dockerfileの記述で依存関係を指定できる）
  • Mastodonの自動更新が容易に達成できるようになる（弊スクリプト参照）
  • Dockerfileやdocker-compose.ymlに、依存関係に対してさせたいことをプログラムとして残せる

などがあります。欠点としては、

  • 依存関係にあるパッケージの個別チューニングが面倒くさくなる
  • 下手にdocker-compose buildを繰り返してるとディスクフルに陥る
  • jemallocが機能しない

などが考えられます。jemallocはStandalone構成ではするっと入るのですが、Docker構成だとなんでかうまいことはいらないようです。このことにより、若干ですが運用が富豪的になってしまいます。

ドキュメントからDocker-guideが消えている

GitHubのtootsuite/documentationリポジトリに公式ドキュメントがあった時は、Docker-Guide.md というものがあり、Dockerで環境構築する指針についてメンテナンスがされていました。しかし、joinmastodonにドキュメントが移管されてからは、DockerについてはInstallationの項ではバッサリされています。

しかし、2か月前のコミットでオイゲンさんが「たくさんのインスタンスのデータベースがこいつで失われた」と嘆きつつ更新をしているのが記録されていることから、別にサポート自体は止まってないように思われます。

僕個人としては、自動更新によって楽をしつつmaster追従をしているので、できればDockerのサポートは打ち切らんでくれ～と思います。

オブジェクトストレージは是非入れよう

連合が広がっていくにつれて、多くの画像ファイルをMastodonが取り込んできます。 もしMastodonを設置したサーバーにメディアも保存するようにしておくと、どんどんディスク容量を圧迫していきます。そして、移転作業も面倒です。

なので、オブジェクトストレージだけはOptionの中でも用意しておくべきものでしょう。 オススメはAWSのAmazonS3です。設定方法についてはこちらの記事を参考にして進めてよいと思います。

Amazon S3でしたら月額$3あたり（弊インスタンスでの料金）で運営できます。とてもやすい。なので、節約するにしても正直$3ケチるよりは払ってメンテナンスで楽すべきと思っています。まあmedia removeコマンドもあるのでそれでなんとかディスク容量を空けることもできますが、めんどくさそう（偏見）

PostgreSQLの外出しはやっておいたほうがいい

外出しというのは、「データベースのサーバーを別に用意しておく」ことを指します。Mastodonの構築周りで何かやらかしてサーバーがオワってしまっても、データベースのデータは守れることができます。また、自動でdumpを取ったりしてDBサーバーでバックアップを保持したりすることもできます（これはMastodonの乗っているサーバーでもできるが）。

僕は、AmazonRDSを使ってDBを外出ししております。RDSのサービスで自動バックアップを14日間期限で毎日取っており、今すぐWebサーバーが死んでもしれっと復活できます。

Mastodonの更新作業でリリースノートに「必ずバックアップをとりなさーい！」と毎回書かれているので、そういうことならば毎日バックアップ取得できるように構築しちゃったほうが楽じゃないかなと思います。

もちろん、サーバー追加にはコストがかかります。AmazonRDSですが、僕は無料枠で回せていますが無料枠の期間が終わると（2019/05）、$15が月額に乗ってきます。つらい。なので、コストカットでMastodonサーバー内やオブジェクトストレージにバックアップを飛ばすことでコストカットできるかなぁとは思います。

RedisはWebサーバー内で完結しててOK

Redisは揮発性のデータベースのため、吹っ飛んでもそれほど痛くありません。主にトゥートのやりとりやTLの構築などで使われますが、揮発性ゆえにデータがとんだところで再構築するだけです（コマンドもある）。なのでRedis用のサーバーを用意する必要はないと思います。

AWSはいいぞ

AWSのサービスをさんざん記事に振りまいてステマしてきましたが、A W S は い い ぞ 。

AWSは様々なサービスを取り揃えております。VPSでのサーバー立てではいろんなところにそれぞれ登録して連携しなければなりませんが、AWSではコンソール用のIAM一つで連携が可能です。AWSのサービスを連携するので、それぞれのサービスの設定をするときに別のサービスの設定項目に自動補完が効きます。これも作業時間を縮めれる要素ですね。

でもお高いんでしょう？という言葉をよく目にしますが、特に工夫なくオンデマンド利用をすると確かに高くなります。自分も、RDS無料枠を利かしていながら月$31かかっているのは遺憾に思っております。

ここで、安価なAWS運用に関する知見を得ましたのでご紹介します。僕の方でも実装して経費を減らしていきたいと思っております。

AWS発展系: コストを下げるためにスポットインスタンス、リザーブドインスタンスを使う

僕がAWSのコストカットについて唸っていたとき、ヒドロさんが珠玉のトゥートを投げてくださいました。

そこから、スポットインスタンスやリザーブドインスタンスという概念についてざっくりと調べて、以下の仮説を立てました。

順序としてはec2（t3.small）にスポットインスタンス、rds（t2.micro）にリザーブド1年払いの一部前払いで安くして、さらにDNSフェイルオーバーとAWSシステムマネージャーのコンボで睡眠時・マストドン見れないときにインスタンス停止する（HTL復旧時間見据えて復旧する）というダイナミック躁鬱おひとりさまインスタンスができるってわけ

スポットインスタンスやリザーブドインスタンスについての詳しい説明はここでは省きますが、要は制約が付くがその分安くなるというものです。さらに、就寝時や仕事時など、SNSを見れない時間帯はサーバーを動かすのは無駄なので、落とします（これができるのが “おひとりさま” インスタンスの長所）。

ただサーバーを落としてしまうと連合がアクセスしたときに応答を待ってしまうので、待たせないためにHTTPステータスコード503を返す静的メンテナンスページを作り、緊急連絡先を添えてDNSフェイルオーバーの仕組みを使ってメンテナンスページを表示して、連合先に対応します。DNSフェイルオーバーの仕組みも、AWSの中で実現することができます。他サービスの連携でもできますが、ちょっと骨が折れそうな空気が。

コストカットの予想ですが、多分$31 -> $17ぐらいまでには落ち着いてくれそうな気がしてます。やる作業が難しくはないながらも多いので、後手後手に回っておりますが、2018年度内には実装したいところです。カットしたコストでステーキが食べたい！

クロージング

いかがでしたでしょうか。おひとりさまインスタンスのための環境構築といいつつも、様々な方々に汎用的に使えるような記事になりました。おひとりさまインスタンス作成に及び腰になってしまっている皆様のもとへこの記事が届きましたら幸いです。

次のMastodon Advent Calendar 14日目の記事は、なちかさんの「マストドンポエム」です。ポエムはいいぞ。