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がメディアの変換に使われています。
@noellabo is there any node such as puma process using docker image?
@super All configurations are without Docker.
@noellabo I see this Architecture may require modifying official code base, such as separating sidekiq read and write, which is not easy for most of admin. Anyway it looks super strong and solid and maybe we don’t need that until got 10k+ active users.
@super Fedibird has 1,082 registered users and about 600 active users. The current number of processes on sidekiq is default x 4, push x 2, pull x 2, and two VPSs with the same configuration, totaling 16 processes. If you want to scale this further, you'll probably have multiple servers handling only sidekiq. Currently, I have a little extra processing power.
Bigger server admins said redis would be a bottleneck.
@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).
@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.
Fedibirdの現在の構成図です。
基本的な構成と比較していきます。
マシンの台数を増やしています。同じ構成のサーバを2台置いて、負荷の分散・処理能力の増強、片方が落ちてもサービスが停止しないように構成しています。
データベース（PostgreSQLとRedis）は、2台が同じものを参照する必要があるので、別のマシンに分けて実行しています。
Storageは、ローカルファイルシステムだと両方のマシンから読み書きできないので、外部のオブジェクトストレージ（Amazon S3）に変更しています。
Sidekiqは、キュー毎にプロセスを分離しています。
PostgreSQLへ同時接続するプロセスがどんどん増えていくので、pgbouncerを経由して接続することで、PostgreSQL側の接続数を一定以内に制限し、接続を再利用することで効率化しています。
2台の手前にHAProxyを置いて、外部からは一つのサーバに見えるようにして、2台のサーバに接続を分散させます。
全文検索用にElasticsearchを追加しています。
あとは、二重化したりバックアップする機構です。