ハードウェア要件

ハードウェア要件

Overleaf を実行するハードウェアをプロビジョニングする際に考慮すべき主な要素は、同時にコンパイルを実行するユーザー数です。

例えば、合計で 100 人分のライセンスを持っているが、同時に作業するのは約 5 人程度と想定している場合、最小構成のインストールで十分です。より多くの割合のユーザーが同時に作業（およびコンパイル）することが予想される場合は、より高い仕様のサーバーのプロビジョニングを検討してください。

最小インストール

約 5 人の同時ユーザーで基本的な操作を行うための最小ベース要件は 2 コアと 3GB メモリです。この最小要件は、同時使用が少ない大きなグループや、負荷が高い使用時にコンパイル時間が長くなっても問題ない場合にも十分です。

小規模インスタンスで NFS（Network File System）ベースのファイルシステムの使用を検討している場合は、以下のセクションをご覧ください： トラブルシューティング セクション。

スケーリング

目安として、高く一貫したサービスレベルを提供するには、最小インストールに対して同時 5～10 ユーザーごとに CPU コア 1 個とメモリ 1GB を追加することを推奨します。

これはあくまでガイドラインとして受け取ってください。典型的なドキュメントのサイズ（大きなドキュメントはより多くのコンパイル資源を消費します）、ユーザーのコンパイル頻度、負荷時にコンパイル時間が長くなることへの許容度などの要素が、必要なプロビジョニングの水準に影響します。

多くのお客様は Server Pro を組織全体や大規模チームで展開することを検討しています。そのような場合、ユースケースや使用可能なハードウェアが大きく異なるため、特定の構成要件について当社から具体的な助言をすることは難しいです。

例 1	例 2
合計 300 人分のユーザー向けに Server Pro を運用しており、そのうち定期的に 30～60 人が同時にドキュメントをコンパイルすると予想される場合、合計で 8GB と 7 コア（5 コア + 5GB + ベースの 2 コア & 3GB）は、ユーザーに一貫して高いサービスレベルを提供するのに十分なリソースを提供するはずです。	より大規模な導入のハードウェア要件の例として、合計 1,000 ユーザー向けの Server Pro を単一サーバーで構築し、4 コアプロセッサを 2 基（合計 8 コア）とシステムメモリ 32GB を割り当てた構成で正常に運用されたことがあります。これは過去 1 年間の使用においてチームのニーズを満たすのに十分でした。

単一の大きなサーバーの限界を超えているお客様は、次を参照してください： 水平スケーリング （Server Pro 向け）

ストレージ

大規模なセットアップでは、プロジェクト／履歴ストレージに Network File System（NFS）/Amazon EFS/Amazon EBS を使用することは推奨しません。また明確に サポートしていません 水平スケーリングにおいて。

これらのファイルシステムの挙動は、高スケールで動作する Server Pro に必要なパフォーマンスと信頼性を提供しません。ファイルシステムが負荷に追いつけない場合、アプリケーションは多数のブロッキング IO 操作により停滞します。これらの停滞は Redis ベースのロックのオーバーランを引き起こし、結果としてプロジェクトデータの破損につながる可能性があります。

代わりに、以下の使用を推奨します： S3 互換のオブジェクトストレージ 。S3 のパフォーマンスが遅い場合でも、影響を受けるのは主にファイルのアップロード／ダウンロードのみであり、それにより S3 プロバイダへのオープン接続数が増加するだけで、アプリケーションのその他の挙動には影響しません。さらに、Server Pro は S3 リクエストに対して適切なタイムアウトを設定できますが、ファイルシステム／IO 操作に対してはアプリケーションレベルで同様の制御ができません。

参考として、GitLab もセルフマネージド提供において類似の立場を取っており、 NFS/Amazon EFS をサポートしていません 。

大規模導入向けの Nginx 固有の設定

デフォルトでは、Overleaf Server インスタンスは接続数を 768 に制限しています。これには永続的な WebSocket 接続、トップレベルの HTML ナビゲーション、および ajax リクエストが含まれます。制限に達すると、エディタが接続できなくなる、エディタページが完全に読み込まれない、コンパイルリクエストが失敗するなどの問題が発生する可能性があります。Nginx はステータス 500 を返し、次のようなメッセージをログに記録します： upstream に接続中に worker_connections が不十分です を var/log/nginx/error.log に sharelatex コンテナ内の

その worker_connections 設定は nginx がワーカーごとに受け入れる同時接続数を制限します。ワーカー数は worker_processes 設定で制御され、当社の nginx 設定ではデフォルトで 4 に設定されています。

Nginx はシステムの他の部分に比べてそれほど多くの作業を行わないため、これらの制限はシステムを圧倒する過剰な接続から保護する安全策として機能します。すべての接続を遅くするよりも、余分な接続を早期に切り捨てる方が望ましいです。

Overleaf Server インスタンスはこれらの nginx 設定を調整するための環境変数を公開しています：

• NGINX_WORKER_PROCESSES （に対して） worker_processes （デフォルト 4)

• NGINX_WORKER_CONNECTIONS （に対して） worker_connections （デフォルト 768)

• NGINX_KEEPALIVE_TIMEOUT （に対して） keepalive_timeout （デフォルト 65)

  別のプロキシをコンテナの前に置いている場合（例：TLS 終端のため）、Overleaf Server インスタンス内の sharelatex は前段のプロキシより大きくする必要があります。例えば、Docker ホスト上で別の nginx プロセスを動かしている場合 NGINX_KEEPALIVE_TIMEOUT nginx-host 、以下は 2 つの例です：デフォルト値

• 、使用する： NGINX_KEEPALIVE_TIMEOUTkeepalive_timeout 60s （upstream のデフォルト値）を に設定 、以下は 2 つの例です：

• カスタム値 NGINX_KEEPALIVE_TIMEOUT=100skeepalive_timeout 60s keepalive_timeout 90s （upstream のカスタム値）を 、以下は 2 つの例です：

CPU スピード

LaTeX はシングルスレッドのプログラムであり、同時に 1 つの CPU コアしか利用できません。CPU はドキュメントのコンパイル時の主な制約でもあります。したがって、CPU のシングルコア性能が速いほど、ドキュメントのコンパイルは速くなります。より多くのコアは、利用可能な空き CPU コアより多くのドキュメントを同時にコンパイルしようとする場合にのみ役立ちます。