Mastodonの構成の話。
ちいさなサーバは、VPSを一つ借りて、必要なプロセスを一つずつ起動して実行しています。
nginx、puma、sidekiq、node、postgresql、redisってとこかな。
nginxが外からのAPIアクセスや連合のリクエストを受け付けて、背後で実行しているMastodonのアプリケーションサーバであるpuma(mastodon-web)に処理を依頼します。
pumaは受け付けた内容を、その場で応答するものと、バックグラウンド処理にまわすものにわけます。
バックグラウンド処理は、小さなジョブに分割し、種類毎に順番待ちの列に突っ込んで、sidekiqプロセス(mastodon-sidekiq)が処理を行います。
pumaやsidekiqは、ユーザーにリアルタイムに知らせるべき内容をredisにpublish(発行)しておきます。
それをnode(mastodon-streaming)のプロセスが、現在subscription(購読)しているユーザーに対し、サーバ側からクライアント側に次々と流していきます。タイムラインがリアルタイム更新されていく仕組みです。
ずっと内容を保持しておくデータは、PostgreSQLによるデータベースに保持されています。
pumaやsidekiqからの読み書き、nodeからの読み出しを一手に引き受け、矛盾のない状態を維持しています。
redisは、みんなのホームやリストタイムラインを保持したり、pumaやsidekiqの一時的なデータをキャッシュして高速化に貢献したり、発行と購読の仕組みをサポートして発行側と購読側を橋渡しする役割を担っています。
全体の役割分担は、だいたいこんな感じです。
このほか、オプションとして、全文検索の処理を行うElasticsearchを実行する場合もあります。
Elasticsearchがあると、そのサーバでは全文検索ができるようになるのですが、Mastodon本体と同じかそれ以上にヘビーなプロセスなので、余力のあるサーバにしか設置されていません。
PostgreSQLのデータベースは、基本的には一つしか設置できません。先程までに紹介した、たくさんのプロセスからのリクエストに、矛盾無く応じる必要があるためです。
PostgreSQLと各プロセスの間に、pgbouncerなどの交通整理をするプロセスを挟むこともあります。
大規模化すると同時にたくさんの接続とリクエストが来るようになるので、pgbouncerがそれぞれと接続しておいて、PostgreSQLとの接続は少数にしぼり、交通整理して順番に流すようにする役割を果たします。
リードレプリカという、読み出しのみを受け付けるサーバを設置することもできます。
データベースの複製を作って同期し、負荷分散を図る仕組みですが、書き込まれた内容が反映するまえに古い内容を応答すると動作がおかしくなるので、適用できる条件が限定的になります。
他にもいくつか冗長化する工夫は可能ですが、比較的高度です。
プロセスの解説、有難うございます。めっちゃ勉強になります。
物理的には、各プロセスを実行する、複数台の実行環境に分割することができます。
処理能力の高いすごいサーバを借りてもいいし、小さなVPSを複数借りてもいいし、必要に応じてサーバ数を増減できる仕組みで動的に対応することも可能です。
PostgreSQLが大きくなりますので、自前設置ではなく、データベースサーバとして提供されているサービスを利用することで、安定動作やスケーリングの問題をサービス側で解決する方法もあります。めっちゃお金かかるけどね!!