ずっと内容を保持しておくデータは、PostgreSQLによるデータベースに保持されています。
pumaやsidekiqからの読み書き、nodeからの読み出しを一手に引き受け、矛盾のない状態を維持しています。
redisは、みんなのホームやリストタイムラインを保持したり、pumaやsidekiqの一時的なデータをキャッシュして高速化に貢献したり、発行と購読の仕組みをサポートして発行側と購読側を橋渡しする役割を担っています。
全体の役割分担は、だいたいこんな感じです。
このほか、オプションとして、全文検索の処理を行うElasticsearchを実行する場合もあります。
Elasticsearchがあると、そのサーバでは全文検索ができるようになるのですが、Mastodon本体と同じかそれ以上にヘビーなプロセスなので、余力のあるサーバにしか設置されていません。
PostgreSQLのデータベースは、基本的には一つしか設置できません。先程までに紹介した、たくさんのプロセスからのリクエストに、矛盾無く応じる必要があるためです。
PostgreSQLと各プロセスの間に、pgbouncerなどの交通整理をするプロセスを挟むこともあります。
大規模化すると同時にたくさんの接続とリクエストが来るようになるので、pgbouncerがそれぞれと接続しておいて、PostgreSQLとの接続は少数にしぼり、交通整理して順番に流すようにする役割を果たします。
リードレプリカという、読み出しのみを受け付けるサーバを設置することもできます。
データベースの複製を作って同期し、負荷分散を図る仕組みですが、書き込まれた内容が反映するまえに古い内容を応答すると動作がおかしくなるので、適用できる条件が限定的になります。
他にもいくつか冗長化する工夫は可能ですが、比較的高度です。
プロセスの解説、有難うございます。めっちゃ勉強になります。
さて、ある程度の大きさのサーバになったら、これらのプロセスを複数用意して、よりたくさんの処理を捌けるように構成する必要があります。
nginxは、pumaが複数あるときには、処理を分散して引き渡す役割を果たします。応答してこないpumaがあったら他に割り振ることで、全体が一度にダウンしないようにする安全を担保する役割も果たしています。
sidekiqは、元々小さなジョブに分割された処理を実行するエンジンなので、たくさんあれば、それだけ同時にたくさんの処理ができます。
ジョブは種類でわけられているので、種類別のsidekiqを立てて、役割を分割することができます。
一番大事なローカルユーザーに応答する処理と、リモートサーバに配送する処理、リモートサーバから受けたリクエストに対応する処理など、別々にわけることで、負荷が高くなったときに、どの処理を優先し、どの処理に処理能力を配分するか、調整することもできます。
nodeは、redisの発行と購読の仕組みのおかげで、プロセスをたくさん起動しても、分散して対応することができます。
redisは、役割に応じて3つまで分割できます。最近は、redisの冗長化機能も使えるようになったようです。