マストドンサーバーのスケーリング方法

2年 ago

芽依, 雨夜

8 minutes

著者は、寄付プログラム「Write for Donations」の一環として、The Apache Software FoundationとFree and Open Source Fundを寄付の受取先として選びました。

イントロダクション

マストドンはオープンソースのセルフホスト型ソーシャルネットワークです。
マストドンはフェデレーテッドされており、複数のマストドンのインスタンスが相互運用できるため、異なるサーバーのユーザー同士がコミュニケーションを取り合ってフェディバースというネットワークを作ります。
フェディバースはActivityPubプロトコルを使用してお互いに通信する相互接続されたサーバーのネットワークです。

Mastodonコミュニティが急速に成長するにつれて、サーバーへの負荷も増えています。過去1年間、ピーク時のユーザーアクティビティにより、Mastodonサーバーがダウンしてしまう事例が数多く発生しました。ユーザーの急増によるMastodonサーバーのダウンを防ぐためには、スケールする必要があります。

次に示す内容を日本語で言い換えます（1つのオプションのみ）:
オプションとして、オブジェクトストレージを使用することで、静的メディアファイルのパフォーマンスが大幅に向上し、Webサービスの負荷が軽減できます。パフォーマンスの向上はないものの、ElasticSearchを使用すれば全文検索が可能になり、LibreTranslateを利用すればサーバーがメッセージを自動的に翻訳できるようになり、サーバーが少しだけ便利になります。

Note

注意：Mastodonのサービスはデータストレージ（RedisとPostgreSQL）を通じてのみ通信します。これにより、分散設定において大きな柔軟性が提供されますが、適切な設定なしに単にコンポーネントを複数のマシンに分散させるだけでは、望ましい性能向上は得られません。

このチュートリアルでは、あなたのマストドンサーバーにおける異なるスケーリング技術について学びます。

Increasing the database resources and available connections
Splitting Sidekiq queues into multiple processes
Configuring threads and resources for each Sidekiq queue
Adding object storage to unload Web service
Increasing threads and processes of Web service

Mastodonサーバーの拡張を計画していて、アクティブなユーザーの需要に対応するためにスケールする場合、全ての記事を確認して各コンポーネントをスケーリングすることをおすすめします。
一方で、特定のコンポーネントをスケールすることを目的としている場合は、各コンポーネントの節に直接移動してください。
基本的なルールは、Mastodonの各コンポーネントを実行している各マシンの平均負荷を約60-70％に保つことです。時には、適切なサービスの設定が低パフォーマンスや低い平均負荷を引き起こすこともあります。
以下の各節には、そのような状況を検出するための症状が記載されています。

Note

注意：この記事には、systemd サービス (たとえば Mastodon vServer 1-Click) 上で実行される Mastodon サーバーの例が含まれています。他の種類の Mastodon セットアップ (Docker、K8s など) をご利用の場合は、対応する構成方法をご検討ください。

データベースのパフォーマンスを向上させる

PostgreSQLは、マストドンサーバーの主要な真実の情報源です。ユーザーの資格情報、トゥート、ブースト、ユーザー関係などがすべて含まれています。データベースのセキュリティを確保し、バックアップを作ることは、最も重要なことです。

マストドンはデータベースへの膨大な数の接続を使用しています。接続が不足すると、Sidekiqのパフォーマンスが低下し、フィードの更新が数時間遅れ、全体的な遅さが生じ、サーバー自体にアクセスできなくなる可能性もあります。

このセクションでは、サーバーに必要な接続数を計算し、それに応じてデータベースを設定します。余分なリソースを必要とせずに、接続が足りなくなることを防ぎ、全てのMastodonサービスのパフォーマンスに影響を与えることを防ぎます。

Info

情報：あなたのMastodonサーバーに必要な接続数は、PostgreSQLのmax_connections変数を絶対に超えてはなりません。また、データベースの競合を避けるために、max_connectionsはできるだけ少なくする必要があります。

あなたのマストドンサーバーに必要な総接続数を計算するには、各コンポーネントによって必要な接続数を計算する必要があります。

For every Web service instance, the required connections are MAX_THREADS multiplied by WEB_CONCURRENCY.
For every StreamingAPI instance, the required connections are the STREAMING_CLUSTER_NUM multiplied by the DB_POOL.
For every Sidekiq instance, the required connections equal the DB_POOL.

Info

情報：上記のすべての変数は、対応するコンポーネントの環境で見つけることができます。以下の記事では、ここにリストされているすべての変数と共に作業します。

それらの数値を合計して、メンテナンス用に20つの接続を追加してください。これがmax_connectionsの値です。

Info

情報：Mastodonをスケールするためには、データベースの適切な設定が最優先ですが、max_connectionsの数を決定するためには、まず他のサービスをどのようにスケールさせるかを知る必要があります。
他のサービスをスケールさせる計画を作成した後（次のセクションで見つけることができます）、ここに戻ってmax_connectionsの計算を完了させることができます。

最大接続数の値がわかったので、それを使ってデータベースを設定します。

PGTuneというサービスを使用すると、設定を生成するのに良い方法です。
PGTuneのページを開くと、値を入力する必要がある設定フィールドが表示されます。

DB Version: Specify here the version of PostgreSQL that your Mastodon server uses. You can find it by using this command on the machine running PostgreSQL:

pg_config –version

OS Type: Operating system of the machine which runs PostgreSQL.
DB Type: Type of workload your PostgreSQL will perform. In the case of Mastodon, choose Online Transaction Processing System (OLTP in the future) since Mastodon creates tons of connections.
Total Memory (RAM): Amount of memory PostgreSQL will use. Try to allocate up to half of the physical memory of a machine, but if other services are running on the same machine – make sure not to exceed the total RAM. For example, on a machine with 8 GB of RAM and just PostgreSQL, we specify 4 GB in PGTune.
Number of CPUs: Amount of CPU cores that PostgreSQL will use. Since OLTP is CPU bound, we highly recommend setting this number as high as the number of CPU threads your machine supports.
Number of Connections: max_connections goes here.
Data Storage: Type of data storage device on the machine which runs PostgreSQL.

たとえば、8 GBのRAMを搭載したマシンで、8スレッドと最大接続数420の設定の場合、配置は次のようになります。

「生成」をクリックすると、postgresl.conf ファイルに追加する必要のある設定パラメータが送信されます。

あなたのPostgreSQLを実行しているマシンで、postgresql.confを開きます。

sudo nano /etc/postgresql/major version of your PostgreSQL/main/postgresql.conf

たとえば、PostgreSQLのバージョン15.xを実行している場合、このファイルの場所は/etc/postgresql/15/main/postgresql.confになります。

次に、PGTuneによって生成された各パラメーターについて、postgresql.confで同じパラメーターを検索し、その値を変更します。nanoではCtrl+Wを使用して検索し、vi/vimではEsc+/を使用してください。postgresql.confに存在しない場合は、ファイルのどこにでも作成することができます。

Example of searching parameter in postgresql.conf

最後に、変更を適用するためにPostgreSQLサービスを再起動してください。

sudo service postgressql restart

今、あなたはMastodonのパフォーマンスを向上させるためにPostgreSQLを設定し、新しい設定を適用する方法を知っています。次のセクションでは、max_connectionsを計算するために必要なすべての変数の正確な値が示されています。

Sidekiqキューの完璧化

SidekiqはRubyのジョブスケジューラーであり、ワーカーです。このツールは、投稿のサーバー間伝播、リンクのプレビュー生成、いいねの処理など、バックグラウンドでのジョブ実行を担当しています。

Sidekiqでは、ジョブのキューマネージャーとしてRedisを使用し、ジョブの結果を保存するためにPostgreSQLを使用しています。複数のサーバーが接続されている場合（ユーザーが他のサーバーのユーザーをフォローしている場合）、必要なデータを1つのサーバーから別のサーバーに伝播するために多くのジョブが作成されます。

Sidekiqのボトルネックの症状には、フィードの更新における遅延が長くなること、詰まったSidekiqキュー、そして持続的なデータベースの負荷が含まれます。

このセクションでは、サーバーに必要なSidekiqキューのサイズと、それを動作させるために必要な物理的なマシンの数をおおよそ求めます。

マストドンには、Sidekiqの複数のキューがあります。しかし、その中にはリソースをより多く消費し、CPUを完全に負荷させるキューもありますが、他のキューはほとんど負荷をもたらしません。以下の表には、マストドンに必要なすべてのキューとそのリソースの優先度が記載されています。ハイプライオリティのキューは、ロープライオリティと比較してより多くのCPUを使用します。

Queue	Priority	Role
default	Highest	Handles all tasks that affect local users.
ingress	High	Handles incoming remote activities. Lower priority than the default queue so local users still see their posts when the server is under load. Keep in mind, the `ingress` queue is highly CPU intense.
push	Medium	Delivers payloads to other servers.
pull	Medium	Handles tasks such as handling imports, backups, resolving threads, deleting users, and forwarding replies.
mailers	Low	Delivers emails.
scheduler	Lowest	Manages cron jobs such as refreshing trending hashtags and cleaning up logs.

Warning

警告：スケジューラキューは複数のプロセスにスケーリングしてはなりません。Mastodonサーバーでは、スケジューラを実行するプロセスは1つだけ存在する必要があります。

上記のテーブルは、マシンを適切に割り当てるのに役立ちますが、キュー自体の設定はどうですか？キューは、効果的にサービスを提供できるアクティブユーザーの数に制限があり、この制限は特定のキューが持つスレッド数に関連しています。割り当てられたスレッド数が多ければ、特定のキューが処理できるアクティブユーザーも多くなります。また、キューの種類によってもこの制限は影響を受けます。一部のキューは、他のキューと比較して同じ数のユーザーを処理するためにより少ないスレッドを必要とします。この多次元関係は、以下のグラフで説明されています。

サーバーコミュニティによって、プッシュキューやプルキューの優先順位は異なる場合があります。他の連邦と高度に連携しているコミュニティの場合は、プッシュキューに優先度を与えるべきです。一方、サーバーが特定の興味のある地域に特化している場合は、ローカルなアクティビティが多く発生するため、プルに優先度を与えることができます。

Note

注意：異なるサーバーは異なる使用パターンと負荷分散を持っています。他のサーバーからのユーザーがユーザーを応援したり、好意を示す可能性を分析して、自分のサーバーの使用パターンを予測してみてください。

例えば、もしもあなたのサーバーが特定の科学のトピックをカバーしている場合は、あなたのサーバーのユーザー同士が主にコミュニケーションを取るでしょう。一方で、もしもあなたのサーバーが個人の政治ブログである場合は、ユーザー同士が他の政治家をサポートする可能性が高くなるかもしれません。Mastodonの管理者として、自身のサーバーの負荷を監視し、コンポーネントを適切にスケーリングする必要があります。

Sidekiq parameters to resources relation

Warning

警告: 一つのSidekiqサービスで50スレッド以上は使用しないでください。60スレッドを処理する場合は、それぞれ30スレッドの2つのサービスを実行してください。

例えば、私たちはローカルフェデレーションのみを主に利用するアクティブユーザーが15000人いると推定しています。
上記のグラフによれば、私たちは以下が必要です。

default: about 70 threads total, 2 services 35 threads each.
ingress: about 50 threads total, 2 services 25 threads each.
pull: about 40 threads total, 1 service with all 40 threads.
push: about 30 threads total, 1 service with all 35 threads.
mailer: about 20 threads total, 1 service with all 20 threads.
scheduler: 5 threads total, 1 service with all 5 threads.

私たちのユーザーは外部連携をあまり使っていないため、私たちはプッシュではなくプルキューに優先度を置くことにしました。

スケジューラキューは最も優先度が低いキューなので、デフォルトキューと一緒に実行することができます。デフォルトキューには影響を与えず、合計で70 + 5 = 75のスレッドが必要で、おおよそ8GBのRAMが必要です。ヘビーなキューが1つだけなので、4コア8GBのマシンを使用することができます。

イングレスとメーラーは高優先度と低優先度のキューであり、単一のデフォルトキューよりも少ないCPUリソースを必要としますが、依然として4コアのマシンを使用します。それらのために必要な合計スレッド数は25 + 20 = 45で、おおよそ6GBのRAMが必要です。

プルキューとプッシュキューはどちらも中程度の優先度であり、イングレスやメーラーよりも少しCPUを多く使用しますので、再び4コアを使用します。必要なスレッド数は40 + 30 = 70で、おおよそ8GBのRAMが必要です。

要約すると、15000人のアクティブユーザーに対応するために、Sidekiqの設定には合計で3台のマシンが必要です。

A 4c/8GB machine to serve 2 services of the default queue with 35 threads each and 1 service of scheduler queue with 5 threads.
A 4c/8GB machine to serve 1 service of ingress queue with 50 threads and 1 service of mailer queue with 20 threads.
A 4c/6GB machine to serve 1 service of pull queue with 40 threads and 1 service of push queue with 30 threads.

Note

注意：必要なコア数を確定する最も良い方法は、Sidekiqを実行しているマシンの平均負荷を観察することです。
平均負荷が80％を超える場合、より多くのCPUコアが必要です。もしコア数がすでに十分に多い場合（たとえば8コア以上）、同じ構成の別のマシンを作成して負荷分散せずに、スケーリングの別の次元を手に入れることができます。スケジューラーキューを2回以上実行しないように忘れずに。

スケーリングのためのSidekiqの拡張

ハードウェアリソースを最大限に活用するためには、Sidekiqは適切な数のスレッドで構成され、プロセスレベルでスケーリングする必要があります。このセクションでは、Sidekiqキューのスレッド数を正確に設定する方法や、サービステンプレートを使用して同じマシン上で複数のキューを実行する方法について説明します。

Note

注意：以下の例は、systemdサービスのExecStartまたはDockerのコマンドフィールドに直接記述することができます。Dockerを使用している場合は、Dockerファイルの変更後にコンテナを再ビルドする必要があります。

単一のSidekiqプロセスで使用されるスレッド数を増やす

サービスは、systemdが管理し、ログを記録し、自動的に再起動するなどのリソースです。実行ファイルをサービスにラッピングすることは、アプリケーションを展開する最も簡単な方法の1つです。Systemdサービスは、Sidekiqキューを実行する最も一般的な方法です。
Sidekiqサービスの場所は、Mastodonインストールのタイプによって異なります。たとえば、Mastodon vServer 1-Clickを使用している場合、Sidekiqサービスファイルは次の場所にあります。

cat /etc/systemd/system/mastodon-sidekiq.service

「サービスファイルの先頭をさっくり確認しましょう。」

[Unit]
Description=mastodon-sidekiq
After=network.target

[Service]
Type=simple
User=mastodon
WorkingDirectory=/home/mastodon/live
Environment="RAILS_ENV=production"
Environment="DB_POOL=25"
Environment="MALLOC_ARENA_MAX=2"
Environment="LD_PRELOAD=libjemalloc.so"
ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 25
...

[Install]
WantedBy=multi-user.target

私達の注意は、特に「ExecStart」と「Environment」の2つの分野に集中する必要があります。
「ExecStart」は、サービスの開始または再起動時に実行されるサービスの起点を定義します。
「Environment」は、ExecStartに渡される環境変数を定義します。

一つのSidekiqプロセスのスケーリングには、Sidekiqが使用するスレッドの数を増やす必要があります。この数は、ExecStartフィールドの-cパラメータで制御されます。-cパラメータとDB_POOL環境変数を同期させることを忘れないでください。
例えば、スレッド数を45に増やします。-cパラメータとDB_POOLの値を変更します。

[Unit]
Description=mastodon-sidekiq
After=network.target

[Service]
Type=simple
User=mastodon
WorkingDirectory=/home/mastodon/live
Environment="RAILS_ENV=production"
Environment="DB_POOL=40"
Environment="MALLOC_ARENA_MAX=2"
Environment="LD_PRELOAD=libjemalloc.so"
ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 40
...

[Install]
WantedBy=multi-user.target

Info

情報：DB_POOL環境変数は常に-cパラメーターと同じ値（上記例では40）にする必要があります。それを小さくすると、Sidekiqのパフォーマンス問題が発生し、大きくするとデータベースに追加負荷がかかる可能性があります。

サービスファイルに変更を加えた後は、ユニットファイルを再読み込みしてSidekiqサービスを再起動することを確認してください。

sudo systemctl daemon-reload
sudo systemctl restart mastodon-sidekiq.service

このセクションの変更を適用することで、Sidekiqが使用するスレッドの数が増え、より多くのユーザーへの対応が可能になりました。

単一のSidekiqインスタンスに特定のキューを指定する

最初に、デフォルトのSidekiqサービスファイルを分析しましょう。Mastodon vServer 1-Clickを使用している場合、Sidekiqサービスファイルはこの場所にあります。

cat /etc/systemd/system/mastodon-sidekiq.service

ご存知の通り、マストドンはSidekiqのデータを複数のキューに分割しています。サービスファイルではデフォルトでキューが明示的に指定されていません。

[Unit]
Description=mastodon-sidekiq
After=network.target

[Service]
Type=simple
User=mastodon
WorkingDirectory=/home/mastodon/live
Environment="RAILS_ENV=production"
Environment="DB_POOL=25"
Environment="MALLOC_ARENA_MAX=2"
Environment="LD_PRELOAD=libjemalloc.so"
ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 25
...

[Install]
WantedBy=multi-user.target

明示的なキューがない場合、Sidekiqはいくつかのデフォルトの優先順位ですべてのキューを処理します。Sidekiqの単一インスタンスですべてのキューを実行することは、リソースを多く消費するため理想的ではありません。
実現したいのは、Sidekiqのキューを複数のインスタンスに分割することです。これにより、各キューのスレッド数を正確に指定できるようになり、複数のマシンで異なるキューを実行できるようになります。
デフォルトのSidekiqの動作を上書きするには、ExecStartフィールドに-qパラメータを追加するだけで良いでしょう。

例えば、Sidekiqは入口キューのみを処理するように設定しましょう。

[Unit]
Description=mastodon-sidekiq
After=network.target

[Service]
Type=simple
User=mastodon
WorkingDirectory=/home/mastodon/live
Environment="RAILS_ENV=production"
Environment="DB_POOL=25"
Environment="MALLOC_ARENA_MAX=2"
Environment="LD_PRELOAD=libjemalloc.so"
ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 25 -q ingress
...

[Install]
WantedBy=multi-user.target

「-q ingress」と指定することで、Sidekiqにはイングレスキューのみを処理させ、他のキューは処理しないようにします。

Warning

警告: 上記の例では、入口以外のすべてのキューが処理されなくなり、Mastodonが正常に動作しなくなります。少なくとも各キューを一度カバーするようにしてください。次のセクションには、シングルマシン上で複数のSidekiqサービスのインスタンスを実行する方法に関するガイダンスが含まれています。

Sidekiqサービスが単一のキューのみを処理することにはいくつかの利点があります。特定のキューのログを処理しやすくなりますし、キューごとの管理とスレッド制御が可能です。また、異なるマシン上で異なるキューを実行することで分散セットアップが可能となります。全体的には、Sidekiqキューのスケーリングにおいて主要なプラクティスとされています。
ただし、すべてのハードウェアリソースを単一のキューに与えることが常に効率的とは限りません。そのため、次のセクションでは、単一のマシン上で複数のキューを個別に実行する方法を学びます。

シングルマシン上で複数のSidekiqインスタンスを実行するためにテンプレートを使用する

単一のインスタンスでのSidekiqの実行は効率的ではありません。さらにSidekiqをスケーリングするためには、複数のインスタンスを同時に実行できます。
systemdサービスがSidekiqを実行する最も一般的な方法であるため、単一のマシン上で複数のインスタンスを実行するためのサービステンプレートの作成方法を学びます。

サービステンプレートを使用することで、1つのサービスファイルから複数のサービスを作成することができます。

最初に、既存のSidekiqサービスファイルのコピーを作成しましょう。

cp /etc/systemd/system/mastodon-sidekiq.service /etc/systemd/system/mastodon-sidekiq-template.service

これにより、既存のSidekiqサービスのコピーであるmastodon-sidekiq-template.serviceという新しいファイルが作成されます。
このコピーをテンプレートに変換するために、テンプレート指定子を使用します。この記事では、特定の二つの指定子、%iと%jを使用します。

%i is the instance name. For instantiated services, this is the string between the first “@” character and the type suffix.
%j is the final component of the prefix. This is the string between the last “-” and the end of the prefix name.

わかりにくいですか？それでは、実践的な部分に飛び込んで、より理解しましょう。

最初に、編集するために新しいサービスファイルを開いてください。

sudo nano /etc/systemd/system/mastodon-sidekiq-template.service

サービスファイル内の値をテンプレート指定子に変更してください。

The description field should contain %j specifier for easier tracking and maintenance of service.
DB_POOL environment variable should be equal to %i specifier.
-c parameter in ExecStart should be equal to %i
-q parameter in ExecStart should be equal to %j

/etc/systemd/system/mastodon-sidekiq-template.serviceの内容を日本語で表現します。

[Unit]
Description=mastodon-sidekiq-%j-queue
After=network.target

[Service]
...
Environment="DB_POOL=%i"
Environment="MALLOC_ARENA_MAX=2"
Environment="LD_PRELOAD=libjemalloc.so"
ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c %i -q %j
...
[Install]
WantedBy=multi-user.target

推測する通り、%i指定子はSidekiqのスレッド数を含んでおり、%j指定子はSidekiqキューの名前を含んでいます。

Substitution of specifiers from the service file

このテンプレートを使用して、望むSidekiqの設定に合わせたサービスファイルを作成しましょう。

最初に、このマシンで実行したいキューを指定するためにテンプレートをコピーしてください。たとえば、デフォルトキューとスケジューラーキューを実行する場合は以下のようにしてください。

cp /etc/systemd/system/mastodon-sidekiq-template.service /etc/systemd/system/mastodon-sidekiq-default@.service
cp /etc/systemd/system/mastodon-sidekiq-template.service /etc/systemd/system/mastodon-sidekiq-scheduler@.service

キューの名前には、デフォルト、イングレス、プッシュ、プル、メーラー、スケジューラーのいずれかを使用することができます。

@シンボルの後に何も指定しなかったことに気づいたかもしれません。それは、サービス自体を有効にする際に、このパラメーターを指定するからです。
新しいサービスを有効化するために、デフォルトキューに20スレッド、スケジューラキューに5スレッドを使用しましょう。

sudo systemctl enable mastodon-sidekiq-default@20.service
sudo systemctl enable mastodon-sidekiq-scheduler@5.service

最後に、新しいサービスを有効にしたら、次のコマンドを使用してすべてを一度に実行することができます。

sudo systemctl start mastodon-sidekiq*

この段階では、テンプレートのサービスファイルを作成し、それを使用して異なるキューとスレッドを持つ複数のSidekiqサービスを実行することに成功しました。

実行中のテンプレートサービスの設定を変更する。

例えば、テンプレートで作成されたデフォルトのサービスのスレッド数を20から40に変更したい場合は、まず既存のサービスを無効にする必要があります。

sudo systemctl stop mastodon-sidekiq-default.service
sudo systemctl disable mastodon-sidekiq-default@20.service

停止コマンドでは、スレッド数のみを指定しながらも、無効化コマンドではその点に注目してください。

古いプッシュサービスを無効にした後、新しいサービスを20ではなく40のスレッドで作成できます。

sudo systemctl enable mastodon-sidekiq-default@40.service
sudo systemctl start mastodon-sidekiq-default.service

この時点で、既存のsystemdサービスのスレッド数を正常に変更しました。

同じSidekiqキューの複数のサービスを実行する

ご存知の通り、Sidekiqの1つのインスタンスには50スレッド以上設定しないようにしてください。特定のキューに60スレッドを実行する場合、それを2つのサービスに分割して、それぞれ30スレッドに設定する必要があります。

それを達成するために、同じキューでテンプレートを複数回コピーする必要がありますが、インデックスを追加します。インデックスは、各サービスファイルを識別するための単純な番号です。
初期テンプレートを複数回コピーし、同じキューが繰り返されるたびにインデックスを増やします。例えば、デフォルトキューのサービスファイルを2つ作成する場合：

cp /etc/systemd/system/mastodon-sidekiq-template.service /etc/systemd/system/mastodon-sidekiq-1-default@.service
cp /etc/systemd/system/mastodon-sidekiq-template.service /etc/systemd/system/mastodon-sidekiq-2-default@.service

Warning

警告：/etc/systemd/system/mastodon-sidekiq-default-2@serviceの名前の後にインデックスを追加しないでください。これによってテンプレートは2をキューの名前として処理し、必ず失敗します。インデックスはキューの名前の前にのみ挿入してください。

では、デフォルトキューの最初のインスタンスには40スレッドを有効にし、2番目のインスタンスには60スレッドを有効にしましょう。

sudo systemctl enable mastodon-sidekiq-1-default@40.service
sudo systemctl enable mastodon-sidekiq-2-default@60.service

最終的に、サービスを有効にした後は、以下のコマンドを使用してすべてを実行できます。

sudo systemctl start mastodon-sidekiq*

この時点では、同じキューの複数のインスタンスを正しく作成することができ、大量のスレッドを適切に分割することができます。

複数の方法を学んで、Sidekiqサービスの設定方法があります。状況によっては、単一のデフォルトサービスだけで十分な場合もありますが、他の場合では1台のマシン上で複数のサービスが必要になることもありますし、複数のマシン上で同じキューの複数のサービスが必要な場合もあります。すべてのケースは、サポートしたいアクティブユーザーの数に依存します。

オブジェクトストレージを追加する。 (Obujekuto sutorēji o tsuika suru.)

オブジェクトストレージ、または単にバケットと呼ばれるものは、ユーザーがサーバーにアップロードしたメディアファイルを保存することができます。写真、動画、GIF、音声ファイルなどを含みます。

ファイルシステムからオブジェクトストレージへの移行は、ストレージの速度と容量を向上させるだけでなく、Mastodon サービスへの負荷を軽減します。さらに、ほとんどのクラウド提供のオブジェクトストレージは、CDN も提供しており、メディアファイルをユーザーにより高速に配信します。

注意：MastodonはS3互換のインターフェースを使用しているため、オブジェクトストレージプロバイダはS3インターフェースをサポートし、S3ストレージの資格情報のマッピングを提供する必要があります。

もしMastodonの初期設定中にオブジェクトストレージの設定をうっかり見落としてしまった場合、オブジェクトストレージはWebサービスのみで使用されるため、必要な変数を直接Webサービスを実行しているマシンの設定に追加することができます。

Warning

注意：オブジェクトストレージを変更すると、サーバー上の既存のメディアファイルがすべて失われます。

Webサービスを実行中のマシンで、お好みのテキストエディターで.env.productionファイルを開いてください。Mastodon vServer 1-Clickを使用している場合、env.productionは/home/mastodon/liveにあります。

sudo nano .env.production

ハイライトされたテキストを自分の情報で置き換えて、以下の行を.env.productionファイルの任意の場所に追加してください。これらの変数がすでに存在する場合は、オブジェクトストレージがセットアップ中に設定されていることを意味しますが、値が誤っている場合でも変更することができます。

.env.production
環境変数.production

...
S3_ENABLED=true
S3_PROTOCOL=https
S3_BUCKET=your bucket name
S3_REGION=your bucket region
S3_HOSTNAME=your bucket hostname
S3_ENDPOINT=your bucket endpoint
AWS_ACCESS_KEY_ID=your bucket secret ID
AWS_SECRET_ACCESS_KEY=your bucket secret key
...

上記の変数はS3インターフェース接続パラメーターを表しています。オブジェクトストレージプロバイダーからの接続パラメーターには正しいS3マッピングを使用してください。

エディタを保存して終了してください。

変更を保存した後、Webサービスを再起動することを必ず確認してください。

sudo systemctl restart mastodon-web.service

自動セットアップの失敗、人為的なミス、もしくは手動インストールの場合に、Mastodonのオブジェクトストレージを手動で設定する方法がわかりました。オブジェクトストレージは、MastodonのWebサービスへの負荷を軽減し、サーバー上のメディアファイルのアップロード/ダウンロード速度を向上させるのに役立ちます。

ウェブサービスのスケーリング

Webサービスは、MastodonのUIを提供し、ユーザーからのリクエストを処理するためのRuby-on-RailsのHTTPSサーバーです。Webサービスの負荷はアクティブユーザーの数に比例しています。各スレッドは同時に1つのリクエストに応答することができます。すべてのスレッドが忙しい場合、次のリクエストは待機する必要があります。リクエストが長時間待機している場合、タイムアウトエラーでキャンセルされます。Webサービスのボトルネックは、長時間にわたるリクエスト処理時間によって特定できます：ページの読み込みが遅い、投稿が遅れて作成される、またはログにタイムアウトエラーが表示されるなど。

Warning

警告：WebサービスはHTTPSのみを適用しており、つまり、Webサービスをホストする複数のマシン間の負荷分散器でSSL終了を使用することはできません。

Webサービスでのユーザー処理量を増やすためには、サービスが使用するスレッドの総数を増やす必要があります。これは、WEB_CONCURRENCY（ワーカーの数）および/またはMAX_THREADS（ワーカー当たりのスレッド数）の環境変数を増やすことで実現できます。各ワーカーにはMAX_THREADS数のスレッドがあり、スレッドの総数はWEB_CONCURRENCY（ワーカー数） × MAX_THREADS（ワーカー当たりのスレッド数）となります。

MAX_THREADSを増やすと、より多くのCPUを消費する傾向がありますが、WEB_CONCURRENCYを増やすと、より多くのRAMを消費する傾向があります。Mastodonバージョン4.0.2の場合、単一のワーカーには平均2〜3GBのRAMが必要とされています。上記の例でWEB_CONCURRENCY = 3の場合、必要なRAMの推定量は9GBです。
MAX_THREADSについては、15などの一般的な値から開始し、CPU使用率が平均70％になるまで増やしてみることをおすすめします。これは、Webサービスを実行しているマシンを観察して、さらにスレッドを追い込めるかどうかを理解する必要があるということを意味します。

Note

注意：以下はsystemdウェブサービスの設定の一部を示しています。もしあなたが他の技術（Docker、K8sなど）を使用してウェブサービスを実行している場合は、WEB_CONCURRENCYとMAX_THREADS変数を、その技術環境の仕様に合わせて調整してください。

最初に、ウェブサービスのファイルを開きましょう。

sudo nano /etc/systemd/system/mastodon-web.service

見るものは、次のようなWebサービスのsystemdファイルです。

次のフレーズを日本語で自然な文に言い換えます。１つのオプションを提供します：

「/etc/systemd/system/mastodon-web.service」

[Unit]
Description=mastodon-web
After=network.target

[Service]
...
Environment="LD_PRELOAD=libjemalloc.so"
ExecStart=/home/mastodon/.rbenv/shims/bundle exec puma -C config/puma.rb
ExecReload=/bin/kill -SIGUSR1 $MAINPID
...
[Install]
WantedBy=multi-user.target

ExecStart フィールドの直前に、WEB_CONCURRENCY と MAX_THREADS 変数を使用して2つの追加フィールドを追加してください。

/etc/systemd/system/mastodon-web.serviceを日本語で表現する:

[Unit]
Description=mastodon-web
After=network.target

[Service]
...
Environment="LD_PRELOAD=libjemalloc.so"
Environment="WEB_CONCURRENCY=your concurrency value"
Environment="MAX_THREADS=your threads value"
ExecStart=/home/mastodon/.rbenv/shims/bundle exec puma -C config/puma.rb
ExecReload=/bin/kill -SIGUSR1 $MAINPID
...
[Install]
WantedBy=multi-user.target

これらの新しいフィールドは、WEB_CONCURRENCYとMAX_THREADSのデフォルト値を、独自の値で上書きします。

エディタを保存して終了してください。

変更を保存した後に、ユニットファイルを再読み込みし、サービスを再起動してください。

sudo systemctl daemon-reload
sudo systemctl restart mastodon-web.service

Note

注意：2017年以降、Webサービスのパフォーマンスはほぼ倍増しましたので、ハードウェアの使用状況を監視し、必要に応じてリソースの割り当てを増減することを強くおすすめします。

現時点では、Webサービスの設定のデフォルト値を増やしました。これにより、Mastodonのフロントエンドはより多くのアクティブユーザーをサポートするようになりました。大量のユーザー流入時に、Mastodonサーバーがスロットルされないようにするために、常に余分なパフォーマンス余裕を持つことを心に留めてください。

ストリーミングAPIのスループットを向上させる。

StreamingAPIは、リアルタイムの更新のためのAPIを提供するNodeJSサーバーです。ユーザーは、サーバーから直接イベントのストリームを受け取ることができます。StreamingAPIは、同時に提供できるユーザーの数に制限があります。制限は、STREAMING_CLUSTER_NUM環境変数に結び付けられています。

サービスログを見ることで、StreamingAPIのボトルネックが特定できます。もしログにnode[1201554]: ERR! error: sorry, too many clients alreadyというエラーメッセージが表示されている場合、StreamingAPIを使用しているユーザー数が処理できる限界を超えており、新たなユーザーは自動的に切断されていることを意味します。

ストリーミングAPIのスケーリングは非常に簡単です。
STREAMING_CLUSTER_NUMの環境変数を増やすと、ストリーミングAPIはより多くのユーザーにサービスを提供できます。
もしログに「エラー：すでに多くのクライアントが存在しています」というメッセージがたくさん表示される場合は、STREAMING_CLUSTER_NUMを1.5倍から2倍程度増やしてください。
たとえば、現在のSTREAMING_CLUSTER_NUMの設定が2である場合は、この変数を4に更新してください。

StreamingAPIを実行しているマシンで、StreamingAPIサービスファイルを開いてください。

sudo nano /etc/systemd/system/mastodon-streaming.service

「STREAMING_CLUSTER_NUM」変数の値を編集してください。

以下の文を日本語で言い換えると：
「/etc/systemd/system/mastodon-streaming.service」

[Unit]
Description=mastodon-streaming
After=network.target

[Service]
...
Environment="STREAMING_CLUSTER_NUM=your new value"
ExecStart=/usr/bin/node ./streaming
...

ファイルを保存し、変更を保存したあとにユニットファイルを再読み込みし、サービスを再起動してください。

sudo systemctl daemon-reload
sudo systemctl restart mastodon-streaming.service

さらに、デフォルトではStreamingAPIにはDB_POOL変数が設定されていません。この変数が明示的に設定されていない場合、StreamingAPIは10つの接続を使用します。DB_POOL変数を明示的に増やすこともできますが、STREAMING_CLUSTER_NUM変数を増やさない場合は、StreamingAPIサービスファイルで新しい環境変数を簡単に作成することができます。

StreamingAPIを実行しているマシンで、StreamingAPIサービスファイルを開いてください。

sudo nano /etc/systemd/system/mastodon-streaming.service

新しい環境変数DB_POOLを追加してください。

/etc/systemd/system/mastodon-streaming.serviceを日本語で言い換えると、以下の通りです:
マストドンストリーミング.service

[Unit]
Description=mastodon-streaming
After=network.target

[Service]
...
Environment="DB_POOL=your value"
Environment="STREAMING_CLUSTER_NUM=your value"
ExecStart=/usr/bin/node ./streaming
...

変更を保存した後は、ファイルを保存し、ユニットファイルを再読み込みしてサービスを再起動してください。

sudo systemctl daemon-reload
sudo systemctl restart mastodon-streaming.service

これにより、DB_POOLのデフォルト値が上書きされ、StreamingAPIのインスタンスに必要なデータベース接続の数がより明確になります。

Note

注意：明示的にDB_POOLの値を指定しない場合、max_connections変数の計算にはDB_POOLの値として10を使用してください。

現在、StreamingAPIの設定を更新し、スループットを向上させました。これにより、StreamingAPIはより多くの同時ユーザーに対応し、エラーが発生することなくサービスを提供することができます。オプションで、データベースの設定ルーチンを最適化するためにDB_POOL環境変数を明示的に指定するか、変更せずにStreamingAPIのDB_POOL値を10として使用しました。

結論

このチュートリアルでは、PostgreSQL、Sidekiq、Webサービス、およびStreamingAPIのボトルネックを特定および解決する方法を学びました。これで新しいサーバーをセットアップするか、既存のサーバーをスケーリングすることができます。

スケーリングアプローチは常に改善と洗練が可能です。例えば、複雑なSidekiqの設定は、さらにテンプレート化することができます。
公式のマストドンスケーリングガイドには、サーバーのスケーリングと最適化のさまざまな視点が含まれています。

サーバー上のユーザーエクスペリエンスを向上させるためのもう一つの素晴らしい方法は、ElasticSearchを使用した全文検索を有効にすることです。これにより、ユーザーは自分のステータス、メンション、お気に入り、ブックマークから結果を見つけることができます。

LibreTranslateを有効にすることで、Mastodonはトゥートや他のメッセージをユーザーの言語に翻訳することも可能です。