のえる
Mastodonの基本的な構成図です。
Mastodonをシンプルに構成すると、図のような構成になります。
一番手前にNginxを置いて、バックエンド側の、WebUIとAPI（Puma）、ストリーミング（Node）、メディアファイル（Storage）へのアクセスを中継します。
データベース（PostgreSQL）へ、Puma、Node、Sidekiqがそれぞれ接続します。
もう一つのデータベース（Redis）へ、Puma、Node、Sidekiqがそれぞれ接続します。
ローカルファイルシステム（Storage）へは、Puma、Sidekiqが読み書きを行い、Nginxが読み出してユーザーのリクエストに応えます。
PumaとSidekiqは、インストールしたrubyの環境で実行されます。
Nodeは、node.js v12〜の環境で実行されます。
Pumaは、ユーザーのブラウザに初期値とJavaScriptのコード（WebUI）を渡して、それ以降はAPI経由でやりとりします。
この他、ImageMagickやFFmpegがメディアの変換に使われています。
のえる
Fedibirdの現在の構成図です。
基本的な構成と比較していきます。
マシンの台数を増やしています。同じ構成のサーバを2台置いて、負荷の分散・処理能力の増強、片方が落ちてもサービスが停止しないように構成しています。
データベース（PostgreSQLとRedis）は、2台が同じものを参照する必要があるので、別のマシンに分けて実行しています。
Storageは、ローカルファイルシステムだと両方のマシンから読み書きできないので、外部のオブジェクトストレージ（Amazon S3）に変更しています。
Sidekiqは、キュー毎にプロセスを分離しています。
PostgreSQLへ同時接続するプロセスがどんどん増えていくので、pgbouncerを経由して接続することで、PostgreSQL側の接続数を一定以内に制限し、接続を再利用することで効率化しています。
2台の手前にHAProxyを置いて、外部からは一つのサーバに見えるようにして、2台のサーバに接続を分散させます。
全文検索用にElasticsearchを追加しています。
あとは、二重化したりバックアップする機構です。
のえる
@Gargron We have two Mastodon services running in the same configuration, but each running on a different operator's VPS.
This VPS is maintained so that Cloudflare and HAProxy can be shut down and run independently at any time. It can be directly referenced to isolate failures or to perform experiments in a production environment.
Eugen
@noellabo What's the benefit of haproxy and multiple nginx instances? My architecture is very similar except only one nginx instead of haproxy (and no cloudflare).
senooken JP Social is a social network, courtesy of senooken. It runs on GNU social, version 2.0.2-beta0, available under the GNU Affero General Public License.
All senooken JP Social content and data are available under the Creative Commons Attribution 3.0 license.