> ## Documentation Index
> Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# ハードウェア要件

## ハードウェア要件

Overleaf を実行するハードウェアを用意する際に考慮すべき主な要素は、同時にコンパイルを実行するユーザーの数です。

例えば、合計 100 ユーザー分のライセンスを持っていても、同時に作業するのが 5 人程度と見込まれる場合は、最小構成で十分です。より多くのユーザーが同時に作業(およびコンパイル)すると見込まれる場合は、より高スペックなサーバーの用意を検討してください。

### 最小構成

約 5 人の同時ユーザーで基本的な操作を行うには、最低限 2 コアと 3GB のメモリが必要です。この最小要件は、同時利用が少ない大規模なグループや、利用が多い時間帯にコンパイル時間が長くなっても問題ない場合にも十分です。

<Danger>
  小規模なインスタンスで NFS(Network File System)ベースのファイルシステムの使用を検討している場合は、[トラブルシューティング](/ja/on-premises/support/troubleshooting)セクションの該当箇所を確認してください。
</Danger>

### スケーリング

目安として、高く安定したサービスレベルを提供するには、同時ユーザー 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 基と 32GB のシステムメモリを搭載した単一のサーバーで問題なく構築されています。この構成は、過去 1 年間の利用においてチームのニーズを十分に満たしてきました。 |

単一の大規模サーバーの限界を超えているお客様は、Server Pro の[水平スケーリング](/ja/on-premises/maintenance/horizontal-scaling)を参照してください。

### ストレージ

大規模な構成では、プロジェクトや履歴のストレージに Network File System(NFS)/Amazon EFS/Amazon EBS を使用しないことをお勧めします。また、水平スケーリングについては明示的に**サポートしていません**。

これらのファイルシステムの動作は、Server Pro が大規模に稼働する際に必要とするパフォーマンスと信頼性を提供できません。ファイルシステムが負荷に追いつけない場合、ブロッキング IO 操作が多すぎることでアプリケーションが停止します。こうした停止によって Redis ベースのロックがタイムアウトを超過し、その結果プロジェクトデータが破損する可能性があります。

代わりに [S3 互換オブジェクトストレージ](/ja/on-premises/getting-started/what-is-the-overleaf-toolkit)の使用をお勧めします。S3 のパフォーマンスが低下しても、影響を受けるのはファイルのアップロード/ダウンロードのみであり、S3 プロバイダーへのオープン接続数が増えるだけで、アプリケーションの他の部分の動作には影響しません。さらに、Server Pro は S3 リクエストに適切なタイムアウトを設定できますが、アプリケーションレベルのファイルシステム/IO 操作ではそれができません。

<Info>
  参考までに、GitLab もセルフマネージド版において [NFS/Amazon EFS をサポートしない](https://docs.gitlab.com/ee/administration/nfs.html)という同様の方針をとっています。
</Info>

### 大規模デプロイメント向けの Nginx 固有の設定

デフォルトでは、Overleaf Server インスタンスは接続数を 768 に制限しています。これには、永続的な Websocket 接続、トップレベルの HTML ナビゲーション、ajax リクエストが含まれます。制限に達すると、エディターが接続できなくなったり、エディターページが完全に読み込まれなかったり、コンパイルリクエストが失敗したりする可能性があります。Nginx はステータス 500 のレスポンスを返し、`sharelatex` コンテナ内の `var/log/nginx/error`.log に `worker_connections are not enough while connecting to upstream` を記録します。

[`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) 設定は、nginx がワーカーごとに受け付ける同時接続数を制限します。ワーカー数は [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) 設定で制御され、私たちの nginx 設定ではデフォルトで 4 に設定されています。

Nginx はシステムの他の部分に比べてあまり処理を行わないため、これらの制限は過剰な接続によってシステムが圧迫されるのを防ぐ安全装置として機能します。すべての接続を遅くするよりも、超過した一部の接続を早めに切断するほうが望ましいのです。

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

* [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) 用の `NGINX_WORKER_PROCESSES`(デフォルト `4`)
* [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) 用の `NGINX_WORKER_CONNECTIONS`(デフォルト `768`)
* [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) 用の `NGINX_KEEPALIVE_TIMEOUT`(デフォルト `65`)

  <Info>`sharelatex` コンテナの前段に別のプロキシを配置している場合(例: TLS 終端のため)、Overleaf Server インスタンスの `NGINX_KEEPALIVE_TIMEOUT` は前段のプロキシの値より大きくする必要があります。例えば、Docker ホスト <strong>nginx-host</strong> 上で別の nginx プロセスを実行している場合の 2 つの例を示します。</Info>
* `NGINX_KEEPALIVE_TIMEOUT` がデフォルト値の場合、**nginx-host** で [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout)(upstream のデフォルト値)を使用します
* カスタム値 `NGINX_KEEPALIVE_TIMEOUT=100s` の場合、**nginx-host** で [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout)(upstream のカスタム値)を使用します

### CPU 速度

LaTeX はシングルスレッドのプログラムであり、一度に 1 つの CPU コアしか利用できません。また、ドキュメントをコンパイルする際の主なボトルネックは CPU です。したがって、CPU のシングルコア性能が高いほど、ドキュメントを高速にコンパイルできます。コア数を増やすことが役立つのは、空いている CPU コアの数よりも多くのドキュメントを同時にコンパイルしようとしている場合だけです。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.