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を追加しています。

あとは、二重化したりバックアップする機構です。